Cloud

cloud-formation-1

CloudFormation: Infrastruktúra kódként az AWS-ben

, , , , , , , , , , , , ,

  • Erőforrás típus: IaaS
  • Felhő szolgáltató: Amazon Web Services
  • Angol név: CloudFormation
  • Magyar név: CloudFormation
  • Rövidített név (ha van ilyen): –

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:

AWSTemplateFormatVersion: '2010-09-09'
Description: Egyszerű S3 bucket létrehozása

Resources:
 MySimpleBucket:
 Type: AWS::S3::Bucket
 Properties:
 BucketName: egy-cloudformation-s3-bucket

Mit csinál ez?

  • Létrehoz egy S3 tárolót egy-cloudformation-s3-bucket névvel.
  • A stack elindítása után a CloudFormation automatikusan elvégzi a létrehozást.

Használat lépései az AWS Console-ban:

  1. Menj a CloudFormation szolgáltatásra.
  2. Válaszd a „Create Stack” opciót.
  3. Töltsd fel a sablon YAML fájlt.
  4. Add meg a stack nevét, majd kattints a „Next” gombokra.
  5. Pár perc múlva kész is az erőforrásod!

Komplex példa: EC2 példány biztonságos környezetben

Ebben a példában egy EC2 példányt hozunk létre saját VPC-ben, nyilvános IP nélkül, biztonsági csoporttal:

AWSTemplateFormatVersion: '2010-09-09'
Description: EC2 példány saját VPC-ben

Resources:
 SajatVPC:
 Type: AWS::EC2::VPC
 Properties:
 CidrBlock: 10.0.0.0/16
 Tags:
 - Key: Name
 Value: VCP01

 SajatSubnet:
 Type: AWS::EC2::Subnet
 Properties:
 VpcId: !Ref SajatVPC
 CidrBlock: 10.0.1.0/24
 AvailabilityZone: !Select [0, !GetAZs '']

 BiztonsagiCsoport:
 Type: AWS::EC2::SecurityGroup
 Properties:
 GroupDescription: Csak SSH
 VpcId: !Ref SajatVPC
 SecurityGroupIngress:
 - IpProtocol: tcp
 FromPort: 22
 ToPort: 22
 CidrIp: 0.0.0.0/0

 LinuxVM:
 Type: AWS::EC2::Instance
 Properties:
 InstanceType: t3.micro
 ImageId: ami-0c2e61fdcb5495691 # AMI ID eu-north-1 régióban
 SubnetId: !Ref SajatSubnet
 SecurityGroupIds:
 - !Ref BiztonsagiCsoport
 Tags:
 - Key: Name
 Value: CloudFormationEC2

Mi történik itt?

  • Létrejön egy új VPC, alhálózat (subnet), biztonsági csoport (SG) és EC2 példány.
  • A példány csak SSH-n keresztül érhető el.
  • Ez egy jól strukturált, reprodukálható környezet, amit bármikor újra létrehozhatunk.

CloudFormation sablon részei: Az alapok

Egy CloudFormation sablon tipikusan a következő szekciókból állhat:

  • Parameters – A sablon újrahasználhatóságát biztosítják. Ezek segítségével a sablon külső értékeket fogadhat.
  • Resources – A kötelező szekció, ahol magukat az AWS erőforrásokat definiáljuk.
  • Outputs – Ezekkel az információkkal a stack létrehozása után dolgozhatunk tovább (pl. EC2 publikus IP címe).
  • Conditions – Opcionálisan szabályozhatjuk, hogy egyes erőforrások létrejöjjenek-e vagy sem.
  • Mappings – Előre definiált értéktáblák (pl. régiókhoz tartozó AMI ID-k).
  • Metadata – Opcionális dokumentáció, megjegyzések.
  • Transform – Haladó funkció, például a Serverless Application Model (SAM) használatához.

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. 🙂

aws-iam-role-policy-1

IAM szerepkörök és jogosultságok az AWS-ben

, , , , , , , ,

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:

