Dlaczego zaleca się uruchomienie tylko jednego procesu w kontenerze?

W wielu postach na blogu i w ogólnej opinii istnieje powiedzenie „jeden proces na kontener”.

Dlaczego ta reguła istnieje? Dlaczego nie uruchomić ntp, nginx, uwsgi i innych procesów w jednym kontenerze, który musi mieć wszystkie procesy do działania?

posty na blogu wspominające o tej regule:

• „Pojedynczy proces na pojemnik to zalecany wzorzec projektowy dla aplikacji Docker”.
• „Docker służy wyłącznie do tworzenia kontenerów jednoprocesowych lub pojedynczych usług”.
• „lepiej użyć jednego procesu na pojemnik”
• „Uruchom pojedynczą usługę jako kontener”
• „Jeden proces na pojemnik”
• „jeden proces na pojemnik”

Zapomnijmy na chwilę o argumentach architektonicznych i filozoficznych wysokiego poziomu. Chociaż mogą występować pewne przypadki skrajne, w których wiele funkcji w jednym kontenerze może mieć sens, istnieją bardzo praktyczne powody, dla których warto rozważyć zastosowanie zasady „jedna funkcja na kontener”:

• Skalowanie kontenerów w poziomie jest znacznie łatwiejsze, jeśli kontener jest izolowany do jednej funkcji. Potrzebujesz innego kontenera Apache? Zakręć jeden gdzie indziej. Jednak jeśli mój kontener Apache ma również DB, cron i inne elementy, to komplikuje to wszystko.
• Posiadanie jednej funkcji na pojemnik pozwala na łatwe ponowne wykorzystanie pojemnika do innych projektów lub celów.
• To sprawia, że ​​jest bardziej przenośny i przewidywalny dla deweloperów, którzy ściągają komponenty z produkcji, aby rozwiązywać problemy lokalnie, a nie całe środowisko aplikacji.
• Patchowanie / aktualizacje (zarówno systemu operacyjnego, jak i aplikacji) można wykonywać w bardziej izolowany i kontrolowany sposób. Żonglowanie wieloma drobiazgami w kontenerze nie tylko zapewnia większe obrazy, ale także łączy te elementy razem. Dlaczego trzeba zamykać aplikacje X i Y tylko w celu aktualizacji Z?
  • Powyższe dotyczy również wdrożeń i wycofań kodu.
• Podział funkcji na wiele kontenerów zapewnia większą elastyczność z punktu widzenia bezpieczeństwa i izolacji. Możesz chcieć (lub wymagać), aby usługi były izolowane na poziomie sieci - fizycznie lub w sieciach nakładkowych - w celu utrzymania silnej pozycji bezpieczeństwa lub zgodności z takimi rzeczami, jak PCI.
• Inne drobniejsze czynniki, takie jak radzenie sobie ze standardowym wyjściem / stderr i wysyłanie dzienników do dziennika kontenera, utrzymywanie kontenerów tak efemerycznych, jak to możliwe itp.

Zauważ, że mówię o funkcji, a nie przetwarzaniu. Ten język jest przestarzały. Oficjalna dokumentacja doker został odsunięty od powiedzenia „jeden proces” zamiast polecenia „jeden” za troskę pojemniku.

Po zabiciu kontenera „dwóch procesów” kilka dni temu pojawiły się dla mnie pewne problemy, które spowodowały, że użyłem dwóch kontenerów zamiast skryptu Pythona, który rozpoczął dwa procesy:

1. Docker dobrze rozpoznaje uszkodzone pojemniki. Nie można tego zrobić, gdy główny proces wygląda dobrze, ale jakiś inny proces umarł straszliwą śmiercią. Jasne, możesz monitorować swój proces ręcznie, ale po co to reimplementować?
2. dzienniki dokowane stają się o wiele mniej przydatne, gdy wiele procesów wyrzuca swoje dzienniki do konsoli. Znów możesz zapisać nazwę procesu w dziennikach, ale doktor też może to zrobić.
3. Testowanie i rozumowanie kontenera staje się znacznie trudniejsze.

Zalecenie wynika z celu i projektu wirtualizacji na poziomie systemu operacyjnego

Kontenery zostały zaprojektowane tak, aby odizolować proces dla innych, dając mu własną przestrzeń użytkownika i system plików.
Jest to logiczna ewolucja chrootzapewniająca izolowany system plików. Kolejnym krokiem było odizolowanie procesów od innych, aby uniknąć nadpisywania pamięci i umożliwienie korzystania z tego samego zasobu (np. Port 8080 TCP) z wielu procesów bez konfliktów.

