Návod: Jak nastavit deployment z Gitlab.com?

V tomhle návodu se naučíte, jak propojit váš projekt s GitLabem bez nutnosti instalovat celý systém. Stačí na server nainstalovat pouze gitlab-runner, abychom mohli využívat veškeré potřebné příkazy. Pak ho propojíme se shared-runnerem na GitLab.com a můžeme vesele pushovat i bez nutnosti instalovat celý GitLab na vlastním serveru.

Pokud ale potřebujete mít vše pod jednou střechou, tak mrkněte na návod, jak nainstalovat GitLab a taky jak nastavit automatický deploy aplikací.

Freelo - Nástroj na řízení úkolů a projektů

Přidej se, pozvi svůj tým a klienty, rozděl práci a sleduj, jak se úkoly dají do pohybu.

1. Krok –⁠⁠⁠⁠⁠⁠ Vytvořte si účet na GitLab.com

Pokud nemáte účet, tak se nejprve zaregistrujte.

Po registraci musíte vyplnit ještě 3 kroky, kdy se vás ptají, kdo všechno bude na projektu pracovat, vyberete jméno organizace a příslušnou URL a založíte si první projekt.

2. Krok –⁠⁠⁠⁠⁠⁠ Nainstalujeme GitLab runner na server

Pro testovací účely využíváme naše virtuální servery s VPS Centrem. Konkrétně tarif Basic, který běží na Debian / Buster.

Nejdříve přidáme oficiální GitLab repozitář. Přihlásíme se na SSH a vykonáme příkaz:

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh"  | bash

Výstup by měl vypadat takto:

% Total % Received % Xferd Average Speed Time Time  Time Current

Dload Upload Total Spent Left Speed

100 5945 100 5945 0  0 8704  0 --:--:-- --:--:-- --:--:-- 8691

Detected operating system as debian/buster.

Checking for curl...

Detected curl...

Checking for gpg...

Detected gpg...

Running apt-get update... done.

Installing debian-archive-keyring which is needed for installing

apt-transport-https on many Debian systems.

Installing apt-transport-https... done.

Installing /etc/apt/sources.list.d/runner_gitlab-runner.list...done.

Importing packagecloud gpg key... done.

Running apt-get update... done.

The repository is setup! You can now install packages.

Pro instalaci GitLab runneru využijeme příkaz, kdy vypneme “skel”, abychom zamezili budoucímu problému, s nenalezením souborů či složek. Problém se objevuje pouze na distribuci Debian / Buster.

export GITLAB_RUNNER_DISABLE_SKEL=true

Následně přejdeme k instalaci runneru.

apt-get install gitlab-runner

VPS Centrum

Vyzkoušejte zdarma naši aplikaci pro správu serveru a domén. Budete si připadat jako zkušený administrátor.

3. Krok –⁠⁠⁠⁠⁠⁠ Zaregistrujeme GitLab runner

Přihlásíme se na GitLab.com a pod vašim projektem půjdeme do sekce Settings > CI/CD, kde rozšíříte formulář s Runnery jako na obrázku níže.

Ujistěte se, že tzv. Shared runners jsou vypnuté, abychom mohli pushovat pomocí specifického runneru, který si teď jdeme nainstalovat.

Budeme potřebovat zaregistrovat runner s touto URL “https://gitlab.com/” a registrační token, který si zkopírujete.

Půjdeme tedy zase na SSH a zadáte příkaz:

gitlab-runner register

Poté vložíte URL: https://gitlab.com/
Zadáte token z administrace
Můžete vložit popisek runneru (volitelné)
Přidat tag nebo-li označení runneru: deploy
Vybereme spouštěč runneru v našem případě: shell

Vystup příkazu:

root@rve03-david-janik ~ # gitlab-runner register

Runtime platform  arch=amd64 os=linux pid=13937 revision=775dd39d version=13.8.0

Running in system-mode.

