My Fellowship Journey: Bett Kipchumba

7

For the recent weeks, I’ve been looking into docker and containerization technology. As a concept it refers to the process of packaging up everything needed to run an application, including runtime dependencies, configuration files, and settings then running the application in a pre-prepared isolated environment.

Docker is a containerization technology that enables for the rapid and easy creation of containers. It runs on Windows, Linux, and MacOS. It is used in both development and production. The intention is harness this technology to better our backend development experience. For my case module development.

Docker support for OpenMRS module development

Note: This is still a work in progress. Feedback is highly appreciated

Pre-requisites

  • Docker - (No maven installation needed)

OpenMRS releases two variants of openmrs-core docker images: nightly and dev. I’m going to focus on the dev image, which is used for development. It contains dev dependencies such as maven and a configured OpenMRS SDK necessary for development purposes only.

Below is a docker-compose.yml template file;

version: "3.8"

services:
  db:
    image: mariadb:10.3
    command: "mysqld --character-set-server=utf8 --collation-server=utf8_general_ci"
    environment:
      MYSQL_DATABASE: ${OPENMRS_DB_NAME:-openmrs}
      MYSQL_USER: ${OPENMRS_DB_USER:-openmrs}
      MYSQL_PASSWORD: ${OPENMRS_DB_PASSWORD:-openmrs}
      MYSQL_ROOT_PASSWORD: ${OPENMRS_DB_ROOT_PASSWORD:-openmrs}
    deploy:
      replicas: '${OPENMRS_DB_REPLICAS:-1}'
      restart_policy:
        max_attempts: 3
    volumes:
      - db-data:/var/lib/mysql

  openmrs-core:
    image: openmrs-core:dev
    ports:
      - "8080:8080"
      - "8000:8000"
    restart: "no"
    environment:
      OMRS_CONFIG_MODULE_WEB_ADMIN: "true"
      OMRS_CONFIG_AUTO_UPDATE_DATABASE: "true"
      OMRS_CONFIG_CREATE_TABLES: "true"
      OMRS_CONFIG_CONNECTION_SERVER: ${OPENMRS_DB_SERVER:-db}
      OMRS_CONFIG_CONNECTION_DATABASE: ${OPENMRS_DB_NAME:-openmrs}
      OMRS_CONFIG_CONNECTION_USERNAME: ${OPENMRS_DB_USER:-openmrs}
      OMRS_CONFIG_CONNECTION_PASSWORD: ${OPENMRS_DB_PASSWORD:-openmrs}
      OMRS_REFRESH_MODULES: ${OMRS_REFRESH_MODULES:-false}
    healthcheck:
      test: [ "CMD", "curl", "-f", "http://localhost:8080/openmrs" ]
      timeout: 5s
    volumes:
      - ${PWD}:/openmrs/module/source
      # mount local m2 repository
      - ~/.m2:/root/.m2
volumes:
  db-data:

With changes from this PR(will be available in the next release of dev image), you only a compose file at the root of your module repository to start developing using docker. Moreover, extra configuration file is needed for a module that depend on other modules in order to run/start e.g queue module or emrapi module. That file would be module.properties(same as disto.properties used by SDK) - specifies the required modules to be download and looks like;

version=0.0.1-DEV
war.openmrs=2.6.0-SNAPSHOT
name=Queue module development
omod.webservices.rest=2.36.0

This leverages the OpenMRS-SDK to download modules specified in the properties. However, we need to modify OpenMRS-SDK to make name, version, war.openmrs optional or add a flag or something along those lines…

I would advise to mount local m2 repo for faster builds.

Any additional module to module.properties or force re-download modules needs a restart and first please set OMRS_REFRESH_MODULES to true

Build

Build module sources using the openmrs-dev docker image.

docker run --rm -w="/module" -v ~/.m2:/root/.m2 -v ${PWD}:/module openmrs/openmrs-core:dev mvn clean install -DskipTests

Module development

To start the OpenMRS development server, execute the command;

docker-compose up -d

Restart the container to deploy changes;

docker-compose restart

Under the hood docker-compose restart will build the current module, re-deploy and restart the OpenMRS development server

Access the container/server logs;

docker-compose logs -f --tail=1000

Connecting to an existing database

To use an existing database, first set the OPENMRS_DB_REPLICAS env variable to 0, then provide the following database connection properties in the .env file:

OPENMRS_DB_SERVER=host.docker.internal  // The database host
OPENMRS_DB_NAME=openmrs
OPENMRS_DB_USER=openmrs
OPENMRS_DB_PASSWORD=openmrs

Thoughts? Improvements?

@Platform_Team @dev5 @dev4 @dev3 @dev2 @dev1

Would you be interested to try out? Let me know :slightly_smiling_face:

9 Likes