When shipping applications using containers, one often is confronted with overly large final images. Multi-stage builds are a common way to circumvent this issue, especially for compiled languages like Go or Java. In our latest blog post we show how to utilise multi-stage builds for python images to bring down image sizes and thereby improving security.<\/p>\n\n\n\n\n\n\n\n
When writing container images, it is always preferable to have smaller images and to only include what is really needed. This has two main advantages:<\/p>\n\n\n\n
Let’s take a very simple image that starts off with an official python-docker image, using a slim version of the current stable debian release, bullseye. We are going to use python 3.8, but this is not important. The image is pulled from docker hub<\/a>. <\/a><\/p>\n\n\n\n We are simply going to `COPY` over a `requirements.txt` and install it using `pip`, as this is a fairly common use case. I have chosen to install pyodbc since it has some system Note: The dockerfiles are a m<\/a>inimal reproducible example<\/a> and do not follow some common best practices!<\/em><\/em><\/a><\/p>\n\n\n\n After building the image, we get an image size of 422MB:<\/p>\n\n\n\n Multi-stage builds<\/a> are a neat way to keep build dependencies from blowing up the size of your final image. I am not going to go into detail on how they work.<\/p>\n\n\n\n I am going to create wheels. From the pip documentation<\/a>: <\/p>\n\n\n\n “Wheel is a built-package format, and offers the advantage of not recompiling your software during every install.”<\/em><\/p><\/blockquote>\n\n\n\n And this is exactly what we want. Compile it and then reuse it without compilation. The size of the image has gone down significantly:<\/p>\n\n\n\n The difference is starker when considering the size of the base image:<\/p>\n\n\n\n Smaller images can contribute to more security. The original image that includes the build tools has 331 total vulnerabilities:<\/p>\n\n\n\n
The dockerfiles are provided in this repository<\/a> in the docker directory and can be built using ‘.\/bin\/build.sh’<\/a> on Linux.<\/p>\n\n\n\nReducing the image size<\/h3>\n\n\n\n
The all-in-one solution<\/h4>\n\n\n\n
dependencies that have to be installed.
<\/p>\n\n\n\n```dockerfile\nFROM python:3.8-slim-bullseye\n\nRUN apt-get update && \\\n apt-get install -y gcc g++ unixodbc-dev\n\nCOPY requirements.txt \/tmp\/requirements.txt\n\nRUN pip3 install --no-cache-dir -r \/tmp\/requirements.txt\n```<\/code><\/pre>\n\n\n\n```bash\n$ docker images original\nREPOSITORY TAG IMAGE ID CREATED SIZE\noriginal latest 09ec99a1bafa About a minute ago 422MB\n```<\/code><\/pre>\n\n\n\nIntroducing: multi-stage<\/h4>\n\n\n\n
The original dockerfile is split in 2: the builder image will install the build dependencies and create the wheels. The final image will install the packages from the wheels without the need to install any build tools:<\/p>\n\n\n\nthe wheels. The final image will install the packages from the wheels without the need to install any \n```dockerfile\nARG WHEEL_DIST=\"\/tmp\/wheels\"\n\nFROM python:3.8-slim-bullseye as builder\n\nARG WHEEL_DIST\n\nRUN apt-get update && \\\n apt-get install -y gcc g++ unixodbc-dev\n\nCOPY requirements.txt \/tmp\/requirements.txt\n\nRUN python3 -m pip wheel -w \"${WHEEL_DIST}\" -r \/tmp\/requirements.txt\n\n\nFROM python:3.8-slim-bullseye\n\nARG WHEEL_DIST\n\nCOPY --from=builder \"${WHEEL_DIST}\" \"${WHEEL_DIST}\"\n\nWORKDIR \"${WHEEL_DIST}\"\n\nRUN pip3 --no-cache-dir install *.whl\n``` <\/code><\/pre>\n\n\n\n```bash\n$ docker images multi-stage\nREPOSITORY TAG IMAGE ID CREATED SIZE\nmulti-stage latest b90d97997b3b 44 seconds ago 128MB\n```<\/code><\/pre>\n\n\n\n```bash\ndocker images python:3.8-slim-bullseye\nREPOSITORY TAG IMAGE ID CREATED SIZE\npython 3.8-slim-bullseye caf584a25606 5 days ago 122MB\n```<\/code><\/pre>\n\n\n\nIncreasing security<\/h3>\n\n\n\n
To illustrate this point, we are going to use trivy<\/a> to scan our images for known security vulnerabilities.
The base image has 85 vulnerabilities:<\/p>\n\n\n\n