Creating new images

This is the primary use case that I’m interested in: being able to package up different types of tools in a Docker image has allowed me to create and quickly share tools with others. I think the specific benefits are:

Example: creating a webpack tool

Obviously, if you’re an NPM user, it’s pretty easy to do npm install ... and get the tools you need. However, npm install -g (global install) is only really good for developer environments, but a local install may not be in $PATH. Also, if you’re running on a Mac, any extensions with native components will work locally but not in your container, and vice-versa - creating differences where you don’t want them.

The toolkit approach here is to create a container image that contains the tool, plus any dependencies needed. This can be used directly, and stowage gives you the ability to use this as a binary.

In this example, I’m going to package up webpack in an image so that I can use it standalone.

Building the tool

The Dockerfile for this example is very simple:

FROM node

RUN npm install -g webpack webpack-dev-server yarn

LABEL "org.stowage.spec"="{ \
    \"Name\": \"webpack\", \
    \"Command\": \"webpack\", \
    \"Mounts\": [ \
        { \
            \"Cwd\": true, \
            \"Guest\": \"/workspace\" \
        } \
    ] \

VOLUME /workspace

I’m basing this image on the official node image, and then installing webpack. /workspace is a directory that will be used to project the current working directory when I run it.

In the middle, I’ve put a specfile in the recipe using the org.stowage.spec custom label. Let’s talk about what this is doing quickly:

I’ve built this and published as a test image on Docker Hub, although I don’t necessarily recommend using it as-is!

Installing the tool

Ok, we have the container image created. I’ve pushed it to Docker Hub, although it doesn’t need to be pushed anywhere unless you plan to share it.

This can be installed with stowage the same way any other container would be:

$ stowage install ealexhudson/stowage-webpack
webpack installed
$ stowage list

We can see the first difference: if we had not included the stowage specfile in the container label, our binary would be called stowage-webpack. That could be ok, but I want it to be called webpack and have said so in the specfile - so that’s what we have.

I can now test this quickly and make sure it works in basic fashion:

$ webpack --version

Perfect! It’s installed and executable, other people on my team could install it exactly the same way, and we’re all then definitely using the same tooling - plus our CI. Not just that, I can push out new versions with additional capabilities or libraries, and it’s super-simple to keep everyone up-to-date.