Heads up, I was working in a similar thing a little bit ago. It’s still in review, but I suppose it will be merged soon~ish.
That will make the docker image a little bit more configurable by itself, in isolation of the docker-compose. So the docker image can be a proper build artefact which can be configurable independently. You know,
docker build and
You will be able to potentially deploy the docker image to a docker registry (docker hub or internal registry) or build it independently, without ‘docker-compose build’. And then you will be able to configure several different docker-compose based on the same image deployed.
Here, an example of that using refapp:2.6: https://github.com/cintiadr/docker-openmrs/blob/master/docker-compose.yml
The docker image you see there were generated by the SDK (the code on the PR) and pushed to docker hub. It wasn’t committed anywhere.
I can tell you what I plan to do it from CI on our internal openmrs environments:
- Each build that we want to deploy will upload a docker image to docker hub, versioned with a tag. Like ‘my-distro:nightly-56’ for build 56.
- Each release will deploy a proper version to docker hub, like ‘my-distroy:2.6’ for version 2.6
Each of my environments will have a docker-compose file, committed somewhere. I still don’t know if I’m going to update a tag to docker hub (let’s say, tag my-distro:nightly-57 as my-distro:qa), if I’m going to commit the version to the docker-compose file or if I’m going to use a ‘template’ and replace it with the version received by CI during deployment. Still not sure.
But the docker-compose file used on our environments will not be the one that the SDK generated. It’s lightly based on it, modified to what the environment needs. From the SDK I will only use the docker image, not the compose file.
Of course you don’t need to push to docker hub, it can be only local images. But overall, you want the very same image to be used in tests AND production, you don’t want to recreate it.
If you are running multiple CI agents on the same machine sharing the docker environment, you can run into quite a lot of problems…
Based on that, I’d always build a different docker image named after the buildnumber (let’s say, ‘awesome-distro:5’ for build 5). Remembering that you can tag the same image multiple times, for example, ‘awesome-distro:local’.
Your docker compose would quite possibly not leave on the same repo, something like https://github.com/cintiadr/docker-openmrs/blob/master/docker-compose.yml
That’s how I plan on deploying our disposable environments: I’ll deploy the ‘release candidates’ docker images to docker hub, and each environment will have a different docker-compose file.