Menu

abc

azure_aks_highlight

Konténerek kezelése egyszerűen: Bevezetés az Azure AKS-be

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

| Olvasási idő: 3 perc |
  • Erőforrás típus: IaaS
  • Felhő szolgáltató: Microsoft Azure
  • Angol név: Azure Kubernetes Service
  • Magyar név: Azure Kubernetes Service
  • Rövidített név (ha van ilyen): AKS

Az elmúlt hetekben rengeteg Kubernetes-el foglalkozó cikket zúdítottam már rátok. Ez nem fog változni a közeljövőben sem, azonban ma egy olyan Kubernetes szolgáltatást nézünk meg közelebbről, amely közben felhőszolgáltató specifikus is.

Azt már többször többféle módon is elmondtam, hogy a konténertechnológia forradalmasította a modern alkalmazásfejlesztést (a legismertebb konténertechnológiai megoldás a Docker): egyszerűbbé vált az alkalmazások csomagolása, szállítása és futtatása különböző környezetekben. Az Azure Kubernetes Service (AKS) ebbe a világba nyújt belépőt, méghozzá teljes mértékben menedzselt formában. A kezdők számára különösen előnyös, mert elrejti a komplexitás nagy részét, miközben erős kontrollt és rugalmasságot biztosít.

Mi az az Azure AKS?
Az Azure Kubernetes Service (AKS) a Microsoft Azure felhőplatformjának menedzselt Kubernetes-szolgáltatása. Lehetővé teszi konténerizált alkalmazások automatikus üzembe helyezését, kezelését, skálázását és monitorozását anélkül, hogy külön kellene gondoskodni a Kubernetes-fürt (cluster) telepítéséről és karbantartásáról.

Miért előnyös az AKS használata?

  • Menedzselt vezérlőréteg
    A Kubernetes vezérlőelemeit (control plane) teljesen menedzseli az Azure – így ezek frissítése, méretezése és biztonsági javítása nem a fejlesztőcsapat feladata.
  • Automatikus skálázás
    Támogatja a vízszintes pod-autoskalázást (HPA), node pool szintű autoskalázást, valamint a manualis skálázást is.
  • Integráció az Azure ökoszisztémával
    Könnyen integrálható más Azure szolgáltatásokkal, például Azure Monitor, Log Analytics, Key Vault, EntraID (Azure AD), vagy az Application Gateway-vel.
  • Támogatás Windows és Linux node poolokra
    Lehetőség van hibrid környezetek létrehozására is, ahol egyes szolgáltatások Windows, mások Linux konténerként futnak.
  • RBAC és identitáskezelés
    Az Azure AD integráció segítségével szabályozhatjuk, ki mit tehet a fürtben (Role-Based Access Control).
  • Frissítési stratégia testreszabása
    A cluster frissítések tervezetten, lépésenként is végrehajthatók, hogy minimalizáljuk a leállást.

Korlátok, amikkel érdemes számolni

  • Control Plane testreszabhatósága korlátozott
    Mivel menedzselt szolgáltatás, bizonyos alacsony szintű beállításokhoz nincs hozzáférés.
  • Sokféle beállítási lehetőség, ami összezavarhatja a kezdőket
    Bár a vezérlőréteg menedzselt, a node poolok, hálózatkezelés, tárolók és jogosultságok konfigurálása összetett lehet.
  • Hosszabb indulási idő
    A node poolok indulása néhány perctől akár 10-15 percig is eltarthat, főleg ha új skálázást kérünk.

Mikor érdemes az AKS-t választani?
Az AKS ideális választás, ha:

  • Több mikroalkalmazást futtatnál egységes környezetben
  • DevOps pipeline-t szeretnél kiépíteni CI/CD-vel
  • Folyamatosan skálázódó alkalmazásokat futtatsz
  • Hosszú távon Kubernetes-es megközelítést szeretnél alkalmazni

Felhasználási példa: Webalkalmazás CI/CD pipeline-nal
Egy több részből álló webalkalmazás (pl. frontend, backend, adatbázis) konténerizált formában van tárolva. Az alkalmazás képfájlai pedig az Azure Container Registry-ben (ACR).

Az AKS lehetővé teszi ezen konténerek fürtbe szervezését. GitHub Actions vagy Azure DevOps használatával CI/CD pipeline-t építhetünk, amely automatikusan telepíti és frissíti az alkalmazás egyes komponenseit a Kubernetes-fürtbe.

A forgalmat Azure Application Gateway vagy Ingress Controller segítségével lehet terelni, míg a logokat Azure Monitorban gyűjthetjük.

Milyen más Azure szolgáltatások támogatják még a Docker-konténereket?
Bár az AKS a legteljesebb konténerkezelési megoldás, az Azure több más konténeres megoldást is kínál, amelyekről külön cikkekben olvashatsz:

  • Azure Container Instances (ACI): Egyszerűbb, rövid életű konténerekhez ideális
  • Azure Container Apps: Serverless konténer platform KEDA és Dapr támogatással
  • Azure App Service for Containers: Webalkalmazások konténerizált verziója
  • Azure Functions with custom containers: Egyedi konténeres serverless megoldások
  • Azure Spring Apps: Spring Boot alkalmazások futtatása konténerekben
  • Azure Dev Spaces (megszűnt): Fejlesztői környezet AKS-en belül
  • Azure Arc-enabled Kubernetes: Saját Kubernetes-fürtök Azure-ból való menedzsmentje

Összefoglalás
Az Azure Kubernetes Service (AKS) ideális választás azok számára, akik szeretnének skálázható, rugalmas, mikroszolgáltatás-alapú architektúrát kialakítani konténerek használatával, anélkül hogy a Kubernetes teljes komplexitásával kellene nap mint nap megküzdeniük. Az AKS lehetőséget ad a fejlődésre: kezdőként is elkezdhetjük, de haladó szintig is skálázhatjuk tudásunkat benne.

Azt azért megjegyezném, hogy egy AKS cluster fenntartása és üzemeltetése nem olcsó mulattság. Mielőtt kipróbálod, – márpedig ki kell próbálnod – ellenőrizd a díjkalkulátor segítségével, hogy mennyibe kerülne.

vpc-highlight

Amazon VPC és Subnet alapok: építs biztonságos hálózatot

, , , , , , , ,

| Olvasási idő: 4 perc |
  • Erőforrás típus: IaaS
  • Felhő szolgáltató: Amazon Web Services
  • Angol név: Virtual Private Cloud
  • Magyar név: Virtuális Hálózat
  • Rövidített név (ha van ilyen): VPC

