We'll dockerize a FastAPI app. This is the file structure for our app.

And we have a main.py file in the code file. Our Dokcerfile looks like this.

FROM python:3.9
COPY ./requirements.txt /code/requirements.txt
RUN pip install --no-cache-dir --upgrade -r /code/requirements.txt
COPY ./code /code
WORKDIR /code
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Let's explain each line of code. :D

FROM python:3.9
In this line, we're pulling an image from the docker hub. As we're building a FastAPI app, we need Python. If it were a react or vue app, we might've used node:something. To find out more about available docker images, Docker Hub is the place to search.

COPY ./requirements.txt
RUN pip install --no-cache-dir --upgrade -r /code/requirements.txt

It may seem a bit odd that, we're first copying only the requirements file and then we're copying the code after installing the requirements. This is to utilize docker's caching mechanism. By default, docker will cache each layer of an image. So, by installing the dependencies first, docker can use the cache for the next time build if requirements haven't changed. We can see the layered history by using the docker history <image_name> command.

COPY ./code /code
WORKDIR /code

After installing the required dependency, now we're copying the code and setting the working directory to /code. So that, when we try to execute any command it'll execute from /code directory.

CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "80"]

Finally, we execute the app by spinning up a uvicorn wsgi server pointed to our app inside the docker.

RUN vs CMD

It might be confusing that we used RUN and CMD. The difference is that RUN will execute the command when building the image but CMD will execute the commands when we run the container. If multiple CMD is written on the Dockerfile, only the last one will take effect.

Also, one thing to mention here is that there are two forms of writing CMD. Shell form [CMD uvicorn main:app] or Exec form [CMD ["uvicorn", "main:app"]]. The difference is that commands written in shell form will be executed through the shell. But exec form commands do not need to spin up another shell process to run as it will run directly. So, it's faster to use the exec form.

We also have a command ENTRYPOINT. It does the same thing as CMD but it's a little bit harder to overwrite. For example, when we start the container in interactive mode (mentioned below), we can easily overwrite the CMD. But to overwrite ENTRYPOINT command, we have to use the --entrypoint option.

Building The Image

We can now build the image by running the command:

docker build -t <image_name>:tag

After the building is complete, we can view it by running the command:

docker images

We can interact with the container with the following command:

docker run -it <image_name> sh

We're saying docker to start the image in interactive mode and run the "shell" program.

Running The Container

For development, we'll be using the following command to run the container:

docker run -d -p 8000:80 -v $(pwd)/code:/code <image_name>

Here,
-d is to run the container in detached mode.
-p is to map ports from outside to inside.
-v is to map our current directory to the container's directory so that when we make any changes to our code, it reflects on the directory inside the container. (-v is to map volume in order to persist data, more on that in another journal).

For production, we'll be using the following command to run the container:

docker run -d -p 8000:80 <image_name>

Notice that, we're not using a volume here to track. That's because we want a clean production build.

Clean Up

We can see the list of all the images with this command

docker images

And, we might see some images with <none> tag and repository. That means, the images are dangling. They lost their connection with any containers. Those images can be removed with the following command

docker image prune

We can also see running containers with the following command:

docker ps

But it only show all the running containers. To view all the containers, that are also exited, we can run the following command:

docker ps -a

We call remove all the stopped containers with the following command:

docker container prune

Good To Know

Image

We can have all the image operations by running the following command:

docker image

We can tag any image using the docker tag command. For example:

docker tag <image_id> <username>/<image_name>:<tag>

We can push this image to docker hub using the following command.

docker push <username>/<image_name>:<tag>

Container

We can run any command in a running container using the following exec command. For example:

docker exec <container_name> ls

We can use start/stop/rm to start/stop/remove a container.

docker start/stop/rm <container_name>

Logs

We can see all logs option using the following command:

docker logs