It is clear to me and to everyone else that I have not completed the ambitious outline I proposed at the beginning of this series, and after close to a full year of neglect, I feel I owe it to readers to be honest about the fact that no more posts in this series are forthcoming.

Now that we’ve established a viable workflow for building and running our application in Docker containers, it’s time to take our first pass at running those containers on Kubernetes!

One of the quickest ways to rapidly prototype and confirm that your new Docker image is viable is to stand it up in a Docker-Compose environment. I often skip this step nowadays but it’s still a very useful validation step, and is more generally applicable in open source projects where we can’t fully assume Kubernetes as a target.

As described in the introductory post, this article will briefly outline the installation of Distillery 2 as well as including a deeper philosophical and technical explanation of how I structure multi-stage Docker images for Elixir/Phoenix applications.

I’m kicking off a new blog series that focuses on the intersection of Elixir and Kubernetes. This is becoming a more and more popular deployment target for companies and developers who don’t find a comfortable fit with other options that make different trade-offs.

An uncomfortably common problem when developing for a particular programming language is needing to deal with compatibility issues across different versions of the language runtime. Most often this means keeping individual projects tied to their then-current version of the language until such time that the project can address any compatibility issues with later language releases. To that end, Ruby developers are probably familiar with one of rbenv, chruby or rvm, for example. Elixir isn’t much different in this regard.

It’s possible to run Chris McCord’s sample Phoenix chat app in a Docker environment easily using docker-compose.