"Konuşlandırma" kelimesinin bağlama bağlı olarak iki anlamı olabilir. Ayrıca Apache / Nginx'in rollerini diğer bileşenlerin rolleriyle karıştırıyorsunuz.
Tarihi not: Bu makale ilk olarak Ruby uygulama sunucusu ekosisteminin sınırlı olduğu 6 Kasım 2010'da yazılmıştır. Bu makaleyi 15 Mart 2013 tarihinde ekosistemdeki en son güncellemelerle güncelledim.
Yasal Uyarı : Ben uygulama sunucularından biri olan Phusion Passenger'ın yazarlarından biriyim.
Apache vs Nginx
İkisi de web sunucusu. Statik dosyalar sunabilirler, ancak - doğru modüllerle - PHP'de yazılmışlar gibi dinamik web uygulamaları da sunabilirler. Apache daha popüler ve daha fazla özelliğe sahip, Nginx daha küçük ve daha hızlı ve daha az özelliğe sahip.
Apache / Nginx, daha sonra açıklanacak bir tür eklenti ile birlikte kullanmanız için Ruby web uygulamalarını hazır olarak sunamaz.
Apache ve Nginx ters proxy olarak da görev yapabilir, yani gelen bir HTTP isteğini alıp HTTP'yi de konuşan başka bir sunucuya iletebilirler. Bu sunucu bir HTTP yanıtıyla yanıt verdiğinde, Apache / Nginx yanıtı istemciye iletir; Daha sonra bunun neden önemli olduğunu öğreneceksiniz.
Moğol ve diğer üretim uygulaması sunucuları - WEBrick
Mongrel bir Ruby "uygulama sunucusudur": Somut olarak bu, Mongrel'in aşağıdakileri yapan bir uygulamadır:
- Ruby uygulamanızı kendi işlem alanının içine yükler.
- Dış dünya ile iletişim kurmasını sağlayan bir TCP soketi kurar (örn. İnternet). Mongrel, bu yuvadaki HTTP isteklerini dinler ve istek verilerini Ruby web uygulamasına iletir.
- Ruby web uygulaması daha sonra HTTP yanıtının nasıl görünmesi gerektiğini tanımlayan bir nesne döndürür ve Mongrel bunu gerçek bir HTTP yanıtına (gerçek baytlar) dönüştürerek ilgilenir ve soket üzerinden geri gönderir.
Ancak Moğol oldukça eskidir, günümüzde artık korunmamaktadır. Daha yeni alternatif uygulama sunucuları:
- Phusion Yolcu
- tek boynuzlu at
- İnce
- Puma
- Trinidad (sadece JRuby)
- TorqueBox (yalnızca JRuby)
Onları daha sonra ele alacağım ve birbirlerinden ve Mongrel'den nasıl farklı olduklarını anlatacağım.
WEBrick, Mongrel ile aynı şeyi yapar, ancak farklılıklar şunlardır:
- WEBrick, daha önce bahsettiğim diğer her şeyin aksine üretime uygun değil. WEBrick tamamen Ruby'de yazılmıştır. Mongrel (ve diğer birçok Ruby uygulama sunucusu) bölüm Ruby ve bölüm C'dir (Çoğunlukla Ruby), ancak HTTP ayrıştırıcısı performans için C olarak yazılmıştır.
- WEBrick daha yavaş ve daha az sağlamdır. Bilinen bazı bellek sızıntıları ve bilinen bazı HTTP ayrıştırma sorunları var.
- WEBrick genellikle geliştirme sırasında varsayılan sunucu olarak kullanılır, çünkü WEBrick varsayılan olarak Ruby'ye dahil edilir. Mongrel ve diğer uygulama sunucularının ayrı olarak yüklenmesi gerekir. WEBrick'i üretim ortamlarında kullanmanız önerilmez, ancak bir nedenden dolayı Heroku WEBrick'i varsayılan sunucusu olarak seçti. Daha önce Thin kullanıyorlardı, bu yüzden neden WEBrick'e geçtiklerini bilmiyorum.
Uygulama sunucusu ve dünya
Tüm geçerli Ruby uygulama sunucuları HTTP konuşuyor, ancak bazı uygulama sunucuları 80 numaralı bağlantı noktasında doğrudan Internet'e maruz kalabilirken, diğerleri olmayabilir.
- Doğrudan İnternet'e maruz kalabilecek uygulama sunucuları: Phusion Passenger, Rainbows
- Doğrudan İnternete maruz kalmayabilecek uygulama sunucuları: Mongrel, Unicorn, Thin, Puma. Bu uygulama sunucularının Apache ve Nginx gibi bir ters proxy web sunucusunun arkasına yerleştirilmesi gerekir .
- Trinidad ve TorqueBox hakkında yeterince bilgim yok, bu yüzden onları atladım.
Neden bazı uygulama sunucuları ters bir proxy'nin arkasına yerleştirilmelidir?
- Bazı uygulama sunucuları işlem başına aynı anda yalnızca 1 isteği işleyebilir. Aynı anda 2 isteği işlemek istiyorsanız, her biri aynı Ruby uygulamasını sunan birden fazla uygulama sunucusu örneği çalıştırmanız gerekir. Bu uygulama sunucusu işlemleri kümesine uygulama sunucusu kümesi denir (bu nedenle Moğrel Kümesi, İnce Küme vb. Adı verilir). Daha sonra proxy'yi bu kümeye ters çevirmek için Apache veya Nginx'i kurmanız gerekir. Apache / Nginx, kümedeki örnekler arasında istekleri dağıtmaya özen gösterir (Bununla ilgili daha fazla bilgi için "I / O eşzamanlılık modelleri" bölümü).
- Web sunucusu istekleri ve yanıtları arabelleğe alabilir ve uygulama sunucusunu "yavaş istemciler" den koruyabilir - çok hızlı veri göndermeyen veya kabul etmeyen HTTP istemcileri. Uygulama sunucunuzun istemcinin tüm isteği göndermesini veya tam yanıtı almasını beklerken hiçbir şey yapmasını istemezsiniz, çünkü bu süre zarfında uygulama sunucusu başka bir şey yapamayabilir. Apache ve Nginx aynı anda birçok şeyi yapmakta çok iyidir çünkü çok iş parçacıklı veya olaylıdırlar.
- Çoğu uygulama sunucusu statik dosyalar sunabilir, ancak özellikle iyi değildir. Apache ve Nginx daha hızlı yapabilir.
- İnsanlar genellikle statik dosyaları doğrudan sunmak için Apache / Nginx'i kurar, ancak statik dosyalara karşılık gelmeyen istekleri uygulama sunucusuna iletir, bu iyi bir güvenlik uygulamasıdır. Apache ve Nginx çok olgun ve uygulama sunucusunu (belki de kötü amaçlı olarak) bozuk isteklerden koruyabilir.
Bazı uygulama sunucuları neden doğrudan Internet'e maruz kalabilir?
- Phusion Passenger diğer tüm uygulama sunucularından çok farklı bir canavar. Benzersiz özelliklerinden biri, web sunucusuna entegre olmasıdır.
- Rainbows'un yazarı, bunu doğrudan İnternet'e maruz bırakmanın güvenli olduğunu açıkça belirtti. Yazar, HTTP ayrıştırıcısında (ve benzeri) herhangi bir güvenlik açığı olmadığından oldukça emin. Yine de yazar hiçbir garanti vermez ve kullanımın kendi sorumluluğunda olduğunu söyler.
Uygulama sunucuları karşılaştırıldı
Bu bölümde, bahsettiğim çoğu uygulama sunucusunu karşılaştıracağım, ancak Phusion Passenger'ı karşılaştırmayacağım. Phusion Passenger, ona adanmış bir bölüm verdiğim diğerlerinden çok farklı bir canavar. Ayrıca Trinidad ve TorqueBox'ı da atladım çünkü onları yeterince iyi bilmiyorum, ancak JRuby kullanıyorsanız sadece ilgili.
- Melez oldukça çıplak kemiklerdi. Daha önce de belirtildiği gibi, Mongrel tamamen tek iş parçacıklı çok işlemlidir, bu nedenle yalnızca bir kümede yararlıdır. Süreç izleme yoktur: Kümedeki bir işlem çökerse (örn. Uygulamadaki bir hata nedeniyle), manuel olarak yeniden başlatılması gerekir. İnsanlar Monit ve God gibi dış süreç izleme araçlarını kullanma eğilimindedir.
- Tek boynuzlu at , melez bir çatal. Sınırlı işlem izlemeyi destekler: bir işlem çökerse ana işlem tarafından otomatik olarak yeniden başlatılır. Tüm işlemlerin her işlem için ayrı bir soket yerine tek bir paylaşılan soket üzerinde dinlemesini sağlayabilir. Bu, ters proxy yapılandırmasını basitleştirir. Mongrel gibi, tamamen tek iş parçacıklı çok işlemlidir.
- Thin , EventMachine kütüphanesini kullanarak olaylı I / O modelini kullanır. Mongrel HTTP ayrıştırıcısını kullanmak dışında, hiçbir şekilde Mongrel'i temel almaz. Küme modunda işlem izlemesi yoktur, bu nedenle çökmeleri vb. İzlemeniz gerekir. Unicorn benzeri paylaşılan soket yoktur, bu nedenle her işlem kendi soketinde dinler. Teorik olarak, Thin'in I / O modeli yüksek eşzamanlılığa izin verir, ancak Thin'ın kullanıldığı en pratik durumlarda, bir İnce işlem yalnızca 1 eşzamanlı isteği işleyebilir, bu yüzden yine de bir kümeye ihtiyacınız vardır. "I / O eşzamanlılık modelleri" bölümündeki bu tuhaf özellik hakkında daha fazla bilgi.
- Puma da Mongrel'den çatallandı, ancak Unicorn'un aksine Puma tamamen çok iş parçacıklı olacak şekilde tasarlandı. Bu nedenle, şu anda yerleşik küme desteği bulunmamaktadır. Birden fazla çekirdeği kullanabilmeniz için özel dikkat göstermeniz gerekir (Bununla ilgili daha fazla bilgi için "I / O eşzamanlılık modelleri" bölümünde).
- Rainbows , farklı kütüphanelerin kullanılmasıyla birden fazla eşzamanlılık modelini destekler.
Phusion Yolcu
Phusion Passenger diğerlerinden çok farklı çalışıyor. Phusion Passenger doğrudan Apache veya Nginx ile entegre olur ve Apache için mod_php ile karşılaştırılabilir. Tıpkı mod_php'nin Apache'nin neredeyse sihirli bir şekilde PHP uygulamalarına hizmet etmesine izin verdiği gibi Phusion Passenger da Apache'nin (ve ayrıca Nginx!) Ruby uygulamalarına neredeyse sihirli bir şekilde hizmet etmesine izin veriyor. Phusion Passenger'ın amacı Just Work (tm) 'de mümkün olan en az güçlükle her şeyi yapmaktır.
Uygulamanız için bir işlem veya küme başlatmak ve Apache / Nginx'i statik dosyaları sunacak ve / veya Phusion Passenger ile işleme / kümeye proxy uygulama isteklerini tersine çevirecek şekilde yapılandırmak yerine şunları yapmanız gerekir:
- Web sunucusu yapılandırma dosyasını düzenler ve Ruby uygulamanızın 'genel' dizininin konumunu belirtirsiniz.
- 2. adım yoktur.
Tüm yapılandırma web sunucusu yapılandırma dosyası içinde yapılır. Phusion Passenger hemen hemen her şeyi otomatik hale getirir. Bir küme başlatmaya ve işlemleri yönetmeye gerek yoktur. İşlemleri başlatma / durdurma, çöktüklerinde yeniden başlatma, vb. - hepsi otomatik. Diğer uygulama sunucularıyla karşılaştırıldığında, Phusion Passenger'ın daha az hareketli parçası vardır. Bu kullanım kolaylığı, insanların Phusion Passenger'ı kullanmasının başlıca nedenlerinden biridir.
Ayrıca diğer uygulama sunucularının aksine, Phusion Passenger öncelikle C ++ ile yazılmıştır, bu da çok hızlı hale getirir.
Otomatik haddeleme yeniden başlatmaları, çoklu iş parçacığı desteği, dağıtım hatası direnci vb. Gibi daha da fazla özelliğe sahip bir Phusion Passenger kurumsal çeşidi de vardır .
Yukarıdaki nedenlerden ötürü, Phusion Passenger şu anda en popüler Ruby uygulama sunucusudur ve New York Times, Pixar, Airbnb vb.
Phusion Passenger vs diğer uygulama sunucuları
Phusion Passenger, çok daha fazla özellik sağlar ve diğer uygulama sunucularına göre birçok avantaj sağlar:
- Trafiğe dayalı işlem sayısını dinamik olarak ayarlama. Kaynak kısıtlı sunucumuzda herkese açık olmayan ve kuruluşumuzdaki kişilerin günde en fazla birkaç kez kullandıkları bir ton Rails uygulaması çalıştırıyoruz. Gitlab, Redmine, vb. Gibi şeyler. Phusion Passenger, kullanılmadığında bu işlemleri yavaşlatabilir ve kullanılmadığında hızlandırabilir, böylece daha önemli uygulamalar için daha fazla kaynak kullanılabilir. Diğer uygulama sunucularında, tüm işlemleriniz her zaman açıktır.
- Bazı uygulama sunucuları tasarım gereği belirli iş yüklerinde iyi değildir. Örneğin , Unicorn yalnızca hızlı çalışan istekler için tasarlanmıştır: Unicorn web sitesi "Bazı Durumlarda Daha Kötü" bölümüne bakın .
Unicorn'un iyi olmadığı iş yükleri:
- Akış iş yükleri (örn. Rails 4 canlı akış veya Rails 4 şablon akışı).
- Uygulamanın HTTP API çağrıları yaptığı iş yükleri.
Phusion Passenger Enterprise 4 veya sonraki sürümlerdeki hibrit I / O modeli, bu tür iş yükleri için mükemmel bir seçimdir.
- Diğer uygulama sunucuları, kullanıcının uygulama başına en az bir örneği çalıştırmasını gerektirir. Bunun aksine, Phusion Passenger tek bir durumda birden fazla uygulamayı destekler. Bu, yönetim yükünü büyük ölçüde azaltır.
- Otomatik kullanıcı değiştirme, kullanışlı bir güvenlik özelliği.
- Phusion Passenger birçok MRI Ruby, JRuby ve Rubinius'u destekler. Mongrel, Unicorn ve Thin sadece MR'ı destekler. Puma ayrıca 3'ü de destekler.
- Phusion Passenger aslında Ruby'den fazlasını destekliyor! Ayrıca Python WSGI'yı da destekler, böylece Django ve Flask uygulamalarını da çalıştırabilir. Aslında Phusion Passenger çok dilli sunucu olma yolunda ilerliyor. Yapılacaklar listesinde Node.js desteği.
- Bant dışı çöp toplama. Phusion Passenger, Ruby çöp toplayıcısını normal istek / yanıt döngüsünün dışında çalıştırabilir ve bu da istek sürelerini yüzlerce milisaniye kadar azaltır. Unicorn da benzer bir özelliğe sahiptir, ancak Phusion Passenger'ın sürümü daha esnektir, çünkü 1) GC ile sınırlı değildir ve keyfi çalışma için kullanılabilir. 2) Phusion Passenger'ın sürümü çok iş parçacıklı uygulamalarla iyi çalışır, Unicorn's çalışmıyor.
- Otomatik haddeleme yeniden başlar. Unicorn ve diğer sunucularda yuvarlama yeniden başlatma işlemleri için biraz komut dosyası çalışması gerekir. Phusion Passenger Enterprise sizin için bu yolu tamamen otomatik hale getirir.
Daha fazla özellik ve avantaj var, ancak liste gerçekten uzun. Bilgi için kapsamlı Phusion Passenger kılavuzuna ( Apache sürümü , Nginx sürümü ) veya Phusion Passenger web sitesine başvurmalısınız.
I / O eşzamanlılık modelleri
- Tek iş parçacıklı çoklu işlem. Bu, Ruby uygulama sunucuları için geleneksel olarak en popüler G / Ç modelidir, çünkü Ruby ekosistemindeki çoklu iş parçacığı desteği çok kötüydü. Her işlem bir seferde tam olarak 1 isteği işleyebilir. Web sunucusu yükü işlemler arasında dengeler. Bu model çok sağlamdır ve programcının eşzamanlılık hataları getirme şansı çok azdır. Ancak, G / Ç eşzamanlılığı son derece sınırlıdır (işlem sayısı ile sınırlıdır). Bu model hızlı, kısa süreli iş yükleri için çok uygundur. Yavaş, uzun süre çalışan engelleme G / Ç iş yükleri, örneğin HTTP API'lerinin çağrılmasını içeren iş yükleri için çok uygun değildir.
- Tamamen çok iş parçacıklı. Günümüzde Ruby ekosisteminin mükemmel çoklu iş parçacığı desteği var, bu nedenle bu G / Ç modeli çok uygulanabilir hale geldi. Çoklu kullanım, yüksek G / Ç eşzamanlılığına izin vererek hem kısa hem de uzun süreli engelleme G / Ç iş yükleri için uygun hale getirir. Programcı eşzamanlılık hataları getirme olasılığı daha yüksektir, ancak neyse ki çoğu web çerçevesi hala çok olası olmayacak şekilde tasarlanmıştır. Bununla birlikte dikkat edilmesi gereken bir nokta, MRI Ruby yorumlayıcısının, Global Tercüman Kilidi (GIL) kullanımı nedeniyle birden fazla iş parçacığı olsa bile birden fazla CPU çekirdeğinden yararlanamamasıdır. Birden çok iş parçacıklı işlem kullanarak bu sorunu çözebilirsiniz, çünkü her işlem bir CPU çekirdeğinden yararlanabilir. JRuby ve Rubinius'un GIL'si yoktur, böylece tek bir işlemde birden çok çekirdeği tam olarak kullanabilirler.
- Hibrit çok iş parçacıklı çok işlemli. Öncelikle Phusion Passenger Enterprise 4 ve üstü tarafından uygulanır. Tek iş parçacıklı çok işlemli, tamamen çok iş parçacıklı ve hatta her biri birden çok iş parçacıklı birden çok işlem arasında kolayca geçiş yapabilirsiniz. Bu model her iki dünyanın da en iyisini verir.
- Evented. Bu model, daha önce bahsedilen modelden tamamen farklıdır. Çok yüksek G / Ç eşzamanlılığına izin verir ve bu nedenle uzun süre çalışan engelleme G / Ç iş yükleri için mükemmeldir. Bunu kullanmak için uygulamadan ve çerçeveden açıkça destek alınması gerekmektedir. Ancak Rails ve Sinatra gibi tüm büyük çerçeveler olay kodunu desteklemez. Bu nedenle pratikte İnce bir işlem hala bir seferde 1'den fazla talebi işleyemez ve bu da tek iş parçacıklı çok işlemli modelle aynı şekilde davranmasını sağlar. Kramp gibi olaylı G / Ç'den yararlanabilecek özel çerçeveler vardır.
Kısa bir süre önce Phusion blogunda, iş yükünüzün verildiği işlem ve iş parçacıklarının sayısını en iyi şekilde ayarlamaya yönelik bir makale yayınlandı. Bkz. Phusion Passenger'ın eşzamanlılık ayarlarını yapma .
Capistrano
Capistrano tamamen farklı bir şey. Önceki tüm bölümlerde, "dağıtım", Ruby uygulamanızı bir uygulama sunucusunda başlatma işlemine atıfta bulunur, böylece ziyaretçilerin erişebilmesini sağlar, ancak bundan önce birinin aşağıdakiler gibi bazı hazırlık çalışmaları yapması gerekir:
- Ruby uygulamasının kodunu ve dosyalarını sunucu makinesine yükleme.
- Uygulamanızın bağlı olduğu kütüphaneleri yükleme.
- Veritabanını ayarlama veya taşıma.
- Sidekiq / Resque çalışanları ya da her neyse, uygulamanızın güvenebileceği arka planın başlatılması ve durdurulması.
- Başvurunuzu kurarken yapılması gereken diğer şeyler.
Capistrano bağlamında, "dağıtım", tüm bu hazırlık işlerini yapmak anlamına gelir. Capistrano bir uygulama sunucusu değil. Bunun yerine, tüm bu hazırlık çalışmalarını otomatikleştirmek için bir araçtır. Capistrano'ya, uygulamanızın her yeni sürümünü dağıttığınızda sunucunuzun nerede olduğunu ve hangi komutların çalıştırılması gerektiğini söylersiniz ve Capistrano, sizin için Rails uygulamasını sunucuya yüklemeye ve belirttiğiniz komutları çalıştırmaya özen gösterir.
Capistrano her zaman bir uygulama sunucusuyla birlikte kullanılır. Uygulama sunucularının yerini almaz. Bunun tersine, uygulama sunucuları Capistrano'nun yerini almaz, Capistrano ile birlikte kullanılabilir.
Tabii ki yok olması Capistrano kullanmak. Ruby uygulamanızı FTP ile yüklemeyi ve her seferinde aynı komut adımlarını manuel olarak çalıştırmayı tercih ederseniz, bunu yapabilirsiniz. Diğer insanlar bundan sıkıldı, bu yüzden Capistrano'daki bu adımları otomatikleştirdiler.