ElemLeírás
IAM UserEgy AWS felhasználó (pl. fejlesztő, tesztelő)
IAM GroupTöbb user közös kezelése
IAM PolicyJSON-alapú jogosultságlista
IAM RoleIdeiglenes 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).
  • Például: AmazonS3ReadOnlyAccess, AmazonEC2FullAccess, AWSLambdaExecute
  • Ezeket készen hozzá tudod rendelni felhasználókhoz vagy szerepkörökhöz.
  • Előnyük, hogy gyorsan használhatók, és AWS által karbantartottak, de kevésbé testreszabhatók.

B. Customer Managed Policies – saját szabályzatok, egyedi igényekre

  • Ezeket te magad írod meg, ha pontosan szabályozni akarod, hogy mi történhet.
  • Teljes rugalmasságot adnak, de több figyelmet és tesztelést igényelnek.

Mikor melyiket használd?

HelyzetPolicy típus
Általános, jól definiált feladat (pl. csak olvasás S3-ból)Managed policy
Egyedi igény, szigorúan csak adott bucket, tábla, stb.Customer managed policy
Több szabály kombinációja, például időkorlátos hozzáférés + feltételCustomer managed policy

Példa – Csak olvasási jogosultság egy S3 bucketre

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": ["s3:GetObject"],
 "Resource": ["arn:aws:s3:::egy-pelda-bucket/*"]
 }
 ]
}

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ábaA Lambda felveszi a „DynamoDBWriterRole”-t, amely ehhez jogot ad
Egy EC2 instance fájlokat tölt fel egy S3 bucketbeAz EC2 példány a hozzárendelt szerepkörrel teheti ezt
Egy külső felhasználó ideiglenes admin hozzáférést kapAz 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.

Példa CLI-ból:

aws sts assume-role \
 --role-arn arn:aws:iam::123456789012:role/AdminAccessRole \
 --role-session-name admin-session \
 --profile felhasznalo1

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

ElemLeírás
PolicyMeghatározza, mit lehet csinálni (pl. olvasás, írás, törlés), hol (melyik erőforráson), milyen feltételekkel
RoleMeghatá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

  1. Használj role-t szolgáltatásokhoz, ne kulcsokat.
  2. Csak annyi jogosultságot adj, amennyi szükséges – ez a „least privilege principle”.
  3. Kerüld az Action: "*" és Resource: "*" használatát, kivéve teszteléskor.
  4. Használj IAM policy simulator-t, hogy kipróbáld, mit engedélyez a policy.
  5. 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.

tanusotvany-tapasztalat-2

Tanúsítvány vagy tapasztalat? A felhő karrier dilemmája

, , , , , , , , , ,

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:

  1. 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.
  2. 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.
  3. 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.
  4. Használj interaktív laborkörnyezeteket: KodeKloud és hasonló platformok kínálnak éles környezetben végrehajtható gyakorlati feladatokat.
  5. 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á!

docker-challanges-2

A mikroszolgáltatás kihívásai és a Kubernetes, mint megoldás

, , , , , , , , , , , , , ,

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.

k8s3-1

Hogyan alakítja át az alkalmazásüzemeltetést a Kubernetes?

, , , , , , , , , , , , ,

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.

Innen folytatjuk a következő cikkben. 🙂

acr00003

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

, , , , , , , , , ,

  • 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?

bicep1

Egyszerűbb infrastruktúra-kezelés Azure-ban: Azure Bicep

, , , , , , , ,

  • Erőforrás típus: IaaS
  • Felhő szolgáltató: Microsoft Azure
  • Angol név: Bicep
  • Magyar név: Bicep
  • Rövidített név (ha van ilyen): –

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:

resource elsoTarfiok 'Microsoft.Storage/storageAccounts@2021-09-01' = {
 name: 'egyeditarfiokneve'
 location: 'swedencentral'
 sku: {
 name: 'Standard_LRS'
 }
 kind: 'StorageV2'
}

Ebben a fájlban:

  • resource kulcsszóval definiáljuk az erőforrást,
  • a típus az @2021-09-01 verzióval együtt jelenik meg,
  • a tulajdonságokat egyszerűen megadhatjuk, elkerülve a bonyolult JSON szintaxist.

Komplexebb példa: Virtuális hálózat és alhálózat létrehozása

