Читать книгу Mikroserwisy w akcji - Группа авторов - Страница 17

Rozwój i działanie muszą być ściśle powiązane przy budowaniu mikroserwisów. Jeśli coś zbudujemy i przekażemy, to nie powinniśmy przekazywać tego komuś innemu, aby to wdrożył i obsługiwał. W systemie złożonym z wielu autonomicznych usług, jeśli go zbudujemy, musimy go także uruchomić. Zrozumienie, w jaki sposób nasze usługi będą działać, pomoże nam w podejmowaniu lepszych decyzji dotyczących projektu, gdy nasz system będzie się rozwijał.

Pamiętajmy, że to, co wyróżnia naszą aplikację, ma wpływ na biznes. Wynika to ze współpracy między wieloma usługami. W rzeczywistości wszystko można ujednolicić lub uprościć – oprócz unikalnej zdolności oferowanej przez daną usługę – co spowoduje, że zespoły będą skoncentrowane na wartości biznesowej. Ostatecznie powininniśmy osiągnąć etap, w którym nie będzie specjalnej ceremonii związanej z wdrażaniem nowej usługi. Bez tego zmarnujemy całą naszą energię, zamiast stworzyć wartość dla klientów.

W tej książce pokażemy, jak stworzyć właściwą drogę do wdrażania istniejących i nowych usług. Koszt wdrożenia nowych usług musi być nieistotny, aby umożliwić szybkie wprowadzanie innowacji. Proces należy także ujednolicić, aby uprościć działanie systemu i zapewnić spójność między usługami. Aby to osiągnąć, musimy:

■ zestandaryzować artefakty wdrażania usług,

■ zaimplementować strumienie ciągłego wdrażania.

Słyszeliśmy, że niezawodne wdrażanie jest traktowane jako nudne, ale nie o to chodzi, że nie jest ekscytujące, tylko że pozbawione jest incydentów. Niestety, widzieliśmy zbyt wiele zespołów, w których jest odwrotnie – wdrażanie oprogramowania jest stresujące i zachęca do niezdrowych zachowań typu „wszystkie ręce na pokład”. Jest to wystarczająco szkodliwe dla pojedynczej usługi – jeśli wdrażamy większą liczbę usług, sam lęk doprowadzi nas do szaleństwa! Przyjrzyjmy się, jak te kroki prowadzą do stabilnych i niezawodnych wdrożeń mikroserwisów.

STANDARYZACJA ARTEFAKTÓW WDRAŻANIA USŁUG

Często wydaje się, że każdy język i środowisko ma własne narzędzie do wdrażania. Python ma Fabric, Ruby ma Capistrano, Elixir ma exrm itd. Samo środowisko wdrożeniowe również jest złożone:

■ Na jakim serwerze działa aplikacja?

■ Jakie są zależności aplikacji od innych narzędzi?

■ Jak uruchomić tę aplikację?

W środowisku wykonawczym zależności aplikacji (rys. 1.9) są silne i mogą obejmować biblioteki, pliki binarne i pakiety systemu operacyjnego (takie jak ImageMagick lub libc) oraz procesy systemu operacyjnego (takie jak cron lub fluentd).

Technicznie, heterogeniczność jest fantastyczną korzyścią z autonomii usług. Ale nie ułatwia to wdrożenia. Bez unikania konsekwencji nie można zestandaryzować podejścia do wdrażania usług do produkcji, co zwiększa koszty zarządzania wdrożeniami i wprowadzania nowych technologii. W najgorszym przypadku każdy zespół ponownie musi wymyślić koło, tworząc różne podejścia do zarządzania zależnościami, budowania pakietów, umieszczania ich na serwerach i obsługi samej aplikacji.

