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?
Odpowiedzi:
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.
W rzeczywistości jednym brakującym punktem jest skalowalność pozioma. Artykuł z Jamie Alquiza dawno temu dotyczył tego:
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:
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.
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.