Docker, inital images & call for collaboration

For OpenLMIS v3 we’re evaluating docker - both for development as well as deployment of independent services. To this end, I’ve created initial images for a development environment, PostgreSQL, and wired these together in the OpenLMIS Service Template.

Development Environment
This is intended to be a re-usable, lean image to launch throw-away containers that a developer would use interactively providing common build tools (i.e. JDK, Gradle, etc). The image is code-agnostic and expects the Service under development to be host mounted in. While it can be used on it’s own, docker-compose files in the Services (see Service Template next) help in it’s use.

It’s on GitHub, and is auto-built on the Docker Hub under the namespace openlmis/

Postgres
This is a useful wrap of the official Postgres docker image, meant to codify the creation of the open_lmis database, excluding any schema/data.

It’s on GitHub and is auto-built on the Docker Hub.

Service Template
The Service Template now includes a few docker-compose files targeted at using the above images to standup a database-wired development environment, a CI-oriented automated build environment as well as a Dockerfile aimed at producing a lean service-oriented image that’s the end result of the build artifacts to deploy and run (i.e. a Spring Boot jar with Tomcat).

Where to start?
For now it’s easiest to start with the service template and it’s being brought into the example. For now it’s focused on single-service development to get us up and running.

What’s next
There are plenty of issues we have to address, but at this moment there are a few issues I’d like to highlight:

  • Docker-compose interactive mode in Windows seems to be faulty. For Windows developers this is problematic as we’d like to encourage re-use of the same dev/build environment.
  • Credential management (and config). Today the Service Template echos the past in that the connection to Postgres will need to be repeated in Gradle & Spring. And that tends to be done in property files. We’d not only like to reduce this duplication, but we need to externalize the definition so that Docker can inject it into each container that needs it. While there’s no official best-supported credential management in Docker, it looks like mounting the secrets and using environment variables into each container might be our best approach. Do we need more security (e.g. Vault)?
  • Right-sizing logging. SLF4J/log4j sure, logging volume? logging driver? 1 article
  • Streamlining publishing service images, through Gradle and/or docker using docker
  • Developing in multi-service is on the horizon, perhaps 1-2 months.

As we startup in Docker I’ve also put up a docker cheat sheet for ourselves and I’m working on publishing “code standards” for docker within the OpenLMIS style guide.

This work is based off of the learning from this informative spike as well as previous lessons (a)(b). Thanks all.

Collaboration & discussions are very much welcome.

Best,
Josh