A virtuális hálózat

A virtuális hálózat egy logikai izolációs réteg, amely a felhőben létrehozott erőforrásaink közötti stabil, gyors és biztonságos kommunikáció biztosítja.

Felhőben a virtuális hálózat, a hagyományos informatikai fizikai hálózat virtuális megvalósítása. Ennek megfelelően működése majdnem tejesen ugyanúgy történik. Ha valakinek van ismerete a hagyományos informatikai hálózattal kapcsolatban, akkor a virtuális hálózatban is könnyedén el tud igazodni.

Ezekkel a sorokkal kezdtem az Azure VNET cikkemet korábban. És ide is tökéletesen illenek ezek a mondatok.

Az Amazon Virtual Private Cloud (röviden VPC) az AWS egyik alapszolgáltatása, amely lehetővé teszi, hogy saját, „elszigetelt” hálózatot hozzunk létre a felhőben. A VPC segítségével úgy tervezhetjük meg a hálózati környezetünket, mintha az egy helyi adatközpont lenne – csak éppen az Amazon infrastruktúráján fut.

Ez a megoldás különösen fontos minden olyan felhős architektúrában, ahol az adatbiztonság, az irányíthatóság (IT governance) és a skálázhatóság egyszerre fontos szempont.

Mi az a VPC?

A Virtual Private Cloud (VPC) egy logikailag elkülönített hálózati tér az AWS-en belül. Olyan, mint egy saját kis adatközpont a felhőben, amelyben te határozod meg:

  • a használt IP-tartományt (CIDR blokk),
  • az elérhető alhálózatokat (Subneteket),
  • az internetkapcsolat módját,
  • a forgalom szűrését és engedélyezését.

A VPC-ben te kontrollálod, hogy melyik erőforrás honnan érhető el, legyen szó publikus vagy privát elérésről.

Mi az a Subnet?

A VPC-n belül alhálózatokat (Subnet) hozunk létre. Ezek lehetnek:

  • Publikus alhálózatok: az itt futó erőforrások (pl. EC2 példányok) közvetlenül elérhetők az internetről.
  • Privát alhálózatok: az itt található erőforrások csak a VPC-n belülről érhetők el, külső elérésük jellemzően NAT Gateway-en vagy VPN-en keresztül történik.

A subnetek lehetnek különböző Availability Zone-ökben, ezáltal biztosítva a magas rendelkezésre állást.

Konkrét példa

Példa 1 – IPv4-alapú VPC

VPC címtartománya:
10.0.0.0/16 (Elérhető ip címek: 10.0.0.1 – 10.0.255.254. Összesen: 65534)

Subnetek (külön AZ-ben):

  • Subnet 1: 10.0.0.0/24 – elhelyezés: eu-central-1a (Elérhető ip címek: 10.0.0.1 – 10.0.0.254. Összesen: 254)
  • Subnet 2: 10.0.1.0/24 – elhelyezés: eu-central-1b (Elérhető ip címek: 10.0.1.1 – 10.0.1.254. Összesen: 254)
  • Subnet 3: 10.0.2.0/24 – elhelyezés: eu-central-1c (Elérhető ip címek: 10.0.2.1 – 10.0.2.254. Összesen: 254)

Kiegészítések:

  • Internet Gateway csatlakoztatva a VPC-hez
  • Subnet 1 publikus (útvonaltábla: 0.0.0.0/0 → IGW)
  • Subnet 2 és Subnet 3 privát, kimenő forgalomhoz NAT Gateway használva
  • Alkalmazás: web frontend a Subnet 1-ben, backend a Subnet 2-ben, adatbázis a Subnet 3-ban

IP cím tartományokat Te magad is ellenőrizheted: https://jodies.de/ipcalc

Példa 2 – IPv6-alapú VPC

VPC IPv6 címtartománya:
Automatikusan kiosztva az AWS által, pl.: 2600:abcd:1234::/56

Subnetek (külön AZ-ben):

  • Subnet A: 2600:abcd:1234:1000::/64 – elhelyezés: eu-central-1a
  • Subnet B: 2600:abcd:1234:2000::/64 – elhelyezés: eu-central-1b
  • Subnet C: 2600:abcd:1234:3000::/64 – elhelyezés: eu-central-1c

Kiegészítések:

  • Internet Gateway IPv6-ra is használható (útvonaltábla: ::/0)
  • Nincs NAT IPv6-ra – az erőforrások közvetlenül elérik az internetet, ha útvonal engedi
  • Javasolt: biztonsági szabályokkal szigorúan szabályozni az elérhetőséget
  • Alkalmazás: publikus IPv6-címmel rendelkező frontend EC2 példány, belső szolgáltatások IPv6-címmel, de szűrt eléréssel

Miért fontos a VPC?

Az alapértelmezett VPC-t minden AWS-fiók tartalmaz, de a legtöbb komolyabb projekt saját, testreszabott VPC-t igényel. Ez lehetővé teszi:

  • a részletes biztonsági szabályozást,
  • a hálózati struktúra tudatos kialakítását,
  • és a felhőerőforrások biztonságos, jól átlátható kezelését.

VPC-hez kapcsolódó fontosabb fogalmak

A VPC-t számos kapcsolódó komponens egészíti ki, amelyek külön cikkek témái lesznek, de fontos most megemlíteni őket, hogy lásd, milyen lehetőségek rejlenek a szolgáltatásban:

  • Internet Gateway: lehetővé teszi, hogy egy alhálózat publikus legyen, és az erőforrások internettel kommunikálhassanak.
  • NAT Gateway / NAT Instance: privát alhálózatból lehet vele kimenő forgalmat irányítani az internet felé, anélkül, hogy a bejövő forgalmat engedélyeznénk.
  • VPN Gateway és AWS Client VPN: biztonságos, titkosított kapcsolatot alakítanak ki a saját irodai hálózat és az AWS VPC között.
  • Peering: VPC-k közötti kapcsolatot tesz lehetővé.
  • Security Group: tűzfalként működik az erőforrások (pl. EC2) körül – csak az engedélyezett forgalmat engedi át.
  • Network ACL: alhálózati szintű forgalomszűrő, kiegészítő védelmet nyújt.

