Docker Images and OS security updates

Question

Let's consider I'm using the Node.js 10.8.0 node:10.8.0-jessie Docker image as a base image for my application Dockerfile. The application is running stable in production and is not updated for a while (several months).

The Node.js 10.8.0 image is based on the buildpack-deps:jessie image, which itself is based on buildpack-deps:jessie-scm image. This is based on the buildpack-deps:jessie-curl image, whose base image is debian:jessie.

System / security updates for Debian Jessie are released regularly. In a classic hosted environment I would update my Host using sudo apt-get update && sudo apt-get upgrade and I'm fine.

But how do I ensure my running Node.js application in the container gets the latest Debian Jessie updates and patches while staying on Node.js node:10.8.0-jessie?

Running sudo apt-get update && sudo apt-get upgrade for my application Dockerfile in my CI and regularly creating a new Image for my application and re-deploying the container doesn't them the correct way.

As it all starts with the debian:jessie image, I would expect this to be updated regularly and all depending images as well.

Then I would rebuild my application image by pulling the Node.js 10.8.0 images again (--no-cache) and re-deploy it.

My questions are: is this assumption correct? Is there any official Docker documentation about that workflow which seems essential to me? How do I get notified about debian:jessie and eventually node:10.8.0-jessie image patch releases?

Answer 1

The preferred workflow is to pull an updated base image, or rebuild your base image if it's locally built. Then rebuild your child images. The only commands you run should be install, not upgrade, if at all possible. For fixing to a specific version of an app, add that version dependency in your install command.

This is preferred over upgrading packages in an existing image for several reasons:

• upgrading images still leaves the old versions of the packages in the image layers, causing your images to grow unnecessarily in size.
• upgrading would require a new Dockerfile for each new release, with the parent image set to the previous version, causing a maintenance challenge.
• reproducing an image created through an upgrade process would require first installing lots of old versions and building up the layers again.
• adding layers for each upgrade reduces performance with the union filesystem. Some of the storage drivers also have limits on how many layers you can create, which would eventually fail after enough iterations of an upgrade cycle.
• upgrades introduce the risk of state drift. If one image in your chain of upgrades included a change that got lost in the chain of Dockerfiles, or the state from a previous install changes how a fresh install runs, you get an unreproducible environment that may break for unknown reasons.

The only scenario where I might perform an upgrade is if an upstream base image is not being maintained. Preferably I'd find a different base image, or build it locally. But when neither of those is possible, I may build a local base image that is a child of the unmaintained external base image, with the first step of upgrading packages. In Dockerfiles, this would look like:

FROM scratch as remote-unmaintained
ADD unmaintained.tgz /

FROM remote-unmaintained as local-base
RUN upgrade-cmd

FROM local-base as app
COPY app /
CMD /app