DevTest és DevOps mikroszolgáltatás-megoldásokhoz

Azure Boards
Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Pipelines
GitHub

Megoldási ötletek

Ez a cikk egy megoldási ötlet. Ha azt szeretné, hogy további információkkal bővítsük a tartalmat, például a lehetséges használati eseteket, alternatív szolgáltatásokat, megvalósítási szempontokat vagy díjszabási útmutatást, a GitHub visszajelzésével tudassa velünk.

A mikroszolgáltatási architektúrák lazán összekapcsolt szolgáltatások gyűjteményeként tervezik az alkalmazásokat. A mikroszolgáltatás-architektúrában a szolgáltatások részletesek, a protokollok pedig egyszerűek. A mikroszolgáltatások olyan előnyöket kínálnak, mint az aggodalmak egyértelmű elkülönítése és a függőségek szétválasztása.

A mikroszolgáltatások összetettségeket vezetnek be a fejlesztési ciklusban a hagyományos monolitikus alkalmazásokhoz képest. A fejlesztés hagyományosan az alkalmazásverem helyi vagy virtuális replikájában történik, amely helyileg, elszigetelten konfigurálja és futtatja a számítási és tárolási összetevőket. Egy mikroszolgáltatási modellben a fejlesztőknek tesztelniük kell szolgáltatásaikat a meglévő architektúrán, korai integrációs problémákat kell észlelniük a buildelési és üzembe helyezési idő megtakarításához, és az integrált buildeket tisztán kell tartaniuk az alkalmazás életciklusa során.

A fejlesztési tesztelés (DevTest) egy szoftverfejlesztési megközelítés, amely a fejlesztés korai szakaszában integrálja a tesztelést a fejlesztés felgyorsítása érdekében. A DevOps egy olyan gyakorlatkészlet, amely a szoftverfejlesztést és az informatikai műveleteket kombinálva lerövidíti a fejlesztési ciklust, és kiváló minőségű folyamatos teljesítést biztosít. A Kubernetes egy nyílt forráskódú tárolóvezénylési rendszer az alkalmazások üzembe helyezésének automatizálásához.

Ez a megoldásarchitektúra egy fejlesztési és üzembehelyezési környezetet modellez, amely a DevTestben a DevOps használatával gyors iteratív fejlesztést biztosít egy Azure Kubernetes Service-(AKS-) mikroszolgáltatási alkalmazáshoz.

Lehetséges használati esetek

  • Régi alkalmazáskorszerűsítés
  • Valós idejű feldolgozást igénylő megoldások (banki/pénzügyi vagy adatstreamelés/média)
  • EGY alkalmazás RAM- vagy CPU-igényes részei (natív nyelvi feldolgozás)

Architektúra

Diagram showing the configuration of DevTest and DevOps for a microservice application.

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

Adatfolyam

  1. A fejlesztők a Helyi folyamat és a Kubernetes használatával futtatják a helyi mikroszolgáltatás-verziókat a fejlesztési Kubernetes-fürt kontextusában. A szolgáltatás hibakeresése közben Csatlakozás a fürtre, így gyors tesztelést és fejlesztést tesz lehetővé a teljes alkalmazáskörnyezetben.

  2. Minden mikroszolgáltatás-kódbázis egy külön GitHub-kódtárat használ a forráskezeléshez.

  3. A GitHub Actions létrehozza a mikroszolgáltatás-tároló lemezképeit, és leküldi őket az Azure Container Registriesbe. A GitHub Actions emellett frissíti az adattárak legújabb címkéjét a folyamatos integrációhoz (CI), illetve a címkék adattárait a kiadáshoz.

  4. A GitHub Actions automatizált tesztelése munkaelemeket hoz létre az Azure Boards számára , így az összes munkaelem kezelhetővé válik egy helyen.

  5. A Visual Studio Code-bővítmények támogatják az Azure Boards és a GitHub integrációját. Az Azure Boards-munkaelemek társítása a GitHub-adattárakkal a kódhoz való kötődés követelményeivel, ami előrevetíti a fejlesztési ciklust.

  6. Az integrációs ágba egyesített véglegesítések aktiválják a GitHub Actions-buildeket, és a Docker leküldi a DevTest-tárolóregisztrációs adatbázisokat. Minden mikroszolgáltatás saját tárolóregisztrációs adattárral rendelkezik a GitHub-adattárakkal párhuzamos tárolóregisztrációs adatbázisokban. A CI-buildek a legújabb címkével vannak megjelölve, amely a legutóbbi sikeres mikroszolgáltatás-buildeket jelöli.

  7. Az Azure Pipelines a Kubernetes apply parancs futtatásával aktiválja a frissített Tárolóregisztrációs adatbázis lemezképeinek központi telepítését a DevTest Kubernetes-fürtökön. Az Azure hitelesítheti az AKS-t felügyelet nélküli Container Registry-lekérések futtatásához, ami leegyszerűsíti a folyamatos üzembe helyezési (CD-) folyamatot.

    Az Azure Pipelines az Azure Key Vault használatával biztonságosan használja fel a kiadási és üzembehelyezési konfigurációkhoz szükséges titkos kulcsokat, például hitelesítő adatokat és kapcsolati sztring.

  8. Ha az alkalmazás egy verziója készen áll a minőségbiztosítási (minőségbiztosítási) tesztelésre, az Azure Pipelines elindít egy minőségbiztosítási kiadást. A folyamat minden megfelelő lemezképet címkéz a következő növekményes verzióval, frissíti a Kubernetes-jegyzékfájlt a képcímkék megjelenítéséhez, és futtatja a apply parancsot. Ebben a példában bár előfordulhat, hogy egy fejlesztő külön-külön iterál egy szolgáltatáson, csak a CI/CD-n keresztül integrált buildek kerülnek át az üzembe helyezésre.

  9. Miután a tesztelés jóváhagyta a szolgáltatás üzembehelyezési verzióját, a GitHub Actions előléptet egy kiadást a DevTest Container Registryből egy éles tárolóregisztrációs adatbázisba. A GitHub Actions a lemezképeket a megfelelő verzióval címkézi meg, és a tárolóregisztrációs adatbázis ajánlott eljárásait követve leküldi őket az éles tárolóregisztrációs adatbázisba.

  10. Az Azure Pipelines létrehoz egy kiadást az éles környezetben. A folyamat jóváhagyási kapukat, előzetes és fázis utáni feltételeket ír elő, hogy megvédje az éles környezetet a véletlen vagy helytelen üzembe helyezéstől.

Az alkalmazás az Azure Cosmos DB-t használja a globálisan elosztott adatbázisszinthez.

Minden szolgáltatás és környezet metrikákat jelent az Azure Monitornak.

Ebben a megoldásban egyetlen Microsoft Entra-azonosító kezeli a DevTest és az Éles verziós előfizetések identitását. Az Azure szerepköralapú hozzáférés-vezérlés (Azure RBAC) korlátozza a védett erőforrásokhoz való hozzáférést, megakadályozva az éles erőforrások jogosulatlan vagy véletlen módosítását. A fejlesztők nem rendelkeznek ugyanazokkal a hozzáférés-vezérlési szintekkel az éles környezetben, mint a DevTest tesztkörnyezetekben.

Összetevők

  • Az Azure DevTest Labs olyan tesztkörnyezeteket biztosít, amelyek rendelkeznek a környezetek létrehozásához szükséges eszközökkel és szoftverekkel. A fejlesztők hatékonyan kezelhetik az erőforrásokat anélkül, hogy jóváhagyásra várnak. A DevTest Labs segítségével a csapatok szabályozhatják a tesztkörnyezetenkénti költségeket és szabályozhatják az erőforrásokat, így a fejlesztők engedélyt és rugalmasságot biztosíthatnak a tesztkörnyezeteik költségkorlátokon belüli működtetéséhez.

  • A GitHub egy kódüzemeltetési platform a verziókövetéshez és az együttműködéshez. A GitHub forrásvezérlési adattára tartalmazza az összes projektfájlt és azok korrektúraelőzményeit. A fejlesztők együttműködhetnek a kódtárban való közreműködéshez, megvitatásához és kezeléséhez.

  • A GitHub Actions összeállítási és kiadási munkafolyamatokat biztosít, amelyek a CI-t, az automatizált tesztelést és a tárolótelepítéseket fedik le.

  • Az Azure Boards a szoftverprojektek munkáinak kezelésére szolgáló szolgáltatás. Az Azure Boards számos funkciót kínál, beleértve a Scrum és Kanban módszertanok natív támogatását, a testreszabható irányítópultokat és az integrált jelentéskészítést.

  • Az Azure Pipelines egy teljes körű CI/CD szolgáltatás, amely automatikusan üzembe helyezheti a frissített Tárolóregisztrációs adatbázis lemezképeit a Kubernetes-fürtökön.

  • Az Azure Key Vault biztonságosan tárolja és szigorúan szabályozza az olyan titkos kódokhoz való hozzáférést, mint az API-kulcsok, jelszavak és tanúsítványok. A Key Vault DevOps-forgatókönyvekben való használatával kapcsolatos további információkért lásd: DevSecOps az AKS-en és a DevSecOps a GitHubon.

  • Az Azure Container Registry támogatja a tárolólemezképek és -összetevők magánregisztrációs adatbázisokban való kiépítését, tárolását és kezelését minden típusú tárolótelepítéshez.

  • Az Azure Kubernetes Service egyszerűvé teszi a felügyelt Kubernetes-fürtök üzembe helyezését azáltal, hogy a bonyolultság, a felelősség és a működési többlet nagy részét kiterjessze az Azure-ba.

  • A Microsoft Entra ID vállalati identitásplatform egyszeri bejelentkezést és többtényezős hitelesítést biztosít a felhasználói hozzáférés szabályozásához. Egyetlen Microsoft Entra-azonosító képes az összes környezet identitásának kezelésére az előfizetések között. Az Azure szerepköralapú hozzáférés-vezérlése (Azure RBAC) korlátozza a védett erőforrásokhoz való hozzáférést, megakadályozva az éles erőforrások jogosulatlan vagy véletlen módosítását.

  • Az Azure Cosmos DB egy teljes mértékben felügyelt, széles körben elosztott adatbázis-szolgáltatás, amely támogatja a magas rendelkezésre állású, többrégiós alkalmazásokat, valamint az SQL és a NoSQL API-kat is. Az Azure Cosmos DB olyan DevTest-funkciókat tartalmaz, mint például egy helyi Azure Cosmos DB emulátor, amely integrálható az Azure DevOpsszal, valamint alacsony költségű szinteket a Költségek kezeléséhez a DevTest tesztkörnyezetekben.

  • Az Azure Monitor az éles és a DevTest-környezeteket is monitorozni tudja. Az Azure Monitor naplóadatokat gyűjt a virtuálisgép-operációs rendszerekről és összeomlási memóriaképfájlokról, és összesíti őket a Felhőhöz készült Microsoft Defender való megtekintéshez.

Alternatívák

  • Az Azure Repos a GitHub for Git-adattár üzemeltetésének alternatíva. Az Azure Repos, az Azure Boards és az Azure Pipelines használatával minden Azure DevOps Services ugyanazt a portált és felhasználói felületet használja, így összesíti a DevOps-tevékenységekhez szükséges szolgáltatásokat a fejlesztők számára.

  • Az Azure Pipelinesban elérhető egyes integrációk, például a szolgáltatáskapcsolat vagy a közvetlenül az Azure gerinchálózatába történő hitelesítés jelenleg nem léteznek a GitHub Actionsben. Ezekhez az igényekhez fontolja meg az Azure Pipelines használatát a GitHub Actions helyett a CI-hez és a buildelési tevékenységekhez.

  • Egy széles körben elosztott rendszerben a mikroszolgáltatások különálló adattárakba való elkülönítésének előnyei vannak. A tulajdonjog és az engedély szétválasztása egyszerűbb, és a különböző nyelvű projektek könnyebben karbantarthatóak, mint egyetlen adattárral. Az azonos nyelven vagy futtatókörnyezetben kevesebb mikroszolgáltatást tartalmazó megoldások esetében azonban egyszerűbb lehet egyetlen Git-adattárat fenntartani a projekthez.

Következő lépések