Sdílet prostřednictvím

Pracovní postup CI/CD s využitím GitOps (Flux v2)

Moderní nasazení Kubernetes obsahují více aplikací, clusterů a prostředí. Pomocí GitOps můžete snadněji spravovat tato složitá nastavení a sledovat požadovaný stav prostředí Kubernetes deklarativně pomocí Gitu. Pomocí běžných nástrojů Gitu můžete deklarovat stav clusteru, zvýšit odpovědnost, usnadnit šetření chyb a umožnit automatizaci pro správu prostředí.

Tento článek popisuje, jak GitOps zapadá do celého životního cyklu změn aplikací pomocí Azure Arc, Azure Repos a Azure Pipelines. Poskytuje také příklad jedné změny aplikace na prostředí Kubernetes řízená GitOps.

Architektura

Tento diagram znázorňuje pracovní postup CI/CD pro aplikaci nasazenou do jednoho nebo více prostředí Kubernetes.

Diagram znázorňující architekturu CI/CD GitOps

Pokud si chcete stáhnout diagramy architektury ve vysokém rozlišení, navštivte Jumpstart Gems.

Úložiště kódu aplikace

Úložiště aplikací obsahuje kód aplikace, se kterým vývojáři pracují a iterují během svého vývojového cyklu. Šablony nasazení aplikace jsou v tomto úložišti v obecné podobě, například Helm nebo Kustomize. Hodnoty specifické pro prostředí se v úložišti neukládají.

Změny v tomto úložišti vyvolávají žádost o přijetí změn nebo CI kanál, který spouští proces nasazení.

Registr kontejneru

Registr kontejneru obsahuje všechny image první a třetí strany používané v prostředích Kubernetes. Obrázky aplikací první strany jsou označené značkami, které jsou čitelné pro člověka, a Git commitem použitým k vytvoření obrázku. Image třetích stran se můžou ukládat do mezipaměti, aby pomohly se zabezpečením, rychlostí a odolností. Nastavte plán pro včasné testování a integraci aktualizací zabezpečení.

Další informace najdete v tématu Jak využívat a udržovat veřejný obsah pomocí úloh služby Azure Container Registry.

Kanál žádosti o přijetí změn

Žádosti o změny od vývojářů provedené v úložišti aplikace jsou podmíněné na úspěšném spuštění procesního kanálu PR. Tento kanál spouští základní brány kvality, jako je lintování a testy jednotek v kódu aplikace. Řetězec závislostí testuje aplikaci a provádí kontrolu Dockerfile a šablon Helm, které jsou používány pro nasazení do prostředí Kubernetes. Image Dockeru by se měly sestavit a testovat, ale neměly by se nasdílet. Udržujte dobu trvání potrubí relativně krátkou, aby umožnila rychlou iteraci.

Kanál CI

Kanál CI aplikace spouští všechny kroky kanálu žádosti o přijetí změn a rozšiřuje kontroly testování a nasazení. Potrubí lze spustit pro každý commit do hlavní větve, nebo může běžet pravidelně s skupinou commitů.

V této fázi je možné provádět testy aplikace, které jsou pro PR proces příliš náročné, včetně:

  • Odesílání obrázků do registra kontejnerů
  • Vytváření, lintování a testování obrázků
  • Generování nezpracovaných souborů YAML šablon

Na konci sestavení CI se vygenerují artefakty. Tyto artefakty je možné použít v kroku CD ke zpracování při přípravě na nasazení.

Rozšíření clusteru Flux

Flux je agent, který běží v každém clusteru jako rozšíření clusteru. Toto rozšíření clusteru Flux zodpovídá za udržování požadovaného stavu. Agent se dotazuje úložiště GitOps v uživatelem definovaném intervalu a pak sladí stav clusteru se stavem deklarovaným v Git úložišti.

Další informace najdete v tématu Kurz: Nasazení aplikací pomocí GitOps s flux v2.

Kanál CD

CD pipeline je automaticky spuštěn při úspěšných sestaveních CI. V tomto prostředí kanálu se hodnoty specifické pro dané prostředí nahradí dříve zveřejněnými šablonami a v úložišti GitOps je vytvořen nový pull request s těmito hodnotami. Tato žádost o přijetí změn obsahuje navrhované změny požadovaného stavu jednoho nebo více clusterů Kubernetes. Správci clusteru kontrolují žádost o přijetí změn a schvalují sloučení do úložiště GitOps. Pipeline čeká na sloučení pull requestu, po kterém Flux synchronizuje a aplikuje změny stavu.

Úložiště GitOps

Úložiště GitOps představuje aktuální požadovaný stav všech prostředí napříč clustery. Jakékoli změny v tomto úložišti přebírá služba Flux v každém clusteru a nasadí je. Změny požadovaného stavu clusterů se zobrazí jako žádosti o přijetí změn, které se pak zkontrolují a nakonec se sloučí po schválení změn. Tyto pull requesty obsahují změny šablon nasazení a vygenerované manifesty Kubernetes. Vykreslené manifesty nízké úrovně umožňují pečlivější kontrolu změn, které obvykle nevidíte na úrovni šablony.

Konektor GitOps

Konektor GitOps vytvoří připojení mezi agentem Flux a kanálem úložiště GitOps/CD. Když se změny použijí v clusteru, Flux upozorní konektor GitOps na každou změnu fáze a kontrolu stavu. Tato komponenta slouží jako adaptér. Rozumí tomu, jak komunikovat s úložištěm Git a aktualizuje stav potvrzení Gitu, aby průběh synchronizace byl viditelný v úložišti GitOps. Po dokončení nasazení (bez ohledu na to, zda je úspěšné nebo neúspěšné) konektor upozorní kanál CD, aby mohl pokračovat a provádět aktivity po nasazení, jako je testování integrace.

Kubernetes klastry

Alespoň jeden cluster Kubernetes s podporou Azure Arc nebo Azure Kubernetes Service (AKS) obsluhuje různá prostředí potřebná aplikací. Například jeden cluster může sloužit jak pro vývojové, tak pro kontrolní prostředí pomocí různých namespaces. Druhý cluster může poskytovat snadnější oddělení prostředí a jemněji odstupňované řízení.

Ukázkový pracovní postup

Jako vývojář aplikací Alice:

  • Zapíše kód aplikace.
  • Určuje způsob spuštění aplikace v kontejneru Dockeru.
  • Definuje šablony, které spouští kontejner a závislé služby v clusteru Kubernetes.

Alice chce zajistit, aby aplikace mohla běžet ve více prostředích, ale nezná konkrétní nastavení pro každé prostředí.

Předpokládejme, že Alice chce provést změnu aplikace, která změní image Dockeru použitou v šabloně nasazení aplikace.

  1. Alice změní šablonu nasazení, odešle ji do vzdálené větve pojmenované alice v úložišti aplikace a otevře požadavek na sloučení pro kontrolu vůči větvi main.

  2. Alice požádá svůj tým, aby změnu zkontroloval.

    • Kanál žádosti o přijetí změn spouští ověření.
    • Po úspěšném spuštění pipeline pro žádosti o přijetí změn a schválení týmem je změna sloučena.

  3. Kanál CI se pak spustí a ověří změnu Alice a úspěšně se dokončí.

    • Změna je bezpečná pro nasazení do clusteru a artefakty se ukládají v běhu CI kanálu.

  4. Úspěšné spuštění kanálu CI aktivuje kanál CD.

    • Kanál CD přebírá artefakty uložené během spuštění Aliceina kanálu CI.
    • Kanál CD nahradí šablony hodnotami specifickými pro prostředí a připraví všechny změny proti existujícímu stavu clusteru v úložišti GitOps.
    • Kanál CD vytvoří pull request proti produkční větvi repozitáře GitOps s požadovanými změnami stavu clusteru.

  5. Tým Alice zkontroluje a schválí její žádost o přijetí změn.

    • Změna je začleněna do cílové větve, která odpovídá danému prostředí.

  6. Během několika minut si Flux všimne změny v úložišti GitOps a stáhne Alicinu změnu.

  7. Kanál CD spouští automatizované testy, které ověřují, že nové nasazení bylo úspěšně dokončeno a systém funguje podle očekávání.

    Poznámka:

    V případě dalších prostředí cílených na nasazení opakuje CI/CD kanál proces vytvořením pull requestu pro další prostředí a zopakuje kroky 4 až 7. Proces může vyžadovat dodatečné schválení pro riziková nasazení nebo prostředí, například změnu související se zabezpečením nebo produkční prostředí.

  8. Když všechna prostředí obdržela úspěšná nasazení, pipeline je dokončen.

Další kroky

  • Last updated on