Konténerizáció

Az elkészült alkalmazásunkat sokféleképpen közzé tudjuk tenni. Fejlesztői szempontból látszólag talán a legkönnyebb megoldás az, hogy egy ZIP fájlt odaadunk az alkalmazásunkból és majd az üzemeltetés megoldja a telepítését és beüzemelését. Ezen megoldás rejtett problémái hamar meg tudnak mutatkozni problémák esetén, például ha valami függőségünk beüzemelése nagyon nem triviális. Ebben az esetben elkerülhetetlen, hogy kérdések legyenek. De nem ez a legnagyobb hátrány, hanem az, hogy egy ilyen módon terjesztett alkalmazás beüzemelésének nincs univerzális módja. Ahány alkalmazás, annyiféleképpen kell beüzemelni és működésre bírni, a folyamat automatizálhatósága is kérdéses és szinte biztos, hogy egy egyedi megoldást fog igényelni.

Éppen ezért született meg az igény az egyszerűen közzétehető és beüzemelhető alkalmazások iránt. Az egész folyamat talán a virtuális gépekkel indult. Egy virtuális gépbe telepített alkalmazást üzemelteni és frissíteni nagyon egyszerű, mivel csak a lemezképet kell frissíteni. Azonban ezen megoldás hátránya, hogy egy egész virtuális gépet kell emulálni operációs rendszerrel együtt, illetve az alkalmazás méretére rárakódik a teljes operációs rendszer.

Ezen igények mentén született meg a konténerizáció, amit a Docker tett igazán népszerűvé. Itt fontos megjegyezni, hogy a Docker nem az egyetlen ilyen megoldás. De mi is az a konténerizáció? A konténerizáció egy szoftver telepítési és üzemeltetési módszer, ami lehetővé teszi az alkalmazások és azok függőségeinek az egybecsomagolását és futtatását különböző környezetekben. A módszer alapja a konténer, ami a futtatni kívánt kódot, az ahhoz szükséges futtatókörnyezetet, rendszereszközöket és programkönyvtárakat egyetlen hordozható és futtatható egységbe csomagolja.

A konténerizáció nem virtualizáció, vagyis nem emulálunk egy teljes virtuális gépet. Ennek előnye, hogy csak minimális erőforrás többlettel jár egy konténer futtatása. Ezen a ponton gondolhatnánk, hogy ezen megoldás kevésbé biztonságos, mint egy virtuális gép, de nem ez a helyzet. A konténerek egymástól izolált környezetben futnak és nem látják egymás folyamatait. Ezt a konténer alatt lévő operációs rendszer oldja meg.

Itt viszont némi problémába ütköztünk, mivel a különböző operációs rendszerek izolációs képességei és megoldásai eltérnek és sokszor nem kompatibilisek egymással. Ennek köszönhetően a Linux alapú megoldások szinte egyeduralkodók, olyan szinten, hogy a Docker Windows-on egy Linux alapú virtuális gépben futtatja a konténereket és nem véletlen született meg a WSL.

Docker vagy nem docker

A konténerizációt a Docker tette népszerűvé, azonban nem csak ez az egyetlen megoldás. Az alternatív megoldások terjedését a Docker licenc feltételei tették szükségessé és indokolttá. A Docker üzleti célú felhasználásra és fejlesztésre sem ingyenes termék. Egy teljesen ingyenes és szabad, 99%-ban kompatibilis implementációja a Podman, ami ugyanazokat a parancsokat és argumentumokat használja, de nem teljesen kompatibilis a Docker-al. Ez az esetek többségében nem okoz problémát, de ha igen, akkor tapasztalatom szerint rendesen meg tudja keseríteni az ember életét, mivel jóval kevesebb dokumentáció és szakirodalom áll rendelkezésre a probléma elhárításához. És akkor még a fejlesztői eszközök támogatottságáról nem is beszéltem.

A Docker egyfajta de-facto szabvánnyá nÅ‘tte ki magát és annak ellenére, hogy a Podman szinte mindenben kompatibilis vele, fejlesztÅ‘i eszközök tekintetében szinte nulla az integrációja.¹ Éppen ezért a könyv ezen részében is dockert fogunk használni. Opcionálisan egy továbbfejlesztési ötlet lehet a rendszer podman-es beüzemelése.

