Infrastructure as Code, lehký úvod

Publikováno: 31.7.2020

#Různé

Vysvětlíme, co znamená Infrastructure as Code, popíšeme výhody tohoto přístupu, alternativy a testování.

Celý článek

Texty vyšel původně na webu autora.

Už druhým rokem máme s kolegou krátký seminář na MatFyzu o tématu Infrastructure as Code. Předmět se jmenuje Vývoj cloudových aplikací a škola po nás chtěla, 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ě!

Během koronavirové krize proběhla letos všechna setkání přes Zoom a najdete je nahrané v playlistu 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 č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 důlež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í management

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í

  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

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

YouTube přednášky

Slidy k přednáškám

Nahoru
Tento web používá k poskytování služeb a analýze návštěvnosti soubory cookie. Používáním tohoto webu s tímto souhlasíte. Další informace