You can manage updates and patches in various ways. This applies to base OS images,
dependency images such as those containing binaries and libraries, and the
application images themselves.
In the first approach, when an update or patch is available, a new base OS image or
container image is created with the update/patch applied and uploaded to the
repository. The Dockerfile is updated to use the new version number (if a version
number is used as opposed to specifying to use the latest), and the container instances
are rebuilt, which will pull the updated images. You must rebuild any containers that
need to use an updated version of an image/base OS image, as every image stores
Metadata about the layers on which it depends with a strong identifier in the form of a
file hash. It is possible to configure autobuild for images by also uploading the
corresponding Dockerfile that created the image, and then, when a dependent layer is
updated, the image will automatically be rebuilt.
The second approach is just to apply the updates to the container instance, which will
create a new layer containing the updates. Remember that any writes to a container
are applied to the top layer, as all other container/base OS images it depends on are
read-only. Therefore, any updates/patches to dependency images will have the
filesystem/registry updates written to a new layer above the application. The updates
will then be unioned with the underlying layers (with the highest layer taking
precedence if a conflict occurs because updates are applied but the original version of
the file/registry is still present in the lower-level base/container image). This is shown
in Figure 10.7. Where possible, the first approach is preferred.
Figure 10.7 Two options for updating images