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.

I’ve recently assembled a workflow for blogging with Hugo, org-mode, and Netlify via a single .org document, with live reload during writing and git push driven deployments.

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.

I’ve begun using GitLab to host some of my personal projects on my own domain, sometimes as a mirror of a GitHub repository and sometimes as the primary home of the project.

Today I received the final component to complete my first homelab-specific PC build.

Like many, I use docker-machine (installed via Docker Toolbox) to develop Docker images on OSX. I am terrible about remembering to launch the docker-machine VM ahead of time, and I don’t like having STDERR output or delays from launching new shell tabs, so I wrote a quick lazy-load function inspired by Spacemacs.

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

This article has been cross-posted here from my employer’s technical blog.

We are investing a lot of research and development time into leveraging Docker in the next generation of our internal infrastructure. One of the next components we need to build out to full maturity is being able to dynamically route web traffic from our Nginx load balancers to internal Docker containers in a performant way.

We are very passionate fans of the work of HashiCorp at Belly, and they recently published a new project named Consul-Template. We were using an earlier HashiCorp tool named consul-haproxy to reconfigure our Nginx load-balancers based on Consul data. Consul-Template is a slightly more generalized tool that was fairly smooth to adopt.

Let me walk you through a proof of concept I whipped up last week. Starting from an OSX computer with Homebrew and VirtualBox installed, we will be able to spin up a Docker-based environment that will load-balance HTTP traffic via Nginx to an arbitrary number of backend processes, all running in separate Docker containers.