Hogyan hosztoljunk Docker-lemezkép-tárolót és építsünk Docker-lemezképeket saját üzemeltetésű GitLab példánnyal Ubuntu 20.04-en

Konténerizációs technológia hatalmasat fejlődött a szoftverfejlesztési technológiai térben, mint az alkalmazások felhőkörnyezetben történő csomagolásának és telepítésének leginkább elfogadott módszere. Ezt a folyamatos integráció (CI) és a folyamatos telepítés (CD) iránti igény tette szükségessé, amelyek meghatározó aspektusai a DevOps-nak. A szoftverfejlesztők és mérnökök konténereket használnak a szoftverarchitektúra CI/CD aspektusának megvalósításához. A konténer lényegében egy teljesen becsomagolt, hordozható és önálló számítástechnikai platform. Bár számos konténerplatform létezik a weben, a Docker a legelterjedtebb.

A Docker egy nyílt forráskódú konténerplatform, amely hatékonnyá és kiszámíthatóvá teszi a fejlesztést. A Docker egy nyilvános Docker-lemezkép-tárolót kínál, amely elérhető a Docker Hub oldalon. Számos nyílt forráskódú Docker-lemezképet tartalmaz a leggyakoribb implementációkhoz, amelyeket letölthet és használhat. Mivel ez egy nyilvános tároló, Ön is szabadon hozzáadhatja saját Docker-lemezképeit, hogy megossza azokat a nyilvánossággal. Ha azonban privát/saját tulajdonú kóddal rendelkezik, előfordulhat, hogy fizetnie kell egy privát lemezkép-tárolóért, vagy saját lemezkép-tároló szolgáltatást kell kiépítenie. Itt jön a képbe a GitLab.

GitLab egy webalapú Git tároló, amely több mint egy verziókezelő eszköz. DevOps eszközöket biztosít a folyamatos integrációhoz és telepítéshez, a hibakövetéshez, Docker-lemezkép-regiszterekhez és sok máshoz. Három lehetőséget kínál: GitLab Community Edition (CE), GitLab Enterprise Edition (EE) és GitLab SaaS. A GitLab CE és a GitLab EE saját üzemeltetésű megoldások, amelyek lehetővé teszik a GitLab példány letöltését, telepítését és kezelését saját magának. A GitLab SaaS szolgáltatást a GitLab Inc. üzemelteti, így nem kell aggódnia semminek a telepítése miatt a használatához.

Egy korábbi útmutatóban megmutattuk, hogyan állíthat be egy GitLab példányt egy CloudSigma szerveren, és hogyan hosztolhatja saját Git tárolóját. Azt is megmutattuk, hogyan valósítson meg folyamatos integrációs folyamatokat a GitLab runner segítségével, hogy automatikusan felépítse és lefuttassa a teszteket minden új commit esetén. Ha még nem olvasta az említett útmutatókat, kérjük, tegye meg, mivel ezek az útmutató építőkövei.

Ebben az útmutatóban bemutatjuk, hogyan építhet fel egy egyszerű Docker-lemezképet, és hogyan hosztolhatja azt egy saját üzemeltetésű GitLab példányon (függetlenül attól, hogy a Community Edition-t vagy az Enterprise Edition-t használja – a lépések menete ugyanaz).

Előfeltételek

Ahhoz, hogy az útmutató minden lépését követni tudja, kérjük, győződjön meg arról, hogy rendelkezik egy GitLab CI runner-rel és egy saját üzemeltetésű GitLab szerverrel az alábbiakban leírtak szerint.

1. Egy biztonságos GitLab szerver

Ezt a forráskód tárolására, CI/CD feladatok futtatására és a Docker-lemezkép-regiszter hosztolására fogjuk használni. Rendelkeznie kell egy olyan szerverrel, amely legalább 2 CPU maggal és 4GB of RAM-mal rendelkezik, ahogy azt a GitLab javasolja egy saját üzemeltetésű GitLab példány telepítéséhez. Szüksége lesz egy regisztrált domain névre is, amely a szerverre mutat, mivel ezt fogjuk használni egy Let’s Encrypt SSL-tanúsítvány beszerzéséhez a szerver biztosítására. Az alábbiakban talál néhány linket, amelyeket követve beállíthat egy saját üzemeltetésű GitLab példányt.

• Regisztráljon egy domain nevet az Ön által választott tetszőleges domain-regisztrátornál, és irányítsa azt a CloudSigma-ra.
• Kövesse ezt az útmutatót az Ubuntu szerver kezdeti beállításához, egy nem-root felhasználó hozzáadásához, valamint az Ubuntu UFW tűzfalának engedélyezéséhez.
• Végezetül kövesse ezt a leírást egy saját üzemeltetésű GitLab példány telepítéséhez és konfigurálásához.

