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 infrastrukturu a proces nasazení v kódu, můžete ho zkontrolovat a zkontrolovat pomocí 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.

Architektura

Tok dat

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í analýza citlivostní analýzy Terraformu nebo Bicep, která vygeneruje náhled změn, ke kterým dojde ve vašem prostředí Azure.
4. Po odpovídajícím posouzení je možné žádost o přijetí změn 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žití 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 pokynů vytvořte prostředí s názvemproduction. production V prostředí nastavte pravidlo ochrany a přidejte všechny požadované schvalovatele, které chcete, aby se při produkčních nasazeních musely odhlásit. Prostředí můžete také omezit na hlavní větev. Podrobné pokyny najdete tady.

2. Nastavení identity Azure:

   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 Připojení (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 název prostředí a použijte ho production .
   • Nastavte typ entity na Pull Request.
   • Nastavte typ entity na Branch název větve a použijte ho 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 bude potřeba aktualizovat s vybraným umístěním úložiště (tady najdete dokumentaci).

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 pokynů vytvořte prostředí s názvemproduction. 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í identity Azure:

   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 tak, aby GitHub mohl využívat identitu pomocí OpenID Připojení (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:

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

   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.
   • Branch Nastavte Entity Type a použijte main název větve.

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.

   Pomocí identity vytvořte v úložišti následující tajné kódy 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 v prostředí další tajný klíč production pomocí read-write identity:

   • 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í s využitím GitHub Actions

Použití Bicep

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

1. Testy jednotek Bicep

   Tento pracovní postup běží na každém potvrzení a skládá se ze sady testů jednotek v kódu infrastruktury. Spustí sestavení bicep 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, opensourcový nástroj pro analýzu statického 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. Bicep What-If / Deploy

   Tento pracovní postup běží na všech žádostech o přijetí změn a na každém potvrzení do hlavní větve. Fáze citlivostní fáze pracovního postupu se používá k pochopení dopadu změn IaC na prostředí Azure spuštěním citlivostní akce. Tato sestava se pak připojí k žádosti o přijetí změn, abyste ji mohli snadno 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 běží na každém potvrzení a skládá se ze sady testů jednotek v kódu infrastruktury. Spustí terraform fmt, aby se zajistilo, že kód je správně lintovaný a dodržuje osvědčené postupy terraformu. Dále provede terraform ověření a zkontroluje, jestli je kód syntakticky správný a interně konzistentní. A konečně, checkov, opensourcový nástroj pro analýzu statického 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 / použít

   Tento pracovní postup běží na všech žádostech o přijetí změn a na každém potvrzení do hlavní větve. Fáze plánu pracovního postupu se používá k pochopení dopadu změn IaC na prostředí Azure spuštěním plánu terraformu. Tato sestava se pak připojí k žádosti o přijetí změn, abyste ji mohli snadno zkontrolovat. Fáze apply se spustí po plánu, když se pracovní postup aktivuje vložením do hlavní větve. Tato fáze vezme dokument plánu a použije změny poté, co se ruční kontrola odhlásí, pokud dojde k nějakým čekajícími změnám prostředí.

3. Detekce odchylek Terraformu

   Tento pracovní postup se pravidelně spouští, aby kontroloval vaše prostředí, jestli se nekonfiguruje žádná změna konfigurace nebo změny provedené mimo Terraform. Pokud se zjistí nějaký posun, vyvolá se problém GitHubu, který upozorní správce projektu.

Související prostředky

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