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):
- 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.
- 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.
- 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.
- 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.