4Developers2019: Everything as Code(...)środowiska Cloud Native oparte na kontenerach,Tomasz Cholewa

### Overview W prezentacji Tomasz Cholewa omawia koncepcję „Everything as Code” w kontekście budowy i utrzymania środowisk Cloud Native opartych na kontenerach i platformie Kubernetes. Prelegent, odwołując się do analogii z bolidami Formuły 1 oraz supersamochodami takimi jak LaFerrari, zwraca uwagę na konieczność unikania ręcznych wdrożeń („klikania”) i przejścia na pełną automatyzację środowisk za pomocą kodu. Prezentowane podejście opiera się na doświadczeniach zdobytych przez prelegenta m.in. jako architekt w firmie Mindbox przy wdrożeniach dla największego operatora telekomunikacyjnego w Polsce.

### Key Topics - **Infrastruktura jako kod (IaC):** Wyeliminowanie ręcznych modyfikacji, SSH oraz klikania w konsolach dostawców chmurowych na rzecz powtarzalnych i testowalnych definicji kodu. - **Demokratyzacja dzięki Kubernetes:** Niezależność od dostawcy chmury lub środowiska on-premise (np. VMware) – Kubernetes zapewnia spójną warstwę abstrakcji umożliwiającą szybkie dostarczanie środowisk niezależnie od bazowej platformy. - **Zarządzanie konfiguracją jako kodem:** Traktowanie konfiguracji jako kluczowego elementu (porównywanego do mieszanek opon w F1) oraz organizowanie jej w hierarchiczne struktury za pomocą narzędzi takich jak Kustomize czy Helm. - **Podział ról i separacja repozytoriów:** Rozdzielenie repozytoriów z kodem aplikacji od repozytoriów konfiguracyjnych i infrastrukturalnych, co umożliwia deweloperom skupienie się na logice biznesowej, a architektom i inżynierom platformy na bezpieczeństwie, limitach zasobów i sieci. - **Automatyzacja CI/CD i środowiska ephemeral (preview):** Zastosowanie pipeline'ów Jenkinsa do zarządzania środowiskami stałymi oraz tworzenia dynamicznych środowisk poglądowych na żądanie dla Pull Requestów.

### Technical Details - **Warstwa infrastruktury:** Do provisioning infrastruktury bazowej prelegent jednoznacznie rekomenduje narzędzie Terraform (wskazując m.in. na rezygnację Oracle z własnych narzędzi na rzecz providera Terraform oraz wsparcie w Azure i VMware). Odradza stosowanie Ansible na najniższej warstwie. - **Warstwa platformy i instalacji:** Do wdrażania OpenShift (określanego jako „Kubernetes na sterydach”) wykorzystywane są playbooki Ansible, a sam proces instalacji weryfikowany jest w pipeline z użyciem narzędzi testowych, takich jak BATS, Testinfra czy Goss. - **Struktura konfiguracji aplikacji:** Konfiguracje w postaci ConfigMap, Secrets, reguł sieciowych czy limitów CPU/RAM są wersjonowane w Git i organizowane hierarchicznie (wykorzystując Kustomize wprowadzone w Kubernetes 1.14) w modelu wielu repozytoriów (multi-repo) z bazowymi szablonami na samej górze piramidy. - **Konfiguracja i orkiestracja Jenkinsa:** - Jenkins traktowany jest w całości jako kod dzięki wtyczce Jenkins Configuration as Code (JCasC). - Wykorzystanie OpenShifta pozwala na integrację natywnych obiektów Kubernetes (ConfigMap, Secret) jako poświadczeń i zmiennych Jenkinsa. - Agenci (slave'y) Jenkinsa są w pełni efemeryczni – podnoszą się dynamicznie jako pody tylko na czas trwania buildu. - Zamiast rozbudowanych Dockerfile prelegent rekomenduje technologię Source-to-Image (S2I) w celu unifikacji bazowych obrazów kontenerowych dla technologii takich jak Java/Spring, Node.js czy Python. - Pipeline'y CI/CD definiowane są jako współdzielone biblioteki (Jenkins Shared Libraries).

### Takeaways - Klikanie w interfejsach chmurowych sprawdza się wyłącznie na etapie początkowym; w środowiskach złożonych i o dużej skali zarządzanie kodem skraca czas dostarczania środowisk do pojedynczych godzin lub minut. - Kod infrastruktury należy traktować jak zwykły kod aplikacji: pokrywać go automatycznymi testami (BATS, Goss itp.), aby przełamać strach przed wprowadzaniem zmian i degradacją środowisk (tzw. driftem konfiguracyjnym). - Kubernetes pozwala na tworzenie nowoczesnych, wysoce zautomatyzowanych środowisk również w infrastrukturze lokalnej (on-premise), nie ograniczając innowacji do chmury publicznej. - Kluczem do skalowalności organizacji jest podział odpowiedzialności: deweloperzy rozwijają kod aplikacji, natomiast architekci platformy dbają o szablony, bezpieczeństwo oraz izolację parametrów środowiskowych.