Vissza a bloghoz

Hogyan állítsunk be GitHub folyamatos integrációs folyamatokat saját hosztolású futtatókkal Ubuntu 22.04-en.

Hogyan állítsunk be GitHub folyamatos integrációs folyamatokat saját hosztolású futtatókkal Ubuntu 22.04-en.

Bevezetés

A szoftverfejlesztés egy gyorsan változó és versenyképes terület. Ha gyorsabban juttatja el termékeit a felhasználókhoz, az előnyt jelent a versenytársakkal szemben. Pozitívum, hogy az iparági legjobb gyakorlatok segítenek a vállalatoknak egyenlő esélyeket biztosítani.

A folyamatos integráció és folyamatos fejlesztés (CICD) egy példa arra a stratégiára, amely az iparági legjobb gyakorlatokat kihasználva előnyt biztosít a vállalatoknak ezen a versenyképes területen.

A GitHub, egy Git verziókezelő eszközzel működő webalapú tárhely, lehetővé teszi a szoftverfejlesztők, mérnökök és szoftverarchitektek számára a CI/CD megvalósítását. A folyamatos fejlesztés (CD) a buildek, tesztek és telepítések automatizálásának gyakorlata. A folyamatos integráció (CI) lehetővé teszi, hogy sokan dolgozzanak együtt ugyanazon a projekten, és ellenőrizzék a kód működését anélkül, hogy aggódniuk kellene az összefésülési konfliktusok (merge conflict) miatt.

A GitHub Actions lehetővé teszi olyan lépések megírását, amelyek automatizálják a buildeket, teszteket és a telepítést.

Ebben az útmutatóban megtanulhatja, hogyan állítson be folyamatos integrációt a GitHub Actions segítségével. Kezdésként beállítunk egy Git tárhelyet a kódunk tárolására. Ezután konfigurálunk egy GitHub CI folyamatot, amely figyeli a kódunk változásait, elindít egy CI futtatót (runner) a tesztek futtatásához, felépíti és telepíti az alkalmazásunkat egy Nginx-et futtató Ubuntu 22.04 szerverre.

Előfeltételek

Az útmutató követéséhez a következőkre lesz szüksége:

Most, hogy minden megvan, amire szükségünk van, kezdjük el.

1. lépés: A projekt tárhelyének klónozása.

Ezt az útmutatót a Reactjs-re alapozzuk, ami egy deklaratív Javascript könyvtár felhasználói felületek építéséhez. Ha a semmiből szeretne új projektet létrehozni, használhatja ezt a forrást a React alkalmazás beállításához. A rövidség kedvéért ennek a React.js repónak a klónját fogjuk használni, amelyet már beállítottunk a GitHubon.

Az alkalmazás, amelyet klónozunk, egy egyszerű React alkalmazás react-router 6-tal és egy teszttel, amely a React Testing Library segítségével készült, ami módszereket biztosít számunkra a DOM eléréséhez.

A tárhely klónozásához kattintson a zöld gombra, és másolja ki az URL-t.

Nyissa meg a terminált a munkaterületén, és futtassa az alábbi parancsot az alkalmazás klónozásához:

Miután klónozta a tárhelyet, lépjen be a projekt könyvtárába:

Futtassa a docker-compose up parancsot az alkalmazás felépítéséhez és futtatásához:

Amikor a folyamat befejeződik, látogasson el a http://localhost:3000

Ehhez hasonlót kellene látnia:

2. lépés: A Node.js.yml fájl megértése.

Ebben a lépésben meghatározzuk a GitHub Yaml fájlban található direktívákat, hogy megértsük, mi történik. A tárhelyen található egy könyvtár .github/workflows , amely tartalmaz egy node.js.yml fájlt, amely azokat a munkafolyamat-lépéseket tartalmazza, amelyeket a GitHub futtatók (runners) követnek, miután feltöltötte a változtatásokat a GitHubon lévő kódtárába. YAML szintaxist használnak a GitHub Actions munkafolyamatainak megírásához. A YAML fájlok kiterjesztése yaml vagy yml.

