uvicorn gunicorn docker
0.8.0
이 도커 이미지는 이제 더 이상 사용되지 않습니다. 그것을 사용할 필요가 없으며 --workers 과 함께 Uvicorn을 사용할 수 있습니다.
아래에서 자세히 알아보십시오.
Dockerfile 링크python3.11 , latest (Dockerfile)python3.10 , (Dockerfile)python3.9 , (Dockerfile)python3.11-slim (dockerfile)python3.10-slim (dockerfile)python3.9-slim (dockerfile) 이 태그는 더 이상 지원되거나 유지되지 않으며 GitHub 리포지토리에서 제거됩니다. 그러나 누가 푸시 된 마지막 버전은 누구든지 꺼내면 여전히 사용할 수 있습니다.
python3.9-alpine3.14python3.8python3.8-slimpython3.8-alpine3.10python3.7python3.7-alpine3.8python3.6python3.6-alpine3.8이 버전의 마지막 날짜 태그는 다음과 같습니다.
python3.9-alpine3.14-2024-03-11python3.8-2024-11-02python3.8-slim-2024-11-02python3.8-alpine3.10-2024-03-11python3.7-2024-11-02python3.7-alpine3.8-2024-03-11python3.6-2022-11-25python3.6-alpine3.8-2022-11-25 참고 : 각 빌드 날짜에 대한 태그가 있습니다. 사용하는 Docker 이미지 버전을 "고정"해야하는 경우 해당 태그 중 하나를 선택할 수 있습니다. 예를 들어 tiangolo/uvicorn-gunicorn:python3.11-2024-11-02 .
Python 에서 고성능 웹 애플리케이션을 위해 Gunicorn이 관리하는 Uvicorn 의 Docker Image는 성능 자동 튜닝을 사용합니다.
Github Repo : https://github.com/tiangolo/uvicorn-gunicorn-docker
Docker Hub 이미지 : https://hub.docker.com/r/tiangolo/uvicorn-gunicorn/
Uvicorn 으로 실행되는 Python Web Application (Python Asynchronous Web Applications의 "ASGI"사양 사용)은 타사 벤치 마크에서 측정 한 최상의 성능을 가지고있는 것으로 나타났습니다.
달성 가능한 성능은 Go 및 Node.js 프레임 워크와 동등합니다.
이 이미지에는 사용 가능한 CPU 코어를 기반으로 다수의 작업자 프로세스를 시작하기위한 자동 조정 메커니즘이 포함되어 있습니다. 이렇게하면 코드를 추가하고 고성능을 자동으로 얻을 수 있습니다. 이는 간단한 배포 에 유용합니다.
아마도 Kubernetes 또는 유사한 도구를 사용하고있을 것입니다. 이 경우이 이미지 (또는 다른 유사한 기본 이미지 )가 필요하지 않을 것입니다. 컨테이너의 Fastapi의 문서에서 설명한대로 Docker 이미지를 처음부터 구축하는 것이 좋습니다 - Docker : Fastapi의 Docker 이미지를 구축하십시오. 동일한 프로세스와 아이디어가 다른 ASGI 프레임 워크에 적용될 수 있습니다.
Kubernetes , Docker Swarm Mode, Nomad 또는 기타 유사한 복잡한 시스템이있는 기계 클러스터가있는 경우 여러 기계에서 분산 컨테이너를 관리하기위한 기타 유사한 복잡한 시스템이있는 경우 각 컨테이너에서 프로세스 관리자 (Uvicorn Workers가 포함 된 Gunicorn과 같은)를 사용하는 대신 클러스터 레벨 에서 복제를 처리 하려고합니다.
이러한 경우 (예 : Kubernetes 사용) Docker Image를 처음부터 처음부터 구축하고 종속성을 설치 하며이 이미지 대신 단일 Uvicorn 프로세스를 실행하는 것이 좋습니다.
예를 들어, 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 [ "uvicorn" , "app.main:app" , "--host" , "0.0.0.0" , "--port" , "80" ]이에 대한 자세한 내용은 다음과 같은 Fastapi 문서에서 다음과 같은 자세한 내용을 읽을 수 있습니다. 컨테이너의 Fastapi -Docker는 다른 ASGI 프레임 워크에 적용되는 것과 동일한 아이디어와 적용됩니다.
단일 컨테이너에 여러 명의 작업자를 갖고 싶다면 Uvicorn은 이제 죽은자를 다시 시작하는 것을 포함하여 하위 프로세스 처리를 지원합니다. 따라서 Gunicorn이 단일 컨테이너에서 여러 작업자를 관리 할 필요가 없습니다.
위에서 Dockerfile 예제를 수정하여 --workers 옵션을 Uvicorn에 다음과 같이 추가 할 수 있습니다.
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 [ "uvicorn" , "app.main:app" , "--host" , "0.0.0.0" , "--port" , "80" , "--workers" , "4" ]그게 당신이 필요한 전부입니다. 이 도커 이미지가 필요하지 않습니다. ?
Docker와의 배포에 대한 Fastapi 문서에서 자세한 내용을 읽을 수 있습니다.
Uvicorn은 죽은 노동자 재시작을 포함하여 근로자 처리 관리를 지원하지 않았습니다. 그러나 지금은 그렇습니다.
그 전에 Gunicorn은 Uvicorn 근로자를 운영하는 프로세스 관리자로 사용될 수 있습니다. 더 이상 필요하지 않은 복잡성이 추가되었습니다.
이 문서의 나머지 부분은 역사적 이유로 유지되지만 아마도 필요하지 않을 것입니다. ?
tiangolo/uvicorn-gunicorn이 이미지는 희생하지 않고 실행중인 서버 (사용 가능한 CPU 코어 양)를 기반으로 현명한 구성을 설정합니다.
합리적인 기본값이 있지만 환경 변수로 구성하거나 구성 파일을 재정의 할 수 있습니다.
슬림 버전도 있습니다. 그 중 하나를 원한다면 위의 태그 중 하나를 사용하십시오.
이 이미지는 다음의 기본 이미지로 만들어졌습니다.
그러나 ASGI 사양을 사용하는 Python 웹 응용 프로그램을 실행하기 위해 기본 이미지로 사용될 수 있습니다.
새로운 Starlette 웹 응용 프로그램을 작성하는 경우 대신 Tiangolo/Uvicorn-Gunicorn-Starlette를 사용해야합니다.
새로운 Fastapi 웹 응용 프로그램을 작성하는 경우 Tiangolo/Uvicorn-Gunicorn-Fastapi를 대신 사용해야합니다.
참고 : Fastapi는 Starlette를 기반으로하며 그 위에 여러 가지 기능을 추가합니다. API 및 기타 사례에 유용합니다 : 데이터 검증, 데이터 변환, OpenAPI를 통한 문서, 종속성 주입, 보안/인증 및 기타.
참고 : 기술적으로보다 진보 된 일을하지 않으면 Tiangolo/Uvicorn-Gunicorn-Starlette 와 함께 Starlette를 사용하거나 Tiangolo/Uvicorn-Gunicorn-Fastapi 와 함께 Fastapi를 사용해야합니다.
Github Repo를 복제 할 필요는 없습니다.
이 이미지를 다른 이미지의 기본 이미지로 사용할 수 있습니다.
파일 requirements.txt 있다고 가정하면 다음과 같은 Dockerfile 가질 수 있습니다.
FROM tiangolo/uvicorn-gunicorn:python3.11
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 의 파일입니다.
"ASGI"응용 프로그램이 포함 된 가변 app 포함될 것으로 예상됩니다.
그런 다음 Dockerfile 이있는 디렉토리에서 이미지를 만들 수 있습니다.
docker build -t myimage ./docker run -d --name mycontainer -p 80:80 myimage예를 들어 http://192.168.99.100/ 또는 http://127.0.0.1/ (또는 Docker 호스트를 사용하여)와 같은 Docker Container의 URL에서 확인할 수 있어야합니다.
또한 앱에 의존성을 추가하고 아마도 Uvicorn과 Gunicorn을 포함한 특정 버전으로 고정하려고 할 것입니다.
이렇게하면 앱이 항상 예상대로 작동하도록 할 수 있습니다.
Dockerfile 에 pip 명령이 포함 된 패키지, requirements.txt 또는시를 사용하여 패키지를 설치할 수 있습니다.
그런 다음 해당 종속성을 제어 된 방식으로 업그레이드하고 테스트를 실행하고 모든 것이 작동하는지 확인하지만 새로운 버전이 호환되지 않으면 생산 응용 프로그램을 중단하지 않아도됩니다.
다음은 각 패키지에 대한 고정 버전이 있는지 확인하기 위해 종속성을 설치할 수있는 방법 중 하나의 작은 예입니다.
시와 함께 관리되는 프로젝트가 있다고 가정 해 봅시다. 따라서 파일 pyproject.toml 에 패키지 종속성이 있다고 가정 해 봅시다. 그리고 아마도 파일 poetry.lock .
그런 다음 Docker Multi-Stage 건물을 사용하여 Dockerfile 가질 수 있습니다.
FROM python:3.9 as requirements-stage
WORKDIR /tmp
RUN pip install poetry
COPY ./pyproject.toml ./poetry.lock* /tmp/
RUN poetry export -f requirements.txt --output requirements.txt --without-hashes
FROM tiangolo/uvicorn-gunicorn:python3.11
COPY --from=requirements-stage /tmp/requirements.txt /app/requirements.txt
RUN pip install --no-cache-dir --upgrade -r /app/requirements.txt
COPY ./app /app그것은 :
./poetry.lock* ( * 로 끝나는)를 사용하기 때문에 해당 파일을 아직 사용할 수없는 경우 충돌하지 않습니다.종속성을 설치 한 후 앱 코드를 복사하는 것이 중요합니다. 따라서 Docker의 캐시를 활용할 수 있습니다. 이렇게하면 새로운 종속성을 추가 할 때만 응용 프로그램 파일을 업데이트 할 때마다 처음부터 모든 것을 설치할 필요가 없습니다.
이는 종속성을 설치하는 데 사용하는 다른 방법에도 적용됩니다. requirements.txt 사용하는 경우 TXT를 단독으로 복사하고 Dockerfile 상단에 모든 종속성을 설치 한 다음 앱 코드를 추가하십시오.
컨테이너에서 설정하여 기본값을 구성 할 수있는 환경 변수입니다.
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_NAMEASGI 애플리케이션이 포함 된 파이썬 모듈 내부의 변수.
기본적으로 :
app예를 들어, 기본 Python 파일이 다음과 같은 것이있는 경우
from fastapi import FastAPI
api = FastAPI ()
@ api . get ( "/" )
def read_root ():
return { "message" : "Hello world!" } 이 경우 api "ASGI 응용 프로그램"의 변수입니다. 당신은 다음과 같이 설정할 수 있습니다.
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 " myimage이 이미지의 구성 파일을 귀하의 시작점으로 사용할 수 있습니다.
WORKERS_PER_CORE이 이미지는 컨테이너를 실행하는 현재 서버에서 사용할 수있는 CPU 코어 수를 확인합니다.
근로자 수를이 값을 곱한 CPU 코어 수로 설정합니다.
기본적으로 :
1다음과 같이 설정할 수 있습니다.
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 개의 작업자 프로세스 만 시작할 수 있습니다.
참고 : 기본적으로 WORKERS_PER_CORE 가 1 이고 서버에 1 개의 단일 작업자를 시작하는 대신 1 개의 CPU 코어 만있는 경우 2가 시작됩니다. 이는 소규모 기계 (서버 시스템/클라우드 등)에서 성능이 나쁘고 응용 프로그램 차단 (서버 응용 프로그램)을 피하는 것입니다. WEB_CONCURRENCY 사용하여이를 재정의 할 수 있습니다.
MAX_WORKERS사용할 최대 근로자 수를 설정하십시오.
이미지가 작업자 수를 자동으로 계산할 수 있지만 최대로 제한 될 수 있습니다.
예를 들어, 각 작업자가 데이터베이스 연결을 사용하고 데이터베이스에 최대 개방형 연결 한계가있는 경우 유용 할 수 있습니다.
기본적으로 설정되지 않으므로 무제한이라는 의미입니다.
다음과 같이 설정할 수 있습니다.
docker run -d -p 80:80 -e MAX_WORKERS= " 24 " myimage이렇게하면 서버에서 사용할 수있는 CPU 코어 수와 무관하게 이미지가 최대 24 명의 작업자를 시작하게됩니다.
WEB_CONCURRENCY근로자 수의 자동 정의를 무시하십시오.
기본적으로 :
WORKERS_PER_CORE 를 곱하십시오. 따라서 2 개의 코어가있는 서버에서는 기본적으로 2 로 설정됩니다.다음과 같이 설정할 수 있습니다.
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 " myimageWORKER_CLASS이 수업은 Gunicorn이 노동자들을 위해 사용합니다.
기본적으로 uvicorn.workers.UvicornWorker 로 설정하십시오.
Uvicorn을 사용한다는 사실은 Fastapi 및 Starlette와 같은 ASGI 애플리케이션을 사용할 수 있으며 이는 최대 성능을 제공하는 것입니다.
당신은 아마 그것을 바꾸지 말아야 할 것입니다.
그러나 어떤 이유로 든 대체 Uvicorn Worker ( uvicorn.workers.UvicornH11Worker )를 사용해야한다면이 환경 변수로 설정할 수 있습니다.
다음과 같이 설정할 수 있습니다.
docker run -d -p 80:8080 -e WORKER_CLASS= " uvicorn.workers.UvicornH11Worker " myimageTIMEOUT이 몇 초 동안 침묵하는 노동자들은 죽고 다시 시작됩니다.
Gunicorn Docs : Timeout에서 자세히 알아보십시오.
기본적으로 120 으로 설정하십시오.
Fastapi 및 Starlette와 같은 Uvicorn 및 Asgi 프레임 워크는 동기화가 아니라 비동기입니다. 따라서 동기화 작업자보다 시간 초과가 더 높은 것이 안전 할 것입니다.
다음과 같이 설정할 수 있습니다.
docker run -d -p 80:8080 -e TIMEOUT= " 20 " myimageKEEP_ALIVE유지 보수 연결에서 요청을 기다리는 데 몇 초입니다.
Gunicorn Docs : Keepalive에서 자세히 알아보십시오.
기본적으로 2 로 설정하십시오.
다음과 같이 설정할 수 있습니다.
docker run -d -p 80:8080 -e KEEP_ALIVE= " 20 " myimageGRACEFUL_TIMEOUT우아한 근로자를위한 시간 초과가 다시 시작됩니다.
Gunicorn Docs : Graceful-Timeout에서 자세한 내용을 읽으십시오.
기본적으로 120 으로 설정하십시오.
다음과 같이 설정할 수 있습니다.
docker run -d -p 80:8080 -e GRACEFUL_TIMEOUT= " 20 " myimageACCESS_LOG쓸 수있는 액세스 로그 파일.
기본적으로 "-" 는 stdout (docker logs에서 인쇄)을 의미합니다.
ACCESS_LOG 비활성화하려면 빈 값으로 설정하십시오.
예를 들어, 다음과 같이 비활성화 할 수 있습니다.
docker run -d -p 80:8080 -e ACCESS_LOG= myimageERROR_LOG쓸 오류 로그 파일.
기본적으로 "-" , 이것은 stderr (docker logs에서 인쇄)을 의미합니다.
ERROR_LOG 비활성화하려면 빈 값으로 설정하십시오.
예를 들어, 다음과 같이 비활성화 할 수 있습니다.
docker run -d -p 80:8080 -e ERROR_LOG= myimageGUNICORN_CMD_ARGS Gunicorn의 추가 명령 줄 설정은 GUNICORN_CMD_ARGS 환경 변수에서 전달할 수 있습니다.
Gunicorn Docs : 설정에서 자세히 알아보십시오.
이러한 설정은 다른 환경 변수와 모든 Gunicorn 구성 파일보다 우선합니다.
예를 들어, 사용하려는 사용자 정의 TLS/SSL 인증서가있는 경우 Docker 이미지에 복사하거나 컨테이너에 마운트 한 후 파일의 위치에 --keyfile 및 --certfile 설정할 수 있습니다.
docker run -d -p 80:8080 -e GUNICORN_CMD_ARGS= " --keyfile=/secrets/key.pem --certfile=/secrets/cert.pem " -e PORT=443 myimage참고 : TLS/SSL을 직접 처리하고 컨테이너에서 구성하는 대신 Traefik과 같은 "TLS 종단 프록시"를 사용하는 것이 좋습니다. HTTPS에 대한 Fastapi 문서에서 자세한 내용을 읽을 수 있습니다.
PRE_START_PATH사전 스타트 스크립트를 찾을 수있는 경로.
기본적으로 /app/prestart.sh 로 설정하십시오.
다음과 같이 설정할 수 있습니다.
docker run -d -p 80:8080 -e PRE_START_PATH= " /custom/script.sh " myimage 이미지에는 /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 위에서 설명한 환경 변수 PRE_START_PATH 로 Prestart 스크립트의 위치를 사용자 정의 할 수 있습니다.
실행되는 기본 프로그램은 /start.sh 에 있습니다. 위에서 설명한 모든 작업을 수행합니다.
Live Auto Reload를 사용하여 개발하기위한 버전도 다음과 같습니다.
/start-reload.sh개발을 위해서는 컨테이너 내부의 응용 프로그램 코드의 내용을 Docker "호스트 볼륨"으로 마운트하여 매번 이미지를 작성하지 않고도 코드를 변경하고 실시간으로 테스트 할 수있는 것이 유용합니다.
이 경우 라이브 자동 재로드로 서버를 실행하는 것이 유용하여 모든 코드 변경마다 자동으로 다시 시작되도록 유용합니다.
추가 스크립트 /start-reload.sh Uvicorn만으로 (Gunicorn없이) 단일 프로세스로 실행됩니다.
개발에 이상적입니다.
예를 들어, 실행하는 대신 :
docker run -d -p 80:80 myimage당신은 달릴 수 있습니다 :
docker run -d -p 80:80 -v $( pwd ) :/app myimage /start-reload.sh-v $(pwd):/app : 디렉토리 $(pwd) 는 /app 컨테이너 내부에 볼륨으로 장착되어야 함을 의미합니다.$(pwd) : pwd ( "인쇄 작업 디렉토리")를 실행하고 문자열의 일부로 넣습니다./start-reload.sh : 명령 끝에 무언가 ( /start-reload.sh )를 추가하면 기본 "명령"을 이로 대체합니다. 이 경우 기본 ( /start.sh )을 개발 대안 /start-reload.sh 로 대체합니다. /start-reload.sh 는 Gunicorn으로 실행되지 않으므로 gunicorn_conf.py 파일에 넣은 구성이 적용되지 않습니다.
그러나 이러한 환경 변수는 위에서 설명한 것과 동일하게 작동합니다.
MODULE_NAMEVARIABLE_NAMEAPP_MODULEHOSTPORTLOG_LEVEL 요컨대 : 아마도 Python 프로젝트에 Alpine을 사용해서는 안되며 slim Docker Image 버전을 사용하십시오.
자세한 내용을 원하십니까? 계속 읽기?
Alpine은 One Docker 이미지 단계 (다중 단계 Docker Building 사용)에서 정적 바이너리를 구축 한 다음 간단한 알파인 이미지로 복사 한 다음 해당 바이너리를 실행하는 다른 언어에 더 유용합니다. 예를 들어, GO를 사용합니다.
그러나 Python의 경우 Alpine이 Python Extensions를 구축하는 데 사용되는 표준 툴링을 사용하지 않기 때문에 패키지를 설치할 때 많은 경우 Python ( pip )은 Alpine에 대한 사전 컴파일 된 설치 가능한 패키지 ( "휠")를 찾을 수 없습니다. 그리고 이상한 이상한 오류를 디버깅 한 후에는 이러한 일반적인 Python 패키지 중 일부를 사용하기 위해 많은 추가 툴링을 설치하고 많은 종속성을 구축해야한다는 것을 알게 될 것입니다. ?
이것은 원래의 알파인 이미지가 작았지만 표준 파이썬 이미지 (데비안 기반)를 사용했거나 경우에 따라 더 큰 크기와 비슷한 크기의 크기를 가진 이미지로 끝납니다. ?
그리고 이러한 모든 경우에, 구축하는 데 훨씬 더 오래 걸리고, 더 많은 자원을 소비하고, 더 오래 의존성을 구축하고, 각 빌드에 더 많은 CPU 시간과 에너지를 사용함에 따라 탄소 발자국을 늘릴 수 있습니다. ?
슬림 한 파이썬 이미지를 원한다면 대신 데비안을 기반으로하지만 더 작은 slim 버전을 사용해야합니다. ?
모든 이미지 태그, 구성, 환경 변수 및 응용 프로그램 옵션이 테스트됩니다.
*.pyc 파일을 PYTHONDONTWRITEBYTECODE=1 으로 생성하지 말고 PYTHONUNBUFFERED=1 으로 로그가 즉시 인쇄되는지 확인하십시오. @estebanx64의 Pr #192. 80 과 443 기본적으로 사용자 정의 할 수 있으므로 EXPOSE 하지 않습니다. @tiangolo의 PR #238. --workers 와 함께 사용하십시오. @tiangolo의 PR #225. issue-manager.yml . @tiangolo의 PR #237.latest-changes GitHub 작업을 업데이트하십시오. @tiangolo의 PR #236.latest-changes.yml 업데이트하십시오. Pr #198의 @alejsdev.arm64 (예 : Mac M1)에 대한 지원을 포함하여 Multi-Arch 빌드에 대한 지원을 추가하십시오. @tiangolo의 PR #195. README.md 에서 테스트 배지를 업데이트하십시오. Pr #197의 @alejsdev. 이 릴리스의 하이라이트는 다음과 같습니다.
python3.6-2022-11-25 입니다.slim 버전을 추가하십시오. PR #40.WORKER_CLASSTIMEOUTKEEP_ALIVEGRACEFUL_TIMEOUTACCESS_LOGERROR_LOGGUNICORN_CMD_ARGSMAX_WORKERS--no-cache-dir 로 설치하는 동안 pip 캐시를 비활성화합니다. @PMAV99의 PR #13.PRE_START_PATH Env var에 대한 테스트 및 문서 추가. PR #30.PRE_START_PATH Env var에 대한 지원을 추가하십시오. @mgfinch의 PR #12.tiangolo/uvicorn-gunicorn:python3.7-2019-10-15 와 같은 각 빌드 날짜에 대해 ENV VARS를 사용하고 이미지 태그를 추가하기위한 Refactor 테스트. PR #15./dev/shm 로 업데이트하십시오. @wshayes의 PR #9./start-reload.sh 를 사용하여 라이브 자동 재로드에 대한 지원을 추가하고 업데이트 된 문서를 확인하십시오. PR #6.WORKERS_PER_CORE 에서 1 성능을 보이는 것으로 나타났습니다.WEB_CONCURRENCY 설정되지 않았을 때 기본 웹 동시성을 최소 2 명의 작업자로 만드십시오. 이는 소규모 컴퓨터 (서버 머신/클라우드/등)에서 성능이 나쁘고 차단 응용 프로그램 (서버 응용 프로그램)을 피하는 것입니다. WEB_CONCURRENCY 사용하여이를 재정의 할 수 있습니다. 예를 들어 WORKERS_PER_CORE 가 1 (기본값)으로 설정되고 서버의 CPU 코어 만있는 경우에 적용됩니다. PR #5./start.sh 독립적으로 실행하여 사용한 기본 환경 변수를 읽고 생성하십시오. /entrypoint.sh 는 시스템의 어떤 것도 수정하지 않고 환경 변수 만 읽습니다. PR #4./app/prestart.sh 에 대한 지원을 추가하십시오. 이 프로젝트는 MIT 라이센스의 조건에 따라 라이센스가 부여됩니다.
