Docker container for dashboard

[r0bby (Robert O'Connor)]

@elliott, @plypy: I have been working quietly on making a Docker container which encapsulates all dependencies for dashboard and allows developers to get started quickly. Couple questions: 1) Do you think that this is a good idea, or should I halt work and 2) where should this go…currently was thinking in my personal github and then move it to the OpenMRS when it’s well-tested.

I am using docker-compose and I figure that we will also deploy this container. Simple and automated is better.

I do not want to make any decisions without consulting the rest of the team

Can I get some 's Once this happens, I’ll request the repo

[michael (Michael Downey)]

I am not a Docker expert but I know with Discourse the data is not inside the Docker container. This makes upgrade of the application code much easier. (Build the new container pointing at the “outside” DB, then swap it out for near-zero downtime.) Would that work here?

[r0bby (Robert O'Connor)]

The way it works is that there are three images:

• Dashboard
• Mongo
• OpenLDAP

The link is that dashboard is linked to OpenLDAP and Mongo. images. This is where docker-compose becomes powerful and super useful The Dashboard image has no database whatsoever. It literally just has node and nothing else.

@burke you have an opinion?

I’ll fully document it when I get it working…I think this architecture works. There is (near) zero-downtime deploys possible (i think)…

[cintiadr (Cintia Del Rio)]

I’ve found this link particularly helpful when handling docker with database data.

Why Docker Data Containers are Good

[r0bby (Robert O'Connor)]

Wow, thank you @cintiadr!!!

[r0bby (Robert O'Connor)]

I got it done – everything except LDAP now resides in Docker. The last remaining bit will be done soonish. For development, it resides in vagrant – in production – it resides on the server itself.

@michael

I am not a Docker expert but I know with Discourse the data is not inside the Docker container. This makes upgrade of the application code much easier. (Build the new container pointing at the “outside” DB, then swap it out for near-zero downtime.) Would that work here?

I did do it this way. This is gonna make deployments much easier.

For educational purposes:

---

Currently I have the following docker-compose file:

version: "2"
services:
  mongodb:
    image: frodenas/mongodb:2.6
    ports:
      - "0.0.0.0:27018:27017"
    environment:
      MONGODB_USERNAME: "openmrsid"
      MONGODB_PASSWORD: "secret"
      MONGODB_DBNAME: "openmrsid"
    volumes:
      - /docker/mongo:/data
    command: "--nojournal --smallfiles"
    restart: unless-stopped
  mailcatcher:
    image: robbyoconnor/mailcatcher
    ports:
      - "0.0.0.0:1080:1080"
      - "0.0.0.0:1025:1025"
    restart: unless-stopped
  web:
    build:
      context: .
    depends_on:
      - mongodb
      - mailcatcher
    environment:
      RECAPTCHA_PUBLIC: "6LdE8xsTAAAAANv1Z-9a443m4HNlVhb7IjYy3dVW"
      RECAPTCHA_PRIVATE: "6LdE8xsTAAAAAOj6zkHqOgxTAs-55jTLVdBuvbiz"
      LDAP_URI: "ldap://192.168.33.10:389"
      MAIL_HOST: "mailcatcher"
      MAIL_PORT: "1025"
    ports:
      - "0.0.0.0:3000:3000"
    restart: unless-stopped

---

And the Dockerfile for the web app:

FROM node:5


# workaround for this: https://github.com/npm/npm/issues/9863
RUN  useradd --user-group --create-home --shell /bin/false node
RUN rm -rf /usr/local/lib/node_modules/npm \
 && git clone https://github.com/DIREKTSPEED-LTD/npm /usr/local/lib/node_modules/npm \
 && rm -rf /usr/local/lib/node_modules/npm/.git \
 && rm -f  /usr/bin/npm \
 && ln -s -f /usr/local/bin/npm /usr/bin/npm \
 && cd /usr/local/lib/node_modules/npm \
 && npm install -g gulp bower

ENV HOME=/home/node

WORKDIR $HOME/app

COPY package.json bower.json gulpfile.js $HOME/app/
RUN chown -R node:node $HOME/*


USER root
RUN wget https://github.com/jwilder/dockerize/releases/download/v0.2.0/dockerize-linux-amd64-v0.2.0.tar.gz \
&& tar -C /usr/local/bin -xzvf dockerize-linux-amd64-v0.2.0.tar.gz

COPY . $HOME/app
RUN chown -R node:node $HOME/*
USER node

COPY app/conf.docker.js app/conf.js
RUN npm install && \
    bower install && \
    gulp

EXPOSE 3000

CMD dockerize -wait tcp://mongodb:27017 npm start

I am not overly concerned with the recaptcha keys being exposed – we do not use these keys in production – They’re meant to be used in development only. dockerize ensures that mongo is accessible before starting express – otherwise things don’t work right. I have a separate docker compose for production – which isn’t finalized yet.