Bir kapta sadece bir işlem yapılması neden tavsiye edilir?

Birçok blog yazısında ve genel görüşlerde, "konteyner başına bir işlem" anlamına gelen bir söz vardır.

Bu kural neden var? Neden tüm işlemlerin çalışması gereken ntp, nginx, uwsgi ve daha fazla işlemi tek bir kapta çalıştırmıyorsunuz?

bu kuraldan bahseden blog gönderileri:

• "Konteyner başına tek işlem Docker uygulamaları için önerilen bir tasarım desenidir."
• "Docker, yalnızca tek işlemli veya tek hizmetli kapsayıcılar oluşturmak içindir."
• "konteyner başına bir işlem kullanmak daha iyi"
• "Tek bir servisi konteyner olarak çalıştır"
• "Konteyner başına bir işlem"
• "konteyner başına bir işlem"

Bir an için üst düzey mimari ve felsefi argümanları unutalım. Tek bir kaptaki çoklu fonksiyonların mantıklı olabileceği bazı son durumlar olsa da, "konteyner başına bir fonksiyonu" dikkate almayı isteyebileceğiniz çok pratik sebepler vardır:

• Kabın tek bir işleve izole edilmesi durumunda kabı yatay olarak ölçeklendirmek çok daha kolaydır. Başka bir apache kabına mı ihtiyacınız var? Birini başka bir yere çevirin. Bununla birlikte, eğer apache kabım aynı zamanda DB, cron ve diğer ayakkabı parçalarımı içeriyorsa, bu işleri karmaşıklaştırıyor.
• Konteyner başına tek bir işleve sahip olmak, kabın diğer projeler veya amaçlar için kolayca yeniden kullanılmasını sağlar.
• Aynı zamanda cihaz geliştiricilerin bir bileşeni tüm uygulama ortamından ziyade yerel olarak sorun gidermeye, üretimden bir parçaya çekmelerini sağlar.
• Yama / yükseltme (hem işletim sistemi hem de uygulama) daha izole ve kontrollü bir şekilde yapılabilir. Konteynırınızdaki birden fazla bit ve bob'u hokkabazlamak yalnızca daha büyük görüntüler elde etmekle kalmaz, aynı zamanda bu bileşenleri birbirine bağlar. Neden Z'yi yükseltmek için X ve Y uygulamalarını kapatmanız gerekiyor?
  • Yukarıda ayrıca kod dağıtımları ve geri almalar için de geçerlidir.
• İşlevleri çoklu kaplara bölmek, güvenlik ve izolasyon açısından daha fazla esneklik sağlar. Güçlü bir güvenlik duruşunu sürdürmek veya PCI gibi şeylere uymak için hizmetlerin ağ düzeyinde (fiziksel olarak ya da yer paylaşım ağları dahilinde) izole edilmesini isteyebilirsiniz.
• Stdout / stderr ile başa çıkmak ve günlükleri konteyner günlüğüne göndermek, konteynerleri mümkün olduğu kadar geçici tutmak gibi diğer küçük faktörler

İşlediğimi, fonksiyon dediğimi not edin. Bu dil eski. Resmi liman işçisi belgeleri "bir işlem" demekten uzağa , bunun yerine konteyner başına "bir endişe" önermekten uzaklaştı .

Birkaç gün önce bir "iki işlem" kabı öldürdüğümde benim için iki işlem başlatan bir python betiği yerine iki kabı kullanmama neden olan bazı acı noktaları var:

1. Docker, çökmüş kapları tanımada iyidir. Ana süreç iyi göründüğünde bunu yapamaz, fakat başka bir süreç korkunç bir ölümle öldü. Elbette, işleminizi manuel olarak izleyebilirsiniz, ancak neden bunu yeniden uygulayın?
2. Docker günlükleri, birden çok işlem günlüklerini konsola yayırken çok daha az kullanışlı olur. Yine, işlem adını günlüklere yazabilirsiniz, ancak liman işçisi de bunu yapabilir.
3. Bir konteynırla ilgili test ve muhakeme çok daha zor.

Tavsiye, İşletim sistemi düzeyinde sanallaştırma hedefinden ve tasarımından gelir.

Konteynerler, kendi kullanıcı alanını ve dosya sistemini vererek başkaları için bir işlemi izole etmek üzere tasarlanmıştır .
Bu, mantıksal evrimin chrootizole edilmiş bir dosya sistemi sağlamasıydı, bir sonraki adım belleğin üzerine yazmaktan kaçınmak için işlemleri diğerlerinden izole etmek ve aynı kaynağı (örneğin, TCP port 8080) çakışma olmadan çoklu işlemlerden kullanmaya izin vermek oldu.

