meinheld gunicorn flask docker
0.5.0
Dockerfilepython3.9 , latest (Dockerfile) Essas tags não são mais suportadas ou mantidas, elas são removidas do repositório do GitHub, mas as últimas versões pressionadas ainda podem estar disponíveis no Docker Hub se alguém os estiver puxando:
python3.9-alpine3.13python3.8python3.8-alpine3.11python3.7python3.7-alpine3.8python3.6python3.6-alpine3.8python2.7As tags de última data para essas versões são:
python3.9-alpine3.13-2024-03-11python3.8-2024-10-28python3.8-alpine3.11-2024-03-11python3.7-2024-10-28python3.7-alpine3.8-2024-03-11python3.6-2022-11-25python3.6-alpine3.8-2022-11-25python2.7-2022-11-25 Nota : Existem tags para cada data de construção. Se você precisar "fixar" a versão da imagem do Docker que você usa, poderá selecionar uma dessas tags. Por exemplo tiangolo/meinheld-gunicorn-flask:python3.9-2024-11-02 .
Imagem do Docker com Meinheld gerenciado pela Gunicorn para aplicativos da Web de alto desempenho em Flask usando Python com ajuste automático de desempenho.
Github Repo : https://github.com/tiangolo/meinheld-gunicorn-flask-docker
Docker Hub Imagem : https://hub.docker.com/r/tiangolo/meinheld-gunicorn-flask/
Aplicativos da Web do Python Flask em execução com Meinheld controlados pela Gunicorn têm algumas das melhores performances alcançáveis pelo Flask (*).
Se você já possui um aplicativo já existente no Flask ou está construindo um novo, esta imagem fornecerá o melhor desempenho possível (ou próximo a isso).
Esta imagem possui um mecanismo de "ajuste automático" incluído, para que você possa adicionar seu código e obter um bom desempenho automaticamente. E sem fazer sacrifícios (como registro).
A versão mais recente do Meinheld lançada é 1.0.2, a partir de 17 de maio de 2020. Esta versão de Meinheld requer uma versão antiga de Greenlet ( >=0.4.5,<0.5 ) que não é compatível com Python 3.10 e 3.11. É por isso que a versão mais recente do Python suportada nesta imagem é o Python 3.9.
Se você estiver iniciando um novo projeto, poderá se beneficiar de uma estrutura mais recente e mais rápida, como o FASTAPI (baseado no ASGI em vez de WSGI como Flask e Django) e uma imagem do Docker como Tiangolo/Uvicorn-Gunicorn-Fastapi .
Isso daria a você cerca de 200% o desempenho alcançável com o Flask, mesmo ao usar essa imagem.
Além disso, se você deseja usar novas tecnologias como o WebSockets, seria mais fácil com uma estrutura mais recente baseada no ASGI, como o FASTAPI . Como o ASGI padrão foi projetado para poder lidar com o código assíncrono como o necessário para o WebSockets.
Meinheld é um servidor web compatível com WSGI de alto desempenho.
Você pode usar o Gunicorn para gerenciar o MeInheld e executar vários processos dele.
O Flask é um microframework para Python baseado em Werkzeug, Jinja 2 e boas intenções.
Esta imagem foi criada para ser uma alternativa ao F-flask Tiangolo/UWSGI-NGINX , fornecendo cerca de 400% o desempenho dessa imagem.
É baseado na imagem mais genérica Tiangolo/Meinheld-Gunicorn . Esse é o que você usaria para outras estruturas do WSGI, como o Django.
Você provavelmente está usando Kubernetes ou ferramentas semelhantes. Nesse caso, você provavelmente não precisa desta imagem (ou de qualquer outra imagem base semelhante ). Você provavelmente é melhor construir uma imagem do Docker a partir do zero .
Se você possui um cluster de máquinas com Kubernetes , modo de enxame do Docker, Nomad ou outro sistema complexo semelhante para gerenciar contêineres distribuídos em várias máquinas, provavelmente desejará lidar com a replicação no nível do cluster, em vez de usar um gerenciador de processos em cada contêiner que inicie os processos de vários trabalhadores , o que é a imagem do Docker.
Nesses casos (por exemplo, usando Kubernetes), você provavelmente gostaria de criar uma imagem do Docker a partir do zero , instalando suas dependências e executando um único processo em vez dessa imagem.
Por exemplo, usando o Gunicorn, você pode ter um app/gunicorn_conf.py com:
# Gunicorn config variables
loglevel = "info"
errorlog = "-" # stderr
accesslog = "-" # stdout
worker_tmp_dir = "/dev/shm"
graceful_timeout = 120
timeout = 120
keepalive = 5
threads = 3 E então você pode ter um Dockerfile com:
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" ]Você pode ler mais sobre essas idéias na documentação do FASTAPI sobre: FASTAPI em contêineres - Docker, pois as mesmas idéias se aplicariam a outros aplicativos da Web em contêineres.
Você pode querer um gerenciador de processos executando vários processos de trabalhador no contêiner se o seu aplicativo for simples o suficiente para que você não precise (pelo menos ainda não) para ajustar muito o número de processos e você pode usar um padrão automatizado e está executando-o em um único servidor , não em um cluster.
Você pode estar implantando para um único servidor (não um cluster) com o Docker Compose , para não ter uma maneira fácil de gerenciar a replicação de contêineres (com o Docker Compose) enquanto preservava a rede compartilhada e o balanceamento de carga .
Em seguida, você pode querer ter um único contêiner com um gerenciador de processos iniciando vários processos de trabalhador dentro, como essa imagem do Docker.
Você também pode ter outros motivos que facilitariam a ter um único contêiner com vários processos, em vez de ter vários contêineres com um único processo em cada um deles.
Por exemplo (dependendo da sua configuração), você pode ter alguma ferramenta, como um exportador do Prometheus no mesmo contêiner que deve ter acesso a cada uma das solicitações que vêm.
Nesse caso, se você tivesse vários contêineres , por padrão, quando o Prometheus chegasse a ler as métricas , ele receberia um único contêiner de cada vez (para o contêiner que lidava com essa solicitação específica), em vez de obter as métricas acumuladas para todos os contêineres replicados.
Então, nesse caso, pode ser mais simples ter um contêiner com vários processos e uma ferramenta local (por exemplo, um exportador de Prometheus) no mesmo contêiner coletando métricas de Prometheus para todos os processos internos e expondo essas métricas nesse contêiner único.
Leia mais sobre tudo na documentação do FASTAPI sobre: FASTAPI em contêineres - Docker, pois os mesmos conceitos se aplicam a outros aplicativos da Web em contêineres.
Você não precisa clonar este repo.
Você pode usar esta imagem como uma imagem base para outras imagens.
Supondo que você tenha um arquivo requirements.txt , você pode ter um Dockerfile como este:
FROM tiangolo/meinheld-gunicorn-flask:python3.9
COPY ./requirements.txt /app/requirements.txt
RUN pip install --no-cache-dir --upgrade -r /app/requirements.txt
COPY ./app /app Ele espera um arquivo em /app/app/main.py .
Ou caso contrário, um arquivo em /app/main.py .
E esperará que ele contenha um app variável com seu aplicativo "WSGI".
Em seguida, você pode criar sua imagem a partir do diretório que possui seu Dockerfile , por exemplo:
docker build -t myimage ./Essas são as variáveis de ambiente que você pode definir no contêiner para configurá -lo e seus valores padrão:
MODULE_NAMEO "módulo" do Python (arquivo) a ser importado pelo Gunicorn, este módulo conteria o aplicativo de frasco real em uma variável.
Por padrão:
app.main se houver um arquivo /app/app/main.py oumain se houver um arquivo /app/main.py Por exemplo, se o seu arquivo principal estivesse em /app/custom_app/custom_main.py , você pode defini -lo como:
docker run -d -p 80:80 -e MODULE_NAME= " custom_app.custom_main " myimageVARIABLE_NAMEA variável dentro do módulo Python que contém o aplicativo de frasco.
Por padrão:
appPor exemplo, se o seu principal arquivo python tiver algo como:
from flask import Flask
api = Flask ( __name__ )
@ api . route ( "/" )
def hello ():
return "Hello World from Flask" Nesse caso, api seria a variável com o "aplicativo de frasco". Você pode definir como:
docker run -d -p 80:80 -e VARIABLE_NAME= " api " myimageAPP_MODULEA corda com o módulo Python e o nome da variável passou para o Gunicorn.
Por padrão, configurado com base no variável MODULE_NAME e VARIABLE_NAME :
app.main:app oumain:appVocê pode definir como:
docker run -d -p 80:80 -e APP_MODULE= " custom_app.custom_main:api " myimageGUNICORN_CONFO caminho para um arquivo de configuração do Gunicorn Python.
Por padrão:
/app/gunicorn_conf.py se existir/app/app/gunicorn_conf.py se existir/gunicorn_conf.py (o padrão incluído)Você pode definir como:
docker run -d -p 80:80 -e GUNICORN_CONF= " /app/custom_gunicorn_conf.py " myimageWORKERS_PER_COREEsta imagem verificará quantos núcleos da CPU estão disponíveis no servidor atual executando seu contêiner.
Ele definirá o número de trabalhadores para o número de núcleos da CPU multiplicados por esse valor.
Por padrão:
2Você pode definir como:
docker run -d -p 80:80 -e WORKERS_PER_CORE= " 3 " myimage Se você usou o valor 3 em um servidor com 2 núcleos de CPU, ele executaria 6 processos de trabalhadores.
Você também pode usar valores de ponto flutuante.
Por exemplo, se você tiver um servidor grande (digamos, com 8 núcleos de CPU) executando vários aplicativos e terá um aplicativo ASGI que você sabe que não precisará de alto desempenho. E você não deseja desperdiçar recursos do servidor. Você pode fazê -lo usar 0.5 trabalhadores por núcleo da CPU. Por exemplo:
docker run -d -p 80:80 -e WORKERS_PER_CORE= " 0.5 " myimageEm um servidor com 8 núcleos de CPU, isso o tornaria iniciado apenas 4 processos de trabalhadores.
WEB_CONCURRENCYSubstituir a definição automática de número de trabalhadores.
Por padrão:
WORKERS_PER_CORE . Portanto, em um servidor com 2 núcleos, por padrão, ele será definido como 4 .Você pode definir como:
docker run -d -p 80:80 -e WEB_CONCURRENCY= " 2 " myimageIsso tornaria a imagem iniciar 2 processos trabalhadores, independentemente de quantos núcleos de CPU estão disponíveis no servidor.
HOSTO "host" usado pelo Gunicorn, o IP onde o Gunicorn ouvirá solicitações.
É o host dentro do contêiner.
Por exemplo, se você definir essa variável para 127.0.0.1 , ela estará disponível apenas dentro do contêiner, não no host que o executa.
É fornecido para a integridade, mas você provavelmente não deve alterá -lo.
Por padrão:
0.0.0.0PORTA porta que o contêiner deve ouvir.
Se você estiver executando seu contêiner em um ambiente restritivo que o obriga a usar alguma porta específica (como 8080 ), poderá defini -lo com essa variável.
Por padrão:
80Você pode definir como:
docker run -d -p 80:8080 -e PORT= " 8080 " myimageBINDO anfitrião e o porto reais passaram para o Gunicorn.
Por padrão, definido com base HOST e PORT variáveis.
Então, se você não mudou nada, ele será definido por padrão como:
0.0.0.0:80Você pode definir como:
docker run -d -p 80:8080 -e BIND= " 0.0.0.0:8080 " myimageLOG_LEVELO nível de log para Gunicorn.
Um de:
debuginfowarningerrorcritical Por padrão, defina como info .
Se você precisar espremer mais desempenho sacrificando o registro, defina -o como warning , por exemplo:
Você pode definir como:
docker run -d -p 80:8080 -e LOG_LEVEL= " warning " myimage Os logs são enviados para o stderr e stdout do contêiner, o que significa que você pode visualizar os logs com o comando docker logs -f your_container_name_here .
A imagem inclui um arquivo de configuração Python padrão do Gunicorn em /gunicorn_conf.py .
Ele usa as variáveis de ambiente declaradas acima para definir todas as configurações.
Você pode substituí -lo incluindo um arquivo em:
/app/gunicorn_conf.py/app/app/gunicorn_conf.py/gunicorn_conf.py/app/prestart.sh Se você precisar executar qualquer coisa antes de iniciar o aplicativo, poderá adicionar um arquivo prestart.sh ao diretório /app . A imagem será detectada e executada automaticamente antes de iniciar tudo.
Por exemplo, se você deseja adicionar migrações SQL Alembic (com sqlalchemy), pode criar um arquivo ./app/prestart.sh no seu diretório de código (que será copiado pelo seu Dockerfile ) com:
#! /usr/bin/env bash
# Let the DB start
sleep 10 ;
# Run migrations
alembic upgrade head E esperaria 10 segundos para dar ao banco de dados algum tempo para iniciar e, em seguida, executar esse comando alembic .
Se você precisar executar um script python antes de iniciar o aplicativo, você pode fazer com que o arquivo /app/prestart.sh execute seu script python, com algo como:
#! /usr/bin/env bash
# Run custom Python script before starting
python /app/my_custom_prestart_script.py Em resumo: você provavelmente não deve usar o Alpine para projetos Python, em vez disso, use as versões slim de imagem do Docker.
Você quer mais detalhes? Continuar lendo?
O Alpine é mais útil para outros idiomas em que você constrói um binário estático em um estágio de imagem de um docker (usando o edifício do Docker de vários estágios) e copie-o para uma imagem alpina simples e, em seguida, execute esse binário. Por exemplo, usando Go.
Mas para o Python, pois a alpina não usa as ferramentas padrão usadas para criar extensões de python, ao instalar pacotes, em muitos casos Python ( pip ) não encontrará um pacote instalável pré -compilado (uma "roda") para alpina. E depois de depurar muitos erros estranhos, você perceberá que precisa instalar muitas ferramentas extras e criar muitas dependências apenas para usar alguns desses pacotes comuns de Python. ?
Isso significa que, embora a imagem alpina original possa ter sido pequena, você acaba com uma imagem com um tamanho comparável ao tamanho que você teria obtido se tivesse acabado de usar uma imagem Python padrão (baseada no Debian) ou em alguns casos ainda maior. ?
E em todos esses casos, levará muito mais tempo para construir, consumindo muito mais recursos, construindo dependências por mais tempo e também aumentando sua pegada de carbono, pois você está usando mais tempo e energia da CPU para cada construção. ?
Se você deseja imagens finas de Python, tente usar as versões slim que ainda são baseadas no Debian, mas são menores. ?
Todas as tags de imagem, configurações, variáveis de ambiente e opções de aplicativos são testadas.
issue-manager.yml . Pr #154 por @tiangolo.latest-changes . Pr #153 por @tiangolo.latest-changes.yml . PR #141 Por @alejsdev.README.md . Pr #137 por @alejsdev. Destaques deste lançamento:
Suporte para Python 3.9 e 3.8.
Deprecação do Python 3.6 e 2.7.
python3.6-2022-11-25 e python2.7-2022-11-25 .Versões atualizadas de todas as dependências.
Pequenas melhorias e correções.
Adicione suporte ao Python 3.9 e Python 3.9 Alpine. Pr #50 por @tiangolo.
Adicione o Python 3.8 com o alpino 3.11. PR #28.
Adicione suporte ao Python 3.8. PR #27.
tiangolo/meinheld-gunicorn-flask:python3.7-2019-10-15 . PR #17.Adicione suporte ao Python 2.7 (você deve usar o Python 3.7 ou o Python 3.6). Pr #11.
Atualize a configuração do Travis CI. Pr #10 por @cclauss.
/app/prestart.sh . Este projeto está licenciado nos termos da licença do MIT.
