paas

2026 01 29

Az Azure Logic Apps csendben felnőtt – és AI-kompatibilis is

agents, Azure, Cloud, mcp, Mesterséges Intelligencia agenticai, ai, azure, cloud, cloudservices, mcp, paas

| Olvasási idő: 5 perc |

Amikor az elmúlt években Azure Logic Apps-ről beszélgettünk, gyakran ugyanoda jutottunk: jó eszköz, rengeteg integrációs lehetőséggel, mégis maradt bennem egy állandó hiányérzet. Én magam is sokszor éreztem azt, hogy működik, de nem igazán élvezetes vele dolgozni. Mondhatni, kicsit merev és nem túl vonzó a grafikus felülete.

Ez az érzés 2025 nyarán is nagyon erősen visszajött, amikor készítettem a „NoCode és LowCode megoldások Azure-ban és AWS-ben” videós képzési anyagot. Akkor is pontosan ezt láttam: az Azure Logic Apps elképesztően sok lehetőséget rejt, mégsem olyan kényelmes használni, mint amennyit valójában tud. Nem a funkcionalitás hiányzott, hanem a használhatóság nem nőtt fel a képességekhez.

2025-ben viszont ez a helyzet látványosan megváltozott. Nem egy hangos marketingkampánnyal, hanem több, egymásra épülő, tudatos fejlesztéssel. Ráadásul ezek a változások már nem csak az integrációról szólnak, hanem arról is, hogyan illeszkedik a Logic Apps az AI-ügynökökkel dolgozó architektúrákba.

Azure Logic Apps Designer újratervezése

2025 novemberében a Microsoft bejelentette az Azure Logic Apps Designer teljes újratervezését, amely jelenleg Public Preview státuszban érhető el a Standard workflow-khoz.

Ez nem egyszerű UI-frissítés. Inkább egy felismerés eredménye. A Logic Apps-et ma már nem csak kisebb automatizmusokra használják, hanem üzletileg kritikus folyamatokra is.

A korábbi designer elsősorban kisebb workflow-kra volt optimalizálva. Nagyobb folyamatoknál gyorsan átláthatatlanná vált, és hosszabb távon mentálisan is fárasztó volt vele dolgozni.

Az új szerkesztő ezzel szemben sokkal jobban kezeli a nagy és összetett workflow-kat. Logikusabb lépésszervezést ad, és végre nem büntetés egy több tucat lépésből álló folyamat karbantartása.

Tehát az új funkció jelenleg csupán a Standard verzióknál elérhető.

Azure Logic Apps new designer availability

Erre figyelni kell, ha szeretnék kipróbálni az új felületet. Itt sem alapértelmezetten kapjunk, hanem be kell azt kapcsolnunk. Ezt könnyű megtenni a portálon.

Ha pedig nem tetszik, bármikor vissza is válthatunk a korábbi megoldásra.

Az XML kezelése végre élhetőbb

Kevésbé látványos, de szakmailag nagyon fontos változás az XML-kezelés javítása.

Aki dolgozott már SOAP-alapú integrációkkal, legacy rendszerekkel vagy vállalati adatcsere-folyamatokkal, pontosan tudja, mennyire nehézkes volt korábban az XML feldolgozása Logic Apps-ben.

2025-ben ezen érezhetően javítottak. Az XML struktúrák kezelése átláthatóbb lett, a kifejezések logikusabban épülnek fel, és az egész élmény már közelít a JSON feldolgozás egyszerűségéhez. Nem lett tökéletes, de végre nem érzem azt, hogy tudatosan kerülni kellene.

Azure Logic Apps mint MCP szerver

A Microsoft Build 2025 egyik stratégiailag legfontosabb bejelentése az volt, hogy az Azure Logic Apps Standard képes MCP, vagyis Model Context Protocol szerverként működni.

Ez elsőre technikai részletnek tűnhet, valójában azonban szemléletváltást jelent. Az MCP célja az, hogy az AI-ügynökök strukturált módon érjenek el műveleteket. Nem ad-hoc API-hívásokkal, hanem egy egységes, szabványosított protokollon keresztül.

Ebben a modellben a Logic Apps egy vizuálisan definiált, enterprise szintű végrehajtási réteggé válik. Több száz connector, kiforrott security és governance modell, valamint most már MCP-kompatibilis működés áll rendelkezésre. Ez ideális alapot ad AI-agentek számára is.

Egy Azure Logic Apps példa

Képzelj el egy AI-ügynököt, amely beérkező e-maileket elemez, majd eldönti, hogy incidensről, számlázási kérdésről vagy support megkeresésről van szó. A döntés után elindítja a megfelelő üzleti folyamatot.

Ebben a felállásban az AI-ügynök hozza meg a döntést, a Logic Apps pedig megbízhatóan végrehajtja azt, ahogy eddig is tette azt. Jegy létrehozás, adatlekérdezés, értesítés, auditálás mind jól definiált workflow-kban történik, MCP-n keresztül.

Itt válik igazán érdekessé a Logic Apps szerepe. Nem okosabb lesz, hanem stabilabb és kiszámíthatóbb végrehajtó réteggé válik.

Mit jelent ez ha most kezded?

Ha most ismerkedsz a felhővel vagy a NoCode és LowCode világgal, akkor a Logic Apps továbbra is könnyen tanulható maradt. Nem kell azonnal AI-agentekben vagy AI-ügynökökben gondolkodnod. Az alap automatizmusok ugyanúgy működnek, mint eddig.

A különbség az, hogy amit most tanulsz, az nem zsákutca. Később természetes módon bővíthető AI-alapú megoldások irányába is.

Haladóknak és karrierváltóknak

A 2025-ös változások egyértelmű irányt mutatnak. Az integráció, az automatizálás és az AI egyre inkább összenő.