2. Egy GitLab CI runner

A GitLab CI runner szükséges az automatizált feladatok futtatásához a tesztesetekhez. A(z) hogyan állítsunk be GitLab folyamatos integrációs folyamatokat Ubuntu 20.04-en című útmutató áttekintést nyújt a GitLab CI szerverről, és megmutatja, hogyan indíthat el feladatokat. Kövesse az útmutató lépéseit a GitLab CI runner szolgáltatás beállításához, ha még nem tette meg. Az útmutató tartalmaz egy Node.js demó alkalmazást tesztesetekkel – ezt fogjuk használni ebben az útmutatóban.

Most pedig kezdjük el!

1. lépés: Privilegizált GitLab CI Runner konfigurálása

A GitLab CI Runner beállításáról szóló útmutatóban egy GitLab runnert konfiguráltunk a sudo gitlab-runner register parancsot, amely lehetővé tette számunkra a szükséges paraméterek interaktív hozzáadását. Bár ez működött a korábbi használati esetünkben, ami a buildek és tesztek futtatása volt izolált Docker konténerekben, előfordulhat, hogy nem kezeli a Docker-képek építését. A Docker-képek építéséhez a runnernek teljes hozzáféréssel kell rendelkeznie a Docker szolgáltatáshoz. Ezt a konfigurációt a hivatalos docker-in-docker kép használatával érheti el a feladatok futtatásához. Egy ilyen konfiguráció magában foglalja a runner felruházását egy privilegizált végrehajtási móddal.

Bár a privilegizált végrehajtási mód megadása szükséges a Docker-képek építéséhez, ez biztonsági kockázatokkal jár. Ez azért van, mert megszünteti a konténerek biztonsági előnyeit. Gondolhatná, hogy a többi Docker runner biztonságos, de azoknál is ugyanazok a problémák merülnek fel, mint ahogy azt leírják a hivatalos Docker dokumentációban.

Létrehozunk egy másik runnert privilegizált végrehajtási móddal. Ez a fent említett biztonsági következmények miatt egy projektspecifikus runner lesz. Ez fogadja majd a feladatokat a Node Pipeline projektből, amelyet a hogyan állítsunk be folyamatos CI pipeline-okat a GitLab segítségével című útmutatóban hoztunk létre.

Az első dolog, amit tennie kell, annak ellenőrzése, hogy a Shared Runners le vannak-e tiltva a projektben. A Node Pipeline projekt oldalán kattintson a Settings lehetőségre a bal alsó menüben, majd válassza a CI/CD lehetőséget az almenüben:

Keresse meg az Expand gombot a Runners szekcióban, és kattintson rá az elérhető runnerek részleteinek megjelenítéséhez:

Kattintson a kapcsolóra a Disable Shared Runners lehetőséghez ennél a projektnél. Ha az előző részben hozzáadott egy projektspecifikus runnert, azt is tiltsa le. Egy privilegizált projektspecifikus runnert fogunk hozzáadni a projekt feladatainak futtatásához. Ez garantálja, hogy nem kapunk build hibákat abban az esetben, ha a GitLab véletlenszerűen olyan runnerekhez rendel feladatokat, amelyek nem lettek privilegizált végrehajtási móddal regisztrálva. A fenti képernyőképen, a Specific runners fül alatt látható a projekt regisztrációs tokenje. Jegyezze fel, mert az alábbiakban szüksége lesz rá.

Megjegyzés: Egy projektspecifikus runner más projektekhez is hozzárendelhető az Admin panel > Runners szekcióból. Ha kiválaszt egy runnert a runnerek listájából, a runner konfigurációs oldalára jut. Görgessen le a Restrict projects for this runner:

Itt az ideje megnyitni a terminált. Ha még nem hajtotta végre a lépéseket a hogyan állítsunk be GitLab folyamatos integrációs pipeline-okat Ubuntu 20.04-en című útmutatóban, tartson egy kis szünetet ebben az útmutatóban, és kövesse az ottani lépéseket, hogy legyen egy szervere GitLab CI runner szolgáltatással. Ellenkező esetben lépjen be SSH-n keresztül a GitLab CI runner szerverre a sudo felhasználójával a következő lépésekhez.

A privilegizált projektspecifikus runner beállításához írja be a következő parancsot a terminálba, kicserélve a tartománynevét és a fent másolt regisztrációs tokent:

Ez a kimenet a sikeres regisztrációt mutatja:

