Miután megismertük a Kubernetes alapvető architektúráját, érdemes néhány kulcsfontosságú fogalommal is megismerkedni. Ezekkel az objektumokkal később is dolgozunk majd, de már most hasznos, ha megértjük, hogyan illeszkednek a teljes rendszerbe.
Mi is az a Kubernetes?
A Kubernetes egy konténer-orchesztrációs rendszer, amelyet arra terveztek, hogy automatizálja a konténerek telepítését, kezelését, skálázását és frissítését. Fontos megérteni, hogy a Kubernetes nem egyesével kezeli a konténereket, hanem úgynevezett Podokba csoportosítva.
Pod
A Pod a Kubernetes legkisebb egysége, amely egy vagy több konténert tartalmaz. Ezek a konténerek:
azonos IP-címen osztoznak,
közösen használják a tárolókat (volumes),
ugyanabba a névtérbe (namespace) tartoznak.
Általában egy Pod egy alkalmazást futtat, míg a többi konténer segédszolgáltatásokat nyújthat hozzá (például loggyűjtés, proxy, stb.).
Namespace – névterek
A namespace, vagy magyarul névtér egy logikai szeparációs eszköz a Kubernetesben. Fő célja:
az erőforrások elkülönítése (pl. fejlesztés, teszt, éles környezet),
a több bérlős környezetek (multi-tenant) biztonságos kezelése,
jogosultságok és kvóták könnyebb szabályozása.
Vannak klaszter szintű objektumok (pl. node-ok), és olyanok is, amelyek csak egy namespace-hez tartoznak. Ha különböző namespace-ekben lévő Podok szeretnének kommunikálni egymással, ahhoz Service objektumokra van szükség.
Orchestráció és vezérlők (operators)
A Kubernetes vezérlését úgynevezett „watch-loopokkal”, azaz operátorokkal végzi. Ezek figyelik a kube-apiserver állapotát, és ha eltérés van az elvárt (deklarált) és a valós állapot között, akkor lépnek közbe.
A leggyakoribb operátor típusok:
Deployment: konténerek kezelése (nem közvetlenül a Podokkal dolgozik).
ReplicaSet: a Podok darabszámát kezeli a megadott sablon (podSpec) alapján.
Kubelet: a node-on futó ügynök, amely végrehajtja a podSpec utasításait (pl. konténer letöltés, indítás, leállítás).
Az alapértelmezett és legtöbbet használt operátor a Deployment, amely biztosítja, hogy az alkalmazás mindig a kívánt példányszámban és konfigurációval fusson.
Custom Resource Definitions (CRD)
Ha a beépített vezérlők nem elegendők, akkor saját típusú erőforrásokat és operátorokat is létrehozhatunk. Ezt CRD-nek (Custom Resource Definition) nevezzük, és ezáltal bővíthetjük a Kubernetes képességeit.
A Kubernetesben a Service objektum biztosítja a hálózati elérhetőséget a Podok között, különböző namespace-ek között, vagy a klaszteren kívülről.
Label alapú működés: a Service címkék alapján találja meg a hozzá tartozó Podokat.
A Service a Endpoint operátortól szerzi meg a Podok IP-címeit és elérési információit.
A Service tehát egyfajta virtuális IP-címként viselkedik, ami mögött a megfelelő Pod(ok) állnak.
Címkék (Labels) és azonosítók
A Kubernetesben nehézkes lenne több ezer Pod vagy objektum kezelése, ha mindig név vagy UID alapján kellene hivatkozni rájuk. Ezért:
használhatunk címkéket (labels) – tetszőleges kulcs-érték párok, melyek az objektum metaadataihoz tartoznak.
így például egy parancs segítségével kiválaszthatunk minden olyan Podot, amelynek az app=web címkéje van, anélkül hogy ismernénk a nevüket.
Taints és tolerations
Az egyes node-ok megjelölhetők úgynevezett taint-ekkel, hogy elkerüljék a Podok automatikus ütemezését oda. Ha egy Pod mégis ilyen node-on szeretne futni, akkor az objektum toleration beállításával jelezheti, hogy elfogadja ezt a környezetet.
Ez az alapismereteket bemutató rész egy fontos lépcsőfok ahhoz, hogy megértsük, hogyan működik a Kubernetes rendszerszinten. A későbbi gyakorlati példákban ezek a fogalmak újra és újra elő fognak kerülni.
Ugye milyen izgalmas ez a világ? És még csak most kezdtük el…
Habár csak néhány napja jelentették be, nekem már volt alkalmam kipróbálni a GitHub CoPilot új Agent funkcióját a Visual Studio Code-ban, és őszintén szólva lenyűgözött, amit tapasztaltam. Korábban is használtam a CoPilotot, de az Agent mód teljesen új szintre emelte az eddig is igen jó fejlesztői élményt.
Bizonyára eddig is sokan kipróbáltátok már a CoPilot-ot, hiszen van belőle ingyenes változat is, így felelőtlenség lenne kihagyni ezt a lehetőséget. Az ingyenes változat kiváló választás azoknak, akik nem folyamatosan használják ezt az eszközt.
Az új funkció lényege, hogy már nem csak sorokat egészít ki, hanem képes folyamatos párbeszédben segíteni a munkámat. Olyan, mintha egy valódi technikai asszisztens ülne mellettem, akivel beszélgetve együtt haladunk előre. Megkérhetem például, hogy magyarázza el egy kódrészlet működését, javítson ki hibákat, vagy írjon nekem egy új funkciót egy meglévő projektbe.
A CoPilot Agent mostantól minden Visual Studio Code felhasználó számára elérhető, külön beállítás nélkül, tehát az ingyenes változatot alapból megkapjuk. A bal oldali menüből egyszerűen elindítható a CoPilot Agent felület, ahol természetes nyelven – akár magyarul is – megfogalmazhatom a kérdéseimet vagy feladataimat. Az élmény sokkal személyesebb, mint a hagyományos kódkiegészítés, mert tényleg beszélgetni tudok a rendszerrel.
Ami különösen izgalmas, hogy megjelent a multi-command plan (MCP) támogatás is, amely lehetővé teszi, hogy a CoPilot több lépéses, komplexebb feladatokat is átlásson és megoldjon. Például ha szeretnék létrehozni egy új REST API-t, akkor először kérdéseket tesz fel az igényeimről, majd ezek alapján generálja a megfelelő fájlokat, „endpoint”-okat és struktúrákat.
Kezdőként ez hatalmas segítséget jelenthet. Emlékszem, korábban én is mennyi időt töltöttem azzal a tanulás elején, hogy rájöjjek, hogyan kezdjek bele egy-egy új projektbe, hogyan építsem fel a fájlstruktúrát vagy írjak teszteket. A CoPilot Agent képes konkrét példákon keresztül megmutatni ezeket, ráadásul valós idejű visszajelzést is ad. Olyan, mintha egy türelmes mentor állna mellettem, akit bármikor kérdezhetek.
Fontos azonban megemlíteni, hogy a CoPilot – még az Agent módban is – nem tévedhetetlen. Az általa generált kódokat minden esetben felelősséggel kell kezelni. Én mindig átnézem, tesztelem, és ahol kell, javítom a javaslatait. Különösen biztonsági, adatkezelési vagy éles környezetbe szánt kódok esetén nem szabad vakon megbízni benne.
Összességében úgy érzem, a GitHub CoPilot Agent módja egy új korszak kezdete lehet a fejlesztésben és a tanulásban. Nemcsak a hatékonyságot növeli, hanem valódi tanulási lehetőséget is kínál – főleg azoknak, akik most vágnának bele a programozás világába. Ha eddig csak próbálgattad a CoPilotot, most érdemes visszatérni hozzá: az Agent mód valóban megváltoztatja, hogyan gondolkodunk a kódolásról.
Van olyan ötlet, aminek a megvalósítását eddig elnapoltad, mert nem volt aki segített volna? Ugye? Most már nincs több kifogás. 🙂
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. 🙂
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. 🙂
Minden informatikai rendszerben kiemelkedő szerepet tölt be a jogosultságkezelés, hiszen ez határozza meg, hogy a rendszer mely részéhez ki és hogyan férhet hozzá. Ezzel egyidőben a jogosultságkezelési megoldások bonyolulttá tehetik ezt a területet, amelybe sokszor belezavarodhatunk. Ez sajnos egy valós probléma a mindennapokban.
A felhőben sincs ez másképp. Minden felhőszolgáltató, kicsit másképp oldja meg ezt a feladatot, annak ellenére, hogy az alapelv emögött ugyanaz: mindenki a számára kijelölt szerepkörök szerint férjen hozzá a felhő szolgáltatásaihoz.
AWS-ben az IAM (Identity and Access Management) rendszeren keresztül tudjuk kezelni a jogosultságokat. Itt azonban nem csupán a jól ismert felhasználók, felhasználói csoportok szerepelnek, hanem szerepkörök (role) és jogosultságpolitika (policy) is. Ezek használata azonban habár jól körülhatárolható, mégis sok fejfájást okoz a kezdőknek.
AWS-ben gyakran találkozom én is azzal a kérdéssel, hogy mi az a IAM szerepkör (IAM Role), és miben különbözik a jogosultságpolitika (IAM Policy). Sokan nehezen értik meg ezt a két fogalmat, pedig az IAM (Identity and Access Management) az egyik legfontosabb biztonsági pillére a felhőalapú rendszereknek.
Ebben a cikkben ehhez szeretnénk egy kis segítséget adni, bemutatva a különbségeket, használati eseteket, és gyakorlati példákat is, hogy értsd, ne csak használd az AWS jogosultságkezelését.
Mi az IAM (Identity and Access Management)?
Az IAM lehetővé teszi, hogy meghatározd:
Ki léphet be az AWS-be
Milyen műveleteket hajthat végre
Mely erőforrásokon
Az IAM az alábbi fő elemekkel dolgozik:
Elem
Leírás
IAM User
Egy AWS felhasználó (pl. fejlesztő, tesztelő)
IAM Group
Több user közös kezelése
IAM Policy
JSON-alapú jogosultságlista
IAM Role
Ideiglenes szerepkör, amelyet user vagy szolgáltatás vehet fel
IAM Policy – Mit lehet csinálni?
Egy IAM Policy (jogosultságpolitika) egy JSON formátumú dokumentum, amely pontosan meghatározza, hogy egy adott felhasználó, csoport vagy szerepkör milyen műveleteket hajthat végre, milyen AWS-erőforrásokon, és milyen feltételek mellett.
Ez a dokumentum a következőket tartalmazza:
Effect: A művelet engedélyezése ("Allow") vagy tiltása ("Deny").
Action: Az engedélyezett vagy tiltott AWS műveletek (pl. s3:PutObject, ec2:StartInstances).
Resource: Az érintett AWS-erőforrások, például egy konkrét S3 bucket vagy EC2 instance.
Condition(opcionális): További megszorítások, pl. csak bizonyos IP-címről vagy csak többfaktoros hitelesítés esetén érvényes a policy.
Miért fontos?
Az IAM Policy határozza meg, hogy valaki mit tehet meg az AWS-ben és mit nem. Ezáltal kulcsszerepe van az AWS-fiók biztonságos és kontrollált használatában.
Előre adott, vagy nekem kell kitalálni?
Amikor a policy-k szóba kerülnek az alábbi kérdés is felvetődik:
A policy-ket nekem kell megírnom, vagy vannak előre elkészített sablonok is?
A válasz pedig: mindkettő lehetséges, az AWS kétféle policy-típust támogat:
A. Managed Policies – előre definiált, újrahasznosítható
Ezeket az AWS hozta létre, és sok tipikus szerepkört lefednek (pl. olvasás S3-ból, teljes hozzáférés DynamoDB-hez).
Ez a policy lehetővé teszi, hogy a megcélzott szereplő olvasni tudjon a egy-pelda-bucket nevű S3 tárolóból, de nem tud írni vagy törölni.
IAM Role – Ki és mikor kaphat jogosultságokat?
Egy IAM Role, vagyis szerepkör, egy olyan AWS-identitás, amely nem egy adott felhasználóhoz van kötve, hanem ideiglenesen felvehető jogosultságokat biztosít különböző szolgáltatásoknak, más felhasználóknak, vagy akár külső AWS-fiókoknak.
Miért hasznos?
Nem kell hozzá felhasználónév vagy jelszó, sem hozzáférési kulcs.
A szerepkört fel lehet venni egy adott helyzetben — például amikor egy Lambda függvény elindul, vagy amikor egy EC2 példány hozzáfér egy S3 buckethez.
A role-hoz tartozó policy-k határozzák meg, hogy az adott szerepet viselő milyen AWS-műveleteket hajthat végre.
Példák szerepkör használatra:
Szituáció
Szerepkör célja
Egy Lambda függvénynek adatot kell írnia egy DynamoDB táblába
A Lambda felveszi a „DynamoDBWriterRole”-t, amely ehhez jogot ad
Egy EC2 instance fájlokat tölt fel egy S3 bucketbe
Az EC2 példány a hozzárendelt szerepkörrel teheti ezt
Egy külső felhasználó ideiglenes admin hozzáférést kap
Az IAM Role ad neki meghatározott időre jogokat
Fontos: A Role csak addig érvényes, amíg „fel van véve” – ezáltal sokkal biztonságosabb hosszú távon, mint ha kulcsokat vagy jelszót adnál ki egy szolgáltatásnak.
Hogyan „veszi fel” egy AWS-identitás az IAM Role-t?
Attól függően, hogy ki vagy mi szeretné használni a szerepkört, a felvétel módja eltér. Alapvetően három fő helyzetvan:
A. AWS szolgáltatás (pl. EC2, Lambda) automatikusan felveszi a szerepkört
Amikor egy AWS-erőforráshoz (pl. EC2 példányhoz vagy Lambda függvényhez) hozzárendelsz egy IAM role-t, akkor az AWS rendszer automatikusan „felveszi” azt a szerepet a szolgáltatás nevében futásidőben.
Példa:
Létrehozol egy role-t, ami engedélyezi PutObject műveletet egy S3 bucketre.
Ezt a role-t hozzárendeled egy EC2 példányhoz.
Amikor a példány fut, és az alkalmazás próbál írni az S3 bucketbe, az AWS automatikusan „aláírja” a kérést a role jogosultságaival.
Tehát nem kell semmit kézzel csinálni – a role automatikusan aktiválódik.
B. Egy emberi felhasználó (IAM User vagy Federated User) kézzel veszi fel a szerepkört
Ez történik például akkor, amikor:
Belépsz az AWS Management Console-ba, és ott manuálisan „Assume Role”-t (szerepváltás, szerep felvétel) végzel.
CLI-ból vagy SDK-ból használsz sts:AssumeRole hívást egy másik szerepkör felvételére.
Amikor egy AWS-identitás (pl. ember vagy szolgáltatás) ideiglenesen magára ölt egy másik jogosultságkészletet, azt nevezzük „Assume Role”-nak, azaz szerepkör felvételének.
Ez a parancs egy másik szerepkört aktivál a felhasznalo1, majd visszaad egy ideiglenes hozzáférési kulcsot, amelyet a CLI vagy SDK automatikusan használ a következő hívásokhoz. Ez hasznos például akkor, ha egy fejlesztő csak ideiglenesen akar admin jogosultságot — a role 1 órára „felvehető”, utána lejár.
C. Egy külső AWS-fiókból vagy identitásszolgáltatóból (pl. Azure EntraID, Google Workspace) történik a role felvétel
Ez akkor történik, ha van egy cross-account access (amikor egy AWS-fiók felhasználója vagy szolgáltatása hozzáférést kap egy másik AWS-fiók erőforrásaihoz, jellemzően IAM szerepkörön keresztül.) vagy federált hitelesítés (amikor egy külső identitásszolgáltató – pl. Google, Azure EntraID, vállalati SSO – felhasználói AWS-hozzáférést kapnak anélkül, hogy külön IAM felhasználót hoznánk létre nekik.):
A külső felhasználó azonosítja magát (pl. SAML vagy OIDC segítségével).
Az AWS STS (Security Token Service) engedélyezi, hogy felvegyen egy role-t, amit előre engedélyeztél neki.
Ekkor is ideiglenes tokeneket kap, amelyeket aztán használhat.
Ez a technika például Single Sign-On (SSO) esetén működik így.
IAM Role vs Policy – A teljes kép
Elem
Leírás
Policy
Meghatározza, mit lehet csinálni (pl. olvasás, írás, törlés), hol (melyik erőforráson), milyen feltételekkel
Role
Meghatározza, ki és mikor kaphatja meg ezeket a jogosultságokat – a policy-t tartalmazza
Mikor lehet összekeverni?
Sok kezdő azon akad fenn, hogy a policy-k önmagukban nem „élnek”. Csak akkor működnek, ha:
Hozzá vannak rendelve egy user-hez, group-hoz vagy role-hoz.
A role-t valaki vagy valami ténylegesen „felveszi”.
Tippek a biztonságos használathoz
Használj role-t szolgáltatásokhoz, ne kulcsokat.
Csak annyi jogosultságot adj, amennyi szükséges – ez a „least privilege principle”.
Kerüld az Action: "*" és Resource: "*" használatát, kivéve teszteléskor.
Használj IAM policy simulator-t, hogy kipróbáld, mit engedélyez a policy.
Auditáld a role használatot a CloudTrail segítségével.
Összegzés
A szerepkör olyan, mint egy színes sapka, amit ideiglenesen felvehetsz – ez mutatja, milyen szerepben vagy. A policy pedig az a szabálykönyv, ami meghatározza, hogy az adott sapka viselője mit tehet meg.
Az IT világában egyre többen fordulnak a felhőtechnológiák felé, és sokan azzal a meggyőződéssel kezdenek neki a tanulásnak, hogy egy tanúsítvány megszerzése az első lépés a sikeres karrier felé. De vajon valóban ez a helyes út? Ebben a cikkben igyekszem objektíven, mégis a saját véleményemet megformálva megvizsgálni a tanúsítványok és a valós tapasztalatok szerepét a felhőalapú karrierépítésben.
A tanúsítványok szerepe
A tanúsítványok kétségtelenül fontosak az IT világában. Több szempontból is hasznosak lehetnek:
Strukturált tanulási útmutató: Segítenek a tanulóknak egy jól meghatározott tananyagot követni.
Álláspályázati előny: Sok munkaadónál előnyt jelent, ha valaki rendelkezik releváns tanúsítványokkal (pl. AWS Certified Solutions Architect, Azure Administrator, Google Cloud Professional Engineer, stb.).
Bizonyíték a tudásról: Egy jól megválasztott tanúsítvány igazolhatja az adott terület elméleti ismeretét.
Mindezek ellenére a tanúsítvány nem cél, hanem eszköz. Ha csak a tanúsítványra koncentrálsz, az tévútra vezethet, mert egy papír önmagában nem ad valódi tudást. A sikeres felhő karrierhez először értsd meg, próbáld ki, építs vele – a tanúsítvány pedig majd igazolja, hogy valóban értesz hozzá!
A valós tapasztalat elengedhetetlen
A valódi munkakörnyezetben egy tanúsítvány önmagában nem elegendő. Az alábbi tények ezt támasztják alá:
Az IT problémák nem feleletválasztósak: A legtöbb tanúsítvány-vizsga tesztalapú, de a való életben a hibakeresés, teljes rendszerek kiépítése és optimalizálása nem ABC-válaszokból áll.
A gyakorlati tapasztalat bizonyítja a kompetenciát: Egy interjún könnyen kiderül, ha valaki csak elméletben ismeri a technológiákat, de még sosem telepített, konfigurált vagy üzemeltetett éles rendszereket.
A komplex rendszerek nem taníthatók meg kizárólag könyvből: Egy multi-cloud vagy nagyvállalati felhőkörnyezet megértése sokkal több, mint az egyes szolgáltatások definícióinak ismerete.
A vizsgák csak a bevált gyakorlatokra koncentrálnak: A vizsgákon azt kell bizonyítanod, hogy ismered a gyártók által ajánlott legjobb gyakorlatokat. A való életben viszont ezek önmagukban nem elegendők. Ahhoz, hogy időtálló, költséghatékony és az ügyfél igényeire szabott megoldásokat építs, többre van szükség: kreativitásra, problémamegoldásra és alkalmazkodóképességre. Ha csak a vizsgák anyagára támaszkodsz, hamar olyan helyzetekbe kerülhetsz, ahol a tankönyvi válaszok nem működnek.
Mennyi idő után érdemes a tanúsítványra koncentrálni?
A tapasztalatok alapján egy minimum 6-12 hónapos gyakorlati időszak ajánlott, mielőtt valaki komolyan elkezdene készülni egy tanúsítvány megszerzésére. Ez idő alatt érdemes:
Saját projekteket építeni AWS, Azure vagy GCP környezetben.
Hibakeresési és optimalizálási feladatokat végezni, akár saját környezetben, akár valós munkakörnyezetben.
Valós infrastruktúrát menedzselni, még ha csak egy kísérleti laborban is.
Ez a tapasztalat segít abban, hogy a tanúsítvány megszerzése ne csak egy elméleti tudást igazoljon, hanem valódi kompetenciát is tükrözzön.
A vizsgára külön készülni kell
A tanúsítvány megszerzése nem csupán technikai tudást igényel. A vizsgák speciális nyelvezettel rendelkeznek, amelynek értelmezése önmagában kihívás lehet.
Magabiztos angol nyelvtudás szükséges: A vizsgákon sokszor összetett mondatokkal és egyedi kifejezésekkel találkozunk. A kérdések gyakran nem egyértelműek, és ha valaki nem érti pontosan a megfogalmazást, könnyen hibás választ adhat.
A vizsganyelvezet külön tanulást igényel: A kérdések sokszor rejtett célzásokat tartalmaznak, ezért nem elég csupán a szolgáltatások működését ismerni – „olvasni kell a sorok között”.
Érdemes vizsgafelkészítő tananyagokat és próbateszteket (brain dump) használni, hogy megértsük a gyakran alkalmazott megfogalmazásokat és logikát.
A helyes megközelítés
Ha valaki valóban sikeres akar lenni a felhőtechnológiák világában, az alábbi stratégiát érdemes követnie:
Gyakorolj és építs saját projekteket: Használj AWS ingyenes szolgáltatásokat, Azure Bicep-et vagy GCP Sandboxot saját rendszerek kialakítására. A felhőtechnológiák elsajátítása hosszú távú befektetést igényel. Az ingyenes lehetőségek jó kiindulópontot jelentenek, de a valódi tudás megszerzéséhez előbb-utóbb érdemes anyagi ráfordítást is tervezni. Nem kell hatalmas összegeket költeni, de a hatékony fejlődés érdekében érdemes havi néhány tízezer forintot szánni fizetős felhőszolgáltatásokra és laborkörnyezetekre. Ezek a befektetések jelentősen felgyorsítják a tanulási folyamatot és valós tapasztalatokat nyújtanak.
Vegyél részt open-source projektekben: GitHub-on rengeteg olyan projekt található, amelyben a felhőalapú technológiák alkalmazása révén valós tapasztalatot szerezhetsz.
Keress online képzéseket: A Gerilla Mentor Klubnál sok-sok képzés (soft- és hard skill) közül választhatsz. Vagy ott van az Udemy, ahol sokszor, csupán néhány forintért juthatsz a legjobb anyagokhoz.
Használj interaktív laborkörnyezeteket: KodeKloud és hasonló platformok kínálnak éles környezetben végrehajtható gyakorlati feladatokat.
Tanúsítványt akkor szerezz, ha már van mögötte tudás – Így a vizsga valódi visszaigazolása lesz annak, amit már tudsz, és nem egy gyorsan megszerzett papír.
Következtetés
A tanúsítványok értékesek, de csak akkor, ha mögöttük valódi tapasztalat áll. Ha valaki kizárólag a tanúsítványokra koncentrál, az tévútra vezethet, mert a munkaerőpiacon az éles helyzetek kezelése és a valódi problémamegoldó képesség a legfontosabb.
Először értsd meg, próbáld ki, játsz vele – a tanúsítvány pedig majd igazolja, hogy valóban értesz hozzá!
Amikor valaki a Docker-ről olvas, vagy tanul, szinte meseszerű annak története és már használatba is vennék, hiszem megváltoztatja a világot. Akkor mire is várunk? Mint minden területen, itt sem felhőmentes az égbolt. A Docker-es, konténeres világ is küzd bizonyos kihívásokkal.
A konténerek kiváló módot kínálnak az alkalmazások csomagolására, szállítására és futtatására
– ez a Docker mottója.
A fejlesztői élmény jelentősen javult a konténereknek köszönhetően. A konténerek lehetővé tették a fejlesztők számára, hogy könnyedén hozzanak létre konténerképeket (docker image), egyszerűen megosszák azokat tároló rendszereken keresztül (DockerHub, ACR, ECR), és hatékony felhasználói élményt biztosítsanak a konténerek kezeléséhez.
Azonban a konténerek nagy léptékű kezelése és egy biztonságos, elosztott alkalmazás tervezése a mikroservices alapelvei szerint komoly kihívást jelenthet.
Hatékony lépés egy folyamatos integrációs és telepítési (CI/CD) folyamat kialakítása a konténerképek építéséhez, teszteléséhez és ellenőrzéséhez. Olyan eszközök, mint a Spinnaker, a Jenkins és a Helm hasznosak lehetnek ezen automatizmusok kialakításában és megvalósításában. Ez segít megbirkózni a folyamatosan változó környezet kihívásaival, és biztosítja, hogy a konténerek megfeleljenek a minimális követelményeknek.
Ezután szükséged lesz egy fürtre (cluster), amelyen futtathatod a konténereidet. Egy olyan rendszerre is szükség van, amely elindítja a konténereket, figyeli őket, és hiba esetén lecseréli vagy helyettesíti azokat. A gördülékeny frissítések és az egyszerű visszaállítások is kiemelten fontosak, valamint a nem használt erőforrások eltávolítása is elengedhetetlen.
Mindezek a műveletek rugalmas, skálázható és könnyen használható hálózati és tárolási megoldásokat igényelnek. Mivel a konténerek bármely munkavégző szerver tagon (worker node) elindulhatnak, a hálózatnak biztosítania kell az erőforrások összekapcsolását más konténerekkel, miközben a forgalmat biztonságosan el kell különíteni másoktól. Emellett olyan tárolási struktúrára van szükség, amely zökkenőmentesen biztosítja, újrahasznosítja vagy felszabadítja a tárhelyet.
Amikor Kubernetes választ ad ezekre a kérdésekre, az egyik legnagyobb kihívás mégis maguk az alkalmazások, amelyek a konténerekben futnak. Ezeket meg kell írni vagy újra kell írni úgy, hogy valóban megbízható és rugalmasan kapcsolódó mikroservice-ek legyenek. Egy jó kérdés, amin érdemes elgondolkodni:
Ha telepítenéd a Chaos Monkey-t, amely bármikor véletlenszerűen leállíthat bármelyik konténert, vajon az ügyfeleid észrevennék?
A konténerek forradalmasították az alkalmazásfejlesztést és -üzemeltetést, de a skálázhatóság, biztonság és automatizáció kihívásai miatt önmagukban nem elegendőek. A Kubernetes olyan eszközt biztosít, amely segít ezeket a problémákat kezelni, ám a sikeres bevezetéshez nemcsak az infrastruktúrát kell megfelelően kialakítani, hanem az alkalmazásokat is a konténerizált, elosztott rendszerek sajátosságaihoz kell igazítani.
A megfelelő CI/CD folyamatok, az erőforráskezelés és a skálázható architektúra kialakítása kulcsfontosságú a konténeres környezetek hatékony működtetéséhez. Végső soron a cél egy olyan rendszer kialakítása, amely nemcsak rugalmas és automatizált, hanem ellenálló is a meghibásodásokkal szemben – annyira, hogy akár egy Chaos Monkey sem tudná megingatni.
A Kubernetes lehetőséget biztosít arra, hogy a konténerizált alkalmazások kezelése egyszerűbbé és hatékonyabbá váljon, de a siker kulcsa a jól megtervezett architektúra és a folyamatos optimalizáció.
A következő lépés annak feltérképezése, hogy saját alkalmazásaink mennyire felelnek meg ezeknek az elveknek – és ha szükséges, hogyan alakíthatók át a jövőbiztos működés érdekében.
Sorozatunk előző részében megismerhettük a Kubernetes történetét, eredetét és hogy ki is fejleszti. Most megyünk tovább és rátérünk arra, hogyan is változtatta meg a világot a Kubernetes és a Docker.
A Kubernetes használata és a konténeres alkalmazások üzembe helyezése alapjaiban változtatja meg a fejlesztési és rendszergazdai megközelítést az alkalmazások telepítésében. Hagyományosan egy alkalmazás – például egy webszerver – monolitikus formában, egy dedikált szerveren futott. A növekvő webes forgalom hatására ezt az alkalmazást finomhangolták, majd egyre nagyobb teljesítményű hardverre költöztették. Idővel jelentős testreszabásokra volt szükség annak érdekében, hogy megfeleljen az aktuális terhelési igényeknek. Ez általában sok nehézséggel és magas költséggel társult. Ráadásul a tervezési feladatok (költség, kapacitás és üzemeltetés) sok emberi erőforrást emésztett fel.
A Kubernetes ehelyett egy teljesen más megközelítést kínál: egyetlen nagy teljesítményű szerver helyett számos kisebb szervert, azaz mikroservice-eket üzemeltet. Az alkalmazás szerver- és kliensoldali komponensei eleve úgy vannak kialakítva, hogy több ügynök (agent) legyen elérhető a kérések kiszolgálására. Ez a megoldás lehetővé teszi a dinamikus skálázást és a rugalmasságot. A klienseknek számítaniuk kell arra is, hogy a szerverfolyamatok időnként leállhatnak és újak veszik át a helyüket, ami a tranziensekre épülő szerverüzemeltetés alapja. Egy klasszikus Apache webszerver helyett például sok kisebb nginx szerver működik párhuzamosan, amelyek egyenként válaszolnak a bejövő kérésekre.
A Kubernetes előnyei: rugalmasság és automatizáció
A kisebb, átmeneti szolgáltatások használata lehetővé teszi a lazább komponenskötéseket (decoupling). A monolitikus alkalmazás egyes részeit dedikált, de tranziensebb mikroservice-ek vagy ügynökök váltják fel. Az egyes ügynökök és azok helyettesítői közötti kapcsolatot szolgáltatásokkal (services) biztosítjuk. Egy szolgáltatás összeköti a forgalmat az egyik komponensről a másikra (például egy frontend webszerverről egy backend adatbázisra), és kezeli az új IP-címeket vagy egyéb információkat, ha valamelyik komponens meghibásodik és újat kell beállítani helyette.
A kommunikáció teljes mértékben API-hívásokon alapul, ami nagy rugalmasságot biztosít. A Kubernetes a konfigurációs adatokat JSON formátumban tárolja az etcd adatbázisban, de a közösség általában YAML formátumban írja ezeket. A Kubernetes agent-ei a YAML fájlokat JSON formátumba alakítják át, mielőtt az adatbázisba mentenék őket. Ez lehetővé teszi az egyszerű konfigurálást és a gyors módosításokat.
Egy modern megoldás a skálázhatóságra
A Kubernetes alapját a Go programozási nyelv adja, amely egy hordozható és hatékony nyelv, egyfajta hibrid a C++, Python és Java között. Egyesek szerint ezeknek a nyelveknek a legjobb (mások szerint a legrosszabb) elemeit ötvözi. A Kubernetes használatával az alkalmazásüzemeltetés kevésbé függ a hardvertől, és inkább az automatizált skálázásra és a magas rendelkezésre állásra épít.
A Kubernetes nem csupán egy új technológia – egy új szemléletmód is, amely lehetővé teszi az alkalmazások hatékonyabb és rugalmasabb működését. A dinamikus skálázás, az automatizált erőforráskezelés és a mikroservice-alapú architektúra révén a modern alkalmazásüzemeltetés alapvető eszközévé vált.
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?