Kubernetes Native Phoenix Apps: Part 3
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!
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.
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.