Enter the GitLab instance URL (for example, https://gitlab.com/):

https://gitlab.com/

Enter the registration token:

wY6-7ZjSggxiST-fXuKV

Enter a description for the runner:

[rve03-david-janik.vas-server.cz]: testing

Enter tags for the runner (comma-separated): deploy

Registering runner... succeeded  runner=wY6-7ZjS

Enter an executor: shell, ssh, docker+machine, docker-ssh+machine, kubernetes, custom, parallels, virtualbox, docker, docker-ssh:

shell

Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

Můžeme si ověřit, jestli runner v pořádku běží příkazem:

gitlab-runner verify

Výstup by měl vypadat:

root@rve03-david-janik ~ # gitlab-runner verify

Runtime platform  arch=amd64 os=linux pid=14651 revision=775dd39d version=13.8.0

Running in system-mode.

Verifying runner... is alive  runner=YawZ9Ssz

Když se pak vrátíme do administrace na GitLab.com a aktualizujeme stránku v nastavení CI / CD, tak nově registrovaný runner už uvidíme. Viz.

A už nám zbývají poslední dva kroky. Vytvořit konfigurační soubor .gitlab-ci.yml, který z odpovídá za práci runneru a jejich chování a jako poslední krok přidáme SSH klíč.

Tady si už vystačíme z minulého návodu, kde jsme nastavili deploy nejdříve na devel a poté se změny propíšou i na produkční verzi. Každý projekt, vývojář by si měl ale takový soubor umět vytvořit sám, tak aby pokryl svoje potřeby.

4. Krok –⁠⁠⁠⁠⁠⁠ Vytvoření konfiguračního souboru .gitlab-ci.yml

V nově vytvořeném projektu vytvoříme 3 důležité soubory:

.gitlab-ci.yml (script zodpovědný za deploy)
.deploy_ignore (které složky se při deploy nekopírují)
.gitignore (git dané soubory nebo složky bude ignorovat)

Pod námi je skript, který vložíte přímo do souboru .gitlab-ci.yml , samozřejmě “variables” vyměníte za svoje údaje/domény.

Pomocí skriptu pod námi budeme uploadovat změny/soubory do dvou složek. Do vývojové, která je zobrazena jako “devel” a pak poputují přimo do produkce.

variables:

  PROJECT_NAME: "test-gitlab-vh"

  PRODUCTION_DIR: "/www/hosting/vas-hosting.cz/www"

  PRODUCTION_SERVER: "rve03.vas-server.cz"

  DEVELOP_DIR: "/www/hosting/vas-hosting.cz/devel"

  DEVELOP_SERVER: "rve03.vas-server.cz"

  DEPLOY_USER: "deploy"

stages:

  - deploy

deploy-job:

  stage: deploy

  tags:

    - deploy

  only:

    - production    

  script:

    - rsync -ar --compress --delete --exclude-from=.deploy_ignore --rsync-path="sudo rsync" --chown=www-data:www-data --exclude-from=.gitignore . $DEPLOY_USER@$PRODUCTION_SERVER:$PRODUCTION_DIR

deploy-local-master-job:

  stage: deploy
 
  tags:

      - deploy   

  only:

    - master
    
  script:

    - rsync -ar --compress --delete --exclude-from=.gitignore --rsync-path="sudo rsync" --chown=www-data:www-data --exclude-from=.deploy_ignore . $DEPLOY_USER@$DEVELOP_SERVER:$DEVELOP_DIR/

deploy-local-job:

  stage: deploy 

  tags:

      - deploy 

  except:

    - master

    - production

  script:

    - rsync -ar --compress --delete --exclude-from=.gitignore --rsync-path="sudo rsync" --chown=www-data:www-data --exclude-from=.deploy_ignore . $DEPLOY_USER@$DEVELOP_SERVER:$DEVELOP_DIR/$PROJECT_NAME-$CI_BUILD_REF_NAME

5. Krok –⁠⁠⁠⁠⁠⁠ Nastavení SSH klíče

Poslední část je nejvíce záludná a týká se vygenerování a správného nastavení SSH klíčů.

Pro vygenerování nového SSH klíče používáme metodu RSA, která se nám osvědčila.

Jako první se musíme přihlásit z roota pod uživatele “gitlab-runner”, který byl při instalaci Gitlabu automaticky vytvořen.

su gitlab-runner

Vygenerujeme SSH klíč.

ssh-keygen -o -t rsa -b 4096

Po vygenerování se vás zeptá, jestli chcete nechat defaultní cestu a pokud ano, stiskněte Enter. Poté se vás zeptá, jestli chcete zaheslovat SSH klíč, a to v našem případě rozhodně nechceme = stiskněte 2x enter.

Poté už se zobrazí klíč podobný tomuto:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQClpCnfh7fzJEKSu1+qXw9Rg5vx9S5tAtC2f57wF2JxjlodvaNvaeTK0yZjpOjwVZ4ZyRS5KNuh8QexPMV0tdMaxM2rnrdFU3PaDPNT2zUE2vz6NBkNwCNb7rhMQCGZGuU9T8b6/JAAMzmJudu2vgS3vFVuKbAohjECiWxK+gtVY5K6F4Z29PoOxNKAlHgvbkFYnCnSsXHruwTsjvmBWC95u/uzDwJLJsS6S9qCYnKHXUq4knIaD67LIqSrgDeel/LQBi0/FrZCrptG2hiz1bIb6VibQctTlYEIoKNfShYila/f5qXiQNkdeXF/38CBl2tsxMUBcQGLnZiSsxx4703O+kDxX+l3C2Y4MXdyWYPzFEXVVwXN5fXBBgmCjBiUYSyP1uq/nocUpSOo56I1MrIf/KZFbeCb2MCppiwA4wfceTfplpiH0U1YVHbQ7KJW+gHS2DZKefMEoA1UabGIcDKEQyM2NAdOioqatOLwjUj2jE0D6tggfoQ2tnc01Tgq1T0eGlvRPmS1gbgmPFDyKUoIvj9ODyPycyQFePoJWVdJb7wcvliVzU8grpRcBSch2KZbKMkHDFYPEc8TXL+BrBDQXs8wXjP7jNtIGRh4a8+idWlj4605cFEr6uk0pGivV6jyRK4xKwiMKB5J7I0VSWSL9+dRfXQcOdah2E+sWTJUxQ== gitlab-runner@xxx08-vh-test-gitlab2.vas-server.cz

Tento klíč si uložíme do poznámkového bloku, protože se nám bude za chvilku hodit.

Mezitím se STÁLE pod uživatelem gitlab-runner přihlásíme na ssh pod uživatele deploy.

ssh deploy@xxx11.vas-server.cz

Zeptá se vás to pouze napoprvé, jestli chcete tomuto serveru důvěřovat a napíšete: yes

Můžeme si otevřít další terminal či se přihlásit zpět na roota a následně se přihlásíme pod uživatele “deploy”.

su deploy

A musíme se podívat, jestli uživatel deploy má vytvořenou složku /.ssh.

cd ~

ls -a

Pokud složku .ssh neuvidíme, tak pokračujeme příkazem:

mkdir .ssh

cd .ssh

touch authorized_keys

Poslední příkaz vytvoří soubor, kam se následně vkládají SSH klíče.

Poté pod rootem je třeba vložit SSH klíč tímto příkazem pod uživatele deploy. (Vyměňte za svůj SSH klíč):

echo "from="46.234.108.7,gitlab.vasedomena.com",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa  AAAAB3NzaC1yc2EAAAADAQABAAACAQClpCnfh7fzJEKSu1+qXw9Rg5vx9S5tAtC2f57wF2JxjlodvaNvaeTK0yZjpOjwVZ4ZyRS5KNuh8QexPMV0tdMaxM2rnrdFU3PaDPNT2zUE2vz6NBkNwCNb7rhMQCGZGuU9T8b6/JAAAbmJudu2vgS3vFVuKbAohjECiWxK+gtVY5K6F4Z29PoOxNKAlHgvbkFYnCnSsXHruwTsjvmBWC95u/uzDwJLJsS6S9qCYnKHXUq4knIaD67LIqSrgDeel/LQBi0/FrZCrptG2hiz1bIb6VibQctTlYEIoKNfShYila/f5qXiQNkdeXF/38CBl2tsxMUBcQGLnZiSsxx4703O+kDxX+l3C2Y4MXdyWYPzFEXVVwXN5fXBBgmC jBiUYSyP1uq/nocUpSOo56I1MrIf/KZFbeCb2MCppiwA4wfceTfplpiH0U1YVHbQ7KJW+gHS2DZKefMEoA1UabGIcDKEQyM2NAdOioqatOLwjUj2jE0D6tggfoQ2tnc01Tgq1T0eGlvRPmS1gbgmPFDyKUoIvj9ODyPycyQFePoJWVdJb7wcvliVzU8grpRcBSch2KZbKMkHDFYPEc8TXL+BrBDQXs8wXjP7jNtIGRh4a8+idWlj4605cFEr6uk0pGivV6jyRK4xKwiMKB5J7I0VSWSL9+dRfXQcOdah2E+sWTJUxQ== gitlab-runner@xxx08-vh-test-gitlab2.vas-server.cz ~deploy/.ssh/authorized_keys

Pokud vše proběhlo úspěšně, tak se můžete zpátky přihlásit pod uživatele “deploy” a podívat se jestli se klíč v pořádku vložil.

cat  ~/.ssh/authorized_keys

Nadále rsync potřebuje, aby uživatel deploy mohl spouštět “sudo” bez nutnosti zadávat heslo. Na to nám stačí 2 příkazy, které musíme spustit pod rootem.

echo "deploy  ALL=(root) NOPASSWD:/usr/bin/rsync,/usr/sbin/nginx

deploy    ALL=(www-data) NOPASSWD:ALL" > /etc/sudoers.d/deploy

chmod 0440 /etc/sudoers.d/deploy

Po těchto příkazech nám deploy začne fungovat!

Stačí jít do jakéhokoliv souboru a po kliknutí na edit udělat nějakou změnu. Klidně jenom přidat řádek navíc a po kliknutí na “Commit changes” se spustí uploadování změn.

Následně v sekci CI / CD > Pipelines uvidíte veškeré změny, které proběhly a vždy chceme vidět zelenou fajfku na znamení, že je všechno v pořádku.

Doporučujeme se poté připojit na FTP a zkontrolovat, že se soubor nahrál do složky na produkční i develovou verzi, jak je specifikováno v konfiguračním souboru(.gitlab-ci.yml). Vyzkoušejte i jestli GitLab správně ignoroval složky nebo soubory, které jste do souboru .deploy_ignore nastavili.