/uvicorn-gunicorn-poetry

Docker image with Gunicorn using Uvicorn workers for running Python web applications. Uses Poetry for managing dependencies and setting up a virtual environment. Supports AMD64 and ARM64 CPU architectures.

Primary LanguagePythonMIT LicenseMIT

codecov pipeline workflow Docker Image Size (latest semver) Docker Pulls

uvicorn-gunicorn-poetry - Docker image for FastAPI

This Docker image provides a platform to run Python applications with Gunicorn as process manager and Uvicorn workers. It provides Poetry for managing dependencies and setting up a virtual environment in the container.

This image aims to follow the best practices for a production grade container image for hosting Python web applications based on micro frameworks like FastAPI. Therefore, source and documentation contain a lot of references to documentation of dependencies used in this project, so users of this image can follow up on that.

If you would like to run your Python application with Uvicorn on Kubernetes, please check out my other project which does not use Gunicorn as process manager: https://github.com/max-pfeiffer/uvicorn-poetry

Any feedback is highly appreciated and will be considered.

Docker Hub: pfeiffermax/uvicorn-gunicorn-poetry

GitHub Repository: https://github.com/max-pfeiffer/uvicorn-gunicorn-poetry

Docker Image Features

  1. Poetry v1.8.2 is available as Python package dependency management tool
  2. A virtual environment for the application and application server
  3. The application is run with Gunicorn and Uvicorn workers
  4. Python versions:
    1. 3.10
    2. 3.11
    3. 3.12
  5. Operating system variants:
    1. Debian Bookworm v12.1
    2. Debian Bookworm slim v12.1
  6. Supported CPU architectures:
    1. linux/amd64
    2. linux/arm64/v8

Usage

It just provides a platform that you can use to build upon your own multistage builds. So it consequently does not contain an application itself.

Please check out the example application for multistage builds on how to use that image and build containers efficiently.

There is also another sample app demonstrating a very simple single stage build.

Please be aware that your application needs an application layout without src folder which is proposed in fastapi-realworld-example-app. The application and test structure needs to be like that:

├── Dockerfile
├── app
│   ├── __init__.py
│   └── main.py
├── poetry.lock
├── pyproject.toml
└── tests
    ├── __init__.py
    ├── conftest.py
    └── test_api
        ├── __init__.py
        ├── test_items.py
        └── test_root.py

Please be aware that you need to provide a pyproject.toml file to specify your Python package dependencies for Poetry and configure dependencies like Pytest. Poetry dependencies must at least contain the following to work:

  • python = "^3.10"
  • gunicorn = "22.0.0"
  • uvicorn = "0.29.0"

If your application uses FastAPI framework this needs to be added as well:

  • fastapi = "0.110.2"

IMPORTANT: make sure you have a .dockerignore file in your application root which excludes your local virtual environment in .venv! Otherwise, you will have an issue activating that virtual environment when running the container.

Configuration

Configuration is done through the following environment variables during docker build. For all the following configuration options please see always the official Gunicorn documentation if you would like to do a deep dive. Following environment variables are supported:

LOG_LEVEL : The granularity of Error log outputs. Valid level names are:

  • debug
  • info
  • warning
  • error
  • critical

default: info

ACCESS_LOG : The Access log file to write to.

default: -

ERROR_LOG : The Error log file to write to.

default: -

WORKERS : The number of worker processes for handling requests. By default, this is set to one worker as this image is meant to be used on a production grade Kubernetes environment. There you have usually monitoring data exported to Prometheus which will not work properly with multiple workers.

default: 1

TIMEOUT : Workers silent for more than this many seconds are killed and restarted.

default: 30

GRACEFUL_TIMEOUT : Timeout for graceful workers restart.

default: 30

KEEP_ALIVE : The number of seconds to wait for requests on a Keep-Alive connection.

default: 2

WORKER_TMP_DIR : A directory to use for the worker heartbeat temporary file. By default, this is set to /dev/shm to speed up the startup of workers by using a in memory file system

default: /dev/shm

BIND : The socket to bind.

default: 0.0.0.0:8000