Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00077 011476 20237165 na godz. na dobę w sumie
Najlepsze praktyki w Kubernetes. Jak budować udane aplikacje - ebook/pdf
Najlepsze praktyki w Kubernetes. Jak budować udane aplikacje - ebook/pdf
Autor: , , , Liczba stron: 248
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-7233-7 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> inne - programowanie
Porównaj ceny (książka, ebook (-30%), audiobook).

Systemy informatyczne oparte na chmurze stały się atrakcyjną alternatywą dla standardowej infrastruktury. Wymusiły jednak radykalne zmiany w praktykach tworzenia, wdrażania i utrzymywania aplikacji. Dziś uwaga profesjonalistów skupiona jest na Kubernetes, który w ciągu zaledwie kilku lat stał się faktycznym standardem wdrażania natywnej chmury. Aby tworzone aplikacje funkcjonowały wydajnie, bezawaryjnie i niezawodnie, warto wdrożyć i stosować wzorce i najlepsze praktyki. Konieczne jest również przemodelowanie sposobu pracy programistów.

Ta książka jest przeznaczona dla profesjonalnych użytkowników Kubernetes, którzy chcą poznać wzorce i najlepsze praktyki przy wdrażaniu rzeczywistych rozwiązań. Znalazły się tu informacje o jego działaniu w różnych skalach, topologiach i domenach, a także liczne przykłady zastosowania omawianych technologii. Sporo miejsca poświęcono zagadnieniom projektowania aplikacji, konfiguracji i działania usług Kubernetes, a także ciągłej integracji i testowania aplikacji. Ważnym zagadnieniem są takie aspekty zarządzania klastrem jak przydzielanie zasobów, zapewnienie bezpieczeństwa czy autoryzacja i dostęp do klastra. Prezentowane treści zilustrowano fragmentami przejrzystego kodu, co dodatkowo zwiększa przydatność tej książki w pracy inżyniera.

Najciekawsze zagadnienia:

