Dlaczego warstwowa budowa obrazu?

Pierwszą zaletą jest przyspieszenie procesu budowania obrazów. Za całość odpowiada mechanizm cache’owania, który w trakcie budowania obrazów sprawdza, czy suma kontrolna (SHA256) dla plików poszczególnej warstwy zmieniła się. Jeżeli nie, proces budowania przechodzi dalej – do kolejnej warstwy. Dzięki takiemu rozwiązaniu proces budowania jest szybszy, gdyż budowane ponownie będą tylko te warstwy, dla których zmieniła się suma kontrolna. Drugim powodem, dla którego warstwowa budowa obrazów ma sens, jest wielokrotne wykorzystywanie poszczególnych warstw dla różnych obrazów. Identyfikatorem warstwy jest suma kontrolna SHA256 z archiwum zawierającego pliki danej warstwy. Dzięki temu różne obrazy mogą wykorzystywać te same warstwy, pod warunkiem, że wszystkie warstwy nadrzędne dla dwóch różnych obrazów są również takie same.

Dziedziczenie warstw z obrazów bazowych

Dziedziczenie warstw z obrazów bazowych zostanie omówione na przykładzie
oficjalnego obrazu NodeJS znajdującego się na Docker Hubie. Jest to oficjalne repozytorium, gdzie publikowane są obrazy, z których każdy może skorzystać. Publikują je właściciele danego narzędzia/systemu. W przypadku projektów open-source obrazy są publikowane przez społeczność rozwijająca dany projekt.

[...]

Na pierwszy rzut oka takie podejście może wydawać się nieco dziwne, ale jest to „standard” dla większości oficjalnych obrazów dostępnych na Docker Hubie. W powyżej przedstawionym przykładzie można zauważyć, że obraz dziedziczy wszystkie warstwy – począwszy od obrazu buildpack-deps:stretch – skończywszy na obrazie debian:strech. To wszystko powoduje, że obraz końcowy również będzie mieć wszystkie warstwy pośrednie.

Elementarne koszty klastra Kubernetes
Istnieje wiele możliwości tworzenia, konfigurowania i zarządzania klastrem (zarówno w chmurze publicznej jak i prywatnej). Jedną z nich jest zarządzana, prekonfigurowana z wbudowanym szeregiem automatyzacji platforma kontenerowa. Jej wstępna wycena, przy pomocy dostępnego kalkulatora, nie nastręcza trudności, zmusza jednak do podjęcia podstawowych decyzji architekturalnych – takich jak: moc obliczeniowa, rozmiar pamięci, konfiguracja sieci, aspektów bezpieczeństwa. To zdecydowanie główny punkt całego kosztorysu, ale niekoniecznie najdroższy.

Koszty związane z monitoringiem

💡 Rozważając migrację do środowiska Kubernetes, należy być świadomym, że może to pociągnąć za sobą zmiany w komponentach odpowiedzialnych za monitorowanie aplikacji biznesowych.

W omawianych przypadku klient monitoruje szczegółowo aplikację głównie za pomocą natywnych mechanizmów chmury. Nasuwa się pytanie: czy te mechanizmy będą nadal efektywne po migracji? To kolejny, kluczowy element analizy w całym procesie migracyjnym.

Monitoring i bezpieczeństwo to dwa najważniejsze aspekty dla naszego klienta, zwłaszcza w kontekście bankowości internetowej, gdzie bezpieczeństwo jest priorytetem. Klienci oczekują niezawodnego dostępu do usług, takich jak sprawdzanie salda konta czy realizacja przelewów. W przypadku jakichkolwiek problemów z aplikacją, bank musi działać proaktywnie, aby wykryć i rozwiązać wszelkie nieprawidłowości, zanim zauważy je klient.

Bezpieczeństwo rozwiązania
Z naszego doświadczenia wynika, że jednymi z najdroższych komponentów kosztorysu są te związane z bezpieczeństwem. Chociaż chmura oferuje solidne rozwiązania dotyczące bezpieczeństwa klastra Kubernetes – pod warunkiem, że są one odpowiednio zaprojektowane – na rynku dostępne są bardziej zaawansowane opcje. Warto tutaj kierować się proponowanym przez społeczność specjalistów Kubernetes frameworkiem 4C: Code, Container, Cluster, Cloud. Holistyczne podejście do tych czterech obszarów pozwala ocenić poziom dojrzałości praktyk bezpieczeństwa w przedsiębiorstwie. Wybór właściwego stosu narzędzi związanych z security jest procesem długotrwałym, skomplikowanym i wymagającym dogłębnej wiedzy z zakresu bezpieczeństwa we wszystkich powyższych obszarach.

Warto jednak zainwestować czas w taką analizę, gdyż koszty tej klasy narzędzi są znaczące a pokusa oparcia całego rozwiązania o narzędzia open-source wielka i niestety (z naszego doświadczenia) często zwodnicza.