Discussion about supporting deployment of Bahmni on Docker

Hi all

I am publishing here MSF OCB’s motivations and reflections around official support for deploying Bahmni inside (one or multiple) Docker container(s). I hope this will lead to a constructive discussion about the pro’s and the cons and an eventual decision about whether or not the community and the consortium wish to officialy support this platform.

So here goes.

We see a couple of different benefits from our perspective (in no particular order):

  1. Docker allows us to run multiple instances of Bahmni on the same server, without Docker we need an additional separate server to be able to have, for instance, an on premise UAT version and we are then still limited to a single UAT per additional server. With containers we can run multiple UAT containers on the same hardware as the production system, given that we have sufficiently powerful servers. This is a big win in terms of resource usage and flexibility.
  2. We do not want to be bound to the platform Bahmni runs on (currently CentOS 6) for our servers, the platform is very old and no longer supported which poses very serious security risks and the choice for this platform to host sensitive medical data would be very hard to defend during an audit or following an eventual data leak or security incident, potentially severely impacting our reputation and credibility as an organisation. Containers give us the flexibility to run a modern and updated OS on the server without having to change the Bahmni code. In an ideal world, Bahmni and its components would receive frequent security updates and would no longer depend on a platform like CentOS but instead run on a minimal container-oriented OS like Alpine to further decrease the attack surface.
  3. Containers offer us the possibility to completely test and validate new versions and updates before rolling them out to our health facilities instead of having to replicate the server set-up with VMs. Working with these VMs also has the risk of configurations of testing servers and the production servers diverging over time. The configuration of the CentOS servers cannot easily be managed and controlled centrally like it can with Docker images whose Dockerfiles can be stored in a version control system and which can be designed to produce reproducible builds.
  4. Containers give us the possibility to do atomic and very quick change-overs from one version to the next instead of having to run a lengthy Ansible script. This reduces the down-time significantly and reduces the amount of time spent by employees outside of the regular working hours to do upgrades. They also allow to do a rollback in case of issues whereas with the current in-place procedure we would need to resort to a full reinstallation of the previous version which takes a lot more time. In short, we can have quick, atomic and reversible upgrades which can be fully tested beforehand.

The obvious downsides are the increased complexity and Docker forming an extra layer of possible bugs. But I believe that in the conditions in which we are deploying and supporting Bahmni, these downsides do not outweigh the benefits.

The logical next question, is about the level of splitting out Bahmni components across multiple Docker containers. While I believe there is definitely a good reason to do this (compliance with the trend of the general industry, reduced complexity per container, guarantees about interdependencies of components, etc.), I would consider this as a secondary concern, the first one being to simply run Bahmni inside a monolithic container. I’m also less certain about (and less experienced in) the possible downsides of having to manage a complexly orchestrated container system.

For what concerns the work already done by OCB, we have deployed a version of Bahmni (OpenMRS, OpenElis, Bahmni reports) running in a monolithic container with only minor changes to the Bahmni installer scripts. The changes entail mostly omissions of unneeded parts installing and configuring the CentOS environment. I believe it would be worthwhile however, to revisit most of the Bahmni installer scripts and rewrite these in a way that reduces the coupling between Bahmni and the underlying platform, both with an upgrade to CentOS 7 and the possibility for Docker in mind. Many parts are fairly specific and tightly coupled to the current CentOS 6 platform and could make less assumptions about the underlying platform being installed on, or could be made entirely optional so they can be easily excluded when not required.

A minimal (but monolithic) installation of Bahmni in Docker, would for me have primarily the following features:

  • Minimal dependency on a specific platform (init system, package manager, local firewall enabled, selinux present, … many small assumptions)
  • Does not manage system users, ssh config, etc itself (unless explicitly asked to in the installer config)
  • Transparently configurable cron jobs instead of the current situation where many jobs being inserted from different parts of the installer without a way to control them
  • Perfectly reproducible, no downloads from the internet (unless specifically asked for in the installer config)
  • No extra admin tools, or system services (e.g. ntp) installed (unless requested in the installer config)

This list is not exhaustive, we can probably come up with a more detailed and workable specification together.

Please let me know your thoughts and then we can see if there’s willingness to take this further and if yes who will lead the effort and in which direction.


@ramses, I just wanted to mention that we haven’t forgotten about this, and hopefully now that our 0.91 release is getting close we will start to have more Product Architecture Team call time to have a good discussion around this.

I can only second all of this. We have gone for using our own Docker containers that fit to our custom CD pipelines, so to say that we couldn’t wait. However we would be 100% supportive of any work going in the direction of improving Bahmni Docker in line with @ramses comments.

1 Like

@darius, I’m glad to hear that. I try to attend the PA calls whenever possible. It would definitely be good to have a general discussion about this, together also with other people and organisations who already made steps in this direction.

@mksd, I would be happy to exchange code and experiences, I’d like to see how other implementations approached this. We can setup a skype call to discuss about this if it interests you.

Hi @ramses, sorry about the late reply.

Sure that sounds like a great idea, what about next week? I think we are on the same timezone which will make things easier.

Let’s do this through this Doodle poll, so if anyone else wants to join, they can voice it on the poll:

Cc @mksrom @zouchine

Hi @mksd

Thanks a lot for the initiative!

However, I have a very busy schedule for the upcoming weeks. Any chance that we can postpone this until the week of the 10th of September?

Thanks again!

@ramses I have updated the poll so that time slots can be chosen during the week of Sep 10th.

Cc @binduak @swathivarkala @angshuonline @mksrom

I just sent a meeting invite for Sep 11th @ 2pm CEST (5.30pm IST) to those who participated in the Doodle poll.

Our team will follow up on this thread with specific discussion points that we hope to be covered during the meeting.

How did you guys go with this? We’re keen to deploy the EndTB release of Bahmni as a monolithic container in the short term, to simplify things a little. I’m also keen to assist, so if there’s anything I can do to help, please shout out.

@andrewwalter: we have done exactly this for a recent project. We have EndTB running in a single monolithic docker image. We have two hosts with MySQL replication between the two. The same docker set-up is also being used in multiple implementations with the regular Bahmni version.

The set-up for the moment is pretty rudimentary and quite tied to our specific environment, but the code is public and can probably be generalised (and improved) to accommodate other environments/organisations as well. Or at the very least it could serve as inspiration.

Unfortunately, there is very little documentation at the moment, we hope to improve upon this eventually but given that we are a very small team with a lot of demands, it’s not our top priority at the moment.

Anyway, you can have a look and please feel free to contact me for further details if needed.

1 Like