Docker version upgrading

Hello.

We use dhis2 images in dockers for testing porpouses.
Each time I need to upgrade dhis2 version in one of them I rewrite the yml file, then delete the docker and compose it again.

Doing this I loose everything in the docker, the database, the file structure.

I am not a docker expert and this might not be a dhis2 directly related question. What I need is a procedure to update the dhis2 version in the docker, keeping the docker folders. Just an update, not a complete rebuild as I am performing now. This will save me a lot of time in testing.

If anyone has a clue I would apreciate it.

Thanks.

Hi @JaimeLopez

It’s great to hear that you are using docker deployments for testing purposes. I have some notes and tips to share but I look forward to your feedback on how it goes, and I actually want to ask you if you’re already using this method: Official DHIS2 Docker deployment system open for beta testing

I’d like to point out one important thing regarding updates/upgrades: please note that there are two paths: a) updates b) upgrades. a) updates are for the same version but a patch-releases. For example, from version v42.1 to v42.2 (same version but updated). And b) upgrades are for a higher version. For example, from v42 to v43.

It’s important to make this distinction because sometimes upgrades requires admins to go through the ā€˜upgrade notes’ and make some changes before the upgrade itself. The reason I mention this is even if you follow an upgrade on Docker, you might still need to go through those notes and make changes first.

Additionally, if the upgrade notes require certain upgrade versions such as postgresql version upgade then the process below might fail..

To answer your question I need to test the steps below so if you have some free time, you’re welcome to test them before I do:


Please try these steps in a clone test instance and let me know how it works for you:

  1. Run: make backup
  2. Run: docker compose stop app
  3. Edit the .env file DHIS2_VERSION=[your new version]
  4. Run: docker compose pull app
  5. Run: docker compose up -d (maybe restarting only app would work in patch updates but I need to test this as well docker compose up -d app)
  6. Run: docker compose logs -f app

If this doesn’t go right, we’ll need to restore…

  1. Edit .env file, set DB_RESTORE_FILE to use the ./backups/ .pgc file
  2. Run DB_RESTORE_FILE=<your-backup-timestamp>.pgc make restore
  3. Edit .evn file, set DHIS2_VERSION to the original version
  4. Run: docker compose up -d app

Hi @JaimeLopez ,

In addition to the advice above, I would say in terms of a ā€œclueā€ you should look into, and understand, docker volumes and volume mounts in docker compose. They are the main way to persist data (although backups that @Gassim mentions are, of course, the ā€œultimateā€ way to protect data).

If you look at the project that @Gassim linked, it might look a bit too complex, but you can see an example there of the use of volumes in the main compose file. There a volume called dhis2 is created and mounted to /opt/dhis2/ in the dhis2-core container (this contains config and filestore); and a volume called postgres is mounted to /var/lib/postgresql/data in the database container (this contains the actual DB data).

Unless you explicitly remove volumes, they will be kept when you stop/delete and start/re-deploy the containers.

Kind regards,
Phil

1 Like