Kapsayıcıya olan ilgi, sürüm çatışmalarından endişe duymadan süreç için gerekli kütüphaneyi paketlemektir. Aynı kullanıcı alanında ve dosya sisteminde aynı kitaplığın iki sürümüne ihtiyaç duyan çoklu işlemleri gerçekleştirirseniz, her bir işlem için en az LDPATH ayarlaması yapmanız gerekir, böylece uygun kitaplık ilk önce bulunur ve bazı kitaplıklar bu şekilde çimdiklenemez. Yolları derleme zamanında çalıştırılabilir kodlarda kodlanmış olduğundan, daha fazla ayrıntı için bu SO sorusuna bakın.
Ağ düzeyinde, aynı bağlantı noktalarını kullanmaktan kaçınmak için her işlemi yapılandırmanız gerekir.

Aynı kapta birden fazla işlem çalıştırmak, biraz fazla ince ayar yapılmasını gerektirir ve günün sonunda, aynı kullanıcı alanı içinde birden çok işlemi yürütmek tamamsa, aynı dosya sistemini ve ağ kaynaklarını paylaşırken, neden bunları çalıştırmıyorsanız, yalıtma amacını yenin konağın kendisi?

İşte düşünebileceğiniz ağır tweaking / tuzaklar listesi olmayan ayrıntılı listesi:

• Günlükleri kullanma

  Ya monte edilmiş bir hacme sahip olmak ya da stdout'a serpiştirmek bu biraz yönetim sağlar. Eğer monte edilmiş bir hacim kullanıyorsanız, kabınız ana bilgisayar üzerinde kendine ait bir "yere" sahip olmalıdır, yoksa aynı kaynak için iki aynı konteyner mücadele eder. docker logsKaynaklardan kolayca anlaşılamıyorsa, faydalanmak için stdout'a girerken analiz için bir kabusa dönüşebilir.

• Zombi işlemlerinden sakının

  Bir konteynır kazasında yaptığınız işlemlerden biri, süpervizörün çocukları zombi durumunda temizleyemeyebilir ve ev sahibi init bunları asla devralmayacaktır. Bir kere kullanılabilir pids (2 ^ 22 yaklaşık 4 milyon) tükendiğinde bir sürü şey başarısız olur.

• Endişelerin ayrılması

  Bir apache sunucusu ve aynı kapsayıcıdaki logstash gibi iki ayrı şey çalıştırırsanız, günlük işlemeyi kolaylaştırabilir, ancak logstash'ı güncellemek için apache'yi kapatmanız gerekir. (Gerçekte, Docker'ın günlük sürücüsünü kullanmalısınız) Geçerli oturumların bitmesini beklememek zarif bir duraklama olur mu? Zarif bir duraksa, biraz zaman alabilir ve yeni sürümü piyasaya sürmesi uzun sürebilir. Bir öldürme yaparsanız, kullanıcıları bir günlük göndereni için etkileyeceksiniz ve bu IMHO'dan kaçınılması gerekir.

Sonunda, birden fazla işleminiz olduğunda, bir işletim sistemi üretiyorsunuzdur ve bu durumda bir donanım sanallaştırması kullanmak bu ihtiyaca göre daha fazla ses çıkarır.

Çoğu durumda olduğu gibi, hepsi ya da hiçbiri değildir. "Konteyner başına bir işlem" yönlendirmesi, konteynerlerin ayrı bir amaca hizmet etmesi gerektiği fikrinden kaynaklanmaktadır. Örneğin, bir kap, bir web uygulaması hem de olmamalıdır ve bir Redis sunucusu.

Her iki işlem de tek, modüler bir işlevi desteklediği sürece, tek bir kapta birden fazla işlemi yürütmenin bir anlamı yoktur.

Burada servis olarak adlandırdığım işlem, 1 konteynır 1 servis , eğer herhangi bir servis başarısız olursa o zaman sadece ilgili konteynırı ve saniyeler içinde her şey tekrar başlar. Dolayısıyla, hizmetler arasında herhangi bir bağımlılık olmayacak. Kap büyüklüğünüzü 200 MB'tan ve en fazla 500 MB'den küçük tutmak (Windows yerel kapsayıcıları hariç), aksi takdirde, performans tam olarak değil, sanal makineye benzer olacaktır. Ayrıca, ölçeklendirme, servis esnekliği, otomatik dağıtım vb. İşlemleri nasıl yapabilirim?

Ve bu tamamen sizin çağrınız, ortamınızı en iyi şekilde karşılayan ve sizin için şeyleri otomatik hale getirecek olan kapsayıcı teknolojisini kullanarak, çoklu servis ortamında mikro-servis gibi mimari kalıplarınızı nasıl yapmanız gerektiğidir.