Managing docker containers with makefiles

Image by Jason Scott, licensed under CC-BY-2.0.

I’m very old school when it comes to managing my personal infrastructure. When I came across Jessie Frazelle‘s blog on her personal infrastructure I was inspired to adopt a makefile based approach. There are a couple of others who’ve written about similar approaches.

Here is a generic version of my makefile for containers which are built and hosted on one of the container repositories

#
# comment
# https://hub.docker.com/r/project/name
#
NAME = containername
REPO = project/name:latest
#
ROOT_DIR:=$(shell dirname $(realpath $(lastword $(MAKEFILE_LIST))))

# Create the container
build:
        docker create \
                --name=$(NAME) \
                -p 8000:3000 \
                -e VARIABLE=true \
                -v $(ROOT_DIR)/config/:/path/in/container/ \
                --restart=unless-stopped \
                $(REPO) 

# Start the container
start:
        docker start $(NAME)

# Update the container
update:
        docker pull $(REPO)
        - docker rm $(NAME)-old
        docker rename $(NAME) $(NAME)-old
        make build
        docker stop $(NAME)-old
        make start

# comment

# https://hub.docker.com/r/project/name

NAME = containername

REPO = project/name:latest

ROOT_DIR:=$(shell dirname $(realpath $(lastword $(MAKEFILE_LIST))))

# Create the container

build:

docker create \

--name=$(NAME) \

-p 8000:3000 \

-e VARIABLE=true \

-v $(ROOT_DIR)/config/:/path/in/container/ \

--restart=unless-stopped \

$(REPO)

# Start the container

start:

docker start $(NAME)

# Update the container

update:

docker pull $(REPO)

- docker rm $(NAME)-old

docker rename $(NAME) $(NAME)-old

make build

docker stop $(NAME)-old

make start

There are 3 targets: build, start, update. The update leaves the old container with a -old name. This is useful if you have to roll back to a previous version if for some reason the new container breaks. You could even create a rollback target that did this automatically.

Now, this is great if there is an existing container repository that has a container for you to pull, but things need to change if you are starting with a Dockerfile and building your own container.

#
# comment
# https://github.com/project/name
#
NAME = containername
#
ROOT_DIR:=$(shell dirname $(realpath $(lastword $(MAKEFILE_LIST))))

# Create the container
build:
        git pull
        docker build . --tag $(NAME)
        docker create \
                --name=$(NAME) \
                --restart=unless-stopped \
                $(NAME)

# Start the container
start:
        docker start $(NAME)

# Update the container
update:
        - docker rm $(NAME)-old
        docker rename $(NAME) $(NAME)-old
        make build
        docker stop $(NAME)-old
        make start

# comment

# https://github.com/project/name

NAME = containername

ROOT_DIR:=$(shell dirname $(realpath $(lastword $(MAKEFILE_LIST))))

# Create the container

build:

git pull

docker build . --tag $(NAME)

docker create \

--name=$(NAME) \

--restart=unless-stopped \

$(NAME)

# Start the container

start:

docker start $(NAME)

# Update the container

update:

- docker rm $(NAME)-old

docker rename $(NAME) $(NAME)-old

make build

docker stop $(NAME)-old

make start

Again, I’ve used the same build, start, update commands and have a built in assumption that the Makefile lives in the root of the git project. Instead of pulling from a container registry, we pull the latest from the git project and do a local build.

Having a very similar structure helps with consistency of managing my docker containers.

One day I would like to further enhance these makefiles to support checking for updates, be that a newer container build or git changes. Adding a post update check to ensure that the container has started would be very good too.

Leave a Reply