Zpět na blog

Jak nastavit pipeline pro průběžnou integraci na GitHubu s vlastně hostovanými runnery na Ubuntu 22.04.

Jak nastavit pipeline pro průběžnou integraci na GitHubu s vlastně hostovanými runnery na Ubuntu 22.04.

Úvod

Softwarové inženýrství je rychlý a konkurenční obor. Rychlejší uvádění produktů k uživatelům vám poskytne výhodu nad konkurencí. Pozitivní je, že existují osvědčené postupy v oboru, které firmám pomáhají zajistit rovné podmínky.

Kontinuální integrace a kontinuální vývoj (CICD) je příkladem strategie, která využívá osvědčené postupy v oboru, aby firmám poskytla výhodu v tomto konkurenčním prostředí.

GitHub, webové úložiště s nástrojem pro správu verzí Git, umožňuje softwarovým vývojářům, inženýrům a architektům implementovat CI/CD. Kontinuální vývoj (CD) je praxe automatizace sestavení, testů a nasazení. Kontinuální integrace (CI) umožňuje mnoha lidem spolupracovat na stejném projektu a kontrolovat, zda kód funguje, bez obav z konfliktů při slučování.

GitHub Actions nám umožňují psát kroky, které automatizují sestavení, testy a nasazení.

V tomto návodu se naučíte, jak nastavit kontinuální integraci pomocí GitHub Actions. Začneme nastavením Git repozitáře pro hostování našeho kódu. Poté nakonfigurujeme proces GitHub CI pro sledování změn v našem kódu, spustíme CI runner pro spuštění testů, sestavení a nasazení naší aplikace na server Ubuntu 22.04 se spuštěným Nginx.

Požadavky

Chcete-li postupovat podle tohoto návodu, budete potřebovat následující:

Nyní, když máme vše, co potřebujeme, pojďme začít.

Krok 1. Klonování repozitáře projektu.

Tento návod založíme na Reactjs, deklarativní JavaScriptové knihovně pro vytváření uživatelských rozhraní. Pokud chcete nastavit nový projekt od nuly, můžete použít tento zdroj o nastavení React aplikace. Pro stručnost budeme používat klon tohoto React.js repozitáře který jsme již nastavili na GitHubu.

Aplikace, kterou klonujeme, je jednoduchá React aplikace s react-router 6 a testem provedeným pomocí React Testing Library, což nám poskytuje metody pro přístup k DOM.

Chcete-li repozitář naklonovat, klikněte na zelené tlačítko a zkopírujte URL.

Otevřete terminál ve svém pracovním prostoru a spuštěním níže uvedeného příkazu naklonujte aplikaci:

Jakmile repozitář naklonujete, přejděte do adresáře projektu:

Spusťte příkaz docker-compose up pro sestavení a spuštění aplikace:

Po dokončení procesu navštivte http://localhost:3000

Měli byste vidět něco podobného tomuto:

Krok 2. Porozumění souboru Node.js.yml.

V tomto kroku budeme definovat direktivy v souboru GitHub Yaml, abychom lépe porozuměli tomu, co se děje. V repozitáři se nachází adresář .github/workflows, který obsahuje node.js.yml soubor, který obsahuje kroky workflow, které spouštěče GitHubu (runners) provádějí poté, co odešlete změny do svého repozitáře kódu na GitHubu. YAML syntaxe se používá k zápisu workflow pro GitHub Actions. Soubory YAML končí příponou yaml nebo yml.

Otevřete node.js.yml soubor, měl by vypadat takto:

V době psaní tohoto návodu jsme používali verzi 16 Node.js 16. Nyní si pojďme vysvětlit workflow GitHub Actions:

  • name

name: cicd-tut

Název vašeho workflow, tento název se zobrazí ve vašem repozitáři na záložce Actions .

  • on

on se používá k definování událostí. Události mohou automaticky spustit workflow nebo být naplánovány na později. Události mohou být jednotlivé nebo vícenásobné, můžete také specifikovat spouštění workflow pro konkrétní větve, tagy nebo soubory. To funguje jako filtr.

V našem souboru YAML definujeme několik automatických událostí, jsou to:

  • Událost push se spustí, když je kód zapsán do repozitáře

  • Událost pull_request se spustí, když je vytvořen pull request ve větvi main.

Specifikujeme název větve main, abychom omezili spouštění workflow pouze na tuto větev. Můžeme také specifikovat větve, které mají být ignorovány, pomocí příznaku ! následovaného názvem větve.

  • jobs

Workflow se v podstatě skládá z jedné nebo několika úloh. Tyto úlohy běží postupně od první do poslední.

Každá úloha běží v prostředí runneru určeném pomocí runs-on. Můžete si vybrat spouštění úloh buď na runnerech GitHubu označených jako ubuntu-latest nebo na self-hosted runneru označeném jako self-hosted. Vaše volba bude záviset na počtu úloh, které potřebujete. S self-hosted runnery máte větší flexibilitu a kontrolu nad prostředky.

V dalším kroku nejprve spustíme naše úlohy na runnerech GitHubu a později nastavíme self-hosted runner GitHubu na našem vlastním serveru.

  • strategy

Strategie nám umožňuje použít proměnné v definici jedné úlohy k automatickému vytvoření více spuštění úloh, které jsou založeny na kombinacích proměnných.

V našem souboru YAML máme jednu proměnnou pro naši verzi Node, ale pokud přidáme další pro Node verze 18, takto: node-version: [16.x, 18.x], pak maticová strategie vytvoří 2 spuštění úlohy pro naši aplikaci React pro verze Node 16 i 18.

  • steps

Kroky jsou sekvence úkolů, které tvoří úlohu. Kroky mohou spouštět příkazy, nastavovat úkoly, spouštět akce ve vašem veřejném repozitáři nebo akce publikované v registru Docker.

Krok má název. I když je volitelný, můžete jej použít k určení snadného způsobu identifikace názvu vašeho kroku, který se zobrazí na GitHubu.

V rámci kroku můžete vybrat akci, která se má spustit ve vaší úloze, akce jsou opakovaně použitelné. Verze akce se specifikují při definování akce, což je důležité, protože to zabraňuje narušení vašeho workflow, když vlastník akce publikuje aktualizaci.

Ve výše uvedeném fragmentu kódu, checkout@v3 je příkladem akce se specifikovanou verzí 3. Tato akce provede checkout vašeho repozitáře, aby k němu mělo vaše workflow přístup.

Některé akce, jako například actions/setup-node@v3 výše, mají vstupy označené pomocí klíčového slova with, akce setup node vyžadují verzi Node 16 a cachování npm.

  • run

Tato akce spouští programy příkazového řádku pomocí shellu operačního systému.

Ve výše uvedeném souboru YAML máme tři příkazy, všechny tři poběží pomocí stejného shellu v prostředí runneru.

  • První příkaz npm i nainstaluje všechny závislosti potřebné pro naši aplikaci React.

  • Druhý npm test, spustí test, který jsme napsali. Test očekává, že text learn react bude vykreslen na domovské stránce.

  • A nakonec, npm run build vytvoří adresář sestavení s produkční verzí naší aplikace. Později tento adresář sestavení použijeme v našem bloku serveru Nginx.

Krok 3. Testování GitHub CI s GitHub Runnery.

V tomto kroku budeme testovat proces průběžné integrace (Continuous Integration) s GitHub runnery. Začněte otevřením souboru node.js.yml souboru. Upravte typ runneru, na kterém se akce spustí, na ubuntu-latest. Účelem toho je otestovat, zda GitHub workflow funguje perfektně na GitHub runnerech předtím, než nastavíme naše vlastní self-hosted runnery.

Vytvořte nový repozitář na svém GitHub účtu. Než budeme pokračovat, vraťte se do svého pracovního adresáře a smažte .git adresář, pokud jej nevidíte, zkontrolujte skryté soubory. Ke smazání adresáře můžete v terminálu použít následující příkaz:

Nyní můžete pomocí git add přidat všechny soubory projektu, provést commit a pushnout je do svého repozitáře. Pokud jste se zasekli, použijte tento návod na připojení složky projektu k repozitáři GitHub který jste vytvořili výše.

Jakmile budete hotovi, klikněte na Code záložku ve vašem repozitáři a vedle celkového počtu commitů uvidíte malou oranžovou tečku. Když na ni kliknete, zobrazí se modální okno podobné tomu níže, které značí, že váš workflow byl zařazen do fronty:

Nyní klikněte na Details odkaz v modálním okně nebo přejděte na Actions záložku, kde uvidíte každý krok node.js.yml workflow spouštěného GitHub runnery:

Pokud bude úspěšný, klikněte na Actions záložku, měla by vypadat takto:

A to je vše, malá oranžová tečka na naší záložce Code by nyní měla být zelené zaškrtnutí. GitHub runner úspěšně sestavil naši aplikaci.

Nyní pojďme o krok dále a změňme sestavovací prostředí tak, aby využívalo GitHub self-hosted runnery v naší vlastní Ubuntu Server infrastruktuře.

Krok 4. Nastavení GitHub workflow pro použití self-hosted runneru.

Předtím, než nainstalujeme self-hosted runner na náš server, se vraťme do našeho pracovního prostoru a upravme node.js.yml  soubor workflow, který se má spouštět na GitHub self-hosted runnerech.

V této fázi, když potvrdíte změny, bude úloha zařazena do fronty, protože nebyl definován žádný self-hosted runner.

Ve svém repozitáři klikněte na Settings kartu, v levém panelu klikněte na Actions, then click Runners:

Klikněte na New self-hosted runner a vyberte Linux jako operační systém.

Uvidíte pokyny, které vám ukážou, jak stáhnout runner a nainstalovat jej na váš server.

Krok 5. Instalace a konfigurace GitHub self-hosted runneru na našem serveru.

V tomto kroku nastavíme self-hosted GitHub runner. Self-hosted runner je systém, který dokáže nasazovat a spravovat spouštění úloh z GitHub Actions na webu GitHub. Jednou z výhod self-hosted runneru oproti runneru hostovanému GitHubem je flexibilita. Nabízí větší kontrolu nad operačním systémem, hardwarem a dalšími nástroji, které lze přizpůsobit vašim konkrétním potřebám aplikace.

Self-hosted runnery lze přidat na různých úrovních, jako jsou:

  • Runnery na úrovni repozitáře (Repository-level), které jsou vyhrazeny pro jeden repozitář.

  • Runnery na úrovni organizace (Organization-level), které mohou zpracovávat úlohy pro více repozitářů v organizaci.

  • Runnery na úrovni podniku (Enterprise-level), které lze přiřadit k více organizacím.

Pro pokračování se přihlaste ke svému serveru přes SSH:

Přejděte do svého domovského adresáře pomocí příkazu:

Poté vytvořte adresář s názvem action-runners a přejděte do něj:

Dále stáhněte nejnovější verzi balíčku runneru:

Poté stažený balíček rozbalte příkazem:

Zpět ve vašem repozitáři, na Settings záložce klikněte v levém panelu na Actions, poté na Runners, stejně jako jsme to udělali v kroku 4.

Uvidíte uvedený příkaz, který obsahuje token propojující váš self-hosted runner s vaším GitHub repozitářem. Zatímco jste stále v adresáři, do kterého jste rozbalili kód GitHub runneru, použijte uvedený příkaz k propojení vašeho runneru, například:

Mělo by dojít k úspěšnému ověření:

Stiskněte Enter pro výchozí (Default) skupinu runnerů.

Poté zadejte název pro váš runner, například my-runner, a stiskněte Enter.

Stisknutím klávesy Enter přeskočte přidávání dalších štítků, na snímku obrazovky níže byste měli vidět zprávu o úspěchu:

Zadejte název vašeho pracovního adresáře, například react-cicd, mělo by to být úspěšné s textem settings saved.

Nakonec spusťte ./run.sh, což by mělo zobrazit Connected to Github:

To ale neběží na pozadí, pokud v našem terminálu stiskneme ctrl+c, runner se zastaví. Musíme jej nahradit .svc.sh službou, aby runner běžel jako služba, abychom s ním mohli nadále komunikovat.

Zastavte runner pomocí ctrl+c. Službu .svc.sh můžete nainstalovat spuštěním příkazu:

Jakmile je nainstalována, spusťte službu příkazem:

To by mělo být úspěšné a mělo by se zobrazit active (running).

Chcete-li potvrdit, že služba svc.sh běží, spusťte příkaz:

V tomto okamžiku by se měl úspěšně spustit jakýkoli workflow, který mohl čekat ve frontě na self-hosted runner. Můžete také upravit soubor a vyzkoušet si to. Upravte například O nás.tsx soubor, proveďte commit a push změn, self-hosted runner úspěšně dokončí úlohu.

