When we look at containerising applications, it's good practice to make the image as small as possible with the least amount of bloat as possible.
The main reason for this is security focused as it means there's less packages to exploit.
But another reason is to make sure resources aren't being taken up.
The repo we will be working with today can be found here. You can clone the repo which has other examples I will eventually go over. But for now, the example we will be going through today will be for the big and small python demos.
Below is an example of two images. One is with the standard python:latest image and the other is with python:alpine
Notice the size difference? Crazy right?
Now you might think in the example for python_big and python_small there's some noticeable differences, but there's not much at all.
All the files are exactly the same.
The only difference is the image version I've chosen.
Below is the Dockerfile and docker-compose file for Python_big
FROM python ADD . /code WORKDIR /code RUN pip install -r requirements.txt CMD ["python", "app.py"]
version: '3' services: web: build: . ports: - "5001:5000" redis: image: "redis"
Below are the dockerfile and docker-compose files from python_small:
FROM python:3.4-alpine ADD . /codeWORKDIR /code RUN pip install -r requirements.txt CMD ["python", "app.py"]
version: '3' services: web: build: . ports: - "5000:5000" redis: image: "redis:alpine"
Notice how the only real difference is the image name?
The reason for this is in the example for python_big is we're just grabbing the standard python image which comes pre installed with a bunch of packages even if they aren't needed.
What we're doing in python_small is grabbing the alpine image which has python installed, but no packages.
So what we then do in the dockerfile is run a pip install on the requirement.txt file and this will install all the essential packages needed without all the bloat.
This is one way we can get smaller images and think about resource management when creating images for our apps.