Azure Container Apps

Sétáló Patrik

Systems Engineer, Microsoft

patrik.setalo@alef.com

Egy újabb konténeres szolgáltatás lépett ki a Preview fázisból, így most már GA-ban (General Availability) is elérhető az Azure Container Apps. Mit is tud ez a szolgáltatás és mi a különbség a hozzá hasonló ACI (Azure Container Instance) között?

  • A Container Instance egy egyedülálló izolált pod/konténer, ami azonnal rendelkezésünk áll
  • A szolgáltató úgy hivatkozik a Container Instance-ra, mint egy alacsonyabb szintű „building block” opció, a Container Apps-hez képest
  • A Container Instance nem tartalmaz load-balancing-ot, illetve nem tud skálázódni

A Container Apps lehetővé teszi az alkalmazás kód végrehajtását, ami bármilyen konténerbe be lehet csomagolva. A Container Apps magával hozza azt az előnyt, hogy a hátunk mögött hagyhatjuk a felhős infrastruktúra menedzselésével és a konténer orkesztrációs (Kubernetes) kezelésével kapcsolatos gondokat.

A következő kis demón keresztül láthatjuk az Azure Container Apps használatát, funkcióit.

A történet az Azure Portalon kezdődik, a keresőbe írjuk be, hogy Container Apps és válasszuk ki az Azure Container App-ot, majd válasszuk ki melyik előfizetésbe, RG-be és Azure régióba szeretnénk deployolni az első Container Appunkat, valamint adjunk neki egy nevet. Ha ezekkel mind megvagyunk, kattintsunk a Container Apps Environment-nél a Create New gombra.

A konténer appot futtató környezetünknél a Basics fülön szintén adjunk magának a környezetnek egy nevet, illetve a demóban nem lesz szükségünk arra, hogy zóna redundánsok legyenek az appjaink, ezért a pöttyöt rakjuk a Disabled körbe.

A Monitoring fülön, ha előtte nem hoztunk létre egy Log Analytics Workspace-t az Azure Container App-nak, akkor itt ezt szintén megtehetjük. Célszerű újat létrehozni, nehogy keveredjenek a logok más szolgáltatások logjaival a Workspace-en belül.

Végül a hálózati részen eldönthetjük, hogy az appjaink saját VNET-et használjanak vagy sem. Abban az esetben, ha itt nem határozzuk meg, hogy egyedi VNET-et használjon a Container App Environment és a benne lévő Container Appok, úgy a rendszer létre fog nekünk hozni egy VNET-et, de ahhoz semmi hozzáférésünk nem lesz. A Virtual IP lehetőségnél 2 opció közül választhatunk, ha az Externalt választjuk az alkalmazásaink publikusan elérhetők lesznek, míg az Internal esetében a rendszer egy Azure Internal Load-balancert helyez az alkalmazások elé és a belső IP címek az egyedi VNET-ben meghatározott IP cím tartományból kerülnek kiosztásra.

Miután létrehoztuk a Container App környezetünket a következő beállítás, amit meg tudunk adni, az maga az alkalmazásnak a beállításai. Még nem hoztunk létre se repository-t, ahova felpusholtuk a kódunkat, nem rendelkezünk konténer image-vel, szóval kattintsunk a Create+Review gombra.

Miután sikeresen létrehoztuk az első Azure Container Apps környezetünket és egy alap alkalmazást, nyissuk meg az alkalmazásunk kódját a Visual Studio Code-ban.

Nyissunk egy terminál ablakot a VS Code-ban, majd először futtassuk le a git init parancsot.

A következő parancs, amit le kell futtatnunk a git add -A (a mappa összes tartalmát hozzáadja).

Ebben a lépésben commitolunk a git commit -m („push code to Azure Container Registry) parancs megadásával. (A cikk írása közben vettem észre, hogy valójában nem ACR-be töltjük fel a kódot, hanem egy Azure DevOps git alapú repository-be). ?

A következő paranccsal kijelöljük, hogy hova szeretnénk feltölteni a kódunkat. A parancs, amit meg kell adnunk az a következő: git remote add origin https://repositorynk-url-je.com/repository/app

Végezetül felpusholjuk a kódunkat a git push -u origin -all paranccsal.

Miután felpusholtuk a kódunkat a megfelelő repo-ba, az Azure DevOps-ban az alkalmazás projektjében menjünk be a beállításokba, majd adjunk hozzá 2 Service Connection-t. Az egyik maga az Azure előfizetésünk, a másik pedig az Azure Container Registry lesz, ahol tároljuk magát a konténer image-t.

A 2 service connection hozzáadása után menjünk be a Repos almenü alatt a Files-ba, majd készítsük el a Build pipeline-unkat a Set up build gombra kattintva.

Ennél a lépésnél válasszuk ki a Docker (Build and push an image to Azure Container Registry) opciót, majd lépjünk tovább.

Válasszuk ki melyik repo-ból készítse el a konténer image-ünket a build pipeline, adjunk neki egy nevet, illetve adjuk meg hol találja a rendszer a Dockerfile-t, ami alapján elkészíti a konténer image-t.

Miután mindent rendben találunk a YAML fájlunkban, ami alapján elkészül a Build pipeline úgy kattintsunk a Save gombra.

Commit üzenetnek adjunk meg valamit, illetve válasszuk ki, hogy a meglévő master branch-re commitoljon a rendszer vagy hozzon létre egy újat, miután ezt eldöntöttük kattintsunk a Save and run gombra.

Amennyiben minden rendben zajlott és nem volt hiba a YAML fájlunkban, úgy kicsivel több, mint 1 perc elteltével el is készült a konténer image-ünk.

Miután sikeresen elkészült a konténer image-ünk, navigáljunk vissza a Container App-ba és a Revision managementben, adjuk hozzá az újonnan létrehozott konténer image-t. Itt lehetőségünk van a futó konténereket ki/bekapcsolni, beállíthatjuk, hogy a hálózati forgalom hány %-át fogadja az adott konténer.

Ebben a lépésben hozzáadjuk az új konténer image-t a Container App-hoz. A Basics fülön ki tudjuk választani, hogy hol tároljuk az image-t, ami lehet ACR vagy más egyéb konténer image tároló. Továbbá meg tudjuk határozni, hogy mennyi erőforrást adunk az adott konténernek (CPU és RAM).

Lehetőségünk van dinamikus skálázási szabályokat megadni, a demóban a konkurrens http kapcsolatok száma alapján skálázódik.

Végső lépésként ellenőrizzük, hogy valóban működik a konténerünk. Ha mindent jól csináltunk, akkor sikeresen deploy-oltuk első Azure Container App-unkat.

Összességében az Azure Container Apps sok hasonló funkcióval rendelkezik, mint a Kubernetes, viszont cserébe kevésbé komplex.

Szeretnél többet tudni?

Vedd fel velünk a kapcsolatot az alábbi elérhetőségen:

Sétáló Patrik
Systems Engineer, Microsoft
+36-30/333-1437
Patrik.Setalo@alef.com