Milyen esetekben érdemes saját VPC-t létrehozni?

  1. Webalkalmazások üzemeltetése
    Külön subnet-ekben futtathatod a publikus (frontend) és privát (backend, adatbázis) komponenseket, így jobban kontrollálható a hozzáférés és a biztonság.
  2. Adatbiztonság és megfelelőség
    Szabályozhatod, hogy az adatok fizikailag hol legyenek (pl. melyik régióban), és hogyan lehet hozzájuk férni.
  3. Hibrid IT környezetek
    VPN segítségével a helyi adatközpontodat összekötheted a VPC-vel, így egységes hálózatként kezelheted az infrastruktúrádat.
  4. Microservice architektúra kiépítése
    Szolgáltatások szegmentálása subnetekbe, központi kommunikációs szabályokkal és forgalomirányítással.

Lehetőségek és korlátok

Erősségek:

  • Teljes kontrol a hálózat felett
  • Széleskörű biztonsági lehetőségek
  • Komplex, de skálázható hálózati struktúrák kialakítása

Korlátok:

  • Az összetettebb VPC-k menedzselése több szakértelmet igényel
  • Az egyes komponensek külön költséggel járhatnak (pl. NAT Gateway, VPN)

Összefoglalás

Az Amazon VPC egy elengedhetetlen építőelem minden komolyabb AWS architektúrában. Segítségével biztonságos, testreszabott hálózati környezetet hozhatsz létre. Már a kezdeteknél érdemes jól átgondolt VPC struktúrát kialakítani, így elkerülhetők a későbbi átalakítások, és hosszú távon stabil, skálázható rendszert építhetsz.

Ha szeretnéd kipróbálni, az AWS Management Console-ban néhány kattintással létrehozhatsz egy saját VPC-t a „VPC Wizard” segítségével.

amazon-ec2-highlight

Rugalmas szerverek a felhőben: Amazon EC2 alapok

, , , , , , ,

| Olvasási idő: 5 perc |
  • Erőforrás típus: IaaS
  • Felhő szolgáltató: Amazon Web Services
  • Angol név: Elastic Compute Cloud
  • Magyar név: Virtuális gép
  • Rövidített név (ha van ilyen): EC2

Jól ismeri mindenki a számítógépeket. Van benne processzor, memória, valamilyen háttértároló. Emellett van benne hálózati kártya, amellyel igény szerint csatlakozhatunk az internetre.

A felhőben lévő virtuálisgépek, virtuális szerverek is ilyenek. A különbség csupán annyi, hogy a felhőben ezeket a gépeket nem érinthetjük meg és egy-egy ilyen gépet akár percenként módosíthatunk, ha ahhoz van kedvünk. Adhatunk hozzá memóriát, virtuális processzormagot, lemezeket és még hálózati kártyát is. És ugyanilyen módon el is vehetjük ezeket, vagy törölhetjük az egész gépet. Ugye milyen izgalmas?

Az a nagyszerű a virtuális gépekben, hogy rugalmasan létrehozhatunk és törölhetünk bármennyit amennyire csak szükségünk van. Nyilvánosan elérhetővé tudjuk őket tenni az interneten bárki számára, vagy biztonságosan elzárhatjuk őket a kíváncsi szemek elől.

Ez csupán attól függ, milyen felhasználási esetre szeretnénk használni ezeket az erőforrásokat. Tudunk eléjük terheléselosztót konfigurálni, hogy ezzel magas rendelkezésre állású rendszereket építsünk. Lehetőségünk van több féle operációs rendszerrel kérni ezeket – Windows, Linux -, szintén attól függően, hogy mit ismerünk vagy mit szeretnénk megvalósítani.

És ha kiválasztottuk az általunk ismert operációs rendszert, akkor pedig már túl is vagyunk a legnehezebb részén a dolgoknak. Miért? Mert onnan egy ismerős világba csöppenünk, hiszen miután bejelentkeztünk a virtuális gépünkre, azonnal otthon érezzük magunkat. Mivel a gépet pontosan ugyanúgy tudjuk használni, ahogy azt már megszoktuk a hagyományos számítógépeknél.

És mielőtt továbbmennénk szeretnék felsorolni néhány igen hasznos tulajdonságot, amire képesek a virtuális gépek:

  • Nagy teljesítmény
  • Automatikus skálázás
  • Több operációs rendszer támogatása (Windows, Linux)
  • Gyors biztonsági mentés és visszaállítás
  • Beépített figyelési és felügyeleti eszközök
  • Mesterséges intelligencia, videókártya és nagy teljesítményű adatfeldolgozás
  • Beépített biztonsági eszközök

És még rengeteg apróság, ami miatt a virtuálisgép az egyik legnépszerűbb felhő erőforrás az AWS-ben is. Mivel ez nevezhető hagyományos erőforrásnak és mellette egy valódi svájci bicska, így érthető, hogy amikor felhőbe költözésről beszélünk, a legnyilvánvalóbb megoldás, hogy „lift-and-shift” megközelítéssel virtuális gépekre költöztetjük a cégünk alkalmazásait.

Mi az az EC2?

Az Amazon EC2 (Elastic Compute Cloud) egy IaaS típusú szolgáltatás. Ez azt jelenti, hogy a felhasználó operációs rendszert, tárolást és számítási kapacitást kap anélkül, hogy fizikai hardverrel kellene dolgoznia. A szolgáltatás lehetővé teszi, hogy percek alatt elindítsunk egy vagy több virtuális gépet, és ezek fölött teljes hozzáférést és irányítást kapjunk – akár Linux, akár Windows alapú rendszerről van szó. (sőt még MacOS-t is használhatunk)

Az Amazon EC2 főbb előnyei

  1. Rugalmasság: Több száz géptípus közül választhatunk (pl. általános célú, memóriára vagy CPU-ra optimalizált).
  2. Skálázhatóság: Könnyedén felskálázható terhelés esetén, vagy épp csökkenthető, ha kevesebb erőforrás is elég.
  3. Integráció más AWS szolgáltatásokkal: Például tárolás (S3, EBS), adatbázisok (RDS), biztonság (IAM).
  4. Fizetés használat alapján: Perc- vagy óradíjas elszámolás, illetve dedikált vagy spot példányok is választhatók.
  5. Globális elérhetőség: Több régióban és elérhetőségi zónában indíthatunk példányokat a gyors válaszidő és redundancia érdekében.

Mire érdemes használni?

