uwsgi nginx 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:python3.12-2024-11-02 .
단일 컨테이너의 파이썬 ( 플라스크 )의 웹 애플리케이션에 대한 UWSGI 및 NGINX를 사용한 Docker 이미지.
이 Docker 이미지를 사용하면 단일 컨테이너에서 UWSGI 및 NGINX 로 실행되는 Python 웹 응용 프로그램을 만들 수 있습니다.
UWSGI와 NGINX의 조합은 Flask 및 Django와 같은 Python 웹 응용 프로그램을 배포하는 일반적인 방법입니다. 업계에서 널리 사용되며 괜찮은 성능을 제공합니다. (*)
이 이미지는 Tiangolo/UWSGI-Nginx-Flask 의 기본 이미지로 만들어졌지만 Django와 같은 다른 (WSGI 기반) Python 웹 응용 프로그램의 기본 이미지로 사용될 수 있습니다.
새로운 프로젝트를 시작하는 경우 WSGI (Flask 및 Django는 WSGI 기반) 대신 ASGI를 기반으로 한 새롭고 빠른 프레임 워크의 혜택을 누릴 수 있습니다.
다음과 같은 ASGI 프레임 워크를 사용할 수 있습니다.
Fastapi 또는 Starlette는이 이미지 ( Tiangolo/uwsgi-nginx )로 달성 할 수있는 성능을 약 800% (8x)에게 제공합니다. 여기에서 타사 벤치 마크를 볼 수 있습니다.
또한 Websockets와 같은 새로운 기술을 사용하려면 Fastapi 또는 Starlette와 같은 ASGI를 기반으로하는 새로운 프레임 워크를 사용하여 더 쉽고 가능 합니다. 표준 ASGI는 WebSockets에 필요한 것과 같은 비동기 코드를 처리 할 수 있도록 설계되었습니다.
Flask 또는 Django (ASGI를 기반으로 한 것 대신)와 같은 이전 WSGI 기반 프레임 워크를 사용해야하고 가능한 최상의 성능이 필요하다면 Tiangolo/Meinheld-Gunicorn : 대체 이미지를 사용할 수 있습니다.
Tiangolo/Meinheld-Gunicorn 은이 이미지의 성능을 약 400% (4 배) 줄 것입니다.
Github Repo : https://github.com/tiangolo/uwsgi-nginx-docker
Docker Hub 이미지 : https://hub.docker.com/r/tiangolo/uwsgi-nginx/
아마도 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/uwsgi-nginx:python3.12
COPY ./requirements.txt /app/requirements.txt
RUN pip install --no-cache-dir --upgrade -r /app/requirements.txt
COPY ./app /app
# Your Dockerfile code... 기본적으로 /app/uwsgi.ini 에서 uwsgi config 파일을 찾으려고합니다.
uwsgi.ini 파일은 /app/main.py 에서 Python 파일을 실행하려고합니다.
플라스크 웹 애플리케이션을 구축하는 경우 대신 Tiangolo/UWSGI-NGINX-FLASK를 사용해야합니다.
/app 과 다른 앱에 디렉토리를 사용해야하는 경우 환경 변수 UWSGI_INI 로 UWSGI 구성 파일 경로를 무시하고 사용자 정의 uwsgi.ini 파일을 거기에 넣을 수 있습니다.
예를 들어, /application /app 응용 프로그램에 응용 프로그램 디렉토리가 있어야하는 경우 Dockerfile 이 다음과 같습니다.
FROM tiangolo/uwsgi-nginx:python3.12
ENV UWSGI_INI /application/uwsgi.ini
COPY ./application /application
WORKDIR /appapplication ./application/uwsgi.ini 의 uwsgi.ini 파일은 다음을 포함합니다.
[uwsgi]
wsgi-file =/application/main.py 참고 : WORKDIR 옵션을 포함하는 것이 중요합니다. 그렇지 않으면 UWSGI는 /app 에서 응용 프로그램을 시작합니다.
기본적으로 이미지는 2 개의 UWSGI 프로세스가 실행되는 것으로 시작합니다. 서버가 높은 부하를 경험할 때 최대 16 개의 UWSGI 프로세스가 필요에 따라 처리됩니다.
이 숫자를 구성 해야하는 경우 환경 변수를 사용할 수 있습니다.
UWSGI 프로세스의 시작 수는 기본적으로 변수 UWSGI_CHEAPER 에 의해 제어되며 기본적으로 2 로 설정됩니다.
UWSGI 프로세스의 최대 수는 기본적으로 16 으로 설정된 변수 UWSGI_PROCESSES 에 의해 제어됩니다.
UWSGI_CHEAPER 는 UWSGI_PROCESSES 보다 낮아야합니다.
예를 들어, 4 개의 프로세스로 시작하여 최대 64로 성장 해야하는 경우 Dockerfile 은 다음과 같습니다.
FROM tiangolo/uwsgi-nginx:python3.12
ENV UWSGI_CHEAPER 4
ENV UWSGI_PROCESSES 64
COPY ./app /app이 이미지에서 Nginx는 무제한 업로드 파일 크기를 허용하도록 구성됩니다. 이것은 기본적으로 간단한 Python 서버가 허용하므로 개발자가 기대할 수있는 가장 간단한 동작이기 때문에 수행됩니다.
nginx에서 최대 업로드 크기를 제한 해야하는 경우 환경 변수 NGINX_MAX_UPLOAD 추가하고 표준 nginx config client_max_body_size 에 해당하는 값을 할당 할 수 있습니다.
예를 들어, 최대 업로드 파일 크기를 1MB로 설정하려면 (일반 NGINX 설치의 기본값) NGINX_MAX_UPLOAD 환경 변수를 값 1m 으로 설정해야합니다. 그런 다음 이미지가 해당 구성 파일을 추가해야합니다 ( entrypoint.sh 에서 수행).
따라서 Dockerfile 은 다음과 같은 것 같습니다.
FROM tiangolo/uwsgi-nginx:python3.12
ENV NGINX_MAX_UPLOAD 1m
COPY ./app /app기본적 으로이 이미지로 만든 컨테이너는 포트 80에서 듣습니다.
이 동작을 변경하려면 LISTEN_PORT 환경 변수를 설정하십시오.
각 EXPOSE Docker 명령을 만들어야 할 수도 있습니다.
Dockerfile 에서 그렇게 할 수 있습니다.
FROM tiangolo/uwsgi-nginx:python3.12
ENV LISTEN_PORT 8080
EXPOSE 8080
COPY ./app /app/app/prestart.sh 앱을 시작하기 전에 무엇이든 실행 해야하는 경우 prestart.sh 를 디렉토리 /app 에 추가 할 수 있습니다. 이미지는 모든 것을 시작하기 전에 자동으로 감지하고 실행합니다.
예를 들어, 스타트 업에서 실행되는 데이터베이스 마이그레이션 (예 : Alembic 또는 Django Migrations)을 추가하려면 앱을 시작하기 전에 코드 디렉토리에 ./app/prestart.sh 파일을 만들 수 있습니다 ( Dockerfile 에서 복사 할).
#! /usr/bin/env bash
# Let the DB start
sleep 10 ;
# Run migrations
alembic upgrade head 또한 데이터베이스에 일정 시간을 시작한 다음 alembic 명령을 실행하는 데 10 초를 기다릴 것입니다 (Django 마이그레이션 또는 필요한 다른 도구를 실행하도록 업데이트 할 수 있습니다).
앱을 시작하기 전에 Python 스크립트를 실행 해야하는 경우 /app/prestart.sh 파일을 다음과 같이 Python 스크립트를 실행할 수 있습니다.
#! /usr/bin/env bash
# Run custom Python script before starting
python /app/my_custom_prestart_script.py 참고 : 이미지가 사용됩니다 . 스크립트를 실행하려면 ( . /app/prestart.sh 에서와 같이) 예를 들어 환경 변수가 지속됩니다. 이전 문장을 이해하지 못한다면 아마도 필요하지 않을 것입니다.
기본적으로 Nginx는 하나의 "작업자 프로세스"를 시작합니다.
다른 수의 NGINX 작업자 프로세스를 설정하려면 환경 변수 NGINX_WORKER_PROCESSES 사용할 수 있습니다.
특정 단일 번호 (예 :)를 사용할 수 있습니다.
ENV NGINX_WORKER_PROCESSES 2 또는 키워드 auto 으로 설정할 수 있으며 사용 가능한 CPU 수를 자동으로 설정하고 작업자 수에 사용합니다.
예를 들어 auto 사용하면 DockerFile이 다음과 같습니다.
FROM tiangolo/uwsgi-nginx: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 웹 애플리케이션을 배포하는 일반적인 방법입니다.
대충:
Nginx 는 웹 서버이며 HTTP 연결을 관리하며 정적 파일을 직접적이고보다 효율적으로 제공 할 수도 있습니다.
UWSGI 는 애플리케이션 서버입니다. 이것이 Python 코드를 실행하고 Nginx와 대화합니다.
파이썬 코드 에는 실제 웹 응용 프로그램이 있으며 UWSGI가 실행합니다.
이 이미지는 이미 슬림하고 최적화 된 기존 Docker 이미지 (Docker가 권장하는 데비안 기반)를 활용하고 Docker 모범 사례를 구현합니다.
공식 Python Docker 이미지를 사용하고 UWSGI를 설치하고 그 위에 최소한의 수정으로 공식 NGINX 이미지를 추가합니다 (2016-02-14).
그리고 Supervisord를 사용하여 이러한 모든 프로세스를 제어합니다.
"컨테이너 당 하나의 프로세스"가 있어야하는 경험 법칙이 있습니다.
예를 들어 앱과 데이터베이스를 다른 컨테이너로 분리하는 데 도움이됩니다.
그러나 "마이크로 서비스"접근 방식을 원한다면 동일한 "서비스"와 관련이있는 경우 하나의 컨테이너에 둘 이상의 프로세스를 원할 수 있으며 동일한 컨테이너에 플라스크 코드, UWSGI 및 NGINX를 포함시키고 싶을 수도 있습니다 (데이터베이스와 함께 다른 컨테이너를 실행할 수 있음).
이것이이 이미지에서 취한 접근법입니다.
이 이미지에는 UWSGI 문서의 예제를 사용하여 컨테이너 /app 디렉토리에 기본 샘플 "Hello World"앱이 있습니다.
아마도 프로젝트에서 그것을 무시하거나 삭제하고 싶을 것입니다.
이 이미지를 자체적으로 실행할 경우 자신의 Dockerfile 의 기본 이미지가 아니라 오류없이 샘플 앱을 얻을 수 있습니다.
요컨대 : 아마도 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 #208. 80 과 443 기본적으로 사용자 정의 할 수 있으므로 EXPOSE 하지 않습니다. @tiangolo의 PR #227. issue-manager.yml . @tiangolo의 PR #226.latest-changes GitHub 작업을 업데이트하십시오. @tiangolo의 PR #214.latest-changes.yml 업데이트하십시오. @alejsdev의 Pr #201.README.md 에서 테스트 배지를 업데이트하십시오. Pr #199의 @alejsdev. 이 릴리스의 하이라이트 :
python3.6-2022-11-25 및 python2.7-2022-11-25 입니다.2.0.20 으로 업그레이드하십시오. @tiangolo의 PR #127.1.17.10 으로 업그레이드하십시오. PR #82.2020-05-04 에 태그를 사용하십시오.2019-10-14 :
2019-09-28 :
tiangolo/uwsgi-nginx:python3.7-2019-09-28 과 같은 각 빌드 날짜에 대한 스크립트를 빌드하고 이미지 태그를 추가하십시오. PR #65.트래비스 업그레이드. PR #60.
/app/prestart.sh 스크립트에 대한 지원이 추가되었습니다. /app/prestart.sh 의 문서는 기본 readme에 있습니다. PR #59.2019-05-04 :
2019-02-02 :
/app/nginx.conf 파일에 대한 지원. PR #51.2018-11-23 : Python 2.7, Python 3.6 및 Python 3.7의 새로운 알파인 3.8 이미지 (Python 3.7 일시적으로 비활성화). PR #45의 Philippfreyer에게 감사합니다
2018-09-22 : 새로운 Python 3.7 버전, 표준 및 알파인 기반. 이 PR에서 Desaintmartin에게 감사드립니다.
2018-06-22 : 이제 NGINX_WORKER_CONNECTIONS 사용하여 최대 Nginx 작업자 연결 및 NGINX_WORKER_OPEN_FILES 수를 설정하여 최대 열린 파일 수를 설정할 수 있습니다. 이 PR의 Ronlut에게 감사합니다.
2018-06-22 : UWSGI는 오류가있는 동안 "전체 동적 모드"로 들어가는 대신 앱을 실행해야합니다. Supervisord는 스스로 종료되지 않지만 UWSGI를 다시 시작하려고 시도하고 오류를 보여줍니다. 이 의견에서 LuckyDonald가 제안한 need-app 사용합니다.
2018-06-22 : UWSGI와 Nginx의 우아한 종료를 올바르게 처리했습니다. 이 PR에서 Desaintmartin에게 감사드립니다.
2018-02-04 : 이제 환경 변수 NGINX_WORKER_PROCESSES 로 Nginx 작업자 프로세스 수를 설정할 수 있습니다. 이 PR의 Naktinis에게 감사드립니다.
2018-01-14 : 이제 두 개의 알파인 기반 버전 인 python2.7-alpine3.7 및 python3.6-alpine3.7 있습니다.
2017-12-08 : 이제이 PR의 TMSHN 덕분에 Environment Variable LISTEN_PORT 사용하여 컨테이너가 청취 해야하는 포트를 구성 할 수 있습니다.
2017-08-09 : 환경 변수 NGINX_MAX_UPLOAD 사용하여 사용자 정의 최대 업로드 파일 크기를 설정할 수 있습니다. 기본적으로 기본적으로 값은 0 이므로 파일 크기가 무제한을 허용합니다. 이것은 Nginx의 기본값 1MB와 다릅니다. Nginx의 전문가가 아닌 개발자가 기대할 수있는 가장 간단한 경험이기 때문에 이러한 방식으로 구성됩니다.
2017-08-09 : 이제 uwsgi.ini 파일을 찾을 위치를 무시할 수 있습니다. 이로 인해 기본 디렉토리를 /app 에서 다른 것으로 변경하여 Envirnoment 변수 UWSGI_INI 사용하십시오.
2017-08-08 : 새로운 latest 태그 이미지가 있습니다. Python 2.7 웹 애플리케이션에 여전히 latest 사용하는 사람들에게 경고를 표시합니다. 현재 모든 사람은 Python 3을 사용해야합니다.
2017-08-08 : Supervisord는 이제 SIGTERM 에서 UWSGI를 종료하므로 docker stop 또는 이와 유사한 것을 실행하면 Docker의 타임 아웃이 컨테이너를 죽일 때까지 기다리는 대신 실제로 모든 것을 중지합니다.
2017-07-31 : Python 3.6의 공식 이미지를 기반으로 Python 3.6의 이미지 태그가 있습니다.
2016-10-01 : 이제 /app/uwsgi.ini 의 파일에서 기본 uwsgi.ini 매개 변수를 재정의 할 수 있습니다.
2016-08-16 : 이제 Python 3.5의 공식 이미지를 기반으로 Python 3.5의 이미지 태그가 있습니다. 이제이 이미지를 Python 2.7 및 Python 3.5에서 프로젝트에 사용할 수 있습니다.
2016-08-16 : 동적 사용 부하에 따라 UWSGI에 대한 다수의 작업자 프로세스를 사용합니다. 이것은 대부분의 경우에 작동해야합니다. 이는 특히 느리게 응답이 생기고 생성하는 데 시간이 걸릴 때 특히 도움이됩니다.이 변경으로 인해 다른 모든 응답은 첫 번째 (느린)가 끝날 때까지 기다릴 필요없이 (새로운 프로세스에서) 빠르게 유지할 수 있습니다.
또한 이제 대부분의 일반 구성과 함께 /etc/uwsgi/ 아래의 기본 uwsgi.ini 파일을 사용하므로 uwsgi.ini 내부 /app (수정해야 할 수있는 것)이 훨씬 간단합니다.
2016-04-05 : Nginx 및 UWSGI 로그가 이제 stdout으로 리디렉션되어 docker logs 사용할 수 있습니다.
이 프로젝트는 Apache 라이센스의 조건에 따라 라이센스가 부여됩니다.
