Skip to content

Instantly share code, notes, and snippets.

Created Oct 14, 2016
What would you like to do?
Deploying releases within containers
This is not meant to be comprehensive, a guide, or anything quite that sophisticated, just a couple
notes on what I do at work, in production, and how my environment is set up.
- Infrastructure runs on AWS
- We run an internal PaaS based on OpenShift Origin/Kubernetes
- We push code to GitHub, which triggers a webhook, which in turn
triggers OpenShift to start a build, which fetches the source
code, and runs the build using the Dockerfile contained in the
root of the project.
- When a build completes, it pushes the image to an imagestream,
which is an OpenShift primitive representing a stream of changes
to a given image name. It's basically just named/tagged Docker images.
- However, the imagestream gives us some nice capabilities, by default
images get tagged with 'latest', but we also have tags for 'staging' and
'prod' which allow us to tag a given image from the 'latest' stream, and
have it automatically promote to the tagged environment. We use this to
tag images into staging, and into production.
- We're not doing hot upgrades, we use rolling releases.
- Configuration is done primarily via environment variables set via Kubernetes
- Our Elixir/Erlang releases are built using my bitwalker/alpine-erlang base image
from Docker Hub.
- Our project Dockerfiles look something like this:
- In short, we install Elixir, fetch deps, compile, build the release, copy it to a target directory,
set permissions, then strip out the source code and the build-time deps (i.e. Elixir) and we are left
with an image which only contains the release.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment