uwsgi nginx flask docker
2.1.0
Dockerfile 링크python3.12 , latest (Dockerfile)python3.11 , (Dockerfile)python3.10 (Dockerfile)python3.9 , (Dockerfile) 이 태그는 더 이상 지원되거나 유지되지 않으며 GitHub 리포지토리에서 제거됩니다. 그러나 누가 푸시 된 마지막 버전은 누구든지 꺼내면 여전히 사용할 수 있습니다.
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-flask:python3.7-2019-10-14 .
단일 컨테이너에서 실행되는 파이썬 의 Flask 웹 응용 프로그램에 대한 UWSGI 및 NGINX를 사용한 Docker 이미지.
이 Docker 이미지를 사용하면 단일 컨테이너에서 UWSGI 및 NGINX 와 함께 실행되는 파이썬 으로 플라스크 웹 응용 프로그램을 만들 수 있습니다.
UWSGI와 NGINX의 조합은 Python Flask 웹 응용 프로그램을 배포하는 일반적인 방법입니다.
새로운 프로젝트를 시작한다면, 내가 만든 Fastapi 와 내가 지금 대부분의 시간을 보내는 곳을 시도하고 싶을 것입니다. 또한 사용자 정의 기본 이미지가 필요하지 않으며 문서에는 자신의 Dockerfile 구축하는 지침이 있습니다.
Github Repo : https://github.com/tiangolo/uwsgi-nginx-flask-docker
Docker Hub 이미지 : https://hub.docker.com/r/tiangolo/uwsgi-nginx-flask/
아마도 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.12
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/uwsgi-nginx-flask:python3.12
COPY ./requirements.txt /app/requirements.txt
RUN pip install --no-cache-dir --upgrade -r /app/requirements.txt
COPY ./app /app사용 가능한 몇 가지 이미지 태그가 있지만 새로운 프로젝트의 경우 사용 가능한 최신 버전을 사용해야합니다.
이 도커 이미지는 Tiangolo/UWSGI-Nginx 를 기반으로합니다. 그 도커 이미지에는 동일한 컨테이너에 UWSGI 및 NGINX가 설치되어 있으며이 이미지의 기초로 만들어졌습니다.
Dockerfile 만듭니다. FROM tiangolo/uwsgi-nginx-flask:python3.12
COPY ./app /appapp 디렉토리를 만들고 입력하십시오main.py 파일을 만듭니다 app from flask import Flask
app = Flask ( __name__ )
@ app . route ( "/" )
def hello ():
return "Hello World from Flask"
if __name__ == "__main__" :
# Only for debugging while developing
app . run ( host = '0.0.0.0' , debug = True , port = 80 ) 기본 응용 프로그램 객체는이 예제에서와 같이 app (코드)으로 명명되어야합니다.
참고 : main() 함수가있는 섹션은 디버깅 목적입니다. 자세한 내용은 아래 고급 지침을 읽으십시오.
.
├── app
│ └── main.py
└── Dockerfile
Dockerfile 이있는 위치, app 디렉토리가 포함되어 있음)docker build -t myimage .docker run -d --name mycontainer -p 80:80 myimage... Docker 컨테이너에 최적화 된 플라스크 서버가 있습니다.
Docker Container의 URL에서 확인할 수 있어야합니다 (예 : http://192.168.99.100 또는 http://127.0.0.1).
최신 프론트 엔드 애플리케이션 (예 : VUE, React, Angular)을 구축하는 경우 최신 버전의 JavaScript (ES2015, TypeScript 등)를 덜 현대적이고 호환되는 버전으로 컴파일하는 것일 것입니다.
동일한 백엔드 (FLASK) Docker 컨테이너로 (컴파일 된) 프론트 엔드 코드를 제공하려면 컴파일을 컴파일 한 후 컨테이너에 코드를 복사해야합니다.
즉, 건물 기계에 모든 프론트 엔드 도구가 설치되어 있어야합니다 (컴퓨터, 원격 서버 등).
그것은 또한 Docker 이미지를 작성하기 직전에 항상 프론트 엔드 코드를 컴파일해야한다는 것을 의미합니다.
또한 컴파일 된 프론트 엔드 코드를 git 저장소에 추가해야 할 수도 있습니다 (이미 GIT를 사용하거나 git 사용 방법을 배우기를 바랍니다).
컴파일 된 코드를 GIT에 추가하는 것은 몇 가지 이유로 매우 나쁜 생각입니다. 그 중 일부는 다음과 같습니다.
이러한 이유로, 동일한 백엔드 (Flask) Docker 컨테이너에서 프론트 엔드 코드를 제공하는 것이 좋습니다.
동일한 백엔드 (FLASK) Docker 컨테이너에서 프론트 엔드 코드를 제공하는 데 훨씬 더 나은 대안이 있습니다.
모든 프론트 엔드 도구가 설치된 다른 Docker 컨테이너 (node.js 등)를 가질 수 있습니다.
Docker의 프론트 엔드 빌딩에 대한이 과정의 세부 사항을 배우려면 다음을 읽을 수 있습니다.
하나의 백엔드 (플라스크) 컨테이너와 하나의 프론트 엔드 컨테이너를 사용한 후에는 두 가지를 제공해야합니다.
그리고 당신은 다른 경로에서 동일한 영역에서 그들을 제공하고 싶을 수도 있습니다. 예를 들어, 경로 /api 의 백엔드 (플라스크) 앱과 "루트"경로 / 의 프론트 엔드.
그런 다음 Traefik을 사용하여 처리 할 수 있습니다.
또한 Let 's Encrypt를 사용하여 응용 프로그램에 대한 HTTPS 인증서를 자동으로 생성 할 수 있습니다. 매우 쉬운 설정으로 모두 무료로 제공됩니다.
이 대안을 사용하려면 위의 프로젝트 생성기를 확인하면이 아이디어를 모두 사용합니다.
이 시나리오에는 3 개의 Docker 컨테이너가 있습니다.
위의 " QuickStart "섹션에서와 동일한 지침을 따라 약간 수정할 수 있어야합니다.
app/ 디렉토리에 코드를 넣는 대신 디렉토리 app/app/ 에 넣으십시오.app/app/ 디렉토리의 빈 파일 __init__.py 추가하십시오.app/ 디렉토리에 uwsgi.ini 파일을 추가하십시오 (컨테이너 내부의 /app/uwsgi.ini 에 복사).uwsgi.ini 파일에서 다음을 추가하십시오. [uwsgi]
module = app.main
callable = app uwsgi.ini 에 대한 설명은 다음과 같습니다.
app.main 입니다. 따라서 패키지 app ( /app/app )에서 main 모듈 ( main.py )을 가져옵니다.app 객체 ( app = Flask(__name__) )입니다.파일 구조는 다음과 같습니다.
.
├── app
│ ├── app
│ │ ├── __init__.py
│ │ ├── main.py
│ └── uwsgi.ini
└── Dockerfile
... 대신 :
.
├── app
│ ├── main.py
└── Dockerfile
동일한 컨테이너에서 정적 파일을 사용하는 경우, STATIC_PATH 환경 변수가 그에 따라 설정되어 있는지 확인하십시오 (예 : /app/static to /app/app/static Dockerfile 기본값을 변경하십시오.
ENV STATIC_PATH /app/app/static... 그 후에는 모든 것이 예상대로 작동해야합니다. 다른 모든 지침은 정상적으로 적용됩니다.
.
├── app
│ ├── app
│ │ ├── api
│ │ │ ├── api.py
│ │ │ ├── endpoints
│ │ │ │ ├── __init__.py
│ │ │ │ └── user.py
│ │ │ ├── __init__.py
│ │ │ └── utils.py
│ │ ├── core
│ │ │ ├── app_setup.py
│ │ │ ├── database.py
│ │ │ └── __init__.py
│ │ ├── __init__.py
│ │ ├── main.py
│ │ └── models
│ │ ├── __init__.py
│ │ └── user.py
│ └── uwsgi.ini
└── Dockerfile
모듈을 가져 오는 동안 공식 문서를 따르십시오.
예를 들어, app/app/main.py 에 있고 app/app/core/app_setup.py 에서 모듈을 가져 오려면 다음과 같이 작성합니다.
from . core import app_setup또는
from app . core import app_setupapp/app/api/endpoints/user.py 에 있고 app/app/core/database.py 에서 users 객체를 가져 오려면 다음과 같이 작성합니다. from ... core . database import users또는
from app . core . database import users 환경 변수를 사용하여 여러 가지를 사용자 정의 할 수 있습니다.
index.html 직접 제공하십시오통지 :이 기술은 최신 프론트 엔드 프레임 워크와 함께 몇 가지 문제를 일으킬 수 있으므로 더 이상 사용되지 않습니다. 세부 사항과 더 나은 대안은 위의 섹션을 읽으십시오.
환경 변수 STATIC_INDEX 1 로 설정하십시오. / 요청이있을 때 url /static/index.html 에서 파일을 제공하도록 nginx를 구성 할 수 있습니다.
UWSGI 나 파이썬과 관련이 없기 때문에 속도가 향상됩니다. Nginx는 파일을 직접 제공합니다. 자세한 내용은 " Spas의 QuickStart "의 섹션을 참조하십시오.
예를 들어, 활성화하려면 Dockerfile 에 추가 할 수 있습니다.
ENV STATIC_INDEX 1기본적으로 이미지는 2 개의 UWSGI 프로세스가 실행되는 것으로 시작합니다. 서버가 높은 부하를 경험할 때 최대 16 개의 UWSGI 프로세스가 필요에 따라 처리됩니다.
이 숫자를 구성 해야하는 경우 환경 변수를 사용할 수 있습니다.
UWSGI 프로세스의 시작 수는 기본적으로 변수 UWSGI_CHEAPER 에 의해 제어되며 기본적으로 2 로 설정됩니다.
UWSGI 프로세스의 최대 수는 기본적으로 16 으로 설정된 변수 UWSGI_PROCESSES 에 의해 제어됩니다.
UWSGI_CHEAPER 는 UWSGI_PROCESSES 보다 낮아야합니다.
예를 들어, 4 개의 프로세스로 시작하여 최대 64로 성장 해야하는 경우 Dockerfile 은 다음과 같습니다.
FROM tiangolo/uwsgi-nginx-flask:python3.12
ENV UWSGI_CHEAPER 4
ENV UWSGI_PROCESSES 64
COPY ./app /app 환경 변수 NGINX_MAX_UPLOAD 사용하여 사용자 정의 최대 업로드 파일 크기를 설정할 수 있습니다. 기본적으로 기본적으로 값은 0 이므로 파일 크기를 무제한으로 업로드 할 수 있습니다. 이것은 Nginx의 기본값 1MB와 다릅니다. Nginx의 경험이없는 개발자가 기대할 수있는 가장 간단한 경험이기 때문에이 방식으로 구성됩니다.
예를 들어, 최대 업로드 파일 크기가 1 MB (Nginx의 기본값) 인 Dockerfile 에 라인을 추가하십시오.
ENV NGINX_MAX_UPLOAD 1m기본적 으로이 이미지로 만든 컨테이너는 포트 80에서 듣습니다.
이 동작을 변경하려면 LISTEN_PORT 환경 변수를 설정하십시오. 각 EXPOSE Docker 명령을 만들어야 할 수도 있습니다.
Dockerfile 에서 그렇게 할 수 있습니다.
FROM tiangolo/uwsgi-nginx-flask:python3.12
ENV LISTEN_PORT 8080
EXPOSE 8080
COPY ./app /appuwsgi.ini 구성 앱 특정 구성이있는 /app/uwsgi.ini 에는 기본 파일이 있습니다 (글로벌 uwsgi 구성 위에).
그것은 단지 포함됩니다 :
[uwsgi]
module = main
callable = appmodule = main main.py 파일을 나타냅니다.callable = app 변수 app 의 Flask "응용 프로그램"을 나타냅니다. 모든 구성을 포함하여 해당 파일을 자신의 파일로 교체하여 uwsgi 사용자 정의 할 수 있습니다.
예를 들어, 기본값을 확장하고 스레드를 활성화하려면 파일을 가질 수 있습니다.
[uwsgi]
module = main
callable = app
enable-threads = trueuwsgi.ini 파일 위치 환경 변수 UWSGI_INI 사용하여 이미지가 앱 uwsgi.ini 파일을 찾는 위치를 무시할 수 있습니다.
이를 통해 앱의 기본 디렉토리를 /app 에서 다른 /application 으로 변경할 수 있습니다.
예를 들어, 이미지가 /application/uwsgi.ini 에서 파일을 사용하도록하려면 Dockerfile 에 이것을 추가 할 수 있습니다.
ENV UWSGI_INI /application/uwsgi.ini
COPY ./application /application
WORKDIR /application 참고 : WORKDIR 중요합니다. 그렇지 않으면 UWSGI는 /app 에서 앱을 실행하려고합니다.
참고 : static 파일 경로를 구성해야합니다. 아래를 읽으십시오.
./static/ Path nginx가 파일과 함께 사용자 정의 디렉토리 경로를 사용하여 환경 변수 STATIC_PATH 와 함께 UWSGI를 직접 제공하지 않고 직접 제공 할 수 있습니다.
예를 들어, nginx가 /app/custom_static/ 의 파일을 사용하여 정적 컨텐츠를 제공하려면 Dockerfile 에 이것을 추가 할 수 있습니다.
ENV STATIC_PATH /app/custom_static 그런 다음 브라우저가 예를 들어 http://example.com/static/index.html에서 파일을 요청하면 nginx는 path /app/custom_static/index.html index.html에서 파일을 직접 사용하여 직접 응답합니다.
참고 : 또한이를 static 디렉토리로 사용하도록 플라스크를 구성해야합니다.
다른 예로, 응용 프로그램 코드를 다른 디렉토리에 넣어야하는 경우 해당 디렉토리에서 해당 정적 파일을 제공하도록 nginx를 구성 할 수 있습니다.
/application/static/ 에 정적 파일이 필요한 경우 Dockerfile 에 추가 할 수 있습니다.
ENV STATIC_PATH /application/static/static URL Nginx가 다른 URL로 정적 파일을 제공 할 수도 있습니다.이를 위해 환경 변수 STATIC_URL 사용할 수 있습니다.
예를 들어 URL /static /content 변경하려면 Dockerfile 에 추가 할 수 있습니다.
ENV STATIC_URL /content 그런 다음 브라우저가 예를 들어 http://example.com/content/index.html에서 파일을 요청하면 nginx는 path /app/static/index.html 에서 파일을 사용하여 직접 응답합니다.
/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 참고 : 이미지는 source 사용하여 스크립트를 실행하므로 예를 들어 환경 변수가 지속됩니다. 이전 문장을 이해하지 못한다면 아마도 필요하지 않을 것입니다.
기본적으로 Nginx는 하나의 "작업자 프로세스"를 시작합니다.
다른 수의 NGINX 작업자 프로세스를 설정하려면 환경 변수 NGINX_WORKER_PROCESSES 사용할 수 있습니다.
특정 단일 번호 (예 :)를 사용할 수 있습니다.
ENV NGINX_WORKER_PROCESSES 2 또는 키워드 auto 으로 설정할 수 있으며 사용 가능한 CPU 수를 자동 감지하고 작업자 수에 사용하려고합니다.
예를 들어 auto 사용하면 DockerFile이 다음과 같습니다.
FROM tiangolo/uwsgi-nginx-flask: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를 추가로 구성 해야하는 경우 Dockerfile 에서 * /etc/nginx/conf.d/ 파일에 *.conf 파일을 추가 할 수 있습니다.
기본 구성은 /etc/nginx/conf.d/nginx.conf 및 /etc/nginx/conf.d/upload.conf 파일에서 시작하는 동안 생성됩니다. 그래서 당신은 그것들을 덮어 쓰지 않아야합니다. nginx.conf 또는 upload.conf 와 다른 것을 가진 *.conf 파일의 이름 : custom.conf .
참고 : NGINX를 사용자 정의하는 경우 블로그 또는 StackOverFlow 답변에서 구성을 복사 할 수 있습니다. 예를 들어 ngx_http_fastcgi_module 과 같은 다른 모듈 대신 UWSGI에 대한 구성을 사용해야 할 것입니다.
기본값을 완전히 무시하고 Nginx를 더욱 구성 해야하는 경우 /app/nginx.conf 에 사용자 정의 nginx 구성을 추가 할 수 있습니다.
/etc/nginx/nginx.conf 에 복사되고 생성 된 것 대신 사용됩니다.
이 경우이 이미지는 NGINX 구성을 생성하지 않으며 구성 파일 만 복사하여 사용합니다.
즉, Nginx에 특이적인 위에서 설명한 모든 환경 변수는 사용되지 않습니다.
또한 사용자 정의 파일 /app/nginx.conf 에 섹션이없는 한 /etc/nginx/conf.d/*.conf 의 파일에서 추가 구성을 사용하지 않음을 의미합니다.
include /etc/nginx/conf.d/*.conf;
Custom /app/nginx.conf 파일을 추가하려면 어디서부터 시작 해야할지 모르면 테스트에 사용되는 nginx.conf 를 사용하여 사용자 정의하거나 더 수정할 수 있습니다.
UWSGI와 NGINX의 조합은 Python Flask 웹 응용 프로그램을 배포하는 일반적인 방법입니다.
대충:
Nginx 는 웹 서버이며 HTTP 연결을 관리하며 정적 파일을 직접적이고보다 효율적으로 제공 할 수도 있습니다.
UWSGI 는 애플리케이션 서버입니다. 이것이 Python 코드를 실행하고 Nginx와 대화합니다.
파이썬 코드 에는 실제 플라스크 웹 응용 프로그램이 있으며 UWSGI가 실행합니다.
이미지 tiangolo/uwsgi-nginx는 이미 기존의 슬림하고 최적화 된 Docker 이미지 (Docker가 권장하는 데비안 기반)를 활용하고 Docker의 모범 사례 중 여러 가지를 구현합니다.
공식 Python Docker Image를 사용하고 UWSGI를 설치하고 그 위에 (최소한 수정량이 적음) 공식 NGINX 이미지를 추가합니다.
그리고 Supervisord를 사용하여 이러한 모든 프로세스를 제어합니다.
이 Repo에 의해 생성 된 이미지 (및 태그)는 이미지 Tiangolo/uwsgi-nginx 를 기반으로합니다. 이 이미지는 플라스크와 현명한 기본값을 추가합니다.
지침을 따르고 main.py 라는 파일과 app 이라는 플라스크 객체를 사용하여 루트 디렉토리 /app 컨테이너에 보관하면 "그냥 작동"해야합니다.
/app 디렉토리에는 이미 UWSGI 구성이있는 uwsgi.ini 파일이 "그냥 작동하기"에 대한 UWSGI 구성이 있습니다. 그리고 다른 모든 필요한 매개 변수는 이미지의 다른 uwsgi.ini 파일, 내부 /etc/uwsgi/ 입니다.
기본 파일 이름 또는 기본 플라스크 객체를 변경 해야하는 경우 자신의 uwsgi.ini 파일을 제공해야합니다. 이 repo의 하나를 시작하여 템플릿으로 사용할 수 있습니다 (그리고 해당 라인 2 개만 변경하면됩니다).
A /app/static 디렉토리를 가질 수 있으며 해당 파일은 NGINX가 직접 효율적으로 제공됩니다 (플라스크 코드 나 UWSGI를 통과하지 않고도 이미 구성되어 있습니다. 그러나 환경 변수를 사용하여 추가로 구성 할 수 있습니다 (위에서 읽으십시오).
Supervisord는 /app 파일 ( /etc/uwsgi/uwsgi.ini 의 파일 포함)에서 uwsgi.ini 파일을 사용하여 UWSGI를 실행하고 nginx를 시작합니다.
"컨테이너 당 하나의 프로세스"가 있어야하는 경험 법칙이 있습니다.
예를 들어 앱과 데이터베이스를 다른 컨테이너로 분리하는 데 도움이됩니다.
그러나 "마이크로 서비스"접근 방식을 원한다면 동일한 "서비스"와 관련이있는 경우 하나의 컨테이너에 둘 이상의 프로세스를 원할 수 있으며 동일한 컨테이너에 플라스크 코드, UWSGI 및 NGINX를 포함시키고 싶을 수도 있습니다 (데이터베이스와 함께 다른 컨테이너를 실행할 수 있음).
이것이이 이미지에서 취한 접근법입니다.
이 이미지 (및 태그)에는 일부 기본 파일이 있으므로 자체적으로 실행하면 (자신의 프로젝트의 기본 이미지가 아님) 기본 "Hello World"웹 앱이 표시됩니다.
COPY ./app /app 으로 Dockerfile 빌드하면 해당 기본 파일을 앱 코드로 바꿉니다.
기본 기본 파일은 /app/main.py 에만 있습니다. 그리고 -index 가있는 태그의 경우 /app/static/index.html 에도 있습니다.
그러나 해당 파일은 제공된 웹 페이지에서 "(기본값) 텍스트를 렌더링하므로 기본 코드가 표시되는지 또는 기본값을 재정의하는 자체 코드를 확인할 수 있습니다.
앱 코드는 컨테이너 /app 디렉토리에 있어야하며 main.py 파일이 있어야하며 main.py 파일에는 Flask Object app 있어야합니다.
위의 지침을 따르거나 다운로드 가능한 예제 템플릿 중 하나를 사용하면 괜찮을 것입니다.
UWSGI의 기본 매개 변수가있는 이미지 안에는 /app/uwsgi.ini 파일도 있습니다.
다운로드 가능한 예제에는 디버깅 목적으로 동일한 uwsgi.ini 파일의 사본이 포함됩니다. 자세한 내용은 아래의 " 고급 개발 지침 "을 읽으십시오.
개발하는 동안 코드 디렉토리를 Docker 컨테이너의 볼륨으로 만들 수 있습니다.
이를 통해 컨테이너를 다시 빌드 할 필요없이 파일을 수정할 때마다 파일을 업데이트 할 수 있습니다.
이렇게하려면 docker run 내부에서 pwd (인쇄 작업 디렉토리)를 사용할 수 있고 Volumes의 플래그 -v 사용할 수 있습니다.
이를 통해 ./app 디렉토리를 컨테이너 /app 디렉토리에 매핑 할 수 있습니다.
그러나 먼저, 컨테이너 (및 모든 내용)에서 디렉토리 /app 완전히 교체 할 예정이므로 ./app 디렉토리에 uwsgi.ini 파일이 있어야합니다.
[uwsgi]
module = main
callable = app그런 다음 Docker 볼륨 매핑을 수행 할 수 있습니다.
참고 : uwsgi.ini 파일은 다운로드 가능한 예에 포함되어 있습니다.
Dockerfile 및 ./app 디렉토리가있는 것)로 이동하십시오../app 디렉토리에 uwsgi.ini 파일이 있는지 확인하십시오.docker build -t myimage ../app )를 컨테이너 /app 디렉토리에 매핑하십시오. docker run -d --name mycontainer -p 80:80 -v $( pwd ) /app:/app myimage Docker 컨테이너 URL로 이동하면 앱이 표시되며 ./app/static/ 에서 파일을 수정하고 재 장전을 통해 브라우저에 반영된 변경 사항을 볼 수 있어야합니다.
... 그러나 UWSGI가 시작되면 전체 Python Flask 웹 응용 프로그램을로드함에 따라 Python Flask 코드를 편집하고 변경 사항을 볼 수 없습니다.
파이썬 플라스크 코드를 라이브로 디버깅 할 수 있으려면 기본 명령을 우선시하는 컨테이너 (UWSGI 및 NGINX를 시작하는 Supervisord를 시작하고 python 과 직접 응용 프로그램을 실행하여 Debug 모드에서 flask 명령을 사용하여 환경 변수와 함께 플라스크 명령을 사용하십시오.
따라서 위의 모든 수정과 flask 로 앱을 직접 실행할 수있게되면 최종 Docker 명령은 다음과 같습니다.
docker run -d --name mycontainer -p 80:80 -v $( pwd ) /app:/app -e FLASK_APP=main.py -e FLASK_DEBUG=1 myimage flask run --host=0.0.0.0 --port=80 또는 패키지 프로젝트의 경우 FLASK_APP=main/main.py 설정합니다.
docker run -d --name mycontainer -p 80:80 -v $( pwd ) /app:/app -e FLASK_APP=main/main.py -e FLASK_DEBUG=1 myimage flask run --host=0.0.0.0 --port=80이제 로컬 컴퓨터에서 플라스크 코드를 편집 할 수 있으며 브라우저를 새로 고치면 변경 사항이 실시간으로 표시됩니다.
디버깅 및 개발에만 사용해야합니다. 생산에 배치하려면 볼륨을 마운트하지 않아야하며 Supervisord를 시작하고 UWSGI 및 NGINX (기본적으로 발생하는 일)를 시작하도록해야합니다.
패키지가 없지만 단일 파일 (모듈)이있는 평평한 구조 만 있으면 이러한 마지막 단계가 작동하는 대안으로 Python Flask 코드는 다음과 같은 섹션을 가질 수 있습니다.
if __name__ == "__main__" :
# Only for debugging while developing
app . run ( host = '0.0.0.0' , debug = True , port = 80 ) ... 그리고 python main.py 로 실행할 수 있습니다. 그러나 패키지 구조를 사용하지 않고 나중에 할 계획이 없을 때만 작동합니다. 이 특정 경우 위의 코드 블록을 추가하지 않은 경우 앱은 디버그 모드가 아닌 다른 포트 (5000)에서 localhost (컨테이너 내부) 만 듣습니다.
또한 환경 변수 STATIC_INDEX=1 사용하여 동일한 라이브 디버깅을 수행하려면 ( /app/static/index.html 요청할 때 직접 제공하기 위해 / nginx는 실행되지 않으므로 직접 서비스를 제공하지 않습니다 (디버그 모드의 Python Flask 앱 만 실행됩니다).
from flask import Flask , send_file그리고
@ app . route ( '/' )
def route_root ():
index_path = os . path . join ( app . static_folder , 'index.html' )
return send_file ( index_path ) ... 앱이 /app/static/index.html 파일을 요청할 때 앱도 제공합니다 / 또는 패키지 구조를 사용하는 경우 /app/main/static/index.html 파일입니다.
스파 프레임 워크를 사용하는 경우 브라우저의 URL을 처리 할 수 있도록 Python Flask 코드는 다음과 같은 섹션이 있어야합니다.
# Everything not declared before (not a Flask route / API endpoint)...
@ app . route ( '/<path:path>' )
def route_frontend ( path ):
# ...could be a static file needed by the front end that
# doesn't use the `static` path (like in `<script src="bundle.js">`)
file_path = os . path . join ( app . static_folder , path )
if os . path . isfile ( file_path ):
return send_file ( file_path )
# ...or should be handled by the SPA's "router" in front end
else :
index_path = os . path . join ( app . static_folder , 'index.html' )
return send_file ( index_path ) ... 루트 ( / ) URL에 요청할 때 Flask가 모든 CSS, JavaScript 및 이미지 파일을 보내지 만 Frontend Spa는 Flask 앱에서 정의되지 않은 다른 모든 URL을 처리해야합니다.
그것이 위의 자습서에 작성된 방법이며 다운로드 가능한 예제에 포함되어 있습니다.
위의 지시 사항을 따르면 어느 시점에서 플라스크 디버깅 서버를 끊을 코드를 작성하면 충돌이 발생할 수 있습니다.
그리고 실행중인 유일한 프로세스는 디버깅 서버 였으므로 이제 중지되면 컨테이너가 중지됩니다.
그러면 코드를 수정 한 후 컨테이너를 다시 시작해야하며 서버에 충돌하는 오류가 무엇인지 쉽게 알 수 없습니다.
따라서 개발 중에는 다음을 수행 할 수 있습니다 (예제 프로젝트에서와 같이 Docker Compose와 함께하지만 일반적으로하는 일입니다).
docker run -d --name mycontainer -p 80:80 -v $( pwd ) /app:/app -e FLASK_APP=main.py -e FLASK_DEBUG=1 myimage bash -c " while true ; do sleep 10 ; done "FLASK_APP=main/main.py 설정하십시오. docker run -d --name mycontainer -p 80:80 -v $( pwd ) /app:/app -e FLASK_APP=main/main.py -e FLASK_DEBUG=1 myimage bash -c " while true ; do sleep 10 ; done "docker exec -it mycontainer bash 이제 /app 디렉토리의 컨테이너 안에 있습니다.
flask run --host=0.0.0.0 --port=80플라스크 디버깅 서버가 시작되는 것을보고, 모든 요청에 응답을 보내는 방법을 볼 수 있으며, 코드를 깨뜨릴 때 오류가 발생하는 오류와 서버를 중지하는 방법을 볼 수 있으며 위의 명령을 다시 실행하여 매우 빠르게 다시 시작할 수 있습니다.
모든 이미지 태그, 구성, 환경 변수 및 응용 프로그램 옵션이 테스트됩니다.
issue-manager.yml . @tiangolo의 PR #385.latest-changes GitHub 작업을 업데이트하십시오. @tiangolo의 PR #360.latest-changes.yml 업데이트하십시오. @alejsdev의 PR #348.README.md 에서 테스트 배지를 업데이트하십시오. @alejsdev의 PR #346. 이 릴리스의 하이라이트 :
python3.6-2022-11-25 및 python2.7-2022-11-25 입니다.1.17.10 .3.11 .-index sufix tags.-index (use ENV STATIC_INDEX 1 instead).2020-05-04 .tiangolo/uwsgi-nginx-flask:python3.8-2019-10-14 . PR #154./start.sh and /app/prestart.sh functionality to parent image. PR #134.2019-02-02:
uwsgi-nginx and PR #121./app/nginx.conf file that overrides the generated one. PR #51 in the parent image uwsgi-nginx and PR #122.2019-01-01:
2018-12-29:
2018-11-23:
2018-09-22:
2018-06-22:
NGINX_WORKER_CONNECTIONS to set the maximum number of Nginx worker connections and NGINX_WORKER_OPEN_FILES to set the maximum number of open files. Thanks to ronlut in this PR.2018-06-22:
Improvements from parent image:
Make uWSGI require an app to run, instead of going in "full dynamic mode" while there was an error. Supervisord doesn't terminate itself but tries to restart uWSGI and shows the errors. Uses need-app as suggested by luckydonald in this comment.
Correctly handled graceful shutdown of uWSGI and Nginx. Thanks to desaintmartin in this PR.
2018-02-04:
It's now possible to set the number of Nginx worker processes with the environment variable NGINX_WORKER_PROCESSES . Thanks to naktinis in this PR.
2018-01-14:
python2.7-alpine3.7 and python3.6-alpine3.7 .2017-12-10:
/app/prestart.sh script to run arbitrary code before starting the app (for example, Alembic - SQLAlchemy migrations). The documentation for the /app/prestart.sh is in the main README./app is part of the PYTHONPATH environment variable. That allows global imports from several places, easier Alembic integration, etc. 2017-12-08: Now you can configure which port the container should listen on, using the environment variable LISTEN_PORT thanks to tmshn in this PR.
2017-09-10: Updated examples and sample project to work with SPAs even when structuring the app as a package (with subdirectories).
2017-09-02:
flask run commands, that allows running a package application while developing more easily.2017-08-10: Many changes:
python3.6 , python3.6-index , python.3.5 , python3.5-index , python2.7 and python2.7-index . All the other images are deprecated in favor is this ones.latest will point to Python 3.6 and the other tags will be removed.tiangolo/uwsgi-nginx that improved this image too.index.html directly: STATIC_INDEXNGINX_MAX_UPLOADuwsgi.ini file (that allows using a custom directory different than /app ): UWSGI_INI (using the ideas by @bercikr in #5 )../static/ path: STATIC_PATH/static/ URL: STATIC_URLDockerfile with: FROM tiangolo/uwsgi-nginx-flask:python3.6
COPY ./app /appand then customize with environment variables.
This project is licensed under the terms of the Apache license.
