What is DockerFile?
A Dockerfile is a text document that contains all the commands a user could call on the command line to assemble an image. Using docker build users can create an automated build that executes several command-line instructions in succession. This page describes the commands you can use in a Dockerfile
Features of Docker:
Docker provides various features, some of which are listed and discussed below.
Faster and easier configuration
Application isolation
Increase in productivity
Swarm
Services
Routing Mesh
Security Management
Rapid scaling of Systems
Better Software Delivery
Software-defined networking
Has the Ability to Reduce the Size
How to write a production-ready dockerfile?
There are a lot of Dockerfile samples on web and developers tend to use those example directly for building applications into containers during development stage. However, the fact is those Dockerfile samples are far from production-ready, which may induce reliablity and security issues if containers created with such Dockerfile are being shipped into production environment. Even though issues may spot out by your security team eventually (or may not), we all should learn how to write a production-ready Dockerfile under the Shift Left approach.
Running as non-root use
Below was the Dockerfile example in building an ASP.NET Core application from docker.com, since this example doesn’t set a user explicity in the Dockerfile, docker will run the command dotnet aspnetapp.dll as root user. This might not be an issue in development stage but that induce container vulnerabilities in production environment.
FROM mcr.microsoft.com/dotnet/aspnet:5.0
COPY bin/Release/netcoreapp3.1/publish/ App/
WORKDIR /App
ENTRYPOINT ["dotnet", "aspnetapp.dll"]The suggested way to write the Dockerfile is as below, which will create and run the command dotnet aspnetapp.dll as a non-root user.
FROM mcr.microsoft.com/dotnet/aspnet:5.0 # Create group app and user app
RUN addgroup --gid 1000 -S app && adduser --uid 1000 -S app -G app # Set permissions for app user for the WORKDIR
RUN chown -R app:app App/ # Switch to the created user
USER app
COPY bin/Release/netcoreapp3.1/publish/ App/
WORKDIR /App
ENTRYPOINT ["dotnet", "aspnetapp.dll"]Pin your image verions
Specify a version number for your image called pinning. Dockerfile samples on web often pin their base images to latest which means it will get the most updated version everytime. This may causes issues in production because latest version means it is not the version being well-tested in your development and QA stages. A new version may introduce some unexpected changes in the container which could induce security and reliability issues out of your expectation.
Pin to latest example
FROM node:latestPin to specific version example
FROM node:16.2.0Add healthchecks (not applicable to Kubernetes)
If your application was running on pure docker or docker swarm, HEALTHCHECK command is the right way to go. If your application was running on Kubernetes, you should instead refer to Liveness Probes and Readiness Probes features provided by Kubernetes.
The HEALTHCHECK command can be specified as:
HEALTHCHECK options CMD commandThe options are: - interval=DURATION (default 30s) - timeout=DURATION (default 30s) - start-period=DURATION (default: 0s) - retries=N (default 3)
The command can by any command you can run inside your container, usually curl will be used, for example we could use below health check command for a SpringBoot application.
HEALTHCHECK --interval=5s --timeout=3s CMD curl --fail http://localhost:8080/actuator/health || exit 1Use multi-stage builds
Mutli-stage build is the way to reduce image size by building the image twice.
The first stage is to build the application artifacts by using the base image containing the entire SDK of that programming lanuage (for example, JDK for Java and .Net SDK for .Net Core).
The second stage is to build an image by copying only the application artifacts left in the first stage and leave out anything which is not needed. Usually the image containing only the runtime environment will be used as the base image in this stage.
Below is an Dockerfile example provided by Microsoft using multi-stage build.
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /source# copy csproj and restore as distinct layers
COPY *.sln .
COPY aspnetapp/*.csproj ./aspnetapp/
RUN dotnet restore# copy everything else and build app
COPY aspnetapp/. ./aspnetapp/
WORKDIR /source/aspnetapp
RUN dotnet publish -c release -o /app --no-restore# final stage/image
FROM mcr.microsoft.com/dotnet/aspnet:6.0
WORKDIR /app
COPY --from=build /app ./
ENTRYPOINT ["dotnet", "aspnetapp.dll"]By using the multi-stage build approach, aspnet:6.0 (image containing only the .Net runtime) instead of sdk:6.0 (image containing the entire .Net SDK) is used as the base image in the final stage. This is a desired result because image containing only the runtime often has a reduced size when compared with image containing the entire SDK.
Ensure image with minimal packages
Reducing image size is an important concern when there is space constraints. Moreover, keeping the image size small also means keeping minimal packages installation on your image. Minimal packages installation has the benefit of reducing attack surface in container security perspective.
To achieve minmial packages installation on your image, we should select the approriate base image. The common base image includes:
Alpine (probably the smallest option among base images, which is an operating system built by Alpine Linux dedicated for container use)
Stretch / Buster / Jessie (buster, jessie or stretch are the codenames for releases of Debian and indicate which release the image is based on)
Slim (contains only the minmial packages needed to run your particular applications compared with the full official image)
Adopt container scanning solutions
Container scanning is the process of scanning containers to identify potential vulnerabilities. It is a crucial process in your DevOps workflow and many teams are looking for such solutions to minmize container security threats. Comparing with above mentioned best practices in writing Dockerfile, container scanning solutions should act as the final security guard to detect and aovid any undesired settings rollout into production environment.
Resource: Medium (Marco),
The Tech Platform
Comments