Co je infrastruktura jako kód?

  • 10 min

Budete požádáni, abyste posoudili, jestli infrastruktura jako kód může být cenným přístupem ke zřizování prostředků ve vaší společnosti. Kontrolujete dostupné možnosti nasazení, včetně následujících:

  • Azure Portal
  • Azure CLI
  • Azure PowerShell
  • Šablony Azure Resource Manageru (JSON a Bicep)

Hledáte opakovatelnou možnost a musíte se rozhodnout, kterou technologii použít k nasazení infrastruktury Azure.

V této lekci se dozvíte, jak a proč vám infrastruktura jako kód může pomoct nasadit infrastrukturu Azure automatizovaným a opakovatelným způsobem.

Příkazy Azure CLI slouží k ilustraci konceptů. Další informace o použití příkazů k nasazení prostředků v dalších modulech studijního programu Bicep.

Definování infrastruktury jako kódu

Vaše společnost navrhuje nové hračky pro uvedení na trh a většina nových hraček vyžaduje po zakoupení nějaké sestavení. Návrhový tým společnosti vytvoří návody, které se mají zahrnout do jednotlivých toy. Každá příručka obsahuje podrobné informace o tom, jak správně sestavit toy.

Infrastrukturu si můžete představit jako kód jako návod pro vaši infrastrukturu. Ruční podrobnosti o koncové konfiguraci vašich prostředků a o tom, jak dosáhnout tohoto stavu konfigurace.

Infrastruktura jako kód je proces automatizace zřizování infrastruktury. Používá popisný kódovací jazyk a systém správy verzí, který se podobá tomu, co se používá pro zdrojový kód. Když vytvoříte aplikaci, zdrojový kód při každém kompilaci vygeneruje stejný výsledek. Podobně jsou nasazení infrastruktury jako kódu automatizovaná, konzistentní a opakovatelná. Infrastruktura jako kód může automatizovat nasazení prostředků infrastruktury, jako jsou virtuální sítě, virtuální počítače, aplikace a úložiště.

Diagram znázorňující infrastrukturu jako proces kódu pomocí úložiště zdrojového kódu se šablonou, která nasazuje prostředky Azure

Pokud si vzpomenete na návod k novému toy, existuje několik způsobů, jak napsat návod k obsluze. Jednou z možností je podrobně pro každý krok procesu sestavení. Další možností je ukázat rozložený pohled na kusy a části potřebné k sestavení toy. Později v této lekci se dozvíte o rozdílech mezi imperativním a deklarativním kódem a o tom, jak souvisí s návody vaší společnosti.

Proč používat infrastrukturu jako kód?

Přijetí infrastruktury jako přístupu ke kódu nabízí mnoho výhod zřizování prostředků. S infrastrukturou jako kódem můžete:

  • Zvyšte důvěru v nasazení.
  • Správa více prostředí
  • Lépe porozumíte cloudovým prostředkům.

Zvýšení spolehlivosti

Jednou z výhod používání infrastruktury jako kódu je úroveň spolehlivosti, kterou v nasazeních získáte z vylepšení konzistence a zabezpečení.

  • Integracesch Například partnerské kontroly můžou pomoct při zjišťování problémů v konfiguracích, které by mohly být obtížné rozpoznat při provádění ručních změn.

  • Konzistence: Přechod na infrastrukturu jako přístup ke kódu pomáhá vašemu týmu sledovat dobře zavedené procesy nasazení infrastruktury. Díky těmto procesům se odpovědnost přesune z malé skupiny jednotlivců na proces automatizace a nástroje. Infrastruktura jako kód pomáhá snížit lidské chyby při zřizování prostředků a zajistit konzistentní nasazení.

  • Automatizovaná kontrola: Konfigurace infrastruktury jako kódu můžete kontrolovat pomocí automatizovaných nástrojů, které můžou kontrolovat chyby v kódu. Automatizované nástroje mohou také zkontrolovat navrhované změny a zajistit, aby byly dodrženy postupy zabezpečení a výkonu.

  • Správa tajných kódů: Řada řešení vyžaduje tajné kódy, jako jsou připojovací řetězec, šifrovací klíče, tajné klíče klienta a certifikáty. Azure Key Vault je služba, která se používá k bezpečnému ukládání těchto tajných kódů. Mnoho nástrojů infrastruktury jako kódu se dá integrovat se službou Key Vault, aby bylo možné bezpečně přistupovat k těmto tajným kódům při nasazení.

  • Řízení přístupu: S nasazením infrastruktury jako kódu máte možnost automatizovat zřizování prostředků pomocí spravovaných identit nebo účtů služeb. Tento proces zajišťuje, aby vaše cloudové prostředky mohly upravovat pouze tyto identity. Pomáhá také zabránit nesprávným konfiguracím nasazených do produkčního prostředí. V případě potřeby můžete tento proces přepsat pomocí účtu tísňového přístupu (často označovaného jako účet pro přerušení) nebo pomocí funkce Microsoft Entra ID Privileged Identity Management.

  • Vyhněte se posunu konfigurace: Idempotence je termín, který je často přidružený k infrastruktuře jako kódu. Když je operace idempotentní, znamená to, že pokaždé, když ji spustíte, poskytne stejný výsledek. Pokud zvolíte nástroje, které používají idempotentní operace, můžete se vyhnout posunu konfigurace.

Jako příklad idempotenci zvažte následující příkaz Azure CLI. Příkaz vytvoří skupinu prostředků Azure s názvem storage-resource-group v oblasti USA – východ.

az group create \
  --name storage-resource-group \
  --location eastus

Pokud tento příkaz spustíte podruhé, obdržíte úplně stejný výstup, protože tento příkaz Azure CLI byl navržen tak, aby byl idempotentní. Nezobrazí se chyba nebo duplicitní skupina prostředků.

Když jako kód používáte infrastrukturu, můžete prostředí znovu nasadit v každé verzi řešení. Tyto verze můžou zahrnovat malé změny konfigurace nebo dokonce významné aktualizace. Tento proces pomáhá vyhnout se posunu konfigurace. Pokud dojde k náhodné změně prostředku, můžete ji opravit opětovným nasazením konfigurace. Tímto přístupem dokumentujete prostředí pomocí kódu.

Správa více prostředí

Mnoho organizací udržuje více aplikačních prostředí. Vývojáři ve vaší společnosti toy můžou mít v úložišti pro vydání do různých prostředí několik verzí kódu aplikace. Prostředí můžou zahrnovat vývoj, testování a produkci. Některé organizace udržují několik produkčních prostředí pro aplikace, které jsou distribuované globálně. Jiné organizace, jako jsou nezávislí dodavatelé softwaru (ISV), udržují pro své zákazníky několik prostředí tenantů.

Tady je několik klíčových způsobů, jak vám může infrastruktura jako kód pomoct se správou prostředí:

  • Zřizování nových prostředí: Jednou z hlavních výhod cloud computingu je možnost škálování. Infrastruktura jako kód vám může pomoct škálovat na více instancí aplikace. Tyto instance můžou pomoct v době zvýšené zátěže nebo je můžete nasadit pro uživatele v jiných oblastech světa. Tato flexibilita může být užitečná i při testování aplikace, jako je testování průniku, zátěžové testování a testování chyb. Pomocí dobře definovaného základu kódu můžete dynamicky zřizovat tato nová prostředí konzistentním způsobem.

  • Neprodukční prostředí: Běžná problémová organizace čelí rozlišení mezi produkčním a neprodukčním prostředím. Když ručně zřídíte prostředky v samostatných prostředích, je možné, že se koncová konfigurace neshodují. Příkladem je nasazení nové funkce do neprodukčního prostředí, které se liší od produkčního prostředí. Je možné, že nová funkce v produkčním prostředí nefunguje podle očekávání kvůli rozdílům mezi těmito dvěma prostředími. Použití infrastruktury jako kódu může pomoct tyto problémy minimalizovat. Pro každé prostředí můžete použít stejné konfigurační soubory, ale zadat různé vstupní parametry k vytvoření jedinečnosti.

  • Zotavení po havárii: V některých situacích lze infrastrukturu jako kód použít jako součást plánu zotavení po havárii organizace. Z důvodu výpadku služby může být například potřeba znovu vytvořit prostředí v jiné oblasti. Pomocí infrastruktury jako kódu můžete rychle zřídit novou instanci, která převezme služby při selhání, místo ručního nasazení a překonfigurování všeho.

Lepší porozumění cloudovým prostředkům