Krok 6. Nastavení server blocku Nginx

V tomto kroku nastavíme server block v Nginx, abychom mohli zobrazit sestavenou verzi naší React aplikace. Máme návod na Nastavení server blocků Nginx, který by pro vás mohl být užitečný.

Níže je příklad server blocku použitého v tomto návodu:

Vytvoříte konfigurační soubor server blocku Nginx v adresáři /etc/nginx/sites-available .

Otevřete soubor pro konfiguraci server blocku vašeho webu v editoru nano pomocí příkazu:

Zkopírujte výše sdílený server block, upravte jej podle cest k vašim adresářům a vložte jej do otevřeného souboru. Jakmile dokončíte úpravy, stiskněte ctrl+x poté stiskněte y a enter pro uložení a ukončení.

Po uložení vytvořte symlink pro konfiguraci server blocku react-cicd z adresáře /etc/nginx/sites-available do /etc/nginx/sites-enabled spuštěním příkazu:

Aby se změny projevily, musíte restartovat Nginx. Před restartováním služby Nginx však otestujte, zda jsou konfigurace Nginx platné, spuštěním příkazu:

Pokud je konfigurace správná, test by měl proběhnout úspěšně.

Všimněte si hodnoty direktivy server_namereact.test ” v bloku serveru? Tuto hodnotu přidáte do svého hosts na svém lokálním počítači. To vám umožní otevřít aplikaci v prohlížeči. Tento krok je nutný pouze pro virtuální domény používané v lokálním vývojovém prostředí. Pokud máte registrovaný doménový název propojený s veřejnou IP adresou vašeho serveru, měl by být doménový název v prohlížeči již přístupný.

Na svém lokálním počítači otevřete soubor hosts pomocí příkazu:

Do souboru hosts přidejte IP adresu svého serveru, např. 127.0.0.1, následovanou vaším virtuálním doménovým názvem.

Příklad je uveden níže. Poté soubor zavřete a uložte:

Zpět na vašem serveru uvnitř /var/www vytvořte nový adresář, můžete jej pojmenovat react-cicd spuštěním:

V této fázi odkomentujeme poslední příkaz v souboru node.js.yml .

Tento příkaz zkopíruje složku sestavení (build) naší aplikace React z místa, kde jsme určili naši pracovní složku uvnitř adresáře actions-runner v předchozím kroku 5.

A vloží public složku do /var/www/react-cicd adresáře.

Blok serveru nyní může přistupovat k naší aplikaci a zobrazit ji v prohlížeči.

Nakonec restartujte službu Nginx pomocí příkazu:

Nyní můžete provést změnu v souboru O nás.tsx, poté potvrďte a odešlete změny do svého repozitáře. Po úspěšném sestavení uvidíte sestavenou verzi své aplikace React na http://react.test nebo na zadaném doménovém jménu. Vyhněte se úpravám prvku href v souboru Home.tsx soubor, protože by to mohlo způsobit selhání již napsaného testu. Záložka Actions ve vašem repozitáři by měla také zobrazovat dokončené sestavení úlohy.

Závěr

Kontinuální integrace s Github Actions přináší spoustu výhod, včetně skvělé zkušenosti pro vývojáře, pomáhá s průběžným testováním, umožňuje snazší spolupráci ve větších týmech, zkracuje dobu vývoje, rychlé vydávání nových funkcí, zpětnou vazbu v reálném čase a spokojenost zákazníků, což vám dává náskok před konkurencí. Chcete-li na těchto znalostech stavět, možná se budete chtít dozvědět více o Nastavení GitLab Continuous Integration (CI) pipelines na Ubuntu. a používání samostatně spravované instance GitLabu k hostování vašich Docker Images a spouštění privátních sestavení.

Příjemnou práci!

author

Preslav Dobrev

Autor · CloudSigma

Preslav Dobrev je kreativní designér ve společnosti CloudSigma, který se zaměřuje na konzistentní firemní identitu prostřednictvím tradičních i inovativních marketingových kanálů. Je zdatný v propojování umělecké vize se strategickým marketingem za účelem vytváření působivých příběhů značky.

Komentáře

Zatím žádné komentáře. Buďte první.