A Kubernetes egyik legfontosabb eleme a vezérlősík (control plane) megfelelő működése. Ez a komponenscsoport gondoskodik arról, hogy a klaszter (cluster) aktuális állapota mindig összhangban legyen a kívánt állapottal. Nézzük meg a vezérlősík fő részeit, azok működését és szerepét a Kubernetes-ökoszisztémában.
Mi az a vezérlősík?
A vezérlősík az a logikai réteg, amely a teljes fürt irányításáért felelős. Olyan kapszulák (pod-ok) összessége, amelyek különböző folyamatokat (pl. API-kiszolgálás, ütemezés, állapotkezelés) futtatnak. Minden művelet ezen keresztül történik, legyen szó felhasználói kérésről vagy a rendszer belső kommunikációjáról.
Főbb vezérlősík-komponensek
kube-apiserver
A kube-apiserver a Kubernetes API bejárata. Ez az egyetlen komponens, amely közvetlenül kommunikál az etcd-adatbázissal, és minden kérést rajta keresztül kell lebonyolítani.
Feladatai:
Kérések fogadása és érvényesítése (mind felhasználói, mind rendszeroldali)
A REST API műveletek kiszolgálása
Az objektumok állapotának frissítése az etcd-ben
A Kubernetes v1.18-as verziójától kezdődően a Konnectivity szolgáltatás külön tudja választani a felhasználói és rendszerforgalmat, bár a legtöbb hálózati bővítmény még nem teszi ezt meg, ami hatással lehet a teljesítményre és a biztonságra.
A Kubernetes aktuális verzióiról az alábbi hivatalos cikkben olvashatsz.
kube-scheduler
Ez a komponens dönti el, hogy melyik csomóponton fusson egy új kapszula. A döntést egy algoritmus hozza meg az alábbi tényezők alapján:
A döntés nem garantálja az azonnali elindulást, például ha egy adott erőforrás még nem áll rendelkezésre, vagy nincs elegendő szerverkapacitás.
etcd
Az etcd egy nagy teljesítményű kulcs-érték (key-value) tároló, amelyben a Kubernetes tárolja a teljes fürt állapotát. Tulajdonságai:
B-fa alapú adattárolás, módosítás helyett új értékek hozzáfűzése
Verziókezelés és ütközéskezelés: ha több kérés érkezik, csak az első sikeres, a többi 409-es hibával tér vissza
Leader-alapú konszenzus: az egyik példány vezér szerepben van, a többiek követők vagy tanulók (learners)
Mivel az etcd a fürt perzisztens állapotának egyetlen forrása, rendszeres biztonsági mentés (snapshot) javasolt karbantartás előtt.
kube-controller-manager
Ez a vezérlőhurok (control loop) démon több különálló vezérlőt futtat. Ezek felelősek azért, hogy az aktuális állapot megfeleljen a kívánt állapotnak.
Példák:
Névtér- (namespace) és replikavezérlő
Végpontok (endpoints) kezelése
A komponens folyamatosan figyeli az állapotot, és szükség esetén beavatkozik.
cloud-controller-manager
Ez egy opcionális komponens, amely a felhőszolgáltatókkal (pl. Azure, AWS, GCP) való integrációt kezeli. Lehetővé teszi, hogy a felhő specifikus műveletek ne befolyásolják a Kubernetes alapműködését.
Jellemzők:
Külső (out-of-tree) vagy belső (in-tree) telepítés
A kubelet elindításához meg kell adni a --cloud-provider=external kapcsolót
Bővíthető saját megvalósítással
CoreDNS
A Kubernetes DNS-szolgáltatása. Felváltotta a korábbi kube-dns megoldást. Rugalmas, bővíthető, összefűzött plugineken keresztül oldja meg a névfeloldást, „szolgáltatásfelfedezést” és más, hálózattal kapcsolatos funkciókat.
Kiegészítők és bővítmények
A vezérlősík alapkomponensein kívül egyes bővítmények is elengedhetetlenek a termelési cluster-ekben, például:
Ezek közül nem mindegyik natív Kubernetes-komponens, de erősen ajánlottak a stabil működéshez.
Felügyelt Kubernetes-szolgáltatások
A felügyelt Kubernetes-szolgáltatások esetén – mint például az Azure Kubernetes Service (AKS), Amazon EKS vagy Google Kubernetes Engine (GKE) – a vezérlősík (control plane):
nem hozzáférhető,
nem számlázott külön tételként (vagy korlátozottan),
láthatatlanul működik a háttérben,
és a felhőszolgáltató üzemelteti és frissíti automatikusan.
Ez a felhasználók számára azt jelenti, hogy:
Nem kell gondoskodniuk az etcd, kube-apiserver, scheduler stb. frissítéséről, biztonságáról, skálázásáról.
A teljes klaszter vezérlése API-n keresztül történik, de annak háttér-infrastruktúráját a szolgáltató kontrollálja.
A látható és menedzselhető réteg a munkavégző csomópontok (worker nodes) és a rajtuk futó kapszulák.
Összegzés
A vezérlősík biztosítja a Kubernetes fürt szívverését. Komponensei szorosan együttműködnek annak érdekében, hogy az alkalmazások megbízhatóan, skálázhatóan és konzisztensen fussanak.
A vezérlősík megértése nélkülözhetetlen minden Kubernetes-adminisztrátor vagy DevOps szakember számára.
Az elmúlt hetekben, hónapokban már sokat olvashattatok a Kubernetes-ről. Azt már mindenki fejből tudja, hogy a Kubernetes egy nyílt forráskódú konténer-orchestrációs rendszer, amely lehetővé teszi a modern, skálázható alkalmazások automatikus telepítését, kezelését és méretezését. Ebben a bejegyzésben a Kubernetes fürt (cluster) fő összetevőit mutatom be, kicsit másképp ahogy esetleg eddig tettem.
Eddig inkább a szerver szintű szerepkörökről és a nagyobb komponensekről beszéltünk. Ideje azonban kicsit mélyebbre ásni.
A Kubernetes-fürt felépítése
Egy Kubernetes-fürt legalább a vezérlősíkból (control plane) és egy vagy több munkavégző csomópontból (worker node) áll. Minden komponens úgy van megtervezve, hogy API-hívásokkal együttműködve biztosítsa az automatizált működést.
A fürt főbb elemei:
Vezérlősík és munkavégző csomópontok
A vezérlősík az agy: feladatai közé tartozik a döntéshozatal, az állapotfigyelés és a feladatkiosztás. A legfontosabb komponensek:
kube-apiserver: az API-hívások belépési pontja, a fürt „művészebejárója”.
etcd: egy elosztott kulcs-érték adatbázis, amely a fürt állapotát tárolja.
kube-scheduler: eldönti, melyik munkavégző csomóponton induljanak el az új kapszulák.
kube-controller-manager: különböző vezérlők futtatása (pl. replikáció, csomópontkezelés).
cloud-controller-manager (felhőalapú környezeteknél): integráció a felhőszolgáltatóval.
A munkavégző csomópontokon futnak a valódi alkalmazáskonténerek. Ezek fő elemei:
kubelet: kapcsolatot tart az aggyal, gondoskodik a kapszulák futtatásáról.
konténerfuttató: például containerd vagy CRI-O, amely ténylegesen futtatja a konténereket.
Vezérlők (operators)
Az operátorok magas szintű vezérlőprogramok, amelyek egy alkalmazás teljes életciklusát kezelik. Az operátorok Kubernetes API-kra épülnek, és képesek komplex alkalmazások kezelésére úgy, mintha beépített Kubernetes-erőforrások lennének.
Szolgáltatások (services)
A szolgáltatás egy állandó hálózati elérhetőséget biztosít a kapszulák számára. Mivel a kapszulák újraindulhatnak és IP-címük változhat, a szolgáltatás stabil interfészként szolgál.
Típusai:
ClusterIP (belső elérés)
NodePort (külső elérés egy adott porton)
LoadBalancer (felhőalapú betöltéselosztás)
Kapszulák (pods)
A legkisebb végrehajtható egység. Egy kapszula egy vagy több konténert tartalmazhat, amelyek közös IP-címet, fájlrendszert és hálózati környezetet használnak.
A kapszulák rövid életűek és általában replikációs kontrollerek (replica set) vagy telepítések (deployments) által menedzseltek.
Névterek (namespaces) és kvóták
A névterek lehetővé teszik a fürtön belüli erőforrások logikai elhatárolását. Ideálisak például több környezet (pl. fejlesztés, teszt, éles) elkülönítésére.
A kvóták szabályozzák, mennyi erőforrást (CPU, memória, tárolás stb.) használhat egy névtér. (ezen kívül még máshol is lesz szerepe)
Hálózat és házirendek
Minden kapszula teljes mértékben elérheti a többi kapszulát az IP-címükön keresztül – ez a Kubernetes hálózati modell alapelve. A hálózati beállításokat egy plugin (pl. CNI) kezeli.
A hálózati házirendek (NetworkPolicies) szabályozzák, hogy mely kapszulák kommunikálhatnak egymással.
Tárolás (storage)
A tárolási rendszer lehetővé teszi, hogy a kapszulák tartós adatokat használjanak. Ezek lehetnek:
Volatile tárolók (pl. emptyDir)
Állandó kötés (Persistent Volume)
Dinamikus provizionálás (StorageClass)
A tárolást gyakran egy külső szolgáltatás biztosítja (pl. NFS, iSCSI, felhőalapú tárhelyek).
Ezek akkor fontosak, amikor olyan alkalmazásokat futtatunk a cluster-en, amelyeknél fontos az adatok hosszútávú és biztonságos tárolása. Ilyen például egy adatbázis megoldás. (MySQL, MariaDB, stb.)
Egybinárisos architektúra
Több Kubernetes disztribúció kínál „egybinárisos” megoldást, ahol a Kubernetes összetevői egyetlen bináris fájlban kerülnek egyesítésre. Ez különösen hasznos lehet teszteléshez, lokális fejlesztéshez vagy különleges környezetekhez.
Verziófrissítés és kompatibilitás
A fürt frissítése során figyelembe kell venni, hogy az egyes komponenseket külön csapatok fejlesztik, és szorosan illeszkednek egymáshoz. A verziók inkompatibilitása működési hibákat okozhat.
A kubeadm upgrade plan parancs segítségével biztonságosan megtervezhető a frissítés. (Erről is hamarosan lesz cikk.)
Összefoglalás
A Kubernetes egy összetett rendszer, de jól strukturált fő komponensei lehetővé teszik a hatékony, megbízható konténerkezelést. A vezérlősík, munkavégző csomópontok, szolgáltatások, kapszulák és egyéb elemek együttműködésével a fürt képes skálázni, hibatűrő módon működni, és automatizált módon kiszolgálni a modern alkalmazásokat.
Ha szeretnél továbblépni, érdemes gyakorlatban is kipróbálni egy mini-fürtöt akkor több lehetőség közül is választhatsz. Erről itt írtam.
Hidd el! Amint belekóstolsz ebbe a világba, nem fogod tudni abbahagyni. 🙂
Ahogy egyre több alkalmazás kerül a felhőbe, úgy válik egyre fontosabbá a konténeresítés. Az Amazon ECS (Elastic Container Service) egy felügyelt konténer-orchesztrációs szolgáltatás, amely megkönnyíti a Docker konténerek futtatását és skálázását az AWS felhőben. Ez a cikk azoknak szól, akik most ismerkednek a konténer technológiákkal, és egy egyszerű, de erőteljes megoldást keresnek az alkalmazásaik futtatására.
Mi az Amazon ECS?
Az Amazon ECS egy olyan szolgáltatás, amely lehetővé teszi konténerek indítását és kezelését anélkül, hogy külön infrastruktúrát kellene kiépíteni vagy menedzselni. Teljes mértékben integrálódik más AWS szolgáltatásokkal, mint például az IAM (jogosultságkezelés), CloudWatch (monitorozás), és az ALB (Application Load Balancer).
Az ECS kétféleképpen használható:
EC2 mód (IaaS): saját virtuális gépeken futtatott konténerekkel, ahol az infrastruktúra kezelése a felhasználó feladata.
Fargate mód (PaaS):serverless megközelítés, ahol az AWS gondoskodik a háttér-infrastruktúráról. A felhasználónak csak a konténert kell megadnia.
Az Amazon ECS előnyei
Felügyelt szolgáltatás: nem kell külön telepíteni vagy frissíteni konténer-orchesztrációs rendszereket.
Fargate támogatás: a serverless konténerfuttatás révén nincs szükség szerverek kezelésére.
Integráció AWS szolgáltatásokkal: könnyen összekapcsolható más szolgáltatásokkal (IAM, VPC, ALB, CloudWatch stb.).
Skálázhatóság: automatikus skálázás és beépített magas rendelkezésre állás.
Biztonság: IAM alapú hozzáférés-szabályozás és hálózati izoláció VPC-n belül.
Korlátai és kompromisszumok
Csak AWS-en működik: nem multicloud vagy hybrid környezetre optimalizált.
Kisebb ökoszisztéma, mint Kubernetes: kevesebb plugin és közösségi megoldás érhető el.
ECS vs EKS: ha már van Kubernetes tapasztalatod, az EKS lehet jobb választás, de bonyolultabb is.
Ha AWS ökoszisztémában dolgozol, és szeretnél stabil, jól skálázható és biztonságos konténeres megoldást, akkor az ECS remek választás. Különösen akkor ajánlott, ha mikroservice architektúrával dolgozol, vagy CI/CD pipeline-t szeretnél integrálni konténeres környezetbe.
Felhasználási példa
Képzeld el, hogy egy webshop backend API-t szeretnél futtatni konténerekben. A szolgáltatásokat – például a termékkezelést, kosár funkciókat és fizetési modulokat – külön konténerekbe szervezed. Az Amazon ECS segítségével ezeket Fargate-en futtathatod úgy, hogy nem kell szervereket kezelned. Az ALB segítségével terheléselosztást is beállíthatsz, a CloudWatch pedig biztosítja a monitorozást
Egyszerű webalkalmazás futtatása Amazon ECS-ben
Ha szeretnéd kipróbálni az Amazon ECS-t, íme egy alap példa, amellyel egy publikus Docker képből (pl. Nginx) indíthatsz el egy futó szolgáltatást:
1. Lépj be az AWS Console-ba
Nyisd meg az ECS konzolt és válaszd az „ECS” szolgáltatást.
2. Kattints a „Create Cluster” gombra
Adj nevet a clusternek, pl. webalkalmazas.
Válaszd a AWS Fargate (serverless) lehetőséget
Kattints a „Create” gombra.
3. Hozz létre egy Task Definition-t
Bal oldalon menj a „Task Definitions” menüpontra.
Kattints a „Create new Task Definition” gombra.
Task definition family mezőben adj meg egy nevet, pl. web-szerver
Válaszd a „AWS Fargate” típust.
Task role: válaszd a ecsTaskExecutionRole-t (ha nincs, hozz létre az AWS útmutató alapján).
Add meg a következő konténer konfigurációt:
Container name: nginx
Image:nginx
Port mappings: 80 → 80
Kattints a „Create” gombra.
4. Hozz létre egy szolgáltatást (Service)
Menj vissza a Clusterekhez, nyisd meg a webalkalmazas-t.
Válaszd a „Create” → „Service” opciót.
Launch type: Fargate
Task definition: válaszd ki az web-szerver definíciót
Service name: web-szolgaltatas
Number of tasks: 1
5. Hálózat és elérhetőség beállítása (opcionális)
VPC: válaszd ki az alapértelmezett VPC-t (vagy sajátot, ha van).
Subnet: válassz legalább egyet.
Public IP: engedélyezd (Turned on), hogy elérhető legyen internetről is.
6. Indítsd el a szolgáltatást
Kattints a „Create” gombra. Néhány perc múlva a konténer futni fog.
7. Nyisd meg a böngésződben Menj a futó Task részleteihez, és másold ki a hozzá rendelt publikus IP címet. (Clusters > webalkalmazas > Tasks > az ott szereplő task neve > Networking > Public IP)
Nyisd meg a böngésződben – meg kell jelennie az Nginx alapértelmezett kezdőoldalának.
Ezzel egy teljesen működő konténeres webalkalmazást indítottál el, szerverek kezelése nélkül. Látod, milyen egyszerű az első lépések megtétele az Amazon ECS-sel?
Összefoglalás
Az Amazon ECS egy jól integrált, rugalmas és skálázható megoldás azok számára, akik konténerekkel szeretnének dolgozni az AWS-en. Egyszerűbb, mint a Kubernetes, de elég erős nagyvállalati környezetekhez is. Ha AWS-t használsz, és stabil konténerkezelésre van szükséged, az ECS jó választás lehet.
Itt a blogon sok konténer megoldásról és Docker megoldásról olvashattál már. Ez nem véletlen, hiszen ez a technológia rengeteg lehetőséget rejt, amelyek mind személyes, mind üzleti oldalon. A mikroszolgáltatásokat talán nem kell bemutatni, amely szintén a mai modern informatika egyik alap pillére. Gondolhatunk azonnal a Kubernetes-re, mert az a legnagyobb és legismertebb ezen a területen, de nem mindig van szükség ekkora komplexitásra, ha csupán egy-egy gyors alkalmazást szeretnénk futtatni. És itt jön képbe a mai cikkünk témája.
Az Azure Container Instance (ACI) egy felhőalapú szolgáltatás, amely lehetővé teszi, hogy konténereket futtassunk anélkül, hogy teljes környezetet – például virtuális gépet vagy Kubernetes-fürtöt – kellene telepítenünk és kezelnünk. Ideális választás lehet azok számára, akik egyszerűen, gyorsan és átmenetileg szeretnének konténeres alkalmazásokat futtatni.
Mi is az Azure Container Instance?
Az ACI a Microsoft Azure egyik platformszolgáltatása (PaaS), amely konténerizált alkalmazások futtatására alkalmas. Használata során nem kell foglalkoznunk az infrastruktúra kezelésével, csak megadjuk a konténerkép nevét (pl. egy Docker image), a kívánt erőforrásokat (CPU, memória), és az Azure elindítja számunkra a konténert.
Az Azure Container Instance támogatja a publikus Docker képeket a Docker Hub-ról és a Microsoft saját registry-jéből (pl. mcr.microsoft.com). Emellett használhatunk privát registry-ből (például Azure Container Registry vagy más hitelesített tároló) származó image-eket is, ha megadjuk a hozzáférési adatokat. Az kép forrását egyszerűen megadhatjuk az ACI létrehozásakor.
Előnyök és lehetőségek
Egyszerűség és gyorsaság Az ACI lehetővé teszi konténerek futtatását perceken belül. Nincs szükség cluster-re, orchestrator-ra vagy hosszadalmas konfigurálásra.
Rugalmasság Csak az erőforrások után fizetünk, amit ténylegesen használunk. Az ACI támogatja a Linux és Windows konténereket is.
Integráció Könnyedén kombinálható más Azure szolgáltatásokkal, például Azure Logic Apps, Functions, vagy akár Azure Virtual Network (VNET) integrációval is elérhetővé tehetjük belső rendszerekből.
Automatikus skálázás helyett egyszerű példányindítás Az ACI nem kínál automatikus horizontális skálázást, de nagyon jól használható, ha fix (előre megadott) példányszámmal vagy rövid élettartamú konténerekkel dolgozunk.
Korlátai
Nem alkalmas komplex, skálázható mikroszolgáltatás-architektúrák futtatására
Nincs beépített támogatás replikák, autoscaling vagy rollout stratégiák kezelésére
A konténerek állapota nem menedzselhető úgy, mint Kubernetes esetén (nincs önjavítás, nincs deployment stratégia)
Egyszerű összehasonlítás a Kubernetes-szel
Tulajdonság
Azure Container Instance
Azure Kubernetes Service (AKS)
Telepítési idő
percek
órák, akár komplex beállítások
Skálázás
manuális
automatikus, fejlett vezérlés
Infrastrukturális háttér
rejtett, Azure kezeli
felhasználó menedzseli részben
Tanulási görbe
alacsony
meredekebb
Üzemeltetés
minimális
összetett
Mikor érdemes használni az Azure Container Instance-ot
Az ACI kiváló választás, ha:
Egy egyszerű REST API-t vagy mikroalkalmazást szeretnénk gyorsan kipróbálni
Egyszeri vagy időszakos batch-feladatokat szeretnénk futtatni (pl. képfeldolgozás, adatkonvertálás)
CI/CD pipeline során szeretnénk ideiglenes build vagy teszt környezetet indítani
Kevés erőforrásigényű feladatokat szeretnénk futtatni felügyelet nélkül
Konkrét példa felhasználásra
Tegyük fel, hogy egy webalkalmazásban a felhasználók képeket töltenek fel, amelyeket különféle szűrőkkel kell feldolgozni. A képfeldolgozást egy konténerbe csomagolt Python script végzi, amelyet minden alkalommal újraindítunk, amikor egy új képet kapunk. Ilyen esetben ACI tökéletes, hiszen nem kell állandóan futtatnunk a feldolgozót, csak akkor, amikor valóban szükség van rá. Ráadásul mivel az erőforrásigény kicsi és futási idő rövid, költséghatékony is.
Próbáld ki Te is: saját konténer futtatása 5 perc alatt
Kattints a Felülvizsgálat + létrehozás, majd Létrehozás gombra
Pár perc múlva az ACI példány elkészül. Az elérési URL-t megkapod, például így nézhet ki: http://szia-laci.e5gsghbgaygzabaw.swedencentral.azurecontainer.io
Nyisd meg ezt az URL-t a böngésződben, és máris látni fogod a konténer által szolgáltatott weboldalt.
Összegzés
Az Azure Container Instance egy könnyen használható, gyors megoldás konténerek futtatására. Ideális kisebb feladatokhoz, teszteléshez, fejlesztéshez vagy időszakos folyamatokhoz. Ha azonban komplexebb architektúrában gondolkodunk, ahol skálázás, önjavítás, rollout kezelés is fontos, akkor érdemes a Kubernetes irányába tovább lépni.
Ez a technológia tökéletes belépő lehet azoknak, akik most ismerkednek a konténerekkel vagy éppen az Azure környezetet szeretnék kihasználni egyszerűbb alkalmazásokhoz. A portálos példa segít abban, hogy akár technikai háttértudás nélkül is sikerélményt szerezzünk az első konténerindítással.
A Kubernetes indulása óta példátlan ütemben fejlődik és terjed. A projekt mögött álló közösség – fejlesztők, felhasználók, tesztelők és lelkes támogatók – folyamatosan növekszik, napról napra egyre többen csatlakoznak ehhez az ökoszisztémához.
A Kubernetes szoftver maga is rendkívül gyorsan fejlődik. Ez a gyors tempó olyan intenzív, hogy még a GitHub infrastruktúráját is próbára teszi, ahol a projekt kódját fejlesztik.
Mi jellemzi ezt az innovációt?
Üzleti szempontból az alapértelmezett megoldásként tekintenek rá: ma már a legtöbb modern, felhőalapú infrastruktúrát építő vállalat Kubernetesre épít.
Több tízezer közreműködő dolgozik a fejlesztésén világszerte – ezzel az egyik legaktívabb nyílt forráskódú projekt.
Százezres nagyságrendű commit (kódmódosítás) történt eddig a kódbázison.
Slack közösségében is tízezrek aktívak, folyamatosan kérdeznek, segítenek és megosztják tapasztalataikat.
Négyhavonta jelenik meg egy új, kisebb (minor) verzió a Kubernetesből.
Körülbelül tíznaponta érkezik egy javítócsomag (patch release), amely hibajavításokat vagy kisebb módosításokat tartalmaz.
Gazdag ökoszisztémával rendelkezik: több száz kapcsolódó projekt létezik, amelyek tovább bővítik és testre szabják a Kubernetes lehetőségeit – ezek közül sokat a CNCF (Cloud Native Computing Foundation) koordinál.
Miért fontos ezt tudni?
Aki korábban monolitikus, egyetlen gyártótól származó, lassan változó rendszerekkel dolgozott, annak kihívás lehet megszokni ezt a dinamikus környezetet. A Kubernetes világában ugyanis a változás állandó.
Ha valaki egy klasztert üzemeltet vagy fejleszt rá, elengedhetetlen, hogy:
tisztában legyen az új verziók jelentésével,
rendszeresen tesztelje a frissítéseket,
és naprakész maradjon az ökoszisztéma változásaival kapcsolatban.
További lehetőségek, ahol tanulhatsz és fejlődhetsz
A CNCF (Cloud Native Computing Foundation) weboldalán elérhető egy részletes lista az összes hivatalos cloud-native projektről, amelyek valamilyen formában kapcsolódnak a Kuberneteshez. Ezek között találhatók olyan eszközök, amelyek:
megkönnyítik a klaszterek menedzselését,
segítik az alkalmazások monitorozását,
vagy lehetővé teszik a biztonságos hálózati kommunikációt.
Egyre jobban körvonalazódik, hogy ez egy időtálló termék. Szerinted érdemes lenne megtanulni? 🙂
Miután megismertük a Kubernetes alapvető architektúráját, érdemes néhány kulcsfontosságú fogalommal is megismerkedni. Ezekkel az objektumokkal később is dolgozunk majd, de már most hasznos, ha megértjük, hogyan illeszkednek a teljes rendszerbe.
Mi is az a Kubernetes?
A Kubernetes egy konténer-orchesztrációs rendszer, amelyet arra terveztek, hogy automatizálja a konténerek telepítését, kezelését, skálázását és frissítését. Fontos megérteni, hogy a Kubernetes nem egyesével kezeli a konténereket, hanem úgynevezett Podokba csoportosítva.
Pod
A Pod a Kubernetes legkisebb egysége, amely egy vagy több konténert tartalmaz. Ezek a konténerek:
azonos IP-címen osztoznak,
közösen használják a tárolókat (volumes),
ugyanabba a névtérbe (namespace) tartoznak.
Általában egy Pod egy alkalmazást futtat, míg a többi konténer segédszolgáltatásokat nyújthat hozzá (például loggyűjtés, proxy, stb.).
Namespace – névterek
A namespace, vagy magyarul névtér egy logikai szeparációs eszköz a Kubernetesben. Fő célja:
az erőforrások elkülönítése (pl. fejlesztés, teszt, éles környezet),
a több bérlős környezetek (multi-tenant) biztonságos kezelése,
jogosultságok és kvóták könnyebb szabályozása.
Vannak klaszter szintű objektumok (pl. node-ok), és olyanok is, amelyek csak egy namespace-hez tartoznak. Ha különböző namespace-ekben lévő Podok szeretnének kommunikálni egymással, ahhoz Service objektumokra van szükség.
Orchestráció és vezérlők (operators)
A Kubernetes vezérlését úgynevezett „watch-loopokkal”, azaz operátorokkal végzi. Ezek figyelik a kube-apiserver állapotát, és ha eltérés van az elvárt (deklarált) és a valós állapot között, akkor lépnek közbe.
A leggyakoribb operátor típusok:
Deployment: konténerek kezelése (nem közvetlenül a Podokkal dolgozik).
ReplicaSet: a Podok darabszámát kezeli a megadott sablon (podSpec) alapján.
Kubelet: a node-on futó ügynök, amely végrehajtja a podSpec utasításait (pl. konténer letöltés, indítás, leállítás).
Az alapértelmezett és legtöbbet használt operátor a Deployment, amely biztosítja, hogy az alkalmazás mindig a kívánt példányszámban és konfigurációval fusson.
Custom Resource Definitions (CRD)
Ha a beépített vezérlők nem elegendők, akkor saját típusú erőforrásokat és operátorokat is létrehozhatunk. Ezt CRD-nek (Custom Resource Definition) nevezzük, és ezáltal bővíthetjük a Kubernetes képességeit.
A Kubernetesben a Service objektum biztosítja a hálózati elérhetőséget a Podok között, különböző namespace-ek között, vagy a klaszteren kívülről.
Label alapú működés: a Service címkék alapján találja meg a hozzá tartozó Podokat.
A Service a Endpoint operátortól szerzi meg a Podok IP-címeit és elérési információit.
A Service tehát egyfajta virtuális IP-címként viselkedik, ami mögött a megfelelő Pod(ok) állnak.
Címkék (Labels) és azonosítók
A Kubernetesben nehézkes lenne több ezer Pod vagy objektum kezelése, ha mindig név vagy UID alapján kellene hivatkozni rájuk. Ezért:
használhatunk címkéket (labels) – tetszőleges kulcs-érték párok, melyek az objektum metaadataihoz tartoznak.
így például egy parancs segítségével kiválaszthatunk minden olyan Podot, amelynek az app=web címkéje van, anélkül hogy ismernénk a nevüket.
Taints és tolerations
Az egyes node-ok megjelölhetők úgynevezett taint-ekkel, hogy elkerüljék a Podok automatikus ütemezését oda. Ha egy Pod mégis ilyen node-on szeretne futni, akkor az objektum toleration beállításával jelezheti, hogy elfogadja ezt a környezetet.
Ez az alapismereteket bemutató rész egy fontos lépcsőfok ahhoz, hogy megértsük, hogyan működik a Kubernetes rendszerszinten. A későbbi gyakorlati példákban ezek a fogalmak újra és újra elő fognak kerülni.
Ugye milyen izgalmas ez a világ? És még csak most kezdtük el…
Ahhoz, hogy valóban megértsük, hogyan működik a Kubernetes, érdemes közelebbről is megvizsgálni az architektúráját. Az alábbi ábra a Kubernetes komponenseit mutatja be magas szinten, vagyis egy áttekintő képet ad arról, hogy milyen főbb részekből áll a rendszer. Fontos megjegyezni, hogy az ábrán nem szerepel minden komponens, például a hálózati bővítményekért (network plugin) felelős elemek külön kerülnek bemutatásra.
A Kubernetes felépítése – egyszerűen
A Kubernetes alapvetően két fő részre osztható:
Control plane – ez a „központi agy”, amely irányítja a klasztert.
Worker nodes – A „munkavégzők” futtatják ténylegesen a konténereket.
A control plane egy vagy három (nagy megbízhatóság esetén három) különálló csomópontból állhat. Ezeket gyakran „cp node”-ként is említjük. A worker csomópontokból tetszőleges számú lehet – ezek a rendszer skálázhatóságának alapját adják.
Később majd bemutatjuk, hogyan lehet akár egyetlen gépen is kipróbálni az egész klasztert, ami fejlesztéshez és teszteléshez kiváló.
Mi történik a központi agyban?
A control plane legfontosabb szerepe, hogy irányítsa és koordinálja az egész klasztert. Itt található többek között:
API szerver (kube-apiserver): ez a rendszer „kapuja”, amelyen keresztül minden külső és belső komponens kommunikál. Minden parancs, amit kiadunk (pl. kubectl segítségével), az API szerverhez fut be.
Ütemező (kube-scheduler): ez a komponens dönt arról, hogy melyik worker csomóponton fusson le egy adott konténer. A döntés alapja lehet az erőforrás-kihasználtság, címkék, korlátozások stb.
Vezérlők (controller manager): ezek a háttérben futó folyamatok figyelik az állapotokat (pl. egy pod leállt), és gondoskodnak arról, hogy a klaszter mindig az elvárt állapotban legyen.
Tárolórendszer (etcd): ez egy kulcs-érték adatbázis, amely az egész klaszter állapotát tárolja – például hogy milyen podok futnak, milyen beállításokkal.
Mi történik a munkavégző csomópontokon?
Minden worker node két fő komponenst futtat:
kubelet: ez egy olyan folyamat, amely figyeli a node-hoz tartozó podokat, és gondoskodik arról, hogy azok megfelelően fussanak. A kubelet letölti a szükséges konténerképeket, előkészíti az erőforrásokat, és a helyi konténer futtatómotor (pl. containerd) segítségével elindítja a konténereket.
kube-proxy: ez felelős a hálózati szabályokért, például hogy a podok hogyan érik el egymást vagy a külvilágot. A kube-proxy a választott hálózati bővítménnyel (pl. CNI plugin) együttműködve kezeli ezeket a szabályokat.
Rugalmas kommunikáció – nem csak Linuxon
A Kubernetes legnagyobb ereje az API-alapú kommunikációs modellje, amely lehetővé teszi, hogy a klaszter különféle típusú rendszereket is kezeljen. Bár a vezérlősík kizárólag Linuxon futhat, a munkavégző csomópontokon akár Windows Server 2019, 2022 vagy 2025 is használható. Ez lehetővé teszi, hogy vegyes környezetben is használjuk a Kubernetes-t, például ha Windows-alapú alkalmazásokat is szeretnénk konténerizálni.
Ha eddig azt gondoltad, hogy csak Linux-on lehet Docker konténereket futtatni, akkor itt a példa, hogy a Windows is egy igen jó alternatíva. 🙂
A modern alkalmazásfejlesztés egyik alappillére a konténerizáció. Az olyan eszközök, mint a Docker, lehetővé teszik, hogy alkalmazásainkat izolált, skálázható konténerekben futtassuk. A konténerizációhoz azonban szükség van egy megbízható tárhelyre, ahol a konténerképeket tárolhatjuk, kezelhetjük és megoszthatjuk.
Pontosan ezt a bevezetőt írtam az AWS ECR-ről szóló cikkben is. Úgy gondoltam, hogy ebben sem lesz ez másképp. Most azonban az Azure tárólóregisztrációs adatbázisáról lesz szó, az ACR-ről.
Az Azure Container Registry (ACR) egy teljes mértékben felügyelt, privát konténerregiszter az Azure felhőplatformon, amely lehetővé teszi a Docker és OCI (Open Container Initiative) kompatibilis konténerek tárolását és kezelését. Az ACR különösen hasznos azoknak, akik Kubernetes-t (AKS – Azure Kubernetes Service) vagy más konténeres megoldásokat használnak, de kezdők számára is könnyen érthető és kezelhető.
Miért van szükség az ACR-re?
A konténerizált alkalmazások egyik alapvető eleme a konténerregiszter, amely a konténerképek tárolására és elérhetővé tételére szolgál. Bár használhatunk publikus tárolókat is, például a Docker Hub-ot, a vállalati vagy biztonsági szempontból érzékeny környezetekben érdemes egy privát megoldást választani, mint az ACR.
Előnyei:
Privát és biztonságos: Csak az engedélyezett felhasználók és szolgáltatások férhetnek hozzá.
Azure integráció: Könnyen csatlakoztatható Azure Kubernetes Service-hez (AKS), App Service-hez és más Azure szolgáltatásokhoz.
Automatizált építés és frissítés: Beállíthatunk automatikus képépítést és frissítést webhookok vagy DevOps pipeline-ok segítségével.
Geo-replikáció: Több régióban is elérhetővé tehetjük a konténerképeket.
Az ACR struktúrája
Az ACR egy hierarchikus struktúrát követ, amely lehetővé teszi a különböző konténerképek és adattárolók rendezett kezelését:
Registry: Az ACR legfelső szintje, amely az összes tárolt képet kezeli.
Repository: Egy adott alkalmazás vagy verziótároló helye, ahol különböző verziójú képek találhatók.
Tag-ek: A különböző verziókat és build-eket azonosítják, például node-webapp:3.0.0, node-webapp:latest.
Hogyan tölthetek fel képet az ACR-be?
Ha van egy helyi Docker image, amelyet szeretnénk az ACR-be feltölteni:
Tag-elés az ACR nevével:
docker tag node-webapp:4.0.0 acrregistryneve.azurecr.io/node-webapp:4.0.0docker tag node-webapp:4.0.0 acrregistryneve.azurecr.io/node-webapp:latest
az acr repository list --name acrregistryneve --output table
Alkalmazás indítása az ACR-ben tárolt képből
A legegyszerűbb módja egy ACR-ben tárolt konténer futtatásának az Azure Container Instances (ACI) használata. Az ACI lehetővé teszi, hogy néhány parancs segítségével elindítsuk az alkalmazásunkat anélkül, hogy egy teljes Kubernetes klasztert kellene kezelni.
ACI erőforrás létrehozása és az ACR-ből való kép futtatása
az container show --resource-group eroforrascsoport --name node-container --query "{FQDN:ipAddress.fqdn}" --output table
Ez az egyszerű megoldás lehetővé teszi, hogy gyorsan és könnyedén futtassunk egy alkalmazást az ACR-ben tárolt képből anélkül, hogy mélyebb Kubernetes ismeretekre lenne szükség.
Életciklus és tárhely kezelés
Az ACR lehetőséget biztosít az életciklus és tárhely kezelésére:
Retention Policies: Beállíthatunk automatikus törlési szabályokat az elavult vagy nem használt képek eltávolítására.
Tiered Storage: Az ACR támogatja a különböző szintű tárhelyeket (Basic, Standard, Premium) az igényekhez igazítva.
Garbage Collection: Az ACR automatikusan törli a nem használt rétegeket, csökkentve ezzel a tárhelyhasználatot.
ACR integráció más Azure szolgáltatásokkal
Az ACR könnyen integrálható más Azure szolgáltatásokkal:
Azure Kubernetes Service (AKS): Automatikusan betölthető konténerképek az ACR-ből.
Azure DevOps: Pipeline-ok segítségével automatizálhatjuk a képépítést és publikálást.
Azure Functions: Konténerizált funkciók futtatása közvetlenül az ACR-ből.
Azure App Service: Webalkalmazások közvetlenül ACR-ből történő futtatása.
Összegzés
Az Azure Container Registry egy kiváló eszköz a konténerizált alkalmazások tárolására és kezelésére az Azure környezetben. Az ACR segítségével biztonságosan és hatékonyan dolgozhatunk konténerképekkel, integrálhatjuk azokat DevOps pipeline-okba, és közvetlenül felhasználhatjuk Azure szolgáltatásokban. Kezdőként érdemes kísérletezni az ACR használatával, és megtapasztalni, hogyan egyszerűsítheti a konténerkezelési folyamatokat.
Szerinted is jobb biztonságosan tárolni az alkalmazásainkat?
Mi az a DeepSeek? Egy új OpenAI modell? Nem! A DeepSeek egy hirtelen berobbant projekt, amely egyre nagyobb figyelmet kap az AI világában. A csapat célja, hogy nyílt forráskódú, nagy teljesítményű és költséghatékony AI-modelleket hozzanak létre, amelyeket a fejlesztők könnyen beépíthetnek saját rendszereikbe. Az egyik legújabb modelljük, a DeepSeek R1, mostantól elérhető az Azure AI Foundry-n, így egyszerűen kipróbálhatod és integrálhatod a saját alkalmazásaidba.
DeepSeek és Azure
A DeepSeek egy AI-kutatásra és fejlesztésre specializálódott csapat, amely nagyméretű nyelvi modelleket (LLM) és más AI-megoldásokat készít. Céljuk, hogy magas teljesítményű, nyílt forráskódú és költséghatékony AI-modelleket biztosítsanak a fejlesztők és vállalatok számára.
A DeepSeek R1 az egyik legújabb nyelvi modelljük, amely hatékony és könnyen használható, így lehetőséget ad a fejlesztőknek, hogy fejlett AI-funkciókat építsenek be alkalmazásaikba anélkül, hogy komoly infrastruktúrába kellene fektetniük.
Mostantól a DeepSeek R1 elérhető az Azure AI Foundry modellkatalógusában és a GitHub-on, így egyszerűen integrálható különböző AI-megoldásokba.
Ráadásul már magyar nyelven is elérhető hozzá a felület, ami még egyszerűbbé teszi a megismerést és a használatot.
Gyorsabb AI-fejlesztés az Azure AI Foundry-n
Az AI-technológia folyamatosan fejlődik, és egyre könnyebben elérhetővé válik. A DeepSeek R1 egy nagy teljesítményű és költséghatékony nyelvi modell, amely lehetővé teszi, hogy a felhasználók minimális infrastruktúrával kihasználják a mesterséges intelligencia előnyeit.
Ha az Azure AI Foundry platformon használod a DeepSeek R1-et, akkor gyorsan kísérletezhetsz, tesztelheted az eredményeket és skálázhatod az alkalmazásodat. A beépített eszközök segítenek az AI-modell teljesítményének mérésében és optimalizálásában.
A Microsoft célja, hogy az Azure AI Foundry egy olyan hely legyen, ahol a legjobb AI-modellek egy helyen elérhetőek, így a fejlesztők és vállalatok gyorsabban és hatékonyabban hozhatnak létre AI-alapú megoldásokat.
Biztonságos és megbízható AI
A DeepSeek R1 komoly biztonsági teszteken és ellenőrzéseken esett át, hogy minimalizálják a kockázatokat. Az Azure AI Content Safety automatikus tartalomszűrési rendszerrel is rendelkezik, amely alapértelmezetten be van kapcsolva, de igény szerint kikapcsolható.
Az Azure AI Foundry folyamatosan monitorozza az AI-modell kimeneteit, így a telepítés előtt és után is ellenőrizheted, hogy megfelelően működik-e. Ezzel biztosítjuk, hogy a platform biztonságos és megfelelőségi szempontból is vállalati szintű környezetet biztosítson.
Hogyan próbálhatod ki a DeepSeek R1-et?
Jelentkezz be az Azure Portálra, regisztrálj egy Azure AI Foundry projektet.
Keress rá a DeepSeek R1-re az Azure AI Foundry modellkatalógusában.
Nyisd meg a modell adatlapját.
Kattints a „Deploy” gombra, hogy megkapd az API-t és a hozzáférési kulcsot.
A telepítési oldalon pillanatok alatt megkapod a szükséges adatokat.
Próbáld ki a modellt a beépített playgroundban.
Használd az API-t különböző alkalmazásokkal és kliensekkel.
A DeepSeek R1 mostantól kiszolgáló nélküli, nyilvános végponton is elérhető az Azure AI Foundry-n. Kezdd el itt: Azure AI Foundry, és próbáld ki a DeepSeek modellt!
A GitHubon további forrásokat és részletes útmutatókat találhatsz a DeepSeek R1 integrációjáról, többek között az alábbi cikkben: GitHub Models.
Hamarosan a DeepSeek R1 könnyített verzióját is futtathatod helyben, a Copilot+ segítségével. További részletek a Windows Fejlesztői Blogon: Windows Developer Blog.
A Microsoft egyre nagyobb hangsúlyt fordít erre a területre és folyamatosan bővíti az Azure AI Foundry modellkatalógusát. Bevallom én is kíváncsian várom, hová fejlődik ez és, hogy a fejlesztők és vállalatok hogyan használják a DeepSeek R1-et valódi problémák megoldására. Az látszik, hogy a cél, hogy minden vállalkozás hozzáférjen a legmodernebb AI-megoldásokhoz, és a lehető legtöbbet hozza ki belőlük. Ezzel pedig egyértelműen az Azure felé terelik a felhasználókat.
Te használod már valamelyik AI megoldást vagy magát az Azure-t? 🙂
Az Azure-ban a felhőalapú erőforrások létrehozása és kezelése lehet manuális, de az igazi hatékonysága és vagánysága az automatizálásban rejlik. Az Azure Resource Manager (ARM) sablonok egy hatékony eszközt biztosítanak az infrastruktúra kód alapú kezelésére (Infrastructure as Code, IaC), amely lehetővé teszi az erőforrások deklaratív módon történő létrehozását, frissítését és kezelését.
Ebben a cikkben áttekintjük az ARM sablonok alapjait, erősségeit, valamint a egyéb lehetőségeket, mint a függvények használata, a beágyazott (nested templates) és a hivatkozott (linked templates) sablonok. Kitérünk arra is, hogyan lehet újrahasználni a sablonokat kisebb módosításokkal, illetve milyen korlátai vannak az ARM sablonoknak.
Milyen felhőszolgáltatási modellbe tartozik az ARM sablon?
Habár az ARM sablon egy eszköz, amellyel erőforrásokat hozunk létre, most a besorolást a létrehozható erőforrások alapján tesszük meg. Tehát az Infrastructure as a Service (IaaS) és Platform as a Service (PaaS) kategóriába tartozik attól függően, hogy milyen erőforrásokat telepítünk vele:
IaaS (Infrastructure as a Service): Ha virtuális gépeket, hálózati konfigurációkat vagy tárolókat hozunk létre ARM sablonok segítségével, akkor ezek az infrastruktúra réteghez tartoznak.
PaaS (Platform as a Service): Ha az ARM sablonokat például egy Azure App Service, Azure SQL Database vagy más menedzselt szolgáltatások telepítésére használjuk, akkor azokat a PaaS kategóriába sorolhatjuk.
Az ARM sablonok tehát rugalmasan használhatók mind az infrastruktúra, mind pedig az alkalmazási szintű szolgáltatások kezelésére az Azure környezetben.
Mi az az ARM sablon?
Az ARM sablon egy JSON formátumú fájl, amely deklaratívan írja le az Azure erőforrások konfigurációját. Ezzel biztosítható, hogy az infrastruktúra következetes módon legyen telepítve, akár manuálisan, akár CI/CD folyamatokban.
ARM sablon felépítése
Egy alapvető ARM sablon a következő részekből áll:
$schema: Meghatározza a sablon JSON sémáját.
contentVersion: Verziókezeléshez használható. (beágyazott és hivatkozott sablonok esetén kiemelt szerepe van)
parameters: A telepítéskor megadható paraméterek.
variables: Kiszámított értékek definiálása.
resources: Az Azure erőforrások definiálása.
outputs: A telepítés végeredményeként visszaadható adatok. (beágyazott és hivatkozott sablonok esetén különösen hasznos)
Példa egy egyszerű ARM sablonra, amely egy Tárfiókot (Storage Account) hoz létre:
Az ARM sablonok deklaratív módon határozzák meg az infrastruktúrát, így az eredmény mindig konzisztens lesz, függetlenül attól, hányszor futtatjuk.
2. Újrafelhasználhatóság és skálázhatóság
A sablonokat egyszer elkészíthetjük, majd később más projektekben is használhatjuk. Segítenek a nagyvállalati szintű infrastruktúra kezelésében.
3. CI/CD támogatás
Beépíthetők DevOps folyamatokba, így automatizált telepítéseket és frissítéseket hajthatunk végre az Azure Pipelines vagy GitHub Actions segítségével.
4. Függvények használata
Az ARM sablonok támogatják a beépített függvényeket, amelyek dinamikus adatmanipulációt tesznek lehetővé. Számtalan függvény használható a sablonban, melyek bizonyos korlátozások mellett együtt és összefűzve is használhatók.
Ezzel a módszerrel egyetlen sablont használhatunk több környezetben anélkül, hogy jelentős módosításokra lenne szükség.
Beágyazott (Nested) és hivatkozott (Linked) ARM sablonok
Beágyazott sablonok (Nested Templates)
A beágyazott sablonok lehetővé teszik, hogy egy ARM sablonon belül további sablonokat definiáljunk és telepítsünk. Ez segít az infrastruktúra modularizálásában és újrafelhasználhatóságában.
Példa egy beágyazott sablonra, amely egy Tárfiókot hoz létre:
A hivatkozott sablonok lehetővé teszik, hogy külső forrásból (például egy Azure Storage Blob-ból) töltsünk be egy másik ARM sablont. Ez különösen hasznos nagyobb infrastruktúrák esetén, ahol az egyes sablonokat külön szeretnénk kezelni és frissíteni.
A hivatkozott sablonok lehetővé teszik a jobb kezelhetőséget és karbantarthatóságot, különösen összetett környezetek esetén.
A „mode” beállítás szerepe
Bizonyára feltűnt, hogy mindegyik példában szerepel egy „mode” nevű parameter. A „mode” beállítás határozza meg, hogy az ARM sablon telepítése hogyan történjen az Azure környezetben. Két lehetőség van:
Incremental: Csak az új vagy módosított erőforrásokat hozza létre vagy frissíti. A meglévő erőforrásokat nem törli.
Complete: Az összes meglévő erőforrást eltávolítja, amely nincs megadva a sablonban, és csak az új sablon szerinti konfiguráció marad meg.
Általában az Incremental módot ajánljuk (ez az alapértelmezett), hogy elkerüljük az adatok vagy erőforrások véletlen törlését.
ARM sablon futtatása PowerShell-ből és Azure CLI-ból
Fontos, hogy a sablon telepítése előtt minden olyan „erőforrás csoportot”létre kell hoznunk, amelybe erőforrásokat szeretnénk létrehozni.
PowerShell használata
Az ARM sablon PowerShellből történő telepítéséhez az New-AzResourceGroupDeployment parancsot használhatjuk:
Azure CLI-ben az az deployment group create parancsot használhatjuk:
az deployment group create --resource-group EroforrasCsoport --template-file template.json --parameters @parameters.json
Inline paraméterek megadásával:
az deployment group create --resource-group EroforrasCsoport --template-file template.json --parameters tarfiokNeve=cloudmentorsa
Ezekkel a parancsokkal az ARM sablonokat egyszerűen telepíthetjük az Azure környezetben.
Példa egy parameters.json fájlra
A parameters.json fájl a sablon által használt paraméterek megadására szolgál, lehetővé téve a sablon egyszerű újrafelhasználását különböző konfigurációkkal. Egy tipikus parameters.json fájl így néz ki:
Ez biztosítja, hogy az ARM sablon ugyanazt a logikát kövesse, de az értékek rugalmasan változtathatók legyenek.
ARM sablonok korlátai
Bonyolult szintaxis: Az ARM sablonok JSON-alapúak, ami nagyobb komplexitás esetén nehezen olvashatóvá válhat.
Nincs beépített ismétlés: Bár van néhány lehetőség (pl. copy loop), a Terraform-hoz képest kevésbé rugalmas.
Korlátozott hibakeresési lehetőség: A hibák az Azure Portalon vagy CLI-n keresztül nehezen diagnosztizálhatók.
Hosszabb telepítési idő: Összetettebb sablonok esetén a telepítés több percig is eltarthat.
Erőforráscsoport létrehozására nem használható: A sablon egy vagy több, létező erőforráscsoportba futtatható, de erőforráscsoportot nem tud létrehozni. (az előre létre kell hozni)
Összegzés
Az Azure ARM sablonok kulcsfontosságú eszközök a modern felhőalapú infrastruktúra kialakításában és kezelésében. Ha elkezdenéd használni az ARM sablonokat, érdemes egy kisebb projektben kipróbálni őket, majd fokozatosan bevezetni az összetettebb sablonokat.
Tudtad, hogy ha az ARM-be beletanulsz, akkor azzal együtt az teljes Azure automatizálás kulcsát is megkapod? 🙂