Az EC2 általános célokra is kiváló, de különösen hasznos a következő esetekben:

  • Webszerverek futtatása
  • Alkalmazás backendek kiszolgálása
  • Ideiglenes tesztkörnyezetek
  • Adatfeldolgozó vagy gépi tanulási feladatok
  • VPN szerverek, proxik, belső rendszerek

Gyakorlati példa

Tegyük fel, hogy egy kisebb cég webalkalmazást szeretne üzemeltetni. A fejlesztők egy gyors és költséghatékony megoldást keresnek, amely rugalmas és skálázható. Egy Amazon EC2 példányon futtatják az alkalmazás szervert és az adatbázist, amit később külön EC2 példányokra szétbonthatnak. Használhatnak automatikus skálázást és terheléselosztást is, így a rendszer képes kiszolgálni egyre több felhasználót anélkül, hogy manuálisan be kellene avatkozni.

Korlátok és megfontolandó tényezők

  • Menedzsment igény: Az EC2 teljes körű szabadságot ad, de minden frissítést, biztonsági beállítást nekünk kell kezelni.
  • Árképzés komplexitása: Külön figyelmet kell fordítani a példány típusára, régióra, tárhelyre, hálózati forgalomra.
  • Állandóság: Az EC2 példányok nem állandók: ha nem EBS-alapú tárolót használunk, a leállás után minden adat elveszhet.
  • Nem serverless: Egyre több modern alkalmazás preferálja a serverless megközelítést (pl. Lambda), ahol nem kell példányokat kezelni.

Mikor válaszd az EC2-t?

Ha olyan alkalmazást futtatsz, amelynek pontosan meghatározott infrastruktúra igénye van, vagy ha egyedi operációs rendszerre, hálózati beállításokra van szükséged, az EC2 remek választás. Különösen jó kiindulópont, ha még tanulod a felhőalapú rendszerek működését, vagy ha egyéni alkalmazáslogikát szeretnél futtatni teljes kontroll mellett.

EC2 példánytípusok áttekintése

Az Amazon EC2 különféle példánytípusokat kínál, amelyek különböző számítási, memória- és tárolási jellemzőkkel rendelkeznek. Ezek kategóriákba vannak sorolva, hogy könnyebb legyen kiválasztani a megfelelő típust az adott feladathoz.

TípusMéretekLeírás
Általános célúMac, A1, M4, M5zn, M5n, M6a, M6i, M6g, T2, T3a, T3, T4Kiegyensúlyozott processzor-memória arány. ​
SzámításoptimalizáltC4, C5n, C5a, C5, Hpc6a, C6a, C6i, C6gn, C6g, C7g​Magas processzor-memória arány. ​
Memóriaoptimalizált​R5, R5a, R5b, R5n, R6im R6id, X1e, X2gd, X2idn, X2iedn, X2iezn, z1d, High Memory​Magas memória-processzor arány.​
Tároptimalizált​H1, D3en, D3, D2, I3en, I3, I4i, Is4gen, Im4gn​Nagy lemezteljesítmény és I/O ideális big data-, SQL-, NoSQL-adatbázisokhoz, adattárházakhoz és nagy tranzakciós adatbázisokhoz.​
GPU & Accelerated​VT1, F1, G3, G4ad, G4dn, G5g, G5, Inf1, Trn1, DL1, P2, P3, P4​Elérhető egy vagy több GPU-val.​

Választási szempont

Az ideális példánytípus kiválasztása az alábbiak figyelembevételével történik:

  • Mekkora CPU- és memóriaigénye van az alkalmazásnak?
  • Átmeneti vagy folyamatos a terhelés?
  • Kell-e lokális, nagy sebességű tárolás?
  • Futtat-e AI vagy gépi tanulási feladatokat?

Ha valaki például egy kis WordPress oldalt szeretne futtatni, akkor egy T4g vagy T3 példány is elegendő. Egy nagyobb webalkalmazáshoz már M vagy C sorozat ajánlott. Gépi tanulási modell tanításához pedig P vagy Trn példány a megfelelő választás.

Költséghatékonysági lehetőségek: Reserved Instances és Savings Plans

Az Amazon EC2 egyik előnye, hogy többféle díjszabási modell közül választhatunk, így optimalizálhatjuk a költségeket az igényeink szerint. A három leggyakoribb modell: On-Demand, Reserved Instances és Savings Plans.

Mikor melyiket válaszd?

HelyzetAjánlott megoldás
Tesztelés, rövid futásOn-Demand
Stabil, hosszú távú használatReserved Instance
Több régió, szolgáltatás eseténCompute Savings Plan
EC2 használat, fix régióvalEC2 Instance Savings Plan

Az Amazon EC2 ideális belépési pont azok számára, akik szeretnék kihasználni a felhőalapú számítástechnika rugalmasságát és skálázhatóságát. Legyen szó egyszerű weboldalról, tesztkörnyezetről vagy akár komplex üzleti alkalmazásról, az EC2 biztosítja a szükséges építőelemeket. A különféle példánytípusok, a költségoptimalizálási lehetőségek (Reserved Instances, Savings Plans), valamint a globális infrastruktúra miatt szinte bármilyen igényt ki tud szolgálni.

Ha eddig csak olvastál a felhőről, most itt az idő, hogy kipróbáld saját magad. Hozz létre egy ingyenes AWS fiókot, indíts el egy EC2 példányt, és tapasztald meg első kézből, mit jelent egy szerver indítása a felhőben. Lehet, hogy ez lesz az első lépésed egy új digitális karrier vagy vállalkozás felé.

Amazon_ECS_felho_kontener

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

, , , , , , , , , , ,

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

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

Mi az Amazon ECS?

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

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

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

Az Amazon ECS előnyei

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

Korlátai és kompromisszumok

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

Amazon ECS vs Azure Container Instances (ACI)

JellemzőkAmazon ECSAzure Container Instances
Szolgáltatás típusaOrchesztráció (EC2 vagy Fargate)Egyszerű konténerfuttatás
SkálázásAutomatikus, komplexAlap skálázás
HálózatkezelésTeljes VPC integrációEgyszerűbb, korlátozott
Hosszú távú futtatásIdeális (pl. microservice-ekhez)Rövid életű vagy egyszerű feladatokhoz
IntegrációkSzoros AWS-integrációAlap Azure integráció
OrchestratorECS saját megoldása vagy FargateNincs orchestrator

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

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

Felhasználási példa

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

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

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

1. Lépj be az AWS Console-ba

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

2. Kattints a „Create Cluster” gombra

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

