OpenMRS on Kubernetes

Implementing
1

I’m pleased to announce the 1.0.0 release of OpenMRS Helm Chart for Kubernetes!

OpenMRS on Kubernetes is probably the most robust, scalable and failure resistant deployment of OpenMRS ever seen! And it was never easier to deploy OpenMRS on Kubernetes thanks to the OpenMRS Helm Chart.

Please head to Kubernetes for more details.

We cannot wait to hear your experience running OpenMRS on Kubernetes. Thanks to all who contributed to this work! @mherman22 and @kb019 for code contributions, @dkayiwa for tireless code reviews, @grace for engaging us with the community and many others!

5 Likes
2

Following up on the recent discussion during the platform call, which you can listen to here: Platform Meeting - Indiana University

I’m excited to hear that Kubernetes is being evaluated for KenyaEMR and others!

A few key points that I don’t think were mentioned:

  1. If you want to support multiple sites in a single Kubernetes cluster, you don’t need to run separate MariaDB, ElasticSearch and MinIO clusters. It’s more efficient hardware wise to re-use them for multiple sites by defining separate schemas/locations when deploying a new instance of a backend and frontend. Such an option is not provided out of the box by the helm chart, but it can be easily extended to do that, which I’m happy to help with. Please reach out directly to me. It is a huge resource usage improvement as for running an instance of a backend and frontend for an additional site should suffice as low as 2vCPUs, 4 GBs of RAM and 20 GBs of disk space.
  2. Kubernetes Ingress can be easily configured to re-use a single domain to proxy to different instances with a sub-path or sub-domain.
  3. Keycloak SSO has proved to work nicely with OpenMRS so you can deploy a single Keycloak (with 2 replicas for HA) to Kubernetes in front of all your instances and upon login transparently redirect users to their site. All users access the system via the same entry-point this way e.g. top level domain and all are managed from a central place and given access only to the sites they need. If they try to access a site that they do not have access to, they may be even redirected back to their site or to Keycloak to login with different credentials.
  4. If you intend to run multiple sites in the same cluster, it is highly recommended to use a continues delivery tool like AgroCD (deployed to Kubernetes as well) to easily provision new sites or roll out upgrades to all sites.

Please reach out if you have any questions.

3

@PalladiumKenya is this helpful?

4

Thanks @raff for the additional info. This will be helpful.