Container standards
Terminology
Dockerfile - set of instructions for building a docker image
Image - a constructed set of layered docker instructions
Container - a running instance of an image
Standards
Defra base images
Images are extended from a minimal Defra-created parent image. This allows us to benefit from improved security and more efficient builds because we do not have to repeat steps that are common to all Dockerfiles.
Different parent images should be created in line with each framework's best practice. Eg, Node.js, .NET, Ruby etc.
Defra's Dockerfiles to build parent images can be found in the following GitHub repositories:
Each image is hosted in DockerHub and has an equivalent development and production image.
Images are created using Docker
Docker is the de facto industry standard in most enterprises.
Docker Compose is used for defining container builds
Using a consistent containerisation tool will help enforce standards and better promote developer mobility.
Linux containers are used if the service to be containerised can run on Linux
Underlying container hosts can only host either Linux or Windows containers. A model of consistency would reduce the number of underlying hosts. Windows containers can only be run on Windows hosts which typically have greater licensing costs vs Linux.
Note that services built using .NET Framework cannot be run using Linux containers, but services built using modern .NET (formerly .NET Core) can. Defra's position is that .NET should be preferred over .NET Framework, but there may be use cases when containerising legacy services.
Images are built using Defra base images (see above)
Containers are not run using root user
Containers are not trust boundaries and therefore should never be run as root for security reasons.
Public images are signed
A digital fingerprint should be added to each image. This enables consumers of images to verify the source and trust levels of the image they are consuming.
Images are tagged using semantic versioning
For simplicity, it is beneficial to keep the image and containerised application version in sync.
Production images should be immutable and once built do not change but can be configured
Immutable images do not change once created which gives the a versioned image predictability and portability.
Images are self contained and carry all runtime dependencies
Images should not be dependent on their host infrastructure for any application dependency. This enables them to be freely deployed and orchestrated anywhere capable of running containers.