Přejít k navigační liště

Zdroják » Různé » Infrastructure as Code, lehký úvod

Infrastructure as Code, lehký úvod

Články Různé

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

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 DevOpskros-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

Komentáře

Subscribe
Upozornit na
guest
9 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Pepa

Mozna bych Infrastructure as Code videl spis vic a lepe treba takto: AWS CDK

Pepa
https://pepa.holla.cz

Franta

Co jsem mel moznost zatim zazit tak sdilene DevOps moc nefunguje. Vyvojari chtej vyvijet a ne se placat s infrastrukturou a vrcholem statecnosti je v jejich pripade helm chart, ktery nasadi jejich aplikaci nebo ci pipelina v jenkinsu, ale ansible role ktera pripravi os pod nim uz je vetsinou nad jejich sily. Lide od infrastruktury se zase chteji venovat ji a ne ladit kod kterymu nerozumej. V nekterych firmach funguje specialni „DevOps“ oddeleni, ktere ale nedela nic jineho nez se pomaha vyvojarum nastroje ktere nasadi, pripadne zbuildi jejich aplikaci v nastrojich, ktery je u nich standardem. To ale neni oni sdilene DevOps. Markantni je to zejmena v pripadech, kdy se spolecnost rozhodne pouzivat on-premise cloudova reseni, jako jsou kubernetes, openshift apod, zde se vetsinou o takovou platformu stara specialni team pokrokovejsich adminu, protoze vyvojari tomu proste nehovi. Tak to proste je, napsat mikrosluzbu je jedna vec, ale zajistit ji zdroje, vysokou dostupnost, monitoring, bezpecne ji publikovat ven, nebo umoznit ji komunikovat s ostatnimi komponenti uvnitr neni trivialni vec a zezere to spoustu casu a usili.

Karel

No, ale o tom to přesně je. DevOps neznamená, že se najednou z Devs stanou Ops. Zmíněný Helm chat je přesně to místo, kde odbornost vývojáře končí (ví co jeho aplikace potřebuje) a začíná role provozu (ví co s ním). Nejde o to, aby vývojář dělal všechno od železa po front-end. A nezapomínejme ani na security, pokud ji firma vůbec řeší.

Franta

Ale tak to defacto fungovalo i pred DevOps jen se tomu tak nerikalo :). Prisel release a aplikaci nasazoval clovek od app serveru, pripadne databazi apod, v tom neni zadna zmena, jedine co je dnes jine jsou nastroje.

Karel

No jasně :) Jako IT lidé na to máme talent – brát staré věci a dávat jim nové názvy. Best practices jsou v podstatě pořád stejné a ani se moc nemění, dokonce i ty nástroje tu byly už dávno předtím

Kde osobně vidím rozdíl, tak je to celkově naladění ve společnosti – v korporátech se uvažuje nějaké „rozdělení odpovědnosti“, které s devops jde tak trošku do pozadí…

Makovec

I já to vidím tak že jde kromě toho že se “ops” stávají přesunem do cloudů a k virtualizací stále komplexnějšími také o změnu akcentu či převládající mentality – a jako vývojáře který se vždcky nejraději soustředil , aniž by přitom zanedbával nebo odbýval vlastní řemeslo, na to co produkt může udělat pro uživatelemi to upřímně řečeno moc netěší. Z mého pohledu se z hodně vlastně rozumných přístupů a principů pro, v nejobecnějším smyslu, infrastrukturu, stává samožerný stroj který přimo i nepřimo (“prosakováním ops mentality”) nadmíru omezuje vlastní vývoj, a snaží se dělat z řemesla vědu (či magii, chcete-li). Podobně se školometským a mechanickým aplikováním různých architektonických paradigmat.

Franta

Souhlas, jen doplnim ze ani infrastruktura/ops z toho neni take nijak nadasena, protoze vznika mnoho novych trecich ploch kde vlastne neni jasne kdo a jak je ma resit. Typickym prikladem muze byt treba zfailovany build v nejakem ci nastroji, kdy problem muze byt jak chyba v appikaci samotne tak treba nedostatek zdroju pro ci apod.

Rad bych zminil, ze puvodni prispevek sem zde postoval hlavne kvuli nazorum ze: „Vyvojari vlastni infrastrukturu“ a “ Vsichni v miru a pokoji spravujeme sdileny kod aplikace“. Hlavne tu druhou vetu povazuji pro vsi ucte za hodne naivni. Co se tyce vlastnictvi infrastruktury; priznam se ze neznam do detailu nazvoslovi pm, ale neni vlastnikem spis devops oddeleni, pripadne infra/ops a neposkytuje infrastruktru jako sluzbu devu ? Domnivam se ze pokud dev bude jejim vlastnikem, musel by byt odpovedny napr. za jeji patch mgmt, securitu, zalohovani, db spravu, ruzne infra komponenty apod. A to mi opet hlevne v on-premis reseni prijde jako hodne velke scifi.

Makovec

Za mně už jen stručná poznámka:

Plus, vývojáři prostě vědí, jak s kódem zacházet.

Tohle se mi opravdu nelíbí. Zacházet s kódem (zde textem ve verzovacím systému) přece není zacházení s tím co ten kód představuje. To je přece proč se to dělá, nebo snad ne?

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.