Updates on branch that includes deployment packaging approach?

Development
,
1

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
2

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

3 Likes
3

Well done @mksrom :ok_hand:

4

@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

2 Likes
5

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
6

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:
package/target/openmrs-distro-package/
   ├── 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…)

cc @mseaton @burke

1 Like
7

@mksrom this sounds great! Would you be able to open a PR for this branch - that’ll make it much easier to see the changes you are introducing and also make inline/threaded comments about it. Thanks!

8

Well… not sure about that, as really I have wiped everything from the existing project. Were you looking at this branch? https://github.com/openmrs/openmrs-distro-referenceapplication/tree/3.x

As for inline comments, I have added READMEs at the root and sub-folder levels. Have you seen them? If yes, sure I’ll add some more notes.

9

@mksrom I looked this over and this is looking quite good. I did have a question regarding how you have the maven projects set up. When I set up our equivalent of this, I had initially looked to take a similar approach but ran into problems in adding subprojects as dependencies in parent projects, or in having sibling dependencies. Have you run into any issues with this?

10

Only the package/ project (artifact ID openmrs-distro-package) is using subprojects (Maven Modules). This is just a convenience here so that everything is in one place, to make discussion/decisions easier.

In reality it’s likely going to be separate projects (in particular the openmrs-config).

Let me try to provide them as <dependency> just to make sure that works.

11

@mseaton would you be able to give me more details on this?

12

@mksrom I don’t remember the details. But I was likely doing something wrong. I was probably trying to both have inheritance and dependencies set up in a way that was incompatible (eg. having 2 submodules each inherit from the parent pom, and then having the parent depend on the built submodules or something like that). The proof is in the results - as long as what you have put together works, then I’d go with that and assume I was doing something wrong. Regardless, as you say these may well be in other projects in which case the issue is moot.

1 Like