Az Azure Logic Apps ma már nem csak összeköt, hanem orchestration rétegként és végrehajtási motorként működik. AI-ügynökök stabil háttérrendszere lehet, nagyvállalati környezetben is.

Ez hosszú távon értelmezhető, jövőálló tudás. Ráadásul most már mindezt egyben elérheted az Azure-on belül.

Öszefoglalva

2025-ben az Azure Logic Apps csendben, de határozottan szintet lépett. Az új designer használhatóbbá tette, az XML-kezelés élhetőbb lett, az MCP-szerver képesség pedig teljesen új szerepbe helyezte a szolgáltatást.

Számomra ez azt jelenti, hogy a Logic Apps újra komolyan vehető eszköz lett. Nem csak integrációra, hanem AI-ügynökökkel együttműködő architektúrákban is.

Ami fontos: Az új designer sem váltja ki az átgondolt tervezést.

Ígérem, nem állunk meg az elméletnél. Hamarosan hozok egy részletes, végigkövethető példát is, amelyet már az új Logic Apps designerrel valósítok meg, valós problémára, valós döntési pontokkal. Megmutatom, hol erős az új megközelítés, és azt is, hol vannak még kompromisszumok.

Ha követsz, elsőként látod majd ezt a gyakorlati anyagot, és nem csak azt fogod érteni, mi változott, hanem azt is, mikor és miért érdemes használni.

Ha szeretnél ebben az irányban tisztábban látni, érdemes követned a további cikkeimet és feliratkozni az InfoPack hírlevélre.

2025 07 21

A Kubernetes láthatatlan hősei: worker node-ok

AWS, Azure, Cloud, Docker, GCP, Kubernetes cloudservices, docker, iaas, k8s, kubernetes, microservices, paas, serverless

| Olvasási idő: 3 perc |

Legutóbb a Kubernetes agyáról olvashattál. Ez a vezérlősík, ami az a logikai réteg, amely a teljes fürt irányításáért felelős. Tehát már ismerjük azt, aki koordinálja a feladatokat. Akkor felmerül a kérdés: Ki végzi a háttérmunkát?

Ezek lesznek a worker node-ok. Ők azok, akik, szuperhősként dolgoznak értünk és az ügyefeleinkért.

A worker node szerepe

A worker node a Kubernetes fürt azon egysége, ahol ténylegesen futnak a kapszulák. Ezek a csomópontok több alapvető szolgáltatást futtatnak, amelyek biztosítják, hogy az alkalmazásaink megbízhatóan működjenek.

Minden node-on három fő komponens működik:

kubelet

A kubelet a node ügynöke. Folyamatosan kommunikál a vezérlősíkkal, és gondoskodik arról, hogy a node-on valóban azok a kapszulák fussanak, amelyeket a Kubernetes elvár. Ehhez az adott csomóponton telepített konténer futtató motorral dolgozik együtt – például containerd vagy cri-o.

kube-proxy

A kube-proxy felelős a hálózati forgalom irányításáért a kapszulák között, valamint a kívülről érkező kérések célba juttatásáért. Ezt iptables szabályokkal vagy IPVS (IP Virtual Server) segítségével végzi. Létezik egy „userspace” módja is, amelyben a proxy a szolgáltatásokat és azok végpontjait figyeli, és véletlenszerű portokon keresztül továbbítja a forgalmat.

Ezen kívül hálózati bővítmények (például a Cilium) is telepítésre kerülhetnek kapszula formájában, a választott hálózati megoldástól függően.

Konténer futtató motor

Ez a komponens végzi a konténerek konkrét futtatását a node-on. Bár a legtöbb esetben containerd vagy cri-o van használatban, a Kubernetes további motorokat is támogat, és ez a jövőben bővülhet.

Kiegészítő szolgáltatások: naplózás és metrikák

A Kubernetes alapból nem biztosít fürtszintű naplózási megoldást. Ehelyett egy másik CNCF projektet, a Fluentd-t használják sokan, amely egy egységes naplózási réteget biztosít: képes szűrni, pufferelni és továbbítani a logokat.

A metrikák (például CPU- és memóriahasználat) esetén szintén csak alapszintű támogatás érhető el a metrics-server nevű komponens révén. Komplexebb metrikákhoz sokan a Prometheus projektet integrálják.

Mi változik, ha a Kubernetes a felhőben fut?

Felügyelt node-ok vagy serverless?

A legtöbb felhőszolgáltató kínál felügyelt Kubernetes szolgáltatást (pl. EKS, AKS, GKE), ahol a node-ok indítása, frissítése, skálázása az ő rendszerük által automatizált. Emellett egyes platformok (pl. AWS Fargate, Azure Container Apps) lehetővé teszik serverless futtatást, ahol nincs is szükség konkrét node-okra: a kapszulák egy absztrakt erőforrásrétegen futnak, amelyet a platform kezel.

Amikor a Kubernetes nem saját hardveren, hanem valamilyen nyilvános felhőszolgáltatón (pl. AWS, Azure, GCP) fut, a worker node-ok feladatai technikailag hasonlók, de az üzemeltetésük, méretezésük és karbantartásuk módja jelentősen leegyszerűsödik – vagy éppen el van rejtve a felhasználó elől.

Automatikus skálázás

A felhőben könnyen alkalmazható a Cluster Autoscaler és a Horizontal Pod Autoscaler, így a worker node-ok automatikusan hozzáadhatók vagy eltávolíthatók a terhelés függvényében, anélkül hogy manuálisan kellene VM-eket kezelni.

Infrastruktúra szétválasztása

A felhőben gyakori, hogy külön választják a vezérlősíkot (pl. felügyelt, elrejtett control plane) és a worker node-okat. A vezérlősík karbantartása, magas rendelkezésre állása és frissítése a szolgáltató felelőssége, míg a workerök gyakran saját fiókban, saját szabályozással működnek.

