CI/CD és GitOps szemléletek az Azure Arc-kompatibilis Kubernetes használatával

  • Cikk

A Kubernetes natív felhőbeli szerkezetként natív felhőbeli megközelítést igényel az üzembe helyezéshez és a műveletekhez. A GitOps használatával deklarálhatja az alkalmazásalapú üzemelő példányok kívánt állapotát a Git-adattárakban tárolt fájlokban. Az alkalmazások kubernetes-objektumokkal rendelkeznek, amelyeket futtatniuk kell, amelyek közé tartozhatnak az üzemelő példányok, a horizontális-pod-automatikus skálázók, a szolgáltatások és a konfiguráció Térképek. A Kubernetes-operátorok a fürtökben futnak, és folyamatosan egyeztetik az egyes fürtök állapotát a Git-adattárban deklarált kívánt állapottal. Ezek az operátorok lekérnek fájlokat a Git-adattárakból, és a kívánt állapotot alkalmazzák a fürtökre. Az operátorok folyamatosan biztosítják, hogy a fürt a kívánt állapotban maradjon.

A GitOps implementálása a következőket teszi lehetővé:

  • A Kubernetes-fürt állapotának és konfigurációjának általános láthatóságának javítása.
  • A fürt módosításainak egyszerű naplózása és verzióelőzményei a Git változáselőzményei alapján, amely bemutatja, hogy ki és mikor hajtotta végre a módosításokat, és hogy miért.
  • Automatikusan javítsa ki a fürtre esetlegesen bekövetkező eltérést.
  • Állítsa vissza a Kubernetes-konfigurációt egy korábbi verzióra Git-visszaállítási vagy Git-visszaállítási parancsokkal. A fürt üzembe helyezésének ismételt létrehozása vészhelyreállítási forgatókönyvekhez szintén gyors és egyszerű folyamattá válik, mivel a Kubernetes kívánt fürtkonfigurációja a Gitben van tárolva.
  • A biztonság javítása azáltal, hogy csökkenti azon szolgáltatásfiókok számát, amelyek a fürt üzembehelyezési engedélyeinek megadásához szükségesek.
  • Ci/CD-folyamat implementálása alkalmazások fürtben való üzembe helyezéséhez.

Az Azure Arc-kompatibilis Kubernetes GitOps egy olyan bővítményt használ, amely implementálja a Fluxot, egy népszerű nyílt forráskódú eszközkészletet. A Flux egy olyan operátor, amely automatizálja a GitOps-konfiguráció üzembe helyezését a fürtben. A Flux támogatja a gyakori fájlforrásokat (Git-adattárak, Helm-adattárak, gyűjtők) és sablontípusokat (YAML, Helm és Kustomize). A Flux a több-bérlős és üzembehelyezési függőségek kezelését is támogatja más funkciók mellett.

Architektúra

Az alábbi ábrák egy elméleti referenciaarchitektúrát mutatnak be, amely kiemeli a Flux-fürtbővítmények üzembe helyezését egy fürtben, egy Azure Arc-kompatibilis Kubernetes-fürt GitOps-konfigurációs folyamatát és a GitOps Flow-t.

Flux v2 fürtbővítmény üzembe helyezése:

Diagram that shows Flux extension installation.

GitOps-konfigurációs folyamat:

Diagram that shows how to configure GitOps.

GitOps Flow alkalmazásfrissítéssel:

Diagram that shows a typical GitOps workflow.

Kialakítási szempontok

Tekintse át az alábbi tervezési szempontokat az Azure Arc-kompatibilis Kubernetes GitOps implementálásának tervezésekor.

Konfiguráció

Vegye figyelembe a Kubernetes-fürt különböző konfigurációs rétegeit és az üzembe helyezésükhöz szükséges felelősségeket.

Konfigurációs rétegek

  • Az alkalmazás és a kapcsolódó Kubernetes-objektumok fürtre való telepítéséhez szükséges alkalmazáskonfiguráció, például üzembe helyezési, szolgáltatási, HPA- és ConfigMap-erőforrások. Az alkalmazáskonfigurációkat általában egy névtérszintű GitOps-konfigurációra alkalmazzák, így az alkalmazás-összetevőket csak egyetlen névtéren belül kell konfigurálni.
  • Fürtszintű konfiguráció Kubernetes-objektumok, például névterek, szolgáltatásfiókok, szerepkörök, szerepkörkötések és más fürtszintű szabályzatok létrehozásához.
  • A fürtre kiterjedő összetevők, például a bemeneti vezérlő, a monitorozási és biztonsági verem, valamint a fürtön működő különböző ügynökök.

