DockerCon SF 2015: Maintaining the official node.js docker image
Maintaining the Official Node.js
Manager, Solutions Engineering
Joyent Inc., @chorrell
• Container company (since ~2006)
• Joyent Public Cloud
• Private Cloud Software, Smart Data
• Part of Smart Data Centre and available in
Joyent Public Cloud
• Run Docker images natively on SmartOS Zones
• Turns an entire data center into a Docker host
• Or run non-Docker Linux containers at bare-
• The "image team"
• Core members are myself and Derek
• Build images for Joyent Public Cloud, Smart
Data Center, and SmartOS
- SmartOS, KVM Linux (Debian, CentOS)
FreeBSD and Windows Images
- Linux (Triton!) Container images
• And maintain the official Docker Node.js Image!
Docker Node.js Image
• The registry: https://registry.hub.docker.com/
• GitHub: https://github.com/joyent/docker-node
• Kind of popular!
The Hand Off!
• Took over an existing official image, which had some
- Had some great scripts for updating the image
- Everything was pretty well established
• Great resources:
- IRC channel #docker-library on Freenode
• Some prior history we had to get familiar with:
- Choice of base image (buildpack-deps:jessie) balances
general usefulness vs. image size (more on that later)
- Different tags/variants (more on those later)
Image Update Workflow
• Update image Dockerfiles → Generate
new library file → make pull request
to official Library
• The workflow was a bit new for us,
but we settled in nicely
• Looking to automate image updates
and testing. Some interesting options
• Did not want to introduce too much change
to the images
• Derek updated the update.sh and generate-
stackbrew-library.sh scripts (now Mac-
• Added simple build test to ensure all the
images build. Test 0
• Looking at using Serverspec for testing and
automating things (more on that later)
Are you starting from scratch?
• Great resources: Docs, irc channel, other official images
• We had the benefit of taking over an established image
which follows Docker best practices
• You need to consider things like:
- What base image to use? Use an official base image
(Debian, Ubuntu, CentOS etc), one that makes sense for
the overall image.
- Dockerfile best practices
• What Tags and Variants will you have?
• Include Tests! At very least, does it build?
Tags are Great!
• Offer different versions:
docker pull node:0.10.38
docker pull node:0.12.4
docker pull node:latest # -> 0.12.4
Variants: Also Great!
• docker pull node:0.12.4-slim
# A "leaner" version of node:0.12.4
docker pull node:0.12.4-wheezy
# Alternative if prefer Debian Wheezy over Jessie
• Document your tags and variants
• Usage might not be obvious to anyone browsing registry
(or GitHub repo)
• Good examples:
• Keep the image reasonably small: A balance between size and
• node:latest etc. is built from buildpack-deps:jessie
- Big, lots of packages installed, makes building things like
npm modules easy. That's super convenient
• node:slim variant (FROM debian:jessie) is a nice option to
build on if you know what you want installed and prefer to
keep things lean
• Alpine Linux is SUPER small (~5MB!), might probably not be
suitable for your app or use case, but worth looking at.
• Monitor GitHub issues for user feedback
-- this works pretty well
• GitHub issues are great way for
responding to or integrating user
• Consider creating an F.A.Q for recurring
GitHub issues about design decisions
(like choice of base image, etc.)
• At the very least: Does it build?
• Test Driven Development applied to Dockerfiles/
• Continuous Integration with Jenkins?
• Great testing option, based on Rspec
• Been using it to test our SmartOS/KVM images (e.g.,
• Has Docker support!
- Create a test suite that builds your image (test 0)
provisions a container, runs test against a container
• Great option to validate your images before publishing
• Speaking of the Docker Node image...
Interesting Plot Twist!
• Node.js and io.js will be merging!
What will happen to the Node.js image?
• Will eventually move under the Node.js foundation (https://
• Will be maintained by the Node.js Docker Working Group (I'm a
• The Official io.js and Node.js images will probably track
separately until the big merged release
• Working Group is maintaining the Official io.js image, doing a
great job, and the Node.js and io.js images are pretty similar
(tags, variants, etc.)
• It should be a pretty smooth transition (docker pull
node:latest and docker pull node:0.10.38 will still work :)
• Longer term? Still offer older Node.js releases but a lot of
things the Working group will need to figure out.