Soru Nginx'e ve Gunicorn gibi bir şeye neden ihtiyacım var?


Aşağıdaki soruya aşırı basitleştirilmiş bir cevap arıyorum. Nginx'in Gunicorn gibi bir şeyin yanında nasıl çalıştığına dair temel bir anlayış geliştirmeye çalışıyorum.

Nginx'te Django uygulamalarını dağıtmak için Nginx ve Gunicorn gibi bir şeye ihtiyacım var mı?

Öyleyse, gerçekten HTTP isteklerini işleyen nedir?

Ps. Apache ve mod_wsgi kullanmak istemiyorum!


182
2017-11-15 21:16


Menşei


Apache ve mod_wsgi, django uygulamanız ile üretim ortamında da çok yetenekli olan http istekleri arasındaki köprüyü uygulamanın en basit yoludur. Birçok geliştirici için bu, 'Apache nginx'ten daha iyi' anlamına geliyor, eğer biliyorlarsa, ama 'betamax, VHS'den daha iyi' olarak, alas, Dogma kuralları - MagicLAMP


Cevaplar:


Aşırı basitleştirilmiş: Python'u yürüten bir şeye ihtiyacınız var ama Python her türlü talebi ele almak için en iyi yol değil.

[Feragatname: Ben bir Gunicorn geliştiricisi]

Daha az basitleştirilmiş: Kullandığınız uygulama sunucusundan (Gunicorn, mod_wsgi, mod_uwsgi, cherrypy) bağımsız olarak, herhangi bir önemsiz olmayan dağıtım, Django uygulamanızın işlememesi gereken istekleri karşılayacak bir akış yönüne sahip olacaktır. Bu tür isteklerin önemsiz örnekleri, statik varlıklara (images / css / js) hizmet vermektedir.

Bu, klasik "üç katmanlı mimarinin" iki ilk adımı ile sonuçlanır. Yani, web sunucusu (sizin durumunuzdaki Nginx) görüntüler ve statik kaynaklar için birçok istekleri ele alacaktır. Dinamik olarak oluşturulması gereken istekler daha sonra uygulama sunucusuna aktarılacaktır (örneğinizde Gunicorn). (Bir kenara göre, üç katın üçüncüsü veritabanıdır)

Tarihsel olarak, bu katmanların her biri ayrı makinelerde barındırılacaktır (ve büyük olasılıkla ilk iki aşamada birden fazla makine olacaktır, yani: 5 web sunucusu, sırasıyla tek bir veritabanını sorgulayan iki uygulama sunucusuna istek göndermektedir).

Modern çağda artık tüm şekil ve boyutlarda uygulamalar var. Her hafta sonu projesi veya küçük işletme sitesi aslında birden fazla makinenin beygir gücüne ihtiyaç duymaz ve tek bir kutuda oldukça mutlu çalışır. Bu, barındırma çözümleri dizisine yeni girişler getirdi. Bazı çözümler uygulama sunucusunu web sunucusuna (Apache httpd + mod_wsgi, Nginx + mod_uwsgi, vb.) Evlendirir. Ve bu veritabanında, bu web / uygulama sunucusu kombinasyonlarından biri ile aynı makinede barındırılması hiç de nadir değildir.