3. Hozz létre egy Task Definition-t

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

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

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

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

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

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

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

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

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

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

Összefoglalás

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

azure_savings_vs_ri

Hogyan csökkentsük kiadásainkat Azure-ban? – SP vs RI

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

| Olvasási idő: 3 perc |

Nem is olyan régen így kezdem az egyik AWS-es cikket:

A felhő is csak akkor gazdaságos, ha okosan használjuk

És volt már szó az Azure Spot VM-ről is, ami egy olyan típusú virtuális gép, amelyet az Azure a kihasználatlan kapacitásaiból kínál rendkívül kedvező áron. Ma tovább lépünk.

Az Azure használata során hamar szembesülhetünk azzal, hogy a felhőszolgáltatások költségei gyorsan megnövekedhetnek. Szerencsére a Microsoft kínál megoldásokat arra, hogy optimalizáljuk a kiadásainkat: két népszerű lehetőség a Savings Plan és a Reserved Instance (RI). Ebben a cikkben bemutatom, hogyan működnek ezek az ajánlatok, mik az előnyeik, hátrányaik, és milyen helyzetekben érdemes az egyiket vagy a másikat választani.

Mi az az Azure Savings Plan?

Az Azure Savings Plan egy rugalmas megtakarítási konstrukció. Lényege, hogy vállalod egy meghatározott, óránkénti összeg elköltését az Azure-ban, 1 vagy 3 éves időszakra. Ezért cserébe jelentős kedvezményeket kapsz az on-demand (normál) díjszabásokhoz képest.

Az óránkénti költési szint szabadon felhasználható többféle szolgáltatásra és régióra, például virtuális gépekre (VM-ekre), App Service-re vagy más compute-alapú erőforrásokra.

Előnyei:

  • Nagy rugalmasság: bármilyen támogatott compute szolgáltatásra elkölthető.
  • Nincs szükség konkrét erőforrás vagy régió előzetes megkötésére.
  • Könnyebb alkalmazkodni a változó igényekhez.

Hátrányai:

  • Ha nem használod ki az óránkénti költési vállalásodat, akkor is ki kell fizetned.
  • Kevésbé kedvező ár a Reserved Instance-hez képest ugyanazon VM-ekre.

Mi az az Azure Reserved Instance?

A Reserved Instance (foglalt példány) egy klasszikusabb megközelítés: itt konkrét virtuális gép típusra, régióra és üzemidőre vállalsz elköteleződést egy vagy három évre. Cserébe jelentősen olcsóbban használhatod az adott VM-et, akár 72%-os megtakarítást is elérve az on-demand árhoz képest.

Előnyei:

  • Nagy megtakarítás fix VM használat esetén.
  • Tervszerű, stabil költségtervezés hosszú távra.
  • Átadható más előfizetésbe vagy eladható a Reserved Instance Marketplace-en.

Hátrányai:

  • Kevés rugalmasság: kötött VM méret, típus, régió.
  • Ha változnak az igények (pl. más méret vagy régió kell), nehezebb alkalmazkodni.

Savings Plan vs Reserved Instance – Összehasonlítás

JellemzőSavings PlanReserved Instance
RugalmasságMagasAlacsony
Megtakarítás mértékeKözepes (~20-65%)Nagy (~30-72%)
ElköteleződésÓránkénti költési vállalásKonkrét VM, régió, időtartam
ÁtadhatóságNemIgen (Marketplace-en értékesíthető)
Igényváltozások kezeléseRugalmasabbKorlátozott

Mikor melyiket válasszam?

Savings Plan

  • Ha még nem tudod pontosan, milyen erőforrásokat fogsz hosszú távon használni.
  • Ha dinamikusan változik a compute igényed (például szezonális terhelés esetén).
  • Ha többféle compute szolgáltatást kombinálnál (pl. VM-ek, App Service, Functions).

Reserved Instance

  • Ha pontosan tudod, milyen típusú VM-et, melyik régióban, hosszú távon fogsz futtatni.
  • Ha stabil, kiszámítható workloadod van, például állandóan futó alkalmazásszerverek.
  • Ha maximalizálni akarod a megtakarítást, és nem zavar a rugalmasság hiánya.

Összegzés

Mind a Savings Plan, mind a Reserved Instance remek eszköz arra, hogy csökkentsd az Azure költségeidet. A választás attól függ, mennyire tudod előre megjósolni a jövőbeni erőforrásigényedet. Ha bizonytalan vagy, a Savings Plan által kínált rugalmasság előnyösebb lehet. Ha viszont stabil, kiszámítható rendszered van, akkor a Reserved Instance adja a legjobb ár-érték arányt.

Ne feledd! Ez minden esetben elköteleződéssel jár. Azaz akkor is fizetned kell, ha nem használod ki a hűségszerződésben foglaltakat. Ezért jól gondold át, mielőtt beleugrasz.

aws_savings_vs_reserved

Okos költségoptimalizálás AWS-ben: SP vs RI

, , , , , , , , , , ,

| Olvasási idő: 3 perc |

A megfelelő költségkezelés a felhő egyik kritikus része. Minden oktatásomon el is hangzik a következő mondat:

A felhő is csak akkor gazdaságos, ha okosan használjuk

Az egyik korábbi cikkemben már bemutattam a költséghatékonyság kapcsán a Spot Instance-ot, amely olyan virtuális gép (EC2 instance), amit az AWS fel nem használt kapacitásából kínál. Mivel ezek az erőforrások „feleslegesek”, az áruk jelentősen alacsonyabb, mint az on-demand (igény szerinti) vagy reserved instance-oké.

Azt talán nem szükséges ecsetelni, hogy az AWS-felhőszolgáltatásai rugalmasak és nagy teljesítményűek, de a használatuk ára gyorsan emelkedhet, ha nem figyelünk a költségekre. Éppen ezért kínál az AWS olyan konstrukciókat, mint a Savings Plan és a Reserved Instance (RI), amelyekkel jelentős megtakarítást érhetünk el.

Alapfogalmak

Mindkét konstrukció alapja a hosszú távú elköteleződés egy adott futtatási kapacitás mellett. Ezért cserébe akár 72%-os megtakarítást is elérhetünk az on-demand (azonnali) árakhoz képest. A különbség főként a rugalmasságban és a használati feltételekben rejlik.

Reserved Instance (RI) – Lefoglalt példány

A Reserved Instance egy meghatározott régióra, géptípusra és gyakran operációs rendszerre szóló foglalás. Az elköteleződés (hűségszerződés) 1 vagy 3 évre történik.

Előnyök:

  • Jelentős megtakarítás az On-Demand árakhoz képest (akár 72%)
  • Teljesítménygarancia, mert a példány le van foglalva
  • Költség előre jól tervezhető

Korlátok:

  • Merev: példánytípus, régió, OS, fizetési konstrukció kötött
  • Ha megváltozik az igény, a foglalás nem feltétlenül használható jól
  • Csak EC2-re és néhány más szolgáltatásra vonatkozik

Savings Plan – Rugalmasabb megtakarítási terv

A Savings Plan inkább az elköltött összegre vonatkozik, nem konkrét példányokra. Megadhatjuk, hogy napi szinten mekkora összeget vállalunk 1 vagy 3 évre. Ezt az AWS automatikusan optimalizálja a háttérben.

Két típus létezik:

  1. Compute Savings Plan: Rugalmasan használható bármely régióban, bármely példánytípusra, akár AWS Fargate és Lambda esetén is.
  2. EC2 Instance Savings Plan: Kötöttebb – egy régióhoz és géptípus családhoz kötött, de géptípus szinten rugalmasabb, mint az RI.

Előnyök:

  • Nagy rugalmasság – könnyebb alkalmazkodni a változó igényekhez
  • Automatikus alkalmazás, nem kell példányokat lekötni
  • Szélesebb szolgáltatási kör (Lambda, Fargate is)

Korlátok:

  • Kisebb megtakarítás, mint a teljesen lekötött RI esetén (max. ~66%)
  • Előzetes költési elköteleződés szükséges
  • Ha kevesebbet használunk, mint amennyit lekötöttünk, nincs visszatérítés

Mikor melyiket? Felhasználási esetek

Reserved Instance javasolt, ha:

  • Tudjuk, hogy hosszú távon fix kapacitásra lesz szükségünk (pl. 7×24-ben futó webalkalmazás)
  • Nem várható jelentős változás a példánytípusban, régióban vagy OS-ben
  • Az EC2 az elsődleges költségforrásunk

Savings Plan javasolt, ha:

  • Gyakran változik a példánytípus, régió, vagy konténeres/Lambda alapú az architektúra
  • Több szolgáltatás költségét akarjuk optimalizálni egyszerre
  • Nem szeretnénk példányhoz kötött döntéseket hozni

Összegzés

Mind a Reserved Instance (foglalt példány), mind a Savings Plan (megtakarítási terv) hatékony eszköz az AWS költségek optimalizálására. A választás kulcsa az, hogy mennyire fix az infrastruktúránk és mennyire fontos a rugalmasság. Kezdőként érdemes a Savings Plan-nel kezdeni, különösen ha dinamikus vagy kísérletezős környezetben dolgozunk. Ha viszont stabil termékkörnyezetet futtatunk, a Reserved Instance biztosíthatja a legnagyobb megtakarítást.

Savings Plan vs Reserved Instance – Gyors összehasonlítás

TulajdonságSavings PlanReserved Instance (RI)
RugalmasságMagas (Compute SP szinten kiemelkedő)Alacsony (kötött példánytípus, régió stb.)
Megtakartítható költségKözepes–magas (akár ~66%)Magas (akár ~72%)
Elköteleződés időtartama1 vagy 3 év1 vagy 3 év
Példány típusának változtatásaLehetséges (Compute SP esetén)Nem lehetséges
Szolgáltatások köreEC2, Fargate, LambdaFőleg EC2
Felhasználás módjaAutomatikusan alkalmazva költés alapjánElőre lefoglalt példányhoz kötött
Legjobb felhasználási esetDinamikus vagy konténeres környezetÁllandó példányhasználat fix igényekkel
Fizetési lehetőségekElőre, részben előre vagy haviUgyanez (No Upfront, Partial, All Upfront)

Ez a táblázat segíthet gyorsan átlátni a fő különbségeket, és a saját igényeinkhez legjobban illeszkedő megoldást választani.

Ne feledd! Ez minden esetben elköteleződéssel jár. Azaz akkor is fizetned kell, ha nem használod ki a hűségszerződésben foglaltakat. Ezért jól gondold át, mielőtt beleugrasz.

aws_spot-1

AWS Spot instance – Felhőalapú számítás költséghatékonyan

, , , , , , , ,

| Olvasási idő: 5 perc |
  • Erőforrás típus: IaaS
  • Felhő szolgáltató: Amazon Web Services
  • Angol név: EC2 Spot Instance
  • Magyar név: EC2 Spot Instance
  • Rövidített név (ha van ilyen): Spot Instance

Ahogy a legutóbbi cikkemben írtam a felhőben időről-időre lesznek olyan fel nem használt szabad kapacitások, amelyek bizonyos szempontból veszteséget termelnek a szolgáltatónak. Kíváncsi vagyok, vajon azóta megismerd-e az Azure Spot VM-et. Ennek párja az AWS-ben az EC2 Spot Instance (röviden: Spot Instance). Ma ezt szeretném nektek bemutatni kicsit közelebbről, hátha kedvet kaptok és kipróbáljátok, vagy éppen olyan projekten dolgoztok, ahol ez a tökéletes választás.

Tehát az Amazon Web Services (AWS) is lehetőséget kínál arra, hogy akár 90%-kal olcsóbban használjunk számítási erőforrásokat – ez a Spot instance. Ez a lehetőség különösen vonzó lehet fejlesztőknek, startupoknak és minden olyan technológiai csapatnak, amely rugalmas workload-okon dolgozik, és szeretné optimalizálni az infrastruktúra költségeit.

Mi az az AWS Spot instance?

Az AWS Spot instance olyan virtuális gép (EC2 instance), amit az AWS fel nem használt kapacitásából kínál. Mivel ezek az erőforrások „feleslegesek”, az áruk jelentősen alacsonyabb, mint az on-demand (igény szerinti) vagy reserved instance-oké.

A felhasználók licitálás nélkül, rugalmas áron vehetnek igénybe Spot Instance-okat, és az AWS bármikor visszavonhatja őket, ha a kapacitásra másnak van szüksége. Ezért a Spot instance nem minden megoldáshoz ideális – de bizonyos esetekben hatalmas előnyt jelent.

Mikor érdemes Spot instance-ot használni?

A Spot instance különösen hasznos olyan feladatoknál, amelyek:

  • Nem időkritikusak (azaz nem okoz üzletileg kárt, ha a gép leáll)
  • Hibamentesen újraindíthatók vagy megszakíthatók
  • Rugalmasan skálázhatók (automatikus skálázás, kézi beavatkozás nélkül)
  • Rövid ideig tartanak vagy batch jellegűek (20 perc – 1 órás feladatok, vagy olyan tömegesen futtatandó script-ek amelyeknek rövid időre nagy számítási kapacitásra van szüksége. Pl.: CI/CD pipeline-ok, konténeres munkafolyamatok)
  • Párhuzamosíthatók (pl. batch feldolgozás)

Ár és megtakarítás

A legnagyobb előny az ár: Spot instance-ok akár 70-90%-kal olcsóbbak lehetnek az on-demand áraknál. Az ár dinamikusan változik a kereslet-kínálat alapján, de nem kell manuálisan licitálni – az AWS automatikusan a legalacsonyabb aktuális áron biztosítja az erőforrást.

Korlátok és kockázatok

A Spot instance legnagyobb hátránya a bizonytalan rendelkezésre állás. Ha az AWS-nek szüksége van az erőforrásra, akkor értesítést küld a leállításról, és 2 percen belül leállítja az instance-ot. Ezért fontos olyan megoldásokat futtatni rajta, amelyek képesek kezelni ezt a megszakítást.

További korlátok:

  • Nem garantált a futási idő (lehet hogy több hét, lehet hogy csak egy óra)
  • Egyes régiókban vagy instance típusoknál korlátozott a kapacitás
  • Nincs SLA (Service Level Agreement) garancia Spot instance-ra

Hol lehet használni Spot instance-okat?

A Spot instance-ok nem csak egyedi EC2 példányokhoz érhetők el. Az AWS világa számos olyan szolgáltatást kínál, ahol beépítve használhatjuk a Spot kapacitást – akár automatikus méretezéssel, konténerkezeléssel vagy teljesen menedzselt környezetekkel kombinálva. Íme néhány jelentős terület:

1. EC2 Auto Scaling Group (ASG)

Az Auto Scaling Group lehetővé teszi vegyes példánytípusok és ármodellek használatát. Például beállíthatjuk, hogy a csoport 70%-a Spot, 30%-a on-demand példányokból álljon. A rendszer automatikusan pótlást végez, ha egy Spot példány megszűnik.

2. Elastic Beanstalk

A Beanstalk egy platformszintű szolgáltatás, amely leegyszerűsíti az alkalmazások telepítését. Beállítható, hogy a háttérben futó EC2 példányok részben vagy teljesen Spot instance-ok legyenek. Ez ideális webalkalmazások költséghatékony futtatásához.

3. Amazon EKS (Elastic Kubernetes Service)

Az EKS Kubernetes klasztereknél támogatja a Spot alapú node-okat. Vegyes node pool segítségével lehetőség van kevésbé kritikus podokat Spot gépekre ütemezni, míg fontos szolgáltatásokat on-demand node-okon futtatunk.

4. AWS Batch

Az AWS Batch egy batch-alapú feldolgozási szolgáltatás, amely automatikusan skálázza az erőforrásokat – beleértve a Spot instance-okat is. Ez ideális például tudományos szimulációk, nagy volumenű renderelés vagy adatelemzés során.

5. Amazon EMR (Elastic MapReduce)

EMR használható Spot instance-okra építve is, főleg Hadoop, Spark vagy Presto alapú analitikai feladatokra. A nem kritikus worker node-ok Spot alapon futtathatók, míg a master node on-demand példány lehet a stabilitás érdekében.

6. Amazon ECS (Elastic Container Service)

Konténeres környezetben, főleg Fargate spot üzemmóddal vagy EC2 alapú klaszterekben, költséghatékonyan futtathatók konténerek Spot instance-okon, ideális CI/CD pipeline-okhoz vagy rövid életű mikroszolgáltatásokhoz.

7. SageMaker

A SageMaker modellek tanításánál is használható Spot training, amely jelentős költségcsökkentést kínál hosszabb, erőforrás-igényes tréning folyamatok során. Az AWS automatikusan menti az állapotot és folytatja, ha egy Spot gép kiesik.

8. Dev/Test környezetek

Fejlesztési és tesztelési környezetek gyakran nem kritikusak – ideális jelöltek a Spot instance-alapú futtatásra. Automatikusan indíthatók, leállíthatók és újraindíthatók anélkül, hogy ez éles rendszereket veszélyeztetne.

9. CI/CD pipeline-ok

Build, teszt és deploy pipeline-ok gyakran futnak rövid ideig és gyakran – ezek kiválóan optimalizálhatók Spot példányokkal, főleg ha konténeres vagy serverless architektúrában futnak.

10. Gépi tanulás, renderelés, transzkódolás

Minden olyan folyamat, ami párhuzamosítható, szakaszos és újraindítható – például videók transzkódolása, képfeldolgozás vagy gépi tanulásos modellek tanítása – ideálisan futtatható Spot példányokon.

Hogyan lehet biztonságosan használni?

  1. Spot Fleet vagy Auto Scaling Group
    Automatikusan kezeli az elérhető Spot instance-okat, és ha kell, más instance típussal pótolja.
  2. Checkpointing
    A folyamat időszakos mentése lehetővé teszi a gyors visszaállást.
  3. Mixed Instance stratégia
    Kombinálható on-demand és Spot példányokkal egy szolgáltatás, így növelve a rendelkezésre állást.
  4. Containerizáció és Kubernetes
    A konténeres architektúrák, különösen az EKS, ideálisan kezelik a dinamikusan változó Spot környezeteket.

Összefoglalás

Az AWS Spot instance egy kiváló eszköz azoknak, akik költséghatékonyan szeretnék működtetni nem kritikus feladataikat a felhőben. Bár kompromisszumot igényel a rendelkezésre állás terén, megfelelő architektúrával és tervezéssel rengeteg pénzt lehet vele megtakarítani.

A Spot instance-ok ma már szinte minden jelentős AWS szolgáltatásba integrálhatók. Nem csak a költségek csökkentését szolgálják, hanem lehetőséget nyújtanak a rugalmas, skálázható és optimalizált architektúrák kialakítására is.

A kulcs a tudatos tervezés – meg kell érteni, hol van szükség állandó rendelkezésre állásra, és hol engedhetjük meg a rugalmas, megszakítható infrastruktúrát.

