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:
- 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 welldocker 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
- Run:
docker compose up -d app