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.
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:
Run: make backup
Run: docker compose stop app
Edit the .env file DHIS2_VERSION=[your new version]
Run: docker compose pull app
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)
Run: docker compose logs -f app
If this doesnāt go right, weāll need to restoreā¦
Edit .env file, set DB_RESTORE_FILE to use the ./backups/ .pgc file
Run DB_RESTORE_FILE=<your-backup-timestamp>.pgc make restore
Edit .evn file, set DHIS2_VERSION to the original version
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.