PKP Hannover 2023 Sprint Notes released: Easy containers for OxS

The sprint notes from the PKP Hannover Sprint, hosted by the Leibniz Information Centre for Science and Technology in September 2023 are now available.

Sprints involve PKP community members joining diverse groups to work on PKP software and support. The Leibniz Information Centre for Science and Technology (TIB) hosted six working groups at the PKP Hannover Sprint in September. This is a summary of one such group’s work.

Group Members

• Jarda, Public Knowledge Project
• Mathias, University of Bordeaux
• Jyrki, TSV, the Federation of Finnish Learned Societies
• Hanna, University of Göttingen
• Marc Bria, Universitat Autònoma de Barcelona

Background

Editors do not usually have technical staff to help them with technology. The most widespread model is a central technical service that does not know the details of PKP and that installed OJS a thousand years ago but does not know how to update it. Containers offer the possibility of isolating this complexity, understanding the application as a black box.

For some years some group members have been exploring the use of containers for PKP applications.

Some members of the group already use containers in production and propose it as a technology for production but also a quick approach to the tools.

There is a lack of clear documentation to make it easy to get started with this technology, both for demos and for production.

Goals

The group wants to reflect on the real potential of this technology in the PKP community, test the existing images in different platforms (Linux / Mac / Windows),  improve the existing documentation and tools to facilitate the start-up with containers, and make recommendations for use.

Results

Taking from different perspectives (newcomers, devs, sysadmins, community…) we arrive at two simple conclusions that could be summarized:

• We won’t probably need docker images for developers yet, but they will probably be necessary in CI.
• We need official images for production (recommended way), but we need to let people build based on their needs.
• We need to clarify how to deal with plugin management: the proposal is based on managing plugins as a volume in the host.

Results (including documentation) are published in docker-ojs repository. 

At a high level, we expect that “starting an OJS with docker” will be as easy as:

1. Install docker and docker-compose. 
2. Pull the repository
3. Run the docker-compose.
4. Run OJS’s installation wizard from your browser at https://localhost:8081

At a low level, after the work done in the sprint, this is now possible to run:

$ git clone https://github.com/pkp/docker-ojs.git

$ mv docker-ojs journalName && cd journalName

$ mv .env.TEMPLATE .env

$ vim .env # change the environment variables (ojs version, ports, container name, url…)

$ source .env && wget “https://github.com/pkp/ojs/raw/${OJS_VERSION}/config.TEMPLATE.inc.php” -O ./volumes/config/ojs.config.inc.php

$ docker-compose up -d

Next Steps

• In general with docker, there are some known issues with the new Mac’s ARM architecture: https://stackoverflow.com/questions/73294020/docker-couldnt-create-the-mpm-accept-mutex . An alternative solution (other than hardcoding mutex settings) might be to build a docker image also for the arm64 platform (https://github.com/bitnami/containers/issues/4679). Some work was started in this line in GitLab building pipelines with promising preliminary results.
• Instructions to run are for Linux (as far as Linux is the natural platform for docker and servers) but it is also possible to run it in Windows. Then get instructions to use variables defined in the env-file but this is not compatible with Windows Powershell, so would be nice to find an alternative that works on all platforms. As a temporary solution, we add clear instructions for Windows users who need to modify the inline to get the right version of the config.TEMPLATE file.

• A nice addition for docker images would be to offer Nginx images to replace the existing apache2.
• One thing you always will need to deal with is plugins. This is now possible but could be improved with a few ideas that appear during the sprint as:
  • Use volumes managed with git
  • Create a new OJS plugins script helper that backs and downloads the essential release plugins for your version. 
• A lot of work still needs to be done to implement the suggestion made in the containers pkp document.
• Will be necessary to automate docker image building and pushing to different repositories.