Az alábbi Bicep fájl (network.bicep) egy virtuális hálózatot és egy alhálózatot hoz létre az Azure-ban:

resource virtualisHalozat 'Microsoft.Network/virtualNetworks@2021-02-01' = {
 name: 'elsoVirtualisHalozat'
 location: 'swedencentral'
 properties: {
 addressSpace: {
 addressPrefixes: ['10.0.0.0/16']
 }
 }
}

resource elsoAlhalozat 'Microsoft.Network/virtualNetworks/subnets@2021-02-01' = {
 name: 'elsoAlhalaozat'
 parent: virtualisHalozat
 properties: {
 addressPrefix: '10.0.1.0/24'
 }
}

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:

New-AzResourceGroupDeployment -ResourceGroupName EroforrasCsoport1 -TemplateFile .\storage.bicep

Bicep fájlok futtatása Azure CLI-ből

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?

deepseek2

Új szintre emelt AI-fejlesztés: DeepSeek R1 az Azure-ban

, , , , , , , ,

Mi az a DeepSeek? Egy új OpenAI modell? Nem! A DeepSeek egy hirtelen berobbant projekt, amely egyre nagyobb figyelmet kap az AI világában. A csapat célja, hogy nyílt forráskódú, nagy teljesítményű és költséghatékony AI-modelleket hozzanak létre, amelyeket a fejlesztők könnyen beépíthetnek saját rendszereikbe. Az egyik legújabb modelljük, a DeepSeek R1, mostantól elérhető az Azure AI Foundry-n, így egyszerűen kipróbálhatod és integrálhatod a saját alkalmazásaidba.

DeepSeek és Azure

A DeepSeek egy AI-kutatásra és fejlesztésre specializálódott csapat, amely nagyméretű nyelvi modelleket (LLM) és más AI-megoldásokat készít. Céljuk, hogy magas teljesítményű, nyílt forráskódú és költséghatékony AI-modelleket biztosítsanak a fejlesztők és vállalatok számára.

A DeepSeek R1 az egyik legújabb nyelvi modelljük, amely hatékony és könnyen használható, így lehetőséget ad a fejlesztőknek, hogy fejlett AI-funkciókat építsenek be alkalmazásaikba anélkül, hogy komoly infrastruktúrába kellene fektetniük.

Mostantól a DeepSeek R1 elérhető az Azure AI Foundry modellkatalógusában és a GitHub-on, így egyszerűen integrálható különböző AI-megoldásokba.

Ráadásul már magyar nyelven is elérhető hozzá a felület, ami még egyszerűbbé teszi a megismerést és a használatot.

Gyorsabb AI-fejlesztés az Azure AI Foundry-n

Az AI-technológia folyamatosan fejlődik, és egyre könnyebben elérhetővé válik. A DeepSeek R1 egy nagy teljesítményű és költséghatékony nyelvi modell, amely lehetővé teszi, hogy a felhasználók minimális infrastruktúrával kihasználják a mesterséges intelligencia előnyeit.

Ha az Azure AI Foundry platformon használod a DeepSeek R1-et, akkor gyorsan kísérletezhetsz, tesztelheted az eredményeket és skálázhatod az alkalmazásodat. A beépített eszközök segítenek az AI-modell teljesítményének mérésében és optimalizálásában.

A Microsoft célja, hogy az Azure AI Foundry egy olyan hely legyen, ahol a legjobb AI-modellek egy helyen elérhetőek, így a fejlesztők és vállalatok gyorsabban és hatékonyabban hozhatnak létre AI-alapú megoldásokat.

Biztonságos és megbízható AI

A DeepSeek R1 komoly biztonsági teszteken és ellenőrzéseken esett át, hogy minimalizálják a kockázatokat. Az Azure AI Content Safety automatikus tartalomszűrési rendszerrel is rendelkezik, amely alapértelmezetten be van kapcsolva, de igény szerint kikapcsolható.

Az Azure AI Foundry folyamatosan monitorozza az AI-modell kimeneteit, így a telepítés előtt és után is ellenőrizheted, hogy megfelelően működik-e. Ezzel biztosítjuk, hogy a platform biztonságos és megfelelőségi szempontból is vállalati szintű környezetet biztosítson.

