CI/CD for AKS-alkalmazások a GitHub Actions és a GitFlow használatával

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

A GitOps olyan natív felhőbeli alkalmazások üzemeltetési modellje, amely a Gitben tárolja az alkalmazás- és deklaratív infrastruktúra-kódot, hogy az automatikus folyamatos teljesítés igazságforrásaként szolgáljon. A GitOps segítségével a teljes rendszer kívánt állapotát írja le egy Git-adattárban, és egy GitOps-operátor telepíti azt a környezetbe, amely gyakran Egy Kubernetes-fürt. Az Azure-beli GitOps for Kubernetes szolgáltatással kapcsolatos további információkért látogasson el az Azure Kubernetes Service-hez készült GitOps- vagy CI/CD- és GitOps-diszciplínákhoz az Azure Arc-kompatibilis Kubernetes szolgáltatással.

A jelen cikkben szereplő példaforgatókönyv azokra a vállalatokra vonatkozik, amelyek tárolók, folyamatos integráció (CI) használatával szeretnék modernizálni a végpontok közötti alkalmazásfejlesztést a buildeléshez, valamint a GitOps a folyamatos üzembe helyezéshez (CD). Ebben a forgatókönyvben egy Flask-alkalmazást használunk példaként. Ez a webalkalmazás egy Pythonnal és a Flask-keretrendszerrel írt előtérből áll.

Felépítés

Az alábbi lehetőségek a leküldéses és a lekéréses alapú CI/CD megközelítéseket ismertetik.

1. lehetőség: Leküldéses ci/CD

Diagram of the push-based architecture with GitHub Actions.

Push-alapú architektúra a GitHub Actions for CI és CD használatával.

Töltse le az architektúra Visio-fájlját.

Adatfolyam

Ez a forgatókönyv egy leküldéses devOps-folyamatot fed le egy kétrétegű webalkalmazáshoz, egy előtér-webösszetevővel és egy Redist használó háttérrendszerrel. Ez a folyamat a GitHub Actionst használja a buildeléshez és az üzembe helyezéshez. Az adatok az alábbiak szerint haladnak végig a forgatókönyvön:

  1. Az alkalmazáskód fejlesztésre kerül.
  2. Az alkalmazáskód egy GitHub Git-adattárhoz van lekötve.
  3. A GitHub Actions létrehoz egy tárolórendszerképet az alkalmazáskódból, és leküldi a tárolórendszerképet az Azure Container Registrybe.
  4. Egy GitHub Actions-feladat üzembe helyezi vagy leküldi az alkalmazást a jegyzékfájlokban leírtak szerint az Azure Kubernetes Service -fürtbe a Kubectl vagy a Deploy to Kubernetes fürtművelet használatával.

2. lehetőség: Lekéréses alapú CI/CD (GitOps)

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

Pull-alapú architektúra a GitHub Actions for CI és a CD-hez készült Argo CD használatával.

Töltse le az architektúra Visio-fájlját.

Adatfolyam

Ez a forgatókönyv egy lekéréses alapú DevOps-folyamatot fed le egy kétrétegű webalkalmazáshoz, egy előtérbeli webösszetevővel és egy Redist használó háttérrendszerrel. Ez a folyamat a GitHub Actionst használja a buildeléshez. Az üzembe helyezéshez az Argo CD-t használja GitOps-operátorként az alkalmazás lekéréséhez/szinkronizálásához. Az adatok az alábbiak szerint haladnak végig a forgatókönyvön:

  1. Az alkalmazáskód fejlesztésre kerül.
  2. Az alkalmazáskód egy GitHub-adattárhoz van lekötve.
  3. A GitHub Actions létrehoz egy tárolórendszerképet az alkalmazáskódból, és leküldi a tárolórendszerképet az Azure Container Registrybe.
  4. A GitHub Actions frissíti a Kubernetes-jegyzék üzembehelyezési fájlját az aktuális rendszerkép-verzióval az Azure Container Registry tárolólemezképének verziószáma alapján.
  5. Az Argo CD szinkronizálja vagy lekéri a Git-adattárat.
  6. Az Argo CD üzembe helyezi az alkalmazást az AKS-fürtön.

Összetevők

  • A GitHub Actions egy automatizálási megoldás, amely integrálható az Azure-szolgáltatásokkal a folyamatos integráció (CI) érdekében. Ebben a forgatókönyvben a GitHub Actions vezényli az új tárolólemezképek létrehozását a forráskövetési véglegesítések alapján, leküldi ezeket a lemezképeket az Azure Container Registrybe, majd frissíti a Kubernetes-jegyzékfájlokat a GitHub-adattárban.
  • Az Azure Kubernetes Service (AKS) egy felügyelt Kubernetes-platform, amellyel tárolóalapú alkalmazásokat helyezhet üzembe és kezelhet tárolóvezénylési szakértelem nélkül. Üzemeltetett Kubernetes-szolgáltatásként az Azure olyan fontos műveleteket bonyolít le, mint az állapotmonitorozás és a karbantartás.
  • Az Azure Container Registry tárolja és kezeli az AKS-fürt által használt tárolórendszerképeket. A rendszerképek biztonságosan vannak tárolva, és az Azure-platform más régiókba replikálva felgyorsíthatja az üzembe helyezési időket.
  • A GitHub egy webalapú forrásvezérlő rendszer, amely a Giten fut, és a fejlesztők használják az alkalmazáskód tárolására és verziójára. Ebben a forgatókönyvben a GitHub a forráskód Git-adattárban való tárolására szolgál, majd a GitHub Actions használatával leküldéses megközelítéssel készíti el és küldi le a tárolólemezképet az Azure Container Registrybe.
  • Az Argo CD egy nyílt forráskódú GitOps-operátor, amely integrálható a GitHubbal és az AKS-sel. Az Argo CD támogatja a folyamatos üzembe helyezést (CD). Erre a célra használhatták volna a Fluxot, de az Argo CD bemutatja, hogy az alkalmazáscsapatok hogyan választhatnak külön eszközt az alkalmazás életciklusával kapcsolatos problémáikhoz, összehasonlítva azzal az eszközzel, amelyet a fürtüzemeltetők a fürtkezeléshez használnak.
  • Az Azure Monitor segít nyomon követni a teljesítményt, fenntartani a biztonságot és azonosítani a trendeket. Az Azure Monitor által beszerzett metrikákat más erőforrások és eszközök, például a Grafana is használhatja.

Alternatívák

  • Az Azure Pipelines segít implementálni egy CI/DC-t és egy tesztfolyamatot bármely alkalmazáshoz.
  • A Jenkins egy nyílt forráskódú automatizálási kiszolgáló, amely integrálható a CI/CD-hez készült Azure-szolgáltatásokkal.
  • A Flux gitOps-operátorként használható. Ugyanazokat a feladatokat hajthatja végre, mint az Argo CD, és ugyanúgy működik az AKS-sel.

Forgatókönyv részletei

Ebben a forgatókönyvben az alkalmazás automatikus buildelése és üzembe helyezése több technológiát használ. A kódot a VS Code fejleszti, és egy GitHub-adattárban tárolja. A GitHub Actions használatával tárolóként hozhatja létre az alkalmazást, majd leküldi a tárolórendszerképet egy Azure Container Registrybe. A GitHub Actions a Szükséges Kubernetes-jegyzéktelepítési fájl frissítésére szolgál, amelyet szintén a Git-adattárban tárolnak, míg a GitOps operátor Argo CD-je onnan veszi fel a Kubernetes-jegyzékfájlokat, és telepíti az alkalmazást az AKS-fürtön.

Ilyen például az automatizált fejlesztési környezet biztosítása, az új kód véglegesítéseinek érvényesítése, valamint az új üzembe helyezések átmeneti vagy éles környezetekbe való leküldése. A vállalatoknak hagyományosan manuálisan kellett létrehozniuk és lefordítani az alkalmazásokat és frissítéseket, és nagy, monolitikus kódbázist kellett fenntartaniuk. A CD-hez készült CI-t és GitOps-t használó alkalmazásfejlesztés modern megközelítésével gyorsan létrehozhat, tesztelhet és üzembe helyezhet szolgáltatásokat. Ez a modern megközelítés lehetővé teszi alkalmazások és frissítések gyorsabb kiadását az ügyfelek számára, és rugalmasabban reagálhat a változó üzleti igényekre.

Az Olyan Azure- és GitHub-szolgáltatások, mint az AKS, a Container Registry, a GitHub és a GitHub Actions használatával a vállalatok a legújabb alkalmazásfejlesztési technikákat és eszközöket használhatják a magas rendelkezésre állás megvalósításának egyszerűsítése érdekében. A nyílt forráskódú technológiák, például a Flux vagy a GitOpshoz készült Argo CD használatával a vállalatok leegyszerűsítik az üzembe helyezést, és kikényszerítik az alkalmazások kívánt állapotát.

Lehetséges használati esetek

Egyéb releváns használati esetek a következők:

  • Az alkalmazásfejlesztési eljárások modernizálása mikroszolgáltatás-alapú, tárolóalapú megközelítés alkalmazásával.
  • Az alkalmazásfejlesztés és az üzembe helyezés életciklusának felgyorsítása.
  • Automatizálhatja az üzembe helyezéseket az ellenőrzési környezetek teszteléséhez vagy elfogadásához.
  • Győződjön meg a konfigurációkról és az alkalmazás kívánt állapotáról.
  • A fürt életciklus-felügyeletének automatizálása.

CI/CD-beállítások

Ez a dokumentum bemutatja a GitOps használatát a CI/CD-folyamatok folyamatos üzembe helyezésének kezelésére szolgáló modern megközelítéshez. Azonban minden szervezet más. Amikor alkalmazásokat helyez üzembe a Kubernetes-fürtökben automatizált kézbesítési folyamatokon keresztül, fontos tisztában lenni a különböző módszerekkel.

Az alkalmazások AKS-fürtön való üzembe helyezésének két leggyakoribb CI/CD-lehetősége a leküldéses és a lekéréses alapú. A leküldéses beállítás a GitHub Actionst használja a folyamatos üzembe helyezéshez, a lekéréses beállítás pedig a GitOpst használja a folyamatos üzembe helyezéshez.

1. lehetőség: Leküldéses architektúra a GitHub Actions for CI és CD használatával

Ebben a megközelítésben a kód a folyamat CI-részével kezdődik, és a módosításokat üzembe helyezésként küldi el a Kubernetes-fürtbe. Az üzemelő példányok eseményindítón alapulnak. Különböző eseményindítók indíthatják el az üzembe helyezést, például véglegesíthetik az adattárat, vagy egy másik CI-folyamatból származó eseményindítót. Ezzel a módszerrel a folyamatrendszer hozzáfér a Kubernetes-fürthöz. A leküldéses alapú modul a CI/CD-eszközök által ma leggyakrabban használt modell.

A leküldéses megközelítés használatának okai:

  • Rugalmasság: A Legtöbb GitOps-operátor jelenleg csak a Kubernetesben fut. Ha a szervezet a Kubernetesen kívül másra is szeretne alkalmazásokat telepíteni, akkor más CI/CD-eszközökkel, például a GitHub Actions használatával kell leküldnie az alkalmazást az adott környezetbe.

  • Hatékonyság: A natív felhőbeli és hagyományos alkalmazások üzembe helyezésének szabványosított megközelítése hatékonyabb. A GitOps jelenleg a Kubernetesen futó natív felhőbeli alkalmazásokhoz ideális.

  • Egyszerűség: A push-alapú CI/CD számos szervezet mérnökeinek széles körében ismert. A leküldéses megközelítés egyszerűbb lehet, mint a leküldéses és a lekéréses alapú CI/CD-megközelítések keveréke.

  • Struktúra: Előfordulhat, hogy az alkalmazáshoz használt jelenlegi adattárstruktúra nem felel meg a GitOpsnak, ami azt jelenti, hogy jelentős tervezésre és átalakításra lenne szükség a GitOpshoz való illeszkedéshez.

2. lehetőség: Lekéréses architektúra a GitHub Actions for CI és a GitOps operátor Argo CD for CD használatával

Ez a megközelítés a Kubernetes-fürtön belüli módosítások alkalmazásával kapcsolatos. A Kubernetes-fürt tartalmaz egy operátort, amely egy git-tárházat vizsgál a fürt kívánt állapotához, és felveszi és alkalmazza a szükséges módosításokat. Ebben a modellben egyetlen külső ügyfél sem rendelkezik rendszergazdai szintű hitelesítő adatokkal a Kubernetes-fürthöz. A lekéréses modell nem új, de a CI/CD-eszközök nem használják széles körben. A GitOps bevezetésével a közelmúltban a pull-modell egyre elterjedtbbé vált. Számos szervezet használja a GitOpst a CD/CD-folyamatok folyamatos üzembe helyezésének megkönnyítésére.

A lekéréses megközelítés használatának okai:

  • Konzisztencia: A GitOps segítségével egy operátor összehasonlítja a Kubernetes-fürtök állapotát a konfiguráció és az alkalmazások kívánt állapotával egy Git-adattárban. Ha bármilyen eltérés van a konfiguráció vagy az alkalmazások között, a GitOps operátor automatikusan visszahozza a Kubernetes-fürtöt a kívánt állapotba.

  • Biztonság: A CI/CD GitOps használatával történő lekéréses alapú megközelítése lehetővé teszi a biztonsági hitelesítő adatok áthelyezését a Kubernetes-fürtre, ami csökkenti a biztonságot és a kockázat felületét azáltal, hogy eltávolítja a hitelesítő adatokat a külső CI-eszközben való tárolásból. Emellett csökkentheti az engedélyezett bejövő kapcsolatokat, és korlátozhatja a Kubernetes-fürtök rendszergazdai szintű hozzáférését.

  • Verziószámozás: Mivel a GitOps egy Git-adattárat használ az igazság forrásaként, a folyamatos üzembe helyezés eredendően verziószámozási, visszaállítási és naplózási képességekkel rendelkezik.

  • Több-bérlős: A GitOps pull-alapú megközelítése jól használható elosztott csapatok és több-bérlős csoportok számára. A GitOps segítségével külön Git-adattárakat, külön hozzáférési jogosultságokat használhat, és az üzembe helyezéseket különböző névterek között terjesztheti.

  • Natív felhő: Több alkalmazást modernizálnak vagy építenek fel, hogy natív felhő legyen. A Kubernetesben futó legtöbb alkalmazással rendelkező szervezetek esetében a GitOps-operátor folyamatos üzembe helyezése egyszerűbb és hatékonyabb, mint a CI/CD hagyományos leküldéses alapú megközelítése.

Considerations

Ezek a szempontok implementálják az Azure Well-Architected Framework alappilléreit, amely a számítási feladatok minőségének javítására használható vezérelvek halmaza. További információ: Microsoft Azure Well-Architected Framework.

Megbízhatóság

A megbízhatóság biztosítja, hogy az alkalmazás megfeleljen az ügyfelek felé vállalt kötelezettségeknek. További információ: A megbízhatósági pillér áttekintése.

Az alkalmazás teljesítményének monitorozásához és a problémákról való jelentéskészítéshez ez a forgatókönyv az Azure Monitort használja. Lehetővé teszi a kódfrissítéseket igénylő teljesítményproblémák monitorozását és hibaelhárítását, amelyek ezután üzembe helyezhetők a CI/CD-folyamattal.

Az AKS-fürt részeként a terheléselosztó elosztja az alkalmazás forgalmát egy vagy több, az alkalmazást futtató tárolóba vagy podba. A tárolóalapú alkalmazások Kubernetesben való futtatásának ez a megközelítése magas rendelkezésre állású infrastruktúrát biztosít az ügyfelek számára.

Megjegyzés:

Ez a cikk nem foglalkozik közvetlenül a CI/CD-folyamatok magas rendelkezésre állásának címével. További információ: GitHub Actions és Argo CD Deklaratív GitOps CD for Kubernetes.

A rugalmassági összetevők a Kubernetesbe vannak beépítve. Ezek az összetevők figyelik és újraindítják a tárolókat vagy podokat, ha probléma merül fel. Több Kubernetes-csomópont kombinálásakor az alkalmazás elviselheti, hogy egy pod vagy csomópont nem érhető el.

A rugalmas megoldások tervezésével kapcsolatos általános útmutatásért lásd : Megbízható Azure-alkalmazások tervezése.

Biztonság

A biztonság biztosítékokat nyújt a szándékos támadások és az értékes adatokkal és rendszerekkel való visszaélés ellen. További információ: A biztonsági pillér áttekintése.

A hitelesítő adatok és engedélyek elkülönítéséhez ez a forgatókönyv egy dedikált Microsoft Entra szolgáltatásnevet használ. A szolgáltatásnév hitelesítő adatai biztonságos hitelesítő objektumként vannak tárolva a GitHubon GitHub Actions-titkos kódként, hogy ne legyenek közvetlenül elérhetővé és láthatók a szkriptekben vagy a buildelési folyamatban.

Az alkalmazások AKS-fürtökön való biztonságossá tételével kapcsolatos általános útmutatásért tekintse meg az AKS-ben található alkalmazások és fürtök biztonsági alapelveit.

Az aggodalmak elkülönítéséhez az útmutató az üzleti alkalmazást futtató számításnak a CD-ügynököktől vagy a GitOps-operátortól való elkülönítése az üzleti alkalmazás és a GitOps operátor külön névterekben való futtatásával a Kubernetes-fürtben. Az aggodalmak további elkülönítése érdekében a GitOps-operátor futtatható egy Olyan Kubernetes-fürtön, amely a GitOps-példánynak van dedikáltan elkülönítve az üzleti alkalmazást futtató éles Kubernetes-fürttől.

Megjegyzés:

Ez a cikk nem foglalkozik közvetlenül a CI/CD-folyamatok biztonságossá tételével.

Teljesítmény hatékonysága

A teljesítménybeli hatékonyság lehetővé teszi, hogy a számítási feladatok hatékonyan méretezhetők legyenek a felhasználók igényei szerint. További információ: Teljesítményhatékonysági pillér áttekintése.

Az AKS lehetővé teszi a fürtcsomópontok számának skálázását az alkalmazások igényeinek megfelelően. Az alkalmazás növekedésével felskálázhatja a szolgáltatást futtató Kubernetes-csomópontok számát.

A GitHub Actions használatával a felhőszolgáltató automatikusan skálázza a futók számát. Ha saját üzemeltetésű futókat használnak, a futó gazdagépe lesz a felelős a skálázásukért.

További skálázhatósági témakörökért tekintse meg a teljesítményhatékonysági ellenőrzőlistát.

A forgatókönyv üzembe helyezése

A forgatókönyv üzembe helyezéséhez kövesse az AKS-baseline-automation referencia-implementáció lépéseit. A referencia-implementációs adattár végigvezeti a leküldéses ci-/CD-forgatókönyvet és a lekéréses alapú CI/CD-forgatókönyvet (GitOps).

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerzők:

Egyéb közreműködők:

A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.

További lépések

Ez a forgatókönyv az Azure Container Registryt és az AKS-t használta egy tárolóalapú alkalmazás tárolására és futtatására. Az Azure Container Apps vagy az Azure Container Instances tárolóalapú alkalmazások futtatására is használható anélkül, hogy vezénylési összetevőket kellene kiépítenie. További információkért tekintse meg az Azure Container Instances és az Azure Container Apps áttekintését.

Termékdokumentáció:

Microsoft Learn-modulok: