Azure Container Apps
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