Upravit

CI/CD pro aplikace AKS pomocí GitHub Actions a GitFlowu

Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Monitor
Azure Pipelines

GitOps je provozní model pro aplikace nativní pro cloud, které ukládají kód aplikace a deklarativní infrastruktury v Gitu, který se použije jako zdroj pravdy pro automatizované průběžné doručování. Pomocí GitOps popíšete požadovaný stav celého systému v úložišti Git a operátor GitOps ho nasadí do vašeho prostředí, což je často cluster Kubernetes. Další informace o GitOps pro Kubernetes v Azure najdete v GitOps pro služby Azure Kubernetes Service nebo disciplínách CI/CD a GitOps s podporou Azure Arc Kubernetes.

Ukázkový scénář v tomto článku platí pro firmy, které chtějí modernizovat kompletní vývoj aplikací pomocí kontejnerů, kontinuální integrace (CI) pro sestavování a GitOps pro průběžné nasazování (CD). V tomto scénáři se jako příklad používá aplikace Flask. Tato webová aplikace se skládá z front-endu napsaného pomocí Pythonu a architektury Flask.

Architektura

Následující možnosti prozkoumávají přístupy CI/CD založené na nabízených oznámeních a vyžádání obsahu.

Možnost 1: Ci/CD založené na nabízených oznámeních

Diagram of the push-based architecture with GitHub Actions.

Architektura založená na nabízených oznámeních s GitHub Actions pro CI a CD

Stáhněte si soubor aplikace Visio s touto architekturou.

Tok dat

Tento scénář se zabývá kanálem DevOps založeným na nabízení pro dvouvrstvou webovou aplikaci s front-endovou webovou komponentou a back-endem, který používá Redis. Tento kanál používá GitHub Actions k sestavení a nasazení. Data procházejí tímto scénářem:

  1. Kód aplikace se vyvíjí.
  2. Kód aplikace se zavazuje do úložiště GitHub.
  3. GitHub Actions sestaví image kontejneru z kódu aplikace a nasdílí image kontejneru do služby Azure Container Registry.
  4. Úloha GitHub Actions nasadí nebo odešle aplikaci, jak je popsáno v souborech manifestu, do clusteru Azure Kubernetes Service (AKS) pomocí kubectl nebo akce nasazení do clusteru Kubernetes.

Možnost 2: CI/CD na základě změn (GitOps)

Diagram of the pull-based architecture with GitHub Actions and Argo CD.

Architektura založená na vyžádání obsahu s GitHub Actions pro CI a Argo CD pro CD

Stáhněte si soubor aplikace Visio s touto architekturou.

Tok dat

Tento scénář se zabývá kanálem DevOps založeným na vyžádání obsahu pro dvouvrstvou webovou aplikaci s front-endovou webovou komponentou a back-endem, který používá Redis. Tento kanál používá k sestavení GitHub Actions. Pro nasazení používá Jako operátor GitOps cd Argo k vyžádání nebo synchronizaci aplikace. Data procházejí tímto scénářem:

  1. Kód aplikace se vyvíjí.
  2. Kód aplikace se potvrdí do úložiště GitHub.
  3. GitHub Actions sestaví image kontejneru z kódu aplikace a nasdílí image kontejneru do služby Azure Container Registry.
  4. GitHub Actions aktualizuje soubor nasazení manifestu Kubernetes s aktuální verzí image na základě čísla verze image kontejneru ve službě Azure Container Registry.
  5. Argo CD se synchronizuje s úložištěm Git nebo se z tohoto úložiště načítá.
  6. Argo CD nasadí aplikaci do clusteru AKS.

Komponenty

  • GitHub Actions je řešení automatizace, které se dá integrovat se službami Azure pro kontinuální integraci (CI). V tomto scénáři GitHub Actions orchestruje vytváření nových imagí kontejnerů na základě potvrzení do správy zdrojového kódu, odešle tyto image do služby Azure Container Registry a pak aktualizuje soubory manifestu Kubernetes v úložišti GitHub.
  • Azure Kubernetes Service (AKS) je spravovaná platforma Kubernetes, která umožňuje nasazovat a spravovat kontejnerizované aplikace bez odborných znalostí orchestrace kontejnerů. Jako hostovaná služba Kubernetes se za vás Azure stará o důležité úlohy, jako je monitorování stavu a údržba.
  • Azure Container Registry ukládá a spravuje image kontejnerů používané clusterem AKS. Image jsou bezpečně uložené a je možné je replikovat do jiných oblastí platformou Azure, aby se urychlila doba nasazení.
  • GitHub je webový systém správy zdrojového kódu, který běží na Gitu a používá ho vývojáři k ukládání a verzi kódu aplikace. V tomto scénáři se GitHub používá k ukládání zdrojového kódu v úložišti Git a pak se GitHub Actions používá k sestavení a nasdílení image kontejneru do služby Azure Container Registry v přístupu založeném na nabízených oznámeních.
  • Argo CD je opensourcový operátor GitOps, který se integruje s GitHubem a AKS. Argo CD podporuje průběžné nasazování (CD). Flux by se pro tento účel mohl použít, ale Argo CD předvádí, jak tým aplikace může zvolit samostatný nástroj pro konkrétní aspekty životního cyklu aplikace v porovnání s použitím stejného nástroje, který používají operátoři clusteru ke správě clusteru.
  • Azure Monitor pomáhá sledovat výkon, udržovat zabezpečení a identifikovat trendy. Metriky získané službou Azure Monitor můžou používat jiné prostředky a nástroje, jako je Grafana.

Alternativy

  • Azure Pipelines pomáhá implementovat CI/DC a testovací kanál pro libovolnou aplikaci.
  • Jenkins je opensourcový automatizační server, který se dá integrovat se službami Azure pro CI/CD.
  • Flux je možné využít jako operátor GitOps. Může provádět stejné úlohy jako Argo CD a funguje stejným způsobem s AKS.

Podrobnosti scénáře

V tomto scénáři používá automatizované sestavení a nasazení vaší aplikace několik technologií. Tento kód se vyvíjí ve VS Code a ukládá se v úložišti GitHub. GitHub Actions se používá k sestavení aplikace jako kontejneru a následné nasdílení image kontejneru do služby Azure Container Registry. GitHub Actions se používá k aktualizaci potřebného souboru nasazení manifestu Kubernetes, který je také uložený v úložišti Git, zatímco operátor GitOps Argo CD vybere soubory manifestu Kubernetes odtud a nasadí aplikaci do clusteru AKS.

Mezi další příklady patří poskytování automatizovaného vývojového prostředí, ověřování nových potvrzení kódu a nabízení nových nasazení do přípravného nebo produkčního prostředí. Podniky tradičně musely ručně vytvářet a kompilovat aplikace a aktualizace a udržovat velký monolitický základ kódu. Díky modernímu přístupu k vývoji aplikací, který používá CI a GitOps pro CD, můžete rychle vytvářet, testovat a nasazovat služby. Tento moderní přístup umožňuje rychleji vydávat aplikace a aktualizace pro vaše zákazníky a reagovat na změny obchodních požadavků a agilnějším způsobem.

Pomocí služeb Azure a GitHubu, jako jsou AKS, Container Registry, GitHub a GitHub Actions, můžou společnosti využívat nejnovější techniky a nástroje pro vývoj aplikací ke zjednodušení procesu implementace vysoké dostupnosti. Společnosti také zjednodušují nasazení a vynucují požadovaný stav aplikací pomocí opensourcových technologií, jako je Flux nebo Argo CD pro GitOps.

Potenciální případy použití

Mezi další relevantní případy použití patří:

  • Modernizace postupů vývoje aplikací pomocí mikroslužeb, přístupu založeného na kontejnerech.
  • Urychlíte životní cyklus vývoje a nasazení aplikací.
  • Automatizujte nasazení pro testování nebo přijetí prostředí pro ověření.
  • Zajistěte konfigurace a požadovaný stav aplikace.
  • Automatizace správy životního cyklu clusteru

Možnosti CI/CD

Tento dokument ukazuje použití GitOps pro moderní přístup ke zpracování průběžného nasazování v kanálu CI/CD. Každá organizace se ale liší. Při nasazování aplikací do clusterů Kubernetes prostřednictvím automatizovaných kanálů doručování je důležité pochopit různé způsoby, jak je možné je provést.

Dvě nejběžnější možnosti CI/CD pro nasazení aplikace do clusteru AKS jsou založené na nabízených oznámeních a vyžádání obsahu. Možnost nabízení využívá GitHub Actions k průběžnému nasazování a možnost vyžádané replikace využívá GitOps pro průběžné nasazování.

Možnost 1: Architektura založená na nabízených oznámeních s GitHub Actions pro CI a CD

V tomto přístupu kód začíná částí CI kanálu, která funguje tak, aby se změny odesílaly jako nasazení do clusteru Kubernetes. Nasazení jsou založená na triggeru. Existují různé triggery, které můžou spustit nasazení, například potvrzení do úložiště nebo trigger z jiného kanálu CI. Díky tomuto přístupu má systém kanálu přístup ke clusteru Kubernetes. Modul založený na nabízení je nejběžnějším modelem, který dnes používají nástroje CI/CD.

Důvody použití přístupu založeného na nabízených oznámeních:

  • Flexibilita: Většina operátorů GitOps aktuálně běží jenom v Kubernetes. Pokud vaše organizace chce nasadit aplikace na cokoli jiného než Kubernetes, budete ji muset odeslat do tohoto prostředí prostřednictvím jiných nástrojů CI/CD, jako je GitHub Actions.

  • Efektivita: Standardizovaný přístup k nasazení nativních cloudových a tradičních aplikací je efektivnější. GitOps je v současné době nejvhodnější pro aplikace nativní pro cloud, které běží v Kubernetes.

  • Jednoduchost: Technologie CI/CD založená na nabízených oznámeních je dobře známá mezi nejširší sadou techniků v mnoha organizacích. Přístup založený na nabízených oznámeních může být jednodušší než kombinace přístupů CI/CD založených na nabízení a vyžádání obsahu.

  • Struktura: Aktuální struktura úložiště používaná pro vaši aplikaci nemusí být vhodná pro GitOps, což znamená, že pro GitOps by bylo nutné provést významné plánování a restrukturalizaci.

Možnost 2: Architektura založená na vyžádání obsahu s GitHub Actions pro CI a operátora GitOps Argo CD pro CD

Tento přístup se zaměřuje na použití jakýchkoli změn v clusteru Kubernetes. Cluster Kubernetes zahrnuje operátora, který prohledá úložiště Git pro požadovaný stav clusteru, vyzvedne a použije všechny změny, které je potřeba provést. V tomto modelu nemá žádný externí klient přihlašovací údaje na úrovni správce ke clusteru Kubernetes. Model pro vyžádání obsahu není nový, ale nástroje CI/CD ho široce nepoužívají. V nedávné době, s uvedením GitOps, model pro vyžádání změn získal přijetí. Řada organizací využívá GitOps k usnadnění průběžného nasazování v kanálech CD/CD.

Důvody použití přístupu založeného na přijetí změn:

  • Konzistence: S GitOps operátor porovnává stav clusterů Kubernetes s požadovaným stavem konfigurace a aplikací v úložišti Git. Pokud dojde k nějakému posunu konfigurace nebo aplikací, operátor GitOps automaticky přenese cluster Kubernetes do požadovaného stavu.

  • Zabezpečení: Přístup založený na vyžádání obsahu ci/CD s GitOps umožňuje přesunout přihlašovací údaje zabezpečení do clusteru Kubernetes, což snižuje zabezpečení a riziko tím, že odebere přihlašovací údaje, aby se ukládaly do externích nástrojů CI. Budete také moct omezit povolená příchozí připojení a omezit přístup na úrovni správce ke clusterům Kubernetes.

  • Správa verzí: Vzhledem k tomu, že GitOps využívá úložiště Git jako zdroj pravdy, průběžné nasazování má ze své podstaty možnosti správy verzí, vrácení zpět a auditu.

  • Víceklientská architektura: Přístup založený na vyžádání s GitOps je vhodný pro distribuované týmy a více tenantů. GitOps umožňuje využívat samostatná úložiště Git, samostatná přístupová práva a distribuovat nasazení mezi různé obory názvů.

  • Nativní pro cloud: Další aplikace se modernizují nebo vytvářejí tak, aby byly nativní pro cloud. Pro jakoukoli organizaci, která má většinu svých aplikací spuštěných v Kubernetes, je použití operátoru GitOps pro průběžné nasazování jednodušší a efektivnější než tradiční přístup založený na nabízení do CI/CD.

Důležité informace

Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které je možné použít ke zlepšení kvality úlohy. Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.

Spolehlivost

Spolehlivost zajišťuje, že vaše aplikace může splňovat závazky, které uděláte pro vaše zákazníky. Další informace najdete v tématu Přehled pilíře spolehlivosti.

K monitorování výkonu aplikace a hlášení problémů tento scénář využívá Azure Monitor. Umožňuje monitorovat a řešit problémy s výkonem, které můžou vyžadovat aktualizace kódu, které je pak možné nasadit pomocí kanálu CI/CD.

V rámci clusteru AKS distribuuje nástroj pro vyrovnávání zatížení provoz aplikací do jednoho nebo více kontejnerů nebo podů, na kterých běží vaše aplikace. Tento přístup ke spouštění kontejnerizovaných aplikací v Kubernetes poskytuje zákazníkům vysoce dostupnou infrastrukturu.

Poznámka:

Tento článek přímo neřeší vysokou dostupnost kanálu CI/CD. Další informace najdete v tématu Vysoká dostupnost pro GitHub Actions a Cd Deklarativní GitOps CD Argo pro Kubernetes.

Komponenty odolnosti jsou integrované do Kubernetes. Tyto komponenty monitorují a restartují kontejnery nebo pody, pokud dojde k problému. Když se zkombinuje několik uzlů Kubernetes, může vaše aplikace tolerovat nedostupnost podu nebo uzlu.

Obecné pokyny k návrhu odolných řešení najdete v tématu Navrhování spolehlivých aplikací Azure.

Zabezpečení

Zabezpečení poskytuje záruky proti záměrným útokům a zneužití cenných dat a systémů. Další informace najdete v tématu Přehled pilíře zabezpečení.

Pro oddělení přihlašovacích údajů a oprávnění tento scénář používá vyhrazený instanční objekt Microsoft Entra. Přihlašovací údaje pro tento instanční objekt se ukládají jako zabezpečený objekt přihlašovacích údajů na GitHubu, jako tajné kódy GitHub Actions, aby nebyly přímo vystavené a viditelné ve skriptech nebo v kanálu sestavení.

Obecné pokyny k zabezpečení aplikací v clusterech AKS najdete v tématu Koncepty zabezpečení pro aplikace a clustery v AKS.

Pokud jde o oddělení obav, pokyny slouží k oddělení výpočetních prostředků, které spouští obchodní aplikaci od agentů CD nebo operátora GitOps, spuštěním obchodní aplikace a operátorem GitOps v samostatných oborech názvů v clusteru Kubernetes. Pro další oddělení obav je možné operátora GitOps spustit v clusteru Kubernetes, který je vyhrazený pro instanci GitOps odděleně od produkčního clusteru Kubernetes, na kterém běží obchodní aplikace.

Poznámka:

Tento článek se přímo nezabývá zabezpečením kanálu CI/CD.

Efektivita výkonu

Efektivita výkonu je schopnost úlohy škálovat se tak, aby efektivním způsobem splňovala požadavky, které na ni kladou uživatelé. Další informace najdete v tématu Přehled pilíře efektivity výkonu.

AKS umožňuje škálovat počet uzlů clusteru tak, aby splňoval požadavky vašich aplikací. S rostoucím počtem aplikací můžete vertikálně navýšit počet uzlů Kubernetes, na kterých běží vaše služba.

Díky GitHub Actions poskytovatel cloudu automaticky škáluje počet spouštěčů. Pokud se používají spouštěče v místním prostředí, bude hostitel spouštěče zodpovědný za jejich škálování podle potřeby.

Další témata týkající se škálovatelnosti najdete v kontrolním seznamu k efektivitě výkonu.

Nasazení tohoto scénáře

Pokud chcete scénář nasadit, postupujte podle kroků v referenční implementaci automatizace AKS podle směrného plánu. Úložiště referenční implementace obsahuje průvodce průvodcem pro scénář CI/CD založený na nabízených oznámeních i scénář CI/CD (GitOps).

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autoři:

Další přispěvatelé:

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

Tento scénář použil Službu Azure Container Registry a AKS k ukládání a spouštění aplikace založené na kontejnerech. Azure Container Apps nebo Azure Container Instances je také možné použít ke spouštění aplikací založených na kontejnerech, aniž by bylo nutné zřizovat žádné součásti orchestrace. Další informace najdete v přehledu služby Azure Container Instances a přehledu služby Azure Container Apps.

Dokumentace k produktu:

Moduly Microsoft Learn: