Nasazení do infrastruktury Azure pomocí GitHub Actions

V této příručce se podíváme, jak využít CI/CD a infrastrukturu jako kód (IaC) k nasazení do Azure pomocí GitHub Actions automatizovaným a opakovatelným způsobem.

Tento článek je přehledem architektury a představuje strukturované řešení pro návrh aplikace v Azure, která je škálovatelná, zabezpečená, odolná a vysoce dostupná. Pokud chcete zobrazit více skutečných příkladů cloudových architektur a nápadů na řešení, projděte si architektury Azure.

Výhody používání IaC a automatizace pro nasazení

Existuje mnoho způsobů nasazení do Azure, včetně webu Azure Portal, rozhraní příkazového řádku, rozhraní API a dalších. Pro tuto příručku použijeme automatizaci IaC a CI/CD. Mezi výhody tohoto přístupu patří:

• Deklarativní: Když definujete svou infrastrukturu a proces nasazení v kódu, lze ho verzovat a kontrolovat v rámci standardního životního cyklu vývoje softwaru. IaC také pomáhá zabránit jakémukoli posunu v konfiguraci.

• Konzistence: Následující proces IaC zajišťuje, že celá organizace dodržuje standardní a dobře zavedenou metodu nasazení infrastruktury, která zahrnuje osvědčené postupy a je posílená tak, aby vyhovovala vašim potřebám zabezpečení. Všechna vylepšení centrálních šablon se dají snadno použít v celé organizaci.

• Zabezpečení: Centrálně spravované šablony mohou být posíleny a schváleny cloudovým provozním týmem nebo týmem zabezpečení tak, aby splňovaly interní standardy.

• Samoobslužná služba: Týmy je možné využít k nasazení vlastní infrastruktury pomocí centrálně spravovaných šablon.

• Vylepšená produktivita: Díky využití standardních šablon můžou týmy rychle zřizovat nová prostředí, aniž by se museli starat o všechny podrobnosti implementace.

Další informace najdete v rámci opakovatelné infrastruktury v Centru architektury Azure nebo co je infrastruktura jako kód v Centru prostředků DevOps.

Architecture

Dataflow

1. Vytvořte novou větev a zkontrolujte potřebné úpravy kódu IaC.
2. Jakmile budete připraveni sloučit změny do svého prostředí, vytvořte žádost o přijetí změn (PR) na GitHubu.
3. Pracovní postup GitHub Actions se aktivuje, aby byl váš kód dobře naformátovaný, interně konzistentní a vytvořil zabezpečenou infrastrukturu. Kromě toho se spustí Plán Terraformu nebo analýza 'co kdyby' Bicep, která vygeneruje náhled změn, ke kterým dojde ve vašem prostředí Azure.
4. Po řádném přezkoumání lze PR sloučit do hlavní větve.
5. Jiný pracovní postup GitHub Actions se aktivuje z hlavní větve a provede změny pomocí vašeho poskytovatele IaC.
6. (s výhradním přístupem k Terraformu) Pravidelně naplánovaný pracovní postup akce GitHubu by se měl spustit také tak, aby vyhledal všechny odchylky konfigurace ve vašem prostředí a vytvořil nový problém, pokud se zjistí změny.

Požadavky

Použijte Bicep

1. Vytváření prostředí GitHubu

   Pracovní postupy využívají prostředí GitHubu a tajné kódy k ukládání informací o identitě Azure a nastavení procesu schvalování pro nasazení. Podle těchto production vytvořte prostředí s názvem. V prostředí production nastavte pravidlo ochrany a přidejte všechny požadované schvalovatele, které chcete, aby schválili produkční nasazení. Prostředí můžete také omezit na hlavní větev. Podrobné pokyny najdete tady.

2. Nastavení Azure Identity:

   Vyžaduje se aplikace Azure Active Directory, která má oprávnění k nasazení v rámci vašeho předplatného Azure. Vytvořte jednu aplikaci a přidělte jí příslušná oprávnění ke čtení a zápisu ve vašem předplatném Azure. Dále nastavte federované přihlašovací údaje, aby GitHub mohl využívat identitu pomocí OpenID Connect (OIDC). Podrobné pokyny najdete v dokumentaci k Azure . Bude potřeba přidat tři federované přihlašovací údaje:

   • Nastavte typ entity na Environment a použijte název prostředí production.
   • Nastavte typ entity na Pull Request.
   • Nastavte typ entity na Branch a použijte název větve main.

3. Přidání tajných kódů GitHubu

   Poznámka:

   I když žádná data o identitách Azure neobsahují žádné tajné kódy nebo přihlašovací údaje, stále používáme tajné kódy GitHubu jako pohodlný způsob parametrizace informací o identitě v jednotlivých prostředích.

   Pomocí identity Azure vytvořte v úložišti následující tajné kódy:

   • AZURE_CLIENT_ID : ID aplikace (klienta) registrace aplikace v Azure
   • AZURE_TENANT_ID : ID tenanta Azure Active Directory, ve kterém je definována registrace aplikace.
   • AZURE_SUBSCRIPTION_ID : ID předplatného, ve kterém je definována registrace aplikace.

   Pokyny k přidání tajných kódů do úložiště najdete tady.

Použití Terraformu

1. Konfigurace umístění stavu Terraformu

   Terraform využívá soubor stavu k ukládání informací o aktuálním stavu spravované infrastruktury a přidružené konfiguraci. Tento soubor bude potřeba zachovat mezi různými spuštěními pracovního postupu. Doporučeným přístupem je uložit tento soubor v rámci účtu úložiště Azure nebo jiného podobného vzdáleného back-endu. Za normálních okolností by toto úložiště bylo zřízeno ručně nebo prostřednictvím samostatného pracovního postupu. Back-endový blok Terraformu budete muset aktualizovat s vybraným umístěním úložiště; dokumentaci najdete tady.

2. Vytvoření prostředí GitHubu

   Pracovní postupy využívají prostředí GitHubu a tajné kódy k ukládání informací o identitě Azure a nastavení procesu schvalování pro nasazení. Podle těchto production vytvořte prostředí s názvem. V production prostředí nastavte pravidlo ochrany a přidejte všechny požadované schvalovatele, které potřebujete odhlásit při produkčních nasazeních. Prostředí můžete také omezit na hlavní větev. Podrobné pokyny najdete tady.

3. Nastavení Azure Identity:

   Vyžaduje se aplikace Azure Active Directory, která má oprávnění k nasazení v rámci vašeho předplatného Azure. Vytvořte samostatnou aplikaci pro účet read-only a read/write udělte jim příslušná oprávnění ve vašem předplatném Azure. Obě role navíc budou potřebovat alespoň Reader and Data Access oprávnění k účtu úložiště, ve kterém se nachází stav Terraformu z kroku 1. Dále nastavte federované přihlašovací údaje, aby GitHub mohl využívat identitu pomocí OpenID Connect (OIDC). Podrobné pokyny najdete v dokumentaci k Azure .

   read/write Pro identitu vytvořte jeden federovaný přihlašovací údaj následujícím způsobem:

   • Nastavte Entity Type na Environment a použijte název prostředí production.

   read-only Pro identitu vytvořte dva federované přihlašovací údaje následujícím způsobem:

   • Nastavte Entity Type na hodnotu Pull Request.
   • Nastavte Entity Type na Branch a použijte jméno větve main.

