meinheld gunicorn flask docker
0.5.0
Dockerfile 링크python3.9 , latest (Dockerfile) 이 태그는 더 이상 지원되거나 유지되지 않으며 GitHub 리포지토리에서 제거됩니다. 그러나 누가 푸시 된 마지막 버전은 누구든지 꺼내면 여전히 사용할 수 있습니다.
python3.9-alpine3.13python3.8python3.8-alpine3.11python3.7python3.7-alpine3.8python3.6python3.6-alpine3.8python2.7이 버전의 마지막 날짜 태그는 다음과 같습니다.
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 참고 : 각 빌드 날짜에 대한 태그가 있습니다. 사용하는 Docker 이미지 버전을 "고정"해야하는 경우 해당 태그 중 하나를 선택할 수 있습니다. 예를 들어 tiangolo/meinheld-gunicorn-flask:python3.9-2024-11-02 .
성능 자동 조정과 함께 파이썬을 사용하여 Flask 에서 고성능 웹 응용 프로그램을 위해 Gunicorn 이 관리하는 MeinHeld 의 Docker Image.
Github Repo : https://github.com/tiangolo/meinheld-gunicorn-flask-docker
Docker Hub 이미지 : https://hub.docker.com/r/tiangolo/meinheld-gunicorn-flask/
Gunicorn이 제어하는 MeinHeld 로 실행되는 Python Flask 웹 응용 프로그램은 Flask (*)에서 달성 할 수있는 최고의 성능을 가지고 있습니다.
플라스크에 이미 기존 애플리케이션이 있거나 새 응용 프로그램을 구축하는 경우이 이미지는 최상의 성능 (또는 그에 가깝게)을 제공합니다.
이 이미지에는 "자동 조정"메커니즘이 포함되어 있으므로 코드를 추가하고 자동으로 우수한 성능을 얻을 수 있습니다. 그리고 희생을하지 않고 (벌목과 같은).
현재 출시 된 MeinHeld의 최신 버전은 2020 년 5 월 17 일부터 1.0.2입니다.이 버전의 MeinHeld는 Python 3.10 및 3.11과 호환되지 않는 이전 버전의 Greenlet ( >=0.4.5,<0.5 )가 필요합니다. 그렇기 때문에이 이미지에서 지원되는 최신 버전의 Python은 Python 3.9입니다.
새로운 프로젝트를 시작하는 경우 Fastapi (Flask 및 Django와 같은 WSGI 대신 ASGI를 기반으로)와 Tiangolo/Uvicorn-Gunicorn-Fastapi 와 같은 Docker 이미지와 같은 새롭고 빠른 프레임 워크의 혜택을 누릴 수 있습니다.
이 이미지를 사용할 때에도 플라스크로 달성 할 수있는 성능을 약 200% 제공합니다.
또한 Websockets와 같은 새로운 기술을 사용하려면 Fastapi 와 같은 ASGI를 기반으로하는 새로운 프레임 워크를 사용하면 더 쉬울 것입니다. 표준 ASGI는 WebSockets에 필요한 것과 같은 비동기 코드를 처리 할 수 있도록 설계되었습니다.
MeinHeld 는 고성능 WSGI 호환 웹 서버입니다.
Gunicorn을 사용하여 MeinHeld를 관리하고 여러 프로세스를 실행할 수 있습니다.
Flask는 Werkzeug, Jinja 2 및 좋은 의도를 기반으로하는 Python의 마이크로 프레임 워크입니다.
이 이미지는 Tiangolo/UWSGI-Nginx-Flask 의 대안으로 만들어졌으며,이 이미지의 성능을 약 400% 제공합니다.
보다 일반적인 이미지 Tiangolo/Meinheld-Gunicorn을 기반으로합니다. 그것이 Django와 같은 다른 WSGI 프레임 워크에 사용할 것입니다.
아마도 Kubernetes 또는 유사한 도구를 사용하고있을 것입니다. 이 경우이 이미지 (또는 다른 유사한 기본 이미지 )가 필요하지 않을 것입니다. Docker 이미지를 처음부터 구축하는 것이 좋습니다.
Kubernetes , Docker Swarm Mode, Nomad 또는 기타 유사한 복잡한 시스템이있는 기계 클러스터가있는 경우 여러 시스템에서 분산 된 컨테이너를 관리하기위한 기타 유사한 복잡한 시스템이있는 경우 여러 작업자 프로세스를 시작하는 각 컨테이너의 프로세스 관리자를 사용하는 대신 클러스터 레벨 에서 복제를 처리 하려는 경우이 Docker 이미지가하는 것입니다.
이러한 경우 (예 : Kubernetes 사용) Docker 이미지를 처음부터 처음부터 구축하고 종속성을 설치 하고이 이미지 대신 단일 프로세스를 실행하고 싶을 것입니다.
예를 들어, Gunicorn을 사용하면 파일 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 Exporter와 같은 도구를 가질 수 있습니다.
이 경우, 기본적으로 여러 컨테이너 가있는 경우, Prometheus가 메트릭을 읽게 되었을 때, 모든 복제 된 컨테이너에 대한 축적 된 메트릭을 얻는 대신 매번 단일 컨테이너 (특정 요청을 처리 한 컨테이너)에 대한 컨테이너를 얻을 수 있습니다.
이 경우 여러 프로세스가 있는 컨테이너 하나 와 동일한 컨테이너에 로컬 도구 (예 : Prometheus Exporter)가 모든 내부 프로세스에 대해 Prometheus 메트릭을 수집하고 해당 단일 컨테이너에 해당 메트릭을 노출시키는 것이 더 간단 할 수 있습니다.
Fastapi 문서에 대한 자세한 내용은 다음과 같습니다. 컨테이너의 Fastapi -Docker, 동일한 개념이 컨테이너의 다른 웹 애플리케이션에 적용되므로.
이 저장소를 복제 할 필요는 없습니다.
이 이미지를 다른 이미지의 기본 이미지로 사용할 수 있습니다.
파일 requirements.txt 있다고 가정하면 다음과 같은 Dockerfile 가질 수 있습니다.
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 /app/app/main.py 의 파일이 예상됩니다.
또는 그렇지 않으면 /app/main.py 의 파일입니다.
"WSGI"응용 프로그램이 포함 된 가변 app 포함될 것으로 예상됩니다.
그런 다음 Dockerfile 이있는 디렉토리에서 이미지를 만들 수 있습니다.
docker build -t myimage ./컨테이너에서 설정하여 기본값을 구성 할 수있는 환경 변수입니다.
MODULE_NAMEPython "Module"(파일)은 Gunicorn에 의해 가져 오기 위해이 모듈에는 변수의 실제 플라스크 응용 프로그램이 포함됩니다.
기본적으로 :
app.main 파일 /app/app/main.py 또는main 파일 /app/main.py 가있는 경우 예를 들어, 기본 파일이 /app/custom_app/custom_main.py 에있는 경우 다음과 같이 설정할 수 있습니다.
docker run -d -p 80:80 -e MODULE_NAME= " custom_app.custom_main " myimageVARIABLE_NAME플라스크 애플리케이션이 포함 된 파이썬 모듈 내부의 변수.
기본적으로 :
app예를 들어, 기본 Python 파일이 다음과 같은 것이있는 경우
from flask import Flask
api = Flask ( __name__ )
@ api . route ( "/" )
def hello ():
return "Hello World from Flask" 이 경우 api "플라스크 응용 프로그램"의 변수입니다. 당신은 다음과 같이 설정할 수 있습니다.
docker run -d -p 80:80 -e VARIABLE_NAME= " api " myimageAPP_MODULE파이썬 모듈이있는 문자열과 변수 이름이 Gunicorn으로 전달되었습니다.
기본적으로 변수 MODULE_NAME 및 VARIABLE_NAME 을 기반으로 설정합니다.
app.main:app 또는main:app다음과 같이 설정할 수 있습니다.
docker run -d -p 80:80 -e APP_MODULE= " custom_app.custom_main:api " myimageGUNICORN_CONFGunicorn Python 구성 파일의 경로.
기본적으로 :
/app/gunicorn_conf.py 존재하는 경우/app/app/gunicorn_conf.py 존재하는 경우/gunicorn_conf.py (포함 기본값)다음과 같이 설정할 수 있습니다.
docker run -d -p 80:80 -e GUNICORN_CONF= " /app/custom_gunicorn_conf.py " myimageWORKERS_PER_CORE이 이미지는 컨테이너를 실행하는 현재 서버에서 사용할 수있는 CPU 코어 수를 확인합니다.
근로자 수를이 값을 곱한 CPU 코어 수로 설정합니다.
기본적으로 :
2다음과 같이 설정할 수 있습니다.
docker run -d -p 80:80 -e WORKERS_PER_CORE= " 3 " myimage 2 개의 CPU 코어가있는 서버에서 값 3 사용하면 6 개의 작업자 프로세스가 실행됩니다.
부동 소수점 값도 사용할 수 있습니다.
예를 들어, 여러 응용 프로그램을 실행하는 큰 서버 (8 CPU 코어가있는 경우)가있는 경우 고성능이 필요하지 않다는 ASGI 응용 프로그램이 있습니다. 그리고 당신은 서버 리소스를 낭비하고 싶지 않습니다. CPU 코어 당 0.5 작업자를 사용할 수 있습니다. 예를 들어:
docker run -d -p 80:80 -e WORKERS_PER_CORE= " 0.5 " myimage8 개의 CPU 코어가있는 서버에서는 4 개의 작업자 프로세스 만 시작할 수 있습니다.
WEB_CONCURRENCY근로자 수의 자동 정의를 무시하십시오.
기본적으로 :
WORKERS_PER_CORE 를 곱하십시오. 따라서 2 개의 코어가있는 서버에서는 기본적으로 4 로 설정됩니다.다음과 같이 설정할 수 있습니다.
docker run -d -p 80:80 -e WEB_CONCURRENCY= " 2 " myimage이렇게하면 서버에서 사용할 수있는 CPU 코어 수와 무관하게 이미지가 2 개의 작업자 프로세스를 시작하게됩니다.
HOSTGunicorn이 사용하는 "호스트"는 Gunicorn이 요청을 듣는 IP입니다.
컨테이너 내부의 호스트입니다.
예를 들어이 변수를 127.0.0.1 로 설정하면 호스트가 아닌 컨테이너 내부에서만 사용할 수 있습니다.
완전성을 위해 제공되지만 아마도 변경해서는 안됩니다.
기본적으로 :
0.0.0.0PORT컨테이너 포트는 들어야합니다.
제한적인 환경에서 컨테이너를 실행하는 경우 특정 포트 ( 8080 )를 사용하도록 강요하는 경우이 변수로 설정할 수 있습니다.
기본적으로 :
80다음과 같이 설정할 수 있습니다.
docker run -d -p 80:8080 -e PORT= " 8080 " myimageBIND실제 호스트와 항구는 Gunicorn으로 전달되었습니다.
기본적으로 변수 HOST 및 PORT 기반으로 설정하십시오.
따라서 아무것도 변경하지 않으면 기본적으로 다음으로 설정됩니다.
0.0.0.0:80다음과 같이 설정할 수 있습니다.
docker run -d -p 80:8080 -e BIND= " 0.0.0.0:8080 " myimageLOG_LEVELGunicorn의 로그 레벨.
중 하나 :
debuginfowarningerrorcritical 기본적으로 info 로 설정하십시오.
더 많은 성능 희생 벌 로깅을 짜야하는 경우 warning 로 설정하십시오.
다음과 같이 설정할 수 있습니다.
docker run -d -p 80:8080 -e LOG_LEVEL= " warning " myimage 로그는 컨테이너의 stderr 및 stdout 으로 전송됩니다. 즉 docker logs -f your_container_name_here 명령으로 로그를 볼 수 있습니다.
이미지에는 /gunicorn_conf.py 의 기본 Gunicorn Python 구성 파일이 포함되어 있습니다.
위에서 선언 한 환경 변수를 사용하여 모든 구성을 설정합니다.
다음에 파일을 포함시켜 재정의 할 수 있습니다.
/app/gunicorn_conf.py/app/app/gunicorn_conf.py/gunicorn_conf.py/app/prestart.sh 앱을 시작하기 전에 무엇이든 실행 해야하는 경우 prestart.sh 를 디렉토리 /app 에 추가 할 수 있습니다. 이미지는 모든 것을 시작하기 전에 자동으로 감지하고 실행합니다.
예를 들어, Alembic SQL 마이그레이션 (SQLALCHEMY 포함)을 추가하려면 코드 디렉토리에 ./app/prestart.sh 파일을 생성 할 수 있습니다 ( Dockerfile 에서 복사 할).
#! /usr/bin/env bash
# Let the DB start
sleep 10 ;
# Run migrations
alembic upgrade head 그리고 데이터베이스에 일정 시간을주기 위해 10 초를 기다렸다가 alembic 명령을 실행할 수 있습니다.
앱을 시작하기 전에 Python 스크립트를 실행 해야하는 경우 /app/prestart.sh 파일을 다음과 같이 Python 스크립트를 실행할 수 있습니다.
#! /usr/bin/env bash
# Run custom Python script before starting
python /app/my_custom_prestart_script.py 요컨대 : 아마도 Python 프로젝트에 Alpine을 사용해서는 안되며 slim Docker Image 버전을 사용하십시오.
자세한 내용을 원하십니까? 계속 읽기?
Alpine은 One Docker 이미지 단계 (다중 단계 Docker Building 사용)에서 정적 바이너리를 구축 한 다음 간단한 알파인 이미지로 복사 한 다음 해당 바이너리를 실행하는 다른 언어에 더 유용합니다. 예를 들어, GO를 사용합니다.
그러나 Python의 경우 Alpine이 Python Extensions를 구축하는 데 사용되는 표준 툴링을 사용하지 않기 때문에 패키지를 설치할 때 많은 경우 Python ( pip )은 Alpine에 대한 사전 컴파일 된 설치 가능한 패키지 ( "휠")를 찾을 수 없습니다. 그리고 이상한 이상한 오류를 디버깅 한 후에는 이러한 일반적인 Python 패키지 중 일부를 사용하기 위해 많은 추가 툴링을 설치하고 많은 종속성을 구축해야한다는 것을 알게 될 것입니다. ?
이것은 원래의 알파인 이미지가 작았지만 표준 파이썬 이미지 (데비안 기반)를 사용했거나 경우에 따라 더 큰 크기와 비슷한 크기의 크기를 가진 이미지로 끝납니다. ?
그리고 이러한 모든 경우에, 구축하는 데 훨씬 더 오래 걸리고, 더 많은 자원을 소비하고, 더 오래 의존성을 구축하고, 각 빌드에 더 많은 CPU 시간과 에너지를 사용함에 따라 탄소 발자국을 늘릴 수 있습니다. ?
슬림 한 파이썬 이미지를 원한다면 대신 데비안을 기반으로하지만 더 작은 slim 버전을 사용해야합니다. ?
모든 이미지 태그, 구성, 환경 변수 및 응용 프로그램 옵션이 테스트됩니다.
issue-manager.yml . @tiangolo의 PR #154.latest-changes GitHub 작업을 업데이트하십시오. @tiangolo의 PR #153.latest-changes.yml 업데이트하십시오. @alejsdev의 PR #141.README.md 에서 테스트 배지를 업데이트하십시오. @alejsdev의 PR #137. 이 릴리스의 하이라이트 :
Python 3.9 및 3.8에 대한 지원.
파이썬 3.6 및 2.7의 감가 상각.
python3.6-2022-11-25 및 python2.7-2022-11-25 입니다.모든 종속성의 업그레이드 된 버전.
작은 개선 및 수정.
Python 3.9 및 Python 3.9 Alpine에 대한 지원을 추가하십시오. @tiangolo의 PR #50.
알파인 3.11로 파이썬 3.8을 추가하십시오. PR #28.
Python 3.8에 대한 지원을 추가하십시오. PR #27.
tiangolo/meinheld-gunicorn-flask:python3.7-2019-10-15 와 같은 각 빌드 날짜에 대해 ENV VARS를 사용하고 이미지 태그를 추가하는 리팩터 테스트. PR #17.Python 2.7에 대한 지원을 추가하십시오 (Python 3.7 또는 Python 3.6을 사용해야 함). PR #11.
Travis CI 구성을 업데이트하십시오. @cclauss의 PR #10.
/app/prestart.sh 에 대한 지원을 추가하십시오. 이 프로젝트는 MIT 라이센스의 조건에 따라 라이센스가 부여됩니다.