Infrastruktura jako kód vám může pomoct lépe porozumět stavu cloudových prostředků:

  • Záznam auditu: Změny konfigurace infrastruktury jako kódu se řídí verzí stejným způsobem jako zdrojový kód vaší aplikace. Tyto změny se sledují ve vašich nástrojích, jako je historie verzí Gitu. Tento záznam auditu znamená, že můžete zkontrolovat podrobnosti o každé změně, kdo změnu provedl a kdy byla změna provedena.

  • Dokumentace: K přidání metadat, jako jsou komentáře, které popisují účel kódu v konfiguraci, můžete použít mnoho konfigurací infrastruktury jako kódu. Pokud už vaše organizace dodržuje proces dokumentace kódu, zvažte použití těchto stejných postupů s kódem infrastruktury.

  • Jednotný systém: Často, když vývojář pracuje na nové funkci, musí provádět změny kódu aplikace a kódu infrastruktury. Když používáte běžný systém, může vaše organizace lépe porozumět vztahu mezi vašimi aplikacemi a vaší infrastrukturou.

  • Lepší porozumění cloudové infrastruktuře: Když ke zřizování prostředků použijete Azure Portal, mnoho procesů se z pohledu abstrahuje. Infrastruktura jako kód vám může pomoct lépe pochopit, jak Azure funguje a jak řešit problémy, které by mohly nastat. Když například vytvoříte virtuální počítač pomocí webu Azure Portal, některé vytvořené prostředky se ze zobrazení abstrahují. Spravované disky a síťové karty se nasazují na pozadí. Když nasadíte stejný virtuální počítač pomocí infrastruktury jako kódu, máte úplnou kontrolu nad všemi vytvořenými prostředky.

Imperativní a deklarativní kód

Návod k novému sestavení toy můžete napsat různými způsoby. Když automatizujete nasazení služeb a infrastruktury, můžete použít dva přístupy: imperativní a deklarativní.

  • S imperativním kódem spustíte posloupnost příkazů v určitém pořadí, abyste dosáhli koncové konfigurace. Tento proces definuje, co má kód provést, a definuje, jak provést úlohu. Imperativní přístup je jako podrobný návod.

  • Pomocí deklarativního kódu zadáte pouze koncovou konfiguraci. Kód nedefinuje, jak úlohu provést. Deklarativní přístup je jako rozložený návod k zobrazení.

Když zvolíte použití imperativního přístupu a deklarativního přístupu ke zřizování prostředků, zvažte nástroje, které se už ve vaší organizaci používají. Zvažte také, který přístup může odpovídat vašim dovednostem.

Imperativní kód

V Azure se imperativní přístup kódu provádí programově pomocí skriptovacího jazyka, jako je Bash nebo Azure PowerShell. Skripty provádějí řadu kroků pro vytvoření, úpravu a dokonce odebrání prostředků.

Tento příklad ukazuje dva příkazy Azure CLI, které vytvoří skupinu prostředků a účet úložiště.

#!/usr/bin/env bash
az group create \
  --name storage-resource-group \
  --location eastus

az storage account create \
  --name mystorageaccount \
  --resource-group storage-resource-group \
  --location eastus \
  --sku Standard_LRS \
  --kind StorageV2 \
  --access-tier Hot \
  --https-only true

První příkaz vytvoří skupinu prostředků pojmenovanou storage-resource-group v oblasti USA – východ. Druhý příkaz vytvoří účet úložiště pojmenovaný mystorageaccount ve storage-resource-group skupině prostředků, která byla vytvořena v prvním příkazu. Druhý příkaz také nakonfiguruje některé vlastnosti pro účet úložiště, včetně typu účtu úložiště a jeho úrovně přístupu.

K úplné automatizaci zřizování prostředků můžete použít imperativní přístup, ale tento přístup má určité nevýhody. S tím, jak vaše architektura zralá, se skripty můžou stát složitými pro správu. Příkazy můžou být aktualizované nebo zastaralé, což vyžaduje revize existujících skriptů.

Deklarativní kód

V Azure se deklarativní přístup kódu provádí pomocí šablon. K dispozici je mnoho typů šablon, mezi které patří:

  • JSON
  • Bicep
  • Ansible, autor: RedHat
  • Terraform, by HashiCorp

Poznámka:

Tento modul se zaměřuje na používání šablon Bicep.

Podívejte se na následující příklad šablony Bicep, která konfiguruje účet úložiště. Konfigurace účtu úložiště odpovídá příkladu Azure CLI.

resource storageAccount 'Microsoft.Storage/storageAccounts@2203-05-01' = {
  name: 'mystorageaccount'
  location: 'eastus'
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
    supportsHttpsTrafficOnly: true
  }
}

Oddíl prostředků definuje konfiguraci účtu úložiště. Tato část obsahuje název, umístění a vlastnosti účtu úložiště, včetně jeho skladové položky a typu účtu.

Můžete si všimnout, že šablona Bicep nezadá způsob nasazení účtu úložiště. Určuje jenom to, jak účet úložiště musí vypadat. Skutečné kroky, které se spouští na pozadí, aby vytvořily tento účet úložiště nebo aby ho aktualizovaly tak, aby odpovídaly specifikaci, zbývá azure rozhodnout.