Nyissa meg a node.js.yml fájlt, így kellene kinéznie:

Ezen útmutató írásakor a Node.js 16 16-os verzióját használtuk. Most pedig értsük meg a GitHub Actions munkafolyamatot:

  • name

name: cicd-tut

A munkafolyamat neve, ez a név fog megjelenni a repozitórium Actions fülén.

  • on

on az események meghatározására szolgál. Az események automatikusan elindíthatnak egy munkafolyamatot, vagy ütemezhetők későbbre. Az események lehetnek egyszeriek vagy többszörösek, valamint meghatározhatja a munkafolyamatok végrehajtását adott ágakra, címkékre vagy fájlokra is. Ez úgy működik, mint egy szűrő.

A YAML fájlunkban automatikus többszörös eseményeket határozunk meg, ezek a következők:

  • Egy push esemény akkor váltódik ki, amikor kód kerül beküldésre egy repozitóriumba

  • Egy pull_request esemény akkor váltódik ki, amikor egy pull request jön létre a main ágon.

Megadunk egy ágnevet main annak érdekében, hogy a munkafolyamat végrehajtását csak arra az ágra korlátozzuk. A figyelmen kívül hagyandó ágakat is megadhatjuk a ! jelölővel, amelyet az ág neve követ.

  • jobs

Egy munkafolyamat alapvetően egy vagy több feladatból (job) áll. Ezek a feladatok egymás után futnak az elsőtől az utolsóig.

Minden feladat egy olyan futtató (runner) környezetben fut, amelyet a runs-on határoz meg. Választhatja a feladatok futtatását a GitHub futtatóin, amelyeket a ubuntu-latest vagy egy self-hosted futtatón, amelyet a self-hosted jelöl. A választása a szükséges feladatok számától függ. A saját gazdagépű (self-hosted) futtatókkal nagyobb rugalmassággal és az erőforrások feletti ellenőrzéssel rendelkezik.

A következő lépésben először a GitHub futtatóin fogjuk futtatni a feladatainkat, majd később beállítunk egy saját gazdagépű (self-hosted) GitHub futtatót a saját szerverünkön.

  • strategy

A stratégia (strategy) lehetővé teszi, hogy változókat használjunk egyetlen feladatdefinícióban, hogy automatikusan több feladatfuttatást hozzunk létre a változók kombinációi alapján.

A YAML fájlunkban egy változónk van a node-version-höz, de ha hozzáadunk egy másikat a 18-as node verzióhoz, így: node-version: [16.x, 18.x], akkor a mátrix stratégia 2 feladatfuttatást fog létrehozni a react alkalmazásunkhoz mind a 16-os, mind a 18-as node verziókhoz.

  • steps

A lépések (steps) a feladatot alkotó feladatok sorozata. A lépések parancsokat futtathatnak, feladatokat állíthatnak be, műveleteket (actions) futtathatnak a nyilvános repozitóriumában, vagy egy docker regisztrációs adatbázisban közzétett műveleteket.

Egy lépésnek van neve. Bár opcionális, használhatja arra, hogy megadjon egy egyszerű módot a lépés nevének azonosítására, amely megjelenik a GitHubon.

Egy lépésben kiválaszthat egy futtatandó műveletet a feladatában, a műveletek újrafelhasználhatók. A művelet verziói a művelet meghatározásakor kerülnek megadásra, ez azért fontos, mert megakadályozza, hogy a munkafolyamat megszakadjon, amikor a művelet tulajdonosa frissítést tesz közzé.

A fenti kódrészletben checkout@v3 egy példa egy meghatározott verziójú műveletre 3. Ez a művelet letölti a tárhelyét, hogy a munkafolyamat hozzáférhessen.

Néhány művelet, mint például a actions/setup-node@v3 fenti bemenetekkel rendelkezik, amelyeket a with kulcsszó jelöl, a setup node műveletekhez a node 16-os verziója és az npm gyorsítótárazása szükséges.

  • run

Ez a művelet parancssori programokat futtat az operációs rendszer shelljével.