Hogyan próbálhatod ki a DeepSeek R1-et?

  1. Jelentkezz be az Azure Portálra, regisztrálj egy Azure AI Foundry projektet.
  2. Keress rá a DeepSeek R1-re az Azure AI Foundry modellkatalógusában.
  3. Nyisd meg a modell adatlapját.
  4. Kattints a „Deploy” gombra, hogy megkapd az API-t és a hozzáférési kulcsot.
  5. A telepítési oldalon pillanatok alatt megkapod a szükséges adatokat.
  6. Próbáld ki a modellt a beépített playgroundban.
  7. Használd az API-t különböző alkalmazásokkal és kliensekkel.

Ha nincs még Azure-fiókod, itt regisztrálhatsz: Azure regisztráció.

Kezdj bele most!

A DeepSeek R1 mostantól kiszolgáló nélküli, nyilvános végponton is elérhető az Azure AI Foundry-n. Kezdd el itt: Azure AI Foundry, és próbáld ki a DeepSeek modellt!

A GitHubon további forrásokat és részletes útmutatókat találhatsz a DeepSeek R1 integrációjáról, többek között az alábbi cikkben: GitHub Models.

Hamarosan a DeepSeek R1 könnyített verzióját is futtathatod helyben, a Copilot+ segítségével. További részletek a Windows Fejlesztői Blogon: Windows Developer Blog.

A Microsoft egyre nagyobb hangsúlyt fordít erre a területre és folyamatosan bővíti az Azure AI Foundry modellkatalógusát. Bevallom én is kíváncsian várom, hová fejlődik ez és, hogy a fejlesztők és vállalatok hogyan használják a DeepSeek R1-et valódi problémák megoldására. Az látszik, hogy a cél, hogy minden vállalkozás hozzáférjen a legmodernebb AI-megoldásokhoz, és a lehető legtöbbet hozza ki belőlük. Ezzel pedig egyértelműen az Azure felé terelik a felhasználókat.

Te használod már valamelyik AI megoldást vagy magát az Azure-t? 🙂

arm1

Azure ARM sablon: Automatizált és skálázható infrastruktúra

, , , , , , , , , , ,

  • Erőforrás típus: IaaS, PaaS
  • Felhő szolgáltató: Microsoft Azure
  • Angol név: ARM template
  • Magyar név: ARM sablon
  • Rövidített név (ha van ilyen): ARM

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:

{
 "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
 "contentVersion": "1.0.0.0",
 "parameters": {
 "tarfiokNeve": {
 "type": "string"
 }
 },
 "resources": [
 {
 "type": "Microsoft.Storage/storageAccounts",
 "apiVersion": "2022-09-01",
 "name": "[parameters('tarfiokNeve')]",
 "location": "[resourceGroup().location]",
 "kind": "StorageV2",
 "sku": {
 "name": "Standard_LRS"
 }
 }
 ]
}

Miért érdemes ARM sablont használni?

1. Deklaratív és idempotens

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.

Például:

"name": "[concat('storacc', uniqueString(resourceGroup().id))]"

Ez egy egyedi Tárfiók (Storage Account) nevet generál az erőforráscsoport azonosítója alapján.

ARM sablonok újrafelhasználása kisebb módosításokkal

A sablonok újrafelhasználhatók különböző környezetekben (pl. dev, test, prod), ha megfelelő paraméterezést alkalmazunk. Például:

"parameters": {
 "environment": {
 "type": "string",
 "allowedValues": ["dev", "test", "prod"]
 }
}

Majd a sablonban ezt a paramétert használhatjuk egy erőforrás elnevezésére:

"name": "[concat('storage', parameters('environment'))]"

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:

