# Dockerizing development and deployment of OpenMRS

**URL:** <https://talk.openmrs.org/t/dockerizing-development-and-deployment-of-openmrs/36410>\
**Category:** Development\
**Tags:** ohri, o3\
**Created:** [April 12, 2022, 11:01am UTC](https://talk.openmrs.org/t/dockerizing-development-and-deployment-of-openmrs/36410 "2022-04-12T11:01:20Z")\
**Posts on this page:** 18\
**Page:** 3

<div class="post-metadata">

**Author:** ![raff](https://talk.openmrs.org/user_avatar/talk.openmrs.org/raff/32/11894_2.png) [@raff](https://talk.openmrs.org/u/raff)\
**Post date:** [September 28, 2022, 4:36pm UTC](https://talk.openmrs.org/t/dockerizing-development-and-deployment-of-openmrs/36410/41 "2022-09-28T16:36:33Z")

</div>

> [@raff](#):
>
> It deploys only backend and for now it needs to be triggered manually if dependencies change. The frontend is still served from CDN and updated automatically whenever any O3 repo changes. Eventually we will be deploying frontend via Bamboo as well, but this can happen only when we make it discover o3 repo changes without having to trigger anything manually.

I’ve just discovered that this has been already addressed by @ibacher. So the plan is triggered whenever changes to O3 components are made and everything is being deployed. Thanks @ibacher!

---

<div class="post-metadata">

**Author:** ![burke](https://talk.openmrs.org/user_avatar/talk.openmrs.org/burke/32/17_2.png) [@burke](https://talk.openmrs.org/u/burke)\
**Post date:** [September 30, 2022, 4:42pm UTC](https://talk.openmrs.org/t/dockerizing-development-and-deployment-of-openmrs/36410/42 "2022-09-30T16:42:33Z")

</div>

I know you’ve seen this, @raff, but I want to ensure this Talk thread gets linked to a related discussion on Talk:

> [@Adjustment to 3.x Frontend Process - “Test” Environment](https://talk.openmrs.org/t/adjustment-to-3-x-frontend-process-test-environment/36496/11):
>
> A couple months later, we have made some progress, and the end vision is slightly different: We (or at least I) have come to realize that local (docker) setup is very important piece of this puzzle, and is missing from original diagram. Ian has been working hard on transitioning the whole pipeline to be using the same docker containers, so this is at least in progress. From our call yesterday it sounds like that is its own domain with many features still to be made to make it fast and predicta…

---

<div class="post-metadata">

**Author:** ![mohant](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mohant/32/15443_2.png) [@mohant](https://talk.openmrs.org/u/mohant)\
**Post date:** [October 13, 2022, 6:40am UTC](https://talk.openmrs.org/t/dockerizing-development-and-deployment-of-openmrs/36410/43 "2022-10-13T06:40:41Z")

</div>

Hello @raff, Bahmni team is using openmrs/openmrs-distro-platform:2.5.7 as the base image and we have enabled multi-architecture builds in [Github Actions](https://github.com/Bahmni/openmrs-distro-bahmni/blob/master/.github/workflows/build_publish_openmrs.yml#L53). The builds are successful and the [docker images](https://hub.docker.com/r/bahmni/openmrs/tags) have both the architectures now. But still OpenMRS is not coming up properly on Mac M1 machines. We have also tried `openmrs/openmrs-distro-platform:2.5.7 ` image on M1 but that too didn’t start. Do you have any suggestions/ experiences on running OpenMRS containers in Mac M1? Would you suggest trying out any other base image on M1 ?

cc. @gsluthra @angshuonline @binduak @shobanadevi @n0man @mradul.jain

Thanks.

---

<div class="post-metadata">

**Author:** ![raff](https://talk.openmrs.org/user_avatar/talk.openmrs.org/raff/32/11894_2.png) [@raff](https://talk.openmrs.org/u/raff)\
**Post date:** [October 13, 2022, 11:12am UTC](https://talk.openmrs.org/t/dockerizing-development-and-deployment-of-openmrs/36410/44 "2022-10-13T11:12:05Z")

</div>

@mohant Could you please share logs? Have you seen [O3: M1 machine support - #8 by dkayiwa](https://talk.openmrs.org/t/o3-m1-machine-support/37639/8) ?

Basically try increasing available memory and make sure not to hit any REST endpoints before fully started up due to an issue with the backend.

I’m able to run with 8 GB of memory, 4 vCPUs, 1 GB swap, 160 GB disk image size.

---

<div class="post-metadata">

**Author:** ![shobanadevi](https://talk.openmrs.org/letter_avatar/shobanadevi/32/6_22734026db12803ebb3e059622ac3534.png) [@shobanadevi](https://talk.openmrs.org/u/shobanadevi)\
**Post date:** [October 17, 2022, 3:58pm UTC](https://talk.openmrs.org/t/dockerizing-development-and-deployment-of-openmrs/36410/45 "2022-10-17T15:58:16Z")

</div>

@raff I have 7.90 GB memory, 5 CPUs, 1GB swap and 59.6 GB disk image. Earlier i was able to run openmrs even with lesser memory, CPU and disk image than this. Will try with what you have suggested and update.

---

<div class="post-metadata">

**Author:** ![shobanadevi](https://talk.openmrs.org/letter_avatar/shobanadevi/32/6_22734026db12803ebb3e059622ac3534.png) [@shobanadevi](https://talk.openmrs.org/u/shobanadevi)\
**Post date:** [October 19, 2022, 3:45pm UTC](https://talk.openmrs.org/t/dockerizing-development-and-deployment-of-openmrs/36410/47 "2022-10-19T15:45:30Z")

</div>

@raff tried with this storage(8GB memory, CPU -6, swap 1GB, Disk image size 160GB) and still openmrs is not up. shared logs [openmrs.txt](https://talk.openmrs.org/uploads/short-url/59R6n2iDeb67zd52Bz8FMhZXPbs.txt) (21.0 KB) Could you pls check?

---

<div class="post-metadata">

**Author:** ![raff](https://talk.openmrs.org/user_avatar/talk.openmrs.org/raff/32/11894_2.png) [@raff](https://talk.openmrs.org/u/raff)\
**Post date:** [October 20, 2022, 10:35am UTC](https://talk.openmrs.org/t/dockerizing-development-and-deployment-of-openmrs/36410/48 "2022-10-20T10:35:15Z")

</div>

@shobanadevi from the logs it seems as if you have started plain platform and it’s up and running. No unexpected issues. The two errors are bugs in webservices.rest / owa, but they do not affect the system. Did you start it up from [GitHub - openmrs/openmrs-distro-platform: This project is used to package the core OpenMRS war file with bundled modules](https://github.com/openmrs/openmrs-distro-platform) ? If yes, then you should be able to access it via [http://localhost:8080/openmrs](http://localhost:8080/openmrs). Otherwise please share steps to reproduce your issue and how you conclude it is not working.

---

<div class="post-metadata">

**Author:** ![ibacher](https://talk.openmrs.org/user_avatar/talk.openmrs.org/ibacher/32/19751_2.png) [@ibacher](https://talk.openmrs.org/u/ibacher)\
**Post date:** [October 20, 2022, 3:53pm UTC](https://talk.openmrs.org/t/dockerizing-development-and-deployment-of-openmrs/36410/49 "2022-10-20T15:53:23Z")

</div>

> [@raff](#):
>
> make sure not to hit any REST endpoints before fully started up due to an issue with the backend

Could you say something about that bug? I’ve actually been using, e.g., [http://localhost:8080/openmrs/ws/rest/v1/session](http://localhost:8080/openmrs/ws/rest/v1/session) to check whether the app is up or not…

---

<div class="post-metadata">

**Author:** ![dkayiwa](https://talk.openmrs.org/user_avatar/talk.openmrs.org/dkayiwa/32/179_2.png) [@dkayiwa](https://talk.openmrs.org/u/dkayiwa)\
**Post date:** [October 20, 2022, 8:26pm UTC](https://talk.openmrs.org/t/dockerizing-development-and-deployment-of-openmrs/36410/50 "2022-10-20T20:26:23Z")

</div>

> [@ibacher](#):
>
> Could you say something about that bug? I’ve actually been using, e.g., [http://localhost:8080/openmrs/ws/rest/v1/session](http://localhost:8080/openmrs/ws/rest/v1/session) to check whether the app is up or not…

Hiwigo: [[RA-1769] - OpenMRS Issues](https://issues.openmrs.org/browse/RA-1769)

---

<div class="post-metadata">

**Author:** ![shobanadevi](https://talk.openmrs.org/letter_avatar/shobanadevi/32/6_22734026db12803ebb3e059622ac3534.png) [@shobanadevi](https://talk.openmrs.org/u/shobanadevi)\
**Post date:** [October 21, 2022, 4:43pm UTC](https://talk.openmrs.org/t/dockerizing-development-and-deployment-of-openmrs/36410/51 "2022-10-21T16:43:44Z")

</div>

@raff Thank you. yes it is working now by accessing with url [http://localhost:8080/openmrs](http://localhost:8080/openmrs).

---

<div class="post-metadata">

**Author:** ![johnny94](https://talk.openmrs.org/letter_avatar/johnny94/32/6_22734026db12803ebb3e059622ac3534.png) [@johnny94](https://talk.openmrs.org/u/johnny94)\
**Post date:** [August 9, 2023, 11:28am UTC](https://talk.openmrs.org/t/dockerizing-development-and-deployment-of-openmrs/36410/52 "2023-08-09T11:28:38Z")

</div>

Hi @raff,

I saw you in the core team video at OpenMRS 23 implementers conference and you should be the right person for my question if are there some concrete next steps or a confluence page for the backend topic on “Horizontal Scaling”?

According to the O3 Roadmap it looks more in the planning state at Horizontal Scaling Bottlenecks with tags Seeking and Open: [Product Dashboard: OpenMRS Product Vision, Strategy, & Roadmap - Projects - OpenMRS Wiki](https://wiki.openmrs.org/pages/viewpage.action?pageId=235278551)

I mainly found those links for previous investigations: [Playing around with OpenMRS in the cloud - Development - OpenMRS Talk](https://talk.openmrs.org/t/playing-around-with-openmrs-in-the-cloud/19339/21)[Support for Clustering - Documentation - OpenMRS Wiki](https://wiki.openmrs.org/display/docs/Support+for+Clustering)[[TRUNK-314] Investigate about support for Servlet Container Clustering - OpenMRS Issues](https://issues.openmrs.org/browse/TRUNK-314)

But i am curious if there is maybe a more recent or up-to-date list with next steps or if it is rather currently on the plan to be developed sometime?

Many thanks, Johannes

---

<div class="post-metadata">

**Author:** ![raff](https://talk.openmrs.org/user_avatar/talk.openmrs.org/raff/32/11894_2.png) [@raff](https://talk.openmrs.org/u/raff)\
**Post date:** [August 9, 2023, 11:54am UTC](https://talk.openmrs.org/t/dockerizing-development-and-deployment-of-openmrs/36410/53 "2023-08-09T11:54:53Z")

</div>

Hi @johnny94,

It’s on the plan to be developed sometime. Are you personally interested in scaling OpenMRS? Is it affecting your implementation? Is it for performance or high-availability?

I could definitely provide directions on how to approach this, but so far there was not enough interest from implementations.

OpenMRS workloads are mostly DB intensive so if it is about performance then the first thing to do would be to increase DB instance or introduce DB clustering. I would assess this as a medium task.

On the other hand if we want to achieve high-availability then we would also need to be able to run at least 2 instances of OpenMRS behind a load-balancer. It requires changes in openmrs-core as we would need to move away from local data store for caching and search index to distributed cache and search index. I would assess this as a complex task.

---

<div class="post-metadata">

**Author:** ![johnny94](https://talk.openmrs.org/letter_avatar/johnny94/32/6_22734026db12803ebb3e059622ac3534.png) [@johnny94](https://talk.openmrs.org/u/johnny94)\
**Post date:** [August 10, 2023, 9:39am UTC](https://talk.openmrs.org/t/dockerizing-development-and-deployment-of-openmrs/36410/54 "2023-08-10T09:39:12Z")

</div>

Many thanks for your inputs already - especially with the hint to focus on increasing database for a performance quick win!

I am currently more personally interested, but we also use OpenMRS for project implementations in my company - but it is unsure how much time i can use for that from my work time. Currently it is not affecting an implementation but, asked already several times. Performance and high-availability are important, but therefore the application core must support that as well.

Everything outside openmrs is “basically clear” to me and need seperate dedicated time - but i am happy if you can provide me some directions on the internals of openmrs core before I can dig more into.

I already started some brainstorming with space for some comments or extensions from your side:

> **[OpenMRS Horizontal Scaling](https://docs.google.com/spreadsheets/d/1c6_n5TVibv98jAOAm2XRja0XiX3dzRUiBIyePMLTc0Y/edit?usp=sharing)**
>
> Tabellenblatt1
> 
> Application Requirements,johnny94 comments,raff comments
> Lucene index,replication needed
> clusterwide locks,independent RAFT synchronization preferred like Atomix with Java SDK or Quartz scheduler or schedlock over database?
> cluster...

Many thanks, Johannes

---

<div class="post-metadata">

**Author:** ![raff](https://talk.openmrs.org/user_avatar/talk.openmrs.org/raff/32/11894_2.png) [@raff](https://talk.openmrs.org/u/raff)\
**Post date:** [August 10, 2023, 10:42am UTC](https://talk.openmrs.org/t/dockerizing-development-and-deployment-of-openmrs/36410/55 "2023-08-10T10:42:01Z")

</div>

If we would like to run multiple instances of OpenMRS core we would need:

1. Load-balancer in front with sticky sessions e.g. nginx (if self hosting) or whatever cloud provider offers
2. Hibernate Search configured to use Elasticsearch instead of built-in Lucene.
3. Ehcache (used for Hibernate cache and Spring cache) configured for replication between nodes.
4. Migrate in-class caching used in openmrs-core and modules e.g. HashMaps to use Spring cache.
5. Use distributed storage for files stored by modules in the OpenMRS Application Data directory.

1-4 are to be done in openmrs-core and a reference docker setup provided with docker-compose.

5th depends on the deployment environment. Clusters like Kubernetes, ECS, etc. provide shared volumes. Even docker-compose can re-use the same volume for different containers.

It is a significant amount of adjustments and much more infrastructure to run so if it’s mostly for performance reasons I would really recommend starting from working on DB (optimising indexes & queries, increasing DB hardware, introducing DB replicas) then maybe moving to Elasticsearch for the concept and patient search to take off some load from the OpenMRS instance itself and only then look into the OpenMRS instance replication as outlined above.

---

<div class="post-metadata">

**Author:** ![johnny94](https://talk.openmrs.org/letter_avatar/johnny94/32/6_22734026db12803ebb3e059622ac3534.png) [@johnny94](https://talk.openmrs.org/u/johnny94)\
**Post date:** [August 10, 2023, 11:21am UTC](https://talk.openmrs.org/t/dockerizing-development-and-deployment-of-openmrs/36410/56 "2023-08-10T11:21:57Z")

</div>

Many thanks @raff for your direction!

This helps me already further.

Best regards, Johannes

---

<div class="post-metadata">

**Author:** ![ibacher](https://talk.openmrs.org/user_avatar/talk.openmrs.org/ibacher/32/19751_2.png) [@ibacher](https://talk.openmrs.org/u/ibacher)\
**Post date:** [August 10, 2023, 12:54pm UTC](https://talk.openmrs.org/t/dockerizing-development-and-deployment-of-openmrs/36410/57 "2023-08-10T12:54:41Z")

</div>

@raff Is there a strategy for sharing servlet sessions across multiple instances? Is this handled by ehcache? While we don’t make heavy use of session attributes, it’s required for things like the login and, with 2.6.0+, we’ll likely need to do something to share state for the CSRFGuard stuff (although, I think this can use servlet sessions, so might be solved by the above).

We’d also have to make some ecosystem adjustments as well, because we likely have modules outside of core that are storing data in-memory that would need to be shared between instances.

---

<div class="post-metadata">

**Author:** ![raff](https://talk.openmrs.org/user_avatar/talk.openmrs.org/raff/32/11894_2.png) [@raff](https://talk.openmrs.org/u/raff)\
**Post date:** [August 10, 2023, 1:03pm UTC](https://talk.openmrs.org/t/dockerizing-development-and-deployment-of-openmrs/36410/58 "2023-08-10T13:03:11Z")

</div>

@ibacher the easiest way to approach this is to use a load balancer with sticky sessions, which means that an established session will always go to the same instance.

---

<div class="post-metadata">

**Author:** ![grace](https://talk.openmrs.org/user_avatar/talk.openmrs.org/grace/32/16942_2.png) [@grace](https://talk.openmrs.org/u/grace)\
**Post date:** [January 11, 2024, 3:33pm UTC](https://talk.openmrs.org/t/dockerizing-development-and-deployment-of-openmrs/36410/59 "2024-01-11T15:33:08Z")

</div>

@frederic.deniger just curious: Is this load-balancing approach a need for ICRC?

[Previous page](https://talk.openmrs.org/t/dockerizing-development-and-deployment-of-openmrs/36410.md?page=2)
