Vlastní GitLab CI Runner v Docker kontejneru na VPS?

GitLab CI, každý z nás se s ním již setkal, ať už z doslechu, nebo z praxe. Pokud používáte vlastní GitLab, můžete článek rovnou přeskočit, neboť určitě máte vlastní runnery vyřešené.
Budu se bavit o menších projektech umístěných rovnou na GitLab.com. Největší bolestí těchto projektů jsou sdílené runnery, jak se jich zbavit?

Co budete potřebovat:

  • Vlastní stroj ideálně s linuxem
  • Nainstalovaný Docker na stroji
  • Maximálně 10 minut vašeho času
  • Chuť posunout Váš projekt na vyšší úroveň

Příklad:

Mám dockerizovanou aplikaci, potřebuji aby při „oštítkování“ (vydání nové verze), se spustila pipeline, vybuildila image, nahrála a spustila jej na cílovém stroji.
Stává se ale, že sdílené runnery jsou pomalé a hlavně budete časem narážet na časové limity se spuštěním.

Návod:

  1. Přihlásím se do GitLab.com, vyberu projekt a kliknu na „Settings -> CI/CD -> Runners -> Expand“
  2. Zajímá nás blok „Set up a specific Runner manually“
  3. Přihlásím se na server přes SSH (Používám nástroj SuperPutty velice dobrá fíčurka, jinými slovy grafické klikátko pro Oknaře)
  4. Spustím příkaz „docker run –rm -d -t -i –network=host -v /srv/gitlab-runner-docker/config:/etc/gitlab-runner -v /var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner“
  5. Následně budu vyzván k zadání informací z bodu 1. – token a gitlab URL
  6. Docker executor type, je důležité zvolit podle toho, co budeme chtít aby runner dělal. Já osobně používám kombinaci „docker“ na build imagů a „shell“ pro deploy
  7. Voalá GitLab CI Runner funguje 🙂

Postřehy / poznámky:

  • Dávat si pozor na mountované volumes
  • Přečíst si něco o Docker executor type – valmi duležité
  • Nevzdávat se po prvním neúspěchu