Dockerizing development and deployment of OpenMRS


Hi @raff , especially thanks for this. We at Mekom deploy OpenMRS on ARM devices, so that’s not only for devs with M1 chips, but also prod use!


@raff is this still the best image for folks to be using? (Asking because this is what @binduak & team is currently using for the Bahmni upgrade to Platform 2.4.2)

@grace I forgot about the openmrs-distro-platform. It needs to be updated as well. I’ll do that next week.

@raff These images seem to end up with broken file permissions. Trying to run openmrs-distro-referenceapplication from the 3.x branch results (with the CI built images) results in this error:

cp: cannot create directory '/openmrs/data/modules': Permission denied

The error reported on Slack for Initializer seems related.

@ibacher the issue should be fixed now.

A small update on the progress… It took a bit longer than expected to convince our CI to build arm images, but it is finally working. ARM images are available for: openmrs-core, openmrs-reference-application, openmrs-reference-application-3-backend/frontend/gateway

Please note that I unified the image name of reference application 2.x with 3.x and we now publish openmrs-reference-application instead of openmrs-reference-application-distro. I will apply the same to openmrs-distro-platform, which will become openmrs-platform.


Thanks for the heads up. I’m trying to think of all the documentation where we need to redirect people. Probably as a start.

So I mentioned this pedantic concern of maintaining our links across our spaghetti-pile of documentation/wiki-pages to @burke today and he had a good suggestion - we could have standard short-links for each image. That would give us just one single place to maintain (i.e. in our short link admin). How does this idea and these specific suggestions sound to you @raff @ibacher?


Am I missing anything? (Totally open to different suggestions.)

@grace, it is a good idea. We should have in addition to the above. I imagine would point to Docker Hub and from there we could document frontend and gateway images are also needed to complete the stack.

That said when referring to those images from docker-compose.yml or command line one would still need to say openmrs/openmrs-reference-application-3-backend, etc.

1 Like

Another option (possibly easier to maintain over time even with future major changes to our Docker approach similar to what we are doing now) would be to just use when referring to any of our docker images in documentation and leverage documentation of our Docker Hub pages/images to guide people to the correct image.

In other words, if we can make the OpenMRS landing page on Docker Hub informative and have clear README & image naming conventions for our images, it might be enough to send someone to with instructions to grab the latest reference application image or the platform image, etc. Then we wouldn’t have to juggle a bunch of image-specific short links.

1 Like


Could you join our Platform Team call next week (Wednesday, 10 August, at 17:00 UTC) and walk us through the current state & plans for dockerized deployment of OpenMRS? @ibacher, @dkayiwa, myself, and others would like to understand how things are being built & wired together. In return, we could help use what we learn to improve documentation on Docker Hub and prepare for a broader discussion with organizations in the community using Docker in their deployments (to build consensus on the approach not only for demos & reference application builds, but as an exemplar for anyone distributing/deploying OpenMRS).

On a related note, we’re currently using this Talk thread and the #infra Slack channel for issues with docker builds. As the approach matures, we should probably be creating tickets for issues that come up with builds & docker images. Am I correct in assuming we would create JIRA tickets in the project associated with the particular artifact (e.g., TRUNK, PLAT, O3, etc.)? @ibacher mentioned today he was running into an issue where openmrs-reference-application-3-backend would run for him locally, but was failing to run on the demo server.


@burke, yes, I’ll be happy to join and discuss! I should be able to add some docs around new docker images tomorrow as the setup seem to be stabilised enough now.

A small update… The platform is now being published at Docker Hub with ARM64 and AMD64 images for the master branch. I still need to make a few tweaks to speed up the builds with cache and then I’ll be ready to apply the same to older maintenance branches of core and platform.

I’ve been also trying to understand and address issues with o3 for the last few days. They are not directly related to the docker work, but in general to the o3 development. More on this here.

Today, I’ll be increasing storage on our bamboo agents so that we don’t hit the no space left errors when building.

1 Like

@burke could you include me in the invite for the call on 10th

1 Like

This is a Platform Team call. You’re welcome to join! :slightly_smiling_face: Details (when & how to join) available on