Jakie są zalety dokowania nginx i php w różnych pojemnikach?

18

Właśnie zacząłem pracować z Dockerem i Kubernetsem i obserwowałem wiele stosów, w których niektórzy budują nginx + php na jednym obrazie, a niektórzy budują obraz z nginx, a drugi z php (montowanie tej samej ścieżki i dołączanie oba kontenery w tym samym wdrożeniu w Kubernetes).

Jakie byłyby zalety budowania dwóch obrazów dokerów zamiast instalowania obu nginx + php w tym samym?

docker dockerfile CarlosAS
źródło

Odpowiedzi:

19

PHP z nginx jest zwykle wykonywane przy użyciu php-fpm, który jest oddzielnym procesorem.

Utrzymanie podstawowej idei dokera jednego procesu (więcej szczegółów na ten temat znajduje się na końcu odpowiedzi) dla kontenera, ma sens umieszczenie procesu nginx i procesu php-fpm w osobnych pojemnikach.

Ponieważ komunikacja między nginx i php-fpm odbywa się za pośrednictwem fastcgi, pojemnik php-fpm może również znajdować się na oddzielnym hoście, co pozwala na użycie klastra pojemników php-fpm za nginx.

Po ściance komentarza znajduje się trochę więcej informacji, dokumentacja dokera zawiera akapit dotyczący idei, że kontener powinien mieć tylko jeden problem .

Główną ideą kontenera z linuksem ( lxc ) jest uruchomienie procesu w izolowanej przestrzeni nazw na poziomie procesora i pamięci, a dokerowanie dodaje do tego izolację na poziomie systemu plików.
Zaletą jest to, że naruszenie procesu w tym obszarze nazw nie pozwoli na odczyt pamięci innych procesów i jako takie powinno zapobiec innym zagrożeniom na hoście.

Mówiąc o nginx i php-fpm, pracują w parach, ale każdy ma swoje własne obawy, nginx wykona część HTTP, routing, sprawdzanie poprawności nagłówków itp., A php-fpm wykona interpretację kodu i zwróci część html do nginx . Chociaż zwykle obie aplikacje obsługują jedną aplikację, która nie jest obowiązkowa.

W zależności od kontekstu może być łatwiej mieć kontener zawierający cały stos dla aplikacji, na przykład na stacji roboczej programisty. Ale idealnie do użytku produkcyjnego, staraj się zachować mniej interakcji w pojemniku, ponieważ oddzielne procesy w tym samym pojemniku z nadzorem wnoszą swój udział w problemie w zakresie procesu zombie i obsługi logów (przykładowa historia tutaj tylko w celu ilustracji).

Na koniec zacytuję stronę dokera z pewnym naciskiem:

Chociaż „jeden proces na pojemnik” jest często dobrą regułą, nie jest to trudna i szybka reguła. Postaraj się, aby pojemniki były jak najbardziej czyste i modułowe .

Nie ma „reguły srebrnej kuli”, która miałaby zastosowanie do wszystkiego, zawsze jest równowaga między złożonością w kontenerze a złożonością organizującą same kontenery.

Tensibai
źródło
3
Podstawową ideą jest w rzeczywistości „Każdy kontener powinien mieć tylko jeden problem” i „niekoniecznie jest prawdą, że powinien istnieć tylko jeden proces systemu operacyjnego na kontener”. docs.docker.com/engine/userguide/eng-image/…
user2640621
Przyznaję, że jest to skrót do zrobienia pomysłu, nginx nie jest pojedynczym monolitycznym procesem ani php-fpm, ale zastępuję proces troską w mojej odpowiedzi i nadal jest OK nginx robi routing, php-fpm robi interpretację
Tensibai
3
Odpowiedzią jest zazwyczaj jedna usługa jeden port na kontener, a nie jeden proces. Z drugiej strony, jeśli masz wiele uruchomionych procesów w kontenerze, musisz wziąć pod uwagę proces inicjowania, zarządzanie usługami, restarty, niezależne rejestrowanie, niezależne zależności pakietów, staje się to nieco bardziej skomplikowane. A czasami mapowanie 1: 1 zamienia się w mapowanie 1: n podczas skalowania.
Jiri Klouda,
@Jiri gra adwokata diabła: więc apache przed aplikacją szynową korzystającą z DB Postgres powinien znajdować się w tym samym kontenerze? W końcu to tylko jedna usługa z zewnętrznego punktu widzenia.
Tensibai
1
@JiriKlouda odpowiedź zmieniona, mam nadzieję, że jest wystarczająco szczegółowa, aby przekazać wszystkie kwestie poruszone w komentarzach.
Tensibai
4

W rzeczywistości jednym brakującym punktem jest skalowalność pozioma. Artykuł z Jamie Alquiza dawno temu dotyczył tego:

http://archive.is/pDzz0

Krótko mówiąc, skalujesz php-fpm w poziomie, aby osiągnąć wyższą wydajność. Skalowanie Nginx + php-fpm razem nie przynosi żadnych korzyści. Zachęcam do wykonania testów warunków skrajnych (np. Tsung, Gatling itp.; Proszę nie rób Apache ab, czyli bardzo starej zabawki), aby sprawdzić, co napisano w artykule. Osobiście mam kilka rzeczywistych doświadczeń, które udowodniły, że artykuł jest prawdziwy.

Ale są dwie wady (być może nie Kubernetes) dla maszyn / maszyn wirtualnych:

  1. Jak skonfigurować Nginx, aby dynamicznie odkrywał zmiany kontenera php-fpm? To jest łatwa część.
  2. Jak udostępniamy ten sam system woluminów / plików po skalowaniu? Pojemniki Nginx i php-fpm powinny czytać dokładnie tę samą zawartość, aby osiągnąć spójność. To pozostawia najmniej części układanki (i najbardziej zabawnej) do pracy.

ZMIENIONO: Teraz jest już prawie połowa roku 2019. Stary model, php-fpm + nginx w tej samej kapsule, ma inne zastosowanie. Jeśli znasz siatkę usług, to nginx (lub tak zwane Nginmesh) służy jako wózek boczny do obsługi ruchu na granicy wschód-zachód. Ruch związany ze wschodem i zachodem służył głównie do uwierzytelniania wśród usług lub innych wymyślnych funkcji, podczas gdy czysty php-fpm nie mógł tego zrobić jednocześnie.

Ming Hsieh
źródło
3

Nie ma znaczącej korzyści, która przewyższałaby konieczność zarządzania dwoma pojemnikami. Jeśli masz stosunek 1: 1 między procesami i służą one jednemu celowi, umieść je w tym samym pojemniku.

użytkownik2640621
źródło
Masz na myśli różne obrazy na tym samym pojemniku?
CarlosAS
Jak uruchomisz nginx i php-fpm w tym samym kontenerze? Dodaj przykład.
030
1
@ 030 tutaj przykład
CarlosAS
2
@carlos Bardzo ważny przykład do celów programistycznych, zablokowałbym tego rodzaju rzeczy do użytku produkcyjnego (prowadzenie superwordu w kontenerze może dość łatwo obrócić się w pistolety)
Tensibai
Nie zgadzam się z tą odpowiedzią, z tym rozumowaniem serwer apache z mod mod security rozmawiający z kocurem rozmawiającym z serwerem postgresql obsługującym tylko jedną aplikację powinien mieścić się w jednym kontenerze.
Tensibai,
-1

Zaletą jest to, że możesz uruchomić wiele kontenerów php-fpm w back-endie, nazywamy to klastrem PHP, poprzez liczbę portów. Przykładowy port 9000, 9001, 9002 .. i tak dalej

Dylan B.
źródło