Zainteresowanie pojemnikiem to spakowanie potrzebnej biblioteki do procesu bez martwienia się o konflikty wersji. Jeśli uruchamiasz wiele procesów wymagających dwóch wersji tej samej biblioteki w tej samej przestrzeni użytkownika i systemie plików, musiałbyś dostosować przynajmniej LDPATH dla każdego procesu, aby najpierw znaleźć właściwą bibliotekę, a niektórych bibliotek nie można zmienić w ten sposób, ponieważ ich ścieżka jest zakodowana na stałe w pliku wykonywalnym w czasie kompilacji, zobacz to pytanie SO, aby uzyskać więcej szczegółów.
Na poziomie sieci musisz skonfigurować każdy proces, aby uniknąć używania tych samych portów.

Uruchamianie wielu procesów w tym samym kontenerze wymaga pewnych drobnych poprawek, a na koniec pokonaj cel izolacji, jeśli możesz uruchamiać wiele procesów w tej samej przestrzeni użytkownika, współużytkując ten sam system plików i zasoby sieciowe, to dlaczego nie uruchomić ich na samym hoście?

Oto niewyczerpująca lista ciężkich poprawek / pułapek, o których mogę myśleć:

• Obsługa dzienników

  Będąc z zamontowanym woluminem lub przeplatanym na standardowym wyjściu, przyniesie to pewne zarządzanie. Jeśli używasz zamontowanego woluminu, twój kontener powinien mieć własne „miejsce” na hoście lub dwa takie same kontenery będą walczyć o ten sam zasób. Podczas przeplatania na standardowe wyjście, aby z docker logsniego skorzystać , może stać się koszmarem do analizy, jeśli źródeł nie można łatwo zidentyfikować.

• Uważaj na procesy zombie

  Jeśli jeden z twoich procesów ulegnie awarii kontenera, superwizor może nie być w stanie wyczyścić dzieci w stanie zombie, a inicjator hosta nigdy ich nie odziedziczy. Po wyczerpaniu liczby dostępnych ofert (2 ^ 22, czyli około 4 milionów), wiele rzeczy zawiedzie.

• Rozdzielenie obaw

  Jeśli uruchomisz dwie oddzielne rzeczy, takie jak serwer apache i logstash w tym samym kontenerze, może to ułatwić obsługę logów, ale musisz wyłączyć apache, aby zaktualizować logstash. (W rzeczywistości powinieneś użyć sterownika rejestrującego Dockera). Czy będzie to wdzięczne przestanie czekać na zakończenie bieżących sesji, czy nie? Jeśli jest to pełen wdzięku przystanek, nowa wersja może zająć trochę czasu. Jeśli zabijesz, wpłyniesz na użytkowników dla nadawcy dziennika i tego należy unikać IMHO.

Wreszcie, gdy masz wiele procesów, odtwarzasz system operacyjny, a w tym przypadku wirtualizacja sprzętu brzmi bardziej zgodnie z tą potrzebą.

Jak w większości przypadków, nie jest to wszystko albo nic. Wytyczne dotyczące „jednego procesu na pojemnik” wynikają z idei, że pojemniki powinny służyć odrębnemu celowi. Na przykład, pojemnik nie powinien być zarówno aplikację internetową i serwer Redis.

Są przypadki, w których sensowne jest uruchamianie wielu procesów w jednym kontenerze, o ile oba procesy obsługują jedną modułową funkcję.

Proces, który nazywam tutaj usługą, 1 usługa kontenera ~ 1 , jeśli którakolwiek z moich usług nie powiedzie się, wtedy rozkręcę tylko ten kontener i po kilku sekundach wszystko znów będzie działać. Tak więc nie będzie żadnych zależności między usługami. Najlepszą praktyką jest utrzymywanie rozmiaru kontenera mniejszego niż 200 MB i maksymalnie 500 MB (wyjątek od natywnych kontenerów systemu Windows to więcej niż 2 GB), w przeciwnym razie będzie podobny do maszyny wirtualnej, ale nie do końca, ale wystarczająca wydajność. Weź również pod uwagę kilka parametrów, takich jak skalowanie, w jaki sposób mogę zwiększyć odporność moich usług, automatyczne wdrażanie itp.

A to, jak chcesz, tworzyć wzorce architektoniczne, takie jak mikrousługa w środowisku Polygot, przy użyciu technologii kontenerów, która najlepiej pasuje do Twojego środowiska i zautomatyzuje te rzeczy za Ciebie.