docker

kubernetes_telepitesi_no_text

Kubernetes telepítési lehetőségek és eszközök áttekintése

, , , , , , , , , ,

| Olvasási idő: 4 perc |

Már van egy kialakult képünk és történeti hátterünk a Kubernetes-ről. Ezért ideje, hogy foglalkozzunk kicsit a telepítési lehetőségekkel és a legfontosabb eszközökkel. Igen. Kezdünk közelebb kerülni a gyakorlati dolgokhoz.

Kubernetes telepítési eszközök

Belekezdünk abba a részbe, ami a Kubernetes cluster (ejtsd: klaszter) telepítéséről és konfigurálásáról szól. Áttekintjük azokat a lehetőségeket, amelyekkel saját Kubernetes cluster-t hozhatsz létre, akár a saját gépeden, akár a felhőben. Bár a felhőszolgáltatók használata egyszerű és gyors megoldás, továbbra is számos indok szól az on-premise (hagyományos adatközpont) telepítés mellett, például a biztonság, az adatszuverenitás vagy a költséghatékonyság.

Gyors indulás felhőben vagy lokálisan

Kezdők számára hasznos lehet egy előre konfigurált környezet kipróbálása, mielőtt belevágnának egy saját cluster kézi telepítésébe. Ilyen esetekben több lehetőség közül is választhatunk:

  • Google Kubernetes Engine (GKE) – a Google Cloud Platform szolgáltatása, amely lehetővé teszi, hogy a legfrissebb stabil Kubernetes verzióval rendelkező klasztert hozzunk létre néhány kattintással.
  • Amazon Elastic Kubernetes Service (EKS) – az Amazon megoldása, amely részletesebb irányítást ad a vezérlőcsomópontok (control plane nodes) felett.
  • Microsoft Azure Kubernetes Service (AKS) – hasonló funkcionalitással bír, mint a GKE és az EKS.
  • DigitalOcean Kubernetes – egyszerű és költséghatékony belépőszintű alternatíva.
  • Civo – amely hasonló a DigitalOcean-hoz, csak még egyszerűbben használható.

Lokális tanulókörnyezetek

Ha helyben szeretnél kipróbálni egy Kubernetes klasztert, az alábbi eszközök ideálisak tanulásra és fejlesztésre:

  • Minikube – Egyetlen bináris fájl, amely például Oracle VirtualBox segítségével telepíti a klasztert. Bár csak egycsomópontos környezetet hoz létre, ideális tanulási és tesztelési célokra.
  • MicroK8s – A Canonical által fejlesztett, könnyen telepíthető és funkciókban gazdag megoldás, amely fejlesztőknek és tesztelőknek egyaránt megfelelő.
  • Docker Desktop (Kubernetes támogatással) – A Docker Desktop képes egyetlen kattintással Kubernetes cluster-t indítani. Fejlesztőknek kiváló választás, főként ha már egyébként is használják Docker környezetben a konténereket.
  • Kind (Kubernetes IN Docker) – Olyan eszköz, amely lehetővé teszi a Kubernetes klaszterek futtatását Docker konténereken belül. Különösen hasznos CI/CD rendszerekhez és olyan helyzetekben, ahol gyorsan szeretnénk szimulálni több csomópontos környezetet.
  • K3s – A Rancher által fejlesztett, könnyített Kubernetes disztribúció, amely alacsony erőforrásigényű környezetekben is jól fut. ARM architektúrán is kiválóan működik, például Raspberry Pi-n.
  • K3d – A K3s konténeres változata, amely lehetővé teszi, hogy a K3s klaszterek Docker konténerekben fussanak. Gyors, könnyen kezelhető és kiválóan alkalmas tanulásra vagy integrációs tesztekre.

A kubectl használata

A Kubernetes vezérlőparancsokat a kubectl eszközön keresztül adhatjuk ki. Ez a parancssori eszköz elengedhetetlen a klaszterek konfigurálásához és menedzseléséhez. A használata a Kubernetes kezelésben és jövőben is központi szerepet fog kapni, így érdemes alaposan megismerni.

A kubectl az alábbi helyen tárolja a konfigurációs fájlokat: $HOME/.kube/config. Ez a fájl tartalmazza az elérhető cluster-ek címeit (endpoint), hitelesítési adatokat, valamint az úgynevezett kontektsusokat (context).

Egy kontextus egy adott klasztert és a hozzá tartozó felhasználói hitelesítő adatokat jelenti. Ezzel a paranccsal például átválthatsz egy másik klaszterre:

kubectl config use-context <cluster-neve>

Ez különösen hasznos, ha több cluster-el dolgozol egyszerre, például egy helyi fejlesztési és egy éles felhős környezettel.

Felhőspecifikus CLI eszközök