Felelősségi körök

  • Az alkalmazásfejlesztők feladata a forráskód leküldése, a buildek aktiválása és a tárolólemezképek létrehozása.
  • Az alkalmazásüzemeltetők felelősek az alkalmazás-adattárak, konfigurációk, környezeti változók, alkalmazásspecifikus helm-diagramok, Kustomizations stb. karbantartásáért.
  • A fürtüzemeltetők feladata a fürt alapkonfigurációjának beállítása. Általában a fürtszintű összetevők és szabályzatok beállításával foglalkoznak. Olyan általános infrastruktúra-eszközöket tartalmazó Git-adattárat vagy -adattárakat tartanak fenn, mint például névterek, szolgáltatásfiókok, szerepkörkötések, CRD-k, fürtszintű szabályzatok, bemenetivezérlő-összetevők stb.

Az adattár struktúrája

Fontolja meg a kompromisszumokat a Git-adattár szerkezetének megválasztásakor. A választott struktúra határozza meg a Kubernetes-fürt állapotát, amely magában foglal alkalmazásokat és fürtszintű összetevőket. Attól függően, hogy milyen felelősségi köröket és személyeket azonosít, fontos figyelembe venni a különböző adattárszerkezeti lehetőségekhez szükséges együttműködést vagy csapatfüggetlenséget.

A kódtárakhoz tetszőleges elágaztatási stratégiát használhat, mivel azt csak a folyamatos integrációs (CI) folyamat használja.

A GitOps konfigurációs adattáraihoz vegye figyelembe a következő stratégiákat a szervezet üzleti igényei, mérete és eszközei alapján:

  • Egyetlen adattár (ág környezetenként):
    • A legnagyobb rugalmasságot teszi lehetővé a Git-szabályzatok és -engedélyek szabályozásához minden olyan ág esetében, amely egy környezetet képvisel.
    • A hátránya, hogy a környezetek között nincs megosztva a közös konfiguráció, mivel az olyan eszközök, mint a Kustomize , nem működnek a Git-ágakkal.
  • Egyetlen adattár (könyvtár környezetenként):
    • Ezt a megközelítést olyan eszközökkel implementálhatja, mint a Kustomize, amely lehetővé teszi a Kubernetes-objektumok alapkonfigurációjának és a környezethez tartozó összetevők (pl. javítások) alapkonfigurációjának meghatározását, amely felülbírálja az alapkonfigurációkat.
    • Ez a módszer csökkentheti az egyes környezetek duplikált YAML-fájljait, de csökkenti a környezetek konfigurációs elkülönítését is. Az adattár egyetlen módosítása hatással lehet egyszerre az összes környezetre, ezért az alapkönyvtárak módosításainak hatásával teljes mértékben tisztában kell lenni, és körültekintően kell eljárni.
  • Több adattár (mindegyik meghatározott célt szolgál):
    • Ez használható az egyes alkalmazások, csapatok, rétegek vagy bérlők konfigurációs adattárainak elkülönítésére.
    • Ez lehetővé teszi a csapatok számára, hogy függetlenebb vezérléssel rendelkezzenek, de eltávolodnak a rendszerállapot egyetlen adattárban való meghatározásának elvétől, hogy javítsák a fürt központi konfigurációját, láthatóságát és vezérlését.
    • Több-bérlős működés esetén érdemes megfontolni több adattár létrehozását. A beépített szerepköralapú hozzáférés-vezérlés (RBAC) és biztonság korlátozza, hogy egy adott adattárhoz hozzárendelt csapat/bérlő milyen konfigurációt alkalmazhat, például csak bizonyos névterekre vonatkozóan engedélyezi az üzembe helyezést.

Tekintse meg az adattár felépítésének további módjait a Flux útmutatójában.

Alkalmazás- és platformkonfiguráció