Biztonsági integrációk

A node-ok sokkal könnyebben integrálhatók felhőspecifikus biztonsági szolgáltatásokkal, például IAM (AWS), Managed Identity (Azure), vagy Google IAM (GCP), amelyek segítségével minden kapszula hitelesített módon érheti el a felhőszolgáltatásokat.

Összefoglalás

A worker node-ok a Kubernetes rendszer szorgos hősei – akár helyben, akár a felhőben. Míg a helyi környezetekben a node-ok teljes irányítása az üzemeltető kezében van, a felhőben számos feladat automatizálttá vagy teljesen átláthatatlanná válik. Ez megkönnyíti az üzemeltetést, de egyben új típusú megértést is igényel.

2025 07 10

Kubernetes control plane: A klaszter agya működés közben

AWS, Azure, Cloud, Docker, GCP, Kubernetes cloudservices, docker, iaas, k8s, kubernetes, microservices, paas

| Olvasási idő: 3 perc |

A Kubernetes egyik legfontosabb eleme a vezérlősík (control plane) megfelelő működése. Ez a komponenscsoport gondoskodik arról, hogy a klaszter (cluster) aktuális állapota mindig összhangban legyen a kívánt állapottal. Nézzük meg a vezérlősík fő részeit, azok működését és szerepét a Kubernetes-ökoszisztémában.

Mi az a vezérlősík?

A vezérlősík az a logikai réteg, amely a teljes fürt irányításáért felelős. Olyan kapszulák (pod-ok) összessége, amelyek különböző folyamatokat (pl. API-kiszolgálás, ütemezés, állapotkezelés) futtatnak. Minden művelet ezen keresztül történik, legyen szó felhasználói kérésről vagy a rendszer belső kommunikációjáról.

Főbb vezérlősík-komponensek

kube-apiserver

A kube-apiserver a Kubernetes API bejárata. Ez az egyetlen komponens, amely közvetlenül kommunikál az etcd-adatbázissal, és minden kérést rajta keresztül kell lebonyolítani.

Feladatai:

Kérések fogadása és érvényesítése (mind felhasználói, mind rendszeroldali)
A REST API műveletek kiszolgálása
Az objektumok állapotának frissítése az etcd-ben

A Kubernetes v1.18-as verziójától kezdődően a Konnectivity szolgáltatás külön tudja választani a felhasználói és rendszerforgalmat, bár a legtöbb hálózati bővítmény még nem teszi ezt meg, ami hatással lehet a teljesítményre és a biztonságra.

A Kubernetes aktuális verzióiról az alábbi hivatalos cikkben olvashatsz.

kube-scheduler

Ez a komponens dönti el, hogy melyik csomóponton fusson egy új kapszula. A döntést egy algoritmus hozza meg az alábbi tényezők alapján:

Elérhető erőforrások (pl. kötetek)
Kvóták, címkék (labels), tűrések (tolerations) és taint-ek
Felhasználói kényszerítések (node affinity, node selector)

A döntés nem garantálja az azonnali elindulást, például ha egy adott erőforrás még nem áll rendelkezésre, vagy nincs elegendő szerverkapacitás.

etcd

Az etcd egy nagy teljesítményű kulcs-érték (key-value) tároló, amelyben a Kubernetes tárolja a teljes fürt állapotát. Tulajdonságai:

B-fa alapú adattárolás, módosítás helyett új értékek hozzáfűzése
Verziókezelés és ütközéskezelés: ha több kérés érkezik, csak az első sikeres, a többi 409-es hibával tér vissza
Leader-alapú konszenzus: az egyik példány vezér szerepben van, a többiek követők vagy tanulók (learners)

Mivel az etcd a fürt perzisztens állapotának egyetlen forrása, rendszeres biztonsági mentés (snapshot) javasolt karbantartás előtt.

kube-controller-manager

Ez a vezérlőhurok (control loop) démon több különálló vezérlőt futtat. Ezek felelősek azért, hogy az aktuális állapot megfeleljen a kívánt állapotnak.

Példák:

Névtér- (namespace) és replikavezérlő
Végpontok (endpoints) kezelése

A komponens folyamatosan figyeli az állapotot, és szükség esetén beavatkozik.

cloud-controller-manager

Ez egy opcionális komponens, amely a felhőszolgáltatókkal (pl. Azure, AWS, GCP) való integrációt kezeli. Lehetővé teszi, hogy a felhő specifikus műveletek ne befolyásolják a Kubernetes alapműködését.

Jellemzők:

Külső (out-of-tree) vagy belső (in-tree) telepítés
A kubelet elindításához meg kell adni a --cloud-provider=external kapcsolót
Bővíthető saját megvalósítással

CoreDNS

A Kubernetes DNS-szolgáltatása. Felváltotta a korábbi kube-dns megoldást. Rugalmas, bővíthető, összefűzött plugineken keresztül oldja meg a névfeloldást, „szolgáltatásfelfedezést” és más, hálózattal kapcsolatos funkciókat.

Kiegészítők és bővítmények

A vezérlősík alapkomponensein kívül egyes bővítmények is elengedhetetlenek a termelési cluster-ekben, például:

DNS (CoreDNS)
Naplózás (pl. Fluentd, Loki)
Monitorozás (pl. Prometheus)
Házirend kezelés (pl.: Kyverno)

Ezek közül nem mindegyik natív Kubernetes-komponens, de erősen ajánlottak a stabil működéshez.

Felügyelt Kubernetes-szolgáltatások

A felügyelt Kubernetes-szolgáltatások esetén – mint például az Azure Kubernetes Service (AKS), Amazon EKS vagy Google Kubernetes Engine (GKE) – a vezérlősík (control plane):

