We provide a Dockerfile to build the GAIA API, specifically using the version 3.11.7. It is optimized for minimal size by using the slim variant of the Python Docker image. The Dockerfile is structured to allow customization through build-time arguments, enabling flexibility in configuring the application environment and dependencies.
Code Block |
---|
# syntax=docker/dockerfile:1 # Use a specific version of the Python image, slim variant to keep the image size minimal ARG PYTHON_VERSION=3.11.7 FROM python:$PYTHON_VERSION-slim AS GaiaAPI # Arguments for dependency installation and PYQPL library location # Options for INSTALL_DEPENDENCIES: [ldap], [genai], [all], or leave empty ARG INSTALL_DEPENDENCIES="" ARG PYQPL_LOCATION=lib/pyqpl-1.1.0-py3-none-any.whl # Set GAIA_ENV as an environment variable, default value is 'default' ARG GAIA_ENV=system_default ENV GAIA_ENV=$GAIA_ENV # Set CONFIG_URL as an environment variable, for custom configuration JSON file path ARG CONFIG_URL='' ENV CONFIG_URL=$CONFIG_URL # Set number of Uvicorn workers, typically 1 is recommended in Docker ARG UVICORN_WORKERS=1 ENV UVICORN_WORKERS=$UVICORN_WORKERS # Set protocol (default 'http') as an environment variable ARG PROTOCOL=http ENV PROTOCOL=$PROTOCOL # Set host for GAIA API, necessary unless default entrypoint is removed ARG HOST=0.0.0.0 ENV HOST=$HOST # Set port for GAIA API, necessary unless default entrypoint is removed ARG PORT=8085 ENV PORT=$PORT # Set domain name for GAIA API, necessary unless default entrypoint is removed ARG DOMAIN_NAME=host.docker.internal ENV DOMAIN_NAME=$DOMAIN_NAME # Set cookie domain name for GAIA API, necessary unless default entrypoint is removed ARG COOKIE_DOMAIN_NAME='' ENV COOKIE_DOMAIN_NAME=$COOKIE_DOMAIN_NAME # Set engine URL for GAIA API, necessary unless default entrypoint is removed ARG ENGINE_URL=http://host.docker.internal:9200 ENV ENGINE_URL=$ENGINE_URL # Set path to certificates, necessary only if mailer is enabled using custom SMTP ARG CERTIFICATES_PATH='' ENV CERTIFICATES_PATH=$CERTIFICATES_PATH # Set AWS Elasticsearch credentials, only if using AWS service ARG AWS_SERVICE=es ENV AWS_SERVICE=$AWS_SERVICE ARG AWS_REGION=us-east-1 ENV AWS_REGION=$AWS_REGION # Set AWS Access Key and Session Token, required only if using access key and token ARG AWS_ACCESS_KEY_ID=default-key ENV AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID ARG AWS_SECRET_ACCESS_KEY=default-secret ENV AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY ARG AWS_SESSION_TOKEN=default-token ENV AWS_SESSION_TOKEN=$AWS_SESSION_TOKEN # Switch to root user for further operations USER root:root # Copy the current directory into /gaia_api in the container and set it as the working directory WORKDIR /gaia_api COPY . . # Upgrade pip and install dependencies without using cache RUN pip install --upgrade pip RUN pip install --no-cache-dir -e ".$INSTALL_DEPENDENCIES" RUN pip install --no-cache-dir $PYQPL_LOCATION # Expose the specified port for the GAIA API EXPOSE $PORT # Default command to run Uvicorn with specified configurations CMD python -m uvicorn app.webapp:app --host $HOST --port $PORT --workers $UVICORN_WORKERS --no-server-header # Optional commands for running Uvicorn with proxy headers or SSL (uncomment as needed) # Uncomment to run Uvicorn with proxy headers if behind a proxy like Nginx or Traefik # CMD python -m uvicorn app.webapp:app --proxy-headers --host $HOST --port $PORT --workers |
$UVICORN_WORKERS --no-server-header # |
Uncomment to run Uvicorn with SSL, ensure SSL certificate and key paths are correct # CMD |
uvicorn app.webapp:app -- |
host $HOST --port $PORT --ssl- |
keyfile /path/in/container/private.key", "--ssl-certfile", "/path/in/container/certificate.crt"] |
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 |
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.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:
docker build
command with the appropriate tag:shelldocker build -t my-gaia-api .
Modify the Dockerfile:
PYTHON_VERSION
to 3.8
.FROM
line to use the Alpine variant:dockerfileARG PYTHON_VERSION=3.8 FROM python:$PYTHON_VERSION-alpine AS GaiaAPI
Rebuild the Image:
shelldocker build -t my-gaia-api-alpine .
This section will show you how to build a Docker image for GAIA API from scratch, based on the official Python image.
This is what you would want to do in most cases, for example:
Currently GAIA API uses a CIO's Ubuntu image as its base, if we want to build the Docker image we will need access to CIO Docker repository, for that follow the steps in Login Into CIO Azure Container Registry
Install the GAIA API requirements the same way it is specified in Install Python Dependencies
But in essence you need to do this
Code Block |
---|
pip install -e . |
And then
Code Block |
---|
pip install lib/pyqpl-VERSION_IN_PROJECT-py3-none-any.whl |
Table of Contents |
---|
Now in the same project directory create a file Dockerfile
with:
Code Block |
---|
# syntax=docker/dockerfile:1
# Base image (Ubuntu 22.04 from CIO)
FROM acncio.azurecr.io/ubuntu22.04cio-base:latest AS GaiaAPI
# Env variable for the GAIA API PORT [CAN BE REMOVED ONLY IF DEFAULT ENTRYPOINT IS REMOVED AS WELL]
ARG PORT=8085
ENV PORT=$PORT
# Env variable for the GAIA API HOST [CAN BE REMOVED ONLY IF DEFAULT ENTRYPOINT IS REMOVED AS WELL]
ARG HOST=0.0.0.0
ENV HOST=$HOST
# Env variable for the GAIA API DOMAIN_NAME [CAN BE REMOVED ONLY IF DEFAULT ENTRYPOINT IS REMOVED AS WELL]
ARG DOMAIN_NAME=host.docker.internal
ENV DOMAIN_NAME=$DOMAIN_NAME
# Env variable for the GAIA API COOKIE_DOMAIN_NAME [CAN BE REMOVED ONLY IF DEFAULT ENTRYPOINT IS REMOVED AS WELL]
ARG COOKIE_DOMAIN_NAME=''
ENV COOKIE_DOMAIN_NAME=$COOKIE_DOMAIN_NAME
# Env variable for the GAIA API ENGINE_URL [CAN BE REMOVED ONLY IF DEFAULT ENTRYPOINT IS REMOVED AS WELL]
ARG ENGINE_URL=http://host.docker.internal:9200
ENV ENGINE_URL=$ENGINE_URL
# *******************************************************************************
# AWS Elasticsearch Credentials
# *******************************************************************************
# Domain. If service is set then the AWS will be used
ARG AWS_SERVICE=es
ENV AWS_SERVICE=$AWS_SERVICE
ARG AWS_REGION=us-east-1
ENV AWS_REGION=$AWS_REGION
# ------------------------------------------------------
# Only if using Access Key and Session Token
# ------------------------------------------------------
ARG AWS_ACCESS_KEY_ID=default-key
ENV AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
ARG AWS_SECRET_ACCESS_KEY=default-secret
ENV AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
ARG AWS_SESSION_TOKEN=default-token
ENV AWS_SESSION_TOKEN=$AWS_SESSION_TOKEN
# Change user to ROOT
USER root:root
# Install python 3.11 and other dependencies on OS
RUN apt-get update && apt-get install -y\
pkg-config\
libxml2-dev\
libxmlsec1\
libxmlsec1-dev\
libxmlsec1-openssl\
xmlsec1\
build-essential\
curl\
iputils-ping\
libnss3-dev\
libgdbm-dev\
libncurses5-dev\
libssl-dev\
libffi-dev\
libreadline-dev\
libsqlite3-dev\
libbz2-dev\
software-properties-common\
vim\
wget\
zlib1g-dev\
# Installiing Python 3.11.2
&& wget https://www.python.org/ftp/python/3.11.2/Python-3.11.2.tgz\
&& tar xvf Python-3.11.2.tgz\
&& cd Python-*/\
&& ./configure --enable-optimizations\
&& make altinstall\
&& ln -s -f /usr/local/bin/python3.11 /usr/local/bin/python\
&& ln -s -f /usr/local/bin/pip3.11 /usr/local/bin/pip\
&& cd ..\
&& rm Python-3.11.2.tgz\
&& rm -rf Python-3.11.2
# Create our work directory
WORKDIR /gaia_api
# Change work directory ownership to root-less user
RUN chown appuser:appgroup /gaia_api
# Copy SAPI source and change ownership to root-less user
COPY --chown=appuser:appgroup . .
# Installiing all SAPI dependencies
RUN /bin/sh -c pip install --upgrade pip\
&& pip install --no-cache-dir lxml>=4.9.0\
&& pip install --no-cache-dir xmlsec\
&& pip install --no-cache-dir -e .\
# PYQPL from the local lib folder, check the VERSION before installing!
&& pip install --no-cache-dir lib/pyqpl-1.1.0-py3-none-any.whl
# Export GaiaAPI PORT
EXPOSE $PORT
# Change back to the root-less user
USER appuser:appgroup
# Start the SAPI at container start
CMD python -m uvicorn app.webapp:app --host $HOST --port $PORT --workers 1 --no-server-header |
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 |
Now that all the files are in place, let's build the container image.
Dockerfile
is, containing your app
directory).Code Block |
---|
$ docker build -t myimage . |
Tip |
---|
Notice the In this case, it's the same current directory ( |
Code Block |
---|
$ docker run -d --name mycontainer -p 8085:8085 myimage |
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:
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 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.
Anchor | ||||
---|---|---|---|---|
|
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.
Tip |
---|
To see all the configurations and options, go to the Docker image page: tiangolo/uvicorn-gunicorn-fastapi. |
The number of processes on this image is computed automatically from the CPU cores available.
This means that it will try to squeeze as much performance from the CPU as possible.
You can also adjust it with the configurations using environment variables, etc.
But it also means that as the number of processes depends on the CPU the container is running, the amount of memory consumed will also depend on that.
So, if your application consumes a lot of memory (for example with machine learning models), and your server has a lot of CPU cores but little memory, then your container could end up trying to use more memory than what is available, and degrading performance a lot (or even crashing).
Dockerfile
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. |
Here's how you would create a Dockerfile
based on this image:
Code Block |
---|
FROM tiangolo/uvicorn-gunicorn-fastapi:python3.9 # 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 |
You should probably not use this official base image (or any other similar one) if you are using Kubernetes (or others) and you are already setting replication at the cluster level, with multiple containers. In those cases, you are better off building an image from scratch as described above: Build a Docker Image for GAIA API.
This image would be useful mainly in the special cases described above in Containers with Multiple Processes and Special Cases. For example, if your application is simple enough that setting a default number of processes based on the CPU works well, you don't want to bother with manually configuring the replication at the cluster level, and you are not running more than one container with your app. Or if you are deploying with Docker Compose, running on a single server, etc.
After having a Container (Docker) Image there are several ways to deploy it.
For example: