Megosztás a következőn keresztül:


CI/CD-munkafolyamat a GitOps használatával (Flux v2)

A modern Kubernetes-környezetek több alkalmazást, fürtöt és környezetet tartalmaznak. A GitOps segítségével könnyebben kezelheti ezeket az összetett beállításokat, és deklaratív módon követheti nyomon a Kubernetes-környezetek kívánt állapotát a Gittel. A fürtök állapotának deklarálására szolgáló általános Git-eszközökkel növelheti az elszámoltathatóságot, megkönnyítheti a hibavizsgálatot, és lehetővé teheti az automatizálást a környezetek kezeléséhez.

Ez a cikk azt ismerteti, hogyan illeszkedik a GitOps az alkalmazás teljes változási életciklusába az Azure Arc, az Azure Repos és az Azure Pipelines használatával. Példaként szolgál a GitOps által felügyelt Kubernetes-környezetek egyetlen alkalmazásmódosítására is.

Architektúra

Ez az ábra egy vagy több Kubernetes-környezetben üzembe helyezett alkalmazás CI-/CD-munkafolyamatát mutatja be.

A GitOps CI/CD architektúrát bemutató ábra.

Alkalmazáskódtár

Az alkalmazás adattára tartalmazza azt az alkalmazáskódot, amelyen a fejlesztők dolgoznak a belső ciklus során. Az alkalmazás üzembehelyezési sablonjai ebben az adattárban egy általános formában, például a Helmben vagy a Kustomize-ban élnek. A környezetspecifikus értékek nincsenek tárolva az adattárban.

Az adattár módosításai meghívnak egy PR- vagy CI-folyamatot, amely elindítja az üzembe helyezési folyamatot.

Container Registry

A tárolóregisztrációs adatbázis tartalmazza a Kubernetes-környezetekben használt összes első és külső rendszerképet. Az első féltől származó alkalmazásképek címkéje ember által olvasható címkékkel és a rendszerkép létrehozásához használt Git-véglegesítéssel van megjelölve. A külső rendszerképek gyorsítótárazhatók a biztonság, a sebesség és a rugalmasság érdekében. Állítson be egy tervet a biztonsági frissítések időalapú teszteléséhez és integrálásához.

További információ: Nyilvános tartalom felhasználása és karbantartása az Azure Container Registry-feladatokkal.

PR-folyamat

A fejlesztők által az alkalmazás-adattárba küldött lekéréses kérelmek a PR-folyamat sikeres futtatásakor lesznek elérhetők. Ez a folyamat az alapvető minőségi kapukat futtatja, például a linting és az egységteszteket az alkalmazáskódon. A folyamat teszteli az alkalmazást és a Kubernetes-környezetbe való üzembe helyezéshez használt Dockerfile-fájlokat és Helm-sablonokat. A Docker-rendszerképeket ki kell építeni és tesztelni kell, de nem szabad leküldést végezni. Tartsa viszonylag rövidre a folyamat időtartamát, hogy lehetővé tegye a gyors iterációt.

CI-folyamat

Az alkalmazás CI-folyamata futtatja a PR-folyamat összes lépését, kibővítve a tesztelési és üzembehelyezési ellenőrzéseket. A folyamat futtatható minden fő véglegesítéshez, vagy normál ütemben is futtatható egy véglegesítési csoporttal.

Ebben a szakaszban olyan alkalmazástesztek végezhetők el, amelyek túl sok időt igényelnek a PR-folyamathoz, beleértve a következőket:

  • Képek leküldése a tárolóregisztrációs adatbázisba
  • Képkészítés, linting és tesztelés
  • Nyers YAML-fájlok sablongenerálása

A CI-build végére az összetevők létrejönnek. Ezeket az összetevőket a CD-lépés felhasználhatja az üzembe helyezés előkészítése során.

Flux-fürtbővítmény

A Flux egy ügynök, amely az egyes fürtökben fürtbővítményként fut. Ez a Flux-fürtbővítmény felelős a kívánt állapot fenntartásáért. Az ügynök felhasználó által meghatározott időközönként lekérdezi a GitOps-adattárat, majd egyezteti a fürt állapotát a Git-adattárban deklarált állapottal.

További információ : Oktatóanyag: Alkalmazások üzembe helyezése a GitOps és a Flux v2 használatával.

CD-folyamat

A CD-folyamatot a sikeres CI-buildek automatikusan aktiválják. Ebben a folyamatkörnyezetben a rendszer a környezetspecifikus értékeket a korábban közzétett sablonokra cseréli, és új lekéréses kérelmet küld a GitOps-adattárhoz ezekkel az értékekkel. Ez a lekéréses kérelem egy vagy több Kubernetes-fürt kívánt állapotának javasolt módosításait tartalmazza. A fürtgazdák áttekintik a lekéréses kérelmet, és jóváhagyják az egyesítést a GitOps-adattárba. A folyamat megvárja, amíg a lekéréses kérelem egyesül, majd a Flux szinkronizálja és alkalmazza az állapotmódosításokat.

GitOps-adattár

A GitOps-adattár a fürtök összes környezetének aktuális kívánt állapotát jelöli. Az adattár minden módosítását a Flux szolgáltatás minden fürtben átveszi és üzembe helyezi. A fürtök kívánt állapotának módosítása lekéréses kérelmekként jelenik meg, amelyeket a rendszer áttekint, majd a módosítások jóváhagyása után egyesít. Ezek a lekéréses kérelmek az üzembehelyezési sablonok és az eredményül kapott Kubernetes-jegyzékek módosításait tartalmazzák. Az alacsony szintű renderelt jegyzékek lehetővé teszik a módosítások gondos ellenőrzését, amelyek általában sablonszinten nem láthatók.

GitOps-összekötő

A GitOps-összekötő kapcsolatot hoz létre a Flux-ügynök és a GitOps-adattár/CD-folyamat között. Bár a módosítások a fürtre vonatkoznak, a Flux értesíti a GitOps-összekötőt minden fázismódosításról és az elvégzett állapot-ellenőrzésről. Ez az összetevő adapterként szolgál. Megérti, hogyan kommunikálhat egy Git-adattárral, és frissíti a Git véglegesítési állapotát, hogy a szinkronizálási folyamat látható legyen a GitOps-adattárban. Amikor az üzembe helyezés befejeződik (akár sikeres, akár sikertelen), az összekötő értesíti a CD-folyamatot a folytatásról, hogy a folyamat végrehajthassa az üzembe helyezés utáni tevékenységeket, például az integrációs tesztelést.

Kubernetes-fürtök

Legalább egy Azure Arc-kompatibilis Kubernetes- vagy Azure Kubernetes Service-fürt (AKS) az alkalmazás által igényelt különböző környezeteket szolgálja ki. Egy fürt például különböző névtereken keresztül is kiszolgálhat fejlesztői és minőségbiztosítási környezetet. A második fürt megkönnyíti a környezetek elkülönítését és a részletesebb vezérlést.

Példa munkafolyamat

Alkalmazásfejlesztőként Alice:

  • Alkalmazáskódot ír.
  • Meghatározza, hogyan futtathatja az alkalmazást Egy Docker-tárolóban.
  • Meghatározza a tárolót és a függő szolgáltatásokat kubernetes-fürtön futtató sablonokat.

Alice meg szeretné győződni arról, hogy az alkalmazás képes több környezetben is futni, de nem ismeri az egyes környezetek konkrét beállításait.

Tegyük fel, hogy Alice olyan alkalmazásmódosítást szeretne végrehajtani, amely módosítja az alkalmazástelepítési sablonban használt Docker-lemezképet.

  1. Alice módosítja az üzembehelyezési sablont, leküldi egy távoli ágba, amelyet az alkalmazás-adattárban hív alice meg, és megnyitja a lekéréses felülvizsgálatra vonatkozó kérelmet az main ágon.

  2. Alice megkéri a csapatát, hogy tekintse át a változást.

    • A PR-folyamat érvényesítést futtat.
    • A sikeres PR-folyamat futtatása és a csapat jóváhagyása után a módosítás egyesül.
  3. A CI-folyamat ezután elindul, és ellenőrzi Alice változását, és sikeresen befejeződik.

    • A módosítás biztonságosan üzembe helyezhető a fürtben, és a rendszer menti az összetevőket a CI-folyamat futtatásába.
  4. A ci-folyamat sikeres futtatása aktiválja a CD-folyamatot.

    • A CD-folyamat felveszi Alice CI-folyamatfuttatása által tárolt összetevőket.
    • A CD-folyamat környezetspecifikus értékekkel helyettesíti a sablonokat, és a GitOps-adattárban lévő meglévő fürtállapot módosításait szakaszolja.
    • A CD-folyamat lekéréses kérelmet hoz létre a GitOps-adattár éles ágán a fürt állapotának kívánt módosításával.
  5. Alice csapata áttekinti és jóváhagyja a lekéréses kérelmet.

    • A módosítás a környezetnek megfelelő célágba lesz egyesítve.
  6. Perceken belül a Flux észlel egy változást a GitOps-adattárban, és lekéri Alice változását.

    • A Docker-rendszerkép módosítása miatt az alkalmazás podjának frissítésre van szüksége.
    • A Flux alkalmazza a módosítást a fürtre.
    • A Flux a GitOps-összekötőn keresztül jelenti vissza az üzembe helyezés állapotát a GitOps-adattárba.
  7. A CD-folyamat automatizált teszteket futtat az új üzembe helyezés sikeres befejezésének ellenőrzéséhez, és a várt módon működik.

    Feljegyzés

    Az üzembe helyezésre szánt további környezetek esetében a CD-folyamat úgy iterál, hogy létrehoz egy lekéréses kérelmet a következő környezethez, és megismétli a 4–7. lépést. A folyamat sokak számára további jóváhagyást igényel a kockázatosabb üzemelő példányokhoz vagy környezetekhez, például egy biztonsággal kapcsolatos változáshoz vagy egy éles környezethez.

  8. Ha az összes környezet sikeres üzembe helyezést kapott, a folyamat befejeződik.

Következő lépések