Skip to content

Blog

Instalacja Gitlab Runner

W tym wpisie pokażę krok po kroku, jak instaluję GitLab Runnera w praktycznym, produkcyjnym scenariuszu. Skupię się na sprawdzonym podejściu, które stosuję na co dzień — bez zbędnej teorii, za to z naciskiem na poprawną konfigurację, bezpieczeństwo i typowe pułapki, na które łatwo trafić przy pierwszym uruchomieniu runnera.

Jeśli korzystasz z GitLaba do automatyzacji procesów CI/CD i chcesz mieć pełną kontrolę nad tym, gdzie i jak wykonywane są joby, ten materiał jest właśnie dla Ciebie.

Image builder

Budowanie własnych kontenerów w procesie CI/CD może wydawać się skomplikowane, ale wcale nie musi takie być. W tym wpisie pokażę krok po kroku, jak przygotować pipeline do budowania i publikowania obrazów kontenerowych z użyciem narzędzia Buildah.

Dziś przedstawie wam, jak zbudowałem własny image builder, krok po kroku.

Buildah pozwala tworzyć obrazy kontenerów bez uruchamiania demona i bez konieczności posiadania Dockera.

  • Brak demona Buildah działa jako zwykłe polecenie CLI – nie wymaga działającego serwisu w tle (jak dockerd).
  • Rootless (bez uprawnień roota) Może budować obrazy jako zwykły użytkownik, co znacząco poprawia bezpieczeństwo.
  • Zgodność z OCI / Docker Tworzone obrazy są w pełni kompatybilne z Dockerem, Podmanem, Kubernetesem itd.
  • Skryptowalność Buildah jest zaprojektowany jako zestaw niskopoziomowych poleceń (buildah from, buildah run, buildah commit), idealnych do automatyzacji w bashu lub CI.
  • Dockerfile – opcjonalnie Obsługuje Dockerfile (buildah bud), ale nie wymusza ich użycia.

Konfiguracja .gitconfig

Git ma opinię narzędzia prostego: pobierz zmiany, utwórz commit, wypchnij branch. Przy większej liczbie repozytoriów szybko okazuje się jednak, że kilka ustawień globalnych potrafi wyeliminować powtarzalne polecenia i ujednolicić codzienną pracę.

Mój plik ~/.gitconfig nie jest rozbudowany. Koncentruje się na czytelnej historii, przewidywalnym zachowaniu nowych branchy, współdzielonych hookach oraz kilku aliasach do operacji wykonywanych regularnie. W tym artykule przejdę przez jego najważniejsze sekcje i wyjaśnię, dlaczego są przydatne.

Dev Containers w VS Code - jedno środowisko dla wielu projektów

Pracując nad wieloma projektami infrastrukturalnymi szybko trafiamy na ten sam problem: każdy z nich wymaga odpowiedniej wersji narzędzi, rozszerzeń edytora i konfiguracji środowiska. OpenTofu, Ansible, Vault, Go, Python, direnv, certyfikaty, pluginy VS Code - lista rośnie, a ręczne przygotowanie kolejnego laptopa lub maszyny wirtualnej zabiera czas.

Rozwiązaniem są Dev Containers: kontenery developerskie uruchamiane bezpośrednio z Visual Studio Code. Repozytorium devcontainers zbiera gotowe profile środowisk oraz helpery, które pozwalają podpinać je do kolejnych projektów.

Nadpisanie teraform states

Terraform GitLab States pozwala na zarządzanie i synchronizację stanu infrastruktury bezpośrednio w ramach projektu GitLab. Dzięki temu możliwe jest centralne przechowywanie i kontrola stanu, co ułatwia współpracę zespołową oraz automatyzację procesów CI/CD. W niniejszym dokumencie przedstawiono sposób wysyłania zmian do istniejącego stanu OpenTofu do GitLab za pomocą API.