A platformüzemeltetők és az alkalmazásüzemeltetők többféleképpen kezelhetik a Kubernetes-konfigurációt:

  • Az üzembe helyezett Kubernetes API-objektumok YAML-specifikációit képviselő nyers Kubernetes YAML-fájlok jól használhatók egyetlen környezetben. A nyers YAML-fájlok használatának hátránya, hogy a testreszabás nehézkessé válik, amikor több környezetet kezd beépíteni, mivel ezt követően duplikálnia kell a YAML-fájlokat, és nincs jó újrafelhasználási módszer.
  • A Helm a Kubernetes-objektumok csomagkezelő eszköze. Ez egy érvényes lehetőség, amellyel a fürtüzemeltetők harmadik féltől származó, polcon kívüli alkalmazásokat telepíthetnek. Győződjön meg arról, hogy a belső alkalmazások konfigurációkezelési eszközeként nem használja túl nagy mértékben a templatingot, mert a sablonok növekedésével bonyolulttá válhat a kezelés.
    • A Helm használata esetén a Flux tartalmaz egy Helm-vezérlőt, amellyel deklaratív módon kezelheti a Helm Chart-kiadásokat a Kubernetes-jegyzékekkel. HelmRelease-objektumot hozhat létre a folyamat kezeléséhez.
  • A Kustomize egy natív Kubernetes-konfigurációkezelő eszköz, amely sablonmentes módszert vezet be az alkalmazáskonfiguráció testreszabására.
    • A Kustomize használata esetén a Flux tartalmaz egy Kustomize-vezérlőt, amely a Kubernetes-jegyzékekkel definiált és a Kustomize-nal összeszerelt infrastruktúra és számítási feladatok folyamatos szállítási folyamatainak futtatására specializálódott. A folyamat kezeléséhez létrehozhat egy Kustomization objektumot.
  • Az Azure Arc-kompatibilis Kubernetes használata esetén az összetevők életciklusának és támogatásának kezelése helyett használhatja a Microsoft által kezelt és támogatott elérhető bővítmények listáját. Ezeket a bővítményeket az Azure Resource Manager felügyeli. Ezen bővítmények némelyike, például az Azure Key Vault titkos kulcsszolgáltatója nyílt forráskód alternatív megoldásokkal rendelkezik. A bővítményfolyamaton kívüli összetevők kezelésével nagyobb mértékben szabályozhatja az összetevőket, de a támogatás és az életciklus kezelése is nagyobb többletterhelést igényel.

Folyamatos integráció és folyamatos kézbesítés (CI/CD) folyamat

Az alábbi szakaszok az alkalmazásfolyamat és az összetevő frissítési folyamatával kapcsolatos szempontokat ismertetik.

Alkalmazásfolyamat

  • Fontolja meg az alkalmazás összeállítását, tesztelését és érvényesítését, amelyet a CI-folyamatba kell belefoglalnia. Ezek közé tartozhat a biztonsággal, az integrációval és a teljesítménnyel kapcsolatos linting és tesztelés, amelyre a környezetek üzembe helyezéséhez szükséges kiadási jelölt (RC) létrehozásához van szükség.
  • Egy hagyományos leküldéses üzembe helyezési módszerrel áthidalhatja a ci-folyamat buildtároló lemezképe és a fürtben való üzembe helyezés közötti különbséget a Kubernetes API közvetlen meghívásával az üzembe helyezési folyamatból.

A GitOps-adattár manuális konfigurációs módosításainak elkerülése érdekében a CD-folyamatot szolgáltatásfiókként futtathatja, amely rendelkezik engedéllyel a lekéréses kérelmek (PRs) megnyitására, vagy egy új tárolórendszerkép-módosítás véglegesítésére közvetlenül egy konfigurációs tárházba. Ezek a módosítások az alkalmazáshoz szükséges összes YAML-objektumot is kiépíthetik.

Az alábbi folyamatábra a GitOpst támogató módosításokkal beépített hagyományos alkalmazás CI-folyamatot mutatja be.

Diagram that shows the standard GitOps process.

Fürtszintű összetevő frissítési folyamata

  • A fürtüzemeltetőknek fürtszintű összetevőket kell kezelnie, így ez valószínűleg nem az alkalmazások és szolgáltatások üzembe helyezéséhez használt CD-folyamatból származik. Fontolja meg a fürtüzemeltetőkre vonatkozó előléptetési folyamat meghatározását, hogy a módosítások zökkenőmentesen át tudjanak váltani az egyik környezetről a másikra.
  • Ha azonos GitOps-konfigurációt kell nagy méretekben alkalmaznia az Azure Arc-kompatibilis Kubernetes-fürtökre, érdemes lehet olyan Azure Policyt alkalmaznia, amely automatikusan telepítheti a Flux-bővítményt, és alkalmazhatja a GitOps-konfigurációt meglévő Azure Arc-kompatibilis Kubernetes-fürtökre vagy új fürtökre az Azure Arc előkészítésekor.

A konfiguráció frissítésekor valószínűleg ellenőrizni szeretné, hogy a módosítások sikeresen alkalmazva lettek-e a kívánt környezetben. A Fluxban értesítéseket határozhat meg a CI/CD-eszközökkel, e-mailekkel vagy ChatOps-eszközökkel való integrációhoz, és automatikusan riasztásokat küldhet a sikeres módosításokról és az üzembe helyezési hibákról. Az üzembe helyezés állapotadatait az Azure Portalon, valamint a k8s-konfigurációs parancssori felületen és az ARM API-ban is megtalálhatja.

Biztonsági szempontok

Tekintse át az alábbi biztonsági szempontokat az Azure Arc-kompatibilis Kubernetes GitOps implementálásának tervezésekor.

Adattár hitelesítése

  • Használhat nyilvános vagy privát Git-adattárat a GitOps használatával, de a Kubernetes-konfigurációk bizalmas jellege miatt javasoljuk, hogy olyan privát adattárat használjon, amely SSH-kulccsal vagy API-kulccsal történő hitelesítést igényel. A GitOps olyan Git-adattárakkal is működik, amelyek csak magánhálózaton belül érhetők el, amíg a Kubernetes-fürt hozzáfér hozzájuk, de ez a beállítás korlátozza a felhőalapú Git-szolgáltatók, például az Azure Repos vagy a GitHub használatát.
  • A HTTPS és az SSH protokollok egyaránt megbízható és biztonságos kapcsolatot biztosítanak, amellyel csatlakozhat a forrásvezérlő eszközhöz. A HTTPS beállítása azonban gyakran egyszerűbb, és olyan portot használ, amely ritkán követeli meg, hogy több portot nyisson meg a tűzfalakban.

Adattár és ágbiztonság

  • Ágengedélyek és szabályzatok beállítása a konfigurációs adattárban. Mivel a Git-adattár lesz a Kubernetes-üzemelő példányok központi része, kritikus fontosságú, hogy engedélyeket állítson be annak szabályozásához, hogy ki olvashatja és frissítheti a kódot egy ágban, és hogy szabályzatokat implementáljon a csapat kódminőségének és változáskezelésének kikényszerítéséhez. Ellenkező esetben a GitOps-munkafolyamat olyan kódot tud szállítani, amely nem felel meg a szervezetek szabványainak.
  • A lekéréses kérelmek (PR) folyamatai együttműködhetnek az ágszabályzatokkal a YAML-konfiguráció ellenőrzéséhez és/vagy a tesztkörnyezetek szükség szerinti üzembe helyezéséhez. A Gates segít kiküszöbölni a konfigurációs hibákat, és növelni az üzembe helyezés biztonságát és megbízhatóságát.
  • Hozzáférési engedélyek hozzárendelésekor fontolja meg, hogy a szervezet mely felhasználói rendelkezzenek adattár-olvasási hozzáféréssel, pr-létrehozási hozzáféréssel és pr-jóváhagyási hozzáféréssel.

Titkos kódok kezelése

  • Kerülje az egyszerű szöveg vagy base64 kódolású titkos kódok tárolását a Git-adattárban. Ehelyett fontolja meg egy külső titkos kulcsszolgáltató, például az Azure Key Vault használatát. Az Azure Key Vault Titkos kulcstár CSI-illesztőprogramja lehetővé teszi az Azure Key Vault titkos kulcstárolóként való integrálását egy Azure Kubernetes Service-fürttel (AKS) egy CSI-kötet használatával. Ez a szolgáltatás az Azure Arc-kompatibilis Kubernetes-bővítményen keresztül érhető el. A HashiCorp Vault egy harmadik fél által felügyelt titkos kódszolgáltató alternatíva.
  • A titkos kulcsok kezelésének másik alternatív módja a Bitnami lezárt titkos kulcsainak használata, amely a nyilvános és a titkos kulcsok fogalmából működött. Ez lehetővé teszi, hogy az operátorok egy egyirányú titkosított titkos kulcsot tároljanak egy nyilvános kulccsal a Gitben, amelyet csak a fürtben futó SealedSecrets-vezérlő használ a titkos kulcson keresztül.

Tervezési javaslatok

Tekintse át az alábbi tervezési javaslatokat az Azure Arc-kompatibilis Kubernetes GitOps implementálásának tervezésekor.

Az alábbi ábra referenciaarchitektúrát tartalmaz, amely bemutatja a GitOps-folyamatok Azure Arc-kompatibilis Kubernetes Flux-bővítmény használatával történő implementálásához szükséges feladatokat, adattárakat és folyamatokat.

Diagram that shows a GitOps Reference flow.

Adattárak

A terv három Git-adattárat tartalmaz:

  • Alkalmazáskódtár
    • Ez az adattár tárolja az alkalmazáskódot, valamint a folyamatdefiníciókat és a konfigurációs szkripteket.
    • Használjon könnyen érthető fejlesztési elágaztatási stratégiát, és korlátozza a nem kívánt hosszú ideig futó ágak számát.
  • Alkalmazáskonfigurációs adattár
    • Ez az adattár alkalmazáskonfigurációkat tárol, beleértve a Kubernetes-objektumokat, például a Config Térképek, az üzembe helyezéseket, a szolgáltatásokat és a HPA-objektumokat. Strukturálja ezt az adattárat különböző könyvtárakkal az egyes alkalmazásokhoz. A Flux szinkronizálja az adattár és a célág módosításait a fürtre.
    • Olyan eszközök beépítése, amelyek megkönnyítik az alkalmazásfejlesztők és operátorok számára a kezdeti konfigurációk környezetenkénti létrehozását. Az alkalmazásüzemeltetőknek olyan Kubernetes-specifikus alkalmazáskonfigurációt kell meghatározniuk, amely a csomagkezelőket, például a Helmt vagy az olyan konfigurációs eszközöket használja, mint a Kustomize, hogy egyszerűbbé tegyék a konfigurációt.
    • Hozzon létre egy ágat az egyes környezettípusok megjelenítéséhez. Ez lehetővé teszi az egyes környezetek, például a nem produkált és az éles környezetek változásainak részletes ellenőrzését.
    • Ha egy alkalmazás egy adott névtérben van üzembe helyezve, a GitOps-konfigurációban található névtér-hatókör funkcióval csak egy adott névtér konfigurációját kényszerítheti ki.
  • Fürtszintű konfigurációs adattár
    • Fürtszintű összetevők, például bejövőforgalom-vezérlő, névterek, RBAC, monitorozás és biztonsági verem definiálása a fürtüzemeltetők kezeléséhez. A Flux szinkronizálja az adattár és a célág módosításait a fürtre.
    • Strukturálja ezt az adattárat különböző, különböző összetevőket képviselő könyvtárakkal.
    • Hozzon létre egy ágat az egyes környezettípusok megjelenítéséhez. Ez lehetővé teszi az egyes környezetek, például a nem produkált és az éles környezetek változásainak részletes ellenőrzését.
    • A fürtüzemeltetőknek olyan csomagkezelőket kell használniuk, mint a Helm vagy az olyan konfigurációs eszközök, mint a Kustomize overlays, hogy egyszerűbbé tegyék a konfigurációt.

CI/CD és konfigurációfrissítési folyamat

CI/CD- és tárolórendszerkép-frissítések

  • CI-folyamat
    • A fejlesztői csapatoknak olyan CI-folyamatot kell meghatározniuk, amely magában foglalja az alkalmazások a tárolóregisztrációs adatbázisba való kiépítését, lintingét, tesztelését és leküldését.
  • CD-folyamat
    • Hozzon létre egy CD-folyamatot, amely az alkalmazáskonfigurációs adattár módosításait célzó szkriptet futtat. Ez a szkript létrehoz egy ideiglenes ágat a célkörnyezetből, módosítja a képcímke verzióját, véglegesíti a módosítást, és megnyitja a lekéréses kérelmet a célkörnyezeti ágon. Ez a CD-folyamat rendelkezhet a megfelelő környezeti változókkal rendelkező környezeti fázisokkal a megfelelő GitOps Configuration-adattár és -ág megcélzásához.
    • A környezeti szakaszok manuális jóváhagyási lépéseinek meghatározása a nem kívánt lekéréses kérelmek minden környezetre való korlátozásához.
  • Engedélyezze a fiókszabályzatokat az alkalmazáskonfigurációs adattárban a környezetek társértékelésének vagy jóváhagyásának kikényszerítéséhez. Ez magában foglalhatja a minimális számú szükséges felülvizsgálatot vagy az alacsonyabb környezetek automatikus jóváhagyását. Vegye figyelembe a külső integrációkat és jóváhagyásokat is, amelyek szükségesek a szervezet szabványainak való megfeleléshez.