Annak ellenőrzéséhez, hogy a GitLab-példány észlelte-e a runnert, lépjen vissza a böngészőbe, és frissítse a Settings > CI/CD oldalt. Bontsa ki a Runners szekciót, és látnia kell a runnert a Specific Runners:

Opcionálisan, ha az Admin Panel felületre lép (a felső sávban található Menu gombra kattintva, majd az Admin) lehetőséget választva, majd kiválasztja a Runners lehetőséget a menüpontok közül:

Ezen az oldalon kell kikötnie, amely megmutatja az összes elérhető runnert, amely csatlakozik a GitLab-példányához, mind a megosztott, mind a projektspecifikus runnereket:

Eddig a pontig sikeresen beállított egy olyan runnert, amely képes Docker-képeket építeni.

2. lépés: A GitLab Docker Registry konfigurálása

Bizonyos kulcsfontosságú munkafolyamatok megkövetelik a külső szolgáltatásoktól való függetlenséget. Itt jön képbe a GitLab saját üzemeltetésű Docker Registry-je. Ez nemcsak biztonságos, hanem biztosítja azt a rugalmasságot is, amellyel a feladatokat és csővezetékeket az igényeidhez igazíthatod. A Docker Registry beállításához módosítanod kell a GitLab konfigurációs fájlját. Először lépj be SSH-n keresztül a GitLab példányba, majd nyisd meg a fájlt a következő paranccsal:

Görgess le, amíg meg nem látod a Container Registry Settings:

részt. Töröld a kommentjelet a registry_external_url sor elől, és állítsd be a GitLab példányod tartománynevére, megadva a 8888 portot a végén:

Ezután meg kell adnunk, hogy a registry hol találja a Let’s Encrypt tanúsítványokat a következő sorok hozzáadásával. Ne felejtsd el átírni a tényleges GitLab példányod tartománynevére:

Ha elkészültél, mentsd el és zárd be a fájlt. Írd be a következő parancsot a terminálba a GitLab újrakonfigurálásához:

Ezután várj néhány másodpercet, amíg a parancs végrehajtása befejeződik. Sikeres futás esetén a következő kimenetet kell látnod:

Ezután biztosítanunk kell, hogy a tűzfal (ufw) engedélyezze a forgalmat a hozzárendelt registry porthoz a következő paranccsal:

Ezután tesztelned kell, hogy a Docker Registry fut-e, bejelentkezve egy másik olyan gépről, amelyre telepítve van a Docker, a docker login paranccsal. Ha még nem állítottad be a Dockert a helyi környezetedben, beléphetsz SSH-val a GitLab CI runner szerverre, mivel azon már telepítve van a Docker. Ezután futtasd a következő parancsot, természetesen megadva a saját GitLab példányod tartománynevét:

A kimenetben a következő Login Succeeded üzenet fog megjelenni:

Ez azt jelenti, hogy a registry konfigurálása sikeres volt és működik. Amikor képeket hozol létre, azok helyben, a GitLab szerver fájlrendszerében fognak tárolódni. Ez egy privát vállalati registry esetében teljesen megfelelő. Ha azonban azt tervezed, hogy a registry-det nyilvánosan elérhetővé teszed, nagyobb tárhelyre lehet szükséged. Szerencsére a GitLab lehetőséget biztosít tároló-bödönökhöz (storage buckets) való csatlakozásra. További részleteket a hivatalos GitLab container registry docs dokumentációban olvashatsz arról, hogyan konfigurálhatsz tároló-bödönt a GitLab példányodhoz.

3. lépés: Módosítsd a gitlab-ci.yml fájlt és építs egy Docker-képet

A lépés végrehajtásához rendelkezned kell a Node Pipeline projekttel a GitLab példányodon. Így néz ki a projekt a GitLab felületén:

Korábban már beszéltünk a gitlab-ci.yml fájlról, amelyet a GitLab CI runner olvas be, amikor elindul, hogy megtudja, hogyan kell felépíteni az alkalmazást és végrehajtani az automatizált teszteket. Módosítanunk kell ezt a fájlt, hogy hozzáadjuk a Docker-képek építésére vonatkozó utasításokat. Dönthetsz úgy, hogy ezt a fájlt közvetlenül a GitLab felületén szerkeszted. Le is klónozhatod a helyi gépedre, szerkesztheted a kedvenc szerkesztőddel, majd végrehajthatsz egy commitot és git push-t vissza a GitLab-ra. A rövidség kedvéért mi a GitLab felületét fogjuk használni.

Kattints a fájlra a megnyitásához, majd kattints az Szerkesztés gombra:

Ez megnyitja a fájlt szerkesztésre készen. Törölj mindent a fájlból, és add hozzá a következő kódot:

Mialatt a fenti kódrészletet hozzáadja, ne felejtse el frissíteni a kiemelt részt a saját adataival. Ha végzett, mentse el a módosításokat a Commit changes gombbal. Ha a GitLabon kívül dolgozott, commitolja és pusholja a módosításait.

Értsük meg, mit is csinál a(z) .gitlab-ci.yml fájlhoz hozzáadott kód. Az első sor arra utasítja a GitLabot, hogy a hivatalos Docker-in-Docker rendszerképet használja, és csatolja azt a docker-in-docker szolgáltatáshoz (docker:dind). Ezután meghatározzuk a szakaszokat (stages) a következőkhöz: build, test, és release. A build szakasz felépíti a rendszerképet a Dockerfile fájlban található utasítások alapján, majd feltölti azt a Docker Registry-be, amelyet egy előző lépésben állítottunk be.

Amikor a build szakasz sikeresen lefut, a test szakasz letölti a rendszerképet, futtatja azt konténerként, és végrehajtja az npm test parancsot, hogy automatizált teszteket futtasson benne. Ha a test szakasz sikeres, a release szakasz veszi át az irányítást. A release szakaszban a rendszerkép letöltésre kerül, és megkapja a node_pipeline:latest taget. Ezután visszatöltődik (push) a registry-be.

Ez csak egy alapvető konfiguráció egy demóprojekthez. A valós projektekben más szakaszok is lehetnek, például staging, production, stb. Amikor szerkesztés után elmenti a fájlt, egy pipeline (folyamat) indul el. Ezután elkezdi futtatni a feladatokat (jobs). Térjen vissza a Node Pipeline oldalra. Látnia kell, hogy a feladat jelenleg fut:

Kattintson a CI jelzőikonra a feladat különböző szakaszainak megtekintéséhez:

Ahogy a fenti képernyőképen is látható, a zöld pipák alapján minden szakasz sikeres volt. Az egyes szakaszokra kattintva megtekintheti a feladat kimenetét:

A bal oldali menüben kattintson a Packages & Registries lehetőségre, majd válassza a Container Registry:

lehetőséget. Ez megnyit egy oldalt, amely felsorolja a kiválasztott projekthez elérhető Docker rendszerképeket. Az általunk felépített és kiadott rendszerképnek meg kell jelennie a listában a következő taggel: assigned:

Kattintson a rendszerkép különböző tagjeinek megjelenítéséhez:

Ha a helyi környezetében telepítve van a Docker, letöltheti (pull) a rendszerképet, és tesztelheti, hogy az elvárásoknak megfelelően fut-e. Kattintson a Copy ikonra a rendszerkép tag neve mellett. Ez a vágólapra másolja a teljes rendszerképnevet, amelyet a docker pull paranccsal használhat:

A fenti parancsok letöltik a rendszerképet, és futtatják azt egy konténerben:

Az alkalmazás most a következő porton érhető el: 8090. If you open your browser and navigate to your-IP-address:8090 címre, a következő oldalt kell látnia:

Ha lát ilyen oldalt a böngészőjében, akkor sikeresen létrehozott egy Docker-képet, és megosztotta azt egy privát Docker Registry-ben. A jövőben, ha bármilyen módosítást végez a master ágon, a .gitlab-ci.yml fájlban meghatározott szakaszok lefutnak, és ha sikeresek, egy új Docker-kép épül újra latest címkével, amely feltöltésre kerül a registry-be.

Összegzés

Ebben a projektben megtanulta, hogyan adhat hozzá egy privileged GitLab runnert a saját üzemeltetésű GitLab példányához, hogy Docker-képeket építhessen. Beállított egy privát Docker-kép registry-t is a képei tárolására. A(z) Node pipeline projekt segítségével tesztelhette a beállítás minden összetevőjét, és megbizonyosodhatott arról, hogy az elvárásoknak megfelelően kapcsolódnak és kommunikálnak. Miután a kép elérhetővé vált a registry-ben, le tudta tölteni (pull), és ellenőrizhette, hogy fut-e egy konténerben.

Ez egy bevezető útmutató, amely az alapokat nyújtja az építkezéshez. Kérjük, kövesse a hivatalos GitLab dokumentációt, hogy többet tudjon meg a GitLabról. Ez a link információt nyújthat a GitLab Container Registry.

A Docker használatával kapcsolatos további forrásokért érdemes megnéznie további útmutatókat a blogunkon:

• Adatmegosztás Docker-konténerek között
• Privát Docker Registry beállítása Ubuntu 18.04-en
• Hogyan osszunk meg adatokat egy Docker-konténer és a gazdagép között
• Docker-erőforrások tisztítása – képek, konténerek és kötetek

Kellemes számítástechnikát!