uvicorn gunicorn fastapi 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.8python3.8-slimpython3.7python3.9-alpine3.14python3.8-alpine3.10python3.7-alpine3.8python3.6python3.6-alpine3.8이 버전의 마지막 날짜 태그는 다음과 같습니다.
python3.8-2024-11-02python3.8-slim-2024-11-02python3.7-2024-11-02python3.9-alpine3.14-2024-03-11python3.8-alpine3.10-2024-01-29python3.7-alpine3.8-2024-03-11python3.6-2022-11-25python3.6-alpine3.8-2022-11-25 참고 : 각 빌드 날짜에 대한 태그가 있습니다. 사용하는 Docker 이미지 버전을 "고정"해야하는 경우 해당 태그 중 하나를 선택할 수 있습니다. 예를 들어 tiangolo/uvicorn-gunicorn-fastapi:python3.11-2024-11-02 .
성능 자동 조정을 갖춘 Python 의 고성능 Fastapi 웹 응용 프로그램을 위해 Gunicorn 이 관리하는 Uvicorn 의 Docker Image.
Github Repo : https://github.com/tiangolo/uvicorn-gunicorn-fastapi-docker
Docker Hub 이미지 : https://hub.docker.com/r/tiangolo/uvicorn-gunicorn-fastapi/
Fastapi는 Starlette 의 기반 및 구동 덕분에 타사 벤치 마크에서 측정 한 최고의 성능 중 하나를 가진 Python 웹 프레임 워크 인 것으로 나타났습니다.
달성 가능한 성능은 Go 및 Node.js 프레임 워크와 동등합니다.
이 이미지에는 사용 가능한 CPU 코어를 기반으로 다수의 작업자 프로세스를 시작하기위한 자동 조정 메커니즘이 포함되어 있습니다. 이렇게하면 코드를 추가하고 고성능을 자동으로 얻을 수 있습니다. 이는 간단한 배포 에 유용합니다.
아마도 Kubernetes 또는 유사한 도구를 사용하고있을 것입니다. 이 경우이 이미지 (또는 다른 유사한 기본 이미지 )가 필요하지 않을 것입니다. 컨테이너의 Fastapi 문서에 설명 된대로 Docker 이미지를 처음부터 구축하는 것이 좋습니다 - Docker : Fastapi의 Docker 이미지를 작성하십시오.
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에 대한 자세한 내용을 읽을 수 있습니다.
단일 컨테이너에 여러 명의 작업자를 갖고 싶다면 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-fastapi이 이미지는 희생하지 않고 실행중인 서버 (사용 가능한 CPU 코어 양)를 기반으로 현명한 구성을 설정합니다.
합리적인 기본값이 있지만 환경 변수로 구성하거나 구성 파일을 재정의 할 수 있습니다.
슬림 버전도 있습니다. 그 중 하나를 원한다면 위의 태그 중 하나를 사용하십시오.
tiangolo/uvicorn-gunicorn 이 이미지 ( tiangolo/uvicorn-gunicorn-fastapi )는 Tiangolo/Uvicorn-Gunicorn을 기반으로합니다.
그 이미지는 실제로 모든 작업을 수행하는 것입니다.
이 이미지는 Fastapi를 설치하고 Fastapi를 대상으로하는 문서가 있습니다.
Uvicorn, Gunicorn 및 Asgi에 대한 지식에 대해 자신감을 느낀다면 해당 이미지를 직접 사용할 수 있습니다.
tiangolo/uvicorn-gunicorn-starlette형제 도커 이미지가 있습니다 : tiangolo/uvicorn-gunicorn-starlette
새로운 Starlette 웹 응용 프로그램을 작성하고 Fastapi의 모든 추가 기능을 폐기하려면 Tiangolo/Uvicorn-Gunicorn-Starlette를 대신 사용해야합니다.
참고 : Fastapi는 Starlette를 기반으로하며 그 위에 여러 가지 기능을 추가합니다. API 및 기타 사례에 유용합니다 : 데이터 검증, 데이터 변환, OpenAPI를 통한 문서, 종속성 주입, 보안/인증 및 기타.
Github Repo를 복제 할 필요는 없습니다.
이 이미지를 다른 이미지의 기본 이미지로 사용할 수 있습니다.
파일 requirements.txt 있다고 가정하면 다음과 같은 Dockerfile 가질 수 있습니다.
FROM tiangolo/uvicorn-gunicorn-fastapi: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 의 파일입니다.
FastApi 응용 프로그램이 포함 된 가변 app 포함될 것으로 예상됩니다.
그런 다음 Dockerfile 이있는 디렉토리에서 이미지를 만들 수 있습니다.
docker build -t myimage ./Dockerfile 만듭니다. FROM tiangolo/uvicorn-gunicorn-fastapi:python3.11
COPY ./requirements.txt /app/requirements.txt
RUN pip install --no-cache-dir --upgrade -r /app/requirements.txt
COPY ./app /appapp 디렉토리를 만들고 입력하십시오.main.py 파일을 만듭니다. from fastapi import FastAPI
app = FastAPI ()
@ app . get ( "/" )
def read_root ():
return { "Hello" : "World" }
@ app . get ( "/items/{item_id}" )
def read_item ( item_id : int , q : str = None ):
return { "item_id" : item_id , "q" : q } .
├── app
│ └── main.py
└── Dockerfile
Dockerfile 이있는 위치, app 디렉토리가 포함 된 위치)로 이동하십시오.docker build -t myimage .docker run -d --name mycontainer -p 80:80 myimage이제 Docker 컨테이너에 최적화 된 Fastapi 서버가 있습니다. 현재 서버 (및 CPU 코어 수)에 대해 자동 조정.
예를 들어 http://192.168.99.100/items/5?q=somequery 또는 http://127.0.0.1/items/5?q=somequery (또는 Docker 호스트 사용)와 같은 Docker Container의 URL에서 확인할 수 있어야합니다.
당신은 다음과 같은 것을 볼 수 있습니다.
{ "item_id" : 5 , "q" : " somequery " }이제 http://192.168.99.100/docs 또는 http://127.0.0.1/docs (또는 Docker 호스트를 사용하여 동등한)로 이동할 수 있습니다.
자동 대화 형 API 문서 (Swagger UI에서 제공)를 볼 수 있습니다.
또한 Docker 호스트를 사용하여 http://192.168.99.100/redoc 또는 http://127.0.0.1/redoc(or 동등성)를 방문하십시오.
대체 자동 문서 (Redoc에서 제공)를 볼 수 있습니다.
아마도 앱에 대한 종속성을 추가하고 아마도 Uvicorn, Gunicorn 및 Fastapi를 포함한 특정 버전으로 고정하려고 할 것입니다.
이렇게하면 앱이 항상 예상대로 작동하도록 할 수 있습니다.
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-fastapi: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_NAMEFastapi 응용 프로그램이 포함 된 Python 모듈 내부의 변수.
기본적으로 :
app예를 들어, 기본 Python 파일이 다음과 같은 것이있는 경우
from fastapi import FastAPI
api = FastAPI ()
@ api . get ( "/" )
def read_root ():
return { "Hello" : "World" } 이 경우 api FASTAPI 응용 프로그램의 변수입니다. 당신은 다음과 같이 설정할 수 있습니다.
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 코어가있는 경우)가있는 경우 고성능이 필요하지 않다는 FASPAPI 응용 프로그램이 있습니다. 그리고 당신은 서버 리소스를 낭비하고 싶지 않습니다. 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와 같은 ASGI 프레임 워크를 사용할 수 있으며 이는 최대 성능을 제공하는 것입니다.
당신은 아마 그것을 바꾸지 말아야 할 것입니다.
그러나 어떤 이유로 든 대체 Uvicorn Worker ( uvicorn.workers.UvicornH11Worker )를 사용해야한다면이 환경 변수로 설정할 수 있습니다.
다음과 같이 설정할 수 있습니다.
docker run -d -p 80:8080 -e WORKER_CLASS= " uvicorn.workers.UvicornH11Worker " myimageTIMEOUT이 몇 초 동안 침묵하는 노동자들은 죽고 다시 시작됩니다.
Gunicorn Docs : Timeout에서 자세히 알아보십시오.
기본적으로 120 으로 설정하십시오.
Fastapi와 같은 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 버전을 사용해야합니다. ?
모든 이미지 태그, 구성, 환경 변수 및 응용 프로그램 옵션이 테스트됩니다.
--workers 와 함께 사용하십시오. @tiangolo의 PR #303.issue-manager.yml . @tiangolo의 PR #343.latest-changes GitHub 작업을 업데이트하십시오. @tiangolo의 PR #340.latest-changes.yml 업데이트하십시오. @alejsdev의 PR #276.README.md 에서 테스트 배지를 업데이트하십시오. @alejsdev의 PR #275.README.md 에서 테스트 배지를 업데이트하십시오. @alejsdev의 PR #274. 이 릴리스의 하이라이트 :
python3.6-2022-11-25 입니다.slim 버전을 추가하십시오. PR #40.WORKER_CLASSTIMEOUTKEEP_ALIVEGRACEFUL_TIMEOUTACCESS_LOGERROR_LOGGUNICORN_CMD_ARGSMAX_WORKERSPRE_START_PATH Env var에 대한 문서를 추가하십시오. PR #33.tiangolo/uvicorn-gunicorn-fastapi:python3.7-2019-10-15 와 같은 각 빌드 날짜에 대해 ENV VARS를 사용하고 이미지 태그를 추가하는 리팩터 테스트. PR #17./start-reload.sh 를 사용하여 라이브 자동 재로드에 대한 지원을 추가하고 업데이트 된 문서를 확인하십시오. PR #6 부모 이미지.WORKERS_PER_CORE 에서 1 성능을 보이는 것으로 나타났습니다.WEB_CONCURRENCY 설정되지 않았을 때 기본 웹 동시성을 최소 2 명의 작업자로 만드십시오. 이는 소규모 컴퓨터 (서버 머신/클라우드/등)에서 성능이 나쁘고 차단 응용 프로그램 (서버 응용 프로그램)을 피하는 것입니다. WEB_CONCURRENCY 사용하여이를 재정의 할 수 있습니다. 예를 들어 WORKERS_PER_CORE 가 1 (기본값)으로 설정되고 서버의 CPU 코어 만있는 경우에 적용됩니다. 부모 이미지에서 PR #6 및 PR #5./start.sh 독립적으로 실행하여 사용한 기본 환경 변수를 읽고 생성하십시오. /entrypoint.sh 는 시스템의 어떤 것도 수정하지 않고 환경 변수 만 읽습니다. PR #4 부모 이미지./app/prestart.sh 에 대한 지원을 추가하십시오. 이 프로젝트는 MIT 라이센스의 조건에 따라 라이센스가 부여됩니다.