{
 "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
 "contentVersion": "1.0.0.0",
 "parameters": {
 "tarfiokNeve": {
 "type": "string"
 }
 },
 "resources": [
 {
 "type": "Microsoft.Resources/deployments",
 "apiVersion": "2021-04-01",
 "name": "nestedDeployment",
 "properties": {
 "mode": "Incremental",
 "parameters": {
 "tarfiokNeve": {
 "value": "[parameters('tarfiokNeve')]"
 }
 },
 "template": {
 "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
 "contentVersion": "1.0.0.0",
 "parameters": {
 "tarfiokNeve": {
 "type": "string"
 }
 },
 "resources": [
 {
 "type": "Microsoft.Storage/storageAccounts",
 "apiVersion": "2021-09-01",
 "name": "[parameters('tarfiokNeve')]",
 "location": "[resourceGroup().location]",
 "sku": {
 "name": "Standard_LRS"
 }
 }
 ]
 }
 }
 }
 ]
}

Hivatkozott sablonok (Linked Templates)

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.

Példa egy hivatkozott sablon használatára:

{
 "type": "Microsoft.Resources/deployments",
 "apiVersion": "2021-04-01",
 "name": "linkedDeployment",
 "properties": {
 "mode": "Incremental",
 "templateLink": {
 "uri": "https://cloudmentorsa.blob.core.windows.net/templates/nestedTemplate.json",
 "contentVersion": "1.0.0.0"
 }
 }
}

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:

New-AzResourceGroupDeployment -ResourceGroupName EroforrasCsoport -TemplateFile .\template.json -TemplateParameterFile .\parameters.json

Ha inline paramétereket szeretnénk megadni:

New-AzResourceGroupDeployment -ResourceGroupName EroforrasCsoport -TemplateFile .\template.json -tarfiokNeve cloudmentorsa

Azure CLI használata

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:

{
 "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
 "contentVersion": "1.0.0.0",
 "parameters": {
 "tarfiokNeve": {
 "value": "cloudmentorsa"
 }
 }
}

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

  1. Bonyolult szintaxis: Az ARM sablonok JSON-alapúak, ami nagyobb komplexitás esetén nehezen olvashatóvá válhat.
  2. 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.
  3. Korlátozott hibakeresési lehetőség: A hibák az Azure Portalon vagy CLI-n keresztül nehezen diagnosztizálhatók.
  4. Hosszabb telepítési idő: Összetettebb sablonok esetén a telepítés több percig is eltarthat.
  5. 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? 🙂

oci2

A konténerképek: Docker és OCI rétegek és verziókezelés

, , , , , , , , , ,

Korábban már beszéltünk a Kubernetes-ről, Docker-ről és a különböző konténerkép kezelési megoldásokról, mint az AWS ECR és Azur ACR. Azonban arról még nem esett szó: Mi az a képfájl? Hogyan épül fel? Milyen, számunkra fontos típusokról kell beszélnünk?

A konténerizáció egyik legfontosabb eleme a konténerképek használata, amelyek a futtatható környezeteket biztosítják. A Docker és az OCI (Open Container Initiative) képek szerkezete hasonló, mivel az OCI a Docker formátumának egy nyílt ipari szabványa lett. Az OCI létrejötte azért fontos, mert egy iparági szabványt biztosít a konténerképek kezelésére, elősegítve az interoperabilitást és a hordozhatóságot különböző konténer futtatókörnyezetek között. Ezzel kiküszöböli a vendor lock-in problémát, amely egyetlen technológiai ökoszisztémához kötné a fejlesztőket és üzemeltetőket.

Most szeretném nektek bemutatni a képek szerkezetét, a rétegek kezelését, a manifest-ek szerepét és a verziókezelés módját.

Docker és OCI képek alapjai

A Docker és az OCI képek egy rétegelt fájlrendszert használnak, amely lehetővé teszi a hatékony tárolást és a gyors betöltést. Egy konténerkép három fő részből áll:

  • Rétegek (Layers): A képfájl tartalma rétegekre van bontva, amelyek egymásra épülnek.
  • Manifest fájl: Egy JSON-alapú leírófájl, amely meghatározza a kép struktúráját és annak különböző attribútumait.
  • Config (Konfigurációs fájl): A futási beállításokat tartalmazza, mint például a környezeti változók és az alapértelmezett parancsok.

Rétegek kezelése

