Upgrade Joomla with Docker

[MegaShinySnivy]

A friend and I are running a Joomla blog via docker compose, and were wondering what the proper upgrade steps are. We don't see a good method for upgrading, as even with the latest container, it is still reporting that 4.1.3. is installed. We assume this is because the database was not upgraded with the main server. What is the proper upgrade path, and how do we perform it?

[Llewellynvdm]

The proper upgrade path is at this time simply updating via the Joomla admin backend area.

There has been work done, that we may in the future introduce a CLI path into the docker upgrade path.

I suppose you have your Joomla files and database setup in a persistent state, and in this case I would normally update Joomla in the admin area as normal, then I would stop the container, and remove the image, update the composer file, and start up the container again. Since the image will not override any files or database that has been linked to your container persistently this will only update the PHP environment, and not really effect Joomla directly.

But yes there is no docker way to update from one version of Joomla to the next at this time.

[jastlw]

@Llewellynvdm Thx for your response.

Is there a timetable by when the update will be introduced through the Docker image?
Dockerised wordpress can this since its introduction.

I would like to migrate to dockerised Joomla with update option, but waiting for its support.

[MegaShinySnivy]

What files need to be persisted? I was aware of the database, what of the actual files in the joomla container?

[wilsonge]

images directory for sure. Potentially extensions too

[Llewellynvdm]

Okay so we simple do a check here on line 79 of the entry point that stops the rewrite of the existing "persisted" files. And even if we don't find these core files, we give an warring on line 85 with user input possible to stop the process by press Ctrl+C which will stop the process. We could therefore easy adapt this process on the file level without any major changes needed. Since overwriting the files will be seen as a manual update, and in Joomla there is a discovery feature to fix the database should there be any needed. Further more we can auto delete the installation folder should we detect this is an update.

[richard67]

@Llewellynvdm The database fixer fixes only the structure but not the data, and we do data changes in updates. Discovery installation will also not solve everything.

[Llewellynvdm]

@richard67 okay can we use the CLI update to resolve this? I mean is there any way currently to get around these limitations from a CLI stand point? Also if we could focus on only the minor versions, and not step over to major versions... not that that will not also be ideal, but just to get the initial update path in place.

[richard67]

There are options to check for core updates and if some found to update the core with cli, see e.g. php cli/joomla.php core:update

I’m not an expert on the cli but as far as I know it runs the database updates and some of the necessary steps after that, e.g. migrating the repeatable fields to subforms when updating from 3.10 to 4.

For 5.0 we will have other migrations. If the cli is missing some of that we have to fix that. So all in all cli update should work, but that is of course not docker based.

[Llewellynvdm]

What do you mean:

but that is of course not docker based.

Docker is CLI and if we have persisted files we can check if the needed 'cli' files exist and trigger any commands just like you can in any command line interface (CLI) since we are in the PHP base image. That means we should be able to update our entry-point script and catch these edge-case behaviour as needed.

[Llewellynvdm]

I would like to migrate to dockerised Joomla with update option, but waiting for its support.

@MegaShinySnivy, after examining the Wordpress instances, I honestly cannot discern any difference in the implementation. As I previously mentioned, our method involves checking if the core files persist. If they do, we avoid redeploying the update package, which is essentially the same process as what they're doing. Therefore, if you choose not to persist your website's root folder, it would naturally result in a new file set. But in Joomla this will be like a new installation, since the database config file will also be lost, and even if that was the only file to persist, the database would be "un-update" and possible be giving errors.

I've noticed that they possess a completely dedicated set of images for CLI commands. I haven't had the opportunity to work with their tools, so I can't definitively say how it operates. However, I suspect this feature facilitates effortless updates and migration control.

Achieving this without the need for an additional set of images is something we're aiming for, there has been some conversations in the CMS maintenance team, and the current consensus would be to test the CLI for Joomla 4+ as a possible means to achieve this objective.

Let me know if your willing to run some tests, basically using the CLI command to update your system in a docker container. at the same time as updating the docker image. Should you be interested I could pull up some testing images in my private repository and update the entry-point as I mentioned before.

[MegaShinySnivy]

I can run some tests, sure, though obviously not in production. Give me the details and I'll spin something up.

[ReinerNippes]

@Llewellynvdm Any news on this topic?

We would like to deploy and maintain "a bunch" of Joomla instance fully automated. Any click here in the GUI or CLI is a no go for us. Since we deploy with ansible and awx we would like to update everything by running playbooks and have full control over the versions in the ansible inventory. Just to explain our background. I'm doing this with Nextcloud since years and it works great.

Since you have "Updade Packages" why not to include them in the image, check if the installed version is != the version in the update package the run php cli/joomla.php core:update --path /usr/src/Joomla_5-2-3-Stable-Update_Package.zip (In case that's way update packages are installed.

[Llewellynvdm]

Thank you for your response and for sharing your use case and ideas. I completely understand the desire to fully automate the deployment and maintenance of multiple Joomla instances using tools like Ansible and AWX. Having a reliable and automated process that eliminates manual steps is certainly an ideal solution. Let me address your points and provide some additional context.

1. Including Update Packages in the Image

While the idea of bundling update packages directly into the image is worth exploring, it does introduce some considerations:
• Image Size: Adding update packages would increase the size of the Docker image. Official images aim to stay as lean as possible to reduce download times and storage requirements, which is a key principle of containerized applications.
• Hash Validation: The current image build process already includes a hash check to validate that the downloaded Joomla package matches the intended version. Adding update packages would simply mean introducing an additional hash value in the Dockerfile to validate the integrity of the patch or update package. While not a rigorous process, this hash validation is an essential step to ensure that no unintended modifications are introduced during the image build.

2. Automated Upgrade Path

Your proposed workflow of checking the installed version against the version in the update package and automating the upgrade using CLI commands (e.g., php cli/joomla.php core:update) is logical and aligns with the goal of automation. However, real-world Joomla upgrades often involve additional challenges:
• Configuration Changes: Some upgrades may require updates to the configuration file.
• Incompatible Extensions: Plugins or extensions that are not compatible with the new version need to be removed or replaced manually.
• Database Migrations: Certain upgrades include schema changes that may not always be handled seamlessly by the CLI upgrade process.
• Recovery from Failures: Unlike systems like Nextcloud, Joomla lacks a robust built-in recovery mechanism for failed upgrades. When issues arise during an upgrade, manual intervention is often required to restore the site to a functional state.

3. Nextcloud as an Example

Nextcloud is an excellent example of a containerized system with advanced automation. Its ability to manage multiple instances, run automated updates, and recover from failures is impressive. However, Joomla’s current Docker image is much simpler in comparison, as it focuses on providing a basic runtime environment rather than advanced management features. Bridging this gap will require thoughtful improvements, especially around automation and resilience.

4. Testing the Proposal

The idea of automating the upgrade process via Docker has been discussed in the past, and I maintain a test image specifically for experimenting with such ideas. I plan to:
• Test an automated upgrade workflow based on version checks and CLI commands.
• Evaluate potential issues, particularly for major version upgrades (e.g., Joomla 4 to Joomla 5).
• Assess the feasibility of integrating this functionality into the official Docker image while balancing concerns around image size and complexity.

5. Hash Validation in Practice

To provide more context, the current image build process downloads the Joomla package during the build and validates it using a predefined hash in the Dockerfile. If we were to include update packages, this would involve adding a second hash for the patch file to ensure its integrity. While this is a relatively straightforward process, it still adds an extra step to the build pipeline that needs to be carefully managed.

6. Long-Term Goals

Your proposal aligns with the community’s long-standing goal of improving automation in Joomla’s Docker ecosystem. While automating upgrades entirely is ambitious, it’s a worthwhile pursuit that could significantly enhance Joomla’s usability in automated deployment scenarios.

Next Steps

I’ll proceed with setting up a test image to evaluate your proposed workflow. This will include:
• Incorporating version checks and CLI-based upgrade commands.
• Testing upgrades from Joomla 4 to Joomla 5, as well as within Joomla 5.x, to identify and mitigate potential challenges.
• Sharing a link to the test image for further feedback and collaboration.

Thank you for contributing to this important discussion. Let’s continue to explore these ideas and work towards a more automated and robust Joomla Docker solution.