Base Images

Docker images consist of layers. To save internal HCC2 storage it is advised to use common base images where possible to allow common layers to be shared. There are other considerations for using the recommended images too, such as the C compiler (libc implementation) they use. Alpine base images are not recommended unless the developer is certain their binary is compatible with the musl libc implementation. Google’s distroless images are ideal and lightweight Debian 10/11/12 such as buster-slim are acceptable.

Sensia has provided a registry of verified images for use with specific HCC2 releases, below. Images which have 'build' in their name without including 'prod' are intended only for build purposes in the build stage of a Docker image. They include a number of build tools which expose additional unmitigated security vulnerabilities. They should never be used as the base layer for application images in a production device.

c# (.net 6) containers

python containers

Google Distroless Images

Distroless images from Google are an ideal candidate for generating a release quality Docker container image for any chosen language. E.g. the static-debian12:262ae336-distroless-py-2024-04-27-prod above could be used to host other solutions.

Benefits

• They do not have a built-in shell which makes them more secure.
• They only contain basic run-times needed for your application to run.
• Image size is only about 22MB.
• Images available for C++, Python, Java, and Node.js
• Debug version of image available with shell

For HCC2 containerized applications, a Debian 10 (buster) or newer Distroless image is recommended. Reference – GitHub – GoogleContainerTools/distroless: Language focused Docker images, minus the operating system

Disadvantages

There is no package installer (apt). It is assumed that you are bundling an application that is not tightly coupled to services/packages on the OS.
Without a shell, the entrypoint cannot be a script. This can be limiting in situations where startup is complex or 3rd party binaries are involved.

Other Alternatives

debian:buster-slim

Alpine

It’s small, but has a shell (unnecessary in production) and uses musl instead of glibc which means the language and any libraries used by the developer need to be fully compatible with this libc interface to the OS.