uwsgi nginx docker
2.1.0
Dockerfile ที่เกี่ยวข้องpython3.12 , latest (DockerFile)python3.11 , (Dockerfile)python3.10 , (Dockerfile)python3.9 , (Dockerfile) แท็กเหล่านี้ไม่ได้รับการสนับสนุนหรือบำรุงรักษาอีกต่อไปพวกเขาจะถูกลบออกจากที่เก็บ GitHub แต่เวอร์ชันสุดท้ายที่ผลักดันอาจยังคงมีอยู่ใน Docker Hub หากใครก็ตามที่ดึงพวกเขา:
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
Docker Image กับ UWSGI และ NGINX สำหรับเว็บแอปพลิเคชันใน Python (เป็น ขวด ) ในคอนเทนเนอร์เดียว
ภาพ นักเทียบ ท่านี้ช่วยให้คุณสร้างแอปพลิเคชันเว็บ Python ที่ทำงานกับ UWSGI และ NGINX ในคอนเทนเนอร์เดียว
การรวมกันของ UWSGI กับ Nginx เป็นวิธีทั่วไปในการปรับใช้แอปพลิเคชันเว็บ Python เช่น Flask และ Django มีการใช้กันอย่างแพร่หลายในอุตสาหกรรมและจะให้ประสิทธิภาพที่ดีแก่คุณ -
ภาพนี้ถูกสร้างขึ้นเพื่อเป็นภาพพื้นฐานสำหรับ tiangolo/uwsgi-nginx-flask แต่สามารถใช้เป็นภาพพื้นฐานสำหรับแอปพลิเคชั่น Python Web (WSGI ที่ใช้) อื่น ๆ เช่น Django
หากคุณกำลังเริ่มโครงการใหม่คุณอาจได้รับประโยชน์จากเฟรมเวิร์กที่ใหม่กว่าและเร็วขึ้นตาม ASGI แทนที่จะเป็น WSGI (Flask and Django เป็นอิง WSGI)
คุณสามารถใช้กรอบ ASGI เช่น:
fastapi หรือ starlette จะให้ประสิทธิภาพประมาณ 800% (8x) ที่สามารถทำได้ด้วยภาพนี้ ( Tiangolo/Uwsgi-Nginx ) คุณสามารถดูเกณฑ์มาตรฐานของบุคคลที่สามได้ที่นี่
นอกจากนี้หากคุณต้องการใช้เทคโนโลยีใหม่ ๆ เช่น WebSockets มันจะง่ายกว่า (และ เป็นไปได้ ) ด้วยเฟรมเวิร์กใหม่ที่ใช้ ASGI เช่น Fastapi หรือ Starlette เนื่องจาก ASGI มาตรฐานได้รับการออกแบบให้สามารถจัดการรหัสแบบอะซิงโครนัสได้เช่นเดียวกับที่จำเป็นสำหรับ WebSockets
หากคุณต้องการใช้เฟรมเวิร์กที่ใช้ WSGI รุ่นเก่าเช่น Flask หรือ Django (แทนที่จะเป็นสิ่งที่ใช้ ASGI) และคุณต้องมีประสิทธิภาพที่ดีที่สุดเท่าที่จะเป็นไปได้คุณสามารถใช้ภาพทางเลือก: Tiangolo/Meinheld-Gunicorn
Tiangolo/Meinheld-Gunicorn จะให้ประสิทธิภาพของภาพนี้ประมาณ 400% (4x)
GitHub repo : https://github.com/tiangolo/uwsgi-nginx-docker
Docker Hub Image : https://hub.docker.com/r/tiangolo/uwsgi-nginx/
คุณอาจใช้ Kubernetes หรือเครื่องมือที่คล้ายกัน ในกรณีนี้คุณอาจ ไม่ต้องการภาพนี้ (หรือ ภาพฐานอื่น ๆ ที่คล้ายกัน ) คุณน่าจะดีกว่าใน การสร้างภาพนักเทียบท่าตั้งแต่เริ่มต้น
หากคุณมีกลุ่มเครื่องจักรที่มี Kubernetes , Docker Swarm Mode, Nomad หรือระบบที่ซับซ้อนอื่น ๆ ที่คล้ายกันเพื่อจัดการคอนเทนเนอร์แบบกระจายในหลายเครื่องคุณอาจต้องการ จัดการการจำลองแบบ ที่ ระดับคลัสเตอร์ แทนที่จะใช้ตัว จัดการ กระบวนการ ในแต่ละคอนเทนเนอร์
ในกรณีเหล่านั้น (เช่นการใช้ Kubernetes) คุณอาจต้องการสร้าง อิมเมจนักเทียบท่าตั้งแต่เริ่มต้น การติดตั้งการพึ่งพาของคุณและเรียกใช้ กระบวนการเดียว แทนภาพนี้
ตัวอย่างเช่นการใช้ 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 ดังนั้นคุณจะไม่มีวิธีที่ง่ายในการจัดการการจำลองแบบของคอนเทนเนอร์ (พร้อม Docker Compose) ในขณะที่รักษาเครือข่ายที่ ใช้ ร่วมกัน
จากนั้นคุณอาจต้องการมี คอนเทนเนอร์เดียว ที่มี ตัวจัดการกระบวนการ เริ่มต้น กระบวนการของคนงานหลายอย่าง ภายในเช่นเดียวกับภาพนักเทียบท่านี้
คุณอาจมี เหตุผลอื่น ๆ ที่จะทำให้ง่ายขึ้นที่จะมี คอนเทนเนอร์เดียว ที่มี หลายกระบวนการ แทนที่จะมี คอนเทนเนอร์หลายตัว ที่มี กระบวนการเดียว ในแต่ละอัน
ตัวอย่างเช่น (ขึ้นอยู่กับการตั้งค่าของคุณ) คุณอาจมีเครื่องมือบางอย่างเช่นผู้ส่งออก Prometheus ในคอนเทนเนอร์เดียวกันกับที่ควรเข้าถึง คำขอแต่ละคำขอ ที่มา
ในกรณีนี้หากคุณมี คอนเทนเนอร์หลายตัว โดยค่าเริ่มต้นเมื่อ Prometheus มา อ่านตัวชี้วัด มันจะได้รับ คอนเทนเนอร์เดียวในแต่ละครั้ง (สำหรับคอนเทนเนอร์ที่จัดการคำขอนั้น) แทนที่จะได้รับ การวัดสะสม สำหรับภาชนะที่จำลองทั้งหมด
จากนั้นในกรณีนั้นอาจง่ายกว่าที่จะมี คอนเทนเนอร์หนึ่งอัน ที่มี หลายกระบวนการ และเครื่องมือท้องถิ่น (เช่นผู้ส่งออกโพร) ในคอนเทนเนอร์เดียวกันที่รวบรวมตัวชี้วัดโพรโพรสำหรับกระบวนการภายในทั้งหมดและเปิดเผยตัวชี้วัดเหล่านั้นในภาชนะเดียวนั้น
อ่านเพิ่มเติมเกี่ยวกับมันทั้งหมดในเอกสาร Fastapi เกี่ยวกับ: fastapi ในคอนเทนเนอร์ - Docker เป็นแนวคิดเดียวกันนี้ใช้กับเว็บแอปพลิเคชันอื่น ๆ ในคอนเทนเนอร์
คุณไม่ต้องโคลน repo นี้
คุณสามารถใช้ภาพนี้เป็นภาพพื้นฐานสำหรับภาพอื่น ๆ
สมมติว่าคุณมี requirements.txt ไฟล์ 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... โดยค่าเริ่มต้นจะพยายามค้นหาไฟล์กำหนดค่า UWSGI ใน /app/uwsgi.ini
ไฟล์ uwsgi.ini นั้นจะพยายามเรียกใช้ไฟล์ Python ใน /app/main.py
หากคุณกำลังสร้างเว็บแอปพลิ เคชันขวด คุณควรใช้แทน tiangolo/uwsgi-nginx-flask
หากคุณต้องการใช้ไดเรกทอรีสำหรับแอปของคุณที่แตกต่างจาก /app คุณสามารถแทนที่เส้นทางไฟล์ config UWSGI ด้วยตัวแปรสภาพแวดล้อม UWSGI_INI และใส่ไฟล์ uwsgi.ini ที่กำหนดเองที่นั่น
ตัวอย่างเช่นหากคุณต้องการให้ไดเรกทอรีแอปพลิเคชันของคุณอยู่ใน /application แทน /app Dockerfile ของคุณจะเป็นเช่น:
FROM tiangolo/uwsgi-nginx:python3.12
ENV UWSGI_INI /application/uwsgi.ini
COPY ./application /application
WORKDIR /appapplication และไฟล์ uwsgi.ini ของคุณใน ./application/uwsgi.ini จะมี:
[uwsgi]
wsgi-file =/application/main.py หมายเหตุ : เป็นสิ่งสำคัญที่จะต้องรวมตัวเลือก WORKDIR มิฉะนั้น UWSGI จะเริ่มแอปพลิเคชันใน /app
โดยค่าเริ่มต้นภาพเริ่มต้นด้วย 2 กระบวนการ UWSGI ที่ทำงานอยู่ เมื่อเซิร์ฟเวอร์กำลังรับภาระสูงจะสร้างกระบวนการ UWSGI สูงสุด 16 กระบวนการเพื่อจัดการกับความต้องการ
หากคุณต้องการกำหนดค่าตัวเลขเหล่านี้คุณสามารถใช้ตัวแปรสภาพแวดล้อม
จำนวนเริ่มต้นของกระบวนการ UWSGI ถูกควบคุมโดยตัวแปร UWSGI_CHEAPER โดยค่าเริ่มต้นตั้งค่าเป็น 2
จำนวนสูงสุดของกระบวนการ UWSGI ถูกควบคุมโดยตัวแปร UWSGI_PROCESSES โดยค่าเริ่มต้นตั้งค่าเป็น 16
โปรดทราบว่า 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 CONFIC client_max_body_size
ตัวอย่างเช่นหากคุณต้องการตั้งค่าขนาดไฟล์อัพโหลดสูงสุดเป็น 1 MB (ค่าเริ่มต้นในการติดตั้ง 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 และมันจะรอ 10 วินาทีเพื่อให้ฐานข้อมูลเริ่มต้นจากนั้นเรียกใช้คำสั่ง alembic นั้น (คุณสามารถอัปเดตเพื่อเรียกใช้การย้ายถิ่นของ 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 และจะพยายามตรวจจับจำนวนซีพียูที่มีอยู่โดยอัตโนมัติและใช้สำหรับจำนวนคนงาน
ตัวอย่างเช่นการใช้ 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 เพิ่มเติมคุณสามารถเพิ่ม *.conf ไฟล์ไปที่ /etc/nginx/conf.d/ ใน Dockerfile ของคุณ
เพียงจำไว้ว่าการกำหนดค่าเริ่มต้นจะถูกสร้างขึ้นระหว่างการเริ่มต้นในไฟล์ที่ /etc/nginx/conf.d/nginx.conf และ /etc/nginx/conf.d/upload.conf ดังนั้นคุณไม่ควรเขียนทับพวกเขา คุณควรตั้งชื่อไฟล์ *.conf ของคุณด้วยสิ่งที่แตกต่างจาก nginx.conf หรือ upload.conf ตัวอย่างเช่น: custom.conf
หมายเหตุ : หากคุณปรับแต่ง Nginx อาจคัดลอกการกำหนดค่าจากบล็อกหรือคำตอบ stackoverflow โปรดทราบว่าคุณอาจต้องใช้การกำหนดค่าเฉพาะกับ UWSGI แทนที่จะเป็นโมดูลอื่น ๆ เช่น ngx_http_fastcgi_module
หากคุณต้องการกำหนดค่า NGINX ให้ดียิ่งขึ้นการเอาชนะค่าเริ่มต้นอย่างสมบูรณ์คุณสามารถเพิ่มการกำหนดค่า NGINX ที่กำหนดเองให้กับ /app/nginx.conf
มันจะถูกคัดลอกไปยัง /etc/nginx/nginx.conf และใช้แทนสิ่งที่สร้างขึ้น
โปรดทราบว่าในกรณีนี้ภาพนี้จะไม่สร้างการกำหนดค่า NGINX ใด ๆ มันจะคัดลอกและใช้ไฟล์การกำหนดค่าของคุณเท่านั้น
นั่นหมายความว่าตัวแปรสภาพแวดล้อมทั้งหมดที่อธิบายไว้ข้างต้นซึ่งเฉพาะเจาะจงกับ Nginx จะไม่ถูกนำมาใช้
นอกจากนี้ยังหมายความว่าจะไม่ใช้การกำหนดค่าเพิ่มเติมจากไฟล์ใน /etc/nginx/conf.d/*.conf เว้นแต่คุณจะมีส่วนอย่างชัดเจนในไฟล์ที่คุณกำหนดเอง /app/nginx.conf ด้วย:
include /etc/nginx/conf.d/*.conf;
หากคุณต้องการเพิ่มไฟล์ /app/nginx.conf ที่กำหนดเอง แต่ไม่ทราบว่าจะเริ่มจากตรงไหนคุณสามารถใช้ nginx.conf ที่ใช้สำหรับการทดสอบและปรับแต่งหรือปรับเปลี่ยนเพิ่มเติม
การรวมกันของ UWSGI กับ Nginx เป็นวิธีทั่วไปในการปรับใช้แอปพลิเคชันเว็บ Python
ประมาณ:
Nginx เป็นเว็บเซิร์ฟเวอร์ดูแลการเชื่อมต่อ HTTP และยังสามารถให้บริการไฟล์คงที่โดยตรงและมีประสิทธิภาพมากขึ้น
UWSGI เป็นแอปพลิเคชันเซิร์ฟเวอร์นั่นคือสิ่งที่เรียกใช้รหัส Python ของคุณและพูดคุยกับ Nginx
รหัส Python ของคุณ มีเว็บแอปพลิเคชันจริงและดำเนินการโดย UWSGI
ภาพนี้ใช้ประโยชน์จากภาพนักเทียบท่าที่มีอยู่แล้วและปรับให้เหมาะสม (ตาม Debian ตามที่นักเทียบท่าแนะนำ) และใช้แนวทางปฏิบัติที่ดีที่สุดของ Docker
มันใช้อิมเมจ Python Docker อย่างเป็นทางการติดตั้ง UWSGI และยิ่งไปกว่านั้นด้วยการดัดแปลงจำนวนน้อยที่สุดเพิ่มภาพ Nginx อย่างเป็นทางการ (ณ 2016-02-14)
และมันควบคุมกระบวนการเหล่านี้ทั้งหมดด้วยการควบคุมดูแล
มีกฎง่ายๆที่คุณควรมี "หนึ่งกระบวนการต่อคอนเทนเนอร์"
ตัวอย่างเช่นการแยกแอพและฐานข้อมูลในคอนเทนเนอร์ที่แตกต่างกัน
แต่ถ้าคุณต้องการมีวิธีการ "บริการขนาดเล็ก" คุณอาจต้องการมีกระบวนการมากกว่าหนึ่งกระบวนการในคอนเทนเนอร์เดียวหากพวกเขาทั้งหมดเกี่ยวข้องกับ "บริการ" เดียวกันและคุณอาจต้องการรวมรหัสขวดของคุณ UWSGI และ NGINX ในคอนเทนเนอร์เดียวกัน (และอาจเรียกใช้คอนเทนเนอร์อื่นด้วยฐานข้อมูลของคุณ)
นั่นคือวิธีการที่ใช้ในภาพนี้
ภาพนี้มีแอปตัวอย่างเริ่มต้น "Hello World" ในไดเรกทอรีของคอนเทนเนอร์ /app โดยใช้ตัวอย่างในเอกสาร UWSGI
คุณอาจต้องการแทนที่หรือลบในโครงการของคุณ
มันอยู่ที่นั่นในกรณีที่คุณเรียกใช้ภาพนี้ด้วยตัวเองและไม่ใช่ภาพพื้นฐานสำหรับ Dockerfile ของคุณเองเพื่อให้คุณได้รับแอปตัวอย่างโดยไม่มีข้อผิดพลาด
กล่าวโดยย่อ: คุณอาจไม่ควรใช้อัลไพน์สำหรับโครงการ Python แทนที่จะใช้เวอร์ชันอิมเมจ Docker slim
คุณต้องการรายละเอียดเพิ่มเติมหรือไม่? อ่านต่อ?
อัลไพน์มีประโยชน์มากกว่าสำหรับภาษาอื่น ๆ ที่คุณสร้างไบนารีแบบคงที่ในเวทีภาพนักเทียบท่าหนึ่ง (ใช้การสร้างท่าเทียบเรือหลายขั้นตอน) จากนั้นคัดลอกไปยังภาพอัลไพน์ที่เรียบง่ายแล้วดำเนินการไบนารีนั้น ตัวอย่างเช่นการใช้ไป
แต่สำหรับ Python เนื่องจากอัลไพน์ไม่ได้ใช้เครื่องมือมาตรฐานที่ใช้ในการสร้างส่วนขยาย Python เมื่อติดตั้งแพ็คเกจในหลายกรณี Python ( pip ) จะไม่พบแพ็คเกจที่ติดตั้งได้แบบ preompiled ("ล้อ") สำหรับอัลไพน์ และหลังจากการดีบักข้อผิดพลาดแปลก ๆ มากมายคุณจะรู้ว่าคุณต้องติดตั้งเครื่องมือพิเศษจำนวนมากและสร้างการพึ่งพาจำนวนมากเพื่อใช้แพ็คเกจ Python ทั่วไปเหล่านี้ -
ซึ่งหมายความว่าแม้ว่าภาพอัลไพน์ดั้งเดิมอาจมีขนาดเล็ก แต่คุณก็จบลงด้วยภาพที่มีขนาดเทียบได้กับขนาดที่คุณจะได้รับหากคุณเพิ่งใช้ภาพงูหลามมาตรฐาน (อิงตาม Debian) หรือในบางกรณี -
และในทุกกรณีมันจะใช้เวลานานกว่าในการสร้างใช้ทรัพยากรมากขึ้นการสร้างการพึ่งพานานขึ้นและยังเพิ่มการปล่อยก๊าซคาร์บอนไดออกไซด์ในขณะที่คุณใช้เวลาและพลังงานของซีพียูมากขึ้นสำหรับการสร้างแต่ละครั้ง -
หากคุณต้องการรูปภาพ Python ที่เพรียวบางคุณควรลองและใช้เวอร์ชัน slim ที่ยังคงใช้ Debian แต่มีขนาดเล็กลง -
แท็กรูปภาพทั้งหมดการกำหนดค่าตัวแปรสภาพแวดล้อมและตัวเลือกแอปพลิเคชันได้รับการทดสอบ
มีการประกาศการอัปเดตในรุ่น
คุณสามารถคลิกปุ่ม "ดู" ที่ด้านบนขวาและเลือก "รีลีสเท่านั้น" เพื่อรับการแจ้งเตือนทางอีเมลเมื่อมีการเปิดตัวใหม่
*.pyc ด้วย PYTHONDONTWRITEBYTECODE=1 และตรวจสอบให้แน่ใจว่าบันทึกจะถูกพิมพ์ทันทีด้วย PYTHONUNBUFFERED=1 PR #208 โดย @esterbanx64 EXPOSE พอร์ต 80 และ 443 โดยค่าเริ่มต้นเนื่องจากสามารถปรับแต่งได้ PR #227 โดย @tiangolo issue-manager.yml PR #226 โดย @tiangololatest-changes ของ GitHub PR #214 โดย @tiangololatest-changes.yml PR #201 โดย @alejsdevREADME.md PR #199 โดย @alejsdev ไฮไลท์ของรุ่นนี้:
python3.6-2022-11-25 และ python2.7-2022-11-252.0.20 PR #127 โดย @tiangolo1.17.10 ขึ้นอยู่กับ Debian ล่าสุด Buster PR #822020-05-042019-10-14:
2019-09-28:
tiangolo/uwsgi-nginx:python3.7-2019-09-28 PR #65อัพเกรดเทรวิส PR #60
/app/prestart.sh สคริปต์เพื่อเรียกใช้รหัสโดยพลการก่อนที่จะเริ่มแอป (ตัวอย่างเช่น Alembic - Sqlalchemy Migrations) เอกสารสำหรับ /app/prestart.sh อยู่ใน readme หลัก PR #592019-05-04:
2019-02-02:
/app/nginx.conf ที่แทนที่ไฟล์ที่สร้างขึ้น PR #512018-11-23: อัลไพน์ใหม่ 3.8 ภาพสำหรับ Python 2.7, Python 3.6 และ Python 3.7 (Python 3.7 ปิดใช้งานชั่วคราว) ขอบคุณ Philippfreyer ใน PR #45
2018-09-22: Python 3.7 รุ่นใหม่, มาตรฐานและอัลไพน์ ขอบคุณ DesaintMartin ในการประชาสัมพันธ์นี้
2018-06-22: ตอนนี้คุณสามารถใช้ NGINX_WORKER_CONNECTIONS เพื่อตั้งค่าจำนวนสูงสุดของการเชื่อมต่อคนงาน Nginx และ NGINX_WORKER_OPEN_FILES เพื่อตั้งค่าจำนวนสูงสุดของไฟล์ที่เปิด ขอบคุณ Ronlut ในการประชาสัมพันธ์นี้
2018-06-22: ทำให้ UWSGI ต้องการแอพที่จะเรียกใช้แทนที่จะไปใน "โหมดไดนามิกเต็ม" ในขณะที่มีข้อผิดพลาด Supervisord ไม่ได้ยุติตัวเอง แต่พยายามรีสตาร์ท UWSGI และแสดงข้อผิดพลาด ใช้ need-app ตามที่ LuckyDonald แนะนำในความคิดเห็นนี้
2018-06-22: จัดการอย่างถูกต้องอย่างถูกต้องของ UWSGI และ NGINX ขอบคุณ DesaintMartin ในการประชาสัมพันธ์นี้
2018-02-04: ตอนนี้เป็นไปได้ที่จะตั้งค่าจำนวนกระบวนการ Nginx Worker ด้วยตัวแปรสภาพแวดล้อม NGINX_WORKER_PROCESSES ขอบคุณ Naktinis ในการประชาสัมพันธ์นี้
2018-01-14: ขณะนี้มีสองรุ่นที่ใช้อัลไพน์คือ python2.7-alpine3.7 และ python3.6-alpine3.7
2017-12-08: ตอนนี้คุณสามารถกำหนดค่าพอร์ตที่คอนเทนเนอร์ควรฟังโดยใช้ตัวแปรสภาพแวดล้อม LISTEN_PORT ด้วย TMSHN ใน PR นี้
2017-08-09: คุณสามารถตั้งค่าขนาดไฟล์อัพโหลดสูงสุดที่กำหนดเองโดยใช้ตัวแปรสภาพแวดล้อม NGINX_MAX_UPLOAD โดยค่าเริ่มต้นจะมีค่า 0 ซึ่งอนุญาตให้ขนาดไฟล์อัปโหลดไม่ จำกัด สิ่งนี้แตกต่างจากค่าเริ่มต้นของ Nginx ที่ 1 MB มันได้รับการกำหนดค่าด้วยวิธีนี้เพราะนั่นเป็นประสบการณ์ที่ง่ายที่สุดสำหรับนักพัฒนาที่ไม่ได้เป็นผู้เชี่ยวชาญใน Nginx ที่คาดหวัง
2017-08-09: ตอนนี้คุณสามารถแทนที่ว่าจะค้นหาไฟล์ uwsgi.ini ได้ที่ไหนและด้วยการเปลี่ยนไดเรกทอรีเริ่มต้นจาก /app เป็นอย่างอื่นโดยใช้ตัวแปร envirnoment UWSGI_INI
2017-08-08: มีภาพแท็ก latest ใหม่เพียงเพื่อแสดงคำเตือนสำหรับผู้ที่ยังคงใช้ latest สำหรับแอปพลิเคชันเว็บ Python 2.7 ณ ตอนนี้ทุกคนควรใช้ Python 3
2017-08-08: Supervisord ตอนนี้ยุติ UWSGI ใน SIGTERM ดังนั้นหากคุณเรียกใช้ docker stop หรือสิ่งที่คล้ายกันจริง ๆ แล้วมันจะหยุดทุกอย่างแทนที่จะรอการหมดเวลาของ Docker เพื่อฆ่าตู้คอนเทนเนอร์
2017-07-31: ตอนนี้มีแท็กรูปภาพสำหรับ Python 3.6 ตามภาพอย่างเป็นทางการสำหรับ Python 3.6 ขอบคุณ JRD ใน PR นี้
2016-10-01: ตอนนี้คุณสามารถแทนที่พารามิเตอร์ uwsgi.ini เริ่มต้นจากไฟล์ใน /app/uwsgi.ini
2016-08-16: ตอนนี้มีแท็กรูปภาพสำหรับ Python 3.5 ตามภาพอย่างเป็นทางการสำหรับ Python 3.5 ดังนั้นตอนนี้คุณสามารถใช้ภาพนี้สำหรับโครงการของคุณใน Python 2.7 และ Python 3.5
2016-08-16: ใช้ไดนามิกของกระบวนการคนงานจำนวนมากสำหรับ UWSGI ตั้งแต่ 2 ถึง 16 ขึ้นอยู่กับการโหลด สิ่งนี้ควรใช้งานได้สำหรับกรณีส่วนใหญ่ สิ่งนี้จะช่วยได้โดยเฉพาะอย่างยิ่งเมื่อมีการตอบสนองบางอย่างที่ช้าและใช้เวลาในการสร้างการเปลี่ยนแปลงนี้จะช่วยให้การตอบสนองอื่น ๆ ทั้งหมดช่วยให้เร็ว (ในกระบวนการใหม่) โดยไม่ต้องรอการทำครั้งแรก (ช้า) ครั้งแรก
นอกจากนี้ตอนนี้ยังใช้ไฟล์ uwsgi.ini พื้นฐานภายใต้ /etc/uwsgi/ กับการกำหนดค่าทั่วไปส่วนใหญ่ดังนั้น uwsgi.ini ภายใน /app (แอปที่คุณต้องการแก้ไข) ตอนนี้ง่ายขึ้นมาก
2016-04-05: บันทึก Nginx และ UWSGI ตอนนี้ถูกเปลี่ยนเส้นทางไปยัง stdout ทำให้สามารถใช้ docker logs
โครงการนี้ได้รับใบอนุญาตภายใต้ข้อกำหนดของใบอนุญาต Apache