Fürtszintű és alkalmazáskonfigurációs frissítések

  • A fürtüzemeltetők és az alkalmazásüzemeltetők mindegyike a saját konfigurációs adattáraiban határozza meg a konfigurációt. Ezek a felhasználók nem igényelnek folyamateszközöket a konfigurációk leküldéséhez. Ehelyett natív Git-véglegesítési és PR-folyamatokat használnak a konfiguráció definiálásához és a környezeteket képviselő ág módosításainak leküldéséhez.
  • Új konfigurációdefiníciók esetén először definiálja a konfigurációt alacsonyabb környezetekben, például a Devben, majd előléptesse a magasabb környezetekbe egyesítésekkel és lekéréses kérésekkel. A Cherry-pick konfigurációs frissítései szükség szerint bizonyos környezetekre vonatkoznak.

Visszajelzés és riasztás

  • Konfigurálja a Flux-értesítéseket riasztásra, ha a GitOps-konfigurációk nem tudnak szinkronizálni vagy hibákat okoznak. Az alkalmazásüzemeltetőknek riasztásokat kell konfigurálnia annak meghatározásához, hogy az alkalmazástelepítés sikeres volt-e és kifogástalan-e. A fürtüzemeltetőknek riasztásokat kell konfigurálnia annak meghatározására, hogy a fürtszintű összetevők egyeztetése sikertelen volt-e, és ha szinkronizálási problémák merülnek fel a Git-adattárral.
  • A GitOps Csatlakozás or implementálása a Flux-ügynöktől érkező visszajelzések ci/CD-eszközkészletbe való integrálásához.

Biztonsági javaslatok

  • Tekintse át az Azure Arc-kompatibilis Kubernetes-fürtök szabályozási és biztonsági ajánlásait .
  • Kerülje a fürtkonfigurációkhoz való nemkívánatos hozzáférést egy privát Git-adattár használatával hitelesítéssel és engedélyezéssel, amellyel bármilyen konfigurációs adattárat meghatározhat.
  • Ha a Git-szolgáltató támogatja, SSH-protokollon és SSH-kulcson keresztül érheti el a Git-adattárat. Ha az SSH használhatatlan a kimenő kapcsolat korlátozásai miatt, vagy ha a Git-szolgáltató nem támogatja a szükséges SSH-kódtárakat, használjon dedikált szolgáltatásfiókot, és társítson egy API-kulcsot a Flux-fiókhoz. Ha a GitHub használatakor az SSH alternatívára van szüksége, létrehozhat egy személyes hozzáférési jogkivonatot a hitelesítéshez.
  • Konfigurálja a fürt feladatainak megfelelő ágszabályzatokat és engedélyeket. A módosítások jóváhagyásához állítsa be a véleményezők minimális számát.
  • Konfiguráljon egy PR-folyamatot a YAML-konfigurációk és szintaxis ellenőrzéséhez, és opcionálisan telepítsen egy teszt Kubernetes-fürtöt. Állítson be egy olyan ágházirendet, amely megköveteli, hogy a folyamat sikeresen fusson az egyesítés elfogadása előtt.
  • Titkos kulcsok implementálása az Azure Key Vault-szolgáltató titkos kulcstár CSI-illesztőprogramjával, amely lehetővé teszi az Azure Key Vault titkos tárként való integrálását egy Azure Arc-kompatibilis Kubernetes-fürttel egy CSI-köteten keresztül.
  • A Flux-bővítmény támogatja a névteret és a fürt hatókörű konfigurációit. Válassza ki a névtér hatókörét, ha a konfigurációnak nem szabad egyetlen névtéren túli hozzáféréssel rendelkeznie.

Következő lépések

A hibrid és többfelhős felhővel kapcsolatos további információkért tekintse meg az alábbi cikkeket.