A megfelelő költségkezelés a felhő egyik kritikus része. Minden oktatásomon el is hangzik a következő mondat:
A felhő is csak akkor gazdaságos, ha okosan használjuk
Az egyik korábbi cikkemben már bemutattam a költséghatékonyság kapcsán a Spot Instance-ot, amely olyan virtuális gép (EC2 instance), amit az AWS fel nem használt kapacitásából kínál. Mivel ezek az erőforrások „feleslegesek”, az áruk jelentősen alacsonyabb, mint az on-demand (igény szerinti) vagy reserved instance-oké.
Azt talán nem szükséges ecsetelni, hogy az AWS-felhőszolgáltatásai rugalmasak és nagy teljesítményűek, de a használatuk ára gyorsan emelkedhet, ha nem figyelünk a költségekre. Éppen ezért kínál az AWS olyan konstrukciókat, mint a Savings Plan és a Reserved Instance (RI), amelyekkel jelentős megtakarítást érhetünk el.
Alapfogalmak
Mindkét konstrukció alapja a hosszú távú elköteleződés egy adott futtatási kapacitás mellett. Ezért cserébe akár 72%-os megtakarítást is elérhetünk az on-demand (azonnali) árakhoz képest. A különbség főként a rugalmasságban és a használati feltételekben rejlik.
Reserved Instance (RI) – Lefoglalt példány
A Reserved Instance egy meghatározott régióra, géptípusra és gyakran operációs rendszerre szóló foglalás. Az elköteleződés (hűségszerződés) 1 vagy 3 évre történik.
Előnyök:
Jelentős megtakarítás az On-Demand árakhoz képest (akár 72%)
Teljesítménygarancia, mert a példány le van foglalva
Költség előre jól tervezhető
Korlátok:
Merev: példánytípus, régió, OS, fizetési konstrukció kötött
Ha megváltozik az igény, a foglalás nem feltétlenül használható jól
Csak EC2-re és néhány más szolgáltatásra vonatkozik
Savings Plan – Rugalmasabb megtakarítási terv
A Savings Plan inkább az elköltött összegre vonatkozik, nem konkrét példányokra. Megadhatjuk, hogy napi szinten mekkora összeget vállalunk 1 vagy 3 évre. Ezt az AWS automatikusan optimalizálja a háttérben.
Két típus létezik:
Compute Savings Plan: Rugalmasan használható bármely régióban, bármely példánytípusra, akár AWS Fargate és Lambda esetén is.
EC2 Instance Savings Plan: Kötöttebb – egy régióhoz és géptípus családhoz kötött, de géptípus szinten rugalmasabb, mint az RI.
Előnyök:
Nagy rugalmasság – könnyebb alkalmazkodni a változó igényekhez
Automatikus alkalmazás, nem kell példányokat lekötni
Szélesebb szolgáltatási kör (Lambda, Fargate is)
Korlátok:
Kisebb megtakarítás, mint a teljesen lekötött RI esetén (max. ~66%)
Előzetes költési elköteleződés szükséges
Ha kevesebbet használunk, mint amennyit lekötöttünk, nincs visszatérítés
Mikor melyiket? Felhasználási esetek
Reserved Instance javasolt, ha:
Tudjuk, hogy hosszú távon fix kapacitásra lesz szükségünk (pl. 7×24-ben futó webalkalmazás)
Nem várható jelentős változás a példánytípusban, régióban vagy OS-ben
Az EC2 az elsődleges költségforrásunk
Savings Plan javasolt, ha:
Gyakran változik a példánytípus, régió, vagy konténeres/Lambda alapú az architektúra
Több szolgáltatás költségét akarjuk optimalizálni egyszerre
Nem szeretnénk példányhoz kötött döntéseket hozni
Összegzés
Mind a Reserved Instance (foglalt példány), mind a Savings Plan (megtakarítási terv) hatékony eszköz az AWS költségek optimalizálására. A választás kulcsa az, hogy mennyire fix az infrastruktúránk és mennyire fontos a rugalmasság. Kezdőként érdemes a Savings Plan-nel kezdeni, különösen ha dinamikus vagy kísérletezős környezetben dolgozunk. Ha viszont stabil termékkörnyezetet futtatunk, a Reserved Instance biztosíthatja a legnagyobb megtakarítást.
Savings Plan vs Reserved Instance – Gyors összehasonlítás
Tulajdonság
Savings Plan
Reserved Instance (RI)
Rugalmasság
Magas (Compute SP szinten kiemelkedő)
Alacsony (kötött példánytípus, régió stb.)
Megtakartítható költség
Közepes–magas (akár ~66%)
Magas (akár ~72%)
Elköteleződés időtartama
1 vagy 3 év
1 vagy 3 év
Példány típusának változtatása
Lehetséges (Compute SP esetén)
Nem lehetséges
Szolgáltatások köre
EC2, Fargate, Lambda
Főleg EC2
Felhasználás módja
Automatikusan alkalmazva költés alapján
Előre lefoglalt példányhoz kötött
Legjobb felhasználási eset
Dinamikus vagy konténeres környezet
Állandó példányhasználat fix igényekkel
Fizetési lehetőségek
Előre, részben előre vagy havi
Ugyanez (No Upfront, Partial, All Upfront)
Ez a táblázat segíthet gyorsan átlátni a fő különbségeket, és a saját igényeinkhez legjobban illeszkedő megoldást választani.
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.
Ahogy a legutóbbi cikkemben írtam 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. Kíváncsi vagyok, vajon azóta megismerd-e az Azure Spot VM-et. Ennek párja az AWS-ben az EC2 Spot Instance (röviden: Spot Instance). Ma ezt szeretném nektek bemutatni kicsit közelebbről, hátha kedvet kaptok és kipróbáljátok, vagy éppen olyan projekten dolgoztok, ahol ez a tökéletes választás.
Tehát az Amazon Web Services (AWS) is lehetőséget kínál arra, hogy akár 90%-kal olcsóbban használjunk számítási erőforrásokat – ez a Spot instance. Ez a lehetőség különösen vonzó lehet fejlesztőknek, startupoknak és minden olyan technológiai csapatnak, amely rugalmas workload-okon dolgozik, és szeretné optimalizálni az infrastruktúra költségeit.
Mi az az AWS Spot instance?
Az AWS Spot instance olyan virtuális gép (EC2 instance), amit az AWS fel nem használt kapacitásából kínál. Mivel ezek az erőforrások „feleslegesek”, az áruk jelentősen alacsonyabb, mint az on-demand (igény szerinti) vagy reserved instance-oké.
A felhasználók licitálás nélkül, rugalmas áron vehetnek igénybe Spot Instance-okat, és az AWS bármikor visszavonhatja őket, ha a kapacitásra másnak van szüksége. Ezért a Spot instance nem minden megoldáshoz ideális – de bizonyos esetekben hatalmas előnyt jelent.
Mikor érdemes Spot instance-ot használni?
A Spot instance különösen hasznos olyan feladatoknál, 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. Pl.: CI/CD pipeline-ok, konténeres munkafolyamatok)
Párhuzamosíthatók (pl. batch feldolgozás)
Ár és megtakarítás
A legnagyobb előny az ár: Spot instance-ok akár 70-90%-kal olcsóbbak lehetnek az on-demand áraknál. Az ár dinamikusan változik a kereslet-kínálat alapján, de nem kell manuálisan licitálni – az AWS automatikusan a legalacsonyabb aktuális áron biztosítja az erőforrást.
Korlátok és kockázatok
A Spot instance legnagyobb hátránya a bizonytalan rendelkezésre állás. Ha az AWS-nek szüksége van az erőforrásra, akkor értesítést küld a leállításról, és 2 percen belül leállítja az instance-ot. Ezért fontos olyan megoldásokat futtatni rajta, amelyek képesek kezelni ezt a megszakítást.
További korlátok:
Nem garantált a futási idő (lehet hogy több hét, lehet hogy csak egy óra)
Egyes régiókban vagy instance típusoknál korlátozott a kapacitás
A Spot instance-ok nem csak egyedi EC2 példányokhoz érhetők el. Az AWS világa számos olyan szolgáltatást kínál, ahol beépítve használhatjuk a Spot kapacitást – akár automatikus méretezéssel, konténerkezeléssel vagy teljesen menedzselt környezetekkel kombinálva. Íme néhány jelentős terület:
1. EC2 Auto Scaling Group (ASG)
Az Auto Scaling Group lehetővé teszi vegyes példánytípusok és ármodellek használatát. Például beállíthatjuk, hogy a csoport 70%-a Spot, 30%-a on-demand példányokból álljon. A rendszer automatikusan pótlást végez, ha egy Spot példány megszűnik.
2. Elastic Beanstalk
A Beanstalk egy platformszintű szolgáltatás, amely leegyszerűsíti az alkalmazások telepítését. Beállítható, hogy a háttérben futó EC2 példányok részben vagy teljesen Spot instance-ok legyenek. Ez ideális webalkalmazások költséghatékony futtatásához.
3. Amazon EKS (Elastic Kubernetes Service)
Az EKS Kubernetes klasztereknél támogatja a Spot alapú node-okat. Vegyes node pool segítségével lehetőség van kevésbé kritikus podokat Spot gépekre ütemezni, míg fontos szolgáltatásokat on-demand node-okon futtatunk.
4. AWS Batch
Az AWS Batch egy batch-alapú feldolgozási szolgáltatás, amely automatikusan skálázza az erőforrásokat – beleértve a Spot instance-okat is. Ez ideális például tudományos szimulációk, nagy volumenű renderelés vagy adatelemzés során.
5. Amazon EMR (Elastic MapReduce)
EMR használható Spot instance-okra építve is, főleg Hadoop, Spark vagy Presto alapú analitikai feladatokra. A nem kritikus worker node-ok Spot alapon futtathatók, míg a master node on-demand példány lehet a stabilitás érdekében.
6. Amazon ECS (Elastic Container Service)
Konténeres környezetben, főleg Fargate spot üzemmóddal vagy EC2 alapú klaszterekben, költséghatékonyan futtathatók konténerek Spot instance-okon, ideális CI/CD pipeline-okhoz vagy rövid életű mikroszolgáltatásokhoz.
7. SageMaker
A SageMaker modellek tanításánál is használható Spot training, amely jelentős költségcsökkentést kínál hosszabb, erőforrás-igényes tréning folyamatok során. Az AWS automatikusan menti az állapotot és folytatja, ha egy Spot gép kiesik.
8. Dev/Test környezetek
Fejlesztési és tesztelési környezetek gyakran nem kritikusak – ideális jelöltek a Spot instance-alapú futtatásra. Automatikusan indíthatók, leállíthatók és újraindíthatók anélkül, hogy ez éles rendszereket veszélyeztetne.
9. CI/CD pipeline-ok
Build, teszt és deploy pipeline-ok gyakran futnak rövid ideig és gyakran – ezek kiválóan optimalizálhatók Spot példányokkal, főleg ha konténeres vagy serverless architektúrában futnak.
10. Gépi tanulás, renderelés, transzkódolás
Minden olyan folyamat, ami párhuzamosítható, szakaszos és újraindítható – például videók transzkódolása, képfeldolgozás vagy gépi tanulásos modellek tanítása – ideálisan futtatható Spot példányokon.
Hogyan lehet biztonságosan használni?
Spot Fleet vagy Auto Scaling Group Automatikusan kezeli az elérhető Spot instance-okat, és ha kell, más instance típussal pótolja.
Checkpointing A folyamat időszakos mentése lehetővé teszi a gyors visszaállást.
Mixed Instance stratégia Kombinálható on-demand és Spot példányokkal egy szolgáltatás, így növelve a rendelkezésre állást.
Containerizáció és Kubernetes A konténeres architektúrák, különösen az EKS, ideálisan kezelik a dinamikusan változó Spot környezeteket.
Összefoglalás
Az AWS Spot instance egy kiváló eszköz azoknak, akik költséghatékonyan szeretnék működtetni nem kritikus feladataikat a felhőben. Bár kompromisszumot igényel a rendelkezésre állás terén, megfelelő architektúrával és tervezéssel rengeteg pénzt lehet vele megtakarítani.
A Spot instance-ok ma már szinte minden jelentős AWS szolgáltatásba integrálhatók. Nem csak a költségek csökkentését szolgálják, hanem lehetőséget nyújtanak a rugalmas, skálázható és optimalizált architektúrák kialakítására is.
A kulcs a tudatos tervezés – meg kell érteni, hol van szükség állandó rendelkezésre állásra, és hol engedhetjük meg a rugalmas, megszakítható infrastruktúrát.
Korábban írtam már az infrastruktúra automatizálásáról és a DevOps megközelítés fontosságáról az informatikai projektekben. Ezen megközelítés neve Infrastructure as Code (IaC). A Terraform-al már kicsit ismerkedtünk, de minden felhőszolgáltatónak van valamilyen IaC megoldása. Olvashattál már az Azure esetén az ARM-ről és a Bicep-ről is.
AWS-ben a CloudFormation az a szolgáltatás, amely lehetővé teszi, hogy az infrastruktúrát kódként kezeljük – azaz sablonfájlok segítségével automatikusan hozzuk létre és kezeljük az AWS erőforrásokat.
Mi az AWS CloudFormation?
A CloudFormation egy sablonalapú eszköz, amely lehetővé teszi, hogy JSON vagy YAML fájlban írjuk le, milyen AWS erőforrásokat szeretnénk létrehozni – például EC2 példányokat, S3 tárolókat, IAM szerepköröket, VPC-ket stb.
A sablon betöltése után a CloudFormation létrehozza ezeket az erőforrásokat Stack formájában. A stack egy logikai egység, amely tartalmazza az összes erőforrást, amit egy adott sablon alapján hoztunk létre.
Miért érdemes a CloudFormation-t használni?
Az alábbi lista önmagáért beszél:
Kód nézet: YAML vagy JSON formátumban írhatjuk meg a sablonokat – ez könnyen verziózható, visszakövethető, automatizálható.
Grafikus nézet: Az AWS Console-on belül vizuálisan is megtekinthetjük a sablon struktúráját (Resource Map), így könnyen átlátható, mi mivel áll kapcsolatban.
Újrahasználhatóság: A sablonok paraméterezhetők, így ugyanaz a sablon használható több környezetben (pl. dev, test, prod).
Exportálás: Egy meglévő környezetből könnyen generálhatunk sablont, amit újra felhasználhatunk máshol.
Rollback és állapotkezelés: Ha egy stack létrehozása során hiba történik, a CloudFormation automatikusan visszaállítja a korábbi állapotot.
Integráció más AWS eszközökkel: Például CodePipeline vagy Service Catalog támogatás.
Ha megnézzük ezt a listát, akkor láthatjuk, hogy a CloudFormation erősségei vitathatatlanok.
Egyszerű példa: Egy S3 tároló létrehozása
Ez a példa bemutatja, hogyan lehet egyetlen S3 tárolót létrehozni YAML-ben:
Ezek használatáról egy következő cikkben írok részletesebben.
Az AWS CloudFormation hatalmas segítség mindazok számára, akik szeretnék infrastruktúrájukat kóddá alakítani. Kezdőknek is ideális, mivel a sablonokat akár vizuálisan is generálhatják és módosíthatják, míg a haladó felhasználók számára teljes automatizálást tesz lehetővé CI/CD pipeline-okban.
Ha komolyan gondolod a felhőalapú rendszerek kiépítését, a CloudFormation ismerete egy igazi svájcibicska lehet a kezedben. 🙂
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? 🙂
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.
Ebben a cikkben bemutatjuk az AWS Elastic Container Registry-t (ECR), amely egy teljes mértékben felügyelt konténerképtároló szolgáltatás az AWS-ben. A cikk segít megismerni az alapokat és megpróbál megmutatni olyan fejlettebb funkciókat, mint az integrációs lehetőségek és az automatizált életciklus kezelés.
Mi az AWS ECR?
Az AWS Elastic Container Registry (ECR) egy (PaaS) kategóriába tartozó, felügyelt szolgáltatás, amely lehetővé teszi Docker és OCI (Open Container Initiative) kompatibilis konténerképek tárolását, kezelését és megosztását.
Az ECR maga a szolgáltatás elnevezése. Ezen belül történk a varázslás, hiszen ezen belül repository-kat hozhatunk létre. Egy repository egy olyan tárhely, amely egy adott alkalmazás konténerképeit és azok különböző verzióit (változatait) tartalmazza.
Az AWS ECR struktúrája
Az alábbi hierarchikus struktúria szemlélteti az ECR-t:
Repository: tartalmazza a különböző alkalmazás verziók konténerképeit
Hogyan tölthetek fel képet az ECR-be?
Első lépés, hogy fejlesztenem kell egy alkalmazást, amely docker vagy OCI kompatibilis. Ehhez találsz példát az én GitHub kódjaim között is.
Miután elkészítetted a képfájlt a számítógépeden, vagy valamilyen pipeline segítségével, nincs más dolgod, mint bejelentkezni ECR-be és feltölteni oda az aktuális konténerkép verzióját.
Ahhoz, hogy egy Docker-képet feltölts egy ECR repository-ba, kövesd az alábbi lépéseket:
docker tag sajat-kontener:latest <AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com/node-app:latest
docker tag sajat-kontener:latest <AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com/node-app:1.2.0
Az ECR-ben tárolt képeket könnyen használhatod AWS szolgáltatásokkal, például az ECS vagy az EKS segítségével.
Ha egy Amazon ECS clusterben szeretnél futtatni egy konténert az ECR-ből, hozz létre egy Task Definition-t, amely tartalmazza az ECR repository URL-jét:
Amikor nagyon sok alkalmazásunk konténerképeit tároljuk és ezekből rendszeresen készítünk új verziókat, előbb-utóbb azzal szembesülünk, hogy a régi és nem használt verziók sok helyet foglalnak. Ez pedig azt jelenti, hogy sok tárhelyet foglalnak, amely növeli a költségeinket.
Szerencsére az ECR támogatja az életciklus-szabályok (Lifecycle Policies) használatát, amelyek segítenek automatikusan törölni a régi vagy nem használt konténerképeket.
Ezeket szabályokon keresztül tudjuk megtenni. Egy-egy ilyen szabályhoz csupán néhány paramétert kell megadnunk, majd a szabályok között felállítanunk egy prioritási sorrendet, a többit az AWS elvégzi helyettünk.
Példa 1: egy olyan szabályra, amely csak az utolsó 5 képverziót tartja meg, és törli a régebbi verziókat:
{
"rules": [
{
"rulePriority": 1,
"description": "Tartsuk meg az utolsó 5 verziót",
"selection": {
"tagStatus": "tagged",
"countType": "imageCountMoreThan",
"countNumber": 5
},
"action": {
"type": "expire"
}
}
]
}
Példa 2: Összetett példa: A ‘latest’ verzió soha nem törlődik, de minden más 90 nap után törlődik:
{
"rules": [
{
"rulePriority": 1,
"description": "A 'latest' verzió soha nem törlődik",
"selection": {
"tagStatus": "tagged",
"tagPrefixList": ["latest"]
},
"action": {
"type": "retain"
}
},
{
"rulePriority": 2,
"description": "Minden más kép törlődik 90 nap után",
"selection": {
"tagStatus": "any",
"countType": "sinceImagePushed",
"countUnit": "days",
"countNumber": 90
},
"action": {
"type": "expire"
}
}
]
}
AWS ECR integráció más AWS szolgáltatásokkal
Az AWS ECR könnyen integrálható más AWS szolgáltatásokkal, mint például:
Amazon ECS (Elastic Container Service)
Az ECR közvetlenül támogatja az ECS Fargate és ECS EC2 alapú futtatási módokat. Ha egy ECS clusterben szeretnéd futtatni az ECR-ben tárolt képeket, egyszerűen megadhatod az ECR repository URL-jét a Task Definition-ben.
Amazon EKS (Elastic Kubernetes Service)
Ha Kubernetes-t használsz az AWS-en, akkor az ECR tökéletes tárhely lehet a Kubernetes Pod-ok számára. Az alábbi módon hozhatsz létre hitelesítési „secret”-et, amely lehetővé teszi a Kubernetes számára az ECR repository elérését:
Ha AWS Lambda-t szeretnél konténer alapú csomagként használni, akkor az ECR egy megbízható tárhely lehet az ilyen konténerképek számára.
Összegzés
Az AWS ECR egy igazán sokoldalú konténerképtároló szolgáltatás, amely lehetővé teszi a konténerizált alkalmazások hatékony kezelését. Az életciklus-kezelés segít optimalizálni a tárhely felhasználást, így elkerülhető a felesleges konténerképek felhalmozódása. Emellett az ECR könnyedén integrálható más AWS szolgáltatásokkal, így egy teljes körű konténerizált fejlesztési és futtatási (teszt, éles, stb.) környezetet kínál.
Neked is van olyan ötleted, amelyet konténerképben lehetne ECR-en tárolni? 🚀
A kiszolgáló nélküli (serverless) megoldások hatalmas teret nyertek az elmúlt évtizedben, köszönhetően a felhőszolgáltatóknak is. Emellett a felgyorsult világ, az automatizáció nyújtotta hatékonyság és kényelem is megalapozta ezen technológiai megközelítés sikerét.
Szeretném veletek megismertetni a technológia egyik alappillérét az App Service Plan-t, illetve azt, hogyan is gondolkozott a Microsoft a saját „serverless” világát illetően.
Az Azure App Service Plan a Microsoft Azure egyik kulcsfontosságú eleme, amely lehetővé teszi webalkalmazások, API-k, logikai alkalmazások, function app-ok és háttérfolyamatok futtatását az Azure-ban.
Mi az Azure App Service Plan?
Az Azure App Service Plan az erőforrások csoportosításának és kezelésének a módja az ebben futó alkalmazások számára. Lényegében meghatározza az alkalmazásod alatti infrastruktúra kapacitását és teljesítményét. Hasonlóan egy virtuális géphez, itt is különböző teljesítményre van szükségünk az alkalmazásain megfelelő és stabil működéséhez.
A lényeges különbség – leegyszerűsítve annyi – , hogy ez esetben nincs egy virtuális gépünk amelynél gondoskodnunk kell az operációs rendszer beállításairól, biztonsági frissítéseiről vagy hibakezeléséről. Itt csupán használatba kell vennünk, azaz futtatnunk kell rajta a programkódunkat.
Ahogy említettem, ez is hasonló tulajdonságokkal bír mint egy virtuális gép, csupán virtuális gép nélkül. Tehát az alábbi tulajdonságai vannak egy App Service Plan-nak.:
A vCPU és a memória méret, amit az alkalmazás használhat.
A rendelkezésre álló sávszélességet.
Az alkalmazások párhuzamos futtatásának képességét.
Tárhely mérete, amelyen a programunk forráskódját tárolhatjuk.
És még több kényelmi és/vagy biztonsági beállítás, ami az alkalmazásaink használhatóságát növelik.
Főbb tulajdonságok
Skálázhatóság: Az App Service Plan lehetővé teszi az alkalmazások automatikus vagy manuális skálázását. Skálázhatsz felfelé (nagyobb erőforrások felé – scale up/scale down) vagy kifelé (több példány elindításával – scale out/scale in).
Rugalmasság: Több alkalmazás is futhat ugyanazon a Service Plan-en, így optimalizálhatod a költségeidet.
Különböző árszintek: A plan különböző árszinteket kínál (Free, Shared, Basic, Standard, Premium, és Isolated), amelyek eltérő funkciókat és teljesítményt nyújtanak.
Környezetek támogatása: Támogatja a Windows és Linux környezeteket, valamint a konténeralapú megoldásokat.
Hogyan válaszd ki a megfelelő csomagot?
A megfelelő App Service Plan kiválasztása kritikus az alkalmazásod teljesítménye és költségei szempontjából. Íme néhány szempont:
Forgalmi igények: Ha nagy forgalmat vársz, válassz egy magasabb szintű plan-t.
Funkciók szükségessége: Nézd meg, hogy szükséged van-e például automatikus skálázásra vagy dedikált környezetekre.
Költségkeret: Az alacsonyabb szintek olcsóbbak, de kevesebb funkcióval és erőforrással járnak.
Tippek a hatékony használathoz
Optimalizálás több alkalmazáshoz: Futtass több alkalmazást egy plan-en, ha azok erőforrásigénye hasonló.
Monitorozás: Az Azure Monitor-ral kövesd az alkalmazások teljesítményét és az erőforrás-felhasználást.
Skálázási szabályok beállítása: Használj automatikus skálázási szabályokat a költséghatékonyság érdekében.
Hogyan számlázódik a scale out (kifelé történő skálázás)?
App Service Plan estén lehetőségünk van egy csomagon belül, több ugyanolyan paraméterű példány (instance) futtatni és ezeken futtatni az alkalmazásainkat. Ezek számlázási módja azonban nem mindig egyértelmű, ezért ehhez szeretnék egy kis támpontot adni:
Példányok száma: A díjakat a párhuzamos példányok száma alapján számítja ki a Microsoft. Például, ha egy Standard szintű App Service Plan-t használsz, és 3 példányt futtatsz, akkor az adott szint havi díját háromszorosan kell kifizetned.
Automatikus skálázás: Az Azure skálázási szabályok alapján dinamikusan növeli vagy csökkenti a példányok számát, így a költségeid rugalmasan változhatnak a terhelés függvényében.
Hogyan számlázódik általában az App Service Plan?
Az App Service Plan költségei az alábbi tényezőktől függenek:
Árszint: Az App Service Plan szintje (Free, Shared, Basic, Standard, Premium, Isolated) meghatározza az alapdíjat.
Példányok száma: Több példány futtatása (scale out) növeli a költségeket.
Futási idő: Az Azure óradíjat számít, amely a hónap végén kerül összevonásra. Például, ha egy Standard S1 példány óránként 0,1 USD, akkor 24 órára 2,4 USD, egy hónapra pedig körülbelül 72 USD.
Fontos: Az App Service Plan díját a teljes erőforráscsoport (például CPU, memória) használat alapján számlázzák, nem pedig az egyes alkalmazások után.
Az ingyenes csomag részletei (Free Tier)
Az F1 csomag ideális választás azok számára, aki tesztelési vagy tanulási célú projekteket futtatnak. Jellemzői:
CPU és memória: Limitált CPU és memória, alapvetően tesztelési célokra.
Egyidejű alkalmazások: Egyetlen App Service Plan-en belül több alkalmazás futtatható, de az erőforrások megosztásra kerülnek.
Egyéni domain hiánya: Csak az Azure által biztosított alapértelmezett domain használható
Korlátozott teljesítmény: Alkalmas egyszerű alkalmazásokhoz, mint például statikus weboldalak vagy API prototípusok. Napi 60 perc használatot tesz lehetővé. (ezt nem egyben kell érteni, hanem a használat alapján)
Költség: Teljesen díjmentes, így ideális fejlesztőknek és tanulóknak a kísérletezéshez.
Az App Service Plan funkciói
Egy ilyen csomagnak rengeteg hasznos funkciója van, ezekről készítettem egy rövid listát, csupán az áttekintés végett:
1. Alapvető funkciók
Virtuális erőforrások: CPU, memória és tárolókapacitás biztosítása az alkalmazások számára.
Több alkalmazás támogatása: Több alkalmazás futhat ugyanazon a plan-en, így költséghatékonyabb.
OS támogatás: Windows és Linux alapú környezetek futtatása.
Konténer támogatás: Docker konténerek futtatása.
2. Skálázás és teljesítmény
Manuális skálázás: Több példány hozzáadása kézzel.
Automatikus skálázás: Dinamikus skálázás az alkalmazás terhelése alapján.
Skálázási szabályok: Egyedi szabályok beállítása CPU, memóriahasználat vagy egyéb teljesítménymutatók alapján.
Scale up/out lehetőség: Függőleges (nagyobb erőforrások) és vízszintes (több példány) skálázás támogatása.
3. Fejlesztési és tesztelési funkciók
Deployment Slot-ok: Átmeneti környezetek használata a zökkenőmentes frissítések érdekében.
Blue-Green Deployment támogatás: Különböző verziók tesztelése és gyors váltás az élő környezettel.
Git-integráció: Közvetlenül összekapcsolható GitHub, Azure Repos vagy más verziókezelő rendszerekkel.
CI/CD folyamatok támogatása: Automatizált telepítési folyamatok az Azure DevOps vagy más CI/CD rendszerek használatával.
4. Biztonsági funkciók
SSL/TLS támogatás: Egyéni domain-ekhez is biztosított.
Kötelező HTTPS: Az alkalmazások kényszeríthetik a HTTPS protokoll használatát.
Managed Identity: Alkalmazások biztonságos Azure-erőforrásokhoz való hozzáférése jelszó nélkül.
IP-restrikciók: Az alkalmazások elérésének korlátozása IP-cím alapján.
5. Integrációk és további szolgáltatások
Azure Functions integráció: Kisebb kódok futtatása eseményvezérelt környezetben.
Application Insights: Teljesítményfigyelés és hibakeresés az Azure Monitor segítségével.
Könnyű adatbázis-integráció: Az Azure SQL, Cosmos DB, vagy más adatbázis-szolgáltatások gyors csatlakoztatása.
API Management integráció: API-k könnyű publikálása és kezelése.
6. Adatvédelem és mentések
Automatikus biztonsági mentések: Az alkalmazások rendszeres mentése (elérhető a Standard szinttől).
Geo-disztribúció: Alkalmazások elérhetősége több régióban is biztosított.
7. Egyéb funkciók
Ingyenes csomag (Free Tier): Alapvető tesztelési és fejlesztési környezet.
Támogatás egyéni domain-ekhez: Egyedi domain nevek hozzárendelése az alkalmazásokhoz (Standard szinttől).
High Availability (HA): Alkalmazások magas rendelkezésre állásának támogatása.
Traffic Manager integráció: Forgalomirányítás globális alkalmazások számára.
Egyedi skálázási beállítások: Dedikált erőforrások elérhetősége a Premium és Isolated szinteken.
Funkciók csomagok szerint
Funkció
Free
Shared
Basic
Standard
Premium
Isolated
Több alkalmazás támogatása
✅
✅
✅
✅
✅
✅
Deployment Slot-ok
❌
❌
❌
✅
✅
✅
SSL/TLS támogatás
❌
❌
✅
✅
✅
✅
Automatikus biztonsági mentés
❌
❌
❌
✅
✅
✅
Geo-disztribúció
❌
❌
❌
✅
✅
✅
Dedikált erőforrások
❌
❌
✅
✅
✅
✅
Az Azure App Service Plan használata során fontos figyelembe venni az erőforrás-igényeket, az alkalmazás skálázási igényeit és a költségvetési korlátokat. Az ingyenes csomag nagyszerű kezdőknek, míg a Deployment Slots és a skálázási lehetőségek nagyobb projekteknél nyújtanak hatalmas előnyt. A megfelelő konfigurációval optimalizálhatod az alkalmazásaid teljesítményét és költséghatékonyságát.
Neked már van olyan webalkalmazásod, amely Azure-ban fut?
Aki ismer, az már tudja, hogy nekem a kiszolgáló nélküli megoldások a kedvenceim. Ezek azok, amelyekben rengeteg potenciál van mind kezdőknek, mind haladóknak. Ezért is írok erről szívesen.
Ma az AWS zászlóshajóját mutatom be nektek, az AWS Lambda-t. A Lambda az Amazon Web Services (AWS) egyik legsokoldalúbb és leginnovatívabb szolgáltatása, amely a „serverless” megközelítés középpontjában áll. Amikor valaki találkozik az AWS-el, akkor hamar szembetűnik, hogy ez az. a szolgáltatás, amely megkerülhetetlen részét képezi az AWS alapú ökoszisztémának. Hogy miért is van így? Ezt próbálom bemutatni nektek a következő sorokban.
Mi az AWS Lambda?
Az AWS Lambda egy „serverless” szolgáltatás, amely lehetővé teszi, hogy kódot futtassunk anélkül, hogy infrastruktúrát (virtuális gépet) kellene kezelnünk. A szerverek konfigurálásától az operációs rendszerek frissítéséig minden teendőt az AWS végez el helyettünk, miközben mi csak a kódra koncentrálunk. Azaz csupán programoznunk kell. Ez már önmagában is egy nagyon jó dolog.
Hogyan működik az AWS Lambda?
Az AWS Lambda működése néhány kulcsfontosságú lépésre osztható:
Kód feltöltés: Alkalmazhatod a kódodat szöveges fájlként, egy zip fájl formájában, vagy egy konténer képként. Az AWS Lambda támogatja a Python, NodeJS, Java, Go, Ruby és .NET nyelveket, valamint ezek különböző verzióit (általában a legfrissebb és legstabilabb, aktuális verziókat).
Eseménykezelő: Meg kell határoznod a „handler” nevű függvényt, amelyet a Lambda futtat, amikor egy esemény bekövetkezik. Ez a függvény tartalmazza az üzleti logikát.
Kiváltó esemény (trigger) konfigurálása: Mindig egy esemény lesz, ami elindítja a Lambda-t, lehet egy HTTP kérés (pl.: API Gateway-n keresztül), egy S3 fájl feltöltés, egy DynamoDB tábla módosítása vagy akár egy CloudWatch időzítés.
Automatikus futtatás és skálázás: Az AWS Lambda függvényed futtatása megkezdődik, amikor a kiváltó esemény bekövetkezik. Több párhuzamos futtatás esetén a Lambda dinamikusan skálázódik, attól függően, hogy mennyi erőforrásra van szükség.
Fizetés használat alapján: Mint a legtöbb felhő alapú megoldás ez is Pay-As-You-Go modellben számlázódik, azaz csak azért a futási időért és memóriahasználatért fizetsz, amelyet valóban felhasználtál.
Legfontosabb összetevők
Amikor Lambda-t kezdünk használni a következő két összetevő lesz számunkra a legfontosabb. Ezek fogják azt is eldönteni, hogy egyáltalán a Lambda-e az a megoldás amire szükségünk van.
Események (triggers)
Ahogy fent már olvastad, mindig kell egy esemény, ami elindítja a Lambda függvényünket. Mivel az AWS Lambda szorosan van integrálva az AWS ökoszisztémájával, így nem meglepő, hogy az alábbiak a leggyakoribb eseményforrások:
Amazon S3: Automatikusan futtatható a kód, amikor egy fájl feltöltődik vagy módosul egy S3 bucket-ben.
Amazon DynamoDB: Tábla módosítási események kezelése.
Amazon API Gateway: RESTful API-k és webhookok létrehozása.
Amazon EventBridge: Komplex eseményalapú architektúra kialakítása.
Ezeket tudjuk kombinálni ráadásul oly módon is, hogy több Lamda függvényt használunk együtt.
Memória és időkorlát
Habár az AWS világában a Lambda szinte megkerülhetetlen, mégis vannak helyzetek, amikor nem használhatjuk. Ezért azt javaslom, hogy mielőtt eldöntöd, hogy a Lambda lesz-e az a szolgáltatás amit igénybe veszel a választott megoldás kivitelezéséhez, vizsgáld meg, hogy az alábbi korlátozások engedik-e ezt neked:
Memória limit: 128 MB és 10 GB közötti memória allokálható egy funkcióhoz.
Időkorlát: Egy Lambda funkció maximális futási ideje 15 perc lehet.
Tehát ha hosszan futó függvényeket vagy kódokat akarsz használni, a Lambda nem lesz számodra alternatíva. Ne csüggedj, ez esetben lesz más lehetőséged is.
Mikor érdemes használni az AWS Lambda-t?
Gyakorlati példák
Adatfeldolgozás valós időben: Pl. egy S3 bucketbe feltöltött fájl automatikus feldolgozása (pl. képek tömeges átméretezése, videók konvertálása).
RESTful API-k: Az AWS Lambda és az API Gateway kombinációjával gyorsan létrehozhatsz API-kat.
IoT alkalmazások: IoT eszközök eseményeinek kezelése.
Batch feldolgozás: Nagy mennyiségű adat csomagban történő feldolgozása.
Előnyök
Automatikus skálázás: Nem kell manuálisan módosítanod az erőforrásokat.
Nincs infrastruktúrakezelés: Az AWS kezeli a szerverek karbantartását.
Rövid fejlesztési ciklus: Gyorsan prototípusokat hozhatsz létre. Tipikus PaaS megoldás. 🙂
Optimalizálás és bevált gyakorlatok
A fent említett korlátozások miatt erősen ajánlott a lehető legjobban optimalizált kódok alkalmazása a Lambda függvényeknél. Ehhez szeretnék egy kis segítséget nyújtani:
Kisebb függvények létrehozása: Használj kisebb, rövidebb rutinokat és metódusokat az üzleti logika felépítéséhez, amelyek gyorsan és hatékonyan futnak.
Üresjárat csökkentése: A Lambda figyeli és leállítja az nem használt kapcsolatokat, így előfordulhat, hogy amikor újra használni szeretnék azt, akkor hibát kapunk. Ilyen helyzetekben használj keep-alive technikákat.
Környezeti változók: Használj környezeti változókat a dinamikus változók tárolásához. Pl.: S3 bucket neve, kapcsolati információk.
Rekurzív hívások kerülése: Kerüld az olyan eseteket, amikor a függvény önmagát hívja meg, vagy olyan folyamatot indít el, amely újra meghívhatja a függvényt. Ez a költségek növekedéséhez vezethet.
Monitoring és hibakeresés: Állítsd be és használd a CloudWatch Log-okat a futási információk megértéséhez és elemzéséhez.
Dokumentált, szabványos hívások használata: Ne használj, olyan hívásokat és megoldásokat, amelyek nem dokumentáltak vagy nem szabványosak. Ezzel megakadályozhatod, hogy a rendszeres AWS API frissítések kompatibilitási vagy futási hibákat okozzanak.
Idempotens kód használata: Írj olyan kódot, amely többszöri végrehajtása ugyanazzal a bemenettel ugyanazt az eredményt adja.
Összegzés
Az AWS Lambda a serverless megoldások egyik úttörője, amely modernizálta a felhőalapú alkalmazások fejlesztését. Ha költséghatékony, rugalmas és gyors megoldást keresel, az AWS Lambda egy kiváló választás.
Az elmúlt hetekben megismerhettük a böngészőben használható parancssori eszközt, a Cloud Shell-t a nagyobb felhőszolgáltatóknál, úgy mint az AWS vagy a Google Cloud. Amint láthattuk, a CloudShell egy olyan böngészőben használható parancssori eszköz, amely leegyszerűsíti a „kommunikációt” az aktuális felhőszolgáltatónk és közöttünk. Hiszen nem kell semmi új komponenst nem kell telepítenem a számítógépemre, hogy kezelni tudjam a felhőerőforrásaimat. Ez az eszköz kiemelten hasznos mindazok számára, akik szeretnének kísérletezni, alkalmazásokat fejleszteni, tanulni vagy hibákat elhárítani a felhőben. És mindezt nagyon gyorsan.
A korábbi cikkekben bemutatott megoldásokkal ellentétben, az Azure esetén nem lesz olyan rejtett gép a háttérben, amelyen futtathatjuk a parancsainkat. Itt kissé másképpen működik, de ne szaladjunk ennyire előre.
Mi az Azure Cloud Shell?
Az Azure Cloud Shell az egyik legkényelmesebb és legrugalmasabb eszköz, amelyet az Azure felhasználóknak kínál. Ez a böngésző alapú parancssori környezet lehetővé teszi, hogy bárhonnan, bármilyen eszközről elérd és kezeld az Azure erőforrásaidat. Nincs szükség telepítésekre vagy konfigurációkra, mindössze egy internetkapcsolat és egy web böngésző kell hozzá.
Ami a legjobb ebben és az Azure Cloud Shell-t egyedivé teszi, hogy egy helyen férhetsz hozzá az Azure CLI-hoz, a PowerShell-hez, és számos előre telepített eszközhöz, miközben automatikusan hozzáférsz egy tárhelyhez (tárfiók – storage account) is, ahol a fájljaid és szkriptek is találhatók. Ez az eszköz nemcsak időt takarít meg, de megkönnyíti az Azure erőforrások hatékony és biztonságos kezelését.
Fő funkciók, előnyök és tippek:
Webalapú hozzáférés: Bármilyen böngészőből elérhető (akár mobiltelefonról is), nincs szükség telepítésre.
Beépített eszközök: Bash, PowerShell, Azure CLI, és számos más előre telepített eszköz. (Pl.: Git)
Tárhely integráció: Automatikus kapcsolat egy előre megadott tárfiókkal (Azure Storage Account) a szkriptek és fájlok tárolásához. Ezt a tárhelyet ráadásul felcsatolhatod a helyi számítógépedre is.
Egyszerű erőforrás-kezelés: Parancsok és szkriptek egyszerű, gyors futtatása az Azure erőforrások hatékony kezeléséhez.
Alias-ok beállítása: Gyorsítsd meg a munkádat egyéni parancsokkal.
VS Code integráció: Használd a Cloud Shell-t közvetlenül a Visual Studio Code-ból.
Gyorsbillentyűk: Ismerd meg a legfontosabb billentyűkombinációkat, hogy úgy dolgozz mint egy profi.
PowerShell és Bash együtt
A többi felhőszolgáltatótól eltérően, a Microsoft gondolt azon szakemberekre, akiknél vagy PowerShell vagy Bash tapasztalat a nagyobb. Hiszen előfordulhat, hogy valaki a felhő előtt csak PowerShell-t használt, vagy csak Bash-t. Azure-ban pedig senkinek sem kell újratanulnia semmit vagy megszoknia egy új nyelvet.
Egyetlen kattintással választhatunk Bash vagy PowerShell környezetet és ha meggondolnánk magunkat akkor is bármikor átválthatunk a másikra. Teljes szabadságot kapunk. Ez igazán jó hír mindenkinek. 🙂
Kattint a jobb felső sarokban lévő Cloud Shell ikonra.
Válaszd ki, hogy Bash-t vagy PowerShell-t szeretnél használni először
Utána lehetőséged van Tárfiók nélküli beállításra (ekkor a használat végén minden fájl és parancs előzmény törlődik) vagy ha szeretnéd tárolni a szkriptjeidet és fájljaidat, akkor a Tárfiók csatlakoztatása lehetőséget válaszd.
Ezután ki kell választanod azt az előfizetést, amelyben a fájlokat tároló tárfiók van/lesz.
Következő lépésben 3 lehetőséged van:
Meglévő tárfiók kiválasztása: Ez akkor hasznos, ha a tárfiókod már létezik és azt szeretnéd felcsatolni a Cloud Shell mögé
Létrehozunk Önnek egy tárfiókot: Ez esetben az Azure létrehoz egy tárfiókot véletlenszerűen a kijelölt előfizetésben. Ez akkor hasznos, ha gyorsan szeretnék a beállítást elvégezni. (nem javasolt)
Szeretnék létrehozni egy tárfiókot: Általában ezt a lehetőséget választjuk a legtöbb esetben, mert így mi adjuk meg, hogy milyen néven és melyik erőforráscsoportba kerüljön a tárfiók.
Ha a harmadikat választottuk, akkor a következő lapon meg kell adnunk az alábbi adatokat:
Előfizetés neve: Ahová a tárfiókot létrehozzuk
Erőforráscsoport: Ahová a tárfiók létrejön
Régió: Melyik régióban legyen az erőforráscsoport és a tárfiók
Tárfiók neve: Egyedi névnek kell lennie
Fájlmegosztás: Fájlmegosztás neve, ahol a fájlokat majd mentjük és amit fel tudunk csatolni a saját gépünkre (Windows, Linux, Mac)
Ha ezzel megvagyunk, akkor a Létrehozás gombra kattintva 1-2 perc alatt befejeződik a Cloud Shell beállítása.
Példa parancsok
Amint elindult a Cloud Shell, végtelen lehetőségünk van arra, milyen parancsokat futtatunk. Innen már csak rajtunk és a kitűzött céltól függ a parancsok bonyolultsága és jellege.