Updates on branch that includes deployment packaging approach?

Tags: #<Tag:0x00007f1f7f688b48> #<Tag:0x00007f1f7f6887d8>

Hi @mksrom & @mksd,

In today’s TAC meeting we were curious to stay up to date with what’s been happening with Romain’s 3.x branch - this is in reference to our TAC call ~3 weeks ago where we talked about Mekom’s deployment strategy and agreed that the RefApp should become this more easily deployable thing, that includes the approach you’ve been applying. The vision was that there would be a.3.x branch that applies this convention in the next RefApp release sometime around Q1 next year.

The action item we recorded at that time together was: Romain: Make 3.x branch for RefApp distro, that includes Mekom’s approach to deployment? Login page & dashboard.

I know it’s only been a few weeks, and this isn’t meant to apply unfair pressure. So in the interests of keeping in touch - are there any updates, or is there a place containing this branch work that people could look at?

Thanks so much! That was a great conversation a few weeks ago so we’d like to keep it moving. :slight_smile:

CC @burke @mseaton @jdick @ssmusoke @dkayiwa @ibacher @mogoodrich

1 Like

Hi Grace!

Yes I’ve created a 3.x branch of the openmrs-distro-referenceapplication project and made a fork to start looking into this.

Here are the 2 tasks I’ve identified:

  • include Micro Frontends
  • include Initializer + Config

I have only made progress on point 1 for the moment.

Good news is I am using the new tooling (provided in ESM Core) to package the MF, so not using Packmap anymore.

But there are few things still to do on this point 1:

  • bundle the MF as part of the WAR (unsure if that’ll be a priority actually)
  • update the Dockerfile/docker-compose.yml files provided by the OpenMRS SDK
  • support serving the MF via Nginx (now still served via tomcat/module SPA)

I’ll keep posting updates (though I am on leave this week :slight_smile: )


Well done @mksrom :ok_hand:

@mksrom Thank you for the progress update

A question on nginx - while it may be easy to configure with Docker, will it be the only way to serve the MF? Why not use the embedded Tomcat which reduces having an additional software component to setup and configure? That way nginx would be a performance enhancement (probably infront of Tomcat like the old Apache way for static assets)?

In the mean time enjoy your workaction


Yeah, there would be 2 ways to run the MFs.

  • One is using the openmrs-module-spa (so, through Tomcat). And this is already implemented now in my fork
  • The other is via a Nginx server
1 Like

So, after some clarifications the other day, here is a proposed way of (1) packaging the distributions and (2) running the app.

This is pushed to the 3.x branch.

The READMEs should be enough to try it out.

In terms of architecture, I’ve kept a clear division between the packaging and the running of the app.

  1. The package Maven project will output a distribution containing all needed artifacts to later run the app:
   ├── openmrs_core/
   ├── openmrs_modules/
   ├── openmrs_config/
   ├── microfrontends/
   └── microfrontends_config/

This is packaged as a ZIP file found inside package/target/openmrs-distro-package/

  1. The run project will run the said distribution via a Docker Compose project. It assumes that the distro has been unpacked in the run/docker/distro/ folder (which is done when mvn clean package at the top level anyway).

App is then accessible at http://localhost/mf

We could then later on have as many types of “run” we want (tomcat only, k8s…)