Najlepsze praktyki w Kubernetes: poradzisz sobie z każdym wyzwaniem!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Tytuł oryginału: Kubernetes Best Practices: Blueprints for Building Successful Applications on Kubernetes Tłumaczenie: Robert Górczyński ISBN: 978-83-283-7232-0 © 2020 Helion SA Authorized Polish translation of the English edition of Kubernetes Best Practices ISBN 9781492056478 © 2020 Brendan Burns, Eddie Villalba, Dave Strebel, and Lachlan Evenson This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher. Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autorzy oraz Helion SA dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autorzy oraz Helion SA nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Helion SA ul. Kościuszki 1c, 44-100 Gliwice tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: http://helion.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/naprak Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Pliki z przykładami omawianymi w książce można znaleźć pod adresem: ftp://ftp.helion.pl/przyklady/naprak.zip Printed in Poland. • Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność Spis treści Wprowadzenie .......................................................................................................... 11 Najlepsze praktyki dotyczące zarządzania obrazami kontenera Tworzenie replikowanej aplikacji Ogólne omówienie aplikacji Zarządzanie plikami konfiguracyjnymi Tworzenie usługi replikowanej za pomocą wdrożeń 1. Konfiguracja podstawowej usługi .............................................................................. 15 15 15 17 17 18 20 21 22 25 28 29 31 32 33 Konfiguracja zewnętrznego przychodzącego ruchu sieciowego HTTP Konfigurowanie aplikacji za pomocą zasobu ConfigMap Zarządzanie uwierzytelnianiem za pomocą danych poufnych Wdrożenie prostej bezstanowej bazy danych Utworzenie za pomocą usług mechanizmu równoważenia obciążenia TCP Przekazanie przychodzącego ruchu sieciowego do serwera pliku statycznego Parametryzowanie aplikacji za pomocą menedżera pakietów Helm Najlepsze praktyki dotyczące wdrożenia Podsumowanie Cele Tworzenie klastra programistycznego Konfiguracja klastra współdzielonego przez wielu programistów 2. Sposób pracy programisty ......................................................................................... 35 35 36 37 38 40 42 43 43 43 44 Przygotowywanie zasobów dla użytkownika Tworzenie i zabezpieczanie przestrzeni nazw Zarządzanie przestrzeniami nazw Usługi na poziomie klastra Umożliwienie pracy programistom Konfiguracja początkowa Umożliwienie aktywnego programowania 3 Poleć książkęKup książkę Umożliwienie testowania i debugowania Najlepsze praktyki dotyczące konfiguracji środowiska programistycznego Podsumowanie 45 46 46 cAdvisor Wskaźniki serwera kube-state-metrics Wskaźniki kontra dzienniki zdarzeń Techniki monitorowania Wzorce monitorowania Ogólne omówienie wskaźników Kubernetes 3. Monitorowanie i rejestrowanie danych w Kubernetes ................................................ 47 47 47 48 49 49 50 50 51 52 54 58 60 60 62 64 64 64 64 65 Które wskaźniki powinny być monitorowane? Narzędzia do monitorowania Monitorowanie Kubernetes za pomocą narzędzia Prometheus Ogólne omówienie rejestrowania danych Narzędzia przeznaczone do rejestrowania danych Rejestrowanie danych za pomocą stosu EFK Ostrzeganie Najlepsze praktyki dotyczące monitorowania, rejestrowania danych i ostrzegania Monitorowanie Rejestrowanie danych Ostrzeganie Podsumowanie Konfiguracja za pomocą zasobu ConfigMap i danych poufnych 4. Konfiguracja, dane poufne i RBAC .............................................................................. 67 67 67 68 69 74 75 77 79 Najlepsze praktyki dotyczące API zasobu ConfigMap i danych poufnych RBAC Krótkie wprowadzenie do mechanizmu RBAC Najlepsze praktyki dotyczące mechanizmu RBAC ConfigMap Dane poufne Podsumowanie 5. Ciągła integracja, testowanie i ciągłe wdrażanie ........................................................ 81 82 82 82 83 84 System kontroli wersji Ciągła integracja Testowanie Kompilacja kontenera Oznaczanie tagiem obrazu kontenera 4  Spis treści Poleć książkęKup książkę Ciągłe wdrażanie Strategie wdrażania Testowanie w produkcji Stosowanie inżynierii chaosu i przygotowania Konfiguracja ciągłej integracji Konfiguracja ciągłego wdrażania Przeprowadzanie operacji uaktualnienia Prosty eksperyment z inżynierią chaosu Najlepsze praktyki dotyczące technik ciągłej integracji i ciągłego wdrażania Podsumowanie 85 85 89 91 91 93 94 94 95 96 Wersjonowanie aplikacji Wydania aplikacji Wdrożenia aplikacji Połączenie wszystkiego w całość 6. Wersjonowanie, wydawanie i wdrażanie aplikacji ...................................................... 97 98 98 99 100 103 104 Najlepsze praktyki dotyczące wersjonowania, wydawania i wycofywania wdrożeń Podsumowanie 7. Rozpowszechnianie aplikacji na świecie i jej wersje robocze ......................................105 106 107 Rozpowszechnianie obrazu aplikacji Parametryzacja wdrożenia Mechanizm równoważenia obciążenia związanego z ruchem sieciowym w globalnie wdrożonej aplikacji Niezawodne wydawanie oprogramowania udostępnianego globalnie Weryfikacja przed wydaniem oprogramowania Region kanarkowy Identyfikacja typów regionów Przygotowywanie wdrożenia globalnego Gdy coś pójdzie nie tak Najlepsze praktyki dotyczące globalnego wdrożenia aplikacji Podsumowanie 107 108 108 111 111 112 113 114 115 Predykaty Priorytety Zarządca procesów w Kubernetes 8. Zarządzanie zasobami ..............................................................................................117 117 117 118 119 119 120 120 Podobieństwo i brak podobieństwa podów nodeSelector Wartość taint i tolerancje Zaawansowane techniki stosowane przez zarządcę procesów Spis treści  5 Poleć książkęKup książkę Zarządzanie zasobami poda Żądanie zasobu Ograniczenia zasobów i jakość usługi poda PodDisruptionBudget Zarządzanie zasobami za pomocą przestrzeni nazw ResourceQuota LimitRange Skalowanie klastra Skalowanie aplikacji Skalowanie za pomocą HPA HPA ze wskaźnikami niestandardowymi Vertical Pod Autoscaler Najlepsze praktyki dotyczące zarządzania zasobami Podsumowanie 122 122 123 125 126 127 128 129 130 131 132 133 133 134 Usługi w Kubernetes Reguły działania sieci w Kubernetes Wtyczki sieci Kubenet Najlepsze praktyki dotyczące pracy z Kubenet Wtyczka zgodna ze specyfikacją CNI Najlepsze praktyki dotyczące pracy z wtyczkami zgodnymi ze specyfikacją CNI 9. Sieć, bezpieczeństwo sieci i architektura Service Mesh .............................................. 135 135 137 137 138 139 139 140 140 142 143 143 144 146 146 148 150 151 152 Typ usługi ClusterIP Typ usługi NodePort Typ usługi ExternalName Typ usługi LoadBalancer Ingress i kontrolery Ingress Najlepsze praktyki dotyczące usług i kontrolerów Ingress Najlepsze praktyki dotyczące architektury Service Mesh Polityka zapewnienia bezpieczeństwa sieci Najlepsze praktyki dotyczące polityki sieci Architektura Service Mesh Podsumowanie API PodSecurityPolicy 10. Bezpieczeństwo poda i kontenera ............................................................................ 153 153 153 155 162 Włączenie zasobu PodSecurityPolicy Anatomia zasobu PodSecurityPolicy Wyzwania związane z zasobem PodSecurityPolicy 6  Spis treści Poleć książkęKup książkę Najlepsze praktyki dotyczące zasobu PodSecurityPolicy Następne kroki związane z zasobem PodSecurityPolicy Izolacja zadania i API RuntimeClass Używanie API RuntimeClass Implementacje środowiska uruchomieniowego Najlepsze praktyki dotyczące izolacji zadań i API RuntimeClass Pozostałe rozważania dotyczące zapewnienia bezpieczeństwa poda i kontenera Kontrolery dopuszczenia Narzędzia do wykrywania włamań i anomalii Podsumowanie 163 163 164 164 165 166 166 166 167 167 Dlaczego polityka i zarządzanie są ważne? Co odróżnia tę politykę od innych? Silnik polityki natywnej chmury Wprowadzenie do narzędzia Gatekeeper 11. Polityka i zarządzanie klastrem ................................................................................169 169 169 170 170 171 171 172 173 174 174 175 176 176 176 177 Przykładowe polityki Terminologia stosowana podczas pracy z Gatekeeper Definiowanie szablonu ograniczenia Definiowanie ograniczenia Replikacja danych UX Audyt Poznanie narzędzia Gatekeeper Następne kroki podczas pracy z narzędziem Gatekeeper Najlepsze praktyki dotyczące polityki i zarządzania Podsumowanie 12. Zarządzanie wieloma klastrami ................................................................................179 179 Do czego potrzebujesz wielu klastrów? Kwestie do rozważenia podczas projektowania architektury składającej się z wielu klastrów Zarządzanie wieloma wdrożeniami klastrów Wzorce wdrażania i zarządzania Podejście GitOps w zakresie zarządzania klastrami Narzędzia przeznaczone do zarządzania wieloma klastrami Federacja Kubernetes Najlepsze praktyki dotyczące zarządzania wieloma klastrami Podsumowanie 181 183 183 185 187 187 190 191 Spis treści  7 Poleć książkęKup książkę 13. Integracja usług zewnętrznych z Kubernetes ............................................................ 193 Importowanie usług do Kubernetes 193 194 194 196 197 Pozbawiona selektora usługa dla stabilnego adresu IP Oparte na rekordzie CNAME usługi dla stabilnych nazw DNS Podejście oparte na aktywnym kontrolerze Eksportowanie usług z Kubernetes Eksportowanie usług za pomocą wewnętrznych mechanizmów równoważenia obciążenia Eksportowanie usług za pomocą usługi opartej na NodePort Integracja komputerów zewnętrznych z Kubernetes Współdzielenie usług między Kubernetes Narzędzia opracowane przez podmioty zewnętrzne Najlepsze praktyki dotyczące nawiązywania połączeń między klastrami a usługami zewnętrznymi Podsumowanie 197 198 199 200 200 201 201 Dlaczego Kubernetes doskonale sprawdza się w połączeniu z uczeniem maszynowym? Sposób pracy z zadaniami uczenia głębokiego Uczenie maszynowe dla administratorów klastra Kubernetes 14. Uczenie maszynowe w Kubernetes .......................................................................... 203 203 204 205 205 208 208 208 209 210 211 211 212 Trenowanie modelu w Kubernetes Trenowanie rozproszone w Kubernetes Ograniczenia dotyczące zasobów Sprzęt specjalizowany Biblioteki, sterowniki i moduły jądra Pamięć masowa Sieć Protokoły specjalizowane Obawy użytkowników zajmujących się analizą danych Najlepsze praktyki dotyczące wykonywania w Kubernetes zadań związanych z uczeniem maszynowym Podsumowanie 212 213 Rozszerzanie klastrów Kubernetes Wrażenia użytkownika podczas rozszerzania Kubernetes Rozważania projektowe podczas budowania platformy Podejścia w zakresie tworzenia abstrakcji wysokiego poziomu Rozszerzanie Kubernetes 15. Tworzenie wzorców aplikacji wysokiego poziomu na podstawie Kubernetes ............. 215 215 216 216 218 218 218 219 220 220 Obsługa eksportowania do obrazu kontenera Obsługa istniejących mechanizmów dla usług i wykrywania usług Najlepsze praktyki dotyczące tworzenia platform dla aplikacji Podsumowanie 8  Spis treści Poleć książkęKup książkę Pamięć masowa w Kubernetes Woluminy i punkty montowania Najlepsze praktyki dotyczące woluminów 16. Zarządzanie informacjami o stanie i aplikacjami wykorzystującymi te dane ...............221 222 223 223 223 224 225 226 227 228 229 230 231 API PersistentVolume API PersistentVolumeClaims Klasy pamięci masowej Najlepsze praktyki dotyczące pamięci masowej w Kubernetes Zasób StatefulSet Operatory Najlepsze praktyki dotyczące zasobu StatefulSet i operatorów Aplikacje obsługujące informacje o stanie Podsumowanie Sterowanie dopuszczeniem Czym jest kontroler dopuszczenia? Typy kontrolerów dopuszczenia Konfiguracja zaczepu sieciowego dopuszczenia Najlepsze praktyki dotyczące sterowania dopuszczeniem 17. Sterowanie dopuszczeniem i autoryzacja ..................................................................233 233 234 234 235 237 239 239 242 242 Moduły autoryzacji Najlepsze praktyki dotyczące autoryzacji Podsumowanie Autoryzacja 18. Zakończenie .............................................................................................................243 Spis treści  9 Poleć książkęKup książkę 10  Spis treści Poleć książkęKup książkę ROZDZIAŁ 5. Ciągła integracja, testowanie i ciągłe wdrażanie W tym rozdziale zostaną przedstawione kluczowe koncepcje dotyczące integracji z mechanizmem ciągłej integracji (ang. continuous integration, CI) i ciągłego wdrażania (ang. continuous deployment, CD) podczas dostarczania aplikacji do Kubernetes. Przygotowanie doskonałego sposobu pracy pozwoli na sprawne dostarczanie aplikacji do środowiska produkcyjnego. Dlatego też w rozdziale będą zaprezentowane metody, narzędzia i procesy umożliwiające stosowanie technik CI i CD we własnym środowisku pracy. Celem technik CI i CD jest opracowanie w pełni zautomatyzowanego procesu, od programisty umieszczającego kod w repozytorium po przekazanie nowej aplikacji do środowiska produkcyjnego. Najlepiej będzie unikać ręcznego wdrażania w Kubernetes uaktual- nionych aplikacji, ponieważ ten proces jest podatny na błędy. Ponadto ręczne zarządzanie uaktu- alnieniami aplikacji w Kubernetes prowadzi do zmian w konfiguracji i niepewnych uaktualnień oraz ogólnie do utraty zwinności podczas procesu dostarczania aplikacji. W rozdziale zostaną omówione następujące zagadnienia:  system kontroli wersji,  ciągła integracja,  testowanie,  oznaczanie tagami obrazów kontenera,  ciągłe wdrażanie,  strategie wdrażania,  testowanie wdrożeń,  testowanie w chaosie. Zaprezentujemy również przykładowe techniki CI i CD, na które składają się wymienione tutaj zadania:  przekazywanie do repozytorium Git zmian wprowadzonych w kodzie źródłowym,  kompilowanie kodu aplikacji,  testowanie kodu, 81 Poleć książkęKup książkę  utworzenie obrazu kontenera po zakończeniu testów powodzeniem,  przekazywanie obrazu kontenera do rejestru kontenerów,  wdrażanie aplikacji w Kubernetes,  przeprowadzanie testów wdrożonej aplikacji,  nieustanne uaktualnianie wdrożenia. System kontroli wersji Każde rozwiązanie oparte na technikach CI i CD rozpoczyna się od systemu kontroli wersji, któ- rego zadaniem jest obsługa historii zmian kodu aplikacji i jej konfiguracji. Git stał się standardem przemysłowym w dziedzinie platform zarządzania kodem źródłowym, a każde repozytorium Git ma tzw. gałąź master (ang. master branch), która jest gałęzią główną repozytorium i zawiera kod przeznaczony do wdrożenia w środowisku produkcyjnym. W repozytorium zwykle znajdują się także inne gałęzie przeznaczone do opracowywania kolejnych funkcjonalności aplikacji, a wpro- wadzone w nich zmiany ostatecznie i tak trafiają do gałęzi master. Istnieje wiele strategii związa- nych z tworzeniem gałęzi, a konkretna konfiguracja będzie zależała od struktury organizacji i se- paracji zadań. Według nas kod aplikacji i kod konfiguracji, czyli np. manifest Kubernetes lub plik menedżera Helm w formacie chart, pomagają w promowaniu dobrych praktyk DevOps w zakre- sie komunikacji i współpracy. Gdy programiści aplikacji i inżynierowie operacji współpracują nad kodem znajdującym się w jednym repozytorium, to daje przekonanie, że zespół będzie w stanie dostarczyć aplikację do środowiska produkcyjnego. Ciągła integracja Ciągła integracja to proces nieustannego integrowania zmian w kodzie z repozytorium systemu kontroli wersji. Zamiast rzadko przekazywać większe zmiany, znacznie częściej przekazuje się mniejsze. Każde przekazanie zmian do repozytorium powoduje rozpoczęcie kompilacji kodu źródłowego. Dzięki temu można o wiele szybciej otrzymać informacje o tym, co zostało zepsute w aplikacji, gdy wystąpi w niej problem. W tym miejscu prawdopodobnie zadajesz sobie pytanie w rodzaju: „Dlaczego miałbym poznawać szczegóły związane z kompilacją aplikacji, skoro to jest zadanie programisty?”. Tradycyjnie tak było, choć w ostatnim czasie można zaobserwować w firmach przesunięcie w stronę podejścia kultury DevOps, w którym zespół operacji jest bliżej kodu aplikacji i procesów związanych z jej tworzeniem. Istnieje wiele rozwiązań w dziedzinie ciągłej integracji. Jednym z najpopularniejszych narzędzi tego typu jest Jenkins. Testowanie Celem testów jest szybkie dostarczenie informacji o zmianach w kodzie, które doprowadziły do uszkodzenia aplikacji. Używany język programowania będzie miał wpływ na framework testów, który wykorzystasz do ich przygotowania. Przykładowo aplikacje w języku Go używają go test 82  Rozdział 5. Ciągła integracja, testowanie i ciągłe wdrażanie Poleć książkęKup książkę do uruchomienia zestawu testów jednostkowych dla bazy kodu. Opracowanie rozbudowanego zestawu testów pomaga unikać sytuacji, gdy do środowiska produkcyjnego zostaje przekazany niepoprawnie działający kod. Chcesz mieć pewność, że jeśli test zostanie niezaliczony w środowi- sku programistycznym, natychmiast po jego zakończeniu kompilacja zakończy się niepowodze- niem. Nie chcesz utworzyć obrazu kontenera i przekazać go do repozytorium, gdy jakikolwiek test bazy kodu kończy się niepowodzeniem. Także w tym przypadku być może zadajesz sobie pytanie w rodzaju: „Czy tworzenie testów nie powinno być zadaniem programisty aplikacji?”. Gdy zaczniesz stosować zautomatyzowaną infra- strukturę dostarczania aplikacji do środowiska produkcyjnego, musisz pomyśleć o przeprowa- dzaniu zautomatyzowanych testów całej bazy kodu. Przykładowo z rozdziału 2. dowiedziałeś się nieco o użyciu menedżera pakietów Helm w celu przygotowania aplikacji do umieszczenia w Ku- bernetes. Ten menedżer zawiera narzędzie o nazwie helm lint, którego działanie polega na wy- konaniu serii testów względem pliku w formacie chart i przeanalizowaniu kodu pod kątem po- tencjalnych problemów. Istnieje wiele różnych testów do wykonania podczas przygotowywania aplikacji. Część z nich powinna być wykonywana przez programistów, inne zaś to wysiłek podej- mowany wspólnie przez wszystkich. Testowanie bazy kodu i dostarczanie na jej podstawie goto- wej aplikacji do środowiska produkcyjnego jest wysiłkiem całego zespołu i ta operacja powinna być zaimplementowana od początku do końca. Kompilacja kontenera Podczas tworzenia obrazów należy optymalizować ich wielkość. Mniejszy obraz oznacza skróce- nie czasu potrzebnego na pobranie i wdrożenie obrazu, a ponadto zwiększa poziom jego bezpie- czeństwa. Istnieje wiele sposobów na optymalizację wielkości obrazu, z których część wiąże się z pewnymi kompromisami. Zapoznaj się ze strategiami, które pomagają w tworzeniu możliwie małych obrazów zawierających budowane aplikacje. Kompilacja wieloetapowa To pozwala na usunięcie zależności niepotrzebnych do działania aplikacji. Przykładowo w przy- padku języka programowania Go nie potrzebujemy wszystkich narzędzi kompilacji używa- nych do utworzenia statycznych plików binarnych. Dlatego też kompilacja wieloetapowa po- zwala na użycie jednego pliku Dockerfile do przeprowadzenia kompilacji, a ostateczny obraz będzie zawierał tylko statyczne pliki binarne wymagane do uruchomienia aplikacji. Obraz bazowy nieoparty na żadnej dystrybucji To pozwala na usunięcie z obrazu wszystkich niepotrzebnych plików binarnych i powłok. Skutkiem jest znaczne zmniejszenie wielkości obrazu i zwiększony poziom bezpieczeństwa. Natomiast wadą obrazu nieopartego na żadnej dystrybucji jest to, że jeśli nie masz powłoki, wówczas nie będziesz mógł dołączyć debugera do obrazu. Być może uważasz, że to świetne rozwiązanie, ale w rzeczywistości znacznie utrudni debugowanie aplikacji. Takie obrazy nie zawierają żadnego menedżera pakietów, powłoki ani innych typowych pakietów systemu ope- racyjnego, więc możesz nie uzyskać dostępu do narzędzi debugowania znanych Ci z typowego systemu operacyjnego. Kompilacja kontenera  83 Poleć książkęKup książkę Zoptymalizowane obrazy bazowe W przypadku tych obrazów skoncentrowano się na usunięciu wszelkich elementów warstwy systemu operacyjnego i dostarczeniu minimalnej wersji obrazu. Przykładowo Alpine oferuje obraz bazowy o wielkości około 10 MB, a także pozwala na dołączenie debugera lokalnego podczas opracowywania aplikacji w lokalnym środowisku programistycznym. Inne dystrybu- cje również oferują zoptymalizowane obrazy bazowe; przykładem może być tutaj obraz Slim dystrybucji Debian. To może być doskonałe rozwiązanie, ponieważ zoptymalizowane obrazy zapewniają możliwości oczekiwane w środowisku programistycznym, a zarazem są zoptyma- lizowane pod względem wielkości obrazu i podatności na ataki. Optymalizacja obrazów ma wyjątkowo duże znaczenie, choć często jest niedoceniana przez użyt- kowników. Mogą być ku temu pewne powody, np. wynikające z przyjętych w firmie standardów dotyczących dozwolonych do użycia systemów operacyjnych, ale warto je odłożyć na bok, aby maksymalizować wartość kontenerów. Zauważyliśmy, że firmy, które zaczęły używać Kubernetes, zwykle są zadowolone ze stosowanego systemu operacyjnego, a mimo to decydują się na wybór znacznie bardziej zoptymalizowanego obrazu, takiego jak Debian Slim. Gdy zdobędziesz większe doświadczenie w tworzeniu aplikacji dla środowiska kontenerów, poczujesz się pewniej podczas pracy z obrazami nieopartymi na żad- nych dystrybucjach. Oznaczanie tagiem obrazu kontenera Kolejnym krokiem w procesie ciągłej integracji jest utworzenie obrazu Dockera, aby mógł zostać wdrożony do wybranego środowiska. Bardzo duże znaczenie ma stosowanie strategii nadawania tagów obrazom, co pozwoli na łatwe identyfikowanie wersjonowanych obrazów wdrożonych w środowiskach. Jedną z najważniejszych kwestii jest zaprzestanie używania słowa latest jako tagu obrazu. Używanie tagu obrazu nieprzedstawiającego wersji oznacza brak możliwości ustalenia zmian, po których wprowadzeniu w kodzie nastąpiło wygenerowanie takiego obrazu. Każdy ob- raz tworzony w procesie CI powinien mieć unikatowy tag. Istnieje wiele użytecznych strategii podczas oznaczania obrazów tagami w procesie ciągłej inte- gracji. Wymienione tutaj strategie pozwalają bardzo łatwo identyfikować zmiany w kodzie i kon- kretnej kompilacji, z którą zmiany te są powiązane. Identyfikator kompilacji Po rozpoczęciu kompilacji zostaje z nią powiązany pewien identyfikator. Użycie tej części tagu pozwala odwołać się do konkretnej kompilacji powiązanej z obrazem. Identyfikator systemu kompilacji — identyfikator kompilacji To jest taki sam identyfikator jak poprzedni, ale zawiera także identyfikator systemu kompi- lacji, co okazuje się przydatne dla użytkowników, którzy mają wiele systemów kompilacji. Wartość hash z repozytorium Git W przypadku nowej operacji przekazania kodu do repozytorium następuje wygenerowanie wartości hash w repozytorium Git. Następnie ta wartość hash jest używana jako tag, pozwalają- cy na łatwe odwołanie się do operacji, która spowodowała zainicjowanie generowania obrazu. 84  Rozdział 5. Ciągła integracja, testowanie i ciągłe wdrażanie Poleć książkęKup książkę Wartość hash dla identyfikatora kompilacji Ta wartość pozwala odwoływać się do operacji przekazania kodu do repozytorium i identyfi- katora kompilacji, w której wyniku powstał obraz. Trzeba w tym miejscu dodać, że ten znacznik może być dość długi. Ciągłe wdrażanie Ciągłe wdrażanie to proces, w którym zmiany pasywnie przekazywane z sukcesem do systemu ciągłej integracji zostają wdrożone do środowiska produkcyjnego, bez konieczności udziału czło- wieka. Kontenery mają ogromną zaletę w zakresie wdrażania zmian w środowisku produkcyj- nym. Obraz kontenera staje się obiektem niemodyfikowalnym, który poprzez środowiska pro- gramistyczne i robocze można promować do środowiska produkcyjnego. Przykładowo jednym z poważnych problemów, z którymi zawsze się stykamy, jest zapewnienie spójnych środowisk. Niemal każdy napotkał sytuację, w której zasób Deployment działał w środowisku roboczym, a przestał działać po jego przekazaniu do środowiska produkcyjnego. Tak się dzieje na skutek tzw. przesunięcia w konfiguracji, gdy biblioteki i wersjonowane komponenty różnią się w po- szczególnych środowiskach. Kubernetes zapewnia deklaracyjny sposób opisywania obiektów Deployments, które mogą być wersjonowane i wdrażane w spójny sposób. Trzeba pamiętać o tym, by najpierw zadbać o zachowanie spójnej konfiguracji procesu ciągłej integracji, a dopiero później zająć się nieustannym wdrażaniem. Jeżeli nie masz przygotowanego niezawodnego zestawu testów wychwytującego błędy na wstępnym etapie procesu, skutkiem może być przekazanie niepoprawnego kodu do wszystkich środowisk. Strategie wdrażania Skoro poznałeś podstawowe reguły nieustannego wdrażania, warto się zapoznać z różnymi stra- tegiami, które są możliwe do zastosowania. Kubernetes oferuje wiele strategii przeznaczonych do wydawania nowych wersji aplikacji. Nawet jeśli masz wbudowany mechanizm przeznaczony do dostarczania uaktualnień, zawsze możesz skorzystać z nieco bardziej zaawansowanych strategii. W tym podrozdziale będą przeanalizowane następujące strategie związane z dostarczaniem uaktualnień aplikacji:  dostarczanie uaktualnień,  wdrożenie typu niebieski-zielony,  wdrożenie kanarkowe. Mechanizm dostarczania uaktualnień jest wbudowany w Kubernetes i pozwala na przeprowa- dzenie aktualizacji uruchomionej aplikacji bez jej zatrzymywania i przestoju. Przykładowo, jeśli masz uruchomioną aplikację frontendu w wersji 1 i uaktualnisz ją do wersji 2, wówczas Kubernetes przeprowadzi aktualizację tej aplikacji w replikach, jak pokazaliśmy na rysunku 5.1. Strategie wdrażania  85 Poleć książkęKup książkę Rysunek 5.1. Uaktualnienia nieustanne w Kubernetes Obiekt Deployment pozwala na skonfigurowanie maksymalnej liczby uaktualnianych replik i mak- symalnej liczby podów niedostępnych podczas aktualizacji. Spójrz na przedstawiony tutaj mani- fest, który pokazuje, jak można zdefiniować strategię uaktualnień nieustannych. kind: Deployment apiVersion: v1 metadata: name: frontend spec: replicas: 3 template: spec: containers: - name: frontend image: brendanburns/frontend:v1 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 # Maksymalna liczba jednocześnie uaktualnianych replik. maxUnavailable: 1 # Maksymalna liczba replik niedostępnych podczas uaktualnienia. Należy zachować ostrożność podczas uaktualnień nieustannych, ponieważ ta strategia może spo- wodować odrzucanie połączeń. Aby sobie z tym poradzić, można wykorzystać tzw. próbkowanie odczytu (ang. readiness probe) i zaczepy cyklu życiowego preStop. Próbkowanie odczytu ma na celu sprawdzenie, czy nowo wdrożona wersja aplikacji jest gotowa do przyjmowania ruchu sie- ciowego. Zaczep preStop może zaś zagwarantować, że połączenia zostały zamknięte w nowo wdrożonej aplikacji. Ten zaczep cyklu życiowego jest wywoływany przed zakończeniem działania kontenera i jest asynchroniczny, więc musi się zakończyć przed wysłaniem ostatecznego sygnału zakończenia pracy kontenera. Spójrz na przykład przedstawiający zastosowanie próbkowania odczytu i zaczepu cyklu życiowego. 86  Rozdział 5. Ciągła integracja, testowanie i ciągłe wdrażanie Poleć książkęKup książkę kind: Deployment apiVersion: v1 metadata: name: frontend spec: replicas: 3 template: spec: containers: - name: frontend image: brendanburns/frontend:v1 livenessProbe: # ... readinessProbe: httpGet: path: /readiness # Punkt końcowy próbkowania. port: 8888 lifecycle: preStop: exec: command: [ /usr/sbin/nginx , -s , quit ] strategy: # ... W omawianym przykładzie zaczep preStop cyklu życiowego spowoduje eleganckie zakończenie procesu NGINX, podczas gdy sygnał SIGTERM spowodowałby zakończenie szybkie i nieeleganckie. Inną kwestią związaną z uaktualnieniami nieustannymi jest posiadanie dwóch wersji aplikacji działających jednocześnie podczas aktualizacji. Schemat bazy danych musi obsługiwać obie wer- sje aplikacji. Można również użyć strategii opcji właściwości, w której to schemat wskazuje nowe kolumny, utworzone przez nową wersję aplikacji. Po przeprowadzeniu uaktualnienia nieustanne- go stare kolumny mogą zostać usunięte. W manifeście wdrożenia zostało zdefiniowane próbkowanie odczytu i dostępności. Próbkowanie odczytu ma zagwarantować, że aplikacja jest gotowa do obsługi ruchu sieciowego, zanim zacznie działać w charakterze usługi dla punktu końcowego. Z kolei próbkowanie dostępności ma zagwa- rantować, że aplikacja działa poprawnie i że pod zostanie ponownie uruchomiony, jeśli próbko- wanie zakończy się niepowodzeniem. Kubernetes potrafi automatycznie ponownie uruchomić niedziałającego poda tylko wtedy, gdy zostanie on zamknięty na skutek błędu. Przykładowo prób- kowanie dostępności może sprawdzać punkt końcowy i ponownie go uruchomić po wykryciu za- kleszczenia, z którego pod nie zdołał się wydostać. Wdrożenie typu niebieski-zielony pozwala na wydawanie aplikacji w przewidywalny sposób. Dzię- ki wdrożeniu tego typu zachowujesz kontrolę nad przeniesieniem ruchu sieciowego do nowego środowiska, co oznacza większą kontrolę nad wydawaniem nowych wersji aplikacji. W przypadku wdrożenia typu niebieski-zielony musisz mieć do dyspozycji wystarczająco dużą pojemność, aby mogły jednocześnie być wdrożone środowiska istniejące i nowe. Taki rodzaj wdrożenia ma wiele zalet, takich jak łatwość cofnięcia do poprzedniej wersji aplikacji. Strategie wdrażania  87 Poleć książkęKup książkę Stosując tę strategię wdrożenia, trzeba uwzględnić pewne kwestie:  Migracja bazy danych może być trudna, ponieważ trzeba wziąć pod uwagę realizowane trans- akcje i zgodność uaktualnienia schematu.  Istnieje niebezpieczeństwo usunięcia obu środowisk.  Trzeba zapewnić pojemność wystarczającą dla obu środowisk.  Możliwe są problemy związane z koordynacją wdrożeń hybrydowych, po których starsze aplikacje nie będą w stanie obsłużyć danego wdrożenia. Wizualne przedstawienie wdrożenia typu niebieski-zielony pokazaliśmy na rysunku 5.2. Rysunek 5.2. Wdrożenie typu niebieski-zielony Wdrożenie kanarkowe jest bardzo podobne do wdrożenia typu niebieski-zielony, choć zapewnia większą kontrolę nad przesunięciem ruchu sieciowego do nowego wydania. Większość nowych implementacji usługi umożliwia przekierowanie pewnej, wyrażonej w procentach, ilości ruchu sieciowego do nowego wydania. Ponadto istnieje możliwość implementacji technologii Service Mesh — np. Istio, Linkerd lub HashiCorp Consul — która udostępnia pewną liczbę funkcjonal- ności pomagających w przygotowaniu takiej strategii wdrożenia. Wdrożenie kanarkowe pozwala przetestować nowe funkcjonalności tylko na podzbiorze użyt- kowników. Przykładowo można wydać nową wersję aplikacji i przetestować ją jedynie dla 10 bazy użytkowników. Dzięki temu na niebezpieczeństwa związane z wprowadzeniem niepopraw- nego wdrożenia lub niedziałających funkcjonalności będzie narażona znacznie mniejsza grupa użytkowników. Jeżeli we wdrożeniu lub w nowych funkcjonalnościach nie ma błędów, można za- cząć przekierowywać do nowej wersji aplikacji coraz większy odsetek użytkowników. Istnieją również o wiele bardziej zaawansowane technologie przeznaczone do stosowania wraz z wdroże- niami kanarkowymi. Przykładowo aplikacja może zostać wydana dla użytkowników pochodzą- cych z określonego regionu lub jedynie dla użytkowników o konkretnym profilu. Takie rodzaje wydań zwykle są określane jako A/B lub ciemne, ponieważ użytkownicy są nieświadomi tego, że testują nową funkcjonalność wdrożenia. 88  Rozdział 5. Ciągła integracja, testowanie i ciągłe wdrażanie Poleć książkęKup książkę W przypadku wdrożenia kanarkowego trzeba wziąć pod uwagę pewne kwestie pojawiające się we wcześniej omówionym wdrożeniu typu niebieski-zielony, a także kilka nowych:  Możliwość przesunięcia ruchu sieciowego do wyrażonej w procentach grupy użytkowników.  Solidna wiedza pozwalająca na porównanie istniejącej wersji aplikacji z nową.  Wskaźniki pozwalające na określenie, czy stan nowego wydania jest „dobry” czy też „zły”. Wizualne przedstawienie wdrożenia kanarkowego pokazaliśmy na rysunku 5.3. Rysunek 5.3. Wdrożenie kanarkowe Wdrożenie kanarkowe jest utrudnione w przypadku wielu uruchomionych jedno- cześnie wersji aplikacji. Schemat bazy danych musi mieć możliwość obsługi obu wersji aplikacji. Gdy stosujesz tę strategię, naprawdę musisz skoncentrować się na sposobie obsługi usług zależnych i na jednoczesnym działaniu wielu wersji. Dlatego trzeba mieć silne API i zagwarantować, że usługi danych obsługujące wiele wersji aplikacji zostaną wdrożone w tym samym czasie. Testowanie w produkcji Testowanie w produkcji pomaga się upewnić, że aplikacja jest niezawodna, skalowana i charakte- ryzuje się dobrym UX. Trzeba w tym miejscu dodać, że testowanie w produkcji wiąże się z pew- nymi wyzwaniami i ryzykiem, choć warto ponieść ten wysiłek, aby zagwarantować niezawodność systemów. Istnieją pewne ważne aspekty, które trzeba wziąć pod uwagę podczas przygotowywa- nia takiej implementacji. Przede wszystkim należy się upewnić, że istnieje strategia pozwalająca na dogłębną obserwację, co pozwoli sprawdzić efekty testowania w produkcji. Bez możliwości ob- serwacji wskaźników wpływających na wrażenia użytkowników końcowych aplikacji nie będziesz miał jasno określonego celu, na którym trzeba się skoncentrować podczas próby poprawienia od- porności programu na awarie. Dobrze jest zastosować również wysoki stopień automatyzacji i umożliwić automatyczną naprawę po awarii w systemach. Testowanie w produkcji  89 Poleć książkęKup książkę Do dyspozycji masz wiele narzędzi, które trzeba będzie zaimplementować w celu zmniejszenia niebezpieczeństwa i efektywnego przetestowania systemów w produkcji. O części narzędzi już wspomnieliśmy w rozdziale; są też inne, m.in. służące do monitorowania rozproszonego, instru- mentacji, inżynierii chaosu (ang. chaos engineering) i przesłaniania ruchu sieciowego (ang. traffic shadowing). Dla przypomnienia przedstawiamy listę narzędzi, które zostały już wspomniane w rozdziale:  wdrożenie kanarkowe,  testowanie A/B,  przesunięcie ruchu sieciowego,  opcje właściwości. Inżynieria chaosu została opracowana przez firmę Netflix. Polega na wdrażaniu eksperymentów w działających systemach produkcyjnych i ma na celu odkrycie ich słabych stron. Inżynieria cha- osu pozwala poznać sposób, w jaki system się zachowuje, przez jego obserwację podczas kontro- lowanego eksperymentu. Zapoznaj się z wymienionymi tutaj krokami, które trzeba wykonać przed przystąpieniem do eksperymentów. 1. Opracowanie hipotezy i poznanie aktualnego stanu systemu. 2. Przygotowanie rzeczywistych zdarzeń, które mogą wpływać na system. 3. Utworzenie grupy kontrolnej i eksperymentowanie w celu porównania stanu. 4. Przeprowadzenie eksperymentów w celu sformułowania hipotezy. Ogromne znaczenie ma to, aby podczas przeprowadzania eksperymentów zminimalizować „pole rażenia” i zagwarantować, że ewentualne problemy będą naprawdę minimalne. Chcesz mieć pewność, że gdy zaczniesz przeprowadzać eksperymenty, skoncentrujesz się na ich automatyzacji, ponieważ ich wykonywanie może być pracochłonne. Jednak w tym miejscu być może zaczniesz zadawać sobie pytanie: „Dlaczego nie mogę po prostu wykonać testu w środowisku roboczym?”. Przekonaliśmy się, że testowanie w środowisku roboczym wiąże się z pewnymi nieuchronnymi problemami. Są to:  nieidentyczne zasoby wdrożenia,  przesunięcie konfiguracji względem tej stosowanej w produkcji,  nienaturalna symulacja ruchu sieciowego i sposobu zachowania użytkownika,  liczba generowanych żądań nie odzwierciedla rzeczywistego obciążenia,  brak monitorowania zaimplementowanego w środowisku roboczym,  wdrożone usługi danych zawierają inne dane i wiążą się z innym obciążeniem niż w środowi- sku produkcyjnym. Nie sposób podkreślić tego wystarczająco mocno, ale upewnij się o zastosowaniu w środowisku produkcyjnym solidnego rozwiązania w zakresie monitorowania, ponieważ użytkownicy, którzy nie mają odpowiednich możliwości obserwowania systemów produkcyjnych, są skazani na nie- powodzenie. Ponadto rozpocznij od niewielkich eksperymentów, by zwiększyć zaufanie do śro- dowiska produkcyjnego. 90  Rozdział 5. Ciągła integracja, testowanie i ciągłe wdrażanie Poleć książkęKup książkę Stosowanie inżynierii chaosu i przygotowania Pierwszym krokiem w omawianym procesie jest utworzenie rozwidlenia repozytorium GitHub. Dzięki temu będziesz mieć własne repozytorium przeznaczone do użycia w rozdziale. Konieczne będzie użycie interfejsu GitHub pozwalającego na rozwidlenie repozytorium (https://github.com/dstrebel/kbp). Konfiguracja ciągłej integracji Skoro poznałeś technikę ciągłej integracji, zajmiesz się kompilacją kodu, który sklonowaliśmy poprzednio. Na potrzeby omawianego przykładu wykorzystamy serwis https://drone.io/. Będziesz musiał się zarejestrować (https://cloud.drone.io/) i utworzyć bezpłatne konto. Podczas logowania podaj dane uwierzytelniające z serwisu GitHub; w ten sposób zarejestrujesz swoje repozytoria w Drone i bę- dziesz mógł je synchronizować. Po zalogowaniu się do Drone wybierz opcję Active dla rozwidlenia repozytorium. Pierwszym zadaniem, które prawdopodobnie będziesz musiał wykonać, jest doda- nie do konfiguracji pewnych danych poufnych. To pozwoli na przekazanie aplikacji do rejestru Docker Hub i wdrożenie jej do klastra Kubernetes. W ramach repozytorium w Drone kliknij Settings i dodaj następujące dane poufne (zobacz ry- sunek 5.4).  docker_username,  docker_password,  kubernetes_server,  kubernetes_cert,  kubernetes_token. Nazwa użytkownika i hasło w serwisie Docker będą tymi wartościami, których użyłeś podczas rejestrowania konta w Docker Hub. W kolejnych krokach zobaczysz, jak przebiega utworzenie konta usługi Kubernetes, certyfikacja i pobranie tokena. W przypadku serwera Kubernetes potrzebujesz publicznie dostępnego punktu końcowego API Kubernetes. Do wykonania kroków omawianych w tej sekcji konieczne jest uprawnienie cluster-admin w klastrze Kubernetes. W celu pobrania API punktu końcowego należy wydać następujące polecenie: $ kubectl cluster-info Powinieneś otrzymać komunikat informujący o działaniu Kubernetes pod adresem takim jak https://kbp.centralus.azmk8s.io:443. Ta wartość będzie przechowywana w postaci danych pouf- nych kubernetes_server. Stosowanie inżynierii chaosu i przygotowania  91 Poleć książkęKup książkę Rysunek 5.4. Konfiguracja danych poufnych w Drone Przechodzimy teraz do utworzenia konta usługi, które będzie używane przez Drone podczas na- wiązywania połączenia z klastrem. Skorzystaj z przedstawionego tutaj polecenia, które tworzy serviceaccount. $ kubectl create serviceaccount drone Następne polecenie tworzy clusterrolebinding dla serviceaccount: $ kubectl create clusterrolebinding drone-admin \ --clusterrole=cluster-admin \ --serviceaccount=default:drone Kolejnym krokiem jest pobranie tokena dla serviceaccount: $ TOKENNAME=`kubectl -n default get serviceaccount/drone -o jsonpath= {.secrets[0].name} ` $ TOKEN=`kubectl -n default get secret $TOKENNAME -o jsonpath= {.data.token} | base64 -d` $ echo $TOKEN Wygenerowane dane wyjściowe w postaci tokena należy przechowywać jako dane poufne kubernetes_token. Potrzebny jest również certyfikat użytkownika w celu uwierzytelnienia w klastrze. Skorzystaj więc z przedstawionego tutaj polecenia i wklej zawartość ca.crt do danych poufnych kubernetes_cert. $ kubectl get secret $TOKENNAME -o yaml | grep ca.crt: Teraz utwórz rozwiązanie Drone, a następnie przekaż aplikację do rejestru Docker Hub. 92  Rozdział 5. Ciągła integracja, testowanie i ciągłe wdrażanie Poleć książkęKup książkę Pierwszym krokiem jest etap kompilacji, w trakcie którego powstanie frontend opracowany w Node.js. Drone wykorzystuje obrazy kontenera do wykonywania swoich zadań, co zapewnia ogromną elastyczność w zakresie dostępnych możliwości. Na etapie kompilacji skorzystaj z obrazu Node.js pochodzącego z rejestru Docker Hub: pipeline: build: image: node commands: - cd frontend - npm i redis --save Po zakończeniu kompilacji należy ją przetestować, co odbędzie się na etapie testowania. Polega on na wydaniu polecenia npm względem nowo utworzonej aplikacji. test: image: node commands: - cd frontend - npm i redis --save - np Gdy kompilacja i testowanie aplikacji zakończą się sukcesem, będzie można przejść do następnego kroku, którym jest etap publikowania. W tym kroku następuje utworzenie obrazu Dockera apli- kacji i jego przekazanie do rejestru Docker Hub. W pliku .drone.yml wprowadź poniższą zmianę w kodzie: repo: twój-rejestr /frontend publish: image: plugins/docker dockerfile: ./frontend/Dockerfile context: ./frontend repo: dstrebel/frontend tags: [latest, v2] secrets: [ docker_username, docker_password ] Po zakończeniu operacji tworzenia obrazu Dockera można go przekazać do rejestru Dockera. Konfiguracja ciągłego wdrażania Na etapie wdrożenia gotowa aplikacja zostanie przekazana do klastra Kubernetes. W trakcie tego procesu będzie wykorzystany manifest wdrożenia, który znajduje się w katalogu aplikacji fron- tendu w repozytorium. kubectl: image: dstrebel/drone-kubectl-helm secrets: [ kubernetes_server, kubernetes_cert, kubernetes_token ] kubectl: apply -f ./frontend/deployment.yaml Gdy operacja wdrożenia zostanie zakończona, będziesz mógł zobaczyć pody działające w klastrze. Wydanie następującego polecenia pozwoli się upewnić, że pody działają: $ kubectl get pods Stosowanie inżynierii chaosu i przygotowania  93 Poleć książkęKup książkę Istnieje możliwość dodania etapu testowania, w trakcie którego zostaną pobrane informacje o stanie wdrożenia. To jest możliwe po dodaniu w definicji rozwiązania Drone następującego kodu: test-deployment: image: dstrebel/drone-kubectl-helm secrets: [ kubernetes_server, kubernetes_cert, kubernetes_token ] kubectl: get deployment frontend Przeprowadzanie operacji uaktualnienia Teraz pokażemy, jak przeprowadzić uaktualnienie przez wprowadzenie jednej zmiany w kodzie frontendu. W pliku server.js dodaj przedstawiony poniżej wiersz kodu, a następnie przekaż zmiany do repozytorium. console.log( Serwer API został uruchomiony. ); Gdy to zrobisz, powinieneś zobaczyć, jak przebiega wdrażanie i uaktualnianie oprogramowania w ist- niejących podach. Po zakończeniu operacji uaktualnienia nowa wersja aplikacji będzie wdrożona. Prosty eksperyment z inżynierią chaosu W ekosystemie Kubernetes mamy wiele narzędzi pomagających w przeprowadzaniu w wybranym środowisku eksperymentów związanych z inżynierią chaosu. Gama tych narzędzi jest naprawdę ogrom- na, od rozwiązań typu „Chaos as a Service” po proste narzędzia do eksperymentów, które doprowadzą do zakończenia działania podów w środowisku. W tym miejscu zdecydowaliśmy się na przedstawienie wybranych narzędzi, o których wiemy, że są z powodzeniem stosowane przez użytkowników. Gremlin To hostingowana usługa zapewniająca zaawansowane funkcje do przeprowadzania ekspery- mentów związanych z inżynierią chaosu. PowerfulSeal To projekt typu open source oferujący zaawansowane scenariusze inżynierii chaosu. Chaos Toolkit To projekt typu open source, którego zadaniem jest zapewnienie bezpłatnego, otwartego i rozwijanego przez społeczność zestawu narzędzi oraz API dla różnych postaci narzędzi z zakresu inżynierii chaosu. KubeMonkey To narzędzie typu open source oferujące podstawowe możliwości testowania odporności podów w klastrze. Przeprowadzimy teraz szybki eksperyment pozwalający przetestować odporność aplikacji na awarie. W trakcie eksperymentu działanie podów zostanie zakończone. Do przeprowadzenia eksperymentu użyjemy narzędzia Chaos Toolkit. $ pip install -U chaostoolkit $ pip install chaostoolkit-kubernetes $ export FRONTEND_URL= http://$(kubectl get svc frontend -o jsonpath= {.status.loadBalancer.ingress[*].ip} ):8080/api/ $ chaos run experiment.json 94  Rozdział 5. Ciągła integracja, testowanie i ciągłe wdrażanie Poleć książkęKup książkę Najlepsze praktyki dotyczące technik ciągłej integracji i ciągłego wdrażania Przygotowane rozwiązanie w zakresie ciągłej integracji i ciągłego wdrażania nie będzie od razu doskonałe. Dlatego też warto rozważyć zastosowanie wybranych praktyk z poniższej listy, aby iteracyjnie usprawniać to rozwiązanie.  W przypadku technik ciągłej integracji należy skoncentrować się na automatyzacji i szybkiej kompilacji. Optymalizacja wydajności działania kompilacji zapewni programistom szyb- kie informacje o tym, czy wprowadzone przez nich zmiany nie doprowadziły do uszko- dzenia aplikacji.  Skoncentruj się na dostarczeniu w rozwiązaniu niezawodnych testów. Dzięki nim programi- ści będą szybko otrzymywali informacje o potencjalnych problemach w kodzie. Im szybciej takie informacje dotrą do programistów, tym większą osiągną oni produktywność w pracy.  Podczas wybierania narzędzi z zakresu ciągłej integracji i ciągłego wdrażania upewnij się, że te narzędzia pozwolą zdefiniować rozwiązanie w postaci kodu. To umożliwi umieszczenie kodu rozwiązania w systemie kontroli wersji.  Upewnij się co do optymalizacji obrazów. To pozwoli zmniejszyć wielkość obrazu, a tym sa- mym płaszczyznę ataku po wdrożeniu danego obrazu do środowiska produkcyjnego. Wielo- etapowa kompilacja w Dockerze umożliwia usunięcie pakietów niepotrzebnych do działania aplikacji. Przykładowo pakiet Maven może być potrzebny do skompilowania aplikacji, ale nie jest niezbędny do rzeczywistego uruchomienia obrazu.  Unikaj używania słowa latest w tagu obrazu kontenera. Zamiast tego skorzystaj z tagu od- wołującego się do identyfikatora kompilacji lub identyfikatora zatwierdzenia kodu w repo- zytorium Git.  Jeżeli dopiero zaczynasz korzystanie z technik ciągłego wdrażania, użyj oferowanych przez Kubernetes możliwości w zakresie dostarczania uaktualnień. Rozpoczęcie pracy z nimi jest bardzo łatwe, podobnie jak ich zastosowanie we wdrożeniach. Gdy nabędziesz większej wprawy i większej pewności siebie w pracy z technikami ciągłego wdrażania, zainteresuj się strate- giami wdrażania kanarkowego i typu niebieski-zielony.  W trakcie stosowania technik ciągłego wdrażania upewnij się, że przetestowałeś, jak uaktual- nienia połączeń klienta i schematu bazy danych są obsługiwane przez aplikację.  Testowanie w produkcji pomoże w zagwarantowaniu niezawodności działania aplikacji. Upewnij się również, że dysponujesz dobrym rozwiązaniem w zakresie monitorowania. Testując w produkcji, rozpocznij od operacji na mniejszą skalę i postaraj się ograniczyć pole rażenia eksperymentu. Najlepsze praktyki dotyczące technik ciągłej integracji i ciągłego wdrażania  95 Poleć książkęKup książkę Podsumowanie W rozdziale zostały omówione strategie związane z utworzeniem rozwiązania z zakresu ciągłej integracji i ciągłego wdrażania dla aplikacji. Dzięki takiemu rozwiązaniu można zapewnić nieza- wodny proces dostarczania oprogramowania. Stosowanie technik ciągłej integracji i ciągłego wdrażania pozwala ograniczyć ryzyko i zarazem zwiększyć częstotliwość dostarczania aplikacji do Kubernetes. Przedstawiliśmy także różne strategie wdrażania, które można stosować podczas dostarczania aplikacji. 96  Rozdział 5. Ciągła integracja, testowanie i ciągłe wdrażanie Poleć książkęKup książkę
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Najlepsze praktyki w Kubernetes. Jak budować udane aplikacje
Autor:
, , ,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: