Microservices are often called the lego-esque building blocks for creating container-based applications. It provides a handy solution to breaking down monolithic apps, but what do I need to know if I want to deploy a microservice architecture? What sort of things do I need to consider before I containerize my application? And why are these things important?

Get it right or get screwed

Docker is a great way to mix and match technologies to give you the flexibility to write microservices in any kind of language or dependencies. The path to succeeding with microservices in production starts with getting your image right, as your Docker image is the foundation of your service.

I intend to spend quite a bit of time talking about how to get your image right and let you guys playing around with this concept using real-life examples and why testing plays an important role in the deployment process and the additional considerations that play a role in moving your containers into production.

Why sh* t in, just means more sh*t out

We have a lot of data points from talking to and observing how our customers use Docker in production with Cloud 66. And we’ve managed to glean some pretty interesting observations, especially around how they tackle getting their code into containers. During this workshop we will discuss common mistakes, experience those mistakes and how to solve them to create the RIGHT minimal lovable image.

We will experience and talk about the fact that Docker will NOT, and I repeat, will NOT solve your bad coding behaviours. While Docker allows us to define the environment our service process runs in, you still need to team it with good DevOps practices like testing, automation, security and version control. Otherwise you’re still producing sh*t and putting all your energies into polishing a turd.

Workflows that work

When your team’s starting a greenfield microservice architecture project using Docker as the proverbial ‘polyglot glue’, you’re going to need to determine a workflow that works. Not only that, you’ll need to figure out how to get your containers from dev to live. During the workshop we will play with that concept and learn new ways to create a proper Docker workflow.

Some of the things you’ll need to be looking at include what your local environment looks like? You’ll need a plan around how to test your service, whether Docker will work with CI and if it’s possible to automate the deployment of services in production using a Container-as-a-Service platform?

To tackle some of these workflow considerations, I’m putting together a couple microservice examples; in the language of your choice. This will give us a good grounding during the workshop to go into the issues mentioned above, discuss the pitfalls and give you tips for how you can deal with these effectively.

Habitus, A Build Flow Tool for Docker

To achieve the smallest possible image and start small and get smart we also going to use Habitus (habitus.io). Habitus is a build flow tool for Docker. Sometimes you need more stages to achieve the RIGHT image. Like removing the secrets, getting compile time decencies in and out and leave you with the smallest possible image with a huge boost is size, security and reliability.

For example. If you have a Golang based API you need to build the binary and ship the binary. But you don’t want to leave your source code inside a container. You can remove the source code but it’s not gone if you don’t squash your image. We will experiment with that during the workshop.

We basically need two Dockerfiles, one for compiling:

#use the golang base image
FROM golang:1.6
MAINTAINER Daniel van Gils

#agt all the go testing stuff
RUN go get github.com/gin-gonic/gin

#switch to our app directory
RUN mkdir -p /app
WORKDIR /app

#copy the source files
ADD . /app

ENV GIN_MODE=release
ENV CGO_ENABLED=0
ENV GOOS=Linux

RUN go build -a -installsuffix cgo -o server
ENV GIN_MODE=release
CMD /app/server

and one for production:

#use the alpine base image
FROM alpine:3.3
MAINTAINER Daniel van Gils
RUN mkdir -p /app
WORKDIR /app

#copy the binary
ADD ./server /app
RUN chown daemon:daemon /app/server && chmod 700 /app/server

ENV GIN_MODE=release
USER daemon
CMD /app/server

We are using Habitus which requires a build.yml to get a proper build flow. In two stages we building the binary and copy the artefact inside the smallest possible image.

build:
    version: 2016-03-14
    steps:
      builder:
        name: builder
        dockerfile: Dockerfile
        artifacts:
          - /app/server
      runtime:
        name: api_runtime_habitus
        dockerfile: Dockerfile.production
        depends_on:
          - builder

During Jax London I attempt to give you all the insights, hands-on you need to get started creating the RIGHT minimal lovable image for your microservice architecture and run it in production.

See you then!

Don’t forget to check out Cloud 66: