Automatyzacja – Zarządzanie zmianami bez pomyłek

19

Proces budowy i rozwoju platformy, to ciągłe zmaganie się z problemami konfiguracyjnymi, implementacyjnymi czy wydajnościowymi. W większości przypadków, w jego trakcie nie można całkowicie uniknąć błędów. Dlatego tak ważne jest implementowanie systemów testowych, pozwalających ujarzmić i usystematyzować badanie i testowanie zmian.

Proces budowania architektury powinien wychodzić naprzeciw problemom, jakie możemy napotkać w przyszłości. Nie należy rezygnować z kompletności testów i możliwości wzięcia pod uwagę wszystkich dostępnych w danej dziedzinie rozwiązań. Środowisko R&D, zoptymalizowane pod szybkie cykle testowe, powinno posiadać poniższe cechy, adekwatne do tworzonych obecnie stosów technologicznych:

  • Dokumentacja projektowa, czyli system, który pozwoli stworzyć oraz na bieżąco utrzymywać podstawowe informacje nt. projektowanej platformy. Oprócz celów implementacyjnych, pozwoli ona na bieżąco dookreślić wymagania oraz powiązania pomiędzy systemami, a także ułatwi wyłapywanie luk i błędów jeszcze na etapie projektowania.
  • Możliwość wycofania zmian to nieoceniony mechanizm, który pozwala na wykonanie zmian na etapie projektowania i testowania bez obawy o przywrócenie systemu do poprzedniego (dobrego) stanu.
  • Testy A-B, to technika, która pozwala na równoległe poddanie testom dwóch wariantów platformy, aby zaobserwować, który z nich zachowa się lepiej. Aby móc je przeprowadzać, platforma musi być budowana w pełni automatycznie, a kod aplikacji oraz IaC musi wspierać możliwość rozgałęziania w wąskim zakresie (feature branch).
  • Monitoring oraz metryki to bardzo wartościowy element, pozwalający zwizualizować zachowanie środowiska. Dzięki przejrzystym wykresom oraz funkcjom można łatwo porównać zachowanie systemu. Często pozwala to na wychwycenie drobnych zmian i szybkie zdiagnozowanie potencjalnego problemu.
  • Kod wielokrotnego użytku jest ważny z dwóch powodów. Stosowanie systemów wiodących na rynku pozwala na znaczną oszczędność kosztów i badanie wielu alternatyw jednocześnie. 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ą, to każde kolejne wdrożenie będzie 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 doskonała w przypadku rozbudowanych sieciowo platform (np. mikroserwisy, infrastruktura warstwowa, klastry). Nowoczesne środowiska sieciowe pozwalają zasymulować wiele warstw sieci i zdefiniować określone (ograniczone) kryteria ruchu sieciowego.
  • Możliwość elastycznej modyfikacji konfiguracji (ang. customizability) to cecha, która pozwala dopasować moduły oraz zachowanie aplikacji do konkretnych zastosowań.
  • Bezpieczeństwo to bez wątpienia wątek, który powinien towarzyszyć całemu cyklowi SDLC (Software Development Life Cycle), począwszy od etapu projektowania. Zapewnienie podstawowych zasad bezpieczeństwa (np. uprawnienia, hardening, czy usuwanie zbędnych możliwości systemu) od pierwszego dnia istnienia projektu, przyczynia się wydatnie do zmniejszenia “debetu technologicznego” i przyszłych kosztów naprawczych.

Złożoność systemów informatycznych to problem działów deweloperskich i operacyjnych we wszystkich innowacyjnych firmach, gdzie trzonem działania są takie systemy. 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 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 czy CoreOS bez żmudnej ręcznej konfiguracji.
  • Docker Hub oraz GitHub to odpowiedniki Facebooka (czy bardziej ogólnie – social media) dla programistów i operatorów. Miejsce, gdzie (w duchu open source) programiści dzielą się swoimi pomysłami i gotowymi modułami oraz pozwalają społeczności na ich rozwój i klonowanie (forkowanie).
  • 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 miało to miejsce w środowisku produkcyjnym.
  • Puppet Style Guide gwarantuje, że wszystkie moduły zatwierdzone na Puppet Forge będą podlegać parametryzacji. 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 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ę. 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 na ich łatwe 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.

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.

Trzeba pamiętać, że oprogramowanie do zarządzania konfiguracją jest znane już ponad dekadę, a co za tym idzie, masowo i bezpiecznie wdrażane w niezliczonych środowiskach produkcyjnych. Inaczej sytuacja wygląda w przypadku nowszych narzędzi opisanych powyżej, które rozbudowują się i zmieniają niezwykle dynamicznie, w związku z czym zawsze należy do nich podchodzić z odpowiednią rezerwą. Ich produkcyjne zastosowanie w niektórych przypadkach może nadal być zbyt ryzykowne, jednak nie oznacza to, że należy z nich całkowicie rezygnować. Z pewnością w ciągu kilku lat ryzyko zmaleje, a ich zastosowanie będzie równie powszechne, co dziś wdrażanie systemów CM (Configuration Management). Tymczasem warto pracować nad uzyskaniem odpowiedniego know-how oraz tworzyć sprawnie działające środowisko testowe, 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.

Autorem komentarza jest Konrad Rzentarzewski, Senior Solution Architect w Linux Polska Sp. z o.o.

źródło: Core PR