A fenti YAML fájlban három parancsunk van, mindegyik ugyanazt a shellt fogja használni a futtató környezetben.

  • Az első parancs npm i telepíti a react alkalmazásunk által igényelt összes függőséget.

  • A második npm test, futtatja a megírt tesztet. A teszt elvárja, hogy a learn react szöveg megjelenjen a kezdőlapon.

  • Végül a npm run build parancs létrehoz egy build könyvtárat az alkalmazásunk produkciós verziójával. Később ezt a build könyvtárat fogjuk használni az Nginx szerverblokkunkban.

3. lépés: A GitHub CI tesztelése GitHub futtatókkal.

Ebben a lépésben a folyamatos integrációs folyamatot fogjuk tesztelni GitHub futtatókkal. Kezdje a node.js.yml fájl megnyitásával. Módosítsa a futtató típusát, amelyen a műveletek futni fognak, a következőre: ubuntu-latest. Ennek az a célja, hogy teszteljük, hogy a GitHub munkafolyamat tökéletesen működik-e a GitHub futtatókon, mielőtt beállítanánk a saját, saját gazdagépű (self-hosted) futtatóinkat.

Hozzon létre egy új tárhelyet a GitHub-fiókjában. Mielőtt folytatnánk, lépjen vissza a munkaterület könyvtárába, és törölje a .git könyvtárat, ha nem látja, ellenőrizze a rejtett fájlokat. A könyvtár törléséhez használhatja a következő parancsot a terminálon:

Most már hozzáadhatja az összes projektfájlt (git add), véglegesítheti (commit) és feltöltheti (push) őket a tárhelyére. Ha elakad, használja ezt az útmutatót a projektmappa összekapcsolásához a GitHub-tárhellyel, amelyet fentebb hozott létre.

Ha végzett, kattintson a Code fülre a tárhelyén, és egy kis narancssárga pontot fog látni az összesített commit szám mellett. Ha rákattint, egy, az alábbihoz hasonló modális ablakot fog látni, ami azt jelzi, hogy a munkafolyamat várólistára került:

Most kattintson a Details linkre a modális ablakban, vagy lépjen az Actions fülre, ahol láthatja a node.js.yml munkafolyamat egyes lépéseit, amint azokat a GitHub futtatók végrehajtják:

Siker esetén kattintson az Actions fülre, ennek így kell kinéznie:

És ennyi, a Code fülön lévő kis narancssárga pontnak mostanra zöld pipává kell válnia. A GitHub futtató sikeresen felépítette az alkalmazásunkat.

Most menjünk egy lépéssel tovább, és változtassuk meg a build környezetet, hogy a GitHub saját gazdagépű (self-hosted) futtatóit használja a saját Ubuntu szerverinfrastruktúránkban.

4. lépés: A GitHub munkafolyamat beállítása saját gazdagépű futtató használatára.

Mielőtt telepítenénk a saját gazdagépű futtatót a szerverünkre, menjünk vissza a munkaterületünkre, és szerkesszük a node.js.yml  munkafolyamat-fájlt, hogy a GitHub saját gazdagépű futtatóin fusson.

Ebben a szakaszban, amikor véglegesíti a változtatásokat, a feladat várólistára kerül, mivel még nincs meghatározva saját gazdagépű futtató.

A tárhelyén kattintson a Settings fülre, a bal oldali sávban kattintson az Actions, majd kattintson a Runners:

Kattintson a New self-hosted runner lehetőségre, és válassza a Linux operációs rendszert.

Látni fogja a futtató letöltésére és a szerverére történő telepítésére vonatkozó utasításokat.

5. lépés: GitHub saját gazdagépű futtató telepítése és konfigurálása a szerverünkön.

Ebben a lépésben egy saját gazdagépű (self-hosted) GitHub runnert fogunk beállítani. A saját gazdagépű runner egy olyan rendszer, amely képes telepíteni és kezelni a GitHub Actions feladatok végrehajtását a GitHub webhelyén. A saját gazdagépű runner egyik előnye a GitHub által hosztolt runnerrel szemben a rugalmasság. Nagyobb ellenőrzést biztosít az operációs rendszer, a hardver és egyéb eszközök felett, amelyek testreszabhatók az alkalmazás igényeinek megfelelően.