Minden nagyobb felhőszolgáltató kínál saját parancssori eszközt, amellyel kezelhetjük a Kubernetes klasztereket:

  • gcloud – Google Cloud CLI
  • aws – AWS CLI
  • az – Azure CLI

Ezek az eszközök lehetővé teszik, hogy helyben kezeljük a felhőben futó Kubernetes környezeteket, beleértve a klaszterek létrehozását, skálázását és törlését.

Saját cluster építése kubeadm segítségével

Ha kézzel szeretnél Kubernetes klasztert építeni, a kubeadm az egyik legnépszerűbb és a közösség által ajánlott megoldás. A telepítés folyamata egyszerű:

  1. A „központi agy”-ban futtasd: kubeadm init
  2. A munkavégző csomópontokon vagy redundáns vezérlőcsomópontokon: kubeadm join

A kubeadm lehetővé teszi, hogy rugalmasan telepítsük a Kubernetes cluster-t különböző környezetekben, akár fizikai gépekre, akár felhőalapú infrastruktúrára.

Egyéb telepítési eszközök

Számos további telepítési lehetőség áll rendelkezésre, amelyek más-más célcsoportot és igényt szolgálnak ki:

  • kubespray – Ansible-alapú, jól skálázható telepítési eszköz.
  • kops – Kifejezetten AWS-re optimalizált, de más platformokon is működik.

Fontos megjegyezni, hogy ezek az eszközök eltérő fejlettségi szinttel és támogatottsággal rendelkeznek. Némelyik idővel népszerűvé válik, másokat a közösség elhagyhatja.

Összefoglalás

A Kubernetes telepítése ma már többféle módon is megvalósítható, kezdve a felhőszolgáltatók által nyújtott egyszerű megoldásoktól egészen a teljesen testreszabható, kézi telepítésig. A választás attól függ, milyen céllal és környezetben szeretnéd használni a klasztert. A tanuláshoz és gyakorláshoz a Minikube vagy MicroK8s, Kind kiváló belépőt nyújt, míg komolyabb környezetekhez a kubeadm vagy felhőszolgáltatói cluster-ek jelenthetik a megfelelő irányt.

Ugye már ki is gondoltad, melyikkel kezded?

k8s-innovation-1

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

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

| Olvasási idő: 2 perc |

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

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

Mi jellemzi ezt az innovációt?

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

Miért fontos ezt tudni?

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

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

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

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

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

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

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

docker-model-runner

Helyi AI modell futtatása Dockerrel

, , , , , ,

| Olvasási idő: 3 perc |

A Docker a konténerizáció területén az egyik legismertebb név. Azonban az elmúlt években kicsit beleszürkült a technológia világába. Egészen eddig! Most azonban olyan dologgal álltak elő, amely igen ígéretes lehet. A Docker legújabb újítása, a Docker Model Runner, egy izgalmasnak tűnő fejlesztés a generatív mesterséges intelligenciával foglalkozó szakemberek számára. A funkció lehetővé teszi nagy nyelvi modellek (LLM-ek) futtatását helyben, közvetlenül a fejlesztői gépen, anélkül hogy konténert kellene indítani. A cél: gyorsabb tesztelés, egyszerűbb integráció és fejlesztőbarát működés.

A Model Runner a 4.40-es Docker Desktop verzióval vált elérhetővé, egyelőre béta állapotban. A technológia a llama.cpp open-source projektet használja a modellek futtatásához, amely már eddig is népszerű volt a könnyen telepíthető, GPU-gyorsított helyi inferencia miatt. A Docker ezt a megközelítést emelte magasabb szintre, és beépítette a megszokott fejlesztői eszköztárba.

A Model Runner célja, hogy megoldást nyújtson a fejlesztők előtt álló leggyakoribb kihívásokra:

  • töredezett AI eszközkészletek,
  • hardverkompatibilitási problémák,
  • lassú iterációs ciklusok,
  • felhőalapú szolgáltatásokra való túlzott támaszkodás.

Ezeket a problémákat orvosolja egy integrált, egyszerűen használható megoldással, amelyet közvetlenül a fejlesztők gépére szántak.

A Model Runner használatához nincs szükség konténerre: a modellek közvetlenül a gazdagépen futnak, miközben OpenAI API-kompatibilis felületet biztosítanak. Ez azt jelenti, hogy ha már építettél alkalmazást OpenAI API-ra, akkor ezt szinte változtatás nélkül használhatod helyi modellekkel is.

Az új CLI-parancsok – például docker model pull, docker model run, docker model list – lehetővé teszik, hogy egyszerűen letölts, futtass és kezelj modelleket. A modellek OCI Artifacts formátumban érhetők el, amely biztosítja a verziókövetést és a CI/CD pipeline-okba való integrációt.

Különösen érdekes a GPU-gyorsítás támogatása Apple Silicon alapú gépeken (M1–M4), így a fejlesztők teljesítményveszteség nélkül dolgozhatnak akár több milliárd paraméteres modellekkel is. Jelenleg a Docker Model Runner kizárólag Mac gépeken érhető el, de a Windows támogatás is várható a közeljövőben.

A Docker olyan partnerekkel dolgozik együtt a Model Runner fejlesztésén, mint a Google, Hugging Face, Qualcomm, Continue és Dagger. Ez azt jelzi, hogy a cél nem csupán egy technikai funkció bevezetése, hanem egy AI-fejlesztési ökoszisztéma kialakítása, amely mélyen integrálódik a meglévő fejlesztői eszközökhöz.

A Docker ezzel a lépéssel hivatalosan is belépett a helyi AI fejlesztői eszközök világába. Ez a funkció hatékony megoldást kínál mindazok számára, akik gyorsan szeretnének AI prototípusokat építeni, és nem szeretnének felhőalapú szolgáltatásokra támaszkodni a fejlesztési fázisban.

A Model Runner különösen ajánlott fejlesztőknek, adattudósoknak, ML mérnököknek, és bárkinek, aki szeretné kihasználni a helyi inferencia előnyeit, miközben a Docker kényelmes és ismerős eszköztárát használja.

Ha szeretnél részletesen foglalkozni a témával, érdemes kipróbálni a Model Runnert a gyakorlatban is – a Docker már most lehetőséget ad arra, hogy egyéni AI fejlesztési workflow-okat építsünk teljesen helyben, saját gépen.

k8s-terminology-01

Fontos alapfogalmak a Kubernetes világában

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

| Olvasási idő: 3 perc |

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

Mi is az a Kubernetes?

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

Pod

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

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

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

Namespace – névterek

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

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

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

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

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

A leggyakoribb operátor típusok:

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

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

Custom Resource Definitions (CRD)

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

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

Szolgáltatások – Service

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

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

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

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

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

Taints és tolerations

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

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

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

k8s-arch-03

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

, , , , , , , , , ,

| Olvasási idő: 3 perc |

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

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

Erre ad nekünk választ a Kubernetes.

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

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

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

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

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

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

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

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

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

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

Minden worker node két fő komponenst futtat:

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

Rugalmas kommunikáció – nem csak Linuxon

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

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

docker-challanges-2

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

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

| Olvasási idő: 3 perc |

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?

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

| Olvasási idő: 3 perc |

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

, , , , , , , , , ,

| Olvasási idő: 4 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?

oci2

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

, , , , , , , , , ,

| Olvasási idő: 4 perc |

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

ecr1

AWS ECR: Hogyan tárolj és kezelj konténerképeket?

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

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

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

Ebben a cikkben bemutatjuk az AWS Elastic Container Registry-t (ECR), amely egy teljes mértékben felügyelt konténerképtároló szolgáltatás az AWS-ben. A cikk segít megismerni az alapokat és megpróbál megmutatni olyan fejlettebb funkciókat, mint az integrációs lehetőségek és az automatizált életciklus kezelés.

Mi az AWS ECR?

Az AWS Elastic Container Registry (ECR) egy (PaaS) kategóriába tartozó, felügyelt szolgáltatás, amely lehetővé teszi Docker és OCI (Open Container Initiative) kompatibilis konténerképek tárolását, kezelését és megosztását.

Az ECR maga a szolgáltatás elnevezése. Ezen belül történk a varázslás, hiszen ezen belül repository-kat hozhatunk létre. Egy repository egy olyan tárhely, amely egy adott alkalmazás konténerképeit és azok különböző verzióit (változatait) tartalmazza.

Az AWS ECR struktúrája

Az alábbi hierarchikus struktúria szemlélteti az ECR-t:

AWS ECR (szolgáltatás)
│
├── Repository_1 (pl. Python alkalmazás)
│ ├── python-app:2.0.0
│ ├── python-app:1.0.0
│ ├── python-app:latest
│
├── Repository_2 (pl. NodeJs alkalmazás)
│ ├── node-app:1.1.0
│ ├── node-app:1.0.0
│ ├── node-app:latest

  • ECR: maga a felügyelt szolgáltatás
  • ECR repository: a konténerképek tárolási helye
  • Repository: tartalmazza a különböző alkalmazás verziók konténerképeit

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

Első lépés, hogy fejlesztenem kell egy alkalmazást, amely docker vagy OCI kompatibilis. Ehhez találsz példát az én GitHub kódjaim között is.

Miután elkészítetted a képfájlt a számítógépeden, vagy valamilyen pipeline segítségével, nincs más dolgod, mint bejelentkezni ECR-be és feltölteni oda az aktuális konténerkép verzióját.

Ahhoz, hogy egy Docker-képet feltölts egy ECR repository-ba, kövesd az alábbi lépéseket:

  • Hitelesítés az AWS ECR-ben:
aws ecr get-login-password --region <AWS_REGION> | docker login --username AWS --password-stdin <AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com
  • Kép címkézése az ECR repository URL-jével:
docker tag sajat-kontener:latest <AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com/node-app:latest

docker tag sajat-kontener:latest <AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com/node-app:1.2.0
  • Kép feltöltése az ECR-be:
docker push <AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com/node-app:latest

docker push <AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com/node-app:1.2.0

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

Az ECR-ben tárolt képeket könnyen használhatod AWS szolgáltatásokkal, például az ECS vagy az EKS segítségével.

Ha egy Amazon ECS clusterben szeretnél futtatni egy konténert az ECR-ből, hozz létre egy Task Definition-t, amely tartalmazza az ECR repository URL-jét:

"containerDefinitions": [
 {
 "name": "node-js-alkalmazas",
 "image": "<AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com/node-app:latest",
 "memory": 512,
 "cpu": 256
 }
]

Életciklus és tárhely kezelés

Amikor nagyon sok alkalmazásunk konténerképeit tároljuk és ezekből rendszeresen készítünk új verziókat, előbb-utóbb azzal szembesülünk, hogy a régi és nem használt verziók sok helyet foglalnak. Ez pedig azt jelenti, hogy sok tárhelyet foglalnak, amely növeli a költségeinket.

Szerencsére az ECR támogatja az életciklus-szabályok (Lifecycle Policies) használatát, amelyek segítenek automatikusan törölni a régi vagy nem használt konténerképeket.

Ezeket szabályokon keresztül tudjuk megtenni. Egy-egy ilyen szabályhoz csupán néhány paramétert kell megadnunk, majd a szabályok között felállítanunk egy prioritási sorrendet, a többit az AWS elvégzi helyettünk.

  • Példa 1: egy olyan szabályra, amely csak az utolsó 5 képverziót tartja meg, és törli a régebbi verziókat: 
{
 "rules": [
 {
 "rulePriority": 1,
 "description": "Tartsuk meg az utolsó 5 verziót",
 "selection": {
 "tagStatus": "tagged",
 "countType": "imageCountMoreThan",
 "countNumber": 5
 },
 "action": {
 "type": "expire"
 }
 }
 ]
}

  • Példa 2: Összetett példa: A ‘latest’ verzió soha nem törlődik, de minden más 90 nap után törlődik:
{
 "rules": [
 {
 "rulePriority": 1,
 "description": "A 'latest' verzió soha nem törlődik",
 "selection": {
 "tagStatus": "tagged",
 "tagPrefixList": ["latest"]
 },
 "action": {
 "type": "retain"
 }
 },
 {
 "rulePriority": 2,
 "description": "Minden más kép törlődik 90 nap után",
 "selection": {
 "tagStatus": "any",
 "countType": "sinceImagePushed",
 "countUnit": "days",
 "countNumber": 90
 },
 "action": {
 "type": "expire"
 }
 }
 ]
}

AWS ECR integráció más AWS szolgáltatásokkal

Az AWS ECR könnyen integrálható más AWS szolgáltatásokkal, mint például:

Amazon ECS (Elastic Container Service)

Az ECR közvetlenül támogatja az ECS Fargate és ECS EC2 alapú futtatási módokat. Ha egy ECS clusterben szeretnéd futtatni az ECR-ben tárolt képeket, egyszerűen megadhatod az ECR repository URL-jét a Task Definition-ben.

Amazon EKS (Elastic Kubernetes Service)

Ha Kubernetes-t használsz az AWS-en, akkor az ECR tökéletes tárhely lehet a Kubernetes Pod-ok számára. Az alábbi módon hozhatsz létre hitelesítési „secret”-et, amely lehetővé teszi a Kubernetes számára az ECR repository elérését:

kubectl create secret docker-registry ecr-secret \
 --docker-server=<AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com \
 --docker-username=AWS \
 --docker-password=$(aws ecr get-login-password) \
 --namespace=default

AWS Lambda konténer támogatással

Ha AWS Lambda-t szeretnél konténer alapú csomagként használni, akkor az ECR egy megbízható tárhely lehet az ilyen konténerképek számára.

Összegzés

Az AWS ECR egy igazán sokoldalú konténerképtároló szolgáltatás, amely lehetővé teszi a konténerizált alkalmazások hatékony kezelését. Az életciklus-kezelés segít optimalizálni a tárhely felhasználást, így elkerülhető a felesleges konténerképek felhalmozódása. Emellett az ECR könnyedén integrálható más AWS szolgáltatásokkal, így egy teljes körű konténerizált fejlesztési és futtatási (teszt, éles, stb.) környezetet kínál.

Neked is van olyan ötleted, amelyet konténerképben lehetne ECR-en tárolni? 🚀

Load More