Şimdi, Gunicorn durumunda, Nginx'in vekalet davranışına güvenirken, Nginx'ten ayrı şeyleri saklamak için özel bir karar aldık (Ruby'nin Tekboynuzundan kopyalayarak). Spesifik olarak, Gunicorn'un asla internetten bağlantıları asla okumayacağını varsayabilirsek, yavaş olan müşteriler için endişelenmemize gerek yok. Bu Gunicorn için işleme modeli utanç verici basit olduğu anlamına gelir.

Ayrılma aynı zamanda Gunicorn'un, performansı önemli ölçüde etkilemezken, geliştirme maliyetini en aza indiren saf Python'a yazılmasına da olanak tanır. Ayrıca, kullanıcıların diğer proxy'leri kullanmalarına da olanak tanır (doğru şekilde tamponladıkları varsayılarak).

HTTP talebinin gerçekte ne işe yaradığına dair ikinci soruya gelince, basit cevap Gunicorn. Tam cevap hem Nginx hem de Gunicorn isteği ele alıyor. Temel olarak, Nginx isteği alacak ve eğer bu dinamik bir istekse (genellikle URL modellerine dayanarak), o zaman bu işlemi İşlenecek Gunicorn'a verecektir ve daha sonra Nginx'e bir yanıt gönderecektir. istemcisi.

Yani kapanışta evet. Uygun bir Django dağıtımı için Nginx ve Gunicorn (ya da benzer bir şey) gerekir. Eğer Nginx ile Django'ya ev sahipliği yapmak istiyorsanız, o zaman ben de Ditago tarafının bir parçası olarak Gunicorn, mod_uwsgi ve CherryPy'yi araştırırdım.


268
2017-11-15 21:49



Böyle ayrıntılı bir cevap yazmak için zaman ayırdığınız için teşekkürler! Bu "3 katmanlı mimaride" önerilen herhangi bir okuma? - a.m.
Büyük cevap, ancak sorunu yavaş istemcilerle anlamıyorum. - Mads Skjern
@MadsSkjern Burada tahmin ediyorum, ancak tüm istemcilerin hızlı olduğunu varsayarsanız, o zaman işçilerin sabit bir havuzunu kullanabilir ve bir veya birçok müşterinin beklemesini engellediği durum için kod yazmanız gerekmez. - Jonathan Hartley
@ A.m. en.wikipedia.org/wiki/Multitier_architecture - Jonathan Hartley
benim django uygulamasında sadece json yok statik içeriği sadece gunicorn ve nginx ile gidebilir miyim - Sar009


Bu açıklamayı sadeliği ile beğendim:

Nginx dış dünyayla yüzleşecek. Medya dosyaları (görüntüler,   CSS, vb. Doğrudan dosya sisteminden. Ancak konuşamaz   doğrudan Django uygulamalarına; koşacak bir şeye ihtiyacı var   uygulama, web'den istekleri besleyin ve yanıtları döndürün.

Bu Guncorn'un işi. Gunicorn bir Unix soketi oluşturacak ve   wsgi protokolü ile nginx'e yanıtlar - soket veriyi   Her iki yönde:

The outside world <-> Nginx <-> The socket <-> Gunicorn

https://gist.github.com/Atem18/4696071


20
2017-12-13 07:52



Başkalarının merak etmesi durumunda soket olmak zorunda değil. - akshay


Aşırı basitleştirilmiş bir cevap arıyorum ...

Nginx'te Django uygulamalarını dağıtmak için Nginx ve Gunicorn gibi bir şeye ihtiyacım var mı?

Öyleyse, gerçekten HTTP isteklerini işleyen nedir?

Aşırı basitleştirilmiş cevap:

EVET.

Hem Nginx hem de Gunicorn.

Nginx'te konuşlandırdığınıza göre, elbette Nginx'e ihtiyacınız var.

Bir web çerçevesi olan Django'yu konuşlandırdığınızdan beri, web sunucusu (Nginx) ile web çerçevesi (Django) arasındaki konuşmayı köprüleyen bir şeye ihtiyacınız var. Python dünyasında, böyle bir şey WSGI sunucusu olarak adlandırılır (ama bir orta eşya gibi düşünün), bunlara örnek olarak Gunicorn ve uWSGI dahildir. Bir isteği ele alırken, Nginx, Guneycorn veya uWSGI isteğini proxy eder ve bu da Django kodunu çağırır ve yanıtı döndürür.

Bu belge ve Paul'un cevabı daha iyi öğrenmenize yardımcı olacak.


0
2017-10-26 21:42