Github Actions – self-hosted runner

W pierwszym wpisie na temat Github Actions wspominałem, że za darmo mamy do wykorzystania 2000 minut akcji. 2000 minut to ok 33 godziny, wydaje się dużo, ale czy na pewno? Jeden mały błąd (brak timeout), push wieczorem i rano budzimy się biedniejsi o 500 zużytych minut-akcji. Pomnóżmy to razy 2 akcje i połowa z budżetu poszła 🔥 . Są 3 rozwiązania na to:

1. Ograniczyć czas wykonywania akcji poprzez timeout-minutes
2. Zapłacić za więcej minut
3. Postawić swój własny runner

Właśnie 3 opcję opiszę w tym wpisie.

Spis treści

1. Słowem wstępu
2. Co będziemy potrzebować
3. Uruchomienie runnera na serwerze
4. Generowanie Personal Access Token na Github
5. Weryfikacja konfiguracji

Słowem wstępu

Uruchomienie Github runner’a będę opisywał na przykładzie obrazu Dockerowego. Jeśli coś mogę uruchomić z wykorzystaniem Dockera, to tak też robię.

Co będziemy potrzebować

• własny serwer z zainstalowanym Dockerem
• 15 minut wolnego czasu
• Personal access tokens z Githuba
• Przykładową akcję w celu sprawdzenia, czy wszystko działa 🙂

Uruchomienie runnera na serwerze

Aby uruchomić runnera możemy skorzystać z gotowego obrazu myoung34/github-runner. Dla ułatwienia przygotowałem już gotowy docker compose – miłej copy-pasty 🍝

version: "3"
 services:
   ghactions:
     image: myoung34/github-runner:latest
     environment:
       REPO_URL: ADRES_REPOZYTORIUM
       RUNNER_NAME: NASZA_NAZWA_RUNNERA
       # RUNNER_NAME_PREFIX: PREFIX_RUNNERA JEŚLI NAZWA MA BYĆ WYGENEROWANA LOSOWO (np podczas skalowania)
       ACCESS_TOKEN: PERSONAL_ACCESS_TOKEN Z GITHUBA
       # RUNNER_TOKEN: TOKEN_RUNNERA (LEPIEJ PODAĆ PAT Z GITHUBA)
       RUNNER_WORKDIR: /tmp/runner/work
       RUNNER_GROUP: NAZWA_GRUPY_RUNNERA
       ORG_RUNNER: "false"
       LABELS: linux,x64,nasze,labelki,po,przecinku
     restart: always
     security_opt:
       - label:disable
     volumes:
       - "/var/run/docker.sock:/var/run/docker.sock"
       - "/tmp/runner:/tmp/runner"

Na co należy zwrócić uwagę.

Jeśli podajemy RUNNER_NAME to nie podajemy RUNNER_NAME_PREFIX i vice versa.

Dlaczego lepiej skorzystać z ACCESS_TOKEN niż RUNNER_TOKEN? RUNNER_TOKEN ważny jest przez 60 minut od utworzenia. Jeśli po tym czasie dojdzie do restartu kontenera to dostaniemy błąd unauthorized. Korzystając z ACCESS_TOKEN token dla runnera zostanie wygenerowany automatycznie.

Generowanie Personal Access Token na Github

Aby wygenerować Personal access token należy przejść na tą stronę a następnie ustawić uprawnienia:

• repo (all)
• admin:org (all) (wymagane dla runnera organizacji)
• admin:public_key – read:public_key
• admin:repo_hook – read:repo_hook
• admin:org_hook
• notifications
• workflow

Weryfikacja konfiguracji

Po uruchomieniu kontenera oczywiście musimy sprawdzić w logach, czy wszystko działa.

Sprawdźmy na Githubie – ustawienia projektu, podstrona Actions

Uruchomienie akcji na self-hosted runner

No to przechodzimy do ostatecznej weryfikacji 🙂

Czas zamienić:

jobs:
  Build-Docker-Images:
    runs-on: ubuntu-latest #tutaj zmiana
    timeout-minutes: 20

Na:

jobs:
  Build-Docker-Images:
    runs-on: self-hosted #tutaj zmiana
    timeout-minutes: 20

Puszczamy akcję i patrzymy czy wszystko jest ok 🙂
Mam nadzieję, że szybko uda Ci się uzyskać sukces Twojego builda na własnym runnerze.

• Github Actions czy Jenkins? Czy warto korzystać z Github Actions?
• Github Actions – budowa i testowanie aplikacji
• Github Actions – budowa obrazów Dockerowych i wrzucenie ich do repozytorium
• Github Actions – self-hosted runner