Automatyzacja - Zarządzanie zmianami bez pomyłek
Podziel się

Automatyzacja to nie tylko ujednolicenie konfiguracji i zautomatyzowanie procesów wdrażania systemów i aplikacji. Zastosowanie oprogramowania CM pozwala na rozwinięcie technik, które mogą być również nieocenione w przypadku testowania nowych rozwiązań czy projektowania architektury przyszłych platform. Częstym problemem w trakcie procesu wybierania odpowiedniej dla projektu architektury jest czasochłonność samego testowania; brak kompetencji dotyczących budowy danego rozwiązania, nie pozwalające na jego szybkie wdrożenie i rozwiązywanie problemów, które pojawią się w czasie instalacji; wreszcie brak dedykowanej do testów infrastruktury. To potrafi zniechęcić, pozwolić na wybór rozwiązania, do którego być może nie mamy pełnego zaufania, czy po prostu kierując się opiniami innych klientów, czy dostawców. Tymczasem:

Einstein

Błędu nigdy nie popełnił tylko ten, który nie próbował niczego nowego

Nie jest tajemnicą, że proces budowy i rozwoju platformy, to ciągłe zmaganie się z występującymi problemami (konfiguracyjnymi, implementacyjnymi, wydajnościowymi i innymi), zatem całkowite uniknięcie błędów nie będzie w większości przypadków możliwe. Co więcej, jeśli nie popełnimy tych błędów w czasie budowy, tym większym problemem będzie ich wystąpienie – po raz pierwszy – już w środowisku produkcyjnym. Czasem oznaczać to będzie konieczność rozwiązania problemu pod presją czasu lub kosztem niedostępności, czasem może znaczyć wręcz konieczność przeprojektowania systemu zupełnie od nowa. Sensownie będzie zatem założyć, iż nasz proces budowania architektury, będzie wychodził naprzeciw problemom, jakie możemy napotkać, tak, abyśmy nie musieli – ze względu na brak czasu, czy koszta – rezygnować z kompletności naszych testów i możliwości wzięcia pod uwagę wszystkich dostępnych w danej dziedzinie rozwiązań.

Oto kilka cech, które powinno mieć nasze środowisko R&D zoptymalizowane pod szybkie cykle testowe:

  • Dokumentacja projektowa, to system (często bazujący na wiki), który pozwoli nam stworzyć oraz na bieżąco utrzymywać podstawowe informacje nt. projektowanej platformy. Oprócz celów implementacyjnych, pozwoli ona nam na bieżąco dookreślić wymagania oraz powiązania pomiędzy systemami, a więc zwiększyć świadomość i widoczność zakresu projektu w zespole. Powszechnie jej istnienie przyczynia się do wyłapywania luk i błędów jeszcze na etapie projektowania. Dokumentacja nie musi być dodatkowym obciążeniem – jej zwięzłość i zrozumiałe opisanie tematu (np. 1-2 strony A4) są atutem. Jest nim również jej częsta aktualizacja i zawieraniu schematów i idei w formie graficznej.
  • Możliwość wycofania zmian (najczęściej związana z systemami kontroli wersji i snapshotowaniu systemów zwirtualizowanych) to nieoceniony mechanizm, który pozwala nam na niemal bezkarne popełnianie błędów. Głównym strachem przed wykonaniem zmian na etapie projektowania i testowania jest nakład pracy potrzebny do wycofania zmian i przywrócenia systemu do poprzedniego (dobrego) stanu. Dzięki działającym systemom przywracania możemy nawet celowo popełniać błędy i poddawać nasz system zbyt dużym obciążeniom, aby lepiej poznać jego słabe punkty. Popełnianie błędów przestaje być ślepym zaułkiem, a staje się piaskownicą (ang. sandbox), gdzie testuje się nowe idee.
  • Testy A-B, to technika, która pozwala nam na równoległe poddanie testom dwóch wariantów naszej platformy, aby zaobserwować, który z wariantów zachowa się lepiej (często z punktu widzenia wydajności, czasem też funkcjonalności). Aby móc je przeprowadzać, nasza platforma musi być budowana w pełni automatycznie, tak, żeby jej zwielokrotnianie nie wiązało się z dodatkowym nakładem czasowym. Nasz kod (aplikacji oraz IaC) musi też wspierać możliwość rozgałęziania w wąskim zakresie (feature branch), tak abyśmy mogli zaimplementować odpowiednie zmiany punktowo, zachowując pozostałą część kodu bez zmian.
  • Monitoring oraz metryki to nieoceniony element pozwalający nam zwizualizować zachowanie środowiska. Dzięki przejrzystym wykresom oraz funkcjom pozwalającym nakładać na siebie dane z dwóch różnych przebiegów testów łatwo możemy porównać zachowanie naszego systemu. Co powinniśmy monitorować? Co tylko możemy – aplikacje mogą implementować udostępnianie metryk przez prosty interfejs REST, a dzięki obecności danych historycznych możemy przejrzeć i wychwycić drobne zmiany, których wpływu bez dostępu do wykresów nigdy byśmy nie podejrzewali. Warto wyrobić sobie nawyk systematycznego zerkania na dashboardy systemu monitoringu, dzięki któremu bardzo szybko zdiagnozujemy potencjalne problemy.
  • Kod wielokrotnego użytku jest ważny z dwóch powodów. Po pierwsze, stosując systemy wiodące na rynku spotkamy się z wieloma rozwiązaniami, które już wcześniej zostały wdrożone i zautomatyzowane. To pozwoli nam na znaczną oszczędność kosztów i badanie wielu alternatyw jednocześnie. Gotowe moduły pozwolą nam na instalację i uruchomienie środowiska testowego często bez konieczności sięgania po dokumentację (inną niż dokumentacja samego modułu automatyzacji czy wdrażania/budowania). Po drugie, wiele komponentów będzie się powtarzać pomiędzy wdrożeniami. Jeśli będziemy dysponować ich znaną i wcześniej przetestowaną konfiguracją (wariantem), to każde kolejne wdrożenie będzie nas kosztować coraz mniej, a późniejsze zmiany (np. związane z zabezpieczeniami) będą mogły być wdrażane globalnie.
  • Możliwość odwzorowania docelowego środowiska będzie nieoceniona w przypadku rozbudowanych sieciowo platform (np. mikroserwisy, infrastruktura warstwowa, klastry). Nowoczesne środowiska sieciowe pozwalają nam zasymulować wiele warstw sieci i zdefiniować określone (ograniczone) kryteria ruchu sieciowego.
  • Możliwość elastycznej modyfikacji konfiguracji (ang. customizability) to cecha, która pozwala nam dopasować moduły konfiguracji oraz zachowanie aplikacji do konkretnych zastosowań. Konieczne będzie wdrożenie własnego CA (Certificate Authority)? Implementacja współdzielonego repozytorium danych (shared storage)? Zmiana parametrów konfiguracyjnych? Dobre rozwiązania pozwolą nam – przy zachowaniu i użyciu szablonów – zmodyfikować zachowanie danego komponentu do konkretnych potrzeb (w przypadku konfiguracji będą to parametry klas, w przypadku kontenerów, np. wolumeny lub zmienne środowiskowe).
  • Bezpieczeństwo (raport Forrester) to bez wątpienia wątek, który powinien nam towarzyszyć przez cały cykl SDLC (Software Development Life Cycle) i już na etapie projektowania. Badania wykazują, że im później zostaje wprowadzony do projektu czynnik związany z budowaniem zabezpieczeń (poufność, integralność, dostępność), tym większy opór w zespole i tym większy będzie koszt wdrożenia. Dobrze, jeśli nasz system będzie zaprojektowany w sposób opisywany “secure by default”, a więc zapewnione będą podstawowe zasady bezpieczeństwa (np. uprawnienia, hardening, czy usuwanie zbędnych możliwości systemu) od pierwszego dnia istnienia projektu. Przyczyni się to wydatnie do zmniejszenia “debetu technologicznego” i przyszłych kosztów naprawczych.

To dość rozbudowane wymagania, jednak adekwatne do tworzonych obecnie stosów technologicznych. Pamiętajmy o innym cytacie:

Einstein

Wszys­tko po­win­no być tak pros­te, jak to tyl­ko możli­we, ale nie pros­tsze.

Szczęśliwie, nie jesteśmy w problemie złożoności odosobnieni – to chleb powszedni działów deweloperskich i operacyjnych we wszystkich innowacyjnych firmach, gdzie trzonem działania są systemy informatyczne. Dlatego do dyspozycji mamy szereg narzędzi, łączących procesy zarządzania konfiguracją (jak Puppet), dostarczania i wdrażania aplikacji (Docker, rkt), ich skalowania oraz orkiestracji (UCP, origin, Rancher) i monitorowania (Prometeus, Splunk). To powszechnie używane narzędzia DevOps, a każde z nich odpowiada na wiele z przedstawionych powyżej potrzeb:

  • Projekt Blueshift to inicjatywa firmy Puppet (dawniej Puppet Labs) ułatwiająca testowanie nowych technologii. Dzięki niemu możemy testować warianty konfiguracji opartych na takich produktach, jak Docker, Kubernetes, Mesos, Consul, rkt, CoreOS bez żmudnej ręcznej konfiguracji. W większości przypadków wystarczy zainstalować odpowiednie moduły puppetowe (zależności zostaną pobrane automatycznie) i skonfigurować je w sposób standardowy. Potem zapoznajemy się ze zwięzłą dokumentacją modułów, która pozwala nam już na budowanie rozbudowanych środowisk. Wszystko to bez dedykowanego środowiska testowego (lub na nim), na laptopie (z Linux lub OSX).
  • Docker Hub oraz GitHub to odpowiedniki Facebooka (czy bardziej ogólnie – social media) dla programistów i operatorów. Miejsce, gdzie (w duchu opensource) programiści dzielą się swoimi pomysłami i gotowymi modułami oraz pozwalają społeczności na ich rozwój i klonowanie (forkowanie). To idealne miejsce, aby zainspirować się w budowie własnego rozwiązania, albo wręcz znaleźć moduły, które (po rozbudowaniu lub wręcz tylko ściągnięciu) będziemy mogli zaadoptować u siebie.
  • Zarówno Docker jak i rkt (Flannel) dysponują możliwością budowania dedykowanych sieci i połączeń pomiędzy kontenerami (aplikacjami). Pozwoli nam to zasymulować komunikację (lub wymusić izolację) podobnie jak będzie to wdrożone w środowisku produkcyjnym.
  • Puppet Style Guide gwarantuje, że wszystkie moduły zatwierdzone na Puppet Forge będą podlegać parametryzacji. Oznacza to, że używając gotowego kodu, nie tylko oszczędzamy czas, ale mamy też pewność, iż w przypadku konieczności modyfikacji konkretnego ustawienia nie będziemy mieć problemu ze zrobieniem tego na poziomie klasyfikacji naszych zasobów (bez potrzeby przepisywania i/lub modyfikacji kodu). System r10k pozwoli nam na sprawne testowanie wariantów konfiguracji za pomocą mechanizmu feature branch.
  • Systemy Docker i rkt bazując na linux cgroups umożliwiają nam przydzielenie limitów zasobów (pamięć, cpu, sieć, i/o) na poziomie kontenera (aplikacji). W prosty sposób możemy zatem łatwo testować zachowanie aplikacji pod obciążeniem i przy ograniczaniu kluczowych zasobów.
  • Systemy orkiestracji (takie jak UCP, origin, Rancher) oraz monitoringu i metryk (np. Prometeus, ELK, Splunk) są dostępne jako kontenery Docker – zatem możliwe jest ich wdrożenie poprzez wydanie zaledwie kilku komend. Co więcej, wspierają one i rozbudowują infrastrukturę wykonując orkiestrację (w tym np. automatyczne skalowanie) oraz monitoring (i wizualizację metryk) aplikacji umieszczonych w kontenerach. Ich użycie może przyczynić się do zmiany monolitycznych aplikacji w nowoczesne i skalowalne serwisy.
  • Kontenery oraz systemy zarządzania konfiguracją (tu: Puppet) zmniejszają potencjalną powierzchnię ataku poprzez ograniczenie (hardening) możliwości użytkowników w systemie oraz izolację i limitowanie aplikacji (capabilities), a więc realnie wpływają na bezpieczeństwo docelowego rozwiązania.
  • Kompletny obraz konfiguracji oraz budowania aplikacji (tzw. Dockerfile) znajdują się w repozytorium kodu, co pozwala nam na łatwe ich wersjonowanie, testowanie wariantów oraz wycofywanie zmian na żądanie. Coraz powszechniejszą praktyką jest integracja narzędzi wersjonowania kodu (SCM), automatycznego testowania i wydawania (CI/CD) oraz komunikacji grupowej (np. Hipchat, Slack, Mattermost), tak aby cały zespół posiadał natychmiastową orientację w zmianach już w chwili ich wprowadzenia i wdrożenia.

Zobacz też: DevOps — „symfonia kompetencji”

Tak zbudowane rozwiązanie możemy zaimplementować również w środowisku produkcyjnym, pamiętając jednak o rygorystycznym przestrzeganiu zasad bezpieczeństwa związanych z wdrażaniem i funkcjonowaniem aplikacji udostępnionych publicznie. Oto kilka wskazówek w jaki sposób wykorzystać powstałą wcześniej platformę jako finalny produkt:

  • Produkcyjne wdrożenie wymaga zaufania do uruchamianych środowisk i aplikacji. Zatem nie możemy posiłkować się już gotowymi modułami i obrazami (Docker Hub, GitHub), a wszelkie – wcześniej przetestowane – komponenty powinny zostać przebudowane ze źródeł oraz utrzymywane w prywatnych repozytoriach (git, Docker Private Registry) pod kontrolą organizacji.
  • Należy umożliwić skalowanie zależne od obciążenia przez wdrożenie odpowiedniego procesu planowania pojemności (capacity planning) opartego o monitorowanie i metryki (najczęściej z opcją prognozowania) oraz samą architekturę (aplikacja skalowana poziomo, orkiestrator zapewniający funkcjonalność autoskalera). Można do tego użyć gotowych rozwiązań dystrybuowanych jako kontenery, które opisałem powyżej.
  • Należy rozważyć użycie systemów Docker/rkt – ich funkcjonalności są podobne i oba systemy używają tych samych obrazów, jednak specyficzne opcje (np. UCP w przypadku Docker lub Flannel w przypadku rkt) mogą zadecydować o implementacji konkretnego systemu.

Trzeba pamiętać, że oprogramowanie do zarządzania konfiguracją są znane już ponad dekadę i są masowo i bezpiecznie wdrażane w niezliczonych środowiskach produkcyjnych. Nie można tego powiedzieć o nowszych narzędziach opisanych w tym artykule, które rozbudowują się i zmieniają niezwykle dynamicznie, a więc zawsze podchodzić do nich należy z odpowiednią rezerwą. Ich produkcyjne zastosowanie, może być w niektórych przypadkach nadal zbyt ryzykowne. Nie znaczy to, że należy z nich rezygnować, bo z pewnością w ciągu kilku lat ryzyko zmaleje, a ich zastosowanie będzie równie powszechne, co systemy CM (Configuration Management) dziś. Do tego czasu zaś, możemy zyskać odpowiednie know-how oraz dysponować świetnie działającym środowiskiem testowym, dzięki któremu wdrożonych zostanie wiele udanych rozwiązań, a organizacja będzie dysponować solidnym i innowacyjnym warsztatem, będąc w każdym przypadku gotową na zmiany. A te, jak wiemy, są jedyną niezmienną rzeczą w środowisku IT. Dlatego tak wiele firm już teraz implementuje systemy testowe pozwalające ujarzmić i usystematyzować badanie i testowanie zmian. Mam nadzieję, że zainspirowałem państwa do utworzenia podobnej platformy i że dzięki niej państwa organizacja będzie bardziej innowacyjna i skuteczniejsza.

Powiązane wpisy:

Nowy wymiar automatyzacji z Red Hat Ansible Automation Platform

Konfigurowanie systemów Windows za pomocą Ansible na platformie MS Azure

10 powodów dla których warto używać Zabbixa

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.

    Skontaktuj się z nami