You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

When deploying FastAPI applications a common approach is to build a Linux container image. It's normally done using Docker. You can then deploy that container image in one of a few possible ways.

Using Linux containers has several advantages including security, replicability, simplicity, and others.

In a hurry and already know this stuff? Jump to the Dockerfile below.

Dockerfile Preview 
# Base image (alpine linux)
FROM python:3.11.2-alpine3.17 AS SearchAPI
 
#
WORKDIR /search_api
 
 
# copy source files
COPY . .
 
# Install Python Dependencies
RUN pip3 install --no-cache-dir -e .
 
# Install Pyqpl local library
RUN pip3 install lib/pyqpl-1.0.5-py3-none-any.whl
 
# exposed port for docker image [CAN BE CHANGED, BUT WHEN RUNNING THE IMAGE, THIS WILL BE PORT THAT WILL BE OPEN INSIDE DOCKER]
EXPOSE 8085
 
#
CMD ["uvicorn", "app.webapp:app", "--host", "0.0.0.0", "--port", "8085"]

Build a Docker Image for SearchA PI

This section will show you how to build a Docker image for Search API from scratch, based on the official Python image.

This is what you would want to do in most cases, for example:

  • Using Kubernetes or similar tools
  • When running on a Raspberry Pi
  • Using a cloud service that would run a container image for you, etc.

Package Requirements

Install the Search API requirements the same way it is specified in Install Python Dependencies

But in essence you need to do this

pip install -e .

And then 

pip install lib/pyqpl-VERSION_IN_PROJECT-py3-none-any.whl

Dockerfile

Now in the same project directory create a file Dockerfile with:

# Base image (alpine linux)
FROM python:3.11.2-alpine3.17 AS SearchAPI

# 
WORKDIR /search_api


# copy source files
COPY . .

# Install Python Dependencies
RUN pip3 install --no-cache-dir -e .

# Install Pyqpl local library
RUN pip3 install lib/pyqpl-1.0.5-py3-none-any.whl

# exposed port for docker image [CAN BE CHANGED, BUT WHEN RUNNING THE IMAGE, THIS WILL BE PORT THAT WILL BE OPEN INSIDE DOCKER]
EXPOSE 8085

# 
CMD ["uvicorn", "app.webapp:app", "--host", "0.0.0.0", "--port", "8085"]

Behind a TLS Termination Proxy

If you are running your container behind a TLS Termination Proxy (load balancer) like Nginx or Traefik, add the option --proxy-headers, this will tell Uvicorn to trust the headers sent by that proxy telling it that the application is running behind HTTPS, etc.

CMD ["uvicorn", "app.webapp:app", "--proxy-headers", "--host", "0.0.0.0", "--port", "8085"]

Build the Docker Image

Now that all the files are in place, let's build the container image.

  • Go to the project directory (in where your Dockerfile is, containing your app directory).
  • Build your FastAPI image:
$ docker build -t myimage .

Notice the . at the end, it's equivalent to ./, it tells Docker the directory to use to build the container image.

In this case, it's the same current directory (.).

Start the Docker Container

  • Run a container based on your image:
$ docker run -d --name mycontainer -p 8085:8085 myimage

Check it

You should be able to check it in your Docker container's URL, for example: http://localhost:8085/es/api (or equivalent, using your Docker host).

You will see something like:

Search API Running

Interactive API docs

Now you can go to http://localhost/es/docs (or equivalent, using your Docker host).

You will see the automatic interactive API documentation (provided by Swagger UI):

Alternative API docs

Now you can go to http://localhost/es/redoc (or equivalent, using your Docker host).

You will see the automatic interactive API documentation (provided by ReDoc):

HTTPS

If we focus just on the container image for a Search API application (and later the running container), HTTPS normally would be handled externally by another tool.

It could be another container, for example with Traefik, handling HTTPS and automatic acquisition of certificates.

Traefik has integrations with Docker, Kubernetes, and others, so it's very easy to set up and configure HTTPS for your containers with it.

Alternatively, HTTPS could be handled by a cloud provider as one of their services (while still running the application in a container).

Running on Startup and Restarts

There is normally another tool in charge of starting and running your container.

It could be Docker directly, Docker Compose, Kubernetes, a cloud service, etc.

In most (or all) cases, there's a simple option to enable running the container on startup and enabling restarts on failures. For example, in Docker, it's the command line option --restart.

Without using containers, making applications run on startup and with restarts can be cumbersome and difficult. But when working with containers in most cases that functionality is included by default. 

Replication - Number of Processes

If you have a cluster of machines with Kubernetes, Docker Swarm Mode, Nomad, or another similar complex system to manage distributed containers on multiple machines, then you will probably want to handle replication at the cluster level instead of using a process manager (like Gunicorn with workers) in each container.

One of those distributed container management systems like Kubernetes normally has some integrated way of handling replication of containers while still supporting load balancing for the incoming requests. All at the cluster level.

In those cases, you would probably want to build a Docker image from scratch as explained above, installing your dependencies, and running a single Uvicorn process instead of running something like Gunicorn with Uvicorn workers.

  • No labels