A saját gazdagépű runnerek különböző szinteken adhatók hozzá, mint például:

  • Tárhelyszintű (repository-level) runnerek, amelyek egyetlen tárhelyhez vannak hozzárendelve.

  • Szervezeti szintű (organization-level) runnerek, amelyek egy szervezet több tárhelyének feladatait is képesek feldolgozni.

  • Vállalati szintű (enterprise-level) runnerek, amelyek több szervezethez is hozzárendelhetők.

A folytatáshoz jelentkezzen be a szerverére ssh-n keresztül:

Váltson a saját könyvtárára (home directory) a következő paranccsal:

Ezután hozzon létre egy könyvtárat, amelynek neve action-runners és lépjen be oda:

Ezután töltse le a runner csomag legújabb verzióját:

Ezután csomagolja ki a letöltött csomagot a következő paranccsal:

Visszatérve a tárhelyéhez, a Settings lapon, a bal oldali panelen kattintson az Actions, majd a Runners elemre, pontosan úgy, ahogy a lépésben 4.

Látni fog egy listázott parancsot, amely tartalmaz egy tokent, ami összekapcsolja a saját gazdagépű runnert a GitHub tárhelyével. Miközben még mindig abban a könyvtárban tartózkodik, ahová kicsomagolta a GitHub runner kódját, használja a listázott parancsot a runner összekapcsolásához, például:

Sikeresen hitelesítenie kell:

Nyomjon Entert az alapértelmezett (Default) runner csoporthoz.

Ezután adjon meg egy nevet a runnernek, például my-runner, majd nyomjon Entert.

Nyomjon Entert a további címkék hozzáadásának kihagyásához, ekkor meg kell jelennie a sikeres üzenetnek az alábbi képernyőképen látható módon:

Adja meg a munkakönyvtár nevét, például react-cicd, a folyamatnak sikeresnek kell lennie a következő szöveggel: settings saved.

Végül futtassa a ./run.sh parancsot, ennek ezt kell mutatnia: Connected to Github:

De ez nem fut a háttérben, si beírjuk a ctrl+c billentyűkombinációt a terminálunkban, a runner leáll. Ezt fel kell váltanunk a .svc.sh szolgáltatással, hogy a runner szolgáltatásként fusson tovább, így továbbra is interakcióba léphessünk vele.

Állítsa le a runnert a ctrl+c billentyűkombinációval. Telepítheti a .svc.sh szolgáltatást a következő parancs futtatásával:

Miután telepítette, indítsa el a szolgáltatást a következő paranccsal:

Ennek sikeresnek kell lennie, és a következőt kell mutatnia: active (running).

Annak ellenőrzésére, hogy a svc.sh szolgáltatás működik, futtassa a következő parancsot:

Ezen a ponton minden olyan munkafolyamatnak, amely esetleg sorban állt egy saját gazdagépű runnerre várva, sikeresen le kell futnia. Szerkeszthet egy fájlt is, hogy kipróbálja. Például módosítsa az Névjegy.tsx fájlt, véglegesítse (commit) és küldje be (push) a változtatásokat, a saját gazdagépű runner pedig sikeresen befejezi a feladatot.

6. lépés: Az Nginx szerverblokk beállítása

Ebben a lépésben beállítunk egy szerverblokkot az Nginx-ben, hogy megtekinthessük a react alkalmazásunk build verzióját. Készítettünk egy útmutatót az Nginx szerverblokkok beállításáról , amely hasznos lehet az Ön számára.

Alább látható egy példa az ebben az útmutatóban használt szerverblokkra:

Létre fog hozni egy Nginx szerverblokk konfigurációs fájlt a /etc/nginx/sites-available könyvtárban.

Nyissa meg a webhely szerverblokk-konfigurációs fájlját a nano szerkesztővel a következő paranccsal:

