uwsgi nginx docker
2.1.0
Dockerfilepython3.12 , latest (dockerfile)python3.11 , (dockerfile)python3.10 , (dockerfile)python3.9 , (dockerfile) Эти теги больше не поддерживаются или поддерживаются, они удаляются из репозитория GitHub, но последние версии, выдвинутые, все равно могут быть доступны в Docker Hub, если кто -то их тянет:
python3.8python3.8-alpinepython3.7python3.6python2.7Последние теги даты для этих версий:
python3.8-2024-10-28python3.8-alpine-2024-03-11python3.7-2024-10-28python3.6-2022-11-25python2.7-2022-11-25 Примечание : есть теги для каждой даты сборки. Если вам нужно «прикрепить» версию изображения Docker, которую вы используете, вы можете выбрать один из этих тегов. Например, tiangolo/uwsgi-nginx:python3.12-2024-11-02 .
Docker Image с UWSGI и NGINX для веб -приложений в Python (в качестве колбы ) в одном контейнере.
Это изображение Docker позволяет создавать веб -приложения Python , которые работают с UWSGI и NGINX в одном контейнере.
Комбинация UWSGI с NGINX является распространенным способом развертывания веб -приложений Python, таких как Flask и Django. Он широко используется в отрасли и даст вам достойную производительность. (*)
Это изображение было создано как базовое изображение для Tiangolo/uwsgi-nginx-flask, но может использоваться в качестве базового изображения для любого другого (на основе WSGI) веб-приложения Python, таких как Django.
Если вы начинаете новый проект, вы можете извлечь выгоду из более новой и более высокой структуры, основанной на ASGI вместо WSGI (Flask и Django основаны на WSGI).
Вы можете использовать такую структуру ASGI, как:
FOSTAPI, или Starlette, даст вам около 800% (8x) производительность, достижимую с этим изображением ( Tiangolo/Uwsgi-Nginx ). Вы можете увидеть сторонние тесты здесь.
Кроме того, если вы хотите использовать новые технологии, такие как WebSockets, было бы проще (и возможно ) с более новой структурой, основанной на ASGI, таких как Fastapi или Starlette. Поскольку стандартный ASGI был разработан, чтобы иметь возможность обрабатывать асинхронный код, подобный тому, что необходимо для веб -билетов.
Если вам нужно использовать более старые рамки на основе WSGI, такую как Flask или Django (вместо чего-то, основанного на ASGI), и вам нужно иметь наилучшую возможную производительность, вы можете использовать альтернативное изображение: Tiangolo/Meinheld-Gunicorn .
Tiangolo/Meinheld-Gunicorn даст вам около 400% (4x) производительность этого изображения.
Github Repo : https://github.com/tiangolo/uwsgi-nginx-docker
Docker Hub Изображение : https://hub.docker.com/r/tiangolo/uwsgi-nginx/
Вы, вероятно, используете Kubernetes или подобные инструменты. В этом случае вам, вероятно, не нужно это изображение (или любое другое подобное базовое изображение ). Вам, вероятно, лучше построить изображение Docker с нуля .
Если у вас есть кластер машин с Kubernetes , Docker Swarm Mode, Nomad или другой аналогичной сложной системой для управления распределенными контейнерами на нескольких машинах, то вы, вероятно, захотите обрабатывать репликацию на уровне кластера вместо использования диспетчера процессов в каждом контейнере, который запускает несколько рабочих процессов , что делает это изображение Docker.
В этих случаях (например, использование Kubernetes) вы, вероятно, захотите построить изображение Docker с нуля , установить ваши зависимости и запустить один процесс вместо этого изображения.
Например, с помощью стреляющегося у вас может быть файловое app/gunicorn_conf.py с:
# Gunicorn config variables
loglevel = "info"
errorlog = "-" # stderr
accesslog = "-" # stdout
worker_tmp_dir = "/dev/shm"
graceful_timeout = 120
timeout = 120
keepalive = 5
threads = 3 И тогда у вас может быть Dockerfile с:
FROM python:3.9
WORKDIR /code
COPY ./requirements.txt /code/requirements.txt
RUN pip install --no-cache-dir --upgrade -r /code/requirements.txt
COPY ./app /code/app
CMD [ "gunicorn" , "--conf" , "app/gunicorn_conf.py" , "--bind" , "0.0.0.0:80" , "app.main:app" ]Вы можете прочитать больше об этих идеях в документации FastAPI о: FastAPI в контейнерах - Docker, так как те же идеи будут применяться к другим веб -приложениям в контейнерах.
Вы можете хотеть, чтобы диспетчер процессов запускал несколько рабочих процессов в контейнере, если ваше приложение достаточно простое , чтобы вам не нужно (по крайней мере, пока), чтобы точно настроить количество процессов слишком много, и вы можете просто использовать автоматизированный по умолчанию, и вы запускаете его на одном сервере , а не в кластере.
Вы можете развернуть на один сервер (не кластер) с Docker Compose , так что у вас не будет простого способа управления репликацией контейнеров (с Docker Compose) при сохранении общей сети и балансировки нагрузки .
Тогда вы могли бы захотеть иметь один контейнер с диспетчера процессов, запускающего несколько рабочих процессов внутри, как это делает это изображение Docker.
У вас также могут быть и другие причины , которые облегчат наличие одного контейнера с несколькими процессами вместо того, чтобы иметь несколько контейнеров с одним процессом в каждом из них.
Например (в зависимости от вашей настройки) у вас может быть какой -то инструмент, такой как экспортер Prometheus в том же контейнере, который должен иметь доступ к каждому из представленных запросов .
В этом случае, если бы у вас было несколько контейнеров , по умолчанию, когда Прометеус пришел к прочтению метрик , он каждый раз получал бы один для одного контейнера (для контейнера, который обрабатывал этот конкретный запрос) вместо получения накопленных метрик для всех реплицированных контейнеров.
Затем, в этом случае, может быть проще иметь один контейнер с несколькими процессами и локальный инструмент (например, экспортер Prometheus) на одном и том же контейнере, собирающем метрики Prometheus для всех внутренних процессов и выявляя эти метрики на этом единственном контейнере.
Узнайте больше об этом в документации FastAPI о: FastAPI в контейнерах - Docker, так как те же концепции применимы к другим веб -приложениям в контейнерах.
Вам не нужно клонировать это репо.
Вы можете использовать это изображение в качестве базового изображения для других изображений.
Предполагая, что у вас есть файл requirements.txt , у вас может быть Dockerfile как это:
FROM tiangolo/uwsgi-nginx:python3.12
COPY ./requirements.txt /app/requirements.txt
RUN pip install --no-cache-dir --upgrade -r /app/requirements.txt
COPY ./app /app
# Your Dockerfile code... По умолчанию он попытается найти файл конфигурации UWSGI в /app/uwsgi.ini .
Этот файл uwsgi.ini заставит его попытаться запустить файл Python в /app/main.py .
Если вы создаете веб-приложение Flask , вы должны использовать вместо этого Tiangolo/uwsgi-nginx-flask .
Если вам нужно использовать каталог для вашего приложения, отличного от /app , вы можете переопределить путь файла конфигурации UWSGI с помощью переменной среды UWSGI_INI и поместить там свой собственный файл uwsgi.ini .
Например, если вам нужно было иметь свой каталог приложений в /application вместо /app , ваш Dockerfile будет выглядеть как:
FROM tiangolo/uwsgi-nginx:python3.12
ENV UWSGI_INI /application/uwsgi.ini
COPY ./application /application
WORKDIR /appapplication И ваш файл uwsgi.ini в ./application/uwsgi.ini будет содержать:
[uwsgi]
wsgi-file =/application/main.py Примечание . Важно включить опцию WORKDIR , в противном случае UWSGI запустит приложение в /app .
По умолчанию изображение начинается с 2 -х процессов UWSGI. Когда сервер испытывает высокую нагрузку, он создает до 16 процессов UWSGI, чтобы справиться с ним по требованию.
Если вам нужно настроить эти номера, вы можете использовать переменные среды.
Начальное число процессов UWSGI контролируется переменной UWSGI_CHEAPER , по умолчанию, установленной 2 .
Максимальное количество процессов UWSGI контролируется переменной UWSGI_PROCESSES , по умолчанию, установленной 16 .
Имейте в виду, что UWSGI_CHEAPER должен быть ниже, чем UWSGI_PROCESSES .
Так, если, например, вам нужно начать с 4 процессов и вырасти до 64, ваш Dockerfile может выглядеть как:
FROM tiangolo/uwsgi-nginx:python3.12
ENV UWSGI_CHEAPER 4
ENV UWSGI_PROCESSES 64
COPY ./app /appНа этом изображении Nginx настроен, чтобы разрешить неограниченные размеры файлов загрузки. Это делается, потому что по умолчанию простой сервер Python позволит это, так что это самое простое поведение, которое ожидает разработчик.
Если вам необходимо ограничить максимальный размер загрузки в Nginx, вы можете добавить переменную среды NGINX_MAX_UPLOAD и назначить значение, соответствующее стандартному конфигурации Nginx client_max_body_size .
Например, если вы хотите установить максимальный размер файла загрузки на 1 МБ (по умолчанию в обычной установке NGINX), вам необходимо установить переменную среды NGINX_MAX_UPLOAD на значение 1m . Затем изображение позаботится о добавлении соответствующего файла конфигурации (это делается entrypoint.sh ).
Итак, ваш Dockerfile будет выглядеть как -то вроде:
FROM tiangolo/uwsgi-nginx:python3.12
ENV NGINX_MAX_UPLOAD 1m
COPY ./app /appПо умолчанию контейнер, изготовленный из этого изображения, будет прослушать в порту 80.
Чтобы изменить это поведение, установите переменную среды LISTEN_PORT .
Вам также может потребоваться создать соответствующую инструкцию EXPOSE .
Вы можете сделать это в своем Dockerfile , это будет выглядеть как:
FROM tiangolo/uwsgi-nginx:python3.12
ENV LISTEN_PORT 8080
EXPOSE 8080
COPY ./app /app/app/prestart.sh Если вам нужно что -либо запустить перед запуском приложения, вы можете добавить файл prestart.sh в Directory /app . Изображение автоматически обнаружит и запустит его перед началом всего.
Например, если вы хотите добавить миграции базы данных, которые запускаются при запуске (например, с Alembic или Django Migrations), перед запуском приложения вы можете создать файл ./app/prestart.sh в своем каталоге кода (который будет скопирован вашим Dockerfile ) с::
#! /usr/bin/env bash
# Let the DB start
sleep 10 ;
# Run migrations
alembic upgrade head И будет ждать 10 секунд, чтобы дать базе данных некоторое время для запуска, а затем запустить эту команду alembic (вы можете обновить ее для запуска миграций Django или любого другого инструмента, который вам нужен).
Если вам нужно запустить скрипт Python перед запуском приложения, вы можете сделать файл /app/prestart.sh запустить свой скрипт Python, с чем -то вроде:
#! /usr/bin/env bash
# Run custom Python script before starting
python /app/my_custom_prestart_script.py Примечание : изображение использует . Чтобы запустить сценарий (как в . /app/prestart.sh ), например, переменные среды сохранятся. Если вы не понимаете предыдущего предложения, вам, вероятно, не нужно.
По умолчанию Nginx запустит один «работник -процесс».
Если вы хотите установить другое количество рабочих процессов NGINX, вы можете использовать переменную среды NGINX_WORKER_PROCESSES .
Вы можете использовать определенный единственный номер, например:
ENV NGINX_WORKER_PROCESSES 2 Или вы можете установить его на ключевое слово auto , и оно попытается автоматически разместить количество доступных процессоров и использовать его для количества работников.
Например, используя auto , ваш DockerFile может выглядеть так:
FROM tiangolo/uwsgi-nginx:python3.12
ENV NGINX_WORKER_PROCESSES auto
COPY ./app /appПо умолчанию Nginx начнется с максимального предела 1024 соединений на одного работника.
Если вы хотите установить другой номер, вы можете использовать переменную среды NGINX_WORKER_CONNECTIONS , например:
ENV NGINX_WORKER_CONNECTIONS 2048Он не может превышать текущий предел на максимальном количестве открытых файлов. Посмотрите, как настроить его в следующем разделе.
Числовые подключения на работника Nginx не могут превышать предел максимального количества открытых файлов.
Вы можете изменить предел открытых файлов с переменной среды NGINX_WORKER_OPEN_FILES , например:
ENV NGINX_WORKER_OPEN_FILES 2048 Если вам нужно настраивать Nginx дальше, вы можете добавить *.conf файлы в /etc/nginx/conf.d/ в вашем Dockerfile .
Просто помните, что конфигурации по умолчанию создаются во время запуска в файле по адресу /etc/nginx/conf.d/nginx.conf и /etc/nginx/conf.d/upload.conf . Так что вы не должны перезаписать их. Вы должны назвать ваш *.conf -файл с чем -то другим, чем nginx.conf или upload.conf , например: custom.conf .
Примечание . Если вы настраиваете Nginx, возможно, копируете конфигурации из блога или ответ StackOverflow, имейте в виду, что вам, вероятно, необходимо использовать конфигурации, специфичные для UWSGI, а не для других модулей, например, ngx_http_fastcgi_module .
Если вам необходимо настройка Nginx еще дальше, полностью переопределите по умолчанию, вы можете добавить пользовательскую конфигурацию Nginx в /app/nginx.conf .
Он будет скопирован в /etc/nginx/nginx.conf и используется вместо сгенерированного.
Имейте в виду, что в этом случае это изображение не будет генерировать ни одну из конфигураций NGINX, оно только копирует и использует ваш файл конфигурации.
Это означает, что все переменные среды, описанные выше, специфичные для Nginx, не будут использоваться.
Это также означает, что он не будет использовать дополнительные конфигурации из файлов в /etc/nginx/conf.d/*.conf , если только у вас нет явно в разделе в своем пользовательском файле /app/nginx.conf с:
include /etc/nginx/conf.d/*.conf;
Если вы хотите добавить пользовательский файл /app/nginx.conf , но не знаете, с чего начать, вы можете использовать nginx.conf , используемый для тестов и настроить его или изменить его дальше.
Комбинация UWSGI с NGINX является распространенным способом развертывания веб -приложений Python.
Грубо:
Nginx - это веб -сервер, он заботится о подключениях HTTP, а также может обслуживать статические файлы напрямую и эффективнее.
UWSGI - это сервер приложений, это то, что запускает ваш код Python, и он разговаривает с Nginx.
Ваш код Python имеет фактическое веб -приложение и управляется UWSGI.
Это изображение использует преимущества уже тонких и оптимизированных существующих изображений Docker (на основе Debian, как рекомендовано Docker) и реализует лучшие практики Docker.
Он использует официальное изображение Python Docker, устанавливает UWSGI и, кроме того, с наименьшим количеством модификаций добавляет официальное изображение NGINX (по состоянию на 2016-02-14).
И он контролирует все эти процессы с помощью супервизирования.
Есть эмпирическое правило, которое у вас должно быть «один процесс на контейнер».
Это помогает, например, изолировать приложение и его базу данных в разных контейнерах.
Но если вы хотите иметь подход «микро-услуги», вы можете получить более одного процесса в одном контейнере, если они все связаны с одной и той же «службой», и вы можете включить код Flask, UWSGI и Nginx в одном и том же контейнере (и, возможно, запустите другой контейнер в базу данных).
Это подход, принятый на этом изображении.
Это изображение имеет пример примера по умолчанию «Hello World» в каталоге контейнера /app используя пример в документации UWSGI.
Вы, вероятно, хотите переопределить его или удалить в своем проекте.
Это там, если вы запускаете это изображение самостоятельно, а не как базовое изображение для своего собственного Dockerfile , так что вы получаете образец приложения без ошибок.
Короче говоря: вы, вероятно, не должны использовать Alpine для проектов Python, вместо этого использовать версии изображения slim Docker.
Вы хотите больше подробностей? Продолжить чтение?
Alpine более полезен для других языков, где вы строите статический двоичный файл на одной стадии изображения Docker (используя многоэтапное здание Docker), а затем копируете его на простое альпийское изображение, а затем просто выполнить этот двоичный. Например, используя GO.
Но для Python, поскольку Alpine не использует стандартное инструменты, используемое для построения расширений Python, при установке пакетов во многих случаях Python ( pip ) не найдет предварительно скомпилированный пакет («колесо») для альпийского. И после отладки множество странных ошибок вы поймете, что вам нужно установить много дополнительных инструментов и создать много зависимостей, чтобы использовать некоторые из этих общих пакетов Python. ?
Это означает, что, хотя исходное альпийское изображение могло быть небольшим, вы получите изображение с размером, сравнимым с размером, который вы бы получили, если бы только использовали стандартное изображение Python (на основе Debian) или в некоторых случаях еще больше. ?
И во всех этих случаях, для строительства, потребления гораздо большего количества ресурсов потребуется гораздо больше времени, потребление гораздо больше ресурсов, дольше строить зависимости, а также увеличить его углеродный след, поскольку вы используете больше времени и энергии процессора для каждой сборки. ?
Если вам нужны стройные изображения Python, вам следует вместо этого попытаться использовать slim версии, которые все еще основаны на Debian, но меньше. ?
Все теги изображения, конфигурации, переменные среды и параметры приложения протестированы.
Обновления объявлены в выпусках.
Вы можете нажать кнопку «Смотреть» в правом верхнем углу и выбрать «Только релизы», чтобы получить уведомление по электронной почте, когда есть новый релиз.
*.pyc -файлов с помощью PYTHONDONTWRITEBYTECODE=1 и убедитесь, что журналы напечатаны немедленно с помощью PYTHONUNBUFFERED=1 . PR #208 от @estebanx64. EXPOSE порты 80 и 443 по умолчанию, поскольку их можно настроить. PR #227 от @tiangolo. issue-manager.yml . PR #226 от @tiangolo.latest-changes действие GitHub. PR #214 от @tiangolo.latest-changes.yml . PR #201 от @alejsdev.README.md . PR #199 от @alejsdev. Основные моменты этого выпуска:
python3.6-2022-11-25 и python2.7-2022-11-25 .2.0.20 . PR #127 от @tiangolo.1.17.10 , на основе последних Debian, Buster. PR #82.2020-05-04 .2019-10-14:
2019-09-28:
tiangolo/uwsgi-nginx:python3.7-2019-09-28 . PR #65.Обновить Трэвис. PR #60.
/app/prestart.sh для запуска произвольного кода перед запуском приложения (например, миграции Alembic - SQLalchemy). Документация для /app/prestart.sh находится в главном чтении. PR #59.2019-05-04:
2019-02-02:
/app/nginx.conf , который переопределяет сгенерированный. PR #51.2018-11-23: новые изображения Alpine 3.8 для Python 2.7, Python 3.6 и Python 3.7 (Python 3.7 временно отключен). Спасибо Philippfreyer в PR #45
2018-09-22: новые версии Python 3.7, стандартные и альпийские на основе. Спасибо Desaintmartin в этом PR.
2018-06-22: теперь вы можете использовать NGINX_WORKER_CONNECTIONS , чтобы установить максимальное количество подключений NGINX Worker и NGINX_WORKER_OPEN_FILES , чтобы установить максимальное количество открытых файлов. Спасибо Ронлуту в этом PR.
2018-06-22: Make Uwsgi требует запуска приложения, а не в «полном динамическом режиме», пока была ошибка. Superissord не прекращает себя, но пытается перезапустить UWSGI и показывает ошибки. Использует need-app , как предложено Luckydonald в этом комментарии.
2018-06-22: правильно обработано изящное отключение UWSGI и Nginx. Спасибо Desaintmartin в этом PR.
2018-02-04: теперь можно установить количество рабочих процессов NGINX с переменной среды NGINX_WORKER_PROCESSES . Спасибо Naktinis в этом PR.
2018-01-14: В настоящее время существуют две версии на основе альпийцев, python2.7-alpine3.7 и python3.6-alpine3.7 .
2017-12-08: Теперь вы можете настроить, какой порт должен прослушать контейнер, используя переменную среды LISTEN_PORT благодаря TMSHN в этом PR.
2017-08-09: Вы можете установить пользовательский максимальный размер файла загрузки, используя переменную среды NGINX_MAX_UPLOAD , по умолчанию он имеет значение 0 , которое позволяет неограниченное размеры файлов загрузки. Это отличается от значения дефолта Nginx 1 МБ. Это настроено таким образом, потому что это самый простой опыт, который ожидает разработчик, который не является экспертом в Nginx.
2017-08-09: Теперь вы можете переопределить, где искать файл uwsgi.ini , и с помощью этого измените каталог по умолчанию от /app на что-то другое, используя переменную среды UWSGI_INI .
2017-08-08: есть новое latest изображение тега, просто чтобы показать предупреждение для тех, кто все еще использует latest для веб-приложений Python 2.7. На данный момент каждый должен использовать Python 3.
2017-08-08: Superissord теперь завершает Uwsgi на SIGTERM , поэтому, если вы запустите docker stop или что-то подобное, он фактически остановит все, вместо того, чтобы ждать тайм-аут Docker, чтобы убить контейнер.
2017-07-31: теперь есть тег изображения для Python 3.6, основанный на официальном изображении для Python 3.6 благодаря JRD в этом PR.
2016-10-01: Теперь вы можете переопределить параметры uwsgi.ini по умолчанию из файла в /app/uwsgi.ini .
2016-08-16: теперь есть тег изображения для Python 3.5, основанный на официальном изображении для Python 3.5. Итак, теперь вы можете использовать это изображение для своих проектов в Python 2.7 и Python 3.5.
2016-08-16: используйте динамику ряд рабочих процессов для UWSGI, от 2 до 16 в зависимости от нагрузки. Это должно работать для большинства случаев. Это помогает, особенно когда есть некоторые ответы, которые являются медленными и требуют некоторого времени, чтобы быть сгенерированным, это изменение позволяет всем другим ответам сохранять быстрые (в новом процессе), не ожидая первого (медленного) одного, чтобы закончить.
Кроме того, теперь он использует базовый файл uwsgi.ini в /etc/uwsgi/ с большинством общих конфигураций, поэтому uwsgi.ini внутри /app (то, что вам может потребоваться модифицировать) теперь намного проще.
2016-04-05: журналы NGINX и UWSGI теперь перенаправляются на Stdout, что позволяет использовать docker logs .
Этот проект лицензирован в соответствии с условиями лицензии Apache.
