Some might view this question as an opinion based one, but please consider that I am just asking for information sources.

I am working on a Docker based project, using a Node Alpine image. Right now I'm using the node:16.13-alpine image.

When I start updating images to the latest version, I'm always at a loss as to which version to pick.

In my example, the node image page https://hub.docker.com/_/node?tab=description&page=1&name=alpine lists the following available images versions:

18-alpine3.15, 18.10-alpine3.15, 18.10.0-alpine3.15, alpine3.15, current-alpine3.15
18-alpine, 18-alpine3.16, 18.10-alpine, 18.10-alpine3.16, 18.10.0-alpine, 18.10.0-alpine3.16, alpine, alpine3.16, current-alpine, current-alpine3.16
16-alpine3.15, 16.17-alpine3.15, 16.17.1-alpine3.15, gallium-alpine3.15, lts-alpine3.15
16-alpine, 16-alpine3.16, 16.17-alpine, 16.17-alpine3.16, 16.17.1-alpine, 16.17.1-alpine3.16, gallium-alpine, gallium-alpine3.16, lts-alpine, lts-alpine3.16
14-alpine3.15, 14.20-alpine3.15, 14.20.1-alpine3.15, fermium-alpine3.15
14-alpine, 14-alpine3.16, 14.20-alpine, 14.20-alpine3.16, 14.20.1-alpine, 14.20.1-alpine3.16, fermium-alpine, fermium-alpine3.16

This list is of course an ever moving target.

Now, when picking a version out of all of these, what element can I take into consideration (short of reading every single release note for each image)?

Is there a page somewhere offering a high level view of these images, of known issues? Are some of these images designed to be "safe bets", unlikely to introduce freshly introduced bugs? I run an npm audit on packages used inside my image from time to time, but is there some equivalent tool which might alert it is time to update the node image itself, because a new bug / security breach has been found?

I know this is a pretty wide question, but I am sure there are some good practice guidelines to follow here, any pointer is appreciated.

Thanks!

CodePudding user response：

The two most important things to do here are

1. Have good integration tests; and
2. Check your Dockerfile into source control.

If you have both of these things then trying out any of the images you list isn't a huge risk. Update the Dockerfile FROM line, build an image, and run it; if the integration tests pass, check in the change; and if not, revert it. If you can set up your continuous-integration system to run the tests for you then this becomes "open a pull request and wait for a passing build".

The other trade-off is how much you want an image you know works, versus an image that gets regular updates. Most Docker images are built on some underlying Linux distribution. The node:16.13-alpine image you have currently isn't in the list of images you show, which means that, if there is some vulnerability in the underlying Alpine base, that particular image isn't getting rebuilt. But, conversely, your build might automatically update from Node 16.13.0 to 16.13.2 without you being aware of it.

It also helps to understand your language's update and versioning strategy. Node, for example, puts out an major release roughly annually with even major version numbers (14, 16, 18, ...), but Python's annual releases have minor version numbers (3.8, 3.9, 3.10, ...).

I'd suggest:

• If you can tolerate not knowing the exact version, then use a release-version image like node:16-alpine or python:3.10. Make sure to docker build --pull to get the updates in the base image.
• If you've pinned to an exact version like node:16.13.0-alpine, updating to the most recent patch release node:16.13.2-alpine is most likely safe.
• If your base image uses semantic versioning, then upgrading minor releases node:16.17-alpine is supposed to be safe.
• It is worth reading the release notes for major-version upgrades.