Menu

Docker

docker-model-runner

Helyi AI modell futtatása Dockerrel

, , , , , ,

| Olvasási idő: 2 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.

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

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

Verified by MonsterInsights