uwsgi nginx docker
2.1.0
Dockerfile masing -masingpython3.12 , latest (DockerFile)python3.11 , (Dockerfile)python3.10 , (Dockerfile)python3.9 , (Dockerfile) Tag ini tidak lagi didukung atau dipelihara, mereka dihapus dari repositori GitHub, tetapi versi terakhir yang didorong mungkin masih tersedia di Docker Hub jika ada yang menariknya:
python3.8python3.8-alpinepython3.7python3.6python2.7Tag tanggal terakhir untuk versi ini adalah:
python3.8-2024-10-28python3.8-alpine-2024-03-11python3.7-2024-10-28python3.6-2022-11-25python2.7-2022-11-25 Catatan : Ada tag untuk setiap tanggal pembuatan. Jika Anda perlu "menyematkan" versi gambar Docker yang Anda gunakan, Anda dapat memilih salah satu tag tersebut. Misalnya tiangolo/uwsgi-nginx:python3.12-2024-11-02 .
Gambar Docker dengan UWSGI dan Nginx untuk aplikasi web di Python (sebagai Flask ) dalam satu wadah.
Gambar Docker ini memungkinkan Anda untuk membuat aplikasi web Python yang berjalan dengan UWSGI dan Nginx dalam satu wadah.
Kombinasi UWSGI dengan Nginx adalah cara umum untuk menggunakan aplikasi web Python seperti Flask dan Django. Ini banyak digunakan dalam industri dan akan memberi Anda kinerja yang layak. (*)
Gambar ini dibuat untuk menjadi gambar dasar untuk Tiangolo/UWSGI-NGINX-Flask tetapi dapat digunakan sebagai gambar dasar untuk aplikasi web Python (WSGI) lainnya, seperti Django.
Jika Anda memulai proyek baru, Anda mungkin mendapat manfaat dari kerangka kerja yang lebih baru dan lebih cepat berdasarkan ASGI alih-alih WSGI (Flask dan Django berbasis WSGI).
Anda bisa menggunakan kerangka kerja ASGI seperti:
Fastapi, atau Starlette, akan memberi Anda sekitar 800% (8x) kinerja yang dapat dicapai dengan gambar ini ( tiangolo/uwsgi-nginx ). Anda dapat melihat tolok ukur pihak ketiga di sini.
Juga, jika Anda ingin menggunakan teknologi baru seperti WebSockets, itu akan lebih mudah (dan mungkin ) dengan kerangka kerja yang lebih baru berdasarkan ASGI, seperti Fastapi atau Starlette. Karena standar ASGI dirancang untuk dapat menangani kode asinkron seperti yang dibutuhkan untuk websockets.
Jika Anda perlu menggunakan kerangka kerja berbasis WSGI yang lebih lama seperti Flask atau Django (bukan sesuatu yang didasarkan pada ASGI) dan Anda perlu memiliki kinerja terbaik, Anda dapat menggunakan gambar alternatif: Tiangolo/Meinheld-Gunicorn .
Tiangolo/Meinheld-Gunicorn akan memberi Anda sekitar 400% (4x) kinerja gambar ini.
Github Repo : https://github.com/tiangolo/uwsgi-nginx-docker
Gambar Hub Docker : https://hub.docker.com/r/tiangolo/uwsgi-nginx/
Anda mungkin menggunakan kubernet atau alat serupa. Dalam hal ini, Anda mungkin tidak memerlukan gambar ini (atau gambar dasar serupa lainnya). Anda mungkin lebih baik membangun gambar Docker dari awal .
Jika Anda memiliki sekelompok mesin dengan Kubernetes , Docker Swarm Mode, NOMAD, atau sistem kompleks serupa lainnya untuk mengelola wadah terdistribusi pada beberapa mesin, maka Anda mungkin ingin menangani replikasi pada level cluster alih -alih menggunakan manajer proses di setiap wadah yang memulai beberapa proses pekerja , yang merupakan apa yang dilakukan oleh gambar Docker ini.
Dalam kasus tersebut (misalnya menggunakan Kubernetes) Anda mungkin ingin membangun gambar Docker dari awal , memasang dependensi Anda, dan menjalankan satu proses alih -alih gambar ini.
Misalnya, menggunakan Gunicorn Anda bisa memiliki app/gunicorn_conf.py dengan:
# Gunicorn config variables
loglevel = "info"
errorlog = "-" # stderr
accesslog = "-" # stdout
worker_tmp_dir = "/dev/shm"
graceful_timeout = 120
timeout = 120
keepalive = 5
threads = 3 Dan kemudian Anda bisa memiliki Dockerfile dengan:
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" ]Anda dapat membaca lebih lanjut tentang ide -ide ini dalam dokumentasi FASTAPI tentang: FASTAPI dalam wadah - Docker karena ide -ide yang sama akan berlaku untuk aplikasi web lain dalam wadah.
Anda dapat menginginkan manajer proses yang menjalankan beberapa proses pekerja dalam wadah jika aplikasi Anda cukup sederhana sehingga Anda tidak perlu (setidaknya belum) untuk menyempurnakan jumlah proses terlalu banyak, dan Anda bisa menggunakan default otomatis, dan Anda menjalankannya pada satu server , bukan cluster.
Anda bisa digunakan ke server tunggal (bukan cluster) dengan Docker Compose , jadi Anda tidak akan memiliki cara mudah untuk mengelola replikasi wadah (dengan Docker Compose) sambil melestarikan jaringan bersama dan menyeimbangkan beban .
Maka Anda ingin memiliki satu wadah dengan manajer proses yang memulai beberapa proses pekerja di dalamnya, seperti gambar Docker ini.
Anda juga dapat memiliki alasan lain yang akan membuatnya lebih mudah untuk memiliki satu wadah dengan beberapa proses daripada memiliki beberapa wadah dengan satu proses di masing -masing.
Misalnya (tergantung pada pengaturan Anda), Anda dapat memiliki beberapa alat seperti Exporter Prometheus di wadah yang sama yang seharusnya memiliki akses ke masing -masing permintaan yang datang.
Dalam hal ini, jika Anda memiliki banyak kontainer , secara default, ketika Prometheus datang untuk membaca metrik , itu akan mendapatkan yang untuk satu wadah setiap kali (untuk wadah yang menangani permintaan tertentu), alih -alih mendapatkan metrik yang terakumulasi untuk semua wadah yang direplikasi.
Kemudian, dalam hal ini, bisa lebih sederhana untuk memiliki satu wadah dengan banyak proses , dan alat lokal (misalnya eksportir Prometheus) pada wadah yang sama yang mengumpulkan metrik Prometheus untuk semua proses internal dan memaparkan metrik tersebut pada wadah tunggal itu.
Baca lebih lanjut tentang semuanya dalam dokumentasi FastAPI tentang: Fastapi dalam wadah - Docker, karena konsep yang sama berlaku untuk aplikasi web lain dalam wadah.
Anda tidak perlu mengkloning repo ini.
Anda dapat menggunakan gambar ini sebagai gambar dasar untuk gambar lain.
Dengan asumsi Anda memiliki file requirements.txt , Anda dapat memiliki Dockerfile seperti ini:
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... Secara default, ia akan mencoba menemukan file konfigurasi UWSGI di /app/uwsgi.ini .
File uwsgi.ini itu akan membuatnya mencoba menjalankan file Python di /app/main.py .
Jika Anda sedang membangun aplikasi web Flask , Anda harus menggunakan tiangolo/UWSGI-NGINX-Flask .
Jika Anda perlu menggunakan direktori untuk aplikasi Anda berbeda dari /app , Anda dapat mengganti jalur file konfigurasi UWSGI dengan variabel lingkungan UWSGI_INI , dan meletakkan file uwsgi.ini khusus Anda di sana.
Misalnya, jika Anda perlu memiliki direktori aplikasi Anda di /application alih -alih /app , Dockerfile Anda akan terlihat seperti:
FROM tiangolo/uwsgi-nginx:python3.12
ENV UWSGI_INI /application/uwsgi.ini
COPY ./application /application
WORKDIR /appapplication Dan file uwsgi.ini Anda di ./application/uwsgi.ini akan berisi:
[uwsgi]
wsgi-file =/application/main.py Catatan : Penting untuk memasukkan opsi WORKDIR , jika tidak, UWSGI akan memulai aplikasi di /app .
Secara default, gambar dimulai dengan 2 proses UWSGI berjalan. Ketika server mengalami beban tinggi, itu membuat hingga 16 proses UWSGI untuk menanganinya sesuai permintaan.
Jika Anda perlu mengkonfigurasi angka -angka ini, Anda dapat menggunakan variabel lingkungan.
Jumlah awal proses UWSGI dikendalikan oleh variabel UWSGI_CHEAPER , secara default diatur ke 2 .
Jumlah maksimum proses UWSGI dikendalikan oleh variabel UWSGI_PROCESSES , secara default diatur ke 16 .
Perlu diingat bahwa UWSGI_CHEAPER harus lebih rendah dari UWSGI_PROCESSES .
Jadi, jika, misalnya, Anda harus memulai dengan 4 proses dan tumbuh hingga maksimal 64, Dockerfile Anda bisa terlihat seperti:
FROM tiangolo/uwsgi-nginx:python3.12
ENV UWSGI_CHEAPER 4
ENV UWSGI_PROCESSES 64
COPY ./app /appPada gambar ini, Nginx dikonfigurasi untuk memungkinkan ukuran file unggahan tanpa batas. Ini dilakukan karena secara default server Python sederhana akan mengizinkannya, jadi itu adalah perilaku paling sederhana yang diharapkan pengembang.
Jika Anda perlu membatasi ukuran unggahan maksimum di NginX, Anda dapat menambahkan variabel lingkungan NGINX_MAX_UPLOAD dan menetapkan nilai yang sesuai dengan Nginx Config client_max_body_size standar.
Misalnya, jika Anda ingin mengatur ukuran file unggahan maksimum ke 1 MB (default dalam instalasi Nginx normal), Anda perlu mengatur variabel lingkungan NGINX_MAX_UPLOAD ke nilai 1m . Maka gambar akan mengurus menambahkan file konfigurasi yang sesuai (ini dilakukan oleh entrypoint.sh ).
Jadi, Dockerfile Anda akan terlihat seperti:
FROM tiangolo/uwsgi-nginx:python3.12
ENV NGINX_MAX_UPLOAD 1m
COPY ./app /appSecara default, wadah yang dibuat dari gambar ini akan mendengarkan di port 80.
Untuk mengubah perilaku ini, atur variabel lingkungan LISTEN_PORT .
Anda mungkin juga perlu membuat instruksi EXPOSE Docker masing -masing.
Anda dapat melakukannya di Dockerfile Anda, itu akan terlihat seperti:
FROM tiangolo/uwsgi-nginx:python3.12
ENV LISTEN_PORT 8080
EXPOSE 8080
COPY ./app /app/app/prestart.sh Jika Anda perlu menjalankan apa pun sebelum memulai aplikasi, Anda dapat menambahkan file prestart.sh ke direktori /app . Gambar akan secara otomatis mendeteksi dan menjalankannya sebelum memulai semuanya.
Misalnya, jika Anda ingin menambahkan migrasi basis data yang dijalankan saat startup (misalnya dengan alembic, atau migrasi django), sebelum memulai aplikasi, Anda dapat membuat file ./app/prestart.sh di direktori kode Anda (yang akan disalin oleh Dockerfile Anda) dengan:
#! /usr/bin/env bash
# Let the DB start
sleep 10 ;
# Run migrations
alembic upgrade head Dan itu akan menunggu 10 detik untuk memberikan database waktu untuk memulai dan kemudian menjalankan perintah alembic itu (Anda dapat memperbaruinya untuk menjalankan migrasi Django atau alat lain yang Anda butuhkan).
Jika Anda perlu menjalankan skrip python sebelum memulai aplikasi, Anda dapat membuat file /app/prestart.sh menjalankan skrip python Anda, dengan sesuatu seperti:
#! /usr/bin/env bash
# Run custom Python script before starting
python /app/my_custom_prestart_script.py Catatan : Gambar digunakan . Untuk menjalankan skrip (seperti di . /app/prestart.sh ), jadi misalnya, variabel lingkungan akan bertahan. Jika Anda tidak memahami kalimat sebelumnya, Anda mungkin tidak membutuhkannya.
Secara default, Nginx akan memulai satu "proses pekerja".
Jika Anda ingin menetapkan jumlah proses pekerja Nginx yang berbeda, Anda dapat menggunakan variabel lingkungan, NGINX_WORKER_PROCESSES .
Anda dapat menggunakan nomor tunggal tertentu, misalnya:
ENV NGINX_WORKER_PROCESSES 2 Atau Anda dapat mengaturnya ke kata kunci auto dan akan mencoba secara otomatiskan jumlah CPU yang tersedia dan menggunakannya untuk jumlah pekerja.
Misalnya, menggunakan auto , DockerFile Anda bisa terlihat seperti:
FROM tiangolo/uwsgi-nginx:python3.12
ENV NGINX_WORKER_PROCESSES auto
COPY ./app /appSecara default, Nginx akan mulai dengan batas maksimum 1024 koneksi per pekerja.
Jika Anda ingin mengatur nomor yang berbeda, Anda dapat menggunakan variabel lingkungan NGINX_WORKER_CONNECTIONS , misalnya:
ENV NGINX_WORKER_CONNECTIONS 2048Itu tidak dapat melebihi batas saat ini pada jumlah maksimum file terbuka. Lihat cara mengkonfigurasinya di bagian selanjutnya.
Koneksi angka per pekerja nginx tidak dapat melebihi batas pada jumlah maksimum file terbuka.
Anda dapat mengubah batas file terbuka dengan variabel lingkungan NGINX_WORKER_OPEN_FILES , misalnya:
ENV NGINX_WORKER_OPEN_FILES 2048 Jika Anda perlu mengkonfigurasi NGINX lebih lanjut, Anda dapat menambahkan file *.conf ke /etc/nginx/conf.d/ di Dockerfile Anda.
Cukup ingat bahwa konfigurasi default dibuat selama startup dalam file di /etc/nginx/conf.d/nginx.conf dan /etc/nginx/conf.d/upload.conf . Jadi Anda tidak boleh menimpanya. Anda harus memberi nama file *.conf Anda dengan sesuatu yang berbeda dari nginx.conf atau upload.conf , misalnya: custom.conf .
Catatan : Jika Anda menyesuaikan Nginx, mungkin menyalin konfigurasi dari blog atau jawaban stackoverflow, mengingat bahwa Anda mungkin perlu menggunakan konfigurasi khusus untuk UWSGI, bukannya untuk modul lain, seperti misalnya, ngx_http_fastcgi_module .
Jika Anda perlu mengkonfigurasi NGINX lebih jauh, sepenuhnya mengesampingkan default, Anda dapat menambahkan konfigurasi NGINX khusus ke /app/nginx.conf .
Ini akan disalin ke /etc/nginx/nginx.conf dan digunakan sebagai ganti yang dihasilkan.
Perlu diingat bahwa, dalam hal ini, gambar ini tidak akan menghasilkan konfigurasi NGINX apa pun, itu hanya akan menyalin dan menggunakan file konfigurasi Anda.
Itu berarti bahwa semua variabel lingkungan yang dijelaskan di atas yang spesifik untuk nginx tidak akan digunakan.
Ini juga berarti bahwa itu tidak akan menggunakan konfigurasi tambahan dari file di /etc/nginx/conf.d/*.conf , kecuali jika Anda secara eksplisit memiliki bagian dalam file khusus /app/nginx.conf dengan:
include /etc/nginx/conf.d/*.conf;
Jika Anda ingin menambahkan file custom /app/nginx.conf tetapi tidak tahu harus mulai dari mana, Anda dapat menggunakan nginx.conf yang digunakan untuk pengujian dan menyesuaikannya atau memodifikasinya lebih lanjut.
Kombinasi UWSGI dengan Nginx adalah cara umum untuk menggunakan aplikasi web Python.
Dengan kasar:
Nginx adalah server web, ia menangani koneksi HTTP dan juga dapat menyajikan file statis secara langsung dan lebih efisien.
UWSGI adalah server aplikasi, itulah yang menjalankan kode Python Anda dan berbicara dengan Nginx.
Kode Python Anda memiliki aplikasi web yang sebenarnya, dan dijalankan oleh UWSGI.
Gambar ini memanfaatkan gambar Docker yang sudah ramping dan dioptimalkan yang ada (berdasarkan Debian seperti yang direkomendasikan oleh Docker) dan mengimplementasikan praktik terbaik Docker.
Ini menggunakan gambar Python Docker resmi, menginstal UWSGI dan di atasnya, dengan jumlah modifikasi paling sedikit, menambahkan gambar Nginx resmi (pada 2016-02-14).
Dan itu mengendalikan semua proses ini dengan pengawas.
Ada aturan praktis yang harus Anda miliki "satu proses per kontainer".
Itu membantu, misalnya, mengisolasi aplikasi dan basis data dalam wadah yang berbeda.
Tetapi jika Anda ingin memiliki pendekatan "layanan mikro", Anda mungkin ingin memiliki lebih dari satu proses dalam satu wadah jika semuanya terkait dengan "layanan" yang sama, dan Anda mungkin ingin memasukkan kode Flask Anda, UWSGI dan Nginx dalam wadah yang sama (dan mungkin menjalankan wadah lain dengan database Anda).
Itulah pendekatan yang diambil dalam gambar ini.
Gambar ini memiliki sampel default aplikasi "Hello World" di direktori wadah /app menggunakan contoh dalam dokumentasi UWSGI.
Anda mungkin ingin mengganti atau menghapusnya dalam proyek Anda.
Itu ada di sana jika Anda menjalankan gambar ini dengan sendirinya dan bukan sebagai gambar dasar untuk Dockerfile Anda sendiri, sehingga Anda mendapatkan aplikasi sampel tanpa kesalahan.
Singkatnya: Anda mungkin tidak boleh menggunakan Alpine untuk proyek Python, alih -alih menggunakan versi gambar slim Docker.
Apakah Anda ingin detail lebih lanjut? Lanjutkan Membaca?
Alpine lebih berguna untuk bahasa lain di mana Anda membangun biner statis dalam satu tahap gambar Docker (menggunakan bangunan Docker multi-tahap) dan kemudian menyalinnya ke gambar Alpine sederhana, dan kemudian hanya menjalankan biner itu. Misalnya, menggunakan Go.
Tetapi untuk Python, karena Alpine tidak menggunakan perkakas standar yang digunakan untuk membangun ekstensi Python, saat memasang paket, dalam banyak kasus Python ( pip ) tidak akan menemukan paket yang dapat diinstal (roda ") untuk alpine. Dan setelah men -debug banyak kesalahan aneh, Anda akan menyadari bahwa Anda harus menginstal banyak alat tambahan dan membangun banyak ketergantungan hanya untuk menggunakan beberapa paket Python yang umum ini. ?
Ini berarti bahwa, meskipun gambar alpine asli mungkin kecil, Anda berakhir dengan gambar dengan ukuran yang sebanding dengan ukuran yang akan Anda dapatkan jika Anda baru saja menggunakan gambar Python standar (berdasarkan Debian), atau dalam beberapa kasus bahkan lebih besar. ?
Dan dalam semua kasus tersebut, akan membutuhkan waktu lebih lama untuk membangun, mengkonsumsi lebih banyak sumber daya, membangun ketergantungan lebih lama, dan juga meningkatkan jejak karbonnya, karena Anda menggunakan lebih banyak waktu dan energi CPU untuk setiap bangunan. ?
Jika Anda ingin gambar Python ramping, Anda harus mencoba dan menggunakan versi slim yang masih didasarkan pada Debian, tetapi lebih kecil. ?
Semua tag gambar, konfigurasi, variabel lingkungan dan opsi aplikasi diuji.
Pembaruan diumumkan dalam rilis.
Anda dapat mengklik tombol "Tonton" di kanan atas dan pilih "hanya rilis" untuk menerima pemberitahuan email ketika ada rilis baru.
*.pyc yang tidak perlu dengan PYTHONDONTWRITEBYTECODE=1 dan memastikan log dicetak segera dengan PYTHONUNBUFFERED=1 . PR #208 oleh @estebanx64. EXPOSE port 80 dan 443 secara default karena dapat disesuaikan. PR #227 oleh @Tiangolo. issue-manager.yml . PR #226 oleh @Tiangolo.latest-changes . PR #214 oleh @Tiangolo.latest-changes.yml . PR #201 oleh @alejsdev.README.md . PR #199 oleh @alejsdev. Sorotan rilis ini:
python3.6-2022-11-25 dan python2.7-2022-11-25 .2.0.20 . PR #127 oleh @Tiangolo.1.17.10 , berdasarkan Debian terbaru, Buster. PR #82.2020-05-04 .2019-10-14:
2019-09-28:
tiangolo/uwsgi-nginx:python3.7-2019-09-28 . PR #65.Tingkatkan Travis. PR #60.
/app/prestart.sh skrip untuk menjalankan kode sewenang -wenang sebelum memulai aplikasi (misalnya, Alembic - Sqlalchemy Migrations). Dokumentasi untuk /app/prestart.sh ada di readme utama. PR #59.2019-05-04:
2019-02-02:
/app/nginx.conf yang mengesampingkan yang dihasilkan. PR #51.2018-11-23: Alpine 3.8 baru gambar untuk Python 2.7, Python 3.6 dan Python 3.7 (Python 3.7 dinonaktifkan sementara). Terima kasih kepada Philippfreyer di PR #45
2018-09-22: versi Python 3.7 baru, standar dan alpine berbasis. Terima kasih kepada Desaintmartin di PR ini.
2018-06-22: Anda sekarang dapat menggunakan NGINX_WORKER_CONNECTIONS untuk mengatur jumlah maksimum koneksi pekerja Nginx dan NGINX_WORKER_OPEN_FILES untuk mengatur jumlah maksimum file terbuka. Terima kasih kepada Ronlut di PR ini.
2018-06-22: Buat UWSGI memerlukan aplikasi untuk dijalankan, alih-alih masuk "mode dinamis penuh" sementara ada kesalahan. Supervisord tidak mengakhiri dirinya sendiri tetapi mencoba memulai kembali UWSGI dan menunjukkan kesalahan. Menggunakan need-app seperti yang disarankan oleh LuckyDonald dalam komentar ini.
2018-06-22: Shutdown anggun UWSGI dan NGINX yang ditangani dengan benar. Terima kasih kepada Desaintmartin di PR ini.
2018-02-04: Sekarang dimungkinkan untuk mengatur jumlah proses pekerja Nginx dengan variabel lingkungan NGINX_WORKER_PROCESSES . Terima kasih kepada Naktinis di PR ini.
2018-01-14: Sekarang ada dua versi berbasis Alpine, python2.7-alpine3.7 dan python3.6-alpine3.7 .
2017-12-08: Sekarang Anda dapat mengonfigurasi port mana yang harus didengarkan wadah, menggunakan variabel lingkungan LISTEN_PORT berkat tmshn di PR ini.
2017-08-09: Anda dapat mengatur ukuran file unggahan maksimum kustom menggunakan variabel lingkungan NGINX_MAX_UPLOAD , secara default memiliki nilai 0 , yang memungkinkan ukuran file unggah tanpa batas. Ini berbeda dari nilai default Nginx 1 MB. Ini dikonfigurasi dengan cara ini karena itu adalah pengalaman paling sederhana yang diharapkan oleh pengembang yang tidak ahli dalam Nginx.
2017-08-09: Sekarang Anda dapat mengesampingkan di mana mencari file uwsgi.ini , dan dengan itu, ubah direktori default dari /app ke sesuatu yang lain, menggunakan variabel lingkungan UWSGI_INI .
2017-08-08: Ada gambar tag latest baru, hanya untuk menunjukkan peringatan bagi mereka yang masih latest aplikasi web Python 2.7. Sampai sekarang, semua orang harus menggunakan Python 3.
2017-08-08: Supervisord sekarang mengakhiri UWSGI di SIGTERM , jadi jika Anda menjalankan docker stop atau sesuatu yang serupa, itu benar-benar akan menghentikan semuanya, alih-alih menunggu waktu tunggu Docker untuk membunuh wadah.
2017-07-31: Sekarang ada tag gambar untuk Python 3.6, berdasarkan gambar resmi untuk Python 3.6 berkat JRD di PR ini.
2016-10-01: Sekarang Anda dapat mengganti parameter uwsgi.ini default dari file di /app/uwsgi.ini .
2016-08-16: Sekarang ada tag gambar untuk Python 3.5, berdasarkan gambar resmi untuk Python 3.5. Jadi sekarang Anda dapat menggunakan gambar ini untuk proyek Anda di Python 2.7 dan Python 3.5.
2016-08-16: Gunakan dinamis sejumlah proses pekerja untuk UWSGI, dari 2 hingga 16 tergantung pada beban. Ini harus berhasil untuk sebagian besar kasus. Ini membantu terutama ketika ada beberapa respons yang lambat dan membutuhkan waktu untuk dihasilkan, perubahan ini memungkinkan semua respons lain untuk tetap cepat (dalam proses baru) tanpa harus menunggu yang pertama (lambat) satu untuk menyelesaikannya.
Juga, sekarang menggunakan file base uwsgi.ini di bawah /etc/uwsgi/ dengan sebagian besar konfigurasi umum, jadi, uwsgi.ini di dalam /app (yang perlu Anda modifikasi) sekarang jauh lebih sederhana.
2016-04-05: Log Nginx dan UWSGI sekarang diarahkan ke stdout, memungkinkan untuk menggunakan docker logs .
Proyek ini dilisensikan berdasarkan ketentuan lisensi Apache.
