I have a lot of data points from talking to and observing how Cloud 66 customers use Docker in production. And I've managed to glean some pretty interesting observations, especially around how they tackle getting their code into containers.
Taking an inside-out approach to building with Docker, I plan to give workshop attendees a framework for how to get your code into containers, streamline the Docker build flow and avoid common pitfalls when moving from dev to live environments. And our starting point will be how to create the RIGHT minimal lovable image — a concept I've talked quite a lot about in previous posts.
Getting Your Workflows Right
Running Docker commands is one thing, but maintaining containers in production is a whole other ballgame. So you can expect us to cover production workflows in-depth, to help you navigate the wild world of a live Docker environment. With the added benefit of talking to and observing how over 900 of our customers have been using Docker in production, I’ll be presenting some of these data points and sharing our observations on how we've been helping them get it right.
And one other thing we'll do as we tackle these workflow requirements, is to use a couple of microservices case examples to build these in the language of your choice. This will give us a good grounding to go beyond the basics and help you walk away with the beginnings of your very first Docker project, armed with the tips and tactics you need as key takeaways.
Habitus, a Build Flow Tool for Docker
To achieve the smallest possible image to start small and get smart, we're also going to be using Habitus. Habitus is an open source build flow tool for Docker. Sometimes you need more stages to achieve the RIGHT image, like removing secrets and getting compile-time dependencies in and out to leave you with the smallest possible image - one that's secure and reliable.
Why are tools like Habitus important? For example, if you've got a Golang based API, you'll 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 won't be completely inaccessible until you squash your image with the use of tools like Habitus.
We'll experiment with this during the workshop, but to give you a sense of how this works in theory, we basically will 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 the second 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're using Habitus, which requires a build.yml to create a proper build flow. In a two-stage process, we'll build the binary and copy the artifact 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
More on the ins-and-outs of Habitus when I host the workshop during Jax London. I look forward to sharing insights and getting hands-on to get you started creating the RIGHT minimal lovable image for your microservices architecture to run it in production.