Aplikacja kontenerowa potrzebuje odpowiedniego modelu wdrożenia. Docker Compose może wystarczyć do produkcyjnej usługi o umiarkowanej złożoności. Kubernetes warto rozważyć, gdy aplikacje mają działać na kilku maszynach, a wdrażanie wymaga skoordynowanego sterowania. Decyzja zaczyna się od wymagań aplikacji.
Jedna firma prowadzi wewnętrzny portal z interfejsem WWW, bazą danych i przetwarzaniem w tle. Ma okno serwisowe, przewidywalne obciążenie i wyznaczonego administratora. Druga firma kilka razy w tygodniu wydaje nowe wersje wielu usług i musi zachować dostępność podczas planowanych prac. Obie używają kontenerów, ale mogą potrzebować różnych modeli wdrożenia.
Docker, Compose i Kubernetes pełnią różne funkcje
Środowisko uruchomieniowe kontenerów wykonuje kontenery. Docker Engine jest szeroko używaną platformą do tego celu. Docker Compose opisuje usługi aplikacji w pliku YAML. Może łączyć obrazy, sieci, trwałe wolumeny i konfigurację. Narzędzia Compose tworzą aplikację i zarządzają nią na hoście Docker, z którym są połączone.
Kubernetes zarządza stanem docelowym obciążeń w klastrze. Rozmieszcza Pody na odpowiednich węzłach i może zastępować zarządzane instancje lub aktualizować je stopniowo. Każdy węzeł nadal potrzebuje odpowiedniego środowiska uruchomieniowego kontenerów. Plik Compose i zasoby Kubernetes opisują wdrożenia inaczej, dlatego migracja to więcej niż zmiana nazwy pliku.
Wielkość firmy niewiele mówi o tej decyzji. Mały zespół programistyczny z częstymi wydaniami może skorzystać z orkiestracji. Znacznie większej firmie może wystarczyć jeden dobrze utrzymywany host dla pojedynczej wspieranej aplikacji biznesowej.
Docker Compose jest przeznaczony również do produkcji
Docker wyraźnie dokumentuje użycie Compose w produkcji, szczególnie na pojedynczym serwerze. Konfiguracje deweloperskie i produkcyjne można rozdzielać lub rozszerzać według potrzeb. Zasady restartu, publikowane porty, logowanie i proces aktualizacji muszą odpowiadać środowisku produkcyjnemu.
Dla wewnętrznego portalu dokumentów może to być proste rozwiązanie: ograniczony zestaw usług, udokumentowane wersje, chronione dane i przetestowane odtwarzanie. Awaria hosta nadal wymaga osobnego planu. Zasada restartu nie przenosi aplikacji na inną maszynę. Nadmiarowość bazowej platformy wirtualizacji i kopie zapasowe aplikacji również stanowią odrębne warstwy.
Znaczenie ma też metoda instalacji wspierana przez producenta oprogramowania. Oficjalnie utrzymywane wdrożenie Compose może być operacyjnie cenniejsze niż własna instalacja klastra bez niezawodnej ścieżki aktualizacji.
Macierz decyzyjna dla utrzymania
| Pytanie | Docker Compose na jednym hoście | Kubernetes |
|---|---|---|
| Jak duże jest środowisko? | Dobry wybór dla pojedynczych aplikacji z ograniczonym zestawem usług. | Wieloma obciążeniami i węzłami można zarządzać za pomocą wspólnych zasad platformy. |
| Co się stanie przy awarii hosta? | Odtwarzanie lub nadmiarowość infrastruktury organizuje się poza Compose. | Zastąpienie na innych węzłach jest możliwe, jeśli przygotowano aplikację, moc, warstwę sterowania i dostęp do danych. |
| Jak wdraża się wydania? | Zmieniające się usługi zastępuje się w udokumentowanym i, gdzie warto, zautomatyzowanym procesie. | Zasady wdrażania wspierają kontrolowane rollouty. Zmiany danych i testy funkcjonalne nadal potrzebują własnego planu. |
| Gdzie znajdują się dane biznesowe? | W wolumenach lub usługach zewnętrznych z własnymi procedurami kopii zapasowych i odtwarzania. | W trwałej pamięci masowej lub usługach zewnętrznych, których odporność i kopie zapasowe nadal trzeba ocenić. |
| Kto utrzymuje platformę? | Odpowiedzialność obejmuje host, środowisko uruchomieniowe, obrazy i aplikację. | Dodatkowo obejmuje klaster, integrację sieci i pamięci masowej oraz ich cykle życia. |
| Jak ocenia się stan usługi? | Monitorowane są host, usługi i procesy biznesowe. | Monitorowany jest też klaster i współdziałanie składników platformy; sam działający Pod nie wystarcza. |
| Co wspiera producent? | Decydują wspierana metoda instalacji i jej ścieżka aktualizacji. | Muszą być dostępne wdrożenie Kubernetes możliwe do utrzymania i odpowiednie wsparcie producenta. |
Kiedy Kubernetes daje konkretną korzyść
Uzasadnieniem może być potrzeba spójnego zarządzania wieloma podobnymi wdrożeniami lub współdzielenia dostępnej mocy obliczeniowej między usługami. Przemawiają za nim także częste aktualizacje z jasnymi zasadami wdrażania i osobną odpowiedzialnością za różne obszary aplikacji. Wymaga to aplikacji zdolnej do pracy w wielu instancjach oraz osób potrafiących utrzymać dodatkową platformę.
Przed wyborem usługi należy ustalić, czy dostawca zarządza warstwą sterowania, które składniki utrzymujemy sami i jakie zadania reagowania na incydenty pozostają po naszej stronie. Zarządzany klaster ogranicza niektóre zadania platformowe. Odpowiedzialność za aplikacje, uprawnienia, dane i koszty pozostaje.
Częstą przeszkodą są założenia dotyczące współdzielonych danych. Czy aplikacja biznesowa może pracować w kilku aktywnych instancjach? Gdzie zapisuje pliki? Gdzie są sesje? Czy zadanie w tle można bezpiecznie powtórzyć? Te pytania wymagają odpowiedzi przed migracją. Dostępny kontener nie dowodzi poprawnego przetwarzania zamówień.
Nakład pracy obejmuje cały cykl życia
Do porównania nie wystarczą opłaty za serwer lub chmurę. Liczą się również wdrożenie, dokumentacja, aktualizacje, monitoring, kopie zapasowe i czas incydentów. Kubernetes dodatkowo wymaga wiedzy platformowej i koordynacji klastra, sieci oraz pamięci masowej. Ujednolicone utrzymanie może ograniczyć powtarzalną pracę, ale najpierw trzeba ten standard stworzyć i utrzymywać.
Warto porównać trzy warianty kosztowe: dalsze poprawne utrzymanie obecnej aplikacji, standaryzację na Compose albo wprowadzenie platformy Kubernetes. Dla każdego należy przyjąć takie same wymagania biznesowe. Inaczej łatwo porównać prosty pojedynczy serwer ze znacznie wyższym celem dostępności bez wyjaśnienia różnicy.
Jak podjąć uzasadnioną decyzję
- Określić wymagania operacyjne: opisać dopuszczalne przestoje, okna serwisowe, utratę danych i spodziewane zmiany.
- Ocenić aplikację: udokumentować wspierane metody instalacji, obsługę wielu instancji, pliki, sesje i interfejsy zewnętrzne.
- Przypisać odpowiedzialność: wskazać osoby odpowiedzialne za utrzymanie, alarmy, odtwarzanie i zastępstwa.
- Przetestować jedną usługę: przećwiczyć aktualizację, awarię i odtworzenie w proponowanym środowisku oraz udokumentować nakład pracy.
- Rozszerzyć później: ocenić kolejne aplikacje według tych samych kryteriów.
DAXS łączy ocenę aplikacji i jej interfejsów z planowaniem infrastruktury i odpowiednim modelem utrzymania. Do wstępnej oceny wystarczy konkretna usługa, jej zależności i wymagane efekty operacyjne. Od tego zaczyna się indywidualna rozmowa .
Źródła: Docker: model aplikacji Compose · Docker Compose w produkcji · Kubernetes: składniki i odpowiedzialności · Kubernetes: Deploymenty i rollouty · Planowanie produkcyjnego środowiska Kubernetes
