Python Base Image:
ARG PYTHON_VERSION=3.11.7
: Defines a variable PYTHON_VERSION
to specify the Python version. The default is 3.11.7
.FROM python:$PYTHON_VERSION-slim AS GaiaAPI
: Uses the slim variant of the specified Python version as the base image and names the build stage GaiaAPI
.Build Arguments for Dependencies and Configuration:
ARG
instructions define default values for build-time variables like INSTALL_DEPENDENCIES
, PYQPL_LOCATION
, and environment configurations (GAIA_ENV
, CONFIG_URL
, etc.). These arguments allow for customization during the Docker image build process.Environment Variables:
ENV
instructions set environment variables based on the ARG
values. These variables configure the application runtime environment, including API settings (host, port, protocol), AWS credentials, and more.User Context:
USER root:root
: Sets the user context to root
for subsequent commands.Application Setup:
WORKDIR /gaia_api
: Sets the working directory inside the container.COPY . .
: Copies the current directory's contents into /gaia_api
in the container.Dependency Installation:
pip
.PYQPL
library without using the cache, ensuring a fresh install.Port Exposition:
EXPOSE $PORT
: Exposes the port defined by the PORT
environment variable.Default Command:
CMD
instruction sets the default command to run Uvicorn
with the specified configurations.Optional Commands:
CMD
instructions provide options for running Uvicorn with proxy headers or SSL, which can be enabled as needed.To change the base image to another Python base image, follow these steps:
Identify the Desired Python Image:
buster
, alpine
) or version as required.Modify the Dockerfile:
ARG PYTHON_VERSION
value to the desired Python version.FROM
instruction with the new image. For example, if you want to use Python 3.9 on Alpine, change it to:dockerfileARG PYTHON_VERSION=3.9 FROM python:$PYTHON_VERSION-alpine AS GaiaAPI
Rebuild the Docker Image:
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.
Code Block |
---|
CMD python -m uvicorn app.webapp:app --proxy-headers --host $HOST --port $PORT --workers 1 --no-server-header |
Building a Docker image from this Dockerfile involves using the docker build
command. You can customize the build process by specifying various arguments, allowing for different configurations of the resulting image.
Bare Minimum Build: To build the Docker image with the default settings (as specified in the Dockerfile), navigate to the directory containing the Dockerfile and run:
Code Block |
---|
docker build -t my-gaia-api . |
-t my-gaia-api
assigns the tag my-gaia-api
to the built image..
specifies the current directory as the build context.Available Arguments: The Dockerfile includes several build-time arguments (ARG
) that allow for customizing the build. Here is a list of the available arguments and their default values:
PYTHON_VERSION
: The version of the Python image. Default is 3.11.7
.INSTALL_DEPENDENCIES
: Options for additional dependencies. Default is an empty string.PYQPL_LOCATION
: Location of the PYQPL library. Default is lib/pyqpl-1.1.0-py3-none-any.whl
.GAIA_ENV
: Environment setting for GAIA. Default is system_default
.CONFIG_URL
: URL for custom configuration JSON file. Default is an empty string.UVICORN_WORKERS
: Number of Uvicorn workers. Default is 1
.PROTOCOL
, HOST
, PORT
, DOMAIN_NAME
, COOKIE_DOMAIN_NAME
, ENGINE_URL
, CERTIFICATES_PATH
, AWS_SERVICE
, AWS_REGION
, AWS_ACCESS_KEY_ID
, AWS_SECRET_ACCESS_KEY
, AWS_SESSION_TOKEN
: Various settings for the GAIA API.Example Builds with Custom Arguments:
To build with a specific Python version and a set of dependencies:
Code Block |
---|
docker build --build-arg PYTHON_VERSION=3.9 --build-arg INSTALL_DEPENDENCIES=[ldap] -t my-gaia-api . |
To build with a custom configuration URL and a specific number of Uvicorn workers:
Code Block |
---|
docker build --build-arg CONFIG_URL='http://myconfig.com/config.json' --build-arg UVICORN_WORKERS=2 -t my-gaia-api . |
To build with AWS-specific configurations:
Code Block |
---|
docker build --build-arg AWS_ACCESS_KEY_ID=my-access-key --build-arg AWS_SECRET_ACCESS_KEY=my-secret-key -t my-gaia-api . |
Note |
---|
|
After building the Docker image from the Dockerfile, you can run a container using the docker run command. This section provides instructions on how to do so, including how to utilize various environment variables for customizing the runtime behavior of your container.
Code Block |
---|
$ docker run -d --name mycontainer -p 8085:8085 myimage |
Bare Minimum Run: To run a container with the default settings, use the following command:
Code Block |
---|
docker run -d -p 8085:8085 --name my-gaia-api |
-d
runs the container in detached mode (in the background).-p 8085:8085
maps port 8085 of the container to port 8085 on the host. Adjust the port numbers as needed based on the PORT
environment variable.--name my-gaia-api
is the tag name of the image you built.Available Environment Variables: The Dockerfile defines several environment variables (ENV
) that you can override at runtime. Here is a list of the available environment variables:
GAIA_ENV
, CONFIG_URL
, UVICORN_WORKERS
, PROTOCOL
, HOST
, PORT
, DOMAIN_NAME
, COOKIE_DOMAIN_NAME
, ENGINE_URL
, CERTIFICATES_PATH
, AWS_SERVICE
, AWS_REGION
, AWS_ACCESS_KEY_ID
, AWS_SECRET_ACCESS_KEY
, AWS_SESSION_TOKEN
: Various settings for the GAIA API.Example Runs with Custom Environment Variables:
To run with a specific environment and a custom port:
Code Block |
---|
docker run -d -p 5000:5000 -e GAIA_ENV=production -e PORT=5000 --name my-gaia-api |
To run with a custom configuration URL:
Code Block |
---|
docker run -d -p 8085:8085 -e CONFIG_URL='http://myconfig.com/config.json' --name my-gaia-api |
To run with specific AWS credentials:
Code Block |
---|
docker run -d -p 8085:8085 -e AWS_ACCESS_KEY_ID=my-access-key -e AWS_SECRET_ACCESS_KEY=my-secret-key --name my-gaia-api |
To run with a custom engine URL, use the ENGINE_URL
variable.
Code Block |
---|
docker run -d -p 8085:8085 -e ENGINE_URL=https://myengine.example.com --name my-gaia-api |
Note |
---|
|
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:
Code Block |
---|
GAIA API Running |
Now you can go to http://localhost:8085/es/docs (or equivalent, using your Docker host).
You will see the automatic interactive API documentation (provided by Swagger UI):
Now you can go to http://localhost:8085/es/redoc (or equivalent, using your Docker host).
You will see the automatic interactive API documentation (provided by ReDoc):
Customizing the base image in the Dockerfile allows you to use a different version or variant of Python, depending on your application's needs. This can be particularly useful for matching the Python environment to your existing development or production environments.
Identify the Desired Python Image:
alpine
, buster
, etc. The official Python Docker images are available on Docker Hub.Edit the Dockerfile (2 options):
Customizing the base image in the Dockerfile allows you to use a different version or variant of Python, depending on your application's needs. This can be particularly useful for matching the Python environment to your existing development or production environments.
Identify the Desired Python Image:
alpine
, buster
, etc. The official Python Docker images are available on Docker Hub.Edit the Dockerfile (2 options):
ARG PYTHON_VERSION=...
. This line defines the default Python version.PYTHON_VERSION
argument to the desired version. For example, to use Python 3.8, change it to ARG PYTHON_VERSION=3.8
.FROM python:$PYTHON_VERSION-slim AS GaiaAPI
line. This line specifies the base image.slim
to another variant if desired. For example, to use the Alpine variant, change it to FROM python:$PYTHON_VERSION-alpine AS GaiaAPI
.ARG PYTHON_VERSION=...
line, if present. This line defines the default Python version.FROM
instruction to reference your custom base image PYTHON_VERSION
argument to the desired version. For example, if your custom image is named custom-client:latest
, update the line to:Code Block |
---|
FROM custom-client:latest AS GaiaAPI |
Rebuild the Docker Image:
After saving your changes to the Dockerfile, rebuild the image to reflect the new base image. Use the docker build
command with the appropriate tag:
Code Block |
---|
docker build -t my-gaia-api . |
Example: Switching to Python 3.10 Alpine
ARG PYTHON_VERSION=3.8
.FROM python:$PYTHON_VERSION-slim AS GaiaAPI
line. This line specifies the base image.slim
to another variant if desired. For example, to use the Alpine variant, change it to FROM python:$PYTHON_VERSION-alpine AS GaiaAPI
.ARG PYTHON_VERSION=...
line, if present.Modify the FROM
instruction to reference your custom base image. For example, if your custom image is named custom-client:latest
, update the line to:
Code Block |
---|
FROM custom-client:latest AS GaiaAPI |
Rebuild the Docker Image:
Modify the Dockerfile:
PYTHON_VERSION
to 3.10
.Update the FROM
line to use the Alpine variant:
Code Block | ||
---|---|---|
| ||
ARG PYTHON_VERSION=3.10 FROM python:$PYTHON_VERSION-alpine AS GaiaAPI |
Rebuild the Image:
After saving your changes to the Dockerfile, rebuild the image to reflect the new base image. Use the docker build
command with the appropriate tag:
Code Block |
---|
docker build -t my-gaia-api |
Note |
---|
|
. |
Example: Switching to Python 3.10 Alpine
Modify the Dockerfile:
PYTHON_VERSION
to 3.10
.Update the FROM
line to use the Alpine variant:
Code Block | ||
---|---|---|
| ||
ARG PYTHON_VERSION=3.10 FROM python:$PYTHON_VERSION-alpine AS GaiaAPI |
Rebuild the Image:
Code Block |
---|
docker build -t my-gaia-api-alpine . |
Note |
---|
|
If we focus just on the container image for a Gaia API application (and later the running container), HTTPS normally would be handled externally by another tool.
Alternatively, HTTPS could be handled by a cloud provider as one of their services (while still running the application in a container).
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.
Now you can go to http://localhost:8085/es/docs (or equivalent, using your Docker host).
You will see the automatic interactive API documentation (provided by Swagger UI):
Now you can go to http://localhost:8085/es/redoc (or equivalent, using your Docker host).
You will see the automatic interactive API documentation (provided by ReDoc):
If we focus just on the container image for a Gaia API application (and later the running container), HTTPS normally would be handled externally by another tool.
Alternatively, HTTPS could be handled by a cloud provider as one of their services (while still running the application in a container).
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.
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.
When using containers, you would normally have some component listening on the main port. It could possibly be another container that is also a TLS Termination Proxy to handle HTTPS or some similar tool.
As this component would take the load of requests and distribute that among the workers in a (hopefully) balanced way, it is also commonly called a Load Balancer.
Tip |
---|
The same TLS Termination Proxy component used for HTTPS would probably also be a Load Balancer. |
And when working with containers, the same system you use to start and manage them would already have internal tools to transmit the network communication (e.g. HTTP requests) from that load balancer (that could also be a TLS Termination Proxy) to the container(s) with your app.
When working with Kubernetes or similar distributed container management systems, using their internal networking mechanisms would allow the single load balancer that is listening on the main port to transmit communication (requests) to possibly multiple containers running your app.
Each of these containers running your app would normally have just one process (e.g. a Uvicorn process running your Gaia API application). They would all be identical containers, running the same thing, but each with its own process, memory, etc. That way you would take advantage of parallelization in different cores of the CPU, or even in different machines.
And the distributed container system with the load balancer would distribute the requests to each one of the containers with your app in turns. So, each request could be handled by one of the multiple replicated containers running your app.
And normally this load balancer would be able to handle requests that go to other apps in your cluster (e.g. to a different domain, or under a different URL path prefix), and would transmit that communication to the right containers for that other application running in your cluster.
In this type of scenario, you probably would want to have a single (Uvicorn) process per container, as you would already be handling replication at the cluster level.
So, in this case, you would not want to have a process manager like Gunicorn with Uvicorn workers, or Uvicorn using its own Uvicorn workers. You would want to have just a single Uvicorn process per container (but probably multiple containers).
Having another process manager inside the container (as would be with Gunicorn or Uvicorn managing Uvicorn workers) would only add unnecessary complexity that you are most probably already taking care of with your cluster system.
Anchor | ||||
---|---|---|---|---|
|
Of course, there are special cases where you could want to have a container with a Gunicorn process manager starting several Uvicorn worker processes inside.
In those cases, you can use the official Docker image that includes Gunicorn as a process manager running multiple Uvicorn worker processes, and some default settings to adjust the number of workers based on the current CPU cores automatically. I'll tell you more about it below in Official Docker Image with Gunicorn - Uvicorn.
Here Here are some examples of when that could make sense:
You could want a process manager in the container if your application is simple enough that you don't need (at least not yet) to fine-tune the number of processes too much, and you can just use an automated default (with the official Docker image), and you are running it on a single server, not a cluster.
You could be deploying to a single server (not a cluster) with Docker Compose, so you wouldn't have an easy way to manage replication of containers (with Docker Compose) while preserving the shared network and load balancing.
Then you could want to have a single container with a process manager starting several worker processes inside.
You could also have other reasons that would make it easier to have a single container with multiple processes instead of having multiple containers with a single process in each of them.
For example (depending on your setup) you could have some tool like a Prometheus exporter in the same container that should have access to each of the requests that come.
In this case, if you had multiple containers, by default, when Prometheus came to read the metrics, it would get the ones for a single container each time (for the container that handled that particular request), instead of getting the accumulated metrics for all the replicated containers.
Then, in that case, it could be simpler to have one container with multiple processes, and a local tool (e.g. a Prometheus exporter) on the same container collecting Prometheus metrics for all the internal processes and exposing those metrics on that single container.
If you run a single process per container you will have a more or less well-defined, stable, and limited amount of memory consumed by each of those containers (more than one if they are replicated).
And then you can set those same memory limits and requirements in your configurations for your container management system (for example in Kubernetes). That way it will be able to replicate the containers in the available machines taking into account the amount of memory needed by them, and the amount available in the machines in the cluster.
If your application is simple, this will probably not be a problem, and you might not need to specify hard memory limits. But if you are using a lot of memory (for example with machine learning models), you should check how much memory you are consuming and adjust the number of containers that runs in each machine (and maybe add more machines to your cluster).
If you run multiple processes per container (for example with the official Docker image) you will have to make sure that the number of processes started doesn't consume more memory than what is available.
If you are using containers (e.g. Docker, Kubernetes), then there are two main approaches you can use.
If you have multiple containers, probably each one running a single process (for example, in a Kubernetes cluster), then you would probably want to have a separate container doing the work of the previous steps in a single container, running a single process, before running the replicated worker containers.
Info |
---|
If you are using Kubernetes, this would probably be an Init Container. |
If in your use case there's no problem in running those previous steps multiple times in parallel (for example if you are not running database migrations, but just checking if the database is ready yet), then you could also just put them in each container right before starting the main process.
If you have a simple setup, with a single container that then starts multiple worker processes (or also just one process), then you could run those previous steps in the same container, right before starting the process with the app. The official Docker image supports this internally.
There is an official Docker image that includes Gunicorn running with Uvicorn workers, as detailed in a previous chapter: Server Workers - Gunicorn with Uvicorn.
This image would be useful mainly in the situations described above in: Containers with Multiple Processes and Special Cases.
Warning |
---|
There's a high chance that you don't need this base image or any other similar one, and would be better off by building the image from scratch as described above in: Build a Docker Image for GAIA API. |
This image has an auto-tuning mechanism included to set the number of worker processes based on the CPU cores available.
It has sensible defaults, but you can still change and update all the configurations with environment variables or configuration files.
It also supports running previous steps before starting with a script.
setup, with a single container that then starts multiple worker processes (or also just one process), then you could run those previous steps in the same container, right before starting the process with the app. The official Docker image supports this internally.