cloud-formation-1

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

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

| Olvasási idő: 4 perc |
  • 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. 🙂

acr00003

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

, , , , , , , , , ,

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

A modern alkalmazásfejlesztés egyik alappillére a konténerizáció. Az olyan eszközök, mint a Docker, lehetővé teszik, hogy alkalmazásainkat izolált, skálázható konténerekben futtassuk. A konténerizációhoz azonban szükség van egy megbízható tárhelyre, ahol a konténerképeket tárolhatjuk, kezelhetjük és megoszthatjuk.

Pontosan ezt a bevezetőt írtam az AWS ECR-ről szóló cikkben is. Úgy gondoltam, hogy ebben sem lesz ez másképp. Most azonban az Azure tárólóregisztrációs adatbázisáról lesz szó, az ACR-ről.

Az Azure Container Registry (ACR) egy teljes mértékben felügyelt, privát konténerregiszter az Azure felhőplatformon, amely lehetővé teszi a Docker és OCI (Open Container Initiative) kompatibilis konténerek tárolását és kezelését. Az ACR különösen hasznos azoknak, akik Kubernetes-t (AKS – Azure Kubernetes Service) vagy más konténeres megoldásokat használnak, de kezdők számára is könnyen érthető és kezelhető.

Miért van szükség az ACR-re?

A konténerizált alkalmazások egyik alapvető eleme a konténerregiszter, amely a konténerképek tárolására és elérhetővé tételére szolgál. Bár használhatunk publikus tárolókat is, például a Docker Hub-ot, a vállalati vagy biztonsági szempontból érzékeny környezetekben érdemes egy privát megoldást választani, mint az ACR.

Előnyei:

  • Privát és biztonságos: Csak az engedélyezett felhasználók és szolgáltatások férhetnek hozzá.
  • Azure integráció: Könnyen csatlakoztatható Azure Kubernetes Service-hez (AKS), App Service-hez és más Azure szolgáltatásokhoz.
  • Automatizált építés és frissítés: Beállíthatunk automatikus képépítést és frissítést webhookok vagy DevOps pipeline-ok segítségével.
  • Geo-replikáció: Több régióban is elérhetővé tehetjük a konténerképeket.

Az ACR struktúrája

Az ACR egy hierarchikus struktúrát követ, amely lehetővé teszi a különböző konténerképek és adattárolók rendezett kezelését:

  • Registry: Az ACR legfelső szintje, amely az összes tárolt képet kezeli.
  • Repository: Egy adott alkalmazás vagy verziótároló helye, ahol különböző verziójú képek találhatók.
  • Tag-ek: A különböző verziókat és build-eket azonosítják, például node-webapp:3.0.0, node-webapp:latest.

Hogyan tölthetek fel képet az ACR-be?

Ha van egy helyi Docker image, amelyet szeretnénk az ACR-be feltölteni:

  • Tag-elés az ACR nevével:
docker tag node-webapp:4.0.0 acrregistryneve.azurecr.io/node-webapp:4.0.0
docker tag node-webapp:4.0.0 acrregistryneve.azurecr.io/node-webapp:latest

  • Push-olás (feltöltés) az ACR-be
docker push acrregistryneve.azurecr.io/node-webapp:4.0.0
docker push acrregistryneve.azurecr.io/node-webapp:latest

  • Megtekintés az ACR-ben
az acr repository list --name acrregistryneve --output table

Alkalmazás indítása az ACR-ben tárolt képből

A legegyszerűbb módja egy ACR-ben tárolt konténer futtatásának az Azure Container Instances (ACI) használata. Az ACI lehetővé teszi, hogy néhány parancs segítségével elindítsuk az alkalmazásunkat anélkül, hogy egy teljes Kubernetes klasztert kellene kezelni.

  • ACI erőforrás létrehozása és az ACR-ből való kép futtatása
az container create --resource-group eroforrascsoport --name node-container --image acrregistryneve.azurecr.io/node-webapp:4.0.0 --registry-login-server acrregistryneve.azurecr.io --registry-username $(az acr credential show --name acrregistryneve --query "username" --output tsv) --registry-password $(az acr credential show --name acrregistryneve --query "passwords[0].value" --output tsv) --dns-name-label node-webapp-container --ports 80

  • A konténer állapotának ellenőrzése
az container show --resource-group eroforrascsoport --name node-container --query "{FQDN:ipAddress.fqdn}" --output table


Ez az egyszerű megoldás lehetővé teszi, hogy gyorsan és könnyedén futtassunk egy alkalmazást az ACR-ben tárolt képből anélkül, hogy mélyebb Kubernetes ismeretekre lenne szükség.

Életciklus és tárhely kezelés

Az ACR lehetőséget biztosít az életciklus és tárhely kezelésére:

  • Retention Policies: Beállíthatunk automatikus törlési szabályokat az elavult vagy nem használt képek eltávolítására.
  • Tiered Storage: Az ACR támogatja a különböző szintű tárhelyeket (Basic, Standard, Premium) az igényekhez igazítva.
  • Garbage Collection: Az ACR automatikusan törli a nem használt rétegeket, csökkentve ezzel a tárhelyhasználatot.

ACR integráció más Azure szolgáltatásokkal

Az ACR könnyen integrálható más Azure szolgáltatásokkal:

  • Azure Kubernetes Service (AKS): Automatikusan betölthető konténerképek az ACR-ből.
  • Azure DevOps: Pipeline-ok segítségével automatizálhatjuk a képépítést és publikálást.
  • Azure Functions: Konténerizált funkciók futtatása közvetlenül az ACR-ből.
  • Azure App Service: Webalkalmazások közvetlenül ACR-ből történő futtatása.

Összegzés

Az Azure Container Registry egy kiváló eszköz a konténerizált alkalmazások tárolására és kezelésére az Azure környezetben. Az ACR segítségével biztonságosan és hatékonyan dolgozhatunk konténerképekkel, integrálhatjuk azokat DevOps pipeline-okba, és közvetlenül felhasználhatjuk Azure szolgáltatásokban. Kezdőként érdemes kísérletezni az ACR használatával, és megtapasztalni, hogyan egyszerűsítheti a konténerkezelési folyamatokat.

Szerinted is jobb biztonságosan tárolni az alkalmazásainkat?

bicep1

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

, , , , , , , ,

| Olvasási idő: 3 perc |
  • 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?

Load More

Verified by MonsterInsights