A konténerképek rétegei a Copy-on-Write (CoW) elv alapján működnek. Ez azt jelenti, hogy egy újabb réteg csak a módosított fájlokat tárolja, miközben az előző rétegek változatlanok maradnak. A rétegek kezelésének főbb szempontjai:

  • Rétegek építése: Minden egyes RUN, COPY és ADD utasítás egy új réteget hoz létre a Dockerfile feldolgozása során. (Példa)
  • Rétegek optimalizálása: Érdemes minél kevesebb réteget létrehozni, és a gyakran módosuló fájlokat a végső rétegbe helyezni, hogy a cache hatékony maradjon.
  • Rétegek megosztása: Ha több kép ugyanazokat az alaprétegeket használja, a konténer futtatókörnyezet (pl. Docker) csak a különböző rétegeket tölti le, így csökkenti a letöltési és tárolási igényt.

A Manifest szerepe

A manifest fájl egy JSON struktúra, amely meghatározza a kép rétegeit és meta adatait. Egy tipikus manifest a következő információkat tartalmazza:

  • SchemaVersion: A manifest formátum verziója.
  • Layers: A képet felépítő rétegek listája (digest formátumban).
  • Config: A konfigurációs fájl hash-e, amely tartalmazza a környezeti változókat és az indítási parancsokat.
  • MediaType: A fájlformátum meghatározása (Docker vagy OCI specifikus).

Az OCI és Docker image manifest formátumok nagyon hasonlóak, de az OCI teljesen nyílt és szabványosított formátumot biztosít.

Képverziók és a rétegek kezelése

A konténerképek verziókezelése többnyire címkék (tags) és digest-ek segítségével történik:

  • Tag (Címke): Egy könnyen olvasható név, például ubuntu:24.04 vagy webalkalmazas:1.2.0. A címkék bármikor új képverzióhoz rendelhetők.
  • Digest (SHA256 azonosító): Egy egyedi azonosító (pl. sha256:abcd1234...), amely garantálja, hogy a megadott kép mindig ugyanaz marad.
  • Rétegek újrahasznosítása: Ha egy új verzióban csak néhány fájl változik, akkor a rétegek nagy része változatlan marad, és a Docker vagy OCI runtime csak az új rétegeket tölti le. Ezzel tárhelyet és internet sávszélességet is spórol.

A konténerképek rétegei az alábbiak szerint épülnek fel:

  1. Base Image (Alapkép): Az operációs rendszer és a minimális futtatókörnyezet.
  2. Layer 1 (Alapcsomagok és függőségek): A szükséges könyvtárak és függőségek telepítése.
  3. Layer 2 (Alkalmazáskód hozzáadása): Az egyedi alkalmazás fájljainak bemásolása.
  4. Layer 3 (Konfiguráció és optimalizáció): A futtatási beállítások és optimalizációk alkalmazása.
  5. Final Image (Végleges kép): Az összes réteg egyesítésével elkészült futtatható konténerkép.

Mi a különbség a Docker és az OCI között?

Bár az OCI a Docker formátumából fejlődött ki, a kettő között van néhány alapvető különbség:

  • Nyílt szabvány: Az OCI egy iparági konszenzusra épülő nyílt szabvány, míg a Docker formátumát eredetileg a Docker Inc. hozta létre.
  • Kompatibilitás: Az OCI szabvány célja a konténerképek hordozhatóságának biztosítása bármely futtatókörnyezet között, míg a Docker esetén elsősorban a Docker Engine-re optimalizált képekkel dolgozunk.
  • Modularitás: Az OCI szabvány különválasztja a runtime és az image specifikációkat, így rugalmasabb, és más futtatókörnyezetek is könnyen alkalmazhatják.

Összegzés

A Docker és OCI képek rétegelt felépítése lehetővé teszi a hatékony tárolást, gyors letöltést és verziókezelést. A manifest fájl kulcsfontosságú szerepet játszik a kép struktúrájának meghatározásában, míg a rétegek megosztása és optimalizálása jelentősen csökkentheti az erőforrásigényt.

Az OCI formátum szabványosította ezt a struktúrát, így biztosítva a kompatibilitást és a jövőbeli skálázhatóságot.

Remélem kicsit sikerült érhetővé tennem a képfájlok struktúráját. 🙂

Load More