Másolja ki a fent megosztott szerverblokkot, módosítsa a könyvtárútvonalaknak megfelelően, majd illessze be a megnyíló fájlba. Ha végzett a szerkesztéssel, nyomja meg a ctrl+x gombot, majd nyomja meg az y és enter gombokat a mentéshez és kilépéshez.

A mentés után hozzon létre egy szimbolikus linket a react-cicd szerverblokk-konfigurációhoz innen: /etc/nginx/sites-available ide: /etc/nginx/sites-enabled a következő parancs futtatásával:

A változtatások életbe lépéséhez újra kell indítania az Nginx-et. Mielőtt azonban újraindítaná az Nginx szolgáltatást, ellenőrizze, hogy az Nginx konfigurációk érvényesek-e, a következő parancs futtatásával:

Ha a konfiguráció helyes, a tesztnek sikeresnek kell lennie.

Megfigyelte a server_name direktíva “ react.test ” értékét a szerverblokkban? Ezt az értéket hozzá kell adnia a hosts fájlhoz a helyi gépén. Ez lehetővé teszi, hogy megnyissa az alkalmazást a böngészőjében. Ez a lépés csak a helyi fejlesztési környezetben használt virtuális tartományok esetében szükséges. Ha van egy regisztrált domain neve, amely a szervere nyilvános IP-címéhez van kapcsolva, akkor a domain névnek már elérhetőnek kell lennie a böngészőjében.

A helyi gépén nyissa meg a hosts fájlt a következő paranccsal:

A hosts fájlon belül adja hozzá a szervere IP-címét, pl. 127.0.0.1, majd a virtuális domain nevét.

Alább látható egy példa. Ezután zárja be a fájlt és mentse el:

Visszatérve a szerverre, a /var/www könyvtárban hozzon létre egy új könyvtárat, amelyet elnevezhet react-cicd-nek a következő futtatásával:

Ebben a szakaszban kivesszük a megjegyzésből az utolsó parancsot a node.js.yml fájlban.

Ez a parancs átmásolja a react alkalmazásunk build mappáját onnan, ahol a munkamappánkat megadtuk az actions-runner könyvtáron belül az előző lépésben 5.

És behelyezi a public mappát a /var/www/react-cicd könyvtárba.

A szerverblokk most már hozzá tud férni az alkalmazásunkhoz, és meg tudja jeleníteni egy böngészőben.

Végezetül indítsa újra az Nginx szolgáltatást a következő paranccsal:

Most már módosíthatja a Névjegy.tsx fájlt, majd commitolhatja és pusholhatja a változtatásokat a tárolójába. Sikeres build után látni fogja a react alkalmazás build verzióját a http://react.test címen vagy a megadott domain néven. Kerülje a href elem szerkesztését a Home.tsx fájlban, mert ez a már megírt teszt sikertelenségét okozhatja. A Actions fülnek a tárolójában szintén mutatnia kell a befejezett job buildet.

Összegzés

A Github Actions-szel történő folyamatos integráció számos előnnyel jár, többek között jó fejlesztői élményt nyújt, segít a folyamatos tesztelésben, megkönnyíti az együttműködést a nagyobb csapatokban, lerövidíti a fejlesztési időt, lehetővé teszi az új funkciók gyors kiadását, a valós idejű visszajelzést és a vevői elégedettséget, ami előnyt biztosít a versenytársakkal szemben. Ezen ismeretek bővítéséhez érdemes lehet tanulni a következőkről is: GitLab folyamatos integrációs (CI) pipeline-ok beállítása Ubuntu-n. és egy saját üzemeltetésű GitLab példány használatáról a Docker-képek hosztolására és privát buildek futtatására.

Kellemes számítástechnikát!

author

Preslav Dobrev

Szerző · CloudSigma

Preslav Dobrev a CloudSigma kreatív tervezője, aki hagyományos és innovatív marketingcsatornák segítségével következetes vállalati identitás kialakítására összpontosít. Kiemelkedően képes ötvözni a művészi látásmódot a stratégiai marketinggel, hogy hatásos márkatörténeteket hozzon létre.

Hozzászólások

Még nincsenek hozzászólások. Legyen Ön az első.