Ubuntu

Many application containers need familiar Linux libraries, certificate stores and package tooling around their executable. An Ubuntu base image supplies that userspace environment, allowing teams to build an application image from a known distribution release. The container still shares the worker machine’s kernel, so its updates and node updates solve different problems. Choose a supported release and rebuild when relevant packages change; pinning an image digest makes the input reproducible but does not automatically bring in future fixes.

Current guidance

Canonical publishes separate standard, expanded and legacy maintenance periods for each release. Choose an explicit supported release and understand whether the required packages are covered under the applicable maintenance arrangement; an old LTS label is not an unlimited support promise.

A container contains userspace packages while sharing the host kernel, so updating its base image does not update the node kernel. Conversely, patching nodes does not refresh libraries copied into application images. Track both layers and rebuild application images when relevant base packages change, retaining the digest and provenance of the image actually deployed.

For a base-release migration, test native libraries, TLS trust, locale, timezone and non-root filesystem permissions alongside the application. Remove unnecessary build tools from the runtime stage where practical, but keep a useful dependency inventory rather than relying on size alone. Pinning a digest makes a build reproducible; a planned refresh process is still needed to obtain security fixes. The historical image-size comparison should not be treated as a current measurement.