Docker ve Kubernetes ile çalışmaya yeni başladım ve bazı insanların tek bir görüntüde nginx + php oluşturduğu ve bazılarının nginx ve php ile başka bir görüntü oluşturduğu (aynı yolu takma ve çevreleyen) birçok yığın izliyorum her iki kap da Kubernetes'te aynı dağıtımda).
Her ikisi de nginx + php'yi aynı olana yüklemek yerine iki docker görüntüsü oluşturmanın avantajları neler olurdu?
Yanıtlar:
Nginx'li PHP genellikle ayrı bir işlem olan php-fpm kullanılarak yapılır.
Docker'ın temel fikrini bir işlemin (bu nokta hakkında daha fazla ayrıntı için yanıtın sonuna bakın) konteyner başına tutmak, nginx işleminin ve php-fpm işleminin ayrı kaplarda olması mantıklıdır.
Nginx ve php-fpm arasındaki iletişim fastcgi aracılığıyla ortaya çıktığında, php-fpm kabı ayrı bir konakta da olabilir ve bu, nginx'in arkasında bir php-fpm kapları kümesinin kullanılmasına izin verir.
Yorum duvarından sonra biraz daha arka plan var, liman işçilerinin belgelerinde bir konteynerin sadece bir endişesi olması gerektiği fikri var .
Linux kapsayıcısının ( lxc ) ana fikri , işlemci ve bellek düzeyinde yalıtılmış bir ad alanında bir işlem yürütmektir, docker bunun üzerine dosya sistemi düzeyinde bir yalıtım ekler.
Avantajı, bu isim alanındaki bir işlemin tehlikeye atılmasının, diğer işlemlerin belleğinin okunmasına izin vermemesidir ve bu nedenle ana bilgisayarda diğer tehlikelerin önüne geçmelidir.
Nginx ve php-fpm hakkında konuşurken, çift olarak çalışırlar, ancak her birinin kendi endişesi vardır, nginx HTTP bölümünü, yönlendirme, üstbilgileri doğrulama vb. . Her ikisinin birlikte zorunlu olmayan tek bir uygulamaya hizmet etmesi normaldir.
Bağlama bağlı olarak, bir uygulama için tüm yığını içeren bir kapsayıcı, örnek için bir geliştirici iş istasyonunda bulunması daha kolay olabilir. Ama ideal üretim amaçlı, (exemple hikaye zombi sürecinin vadede sorunun payını getiriyor supervisord ile aynı kap içinde ayrı süreçler sahip kabın içine az etkileşim tutmaya çalışın ve işleme log burada örnekleme amaçlıdır için).
Nihayet docker sayfasını biraz vurgulayarak alıntılayacağım:
“Konteyner başına bir işlem” genellikle iyi bir kural olsa da, zor ve hızlı bir kural değildir. Kapları mümkün olduğunca temiz ve modüler tutmak için en iyi muhakemenizi kullanın .
Her şey için geçerli bir "gümüş kurşun kuralı" yoktur, bu her zaman konteynerin içindeki karmaşıklık ile konteynırların kendilerini düzenleyen karmaşıklık arasında bir denge oluşturur.
İki konteynırı yönetmek zorunda kalmadan ağır basan anlamlı bir fayda yoktur. Süreçler arasında 1: 1 ilişkiniz olduğu ve tek bir amaca hizmet ettiği sürece, bunları aynı kaba koyun.
Aslında, burada eksik olan bir nokta yatay ölçeklenebilirliktir. Jamie Alquiza'dan uzun zaman önce şu konuya değinen bir makale var:
Kısacası, daha yüksek performansa ulaşmak için php-fpm'nizi yatay olarak ölçeklendirirsiniz. Nginx + php-fpm'yi birlikte ölçeklendirmek size herhangi bir fayda sağlamaz. Makalenin ne dediğini doğrulamak için bazı stres testleri (örneğin, Tsung, Gatling vb. Şahsen, makalenin genel olarak doğru olduğunu kanıtlayan birkaç gerçek dünya deneyimim var.
Ancak çıplak metal makineleri / VM'ler için iki dezavantaj var (belki Kubernetes için değil):
DÜZENLENEN: Şimdi 2019'un neredeyse yarısı. Aynı modeldeki php-fpm + nginx'in eski modeli farklı kullanıma sahip. Hizmet ağına aşina iseniz, nginx (veya Nginmesh olarak adlandırılan şey) doğu-batı bağlantılı trafiği işlemek için bir sepet olarak işlev görür. Doğu-batı sınırı trafiği çoğunlukla hizmetler veya diğer fantezi işlevler arasında kimlik doğrulaması için kullanılırken, saf php-fpm bunu başaramadı.