4. Přidání tajných kódů GitHubu

   Poznámka:

   I když žádná data o identitách Azure neobsahují žádné tajné kódy nebo přihlašovací údaje, stále používáme tajné kódy GitHubu jako pohodlný způsob parametrizace informací o identitě v jednotlivých prostředích.

   Vytvořte v úložišti následující tajemství pomocí identity read-only:

   • AZURE_CLIENT_ID : ID aplikace (klienta) registrace aplikace v Azure
   • AZURE_TENANT_ID : ID tenanta Azure Active Directory, ve kterém je definována registrace aplikace.
   • AZURE_SUBSCRIPTION_ID : ID předplatného, ve kterém je definována registrace aplikace.

   Pokyny k přidání tajných kódů do úložiště najdete tady.

   Vytvořte další tajnost v prostředí production pomocí identity read-write:

   • AZURE_CLIENT_ID : ID aplikace (klienta) registrace aplikace v Azure

   Pokyny k přidání tajných kódů do prostředí najdete tady. Tajný klíč prostředí přepíše tajný klíč úložiště při provádění kroku nasazení do production prostředí v případě, že jsou vyžadována zvýšená oprávnění ke čtení a zápisu.

Nasazení pomocí GitHub Actions

Použijte Bicep

Referenční architektura obsahuje dva hlavní pracovní postupy:

1. Jednotkové testy Bicep

   Tento pracovní postup běží při každém commitu a skládá se ze sady jednotkových testů na infrastrukturním kódu. Spustí příkaz bicep build pro kompilaci bicep do šablony ARM. Tím se zajistí, že nedojde k žádným chybám formátování. Dále provede ověření , aby se zajistilo, že je šablona nasaditelná. A konečně checkov, open-source nástroj pro statickou analýzu kódu pro IaC, se spustí, aby odhalil problémy se zabezpečením a shodou s předpisy. Pokud úložiště využívá GitHub Advanced Security (GHAS), výsledky se nahrají na GitHub.

2. Bicep What-If / Nasazení

   Tento pracovní postup se spouští při každém pull requestu a při každém commitu do hlavní větve. Co kdyby fáze pracovního postupu se používá k pochopení dopadu změn IaC na prostředí Azure spuštěním what-if. Tato zpráva je pak připojena k žádosti o přijetí změn (pull request), aby bylo možné ji snadno a přehledně zkontrolovat. Fáze nasazení se spustí po analýze citlivostní analýzy, když se pracovní postup aktivuje vložením do hlavní větve. Tato fáze nasadí šablonu do Azure po odhlášení ruční kontroly.

Použití Terraformu

Referenční architektura obsahuje tři hlavní pracovní postupy:

1. Testy jednotek Terraformu

   Tento pracovní postup se spouští při každém potvrzení a skládá se ze sady jednotkových testů v kódu infrastruktury. Spustí terraform fmt , aby se zajistilo, že kód je správně formátovaný a dodržuje osvědčené praktiky Terraformu. Dále provede terraform ověření a zkontroluje, jestli je kód syntakticky správný a interně konzistentní. A konečně checkov, open-source nástroj pro statickou analýzu kódu pro IaC, se spustí, aby zjistil problémy se zabezpečením a dodržováním předpisů. Pokud úložiště využívá GitHub Advanced Security (GHAS), výsledky se nahrají na GitHub.

2. Terraform – plán / aplikovat

   Tento pracovní postup se spouští při každém pull requestu a při každém commitu do hlavní větve. Fáze plánování pracovního postupu se používá k pochopení dopadu změn IaC na prostředí Azure spuštěním terraform plan. Tato zpráva je pak připojena k žádosti o přijetí změn (pull request), aby bylo možné ji snadno a přehledně zkontrolovat. Fáze aplikace se spustí po fázi plánování, když je pracovní postup aktivován push do hlavní větve. Tato fáze vezme dokument plánu a použije změny poté, co manuální kontrola schválí, jestliže v prostředí čekají nějaké změny.

3. Detekce odchylek Terraformu

   Tento pracovní postup se pravidelně spouští, aby prohledal vaše prostředí kvůli jakémukoliv odklonu od původní konfigurace nebo změnám provedeným mimo Terraform. Pokud se zjistí nějaký posun, vytvoří se GitHub issue, který upozorní správce projektu.

Související zdroje informací

• Co je infrastruktura jako kód
• Opakovatelná infrastruktura
• Porovnání Terraformu a Bicep
• Checkov a zdrojový kód
• Pokročilé zabezpečení GitHubu