Nasze doświadczenie sugeruje, że najlepszym narzędziem do tego zadania są kontenery. Kontener to metoda wirtualizacji na poziomie systemu operacyjnego, która obsługuje uruchamianie izolowanych systemów na hoście, z których każdy ma własną sieć i przestrzeń dla procesów, współdzieląc to samo jądro. Kontener jest szybszy do zbudowania i szybszy do uruchomienia niż maszyna wirtualna (trwa to sekundy, a nie minuty). Można uruchomić wiele kontenerów na jednym komputerze, co upraszcza rozwój i może pomóc w optymalizacji wykorzystania zasobów w środowiskach chmurowych.

Rysunek 1.9. Aplikacja udostępnia interfejs API i ma wiele rodzajów zależności, w tym bibliotek, zależności binarnych i procesów wspierających

Kontenery standaryzują tworzenie pakietów aplikacji oraz interfejs środowiska wykonawczego i zapewniają niezmienność zarówno środowiska operacyjnego, jak i kodu. To sprawia, że są potężnymi cegiełkami do budowania na wyższym poziomie. Korzystając z nich, można zdefiniować i wyodrębnić pełne środowisko wykonawcze dowolnej usługi.

Mimo że dostępnych jest wiele implementacji kontenerów (a koncepcja ta istnieje także poza Linuksem, jak np. jails w FreeBSD czy zones w systemie Solaris), to najbardziej dojrzałym i przystępnym narzędziem, spośród tych, których używaliśmy do tej pory, jest Docker. Użyjemy go w dalszej części tej książki.

IMPLEMENTACJA STRUMIENI CIĄGŁEGO DOSTARCZANIA

Ciągłe dostarczanie to praktyka, w której programiści tworzą oprogramowanie, jakie mogą niezawodnie dostarczać do produkcji w dowolnym momencie. Wyobraźmy sobie linię produkcyjną w fabryce – aby nieprzerwanie dostarczać oprogramowanie, budujemy podobny strumień, pobierający zatwierdzony kod i wdrażający go do produkcji. Na rysunku 1.10 pokazano prosty strumień. Każdy etap strumienia dostarcza zespołowi programistycznemu informacje zwrotne na temat poprawności kodu.

Wcześniej wspomnieliśmy, że mikroserwisy są idealnym narzędziem do ciągłego dostarczania, ponieważ ich mały rozmiar oznacza, że można je szybko budować i wydawać niezależnie. Jednak ciągłe dostarczanie nie wynika automatycznie z tworzenia mikroserwisów. Aby zapewnić ciągłe dostarczanie oprogramowania, musimy skupić się na dwóch celach:

■ budowanie zbioru walidacji, które musi przejść nasze oprogramowanie; na każdym etapie procesu wdrażania powinniśmy móc udowodnić poprawność naszego kodu;

■ automatyzacja strumienia dostarczającego kod od momentu zatwierdzenia (commit) do produkcji.

Zbudowanie sprawdzonego, poprawnego strumienia wdrażania pozwoli programistom pracować bezpiecznie oraz w tempie, w jakim będą mogli iteracyjnie rozwijać usługi. Taki strumień jest powtarzalnym i niezawodnym procesem dostarczania nowych funkcjonalności. W idealnej sytuacji powinniśmy móc zestandaryzować walidacje i kroki w strumieniu i używać ich dla wielu usług, bardziej znacząco zmniejszając koszt wdrażania nowych usług.

Ciągłe dostarczanie zmniejsza również ryzyko związane z wdrażaniem oprogramowania, ponieważ zarówno jakość tworzonego oprogramowania, jak i sprawność zespołu w zakresie dostarczania zmian są większe. Z perspektywy produktu może to oznaczać, że możemy pracować w prostszy sposób – szybko sprawdzając własne założenia i je powtarzając.

Rysunek 1.10. Wysokopoziomowy strumień wdrażania dla mikroserwisu

UWAGA  W części 3 zbudujemy strumień ciągłego wdrażania za pomocą funkcjonalności Pipeline dostępnego bezpłatnie narzędzia integracyjnego Jenkins; przeanalizujemy także różne wzorce wdrażania, takie jak kanarkowe i niebieskozielone.