nem hozzáférhető,
nem számlázott külön tételként (vagy korlátozottan),
láthatatlanul működik a háttérben,
és a felhőszolgáltató üzemelteti és frissíti automatikusan.

Ez a felhasználók számára azt jelenti, hogy:

Nem kell gondoskodniuk az etcd, kube-apiserver, scheduler stb. frissítéséről, biztonságáról, skálázásáról.
A teljes klaszter vezérlése API-n keresztül történik, de annak háttér-infrastruktúráját a szolgáltató kontrollálja.
A látható és menedzselhető réteg a munkavégző csomópontok (worker nodes) és a rajtuk futó kapszulák.

Összegzés

A vezérlősík biztosítja a Kubernetes fürt szívverését. Komponensei szorosan együttműködnek annak érdekében, hogy az alkalmazások megbízhatóan, skálázhatóan és konzisztensen fussanak.

A vezérlősík megértése nélkülözhetetlen minden Kubernetes-adminisztrátor vagy DevOps szakember számára.

2025 07 07

Kubernetes komponensek: a fő elemek érthetően

AWS, Azure, Cloud, GCP, Kubernetes cloudservices, cluster, docker, iaas, k8s, kubernetes, microservices, paas

| Olvasási idő: 3 perc |

Az elmúlt hetekben, hónapokban már sokat olvashattatok a Kubernetes-ről. Azt már mindenki fejből tudja, hogy a Kubernetes egy nyílt forráskódú konténer-orchestrációs rendszer, amely lehetővé teszi a modern, skálázható alkalmazások automatikus telepítését, kezelését és méretezését. Ebben a bejegyzésben a Kubernetes fürt (cluster) fő összetevőit mutatom be, kicsit másképp ahogy esetleg eddig tettem.

Eddig inkább a szerver szintű szerepkörökről és a nagyobb komponensekről beszéltünk. Ideje azonban kicsit mélyebbre ásni.

A Kubernetes-fürt felépítése

Egy Kubernetes-fürt legalább a vezérlősíkból (control plane) és egy vagy több munkavégző csomópontból (worker node) áll. Minden komponens úgy van megtervezve, hogy API-hívásokkal együttműködve biztosítsa az automatizált működést.

A fürt főbb elemei:

Vezérlősík és munkavégző csomópontok

A vezérlősík az agy: feladatai közé tartozik a döntéshozatal, az állapotfigyelés és a feladatkiosztás. A legfontosabb komponensek:

kube-apiserver: az API-hívások belépési pontja, a fürt „művészebejárója”.
etcd: egy elosztott kulcs-érték adatbázis, amely a fürt állapotát tárolja.
kube-scheduler: eldönti, melyik munkavégző csomóponton induljanak el az új kapszulák.
kube-controller-manager: különböző vezérlők futtatása (pl. replikáció, csomópontkezelés).
cloud-controller-manager (felhőalapú környezeteknél): integráció a felhőszolgáltatóval.

A munkavégző csomópontokon futnak a valódi alkalmazáskonténerek. Ezek fő elemei:

kubelet: kapcsolatot tart az aggyal, gondoskodik a kapszulák futtatásáról.
kube-proxy: hálózati forgalom továbbítása, szolgáltatások elérésének biztosítása.
konténerfuttató: például containerd vagy CRI-O, amely ténylegesen futtatja a konténereket.

Vezérlők (operators)

Az operátorok magas szintű vezérlőprogramok, amelyek egy alkalmazás teljes életciklusát kezelik. Az operátorok Kubernetes API-kra épülnek, és képesek komplex alkalmazások kezelésére úgy, mintha beépített Kubernetes-erőforrások lennének.

Szolgáltatások (services)

A szolgáltatás egy állandó hálózati elérhetőséget biztosít a kapszulák számára. Mivel a kapszulák újraindulhatnak és IP-címük változhat, a szolgáltatás stabil interfészként szolgál.

Típusai:

ClusterIP (belső elérés)
NodePort (külső elérés egy adott porton)
LoadBalancer (felhőalapú betöltéselosztás)

Kapszulák (pods)

A legkisebb végrehajtható egység. Egy kapszula egy vagy több konténert tartalmazhat, amelyek közös IP-címet, fájlrendszert és hálózati környezetet használnak.

A kapszulák rövid életűek és általában replikációs kontrollerek (replica set) vagy telepítések (deployments) által menedzseltek.

Névterek (namespaces) és kvóták

A névterek lehetővé teszik a fürtön belüli erőforrások logikai elhatárolását. Ideálisak például több környezet (pl. fejlesztés, teszt, éles) elkülönítésére.

A kvóták szabályozzák, mennyi erőforrást (CPU, memória, tárolás stb.) használhat egy névtér. (ezen kívül még máshol is lesz szerepe)

Hálózat és házirendek

Minden kapszula teljes mértékben elérheti a többi kapszulát az IP-címükön keresztül – ez a Kubernetes hálózati modell alapelve. A hálózati beállításokat egy plugin (pl. CNI) kezeli.

A hálózati házirendek (NetworkPolicies) szabályozzák, hogy mely kapszulák kommunikálhatnak egymással.

Tárolás (storage)

A tárolási rendszer lehetővé teszi, hogy a kapszulák tartós adatokat használjanak. Ezek lehetnek:

Volatile tárolók (pl. emptyDir)
Állandó kötés (Persistent Volume)
Dinamikus provizionálás (StorageClass)

A tárolást gyakran egy külső szolgáltatás biztosítja (pl. NFS, iSCSI, felhőalapú tárhelyek).

Ezek akkor fontosak, amikor olyan alkalmazásokat futtatunk a cluster-en, amelyeknél fontos az adatok hosszútávú és biztonságos tárolása. Ilyen például egy adatbázis megoldás. (MySQL, MariaDB, stb.)

Egybinárisos architektúra

