Aplikacje „chmurowe” lub po prostu „chmurowe” są tworzone specjalnie do pracy w infrastrukturze chmurowej. Zazwyczaj są one budowane jako zestaw luźno powiązanych mikrousług spakowanych w kontenerach, które z kolei są zarządzane przez platformę chmurową. Takie aplikacje są domyślnie przygotowane na awarie, co oznacza, że działają niezawodnie i skalują się nawet w przypadku poważnych awarii na poziomie infrastruktury. Drugą stroną medalu są zestawy ograniczeń (umów), które platforma chmurowa nakłada na aplikacje kontenerowe, aby móc nimi automatycznie zarządzać.
Chociaż wiele organizacji jest w pełni świadomych potrzeby i znaczenia przejścia na aplikacje oparte na chmurze, nadal nie wie, od czego zacząć. W tym wpisie przyjrzymy się szeregowi zasad, których przestrzeganie podczas tworzenia aplikacji kontenerowych pozwoli wykorzystać potencjał platform chmurowych i osiągnąć niezawodne działanie oraz skalowanie aplikacji nawet w przypadku poważnych awarii infrastruktury IT poziom. Ostatecznym celem przedstawionych tutaj zasad jest nauczenie się, jak tworzyć aplikacje, które mogą być automatycznie zarządzane przez platformy chmurowe, takie jak Kubernetes.
Zasady projektowania oprogramowania
W świecie programowania zasady odnoszą się do dość ogólnych zasad, których należy przestrzegać podczas tworzenia oprogramowania. Można ich używać podczas pracy z dowolnym językiem programowania. Każda zasada ma swoje własne cele, narzędzia do osiągnięcia, którymi są zwykle szablony i praktyki. Istnieje także szereg podstawowych zasad tworzenia wysokiej jakości oprogramowania, z których wypływają wszystkie inne. Oto kilka przykładów podstawowych zasad:
- (Zachowaj prostotę, głupcze) – nie komplikuj;
- (Nie powtarzaj się) - nie powtarzaj się;
- (Nie będziesz tego potrzebował) - nie twórz czegoś, co nie jest od razu potrzebne;
- Rozdzielenie obaw – podziel się obowiązkami.
Jak widać, zasady te nie wyznaczają żadnych konkretnych reguł, lecz należą do kategorii tzw. rozważań zdroworozsądkowych, opartych na praktycznych doświadczeniach, które podziela wielu programistów i do których regularnie się odwołują.
Ponadto istnieje – Zbiór pierwszych pięciu zasad programowania i projektowania obiektowego, sformułowany przez Roberta Martina. SOLID obejmuje szerokie, otwarte, uzupełniające się zasady, które – zastosowane razem – pomagają tworzyć lepsze systemy oprogramowania i lepiej je utrzymywać w dłuższej perspektywie.
Zasady SOLID należą do dziedziny OOP i są formułowane w języku takich pojęć i pojęć jak klasy, interfejsy i dziedziczenie. Przez analogię zasady programistyczne można sformułować także dla aplikacji chmurowych, jedynie podstawowym elementem nie będzie tutaj klasa, a kontener. Przestrzegając tych zasad, możesz tworzyć skonteneryzowane aplikacje, które lepiej spełniają cele i zadania platform chmurowych, takich jak Kubernetes.
Kontenery natywne w chmurze: podejście Red Hat
Obecnie prawie każdą aplikację można stosunkowo łatwo spakować do pojemników. Aby jednak aplikacje mogły być skutecznie zautomatyzowane i koordynowane w ramach platformy chmurowej takiej jak Kubernetes, wymagany jest dodatkowy wysiłek.
Podstawą przedstawionych poniżej pomysłów była metodologia i wiele innych prac poświęconych różnym aspektom budowania aplikacji internetowych, od zarządzania kodem źródłowym po modele skalowania. Opisane zasady dotyczą tylko tworzenia aplikacji kontenerowych zbudowanych na bazie mikrousług i zaprojektowanych dla platform chmurowych, takich jak Kubernetes. Podstawowym elementem naszej dyskusji jest obraz kontenera, a docelowym środowiskiem wykonawczym kontenera jest platforma orkiestracji kontenerów. Celem proponowanych zasad jest utworzenie kontenerów, dla których planowanie, skalowanie i monitorowanie zadań można zautomatyzować na większości platform orkiestracji. Zasady przedstawiono w dowolnej kolejności.
Zasada pojedynczego koncernu (SCP)
Zasada ta jest pod wieloma względami podobna do zasady pojedynczej odpowiedzialności. ), który jest częścią zestawu SOLID i stwierdza, że każdy obiekt musi mieć jedną odpowiedzialność i ta odpowiedzialność musi być całkowicie zawarta w klasie. Ideą SRP jest to, że każda odpowiedzialność jest powodem do zmiany, a klasa musi mieć jeden i tylko jeden powód do zmiany.
W SCP używamy słowa „obawa” zamiast słowa „odpowiedzialność”, aby wskazać wyższy poziom abstrakcji i szersze przeznaczenie kontenera w porównaniu z klasą OOP. A jeśli celem SRP jest mieć tylko jeden powód do zmian, to za SCP stoi chęć rozszerzenia możliwości ponownego użycia i wymiany pojemników. Postępując zgodnie z SRP i tworząc kontener, który rozwiązuje pojedynczy problem i robi to w sposób funkcjonalnie kompletny, zwiększasz szanse na ponowne wykorzystanie tego obrazu kontenera w różnych kontekstach aplikacji.
Zasada SCP mówi, że każdy pojemnik powinien rozwiązywać jeden pojedynczy problem i robić to dobrze. Co więcej, SCP w świecie kontenerów jest łatwiejszy do osiągnięcia niż SRP w świecie OOP, ponieważ kontenery zwykle uruchamiają jeden proces i przez większość czasu proces ten rozwiązuje jedno zadanie.
Jeśli mikrousługa kontenerowa musi rozwiązać kilka problemów na raz, można ją podzielić na kontenery jednozadaniowe i połączyć w ramach jednego podu (jednostki wdrożenia platformy kontenerowej) przy użyciu szablonów kontenerów sidecar i init. Ponadto SCP ułatwia wymianę starego kontenera (takiego jak serwer WWW lub broker wiadomości) na nowy, który rozwiązuje ten sam problem, ale ma rozszerzoną funkcjonalność lub lepiej się skaluje.
Zasada wysokiej obserwowalności (HOP)
Kiedy kontenery są używane jako ujednolicony sposób pakowania i uruchamiania aplikacji, same aplikacje są traktowane jak czarna skrzynka. Jeśli jednak są to kontenery w chmurze, to muszą udostępnić środowisku wykonawczemu specjalne API, aby monitorować kondycję kontenerów i w razie potrzeby podejmować odpowiednie działania. Bez tego nie będzie możliwe ujednolicenie automatyzacji aktualizacji kontenerów i zarządzania ich cyklem życia, co z kolei pogorszy stabilność i użyteczność systemu oprogramowania.
W praktyce skonteneryzowana aplikacja powinna co najmniej posiadać API do różnego rodzaju kontroli stanu: testów żywotności i testów gotowości. Jeśli aplikacja twierdzi, że potrafi więcej, musi zapewniać inne środki monitorowania swojego stanu. Na przykład rejestrowanie ważnych zdarzeń przez STDERR i STDOUT w celu agregacji dzienników przy użyciu Fluentd, Logstash i innych podobnych narzędzi. Oprócz integracji z bibliotekami śledzenia i gromadzenia metryk, takimi jak OpenTracing, Prometheus itp.
Generalnie aplikację nadal można traktować jako czarną skrzynkę, jednak należy ją wyposażyć we wszystkie API potrzebne platformie, aby jak najlepiej ją monitorować i zarządzać.
Zasada zgodności cyklu życia (LCP)
LCP jest przeciwieństwem HOP. Podczas gdy HOP stwierdza, że kontener musi udostępniać platformie interfejsy API do odczytu, LCP wymaga, aby aplikacja była w stanie akceptować informacje z platformy. Co więcej, kontener musi nie tylko odbierać zdarzenia, ale także dostosowywać się, czyli reagować na nie. Stąd nazwa zasady, którą można uznać za wymóg zapewnienia platformie możliwości pisania API.
Platformy mają różne typy zdarzeń, które pomagają zarządzać cyklem życia kontenera. Ale to sama aplikacja decyduje, które z nich dostrzeże i jak zareaguje.
Oczywiste jest, że niektóre wydarzenia są ważniejsze od innych. Na przykład, jeśli aplikacja nie toleruje dobrze awarii, musi akceptować komunikaty „signal:terminal” (SIGTERM) i jak najszybciej zainicjować procedurę zakończenia, aby przechwycić sygnał: kill (SIGKILL), który następuje po SIGTERM.
Ponadto zdarzenia takie jak PostStart i PreStop mogą być ważne dla cyklu życia aplikacji. Na przykład po uruchomieniu aplikacja może potrzebować trochę czasu na rozgrzewkę, zanim będzie mogła odpowiedzieć na żądania. Lub aplikacja musi zwolnić zasoby w jakiś specjalny sposób podczas zamykania.
Zasada niezmienności obrazu (IIP)
Ogólnie przyjmuje się, że aplikacje kontenerowe powinny pozostać niezmienione po zbudowaniu, nawet jeśli są uruchamiane w różnych środowiskach. Wymaga to konieczności przeniesienia przechowywania danych na zewnątrz w czasie wykonywania (innymi słowy użycia w tym celu zewnętrznych narzędzi) i polegania na zewnętrznych konfiguracjach specyficznych dla środowiska wykonawczego, zamiast modyfikowania lub tworzenia unikalnych kontenerów dla każdego środowiska. Po wprowadzeniu jakichkolwiek zmian w aplikacji obraz kontenera musi zostać odbudowany i wdrożony we wszystkich używanych środowiskach. Nawiasem mówiąc, przy zarządzaniu systemami informatycznymi stosuje się podobną zasadę, zwaną zasadą niezmienności serwerów i infrastruktury.
Celem protokołu IIP jest zapobieganie tworzeniu oddzielnych obrazów kontenerów dla różnych środowisk wykonawczych i używanie wszędzie tego samego obrazu wraz z odpowiednią konfiguracją specyficzną dla środowiska. Kierowanie się tą zasadą pozwala na realizację tak ważnych praktyk z punktu widzenia automatyzacji systemów chmurowych jak roll-back i roll-forward aktualizacji aplikacji.
Zasada jednorazowości procesu (PDP)
Jedną z najważniejszych cech kontenera jest jego efemeryczność: instancję kontenera można łatwo utworzyć i łatwo zniszczyć, dzięki czemu można go łatwo zastąpić inną instancją w dowolnym momencie. Powodów takiej wymiany może być wiele: niepowodzenie testu użyteczności, skalowanie aplikacji, przeniesienie na inny host, wyczerpanie zasobów platformy lub inne sytuacje.
W rezultacie aplikacje kontenerowe muszą utrzymywać swój stan za pomocą zewnętrznych środków lub korzystać w tym celu z wewnętrznych rozproszonych schematów z redundancją. Ponadto aplikacja musi szybko się uruchamiać i zamykać, a także być przygotowana na nagłą, krytyczną awarię sprzętu.
Jedną z praktyk, która pomaga wdrożyć tę zasadę, jest utrzymywanie małych pojemników. Środowiska chmurowe mogą automatycznie wybierać hosta, na którym zostanie uruchomiona instancja kontenera, więc im mniejszy kontener, tym szybciej się uruchomi – po prostu szybciej skopiuje się do hosta docelowego przez sieć.
Zasada samowystarczalności (S-CP)
Zgodnie z tą zasadą, już na etapie montażu, w kontenerze znajdują się wszystkie niezbędne elementy. Kontener należy zbudować przy założeniu, że system posiada wyłącznie czyste jądro Linuksa, zatem wszystkie potrzebne dodatkowe biblioteki należy umieścić w samym kontenerze. Powinien także zawierać takie elementy, jak środowisko wykonawcze odpowiedniego języka programowania, platformę aplikacji (jeśli to konieczne) i inne zależności, które będą wymagane podczas działania aplikacji kontenerowej.
Wyjątki dotyczą konfiguracji, które różnią się w zależności od środowiska i muszą być dostarczone w czasie wykonywania, na przykład za pośrednictwem Kubernetes ConfigMap.
Aplikacja może zawierać kilka skonteneryzowanych komponentów, na przykład oddzielny kontener DBMS w skonteneryzowanej aplikacji internetowej. Zgodnie z zasadą S-CP kontenerów tych nie należy łączyć w jeden, ale należy je tak wykonać, aby kontener DBMS zawierał wszystko, co niezbędne do działania bazy danych, a kontener aplikacji webowej zawierał wszystko, co niezbędne do działania sieci WWW aplikacji, ten sam serwer WWW. W rezultacie w czasie wykonywania kontener aplikacji internetowej będzie zależny od kontenera DBMS i będzie uzyskiwał do niego dostęp w razie potrzeby.
Zasada ograniczenia czasu wykonania (RCP)
Zasada S-CP definiuje, w jaki sposób kontener powinien być zbudowany i co powinien zawierać plik binarny obrazu. Ale kontener to nie tylko „czarna skrzynka”, która ma tylko jedną cechę – rozmiar pliku. Podczas wykonywania kontener przyjmuje inne wymiary: ilość używanej pamięci, czas procesora i inne zasoby systemowe.
I tu z pomocą przychodzi zasada RCP, według której kontener musi zdekapitować swoje wymagania dotyczące zasobów systemowych i przenieść je na platformę. Dzięki profilom zasobów każdego kontenera (ile potrzebuje procesora, pamięci, sieci i zasobów dyskowych) platforma może optymalnie przeprowadzać planowanie i automatyczne skalowanie, zarządzać wydajnością IT i utrzymywać poziomy SLA dla kontenerów.
Oprócz spełnienia wymagań zasobowych kontenera ważne jest również, aby aplikacja nie wychodziła poza własne granice. W przeciwnym razie, gdy wystąpi niedobór zasobów, platforma z większym prawdopodobieństwem umieści je na liście aplikacji, które wymagają zakończenia lub migracji.
Kiedy mówimy o stawianiu na chmurę, mamy na myśli sposób, w jaki pracujemy.
Powyżej sformułowaliśmy szereg ogólnych zasad, które wyznaczają metodologiczny fundament budowania wysokiej jakości aplikacji kontenerowych dla środowisk chmurowych.
Pamiętaj, że oprócz tych ogólnych zasad będziesz także potrzebować dodatkowych zaawansowanych metod i technik pracy z kontenerami. Ponadto mamy kilka krótkich zaleceń, które są bardziej szczegółowe i należy je zastosować (lub nie zastosować) w zależności od sytuacji:
- Spróbuj zmniejszyć rozmiar obrazów: usuń pliki tymczasowe i nie instaluj niepotrzebnych pakietów - im mniejszy rozmiar kontenera, tym szybciej jest on montowany i kopiowany przez sieć do hosta docelowego.
- Skoncentruj się na dowolnych identyfikatorach użytkowników: nie używaj polecenia sudo ani żadnego specjalnego identyfikatora użytkownika do uruchamiania kontenerów.
- Oznacz ważne porty: Możesz ustawić numery portów w czasie wykonywania, ale lepiej jest określić je za pomocą polecenia EXPOSE - ułatwi to innym osobom i programom korzystanie z Twoich obrazów.
- Przechowuj trwałe dane na woluminach: Dane, które powinny pozostać po zniszczeniu kontenera, należy zapisać na woluminach.
- Zapisuj metadane obrazu: tagi, etykiety i adnotacje ułatwiają korzystanie z obrazów — inni programiści będą Ci wdzięczni.
- Synchronizuj hosta i obrazy: niektóre aplikacje kontenerowe wymagają synchronizacji kontenera z hostem pod kątem określonych atrybutów, takich jak czas lub identyfikator komputera.
- Podsumowując, udostępniamy szablony i najlepsze praktyki, które pomogą Ci skuteczniej wdrożyć wymienione powyżej zasady:
11 czerwca o godz. 11.00
Czego się nauczysz:
- Niezmienny system Red Hat Enterprise Linux CoreOS
- Siatka usług OpenShift
- Struktura operatora
- Ramy kative
Źródło: www.habr.com