Docker: Owning the Stack
The paradigm shift of “Stack as a Dependency”
This is the third post of a 3-part series on docker. This series was transformed from a talk I gave at an STL DevOps meetup.
Here we are going to dive into the implications of developers taking ownership of their stacks through docker, and the work I have been doing at NodeSource to help developers take ownership of their Node.js stacks. If you haven’t already, take a few minutes to skim through the previous article in this series which lays the groundwork for this topic.
In my previous article, we introduced the concept of developers owning the stack. Now let’s follow that rabbit hole down into the work I’ve been doing at NodeSource. When developers take ownership of their stack, they are no longer simply running Node 0.10.34, they are deploying all of the packages bundled in the image with that version of Node.
We are still in the exploratory phase of using docker at NodeSource, so when I was looking at pinning deployments to a specific version of Node it became apparent that there was something lacking in the official repositories: only the most recent versions of Node have Dockerfiles.
When the docker registry builds official images, it doesn’t displace legacy tags when they disappear from the image’s definition files. This results in that tag staying in the registry allowing users to pin to specific versions of an official image, but this prevents legacy versions from being rebuilt.
Node 0.12.0 is no longer officially maintained, which means its stack is stale. It no longer receives the updates pushed to buildpacks-deps:jessie, nor are any of the packages installed to support Node.js properly maintained. Essentially the entire stack in the legacy Node.js containers are going stale.
So how bad is this? Let’s try to run updates on the most recent release of Node.js 0.12 and compare that to its original release.
You can see that the stack for a legacy version of Node has already gone incredibly stale. There are updates for 84 of the 405 packages installed in the Node.js 0.12.0 image compared to only 9 for the 0.12.2 release. This is where the work I’m doing at NodeSource comes into play. To safely allow version pinning when deploying Node.js applications in Docker, you have to properly maintain the Dockerfiles used to build each version you would like to pin against.
This all results in the ability to build 104 Dockerfiles supporting 4 Linux distributions and their individual releases for each version of iojs and Node.js supported by the official NodeSource PPAs. These are then setup on the docker registry as automated builds that rebuild themselves when the underlying Linux distribution image updates.
All of this work results in a stack that remains up-to-date while allowing you to ship your code on specific versions of the Node.js and iojs projects.