A fejlesztői környezet

A Docker Windows használatához szükségünk van egy WSL alapú Linux disztribúcióra. Egy ilyet hoz magával a Docker Desktop (https://www.docker.com/products/docker-desktop/) is, azonban a Linux rendszerekkel való átjárhatóság szempontjából itt kizárólag csak parancssorra fogok támaszkodni egy Debian alapú rendszeren.

Ennek oka az, hogy a Debian alapú rendszerek esetén az operációs rendszer nem szállítja magával csomagoltan a .NET-et, így lényegében olyan verziót telepíthetünk a Microsoft oldaláról, amilyet szeretnénk. Ubuntu esetén az Ubuntu szállítja magával a .NET-et a csomagkezelőjében, ami nem biztos, hogy a legújabb.

A WSL beüzemelése viszonylag egy egyszerű folyamat. Egy adminisztrátori powershell konzolból az alábbi parancsok segítségével tudjuk megtenni:

 dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
 dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

Ezt követően újra kell indítanunk az operációs rendszerünket, majd telepítenünk egy WSL disztribúciót. Jelen esetben ez a Debian lesz. Ez parancssorból az alábbi parancsokkal telepíthető:

wsl.exe --set-default-version 2
wsl.exe --update
wsl.exe --install -d Debian

Mivel verziónként eltér, hogy milyen függőségek kellenek a Docker és .NET beüzemeléséhez, ezért csak a hivatalos dokumentációt linkelem itt, amit követve telepíteni tudjuk mindkét szoftvert. A Docker aktuális Debian leírása a https://docs.docker.com/engine/install/debian/ címen található meg. .NET esetén pedig a https://learn.microsoft.com/en-us/dotnet/core/install/linux-debian címen találjuk az utasításokat.

Ha minden jól ment, akkor ellenőrizhetjük az alábbi parancsok segítségével, hogy működőképesek-e:

dotnet --version
docker --version

Ezt követően a dotnet parancs segítségével fordítsuk le Linuxon is az alkalmazásunkat, majd futtatva győződjünk meg arról, hogy Linux-on is működőképes az alkalmazás. Az esetek többségében módosítás nélkül az lesz, ha nem használtunk natív, platformfüggő kódot. Ha van platformfüggő vagy natív kódunk, akkor azt először át kell vinni Linuxra és a C# kódunkban meg kell oldanunk, hogy operációs rendszer függvényében melyik binárist töltse be.

NuGet csomagoknál a natív függőségek problémájába beleszaladhatunk. Egyes csomagok esetén, mint az SQLite, a NuGet disztribúció beépítetten tartalmazza a natív függőségeket minden platformra, míg más csomagok esetén, leginkább méret megfontolásból ezek szét vannak bontva és további csomag telepítése szükséges a Linux támogatáshoz.

A konténer elkészítése

Ha az alkalmazásunk probléma nélkül fut, akkor konténerizálhatjuk. A konténerizációhoz szükségünk lesz egy Dockerfile fájlra. Ez lényegében a konténer létrehozásához szükséges utasítások sorozata. A támogatott utasítások teljes referenciája a https://docs.docker.com/reference/dockerfile/ címen található.

A konténerizáció és .NET esetén két fő irány közül választhatunk: vagy mi készítjük el a konténert teljes egészében, vagy a Microsoft által biztosított Docker konténert bővítjük tovább az alkalmazásunkkal. Az első megoldás akkor lehet hasznos, ha natív kódra fordítjuk az alkalmazásunkat és a lehető legkisebb méretű konténert szeretnénk kapni.

A második megoldás pedig azért jó, mert kényelmesebb. Lényegében minden .NET verzió kiadáshoz készül egy konténer, így az alkalmazásunk újracsomagoláskor mindig a legfrissebb biztonsági frissítések benne lesznek a konténerben, míg az első megoldás esetén erről nekünk kell gondoskodnunk, de cserébe mindent személyre tudunk szabni, még a biztonsági rések számát és komolyságát is. Nem véletlen külön szakterület a konténerizáció.

Az, hogy melyik irányt érdemes választani, szituációfüggő. Jelen esetben a Microsoft konténerbővítés irányt választottam, mivel a könyv ezen fejezete igencsak hosszúra nyúlt már és ha még ebbe is beleásnánk magunkat, akkor csak egy újabb véget nem érő nyúlüregben találnánk magunkat.

Ha a konténerbővítés mellett döntünk, akkor is számos opcióból választhatunk. Azure és Ubuntu esetén létezik olyan konténer image, ami operációs rendszer függőségeket sem tartalmaz, így igazán apró méretűek, cserébe viszont csak és kizárólag a választott operációs rendszeren hajlandóak működni.

Méret és szolgáltatások tekintetében az Alpine alapú docker image-ek kínálják a legjobb választást. Ezen konténerek tartalmazzák az operációs rendszer függőségeket, de a lehető legminimálisabbra szorítva. Éppen ezért előfordulhat, hogy extra csomagokat kell telepítenünk, például, ha globalizációra támaszkodunk.

Az alkalmazásunk konténerizációjához szükséges Dockerfile a következő lesz:

# alap image
FROM mcr.microsoft.com/dotnet/aspnet:9.0-alpine AS runtime

# konténer metaadatok
LABEL maintainer="Maintainert mail <user@mail.com>"
LABEL version="1.0.0"
LABEL description="Image description"
LABEL vendor="Image vendor"

# nyelvi függőségek telepítése
RUN apk add --no-cache icu-libs

# Konténeren belül a /app mappába dolgozunk
WORKDIR /app

# Alkalmazás bemásolása
COPY ./UrlShortner.Web/bin/Release/net9.0/publish/ .

# Az alkalmazás a 80-as porton működik
EXPOSE 80

# Környezeti változók
ENV ASPNETCORE_URLS=http://+:80
ENV DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=false
ENV ASPNETCORE_ENVIRONMENT=Production

# user létrehozás, hogy az app ne root jogosultságokkal fusson a konténerben
RUN adduser -u 1000 -D appuser && \
    chown -R appuser:appuser /app

# user váltás
USER appuser

# alkalmazás belépési pontja
ENTRYPOINT ["dotnet", "UrlShortner.Web.dll"]

A fenti utasítássorozatból az egyik legfontosabb a RUN apk add --no-cache icu-libs, mivel ez telepíti a globalizáció működéséhez szükséges nyelvi csomagokat. Ezek hiányában az ASP.NET alkalmazásunk működésképtelen. A konténer, amit használunk, csak futtatásra képes és a publish folyamat eredményét pakolja bele a konténerbe, ezért mielÅ‘tt a docker image-et elkészítjük, a futtatható binárisoknak létezniük kell.

A másoláshoz használt COPY parancs mappák esetén mindent másol, ha specifikusan ki szeretnénk hagyni fájlokat vagy kiterjesztéseket, akkor azokat egy .dockerignore fájlban felsorolhatjuk. Jelen esetben az alkalmazás mellé nem kell a *.db fájlunk, ezért a .dockerignore-ba érdemes ezt beletenni.

A binárisok fordítását és a docker image készítést az alábbi két parancs segítségével tudjuk megtenni:

dotnet publish -c RELEASE
docker build -t urlshortner-web:latest .

A LABEL utasítások metaadatok megadására szolgálnak. Ezek közül a fájlban szereplÅ‘k az általánosan bevettek, de igazából bármilyen extra metaadat megadható. Ezek a docker inspect urlshortner-web:latest segítségével lekérdezhetÅ‘ek. A fájlnév esetén a latest egy Tag, ami az image verziójára hivatkozik a metaadatokon kívül. Bevett szokás, hogy a konténerünk legújabb verzióját a latest tag-el is publikáljuk, hogy az image használóinak a frissítési folyamatot megkönnyítsük.

Futtatás, compose

A fenti lépésekkel elkészült a konténerünk, de hogyan futtassuk? Természetesen a docker parancs segítségével tudjuk futtatni, megfelelÅ‘ paraméterekkel:

docker run -d -p 8080:80 -v $(pwd)/data:/app/data \ --name urlshortner-web-app urlshortner-web:latest

A fenti parancs a host számítógép 8080-as portját átirányítja a konténer 80-as portjára, majd elindítja a konténert. A -v egy kötetet csatol fel, mégpedig a jelenlegi könyvtár /data mappáját a konténer /data mappájába. Erre azért van szükség, mert valahova az adatbázist mentenie kell majd az alkalmazásunknak. A konténer /app mappája pedig csak olvasható.

Ez a fajta futtatás működőképes, de van ennek egy sokkal kényelmesebb módja, főleg akkor, ha több, egymástól független, de mégis összedolgozó alkalmazást szeretnénk egyszerre futtatni.

Erre találták ki a compose fájlt. A compose fájl egy YAML fájl, ami leírja a Docker számára, hogy melyik konténert hogyan és milyen beállításokkal kell futtatni és kényelmesebb megoldást biztosít a parancssori parancsokkal szemben, mert a compose fájl tartalma a docker compose up parancs segítségével elindítható abból a mappából, ahol a compose fájl van. Egy ilyen compose fájl több konténer együttes indítását is lehetÅ‘vé teszi. Compose fájlt nem szükséges kreálnunk, teljesen opcionális folyamat, de érdemes, mivel egy csomó hosting megoldás alapértelmezetten támogatja, így lényegében egy szövegfájllal a teljes futtató infrastruktúra kiépíthetÅ‘.

A korábbi docker run parancs docker compose szintaxisban:

services:
  web:
    image: urlshortner-web:latest
    container_name: urlshortner-web-app
    ports:
      - "8080:80"
    volumes:
      - ./data:/app/data
    restart: unless-stopped
    environment:
      - ASPNETCORE_ENVIRONMENT=Production
      - ConnectionStrings__DefaultConnection=Data Source=/app/data/Application.db

Itt extra annyi, hogy a restart: unless-stopped direktívával a konténer a rendszer vagy a docker indításával automatikusan futtatásra kerül, egészen addig, amíg explicit meg nem állítjuk a konténer futtatását. Ez egy különösen hasznos beállítás szolgáltatások automatizálásánál.

Az environment: szekcióban bármilyen környezeti változót felül tudunk írni. Éppen ezért, ha az alkalmazásunkat Docker segítségével tervezzük közzétenni, akkor célszerű a fontosabb konfigurációs beállításokat környezeti változóból felülírhatóvá tenni, mivel ezeket közvetlenül elhelyezhetjük a compose fájlokban. A ConnectionStrings__DefaultConnection környezeti változóval az app.config módosítása nélkül felülírhatjuk a kapcsolódáshoz használt DB beállításokat is.

A compose fájlt docker-compose.yml néven kell elneveznünk és a docker compose up -d parancssorból tudjuk elindítani, leállítani pedig a docker compose down parancs segítségével.

De hogy jutnak el a konténerek a cél gépre? Erre számos megoldás létezik. Az egyik a Docker által üzemeltetett DockerHub. Ez a https://hub.docker.com/ címen lelhető fel. Ide regisztrációt követően mi magunk is tölthetünk fel konténereket, amit aztán a compose fájl végrehajtásakor a docker automatikusan letölt majd. Ha nem szeretnénk a nagyvilágnak publikálni a konténereinket, akkor is számos opciónk van. Egy ilyen a Github. A Github rendelkezik egy Container Registry szolgáltatással, ahova privát konténereinket fel tudjuk tölteni, de lényegében bármilyen Container Registry kompatibilis szolgáltatást használhatunk erre a célra. A Github leírása a Container Registry szolgáltatásról a https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry címen található meg.

Ha a konténer hub megoldás abszolút nem játszik, akkor az image-ek exportálhatóak is a docker save parancs segítségével:

docker save urlshortner-web:latest | gzip > ./urlshortner-web-latest.tar.gz

Ez egy .tar kiterjesztésű fájlt kreál, amit érdemes tömöríteni. Ezt a tömörített archívumot bármilyen más módon eljuttathatjuk a cél gépre, ahol kitömörítés után a docker load parancs segítségével importálni tudunk:

gzip -d -c ./urlshortner-web-latest.tar.gz > ./urlshortner-web-latest.tar
docker load -i ./urlshortner-web-latest.tar

Tags compose, docker, podman