Korábban részletesen bemutattam a CDN alapfogalmait, ahol szó volt arról, hogy miként lehet a tartalmakat közelebb vinni a felhasználókhoz, csökkentve a késleltetést és tehermentesítve az eredeti szervereket. Utána írtam az AWS CDN megoldásáról is az AWS CloudFront szolgáltatásról.
Most egy lépéssel tovább megyünk, és megmutatom az Azure CDN-t, amely a Microsoft felhőszolgáltatásának egyik legfontosabb eleme. Gondoljunk bele: mi történik, ha egy nagy nemzetközi esemény közvetítése, egy webáruház kampányidőszaka vagy egy globális alkalmazás frissítése egyszerre több millió felhasználóhoz jut el? Ilyenkor mutatkozik meg igazán, mennyit ér egy jól felépített CDN.
Mi az Azure CDN?
Az Azure Content Delivery Network (CDN) lényege, hogy a tartalmakat – legyen szó weboldalról, képekről, videókról vagy alkalmazásfájlokról – világszerte elérhető peremhálózati (edge) szervereken tárolja. Ezek a szerverek közelebb vannak a végfelhasználókhoz, így az adatok gyorsabban töltődnek be, csökken a hálózati késleltetés, és a felhasználói élmény jelentősen javul. Jelenleg kétféle háttérhálózaton érhető el:
Azure CDN from Microsoft, amely a Microsoft saját globális hálózatát használja.
Azure CDN from Edgio, amely korábban Verizon/Edgecast néven működött, de átnevezés után is elérhető opció maradt.
A korábbi Azure CDN from Akamai szolgáltatás 2023. októberében kivezetésre került, így ma már nem érhető el új előfizetők számára.
Erősségek
Globális jelenlét: a Microsoft saját hálózata és az Edgio közösen biztosítanak világszintű edge pontokat.
Biztonság:HTTPS támogatás, token alapú hitelesítés és modern titkosítási szabványok.
Rugalmasság: fejlett szabálykezelés a gyorsítótárazás finomhangolásához.
Analitika: részletes statisztikák a forgalomról és a teljesítményről.
Lehetőségek és korlátok
Az Azure CDN nem old meg minden teljesítményproblémát. Ha a tartalomforrás lassú vagy hibásan konfigurált, a CDN nem tudja ellensúlyozni. Emellett költséggel is jár: a globális adatforgalom és a speciális funkciók használata külön díjazás alá eshet. Fontos a gondos tervezés, hogy a szolgáltatás valóban értéket adjon.
Felhasználási esetek
Weboldalak:WordPress alapú oldalak esetén a képek és videók gyorsan betöltődnek bárhonnan a világon.
E-kereskedelem: nemzetközi webshopok stabil vásárlói élményt tudnak biztosítani csúcsidőben, például Black Friday alatt.
Streaming: videószolgáltatók számára akadozásmentes lejátszást biztosít még extrém terhelés mellett is.
Azure CDN és AWS CloudFront. Mikor?
Mindkét szolgáltatás globális lefedettséget, integrációt és biztonságot kínál.
Azure CDN: előnyös azoknak, akik elsősorban Microsoft-ökoszisztémát használnak.
AWS CloudFront: jobban illeszkedik az Amazon szolgáltatásaihoz, például az S3-hoz és a Lambda@Edge-hez.
A választás gyakran attól függ, melyik felhőszolgáltatót használja az adott szervezet elsődlegesen.
Összegzés
Az Azure CDN ideális választás minden olyan vállalat számára, amely globális jelenlétet, gyorsabb betöltődést és jobb felhasználói élményt szeretne biztosítani. Ez közvetlen üzleti előnyt is jelent: nagyobb konverziós arányt, elégedettebb ügyfeleket és jobb piaci megítélést.
Internetezési szokásaink sokat változtak az elmúlt években. Emellett az AI megjelenésével, egy új trend is megjelent: mindenki AI-t akar használni mindenhol. Mondhatjuk, hogy fejetetejére állt a világ, hiszen 2022 óta egy technológiai forradalom zajlik.
Ebben a hatalmas változásban, azt gondolnánk, hogy minden technológia új, úttörő és innovatív. Ez azonban nem nem teljesen igaz. Az internet és az ehhez kapcsolódó technológiák alapja még mindig ugyanaz, mint amikor megjelentek. Annak ellenére is, hogy körülöttük, szinte minden megváltozott. Ma egy ilyen megoldás kapcsén szeretnék nektek bemutatni egy Azure szolgáltatást.
Az interneten minden weboldal és alkalmazás mögött IP-címek állnak. Ezek a számok nehezen megjegyezhetők, ezért használjuk a domain neveket. A DNS (Domain Name System) olyan, mint egy univerzális telefonkönyv: amikor beírsz egy webcímet, a DNS kikeresi a megfelelő IP-címet. Erről, már az AWS Route 53 DNS megoldásáról szóló cikkben írtam, most pedig azt nézzük meg, hogyan működik mindez az Azure DNS szolgáltatásban.
Mi az Azure DNS?
Az Azure DNS egy felhőalapú névkiszolgáló, amely lehetővé teszi az általad birtokolt domain zónáinak és rekordjainak kezelését. Az Azure globális infrastruktúráját használja (ez azt jelenti, hogy a Microsoft világszerte elhelyezett adatközpontjaiban és peremhálózati (edge) helyein futnak a DNS-szerverek), így biztosítja a gyors, megbízható és magas rendelkezésre állású névfeloldást. A kezelése egyszerű, mert ugyanazokon az eszközökön keresztül történik, mint más Azure-erőforrásoké: Azure Portal, CLI, PowerShell, REST API vagy akár infrastruktúra mint kód megoldásokkal (pl. Terraform).
Miért érdemes használni?
Hagyományosan a DNS-t külön szolgáltatóknál vagy domain-regisztrátoroknál kezelték. Ha azonban már eleve Azure-t használsz, logikus lépés lehet a DNS-t is ide integrálni, hogy minden egy helyen kezelhető legyen. Ez egységesebb, biztonságosabb és könnyebben automatizálható üzemeltetést jelent. Emellett igen kényelmes is ez a helyzet.
Erősségek
Mik is az Azure DNS erősségei?
Megbízhatóság: A Microsoft globális névszerver-hálózata biztosítja, hogy a DNS-lekérdezések mindig gyorsak és elérhetők legyenek.
Biztonság: Az Azure Active Directory (EntraID) integráció lehetővé teszi a kifinomult jogosultságkezelést.
Egységes kezelés: Az összes erőforrásodhoz hasonlóan a DNS is ugyanazon az Azure-felületen kezelhető, így nem kell új rendszert megtanulni.
Automatizálhatóság: Könnyen integrálható CI/CD folyamatokba és infrastruktúra mint kód megoldásokba.
Privát DNS-zónák: Nemcsak publikus, hanem belső (pl. több virtuális hálózat között megosztott) DNS-szolgáltatást is nyújt.
Lehetőségek és korlátok
Domain-regisztráció az Azure-ban:
Az Azure DNS önmagában nem regisztrátor, de az App Service-tartomány szolgáltatáson keresztül közvetlenül is vásárolhatsz domaint az Azure Portalról.
Ezt a Microsoft a GoDaddy partneren keresztül biztosítja, így egyszerű a kezelés, de technikailag nem az Azure DNS maga regisztrálja a domaint.
Fontos korlát, hogy .hu végződésű domaint nem lehet így regisztrálni, azt csak más szolgáltatón keresztül lehet megvenni, majd delegálni az Azure DNS-re.
Költségek: Árazása rendkívül kedvező (alapesetben nagyjából 200 Ft/zóna/hónap). A zónák fenntartása olcsó, és a lekérdezések díja is minimális, így a legtöbb szervezet számára elhanyagolható költséget jelent. Csak extrém nagy forgalom mellett érdemes előre kalkulálni.
Csak névfeloldás: Az Azure DNS nem kínál webtárhelyet vagy e-mail szolgáltatást, kizárólag a névkiszolgálást biztosítja.
Felhasználási esetek
Céges weboldal kezelése: Ha az alkalmazásaid Azure App Service-ben futnak, kényelmes a DNS-t is az Azure-ban kezelni.
Belső hálózatok: Privát DNS-zónák segítségével egyszerűbb a több Azure VNet összekapcsolása.
Globális alkalmazások: Az Azure DNS kombinálható az Azure Traffic Managerrel, így a felhasználók mindig a legközelebbi szerverhez jutnak.
DevOps folyamatok: Ha Terraformot vagy más IaC megoldást használsz, a DNS is ugyanabban a kódbázisban kezelhető, verziókövetve.
Mikor érdemes választani?
Már Azure-t használsz, és szeretnéd egy helyen kezelni az erőforrásaidat.
Fontos a magas rendelkezésre állás és a globális teljesítmény.
Nagyvállalati szintű biztonságra és jogosultságkezelésre van szükséged.
Összefoglalás
Az Azure DNS tehát modern, megbízható és biztonságos megoldás, amely lehetővé teszi, hogy a DNS-t is ugyanabban a felhőalapú környezetben kezeld, mint az alkalmazásaidat. Bár önmagában nem domain-regisztrátor, az App Service-tartományon keresztül domain is vásárolható, a .hu végződés kivételével. Ez a rugalmasság és integráció teszi különösen vonzóvá azoknak, akik már Azure környezetben dolgoznak.
Próbáld ki az Azure DNS-t saját projektedben, és tapasztald meg, milyen egyszerű a domain-kezelés a felhőben.
A modern világunkban az adat az egyik legértékesebb erőforrás. Az üzleti döntések, a marketingkampányok és a működés hatékonysága mind azon múlnak, hogy a szervezetek mennyire tudják kiaknázni a rendelkezésre álló információkat, mind időben, mind minőségben. Gondoljunk bele, a mesterséges intelligencia is a tengernyi adaton tud csupán jól és hatékonyan működni.
Az adatok azonban gyakran széttagoltak: különböző adatbázisokban, fájlokban, rendszerekben léteznek és legtöbbször eltérő formátumban. Emiatt szükségük van egy olyan eszközre, amely segít ezeket egységesíteni, megtisztítani, átalakítani és feldolgozni. Erre nyújt megoldást az Azure Data Factory (ADF), amely a Microsoft Azure-on érhető el.
Mi az Azure Data Factory?
Az Azure Data Factory egy felhőalapú ETL (Extract, Transform, Load) és ELT (Extract, Load, Transform) szolgáltatás. Lényege, hogy adatokat tud kinyerni (Extract) különböző forrásokból, azokat átalakítani (Transform), majd a célrendszerbe betölteni (Load). Ezzel hidat képez az eltérő rendszerek és az üzleti intelligencia eszközök között.
Mivel teljesen felügyelt szolgáltatás, a felhasználónak nem kell szerverek karbantartásával, skálázásával vagy szoftverfrissítésekkel foglalkoznia. Az ADF vizuális, drag-and-drop alapú felületet kínál, de támogatja az adatfolyamok kód alapú megírását is. Így mind az üzleti felhasználók, mind a fejlesztők megtalálhatják benne a számításaikat.
Egy nagytudású NoCode megoldás, amely segít az üzleti integrációban is, de kiszolgálja a fejlesztői igényeket is.
Főbb építőelemei
Pipeline (csővezeték): Egy adott adatfeldolgozási folyamat leírása, amely több lépésből is állhat.
Activity (tevékenység): Egy pipeline egy-egy művelete, például adatmozgatás vagy átalakítás.
Data Flow (adatfolyam): Kifejezetten adattisztításra és transzformációra szolgáló vizuális eszköz.
Linked Service (kapcsolódó szolgáltatás): Az adatforrás vagy a célrendszer konfigurációja, pl. SQL adatbázis vagy blob tárhely.
Dataset (adathalmaz): A feldolgozott adatok logikai egysége, amelyet egy pipeline vagy activity használ.
Ezek az építőelemek együtt adják az ADF rugalmasságát és sokoldalúságát.
Erősségei
Az Azure Data Factory legnagyobb előnye a széles körű integráció. Több mint 90 különböző adatforráshoz kínál beépített csatlakozót, amelyek között megtaláljuk az SQL adatbázisokat, CSV fájlokat, NoSQL rendszereket, API-kat vagy akár SAP rendszereket is.
Másik erőssége a skálázhatóság: akár kis mennyiségű adatot, akár petabájt méretű adathalmazokat is képes kezelni, anélkül, hogy a háttérben nekünk kellene erőforrást biztosítani.
Kiemelendő az adattisztítási képessége, amely lehetővé teszi a duplikált elemek kiszűrését, a hiányzó vagy hibás értékek javítását, és a különböző formátumok egységesítését. Ez rendkívül fontos, mert a tisztítatlan adatok gyakran félrevezető jelentésekhez és rossz üzleti döntésekhez vezethetnek.
Lehetőségei
Az ADF nemcsak egyszerű adatmozgatást, hanem komolyabb adatintegrációs feladatokat is támogat:
Automatizálás és ütemezés: Beállítható, hogy a pipeline-ok meghatározott időpontokban, például óránként vagy naponta fussanak.
Big Data feldolgozás: Az Azure Synapse Analytics-szel vagy a Databricks-szel kombinálva nagy mennyiségű adatot is képes feldolgozni.
Hybrid környezet támogatása: Nemcsak a felhőből, hanem hagyományos (on-premise) rendszerekből is be tud gyűjteni adatokat.
DevOps integráció: Támogatja a Git verziókezelést, így a folyamatok fejlesztése és karbantartása könnyebben követhető.
Monitorozás: Az ADF képes részletes log-okat és figyelmeztetéseket küldeni, hogy lássuk, mikor és hol futott hiba a folyamatban.
Korlátok
Bár sokoldalú, nem minden helyzetben a legjobb választás. Például:
A valós idejű feldolgozás csak korlátozottan érhető el, főként kötegelt feldolgozásra optimalizált.
A komplex logikai átalakítások esetében gyakran érdemes külső szolgáltatásokkal (pl. Databricks) kombinálni.
A költségek nagy mennyiségű adat esetén gyorsan növekedhetnek, így fontos a folyamatok optimalizálása.
Felhasználási esetek
Kereskedelmi vállalat: Egy online áruház a webes rendelések adatait, a raktárkészlet-információkat és a fizikai üzletek eladásait szeretné egy helyen elemezni. Az ADF összegyűjti az adatokat, megtisztítja azokat, majd az Azure Synapse Analytics-be tölti, ahol a menedzsment valós idejű riportokat készíthet.
Banki szektor: Egy bank különböző rendszerekből (tranzakciók, ügyféladatok, CRM) gyűjt adatokat, majd azokat normalizálja és tisztítja. Az így előkészített adatokból megbízható fraud detection modellek építhetők.
Gyártóipar: Egy gyártó cég különböző szenzorokból származó adatokat integrál az ADF segítségével, majd előkészíti azokat gépi tanulási modellekhez, amelyek előrejelzik a gépek meghibásodását.
Tanulság kezdőknek
Ha most ismerkedsz az adatintegráció világával, az Azure Data Factory kiváló belépési pont. Egyszerre biztosít vizuális, kódmentes megoldást és fejlesztőbarát rugalmasságot. A kulcs az, hogy először kisebb, egyszerűbb pipeline-okat hozz létre, majd fokozatosan bővítsd a tudásod összetettebb adatfolyamokkal és tisztítási feladatokkal.
A Mentor Klubban, 2025. szeptemberétől elérhető NoCode és LowCode megoldások Azure-ban és AWS-ben képzési anyagban is testközelből láthatod ennek működését.
Összegzés
Az Azure Data Factory ideális választás mindenkinek, aki adatvezérelt működésre szeretne átállni. Megbízhatóan kapcsolja össze a különböző rendszereket, tisztítja és feldolgozza az adatokat, majd elérhetővé teszi azokat riportokhoz, elemzésekhez vagy mesterséges intelligencia modellekhez. Bár vannak korlátai, a rugalmassága és az egyszerű kezelhetősége miatt az egyik legfontosabb adatfeldolgozó eszköz az Azure ökoszisztémában.
Én például a DJ fellépéseimhez szükséges zenei tárház elemeit szoktam ezzel tisztítani, mielőtt elküldöm a MAHASZ felé.
Az elmúlt hetekben rengeteg Kubernetes-el foglalkozó cikket zúdítottam már rátok. Ez nem fog változni a közeljövőben sem, azonban ma egy olyan Kubernetes szolgáltatást nézünk meg közelebbről, amely közben felhőszolgáltató specifikus is.
Azt már többször többféle módon is elmondtam, hogy a konténertechnológia forradalmasította a modern alkalmazásfejlesztést (a legismertebb konténertechnológiai megoldás a Docker): egyszerűbbé vált az alkalmazások csomagolása, szállítása és futtatása különböző környezetekben. Az Azure Kubernetes Service (AKS) ebbe a világba nyújt belépőt, méghozzá teljes mértékben menedzselt formában. A kezdők számára különösen előnyös, mert elrejti a komplexitás nagy részét, miközben erős kontrollt és rugalmasságot biztosít.
Mi az az Azure AKS? Az Azure Kubernetes Service (AKS) a MicrosoftAzure felhőplatformjának menedzselt Kubernetes-szolgáltatása. Lehetővé teszi konténerizált alkalmazások automatikus üzembe helyezését, kezelését, skálázását és monitorozását anélkül, hogy külön kellene gondoskodni a Kubernetes-fürt (cluster) telepítéséről és karbantartásáról.
Miért előnyös az AKS használata?
Menedzselt vezérlőréteg A Kubernetes vezérlőelemeit (control plane) teljesen menedzseli az Azure – így ezek frissítése, méretezése és biztonsági javítása nem a fejlesztőcsapat feladata.
Automatikus skálázás Támogatja a vízszintes pod-autoskalázást (HPA), node pool szintű autoskalázást, valamint a manualis skálázást is.
Integráció az Azure ökoszisztémával Könnyen integrálható más Azure szolgáltatásokkal, például Azure Monitor, Log Analytics, Key Vault, EntraID (Azure AD), vagy az Application Gateway-vel.
Támogatás Windows és Linux node poolokra Lehetőség van hibrid környezetek létrehozására is, ahol egyes szolgáltatások Windows, mások Linux konténerként futnak.
RBAC és identitáskezelés Az Azure AD integráció segítségével szabályozhatjuk, ki mit tehet a fürtben (Role-Based Access Control).
Frissítési stratégia testreszabása A cluster frissítések tervezetten, lépésenként is végrehajthatók, hogy minimalizáljuk a leállást.
Korlátok, amikkel érdemes számolni
Control Plane testreszabhatósága korlátozott Mivel menedzselt szolgáltatás, bizonyos alacsony szintű beállításokhoz nincs hozzáférés.
Sokféle beállítási lehetőség, ami összezavarhatja a kezdőket Bár a vezérlőréteg menedzselt, a node poolok, hálózatkezelés, tárolók és jogosultságok konfigurálása összetett lehet.
Hosszabb indulási idő A node poolok indulása néhány perctől akár 10-15 percig is eltarthat, főleg ha új skálázást kérünk.
Mikor érdemes az AKS-t választani? Az AKS ideális választás, ha:
Több mikroalkalmazást futtatnál egységes környezetben
DevOps pipeline-t szeretnél kiépíteni CI/CD-vel
Folyamatosan skálázódó alkalmazásokat futtatsz
Hosszú távon Kubernetes-es megközelítést szeretnél alkalmazni
Felhasználási példa: Webalkalmazás CI/CD pipeline-nal Egy több részből álló webalkalmazás (pl. frontend, backend, adatbázis) konténerizált formában van tárolva. Az alkalmazás képfájlai pedig az Azure Container Registry-ben (ACR).
Az AKS lehetővé teszi ezen konténerek fürtbe szervezését. GitHub Actions vagy Azure DevOps használatával CI/CD pipeline-t építhetünk, amely automatikusan telepíti és frissíti az alkalmazás egyes komponenseit a Kubernetes-fürtbe.
A forgalmat Azure Application Gateway vagy Ingress Controller segítségével lehet terelni, míg a logokat Azure Monitorban gyűjthetjük.
Milyen más Azure szolgáltatások támogatják még a Docker-konténereket? Bár az AKS a legteljesebb konténerkezelési megoldás, az Azure több más konténeres megoldást is kínál, amelyekről külön cikkekben olvashatsz:
Azure Arc-enabled Kubernetes: Saját Kubernetes-fürtök Azure-ból való menedzsmentje
Összefoglalás Az Azure Kubernetes Service (AKS) ideális választás azok számára, akik szeretnének skálázható, rugalmas, mikroszolgáltatás-alapú architektúrát kialakítani konténerek használatával, anélkül hogy a Kubernetes teljes komplexitásával kellene nap mint nap megküzdeniük. Az AKS lehetőséget ad a fejlődésre: kezdőként is elkezdhetjük, de haladó szintig is skálázhatjuk tudásunkat benne.
Azt azért megjegyezném, hogy egy AKS cluster fenntartása és üzemeltetése nem olcsó mulattság. Mielőtt kipróbálod, – márpedig ki kell próbálnod – ellenőrizd a díjkalkulátor segítségével, hogy mennyibe kerülne.
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.
Nem is olyan régen így kezdem az egyik AWS-es cikket:
A felhő is csak akkor gazdaságos, ha okosan használjuk
És volt már szó az Azure Spot VM-ről is, ami egy olyan típusú virtuális gép, amelyet az Azure a kihasználatlan kapacitásaiból kínál rendkívül kedvező áron. Ma tovább lépünk.
Az Azure használata során hamar szembesülhetünk azzal, hogy a felhőszolgáltatások költségei gyorsan megnövekedhetnek. Szerencsére a Microsoft kínál megoldásokat arra, hogy optimalizáljuk a kiadásainkat: két népszerű lehetőség a Savings Plan és a Reserved Instance (RI). Ebben a cikkben bemutatom, hogyan működnek ezek az ajánlatok, mik az előnyeik, hátrányaik, és milyen helyzetekben érdemes az egyiket vagy a másikat választani.
Mi az az Azure Savings Plan?
Az Azure Savings Plan egy rugalmas megtakarítási konstrukció. Lényege, hogy vállalod egy meghatározott, óránkénti összeg elköltését az Azure-ban, 1 vagy 3 éves időszakra. Ezért cserébe jelentős kedvezményeket kapsz az on-demand (normál) díjszabásokhoz képest.
Az óránkénti költési szint szabadon felhasználható többféle szolgáltatásra és régióra, például virtuális gépekre (VM-ekre), App Service-re vagy más compute-alapú erőforrásokra.
Előnyei:
Nagy rugalmasság: bármilyen támogatott compute szolgáltatásra elkölthető.
Nincs szükség konkrét erőforrás vagy régió előzetes megkötésére.
Könnyebb alkalmazkodni a változó igényekhez.
Hátrányai:
Ha nem használod ki az óránkénti költési vállalásodat, akkor is ki kell fizetned.
Kevésbé kedvező ár a Reserved Instance-hez képest ugyanazon VM-ekre.
Mi az az Azure Reserved Instance?
A Reserved Instance (foglalt példány) egy klasszikusabb megközelítés: itt konkrét virtuális gép típusra, régióra és üzemidőre vállalsz elköteleződést egy vagy három évre. Cserébe jelentősen olcsóbban használhatod az adott VM-et, akár 72%-os megtakarítást is elérve az on-demand árhoz képest.
Előnyei:
Nagy megtakarítás fix VM használat esetén.
Tervszerű, stabil költségtervezés hosszú távra.
Átadható más előfizetésbe vagy eladható a Reserved Instance Marketplace-en.
Hátrányai:
Kevés rugalmasság: kötött VM méret, típus, régió.
Ha változnak az igények (pl. más méret vagy régió kell), nehezebb alkalmazkodni.
Savings Plan vs Reserved Instance – Összehasonlítás
Jellemző
Savings Plan
Reserved Instance
Rugalmasság
Magas
Alacsony
Megtakarítás mértéke
Közepes (~20-65%)
Nagy (~30-72%)
Elköteleződés
Óránkénti költési vállalás
Konkrét VM, régió, időtartam
Átadhatóság
Nem
Igen (Marketplace-en értékesíthető)
Igényváltozások kezelése
Rugalmasabb
Korlátozott
Mikor melyiket válasszam?
Savings Plan
Ha még nem tudod pontosan, milyen erőforrásokat fogsz hosszú távon használni.
Ha dinamikusan változik a compute igényed (például szezonális terhelés esetén).
Ha többféle compute szolgáltatást kombinálnál (pl. VM-ek, App Service, Functions).
Reserved Instance
Ha pontosan tudod, milyen típusú VM-et, melyik régióban, hosszú távon fogsz futtatni.
Ha stabil, kiszámítható workloadod van, például állandóan futó alkalmazásszerverek.
Ha maximalizálni akarod a megtakarítást, és nem zavar a rugalmasság hiánya.
Összegzés
Mind a Savings Plan, mind a Reserved Instance remek eszköz arra, hogy csökkentsd az Azure költségeidet. A választás attól függ, mennyire tudod előre megjósolni a jövőbeni erőforrásigényedet. Ha bizonytalan vagy, a Savings Plan által kínált rugalmasság előnyösebb lehet. Ha viszont stabil, kiszámítható rendszered van, akkor a Reserved Instance adja a legjobb ár-érték arányt.
Ne feledd! Ez minden esetben elköteleződéssel jár. Azaz akkor is fizetned kell, ha nem használod ki a hűségszerződésben foglaltakat. Ezért jól gondold át, mielőtt beleugrasz.
A felhőszolgáltatások világában egyre több lehetőség nyílik arra, hogy költséghatékonyan működtessük rendszereinket. Ez azonban mindig relatív és érdemes helyén kezelni ezt a „költséghatékony” szót, hiszen sok összetevő alapján jelenthetjük ki csupán, hogy valami valóban alacsonyabb áron vehető igénybe. Az egyik ilyen lehetőség az Azure Spot Virtual Machines (röviden: Spot VM). Ha szeretnél többet kihozni a költségkeretedből, de közben elfogadod a némi rugalmasságot igénylő működést, akkor ez a technológia neked szól!
Mi az az Azure Spot VM?
Mindegyik felhőszolgáltató esetén igaz, hogy készen kell állni a felhasználók növekvő és azonnali igényeire. Emiatt folyamatosan bővítik a kapacitásukat. Emellett az ügyfelek nem csupán bővítik rendszereiket, hanem a skálázáson keresztül igyekeznek optimalizálni a rendszer kapacitását és a költségeket. Ennek következménye, hogy a felhőben időről-időre lesznek olyan fel nem használt szabad kapacitások, amelyek bizonyos szempontból veszteséget termelnek a szolgáltatónak. Ezt felismerték a felhőszolgáltatók (Azure, AWS, Google) és ezt a szabad, fel nem használt kapacitást igyekeznek tovább értékesíteni ügyfeleik részére. És így jelent meg minden szolgáltatónál a Spot VM.
Az Azure Spot VM egy olyan típusú virtuális gép, amelyet az Azure a kihasználatlan kapacitásaiból kínál rendkívül kedvező áron. Ezeket a VM-eket lényegesen olcsóbban bérelheted, mint a hagyományos, „pay-as-you-go” típusú VM-eket – akár 70-90%-os megtakarítás is elérhető.
Mikor érdemes használni?
A Spot VM ideális olyan feladatokhoz, amelyek:
Nem időkritikusak (azaz nem okoz üzletileg kárt, ha a gép leáll)
Rövid ideig tartanak vagy batch jellegűek (20 perc – 1 órás feladatok, vagy olyan tömegesen futtatandó script-ek amelyeknek rövid időre nagy számítási kapacitásra van szüksége)
Példák:
Adatfeldolgozás
Tesztelés és CI/CD pipeline futtatás
Machine learning modellek tanítása
Nagy számításigényű, de megszakítható feladatok
Ár és költségelőnyök
A Spot VM-ek ára dinamikusan változik, attól függően, hogy mennyi szabad kapacitás áll rendelkezésre az Azure régióiban. Nincs garantált ár, de jellemzően jóval olcsóbb, mint a standard VM-ek, amelyeket listaáron vehetünk igénybe. Az árak követésére és előrejelzésére az Azure kínál API-kat és kalkulátorokat is. Emellett van egy kimondottan erre szakosodott weboldal, amit én is rendszeresen használok: https://instances.vantage.sh/azure
Ha valaki elmélyed ebben, akkor hamar rájön, hogy igen jó áron lehet így virtuális gépekhez jutni.
Fontos: Ellentétben a foglalt példányokkal (reserved instance) vagy költségcsökkentési tervekkel (savings plan) szemben, itt nincs kötelezettségvállalás – csak addig fizetsz, amíg használhatod a VM-et.
Milyen korlátai vannak?
Ez eddig nagyon jól hangzik. Igaz? Természetesen a Spot VM-ek használata bizonyos kockázatokat és korlátozásokat hoz magával:
Bármikor megszakíthatók előzetes értesítés nélkül, ha az Azure-nak szüksége van az erőforrásra.
Nincs SLA (Service Level Agreement), tehát nem garantált a rendelkezésre állás.
Nem minden VM-típus és régió támogatja.
Általában nem alkalmas folyamatosan elérhető szolgáltatások futtatására (pl. webalkalmazások backend komponense).
Hogyan működik a megvonás?
Mivel ez a termék a felhőszolgáltató szabad kapacitását kínálja eladásra, így szükséges tudnunk, hogyan vonja meg tőlünk a szolgáltató az általunk igényelt Spot VM-et, amikor eljön az idő. Itt két lehetőség lehetséges:
Kapacitás alapján: Az Azure akkor szakítja meg a VM-edet, ha már nem tudja fenntartani a kapacitást. Tehát szksége van erre a kapacitásra azon ügyfeleinek, akik listaáron vásárolnak számítási kapacitást.
Ár alapján: Ha az aktuális ár meghaladja az általad beállított maximális árat, a gépet leállítják.
Használati lehetőségek és best practice-ek
Scale set-ekkel együtt: Érdemes Spot VM-eket autoscale beállításokkal, standard VM-ek mellett használni. Csak Spot VM-et nem szabad használni.
Állapotok mentése: Mentsd rendszeresen a munkát vagy modellek állapotát, hogy egy megszakítás után folytatni tudd. (fejlesztői környezeteknél fontos)
Mixelt környezet: Érdemes Spot és standard VM-eket kombinálni a költség és megbízhatóság optimalizálása érdekében.
Beállítás egyszerűen
Az Azure Portalon, CLI-n vagy Terraform segítségével is könnyedén indíthatsz Spot VM-et. A létrehozáskor csak be kell pipálnod a „Futtatás Azure Spot-kedvezménnyel” opciót, és megadhatod a maximális árat vagy választasz kapacitás alapú prioritást.
A többi lépés teljesen megeggyezik azzal, amikor egy hagyományos virtuális gépet hozunk létre.
Összefoglalás
Tulajdonság
Spot VM
Ár
Nagyon kedvező (akár -90%)
SLA
Nincs
Megszakíthatóság
Bármikor leállhat
Alkalmas
Rugalmas, nem időérzékeny munkákhoz
Nem ajánlott
Állandó, üzletkritikus szolgáltatásokhoz
Az Azure Spot VM kiváló választás, ha szeretnél költséget csökkenteni azokon a területeken, ahol megengedhető a megszakítás vagy a leállás. A tudatos tervezéssel és jó automatizációval a legtöbbet hozhatod ki ebből a lehetőségből – akár a fejlesztői környezetedben, akár a machine learning feladataid során.
Tipp: Kezdd el kis projektekkel és mérd fel, hogyan reagál a rendszered a megszakításokra. Így biztonságosan építhetsz rá éles rendszert is – ott, ahol érdemes!
Ha szeretnéd, elkészíthetek egy konkrét példát is, hogyan lehet Azure CLI-al vagy Terraform-mal Spot VM-et indítani. Érdekelne?
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?
A modern informatikai világban az automatizáció mindig is a hatékony erőforrás kezelés egyik alappillére. A DevOps és GitOps is erre épül. És ha ezen metodikákról beszélünk, akkor elsősorban az infrastruktúra automatizáció jut eszünkbe. Aki nem csak Azure-al foglalkozik neki talán a terraform ugrik be erről először.
Most viszont Azure-al foglalkozunk. Legutóbb megismertük az Azure ARM sablont, amellyel nagyon komoly és összetett rendszereket hozhatunk létre automatizáltan és hatékonyan. Ezt azonban hosszab idő lehet megtanulni, hiszen annyira komplex, hogy sokaknak nehézséget okoz. Ekkor jön képbe a Bicep.
Azure Bicep
Az Azure Bicep egy domain-specific language (DSL), amely az Azure Resource Manager (ARM) sablon egyszerűbb és olvashatóbb alternatívájaként jelent meg. Az ARM-sablonok JSON alapúak, ami gyakran nehézkessé teszi az olvasásukat és karbantartásukat. A Bicep ezzel szemben egy deklaratív szintaxist használ, amely leegyszerűsíti az infrastruktúra mint kód (IaC) megvalósítását az Azure környezetben.
Milyen kategóriába tartozik az Azure Bicep?
Az Azure Bicep az Infrastructure as a Service (IaaS) kategóriába sorolható, mivel segítségével virtuális gépek, hálózatok és egyéb infrastruktúra-erőforrások deklaratív módon történő létrehozását és kezelését teszi lehetővé az Azure-ban.
Miért érdemes használni az Azure Bicep-et?
Modularitás: Lehetővé teszi a modulok használatát, ami segít az infrastruktúra szegmentálásában és újrafelhasználásában.
Egyszerűbb szintaxis: A Bicep kód rövidebb és átláthatóbb, mint az ARM JSON sablonok.
Jobb karbantarthatóság: Könnyebb módosítani és újrafelhasználni az erőforrásokat.
Nincsenek JSON struktúrák: Nem kell bonyolult JSON szintaxissal dolgozni.
Automatikus fordítás ARM sablonná: A Bicep kódot könnyen konvertálhatjuk ARM JSON sablonokká.
Példák az Azure Bicep használatára
Egyszerű példa: Tárfiók létrehozása
Hozzunk létre egy egyszerű Bicep fájlt (storage.bicep), amely egy Azure Storage Accountot hoz létre:
Ez a példa bemutatja, hogyan lehet hierarchikus kapcsolatokat kialakítani az erőforrások között, például egy alhálózatot egy adott virtuális hálózaton belül definiálni.
Hogyan működik az Azure Bicep?
A Bicep használata során egy .bicep kiterjesztésű fájlban határozzuk meg az Azure erőforrásokat. Ezt a fájlt ezután Bicep CLI vagy az Azure CLI segítségével ARM sablonná fordítjuk, amelyet az Azure Resource Manager feldolgoz.
Tehát amire képes az ARM sablon, azt meg tudod valósítani Bicep-el is.
Bicep fájlok futtatása PowerShell-ből
PowerShell-ben a következő parancsot használhatod egy Bicep fájl deploy-olásához egy meglévő erőforráscsoportba:
Azure CLI-ben az alábbi parancsot használhatod a telepítéshez:
az deployment group create --resource-group EroforrasCsoport1 --template-file storage.bicep
Ezzel a parancsokkal az Azure Bicep fájlokat könnyedén alkalmazhatod az Azure infrastruktúrád kezelésére.
Összegzés
Az Azure Bicep egy hatékony és egyszerű eszköz az Azure infrastruktúra kezelésére. Az ARM JSON sablonokhoz képest sokkal könnyebben olvasható és írható, miközben megőrzi a teljes funkcionalitást. Ha az Infrastructure as Code (IaC) elveit követve szeretnéd automatizálni az Azure erőforrásaid kezelését, akkor a Bicep egy kiváló választás.
Ha érdekel az Azure infrastruktúra-kezelés, érdemes elkezdeni a Bicep használatát, mert időt takaríthatsz meg, és jobban skálázható megoldásokat építhetsz vele. Kódját megtalálod a GitHub-on.
Te használtad már vagy az ARM sablont vagy a Bicep fájlokat?
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? 🙂