Több Kubernetes disztribúció kínál „egybinárisos” megoldást, ahol a Kubernetes összetevői egyetlen bináris fájlban kerülnek egyesítésre. Ez különösen hasznos lehet teszteléshez, lokális fejlesztéshez vagy különleges környezetekhez.

Verziófrissítés és kompatibilitás

A fürt frissítése során figyelembe kell venni, hogy az egyes komponenseket külön csapatok fejlesztik, és szorosan illeszkednek egymáshoz. A verziók inkompatibilitása működési hibákat okozhat.

A kubeadm upgrade plan parancs segítségével biztonságosan megtervezhető a frissítés. (Erről is hamarosan lesz cikk.)

Összefoglalás

A Kubernetes egy összetett rendszer, de jól strukturált fő komponensei lehetővé teszik a hatékony, megbízható konténerkezelést. A vezérlősík, munkavégző csomópontok, szolgáltatások, kapszulák és egyéb elemek együttműködésével a fürt képes skálázni, hibatűrő módon működni, és automatizált módon kiszolgálni a modern alkalmazásokat.

Ha szeretnél továbblépni, érdemes gyakorlatban is kipróbálni egy mini-fürtöt akkor több lehetőség közül is választhatsz. Erről itt írtam.

Hidd el! Amint belekóstolsz ebbe a világba, nem fogod tudni abbahagyni. 🙂

2025 07 03

Konténerezz okosan: Amazon ECS az AWS világában

abc, AWS, Cloud, Docker, e abc, aws, cloud, cloudservices, docker, microservices, paas, serverless

| Olvasási idő: 4 perc |

Erőforrás típus: PaaS
Felhő szolgáltató: Amazon Web Services
Angol név: Elastic Container Service
Magyar név: Elastic Container Service
Rövidített név (ha van ilyen): ECS

Ahogy egyre több alkalmazás kerül a felhőbe, úgy válik egyre fontosabbá a konténeresítés. Az Amazon ECS (Elastic Container Service) egy felügyelt konténer-orchesztrációs szolgáltatás, amely megkönnyíti a Docker konténerek futtatását és skálázását az AWS felhőben. Ez a cikk azoknak szól, akik most ismerkednek a konténer technológiákkal, és egy egyszerű, de erőteljes megoldást keresnek az alkalmazásaik futtatására.

Mi az Amazon ECS?

Az Amazon ECS egy olyan szolgáltatás, amely lehetővé teszi konténerek indítását és kezelését anélkül, hogy külön infrastruktúrát kellene kiépíteni vagy menedzselni. Teljes mértékben integrálódik más AWS szolgáltatásokkal, mint például az IAM (jogosultságkezelés), CloudWatch (monitorozás), és az ALB (Application Load Balancer).

Az ECS kétféleképpen használható:

EC2 mód (IaaS): saját virtuális gépeken futtatott konténerekkel, ahol az infrastruktúra kezelése a felhasználó feladata.
Fargate mód (PaaS): serverless megközelítés, ahol az AWS gondoskodik a háttér-infrastruktúráról. A felhasználónak csak a konténert kell megadnia.

Az Amazon ECS előnyei

Felügyelt szolgáltatás: nem kell külön telepíteni vagy frissíteni konténer-orchesztrációs rendszereket.
Fargate támogatás: a serverless konténerfuttatás révén nincs szükség szerverek kezelésére.
Integráció AWS szolgáltatásokkal: könnyen összekapcsolható más szolgáltatásokkal (IAM, VPC, ALB, CloudWatch stb.).
Skálázhatóság: automatikus skálázás és beépített magas rendelkezésre állás.
Biztonság: IAM alapú hozzáférés-szabályozás és hálózati izoláció VPC-n belül.

Korlátai és kompromisszumok

Csak AWS-en működik: nem multicloud vagy hybrid környezetre optimalizált.
Kisebb ökoszisztéma, mint Kubernetes: kevesebb plugin és közösségi megoldás érhető el.
ECS vs EKS: ha már van Kubernetes tapasztalatod, az EKS lehet jobb választás, de bonyolultabb is.

Amazon ECS vs Azure Container Instances (ACI)

Jellemzők	Amazon ECS	Azure Container Instances
Szolgáltatás típusa	Orchesztráció (EC2 vagy Fargate)	Egyszerű konténerfuttatás
Skálázás	Automatikus, komplex	Alap skálázás
Hálózatkezelés	Teljes VPC integráció	Egyszerűbb, korlátozott
Hosszú távú futtatás	Ideális (pl. microservice-ekhez)	Rövid életű vagy egyszerű feladatokhoz
Integrációk	Szoros AWS-integráció	Alap Azure integráció
Orchestrator	ECS saját megoldása vagy Fargate	Nincs orchestrator

Mikor érdemes az Amazon ECS-t választani?

Ha AWS ökoszisztémában dolgozol, és szeretnél stabil, jól skálázható és biztonságos konténeres megoldást, akkor az ECS remek választás. Különösen akkor ajánlott, ha mikroservice architektúrával dolgozol, vagy CI/CD pipeline-t szeretnél integrálni konténeres környezetbe.

Felhasználási példa

Képzeld el, hogy egy webshop backend API-t szeretnél futtatni konténerekben. A szolgáltatásokat – például a termékkezelést, kosár funkciókat és fizetési modulokat – külön konténerekbe szervezed. Az Amazon ECS segítségével ezeket Fargate-en futtathatod úgy, hogy nem kell szervereket kezelned. Az ALB segítségével terheléselosztást is beállíthatsz, a CloudWatch pedig biztosítja a monitorozást

Egyszerű webalkalmazás futtatása Amazon ECS-ben

Ha szeretnéd kipróbálni az Amazon ECS-t, íme egy alap példa, amellyel egy publikus Docker képből (pl. Nginx) indíthatsz el egy futó szolgáltatást:

1. Lépj be az AWS Console-ba

Nyisd meg az ECS konzolt és válaszd az „ECS” szolgáltatást.

2. Kattints a „Create Cluster” gombra

Adj nevet a clusternek, pl. webalkalmazas.
Válaszd a AWS Fargate (serverless) lehetőséget
Kattints a „Create” gombra.

3. Hozz létre egy Task Definition-t

Bal oldalon menj a „Task Definitions” menüpontra.
Kattints a „Create new Task Definition” gombra.
Task definition family mezőben adj meg egy nevet, pl. web-szerver
Válaszd a „AWS Fargate” típust.
Task role: válaszd a ecsTaskExecutionRole-t (ha nincs, hozz létre az AWS útmutató alapján).
Add meg a következő konténer konfigurációt:
- Container name: nginx
- Image: nginx
- Port mappings: 80 → 80
Kattints a „Create” gombra.

4. Hozz létre egy szolgáltatást (Service)

Menj vissza a Clusterekhez, nyisd meg a webalkalmazas-t.
Válaszd a „Create” → „Service” opciót.
Launch type: Fargate
Task definition: válaszd ki az web-szerver definíciót
Service name: web-szolgaltatas
Number of tasks: 1

5. Hálózat és elérhetőség beállítása (opcionális)

VPC: válaszd ki az alapértelmezett VPC-t (vagy sajátot, ha van).
Subnet: válassz legalább egyet.
Public IP: engedélyezd (Turned on), hogy elérhető legyen internetről is.

6. Indítsd el a szolgáltatást

Kattints a „Create” gombra. Néhány perc múlva a konténer futni fog.

7. Nyisd meg a böngésződben
Menj a futó Task részleteihez, és másold ki a hozzá rendelt publikus IP címet. (Clusters > webalkalmazas > Tasks > az ott szereplő task neve > Networking > Public IP)

Nyisd meg a böngésződben – meg kell jelennie az Nginx alapértelmezett kezdőoldalának.

Ezzel egy teljesen működő konténeres webalkalmazást indítottál el, szerverek kezelése nélkül. Látod, milyen egyszerű az első lépések megtétele az Amazon ECS-sel?

Összefoglalás

Az Amazon ECS egy jól integrált, rugalmas és skálázható megoldás azok számára, akik konténerekkel szeretnének dolgozni az AWS-en. Egyszerűbb, mint a Kubernetes, de elég erős nagyvállalati környezetekhez is. Ha AWS-t használsz, és stabil konténerkezelésre van szükséged, az ECS jó választás lehet.

2025 06 30

Villámgyors konténerek Azure Container Instance-al

a, abc, Azure, c, Cloud azure, cloud, cloudservices, container, docker, instance, paas

| Olvasási idő: 4 perc |

Erőforrás típus: PaaS
Felhő szolgáltató: Microsoft Azure
Angol név: Azure Container Instance
Magyar név: Azure Container Instance
Rövidített név (ha van ilyen): ACI

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

Lépj be az Azure Portalra
A Market Place-en (Piactér), keresd meg a Container Instances szolgáltatást
Kattints a Létrehozás gombra
Töltsd ki az űrlapot:
- Erőforráscsoport: válassz vagy hozz létre egyet
- Tároló neve: pl. szialaci
- Régió: válassz egy hozzád közelit, pl. Sweden Central
- Kép forrása: Egyéb regisztrációs adatbázis
- Lemezkép típusa: Nyílvános
- Lemezkép: mcr.microsoft.com/azuredocs/aci-helloworld
- Operációs rendszer típusa: Linux
Hálózatkezelés fülön:
- Hálózatkezelési típus: Nyílvános
- Állítsd be a DNS-névcímke mezőt, pl. szia-laci
- Ellenőrizd, hogy Public IP van kiválasztva
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.

2025 04 25

Folyamatos innováció a Kubernetes világában

AWS, Azure, Cloud, GCP, Kubernetes aws, azure, cloud, docker, gcp, iaas, kubernetes, oci, paas

| Olvasási idő: 2 perc |

A Kubernetes indulása óta példátlan ütemben fejlődik és terjed. A projekt mögött álló közösség – fejlesztők, felhasználók, tesztelők és lelkes támogatók – folyamatosan növekszik, napról napra egyre többen csatlakoznak ehhez az ökoszisztémához.

A Kubernetes szoftver maga is rendkívül gyorsan fejlődik. Ez a gyors tempó olyan intenzív, hogy még a GitHub infrastruktúráját is próbára teszi, ahol a projekt kódját fejlesztik.

Mi jellemzi ezt az innovációt?

Üzleti szempontból az alapértelmezett megoldásként tekintenek rá: ma már a legtöbb modern, felhőalapú infrastruktúrát építő vállalat Kubernetesre épít.
Több tízezer közreműködő dolgozik a fejlesztésén világszerte – ezzel az egyik legaktívabb nyílt forráskódú projekt.
Százezres nagyságrendű commit (kódmódosítás) történt eddig a kódbázison.
Slack közösségében is tízezrek aktívak, folyamatosan kérdeznek, segítenek és megosztják tapasztalataikat.
Négyhavonta jelenik meg egy új, kisebb (minor) verzió a Kubernetesből.
Körülbelül tíznaponta érkezik egy javítócsomag (patch release), amely hibajavításokat vagy kisebb módosításokat tartalmaz.
Gazdag ökoszisztémával rendelkezik: több száz kapcsolódó projekt létezik, amelyek tovább bővítik és testre szabják a Kubernetes lehetőségeit – ezek közül sokat a CNCF (Cloud Native Computing Foundation) koordinál.

Miért fontos ezt tudni?

Aki korábban monolitikus, egyetlen gyártótól származó, lassan változó rendszerekkel dolgozott, annak kihívás lehet megszokni ezt a dinamikus környezetet. A Kubernetes világában ugyanis a változás állandó.

Ha valaki egy klasztert üzemeltet vagy fejleszt rá, elengedhetetlen, hogy:

tisztában legyen az új verziók jelentésével,
rendszeresen tesztelje a frissítéseket,
és naprakész maradjon az ökoszisztéma változásaival kapcsolatban.

További lehetőségek, ahol tanulhatsz és fejlődhetsz

A CNCF (Cloud Native Computing Foundation) weboldalán elérhető egy részletes lista az összes hivatalos cloud-native projektről, amelyek valamilyen formában kapcsolódnak a Kuberneteshez. Ezek között találhatók olyan eszközök, amelyek:

megkönnyítik a klaszterek menedzselését,
segítik az alkalmazások monitorozását,
vagy lehetővé teszik a biztonságos hálózati kommunikációt.

Egyre jobban körvonalazódik, hogy ez egy időtálló termék. Szerinted érdemes lenne megtanulni? 🙂

2025 04 11

Fontos alapfogalmak a Kubernetes világában

AWS, Azure, Cloud, GCP, Kubernetes aws, azure, cloud, docker, gcp, iaas, kubernetes, oci, paas

| Olvasási idő: 3 perc |

Miután megismertük a Kubernetes alapvető architektúráját, érdemes néhány kulcsfontosságú fogalommal is megismerkedni. Ezekkel az objektumokkal később is dolgozunk majd, de már most hasznos, ha megértjük, hogyan illeszkednek a teljes rendszerbe.

Mi is az a Kubernetes?

A Kubernetes egy konténer-orchesztrációs rendszer, amelyet arra terveztek, hogy automatizálja a konténerek telepítését, kezelését, skálázását és frissítését. Fontos megérteni, hogy a Kubernetes nem egyesével kezeli a konténereket, hanem úgynevezett Podokba csoportosítva.

Pod

A Pod a Kubernetes legkisebb egysége, amely egy vagy több konténert tartalmaz. Ezek a konténerek:

azonos IP-címen osztoznak,
közösen használják a tárolókat (volumes),
ugyanabba a névtérbe (namespace) tartoznak.

Általában egy Pod egy alkalmazást futtat, míg a többi konténer segédszolgáltatásokat nyújthat hozzá (például loggyűjtés, proxy, stb.).

Namespace – névterek

A namespace, vagy magyarul névtér egy logikai szeparációs eszköz a Kubernetesben. Fő célja:

az erőforrások elkülönítése (pl. fejlesztés, teszt, éles környezet),
a több bérlős környezetek (multi-tenant) biztonságos kezelése,
jogosultságok és kvóták könnyebb szabályozása.

Vannak klaszter szintű objektumok (pl. node-ok), és olyanok is, amelyek csak egy namespace-hez tartoznak. Ha különböző namespace-ekben lévő Podok szeretnének kommunikálni egymással, ahhoz Service objektumokra van szükség.

Orchestráció és vezérlők (operators)

A Kubernetes vezérlését úgynevezett „watch-loopokkal”, azaz operátorokkal végzi. Ezek figyelik a kube-apiserver állapotát, és ha eltérés van az elvárt (deklarált) és a valós állapot között, akkor lépnek közbe.

A leggyakoribb operátor típusok:

Deployment: konténerek kezelése (nem közvetlenül a Podokkal dolgozik).
ReplicaSet: a Podok darabszámát kezeli a megadott sablon (podSpec) alapján.
Kubelet: a node-on futó ügynök, amely végrehajtja a podSpec utasításait (pl. konténer letöltés, indítás, leállítás).

Az alapértelmezett és legtöbbet használt operátor a Deployment, amely biztosítja, hogy az alkalmazás mindig a kívánt példányszámban és konfigurációval fusson.

Custom Resource Definitions (CRD)

Ha a beépített vezérlők nem elegendők, akkor saját típusú erőforrásokat és operátorokat is létrehozhatunk. Ezt CRD-nek (Custom Resource Definition) nevezzük, és ezáltal bővíthetjük a Kubernetes képességeit.

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
 name: blog.cloudmentor.hu
spec:
 group: cloudmentor.hu
 versions:
 - name: v1
 served: true
 storage: true
 schema:
 openAPIV3Schema:
 type: object
 properties:
 spec:
 type: object
 properties:
 domain:
 type: string
 replicas:
 type: integer
 subresources:
 status: {}
 scope: Namespaced
 names:
 plural: websites
 singular: website
 kind: Website
 shortNames:
 - web

Szolgáltatások – Service

A Kubernetesben a Service objektum biztosítja a hálózati elérhetőséget a Podok között, különböző namespace-ek között, vagy a klaszteren kívülről.

Label alapú működés: a Service címkék alapján találja meg a hozzá tartozó Podokat.
A Service a Endpoint operátortól szerzi meg a Podok IP-címeit és elérési információit.
A Service tehát egyfajta virtuális IP-címként viselkedik, ami mögött a megfelelő Pod(ok) állnak.

Címkék (Labels) és azonosítók

A Kubernetesben nehézkes lenne több ezer Pod vagy objektum kezelése, ha mindig név vagy UID alapján kellene hivatkozni rájuk. Ezért:

használhatunk címkéket (labels) – tetszőleges kulcs-érték párok, melyek az objektum metaadataihoz tartoznak.
így például egy parancs segítségével kiválaszthatunk minden olyan Podot, amelynek az app=web címkéje van, anélkül hogy ismernénk a nevüket.

Taints és tolerations

Az egyes node-ok megjelölhetők úgynevezett taint-ekkel, hogy elkerüljék a Podok automatikus ütemezését oda. Ha egy Pod mégis ilyen node-on szeretne futni, akkor az objektum toleration beállításával jelezheti, hogy elfogadja ezt a környezetet.

Ez az alapismereteket bemutató rész egy fontos lépcsőfok ahhoz, hogy megértsük, hogyan működik a Kubernetes rendszerszinten. A későbbi gyakorlati példákban ezek a fogalmak újra és újra elő fognak kerülni.

Ugye milyen izgalmas ez a világ? És még csak most kezdtük el…

2025 04 03

Kubernetes architektúrája – az alapok megértése

AWS, Azure, Cloud, Kubernetes aws, azure, cloud, docker, gcp, iaas, kubernetes, paas

| Olvasási idő: 3 perc |

Legutóbb a mikroszolgáltatások kihívásait tárgyaltuk. Az alábbiakat kell megvalósítanunk:

folyamatos integrációs és telepítés,
konténer felügyelet,
rugalmas, skálázható és könnyen használható hálózati és tárolási megoldások.

Erre ad nekünk választ a Kubernetes.

Ahhoz, hogy valóban megértsük, hogyan működik a Kubernetes, érdemes közelebbről is megvizsgálni az architektúráját. Az alábbi ábra a Kubernetes komponenseit mutatja be magas szinten, vagyis egy áttekintő képet ad arról, hogy milyen főbb részekből áll a rendszer. Fontos megjegyezni, hogy az ábrán nem szerepel minden komponens, például a hálózati bővítményekért (network plugin) felelős elemek külön kerülnek bemutatásra.

A Kubernetes felépítése – egyszerűen

A Kubernetes alapvetően két fő részre osztható:

Control plane – ez a „központi agy”, amely irányítja a klasztert.
Worker nodes – A „munkavégzők” futtatják ténylegesen a konténereket.

A control plane egy vagy három (nagy megbízhatóság esetén három) különálló csomópontból állhat. Ezeket gyakran „cp node”-ként is említjük. A worker csomópontokból tetszőleges számú lehet – ezek a rendszer skálázhatóságának alapját adják.

Később majd bemutatjuk, hogyan lehet akár egyetlen gépen is kipróbálni az egész klasztert, ami fejlesztéshez és teszteléshez kiváló.

Mi történik a központi agyban?

A control plane legfontosabb szerepe, hogy irányítsa és koordinálja az egész klasztert. Itt található többek között:

API szerver (kube-apiserver): ez a rendszer „kapuja”, amelyen keresztül minden külső és belső komponens kommunikál. Minden parancs, amit kiadunk (pl. kubectl segítségével), az API szerverhez fut be.
Ütemező (kube-scheduler): ez a komponens dönt arról, hogy melyik worker csomóponton fusson le egy adott konténer. A döntés alapja lehet az erőforrás-kihasználtság, címkék, korlátozások stb.
Vezérlők (controller manager): ezek a háttérben futó folyamatok figyelik az állapotokat (pl. egy pod leállt), és gondoskodnak arról, hogy a klaszter mindig az elvárt állapotban legyen.
Tárolórendszer (etcd): ez egy kulcs-érték adatbázis, amely az egész klaszter állapotát tárolja – például hogy milyen podok futnak, milyen beállításokkal.

Mi történik a munkavégző csomópontokon?

Minden worker node két fő komponenst futtat:

kubelet: ez egy olyan folyamat, amely figyeli a node-hoz tartozó podokat, és gondoskodik arról, hogy azok megfelelően fussanak. A kubelet letölti a szükséges konténerképeket, előkészíti az erőforrásokat, és a helyi konténer futtatómotor (pl. containerd) segítségével elindítja a konténereket.
kube-proxy: ez felelős a hálózati szabályokért, például hogy a podok hogyan érik el egymást vagy a külvilágot. A kube-proxy a választott hálózati bővítménnyel (pl. CNI plugin) együttműködve kezeli ezeket a szabályokat.

Rugalmas kommunikáció – nem csak Linuxon

A Kubernetes legnagyobb ereje az API-alapú kommunikációs modellje, amely lehetővé teszi, hogy a klaszter különféle típusú rendszereket is kezeljen. Bár a vezérlősík kizárólag Linuxon futhat, a munkavégző csomópontokon akár Windows Server 2019, 2022 vagy 2025 is használható. Ez lehetővé teszi, hogy vegyes környezetben is használjuk a Kubernetes-t, például ha Windows-alapú alkalmazásokat is szeretnénk konténerizálni.

Ha eddig azt gondoltad, hogy csak Linux-on lehet Docker konténereket futtatni, akkor itt a példa, hogy a Windows is egy igen jó alternatíva. 🙂

2025 03 07

Azure ACR – Az első lépéseid a konténerkezelés világában

a, abc, Azure, Cloud abc, acr, azure, cloud, cloudservices, docker, kubernetes, paas

| Olvasási idő: 3 perc |

Erőforrás típus: PaaS
Felhő szolgáltató: Microsoft Azure
Angol név: Azure Container Registry
Magyar név: Tárolóregisztrációs adatbázis
Rövidített név (ha van ilyen): ACR

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.0
docker tag node-webapp:4.0.0 acrregistryneve.azurecr.io/node-webapp:latest

Push-olás (feltöltés) az ACR-be

docker push acrregistryneve.azurecr.io/node-webapp:4.0.0
docker push acrregistryneve.azurecr.io/node-webapp:latest

Megtekintés az ACR-ben

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 create --resource-group eroforrascsoport --name node-container --image acrregistryneve.azurecr.io/node-webapp:4.0.0 --registry-login-server acrregistryneve.azurecr.io --registry-username $(az acr credential show --name acrregistryneve --query "username" --output tsv) --registry-password $(az acr credential show --name acrregistryneve --query "passwords[0].value" --output tsv) --dns-name-label node-webapp-container --ports 80

A konténer állapotának ellenőrzése

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?