Infrastructure as Code, lehký úvod

Už druhým rokem máme s kolegou krátký seminář na MatFyzu o tématu Infrastructure as Code. Takže když už jsem to dopracoval tak daleko, že rozdávám moudra na univerzitě, 🤭 tak by neškodilo si trochu té slávy znalosti odložit i zde.

Rád bych se chviličku zastavil u toho, proč jsme posunuli téma někam jinam, než škola původně chtěla — předmět se jmenuje Vývoj cloudových aplikací a primárně po nás chtěli, abychom popovídali o našem cloudu.

My jsme si ale řekli, že než vykládat o konkrétním cloudu, kdy bude všechno za pár měsíců/let úplně jinak, bude lepší studentům předložit obecnější a trvalejší koncept. A voilà, přednáška Infrastructure as Code byla na světě!

[Update 14. 5. 2020] Vzhledem ke koronavirové šarádě 🤦‍♂️ byly všechny session přes Zoom a pro jistotu jsme je nahrávali. A poněvadž pak studenti požádali o jejich sdílení, tak jsem je publikoval na YouTube.

Definice 3x jinak

Když jsem se na přednášku připravoval, začal jsem tím, co o tématu říkají chytřejší něž já. Například Wikipedie říká:

Infrastructure as code (IaC) is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools. The IT infrastructure managed by this comprises both physical equipment such as bare-metal servers as well as virtual machines and associated configuration resources.

The definitions may be in a version control system.

Software-špióni z ThoughtWorks to zase vidí takhle:

Infrastructure as code, or programmable infrastructure, means writing code (which can be done using a high level language or any descriptive language) to manage configurations and automate provisioning of infrastructure in addition to deployments. … using tested and proven software development practices that are already being used in application development. For example: version control, testing, small deployments, use of design patterns etc. In short, this means you write code to provision and manage your server, in addition to automating processes.

No a Azure DevOps to popisuje jako:

Infrastructure as Code (IaC) is the management of infrastructure (networks, virtual machines, load balancers, and connection topology) in a descriptive model, using the same versioning as DevOps team uses for source code. Like the principle that the same source code generates the same binary, an IaC model generates the same environment every time it is applied.

Idempotence is a principle of Infrastructure as Code. … a deployment command always sets the target environment into the same configuration, regardless of the environment’s starting state.

Jak je vidět, definic existuje mnoho (vybral jsem ty, jež mi nejlíp konvenují) a žádná z nich není kompletní, ani jednoduchá. Za sebe bych si tedy dovolil vypíchnout ty nejpodstatnější aspekty:

  • Infrastruktura je definována (většinou deskriptivním) kódem. Kód má být ve verzovacím systému. (Používá se ještě něco jiného než Git? 🤔)
  • Tenhle kód se používá během CI/CD (Continuous Integration/Continuous Delivery).
  • Kód si zaslouží stejné praktiky, jako běžný “vývojářský” kód. Tedy: testování, inkrementální deployment, code review, clean code, good design, atd.
  • Kód generuje opakovatelný a idempotentní(!) výsledek.

Co to je zase za novinku? 🙄

Samozřejmě, je legitimní otázka, proč by se o něco takového měl (náš) tým snažit?

Benefity

Mezi sociální jistoty IaC patří:

Vývojový tým je vlastníkem (virtuální) infrastruktury. Tohle jde ruku v ruce se všemi těmi proudy jako je DevOps, kros-funkční týmy, atd. Pokud pracujete v silu, tak IaC asi nedosáhne svého potencionálu.

Developer mindset. Možná si někdo ještě myslí, že mít (rasově 😈) čisté role, je dobrý nápad. Vývojáři a operations/admini se můžou navzájem hodně obohatit. A sdílený kód je nejlepším pojítkem, průnikem a závazkem. Plus, vývojáři prostě vědí, jak s kódem zacházet.

Version control — a single source of truth. Proč mít duležité věci rozeseté po různých wiki, privátních návodech, proč mít různé aspekty softwarového vývoje v různých formátech? Kód je kód, jsme přece softwarový inženýři. Verzovací systém a textový soubor — nic transparentnějšího ještě nikdo nevymyslel. Šup tam i s infrastrukturou!

Knowledge sharing. Známý bus factor, co k tomu dodat?

Automatizace. Opět ohraná písnička: odstranění lidských chyb a nekonzistencí, neúplnost řešení atd.

CI/CD. Už to bylo řečeno, ale je potřeba to znovu zdůraznit — bez CI/CD není žádný IaC.

Proč zrovna teď? 🤔

Že se IaC vynořilo v uplynulých letech má svoje důvody. Ono jich bude víc, ale jako tři dominantní bych viděl:

  • vzestup a prominence DevOps,
  • cloudová infrastruktura je převážně API-driven,
  • infrastuktura je vysoce elastická.

Poslední bod bych trochu rozvedl, poněvadž nemusí být úplně jasné, co mám na mysli. Jedním pojmem, umožňujícím elasticitu je disposable infrastructure. Česky bychom řekli něco jako “infrastruktura, která se dá zahodit”.

Jde o to, že pokud jsou v dnešní době zdroje převážně virtuální, není problém celou infrastrukturu zahodit a znovu ji postavit lusknutím prstů — nemusíme ji budovat v potu a krvi z fyzických strojů.

A s tím souvisí i druhý aspekt, který má význačné finanční konotace — zdroje (v cloudu) dnes žijou povětšinou krátkodobě: spíše hodiny, dny až týdny, než měsíce a roky.

A tyhle dvě položky samozřejmě tlačí k větší automatizaci. Přičemž odpovědí je… IaC. 🤓

Jaké jsou alternativy?

Alternativy všichni už dávno známe:

  • Manuální nastavení přes UI konzoli.
  • Manuální nastavení nějakým CLI nástrojem.
  • Sada custom/in-house nástrojů (takové ty smečky neudržovatelných skriptů, na koleně zrobených frameworků atd.).

To nechcete. 🤢

Dvě kategorie, dva přístupy

Jak už jsme viděli u definic(e), výklad IaC je různorodý. Stejně tak, pokud se budeme snažit jej dále katalogizovat. Jeden takový pohled vychází z toho, jak se IaC dívá na komponenty, které spravuje:

Immutable objekty

  1. Objekt se ne-updatuje,
  2. místo toho se odstraní,
  3. a potom se vytvoří nový.

Mutable objekty

  • Změny jsou propagovány do běžících komponent.

Jiný pohled kategorizuje použité nástroje:

Orchestrační nástoje

Nástroje pro konfigurační manažment

Testování

IaC nedělají jenom nástroje, ale také proces — už jsem opakovaně zmiňoval CI/CD. Neoddělitelnou a nutnou součástí tohoto procesu je i testování.

Jak takové testování vypadá? Zjednodušeně ho popisuje následující “3-kostičkový” diagram:

Schéma IaC testování

Schéma IaC testování

  1. V rámci CI/CD se pustí provisioning: buď vytvoření infrastruktury from-the-scratch, nebo z nějaké definované baseline.
  2. Spustí se sada testů, které testují infrastrukturu. Např. jestli se správně vytvořily sítě, jestli nastartoval určitý počet virtuální mašin, jestli jsou dostupné určité porty, atd.
  3. Spustí se de-provisioning, čili odstranění vytvořené infrastruktury.

Konkrétní příklad

Zatím jsme se bavili o IaC obecně, tak je na čase zmínit něco konkrétního — popíšu, jak jsme IaC využili v rámci vytváření nového produktu.

Kontext

Stavěli jsme novou cloud-native službu — takovou, která bude později součástí cloudové platformy.

Následující diagram zobrazuje infrastukturu, která byla kompletně spravována přístupem IaC. Nejedná se o celou architekturu, ale pouze o řídící část služby (control plane). Druhá (ta větší) skupina zdrojů — která měla na starosti exekuční část služby (data plane) — se vytvářela dynamicky on-demand (elastický výpočetní cluster) a jako taková, nebyla pro IaC vhodná.

Control Plane infrastruktura vytvářená Terraformem

Control Plane infrastruktura vytvářená Terraformem

Deliverables

  • RPM balíčky
  • Docker image
  • Cloud-native image (to z čeho se startuje compute instance)

Nástroje

Praktiky

  • Všechny Terraform skripty byly uloženy v Gitu.
  • Změny skriptů procházely code review.
  • Struktura a rozdělení skriptů odpovídala best practices a konvencím daného Terraform Providera.
  • Vytvoření validní infrastruktury bylo pokryto Terratest testy.
  • Provisioning infrastruktury, její testování a de-provisioning byly součástí CI/CD pipeliny.
GitLab Pipelines se zvýrazněnými Terraform testy

GitLab Pipelines se zvýrazněnými Terraform testy

Související články

YouTube přednášky

Slidy k přednáškám

🏷️ infrastructure-as-code 🏷️ cloud 🏷️ terraform