RACHUNA.DEV | Blog

Instalacja Gitlab Runner

Thu, 04 Jun 2026 00:00:00 GMT

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.

Krok po kroku

Utworzenie maszyn wirtualnych
- Definicja vm gitlab-runner-1022
- Definicja vm gitlab-runner-1023
- Definicja vm gitlab-runner-1024
Utworzenie repozytoriów
- Definicja repozytorium dev.rachuna/infrastructure/gitlab-rachuna-net/ansible

Utworzenie projektu ansible

ansible 1.0.2

Definicja hostów

---
all:
  children:
    vault:
    gitlab_runners:
      children:
        nodes:
          hosts:
            gitlab-runner-1002:
            gitlab-runner-1003:
            gitlab-runner-1004:

host_vars/ct01002/gitlab-runner.yml

---
inv_gitlab_runner_configuration:
  concurrent: 100
  check_interval: 0
  shutdown_timeout: 0
  session_timeout: 3600
  runners:
    - name: "{{ inventory_hostname }}.gitlab"
      url: "https://gitlab.com"
      register_runner:
        id: 53317509
        token: "{{ inv_secret_gitlab_runner_token }}"
        register_gitlab_api_token: "{{ ivn_secret_gitlab_api_token }}"
        description: "GitLab Runner for dev.rachuna"
        tag_list: ["rachuna-dev"]
        runner_type: "group_type"
        group_id: 132728705
        access_level: "not_protected"
      executor: "docker"
      docker:
        tls_verify: false
        image: "registry.gitlab.com/dev.rachuna/artifacts/containers/python:1.0.0"
        privileged: true
        disable_entrypoint_overwrite: false
        oom_kill_disable: false
        disable_cache: false
        volumes:
          - "/cache:/cache"
          - "/var/run/docker.sock:/var/run/docker.sock"
        shm_size: 0
        network_mode: "host"

Napisanie roli ansible
- gitlab-runner 1.0.2
Uruchomienie procesu CI/CD

Image builder

Wed, 03 Jun 2026 00:00:00 GMT

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.

Kluczowe cechy

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.

Krok po kroku

Utworzenie repozytoriów

Definicja repozytorium dev.rachuna/artifacts/containers/buildah

Utworzenie kontenera mechanizmem .devcontainer i opublikowanie w gitlab

Dokładny opis znajdziesz w tym artykule

dokerfile:

FROM ubuntu:noble

ENV DEBIAN_FRONTEND=noninteractive
ENV STORAGE_DRIVER=vfs
ENV BUILDAH_ISOLATION=chroot

COPY scripts/ /opt/scripts/

# Install system dependencies and ansible
RUN apt-get update && apt-get install -y \
        buildah \
        curl \
        fuse-overlayfs \
        gzip \
        slirp4netns \
        iproute2 \
        uidmap \
        iputils-ping \
        dnsutils \
        ca-certificates \
        git \
        curl \
        gnupg \
        sudo \
        software-properties-common \
        tar \
        yq \
        zip \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/* \
    && mkdir -p /tmp/buildah-root \
    && mkdir -p /tmp/buildah-runroot \

    # Make scripts executable
    && chmod +x /opt/scripts/*.bash

ENTRYPOINT ["/opt/scripts/entrypoint.bash"]

Przygotowanie procesu CI

Dokładny kod znajdziesz tutaj

Napisanie konfiguracji dla obrazu buildah

Wydanie wersji buildah 1.0.0

---
base_image: ubuntu:noble

labels:
  maintainer: "Maciej Rachuna <rachuna.maciej@gmail.com>"
  description: Kontener z narzędziem Buildah, wykorzystywany w procesach budowania kontenerów w środowisku GitLab CI.
  version: "1.0.0"
  image_source: "https://gitlab.com/dev.rachuna/containers/buildah"

env:
  DEBIAN_FRONTEND: noninteractive
  TF_IN_AUTOMATION: "true"
  LANG: C.UTF-8

before_build_commands: []

packages:
  - bash
  - buildah
  - curl
  - fuse-overlayfs
  - git
  - gzip
  - gnupg2
  - iproute2
  - iputils-ping
  - jq
  - dnsutils
  - libssl3
  - lsb-release
  - openssh-client
  - ca-certificates
  - gnupg
  - slirp4netns
  - uidmap
  - sudo
  - software-properties-common
  - yq
  - zip


custom_repos: []

extra_commands:
  - buildah --version

copy: []

user: null

entrypoint: null
cmd: "/bin/bash"

Skalowanie dla pozostałych kontenerów

Przykład: Wydanie wersji opentofu 1.0.0

Konfiguracja .gitconfig

Tue, 02 Jun 2026 00:00:00 GMT

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.

Tożsamość autora commitów

Pierwsza sekcja określa dane autora zapisywane w commitach:

[user]
    name = Maciej Rachuna
    email = <adres-email>

Git umieszcza te wartości w metadanych każdego nowego commita. Nie jest to mechanizm uwierzytelniania do GitLaba ani GitHuba. Adres e-mail pozwala platformie powiązać commit z kontem użytkownika, ale dostęp do zdalnego repozytorium nadal wymaga osobnej autoryzacji.

Adresu używanego lokalnie nie publikuję w przykładzie. W publicznym repozytorium można zastąpić go adresem noreply, jeżeli platforma hostingowa udostępnia taki wariant.

Czytelniejszy log

Domyślne git log zawiera dużo informacji, ale przy szybkim przeglądaniu historii przydaje się krótszy format:

[pretty]
    slim = "%C(red)%h%C(yellow)%d%C(reset) %s %C(green)(%cd) %C(bold blue)<%an>%C(reset)"

[alias]
    lg = log --graph --abbrev-commit --decorate --date=relative --pretty=slim
    lg1 = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(white)%s%C(reset) %C(dim white)(%cr) %C(green)<%an>%C(reset)'

Format slim składa się z:

Element	Znaczenie
`%h`	Skrócony hash commita.
`%d`	Referencje wskazujące commit, na przykład branch lub tag.
`%s`	Temat commita.
`%cd`	Data commita.
`%an`	Autor commita.

Alias lg używa tego formatu razem z grafem branchy i względną datą, na przykład 2 hours ago. lg1 jest alternatywną wersją z formatem zapisanym bezpośrednio w aliasie.

git lg
git lg1

Oba polecenia sprawdzają się lepiej niż surowe git log, gdy chcę szybko sprawdzić historię zmian i miejsca rozgałęzień.

Commity i praca z branchami

Kolejne ustawienia określają domyślne zachowanie podstawowych operacji:

[commit]
    gpgSign = false

[push]
    autoSetupRemote = true

[pull]
    rebase = false

[init]
    defaultBranch = main

commit.gpgSign = false wyłącza automatyczne podpisywanie commitów kluczem GPG. Commit nadal zawiera autora, ale nie otrzymuje kryptograficznego podpisu.

push.autoSetupRemote = true upraszcza pierwsze wypchnięcie nowego brancha. Zamiast:

git push --set-upstream origin feature/example

wystarczy:

git push

Git sam ustawi upstream dla bieżącego brancha.

pull.rebase = false oznacza, że git pull nie przepisuje lokalnej historii przez rebase. Jeżeli lokalny i zdalny branch się rozeszły, Git zachowuje model oparty na merge.

init.defaultBranch = main ustawia nazwę pierwszego brancha w nowych repozytoriach tworzonych przez git init.

Szybka poprawka ostatniego commita

Najbardziej automatyzujący alias w konfiguracji to:

[alias]
    amend = !git add . && git commit --amend --no-edit --date='now' && git push --force-with-lease

Polecenie:

git amend

wykonuje kolejno trzy operacje:

Dodaje wszystkie zmiany z bieżącego katalogu do staging area.
Nadpisuje ostatni commit bez zmiany jego opisu i aktualizuje datę.
Wysyła poprawiony commit do zdalnego repozytorium.

Warto też pamiętać, że git add . bierze pod uwagę pliki od bieżącego katalogu w dół. Najbardziej przewidywalny efekt daje uruchomienie aliasu z głównego katalogu repozytorium.

Wspólne ignore i hooki

Repozytoria umieszczam pod /repo, dlatego globalna konfiguracja odwołuje się do współdzielonych plików z tego katalogu:

[core]
    excludesfile = /repo/.gitignore_global
    hooksPath = /repo/git-hooks

core.excludesfile wskazuje globalny plik ignorowanych ścieżek. To dobre miejsce na pliki związane z lokalnym środowiskiem pracy, które nie powinny trafiać do .gitignore każdego projektu osobno.

Przykładowe wpisy:

.envrc
.env
.devcontainer
.vscode

core.hooksPath przenosi źródło hooków Git z domyślnego .git/hooks do wspólnego katalogu /repo/git-hooks. Jeden zestaw skryptów może dzięki temu działać we wszystkich lokalnych repozytoriach.

Zaufane repozytoria w `/repo`

Git chroni przed wykonywaniem operacji w repozytoriach należących do innego użytkownika systemowego. W środowiskach kontenerowych właściciel plików widoczny wewnątrz kontenera może różnić się od właściciela procesu, dlatego pojawia się ustawienie:

[safe]
    directory = /repo/*

Pozwala ono pracować z repozytoriami znajdującymi się bezpośrednio pod /repo. Jest to wygodne w Dev Containers, gdzie ten sam workspace jest montowany z hosta do kontenera.

Git domyślnie uruchamia pager, gdy wynik polecenia nie mieści się w terminalu. W mojej konfiguracji pager jest wyłączony dla najczęściej używanych komend:

[pager]
    branch = false
    diff = false
    log = false
    show = false

Dzięki temu git branch, git diff, git log i git show wypisują wynik bezpośrednio do terminala. Jest to wygodne zwłaszcza przy pracy w zintegrowanym terminalu VS Code oraz przy filtrowaniu wyników innymi narzędziami.

Konfiguracja zawiera również aliasy przeznaczone do uruchomienia zewnętrznego narzędzia difft:

[alias]
    dlog = !git -c diff.external=difft log --ext-diff
    dshow = !git -c diff.external=difft show --ext-diff

git dlog
git dshow HEAD

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

Mon, 01 Jun 2026 00:00:00 GMT

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.

Do czego służy Dev Containers w VS Code?

Rozszerzenie Dev Containers pozwala uruchomić środowisko developerskie zdefiniowane w pliku .devcontainer/devcontainer.json. VS Code nadal działa na hoście, ale serwer edytora, terminal i komendy projektu uruchamiane są już w kontenerze.

Dzięki temu:

wersje narzędzi są zapisane w kodzie zamiast w pamięci autora projektu,
nowy projekt można otworzyć bez instalowania całego toolchainu na hoście,
rozszerzenia VS Code są dobierane do rodzaju pracy,
kilka projektów może używać różnych środowisk bez konfliktów,
aktualizację wspólnych narzędzi można wykonać w jednym miejscu.

Pod spodem nadal działa Docker. Dev Containers dodaje warstwę integracji z VS Code: buduje obraz, uruchamia kontener, montuje workspace i otwiera projekt w ścieżce wskazanej przez konfigurację.

Jak zbudowane jest repozytorium?

Repozytorium rozdziela konfigurację na profile, wspólne skrypty i proste helpery:

devcontainers/
├── bin/
│   ├── devcontainer-link
│   ├── devcontainer-render
│   └── devcontainer-update
├── common/
│   ├── Dockerfile.base
│   ├── scripts/
│   └── snippets/
├── profiles/
│   ├── ansible/
│   ├── base/
│   ├── golang/
│   ├── opentofu/
│   ├── python/
│   └── vault/
└── templates/
    └── project-devcontainer/

Każdy profil zawiera dwa podstawowe pliki:

profiles/<profile>/devcontainer.json
profiles/<profile>/Dockerfile

devcontainer.json opisuje sposób uruchomienia środowiska przez VS Code: obraz, workspace, mounty, użytkownika oraz rozszerzenia edytora. Dockerfile buduje środowisko i instaluje potrzebne narzędzia. Powtarzalne kroki zostały przeniesione do common/scripts/, dzięki czemu nie trzeba kopiować tych samych instrukcji do każdego profilu.

Dostępne profile

Profil	Przeznaczenie
`base`	Bazowe środowisko developerskie z shellem, Gitem, `direnv`, Node.js i Codex CLI.
`opentofu`	Praca z OpenTofu oraz narzędziami dla kodu infrastruktury.
`ansible`	Środowisko dla projektów automatyzowanych przez Ansible.
`vault`	Praca z HashiCorp Vault CLI.
`golang`	Toolchain dla projektów Go.
`python`	Środowisko dla projektów Python, rozszerzone między innymi o `conftest`.

Pierwsze uruchomienie

Przed rozpoczęciem pracy potrzebne są:

Docker,
Visual Studio Code,
rozszerzenie Dev Containers,
lokalna kopia repozytorium devcontainers.

Najprostszy wariant to podpięcie profilu jako symlink. Helper devcontainer-link tworzy w projekcie dowiązanie .devcontainer do wybranego profilu.

Przejdź do repozytorium projektu

cd /repo/dev.rachuna/artifacts/opentofu/gitlab-group

Podepnij profil

/repo/dev.rachuna/devtools/devcontainers/bin/devcontainer-link opentofu

Efekt odpowiada ręcznemu utworzeniu dowiązania:

ln -s /repo/dev.rachuna/devtools/devcontainers/profiles/opentofu .devcontainer

Otwórz projekt w kontenerze

W VS Code uruchom polecenie:
```
Dev Containers: Reopen in Container
```
Poczekaj na zbudowanie obrazu

VS Code zbuduje obraz i ponownie otworzy projekt. Dla profilu opentofu wykona także kontrolne polecenie:
```
tofu version
```

Od tej chwili terminal otwierany w VS Code działa wewnątrz kontenera.

Dlaczego ścieżka projektu się nie zmienia?

Domyślnie Dev Containers montuje kod w katalogu podobnym do /workspaces/nazwa-projektu. W projektach infrastrukturalnych wygodniej jest zachować tę samą ścieżkę na hoście i w kontenerze, szczególnie gdy skrypty odwołują się do innych repozytoriów.

Profile takie jak opentofu konfigurują więc:

{
  "workspaceMount": "source=${localWorkspaceFolder},target=${localWorkspaceFolder},type=bind,consistency=cached",
  "workspaceFolder": "${localWorkspaceFolder}"
}

Jeśli projekt na hoście znajduje się tutaj:

/repo/dev.rachuna/artifacts/opentofu/gitlab-group

to po otwarciu kontenera nadal pracujemy w:

/repo/dev.rachuna/artifacts/opentofu/gitlab-group

Nie trzeba zmieniać ścieżek w skryptach ani zastanawiać się, czy polecenie zostało uruchomione na hoście, czy już w kontenerze.

Dwa sposoby podpinania profilu

Repozytorium obsługuje dwa warianty pracy. Wybór zależy od tego, czy projekt ma korzystać z centralnie utrzymywanego profilu, czy przechowywać własną kopię konfiguracji.

Wariant 1: symlink do profilu

/repo/dev.rachuna/devtools/devcontainers/bin/devcontainer-link opentofu /repo/dev.rachuna/artifacts/opentofu/gitlab-group

To najwygodniejsze rozwiązanie dla lokalnych projektów utrzymywanych na tej samej maszynie. Projekt zawsze korzysta z aktualnego profilu z repozytorium devcontainers. Po zmianie Dockerfile wystarczy w VS Code wykonać:

Dev Containers: Rebuild Container

Symlink ma jednak jedną ważną konsekwencję: projekt zależy od lokalnej ścieżki repozytorium devcontainers.

Wariant 2: renderowanie konfiguracji do projektu

Jeżeli projekt powinien zawierać własną, samowystarczalną kopię .devcontainer, można ją wygenerować:

/repo/dev.rachuna/devtools/devcontainers/bin/devcontainer-render opentofu /repo/dev.rachuna/artifacts/opentofu/gitlab-group

Helper zapisze:

.devcontainer/
├── .profile
├── Dockerfile
├── devcontainer.json
└── common/
    └── scripts/

Renderowana konfiguracja ma lokalny build context i własną kopię wspólnych skryptów. Można ją przechowywać razem z projektem, udostępniać innym osobom oraz modyfikować niezależnie od centralnego repozytorium.

Aby później odświeżyć wygenerowany wariant, wystarczy uruchomić:

/repo/dev.rachuna/devtools/devcontainers/bin/devcontainer-update /repo/dev.rachuna/artifacts/opentofu/gitlab-group

Polecenie odczyta nazwę profilu z .devcontainer/.profile i ponownie wykona render.

Co znajduje się w profilu?

Spójrzmy na najważniejsze fragmenty konfiguracji opentofu.

Build obrazu

{
  "build": {
    "dockerfile": "Dockerfile",
    "context": "/repo/dev.rachuna/devtools/devcontainers",
    "args": {
      "USERNAME": "mrachuna"
    }
  }
}

Kontekst budowania wskazuje repozytorium devcontainers, ponieważ Dockerfile korzysta ze wspólnych skryptów:

COPY common/scripts/ /tmp/devcontainer-scripts/

Integracja użytkownika i repozytoriów

{
  "remoteUser": "mrachuna",
  "mounts": [
    "source=${localEnv:HOME},target=/home/mrachuna,type=bind,consistency=cached",
    "source=/repo,target=/repo,type=bind,consistency=cached"
  ],
  "containerEnv": {
    "HOME": "/home/mrachuna"
  }
}

Kontener używa tego samego katalogu domowego i widzi drzewo /repo. Dzięki temu wewnątrz kontenera dostępne są między innymi konfiguracja shella, Git, SSH oraz sąsiednie projekty.

Rozszerzenia VS Code

Profil może automatycznie doinstalować rozszerzenia właściwe dla danego rodzaju projektu:

{
  "customizations": {
    "vscode": {
      "extensions": [
        "editorconfig.editorconfig",
        "redhat.vscode-yaml",
        "gamunu.opentofu",
        "ms-azuretools.vscode-docker",
        "timonwong.shellcheck"
      ]
    }
  }
}

Po otwarciu projektu dostajemy więc nie tylko CLI, lecz także gotowy edytor.

Jak rozwijać repozytorium?

Rozwój repozytorium polega najczęściej na aktualizacji wspólnego skryptu, zmianie istniejącego profilu albo dodaniu kolejnego profilu.

Zmiana wspólnego narzędzia

Jeżeli narzędzie ma znaleźć się w kilku środowiskach, dodaj lub zmodyfikuj skrypt w:

common/scripts/

Następnie wywołaj go w Dockerfile odpowiednich profili. Przykładowo instalacja direnv jest współdzielona przez wiele obrazów:

RUN bash /tmp/devcontainer-scripts/install-direnv

Aktualizacja istniejącego profilu

Każdy profil rozwijamy w jego katalogu:

profiles/opentofu/
├── Dockerfile
└── devcontainer.json

Zmiana w Dockerfile wpływa na zawartość obrazu. Zmiana w devcontainer.json wpływa na sposób uruchamiania kontenera przez VS Code: mounty, rozszerzenia, użytkownika, workspace i komendy startowe.

Dodanie nowego profilu

Utwórz katalog profilu
```
mkdir -p profiles/<nazwa-profilu>
```
Dodaj Dockerfile

Wybierz możliwie prosty obraz bazowy i wykorzystaj skrypty z common/scripts/.
Dodaj devcontainer.json

Skonfiguruj build, remoteUser, mounty, workspace oraz rozszerzenia VS Code dopasowane do technologii.

Sprawdź profil lokalnie

Podepnij go do testowego projektu:

bin/devcontainer-link <nazwa-profilu> /tmp/devcontainer-profile-test

Następnie otwórz katalog w VS Code i wykonaj:

Dev Containers: Rebuild and Reopen in Container

Walidacja zmian

Przed wysłaniem zmian warto wykonać podstawowe testy statyczne:

jq empty profiles/*/devcontainer.json common/snippets/*.json

bash -n bin/devcontainer-render bin/devcontainer-link bin/devcontainer-update common/scripts/*

Można również sprawdzić renderowanie na katalogu tymczasowym:

mkdir -p /tmp/devcontainer-render-test
bin/devcontainer-render opentofu /tmp/devcontainer-render-test

Na końcu pozostaje test praktyczny: przebudowanie kontenera w VS Code oraz uruchomienie podstawowego polecenia dla danego profilu, na przykład:

tofu version

Kiedy używać którego wariantu?

Potrzeba	Najlepszy wybór
Kilka własnych projektów na jednej maszynie	`devcontainer-link`
Centralna aktualizacja środowiska bez kopiowania plików	`devcontainer-link`
Konfiguracja wersjonowana razem z projektem	`devcontainer-render`
Udostępnienie środowiska innym osobom	`devcontainer-render`
Niezależne dostosowanie `.devcontainer` w konkretnym projekcie	lokalna kopia po `devcontainer-render`

Dev Containers dobrze rozwiązuje problem powtarzalnego warsztatu pracy. Zamiast dokumentować kolejną listę pakietów do ręcznej instalacji, utrzymujemy wykonywalną definicję środowiska. VS Code staje się wejściem do projektu, Docker zapewnia izolację, a wspólne profile pozwalają rozwijać narzędzia w jednym miejscu.

Nadpisanie teraform states

Fri, 29 May 2026 00:00:00 GMT

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.

Popsułem terraform state, ale mam backup :)

Mając lokalnie plik tfstate można w bardzo szybki sposób go nadpisać, wystarczy wykonać to polecenie

#!/bin/env bash
export PROJECT_ID=1234569
export TF_STATE_NAME="production"

curl --request POST \
     --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
     --header "Content-Type: application/json" \
     --data-binary "@tfstate.json" \
     "https://gitlab.com/api/v4/projects/${PROJECT_ID}/terraform/state/${TF_STATE_NAME}"

Integracja z projektem gitlab

Thu, 28 May 2026 00:00:00 GMT

Terraform State to mechanizm w Terraformie, który przechowuje aktualny stan zarządzanej infrastruktury. Jest to plik (domyślnie terraform.tfstate), w którym Terraform zapisuje informacje o zasobach, ich konfiguracji oraz zależnościach. Dzięki temu Terraform może:

Śledzić zmiany – porównuje aktualną infrastrukturę ze skonfigurowaną w kodzie, identyfikując różnice.
Optymalizować działania – wie, które zasoby wymagają zmiany, zamiast tworzyć je od nowa.
Zarządzać zależnościami – rozumie, w jakiej kolejności tworzyć, aktualizować lub usuwać zasoby.
Współdzielić stan – umożliwia pracę zespołową poprzez zdalne przechowywanie stanu w backendach takich jak S3, GitLab czy Terraform Cloud.

Zarządzanie stanem jest kluczowe, dlatego warto używać zdalnego backendu zamiast przechowywać terraform.tfstate lokalnie, szczególnie w środowiskach zespołowych.

Ustawienie terraform state w ustawieniach repozytorium

export VAULT_ADDR="https://vault.local"
export VAULT_TOKEN="hvs.QWERTY"

export CI_SERVER_URL="https://gitlab.com/"
export CI_USERNAME="techuser"
export GITLAB_TOKEN="qwerty"
export CI_PROJECT_ID="123456789"
export TF_STATE_NAME="production"

terraform init \
    -backend-config="address=${CI_SERVER_URL}/api/v4/projects/${CI_PROJECT_ID}/terraform/state/${TF_STATE_NAME}" \
    -backend-config="lock_address=${CI_SERVER_URL}/api/v4/projects/${CI_PROJECT_ID}/terraform/state/${TF_STATE_NAME}/lock" \
    -backend-config="unlock_address=${CI_SERVER_URL}/api/v4/projects/${CI_PROJECT_ID}/terraform/state/${TF_STATE_NAME}/lock" \
    -backend-config="username=gitlab-ci-token" \
    -backend-config="password=${GITLAB_TOKEN}" \
    -backend-config="lock_method=POST" \
    -backend-config="unlock_method=DELETE" \
    -backend-config="retry_wait_min=5"

dla OpenTofu

export VAULT_ADDR="https://vault.local"
export VAULT_TOKEN="hvs.QWERTY"

export CI_SERVER_URL="https://gitlab.com/"
export CI_USERNAME="techuser"
export GITLAB_TOKEN="qwerty"
export CI_PROJECT_ID="123456789"
export TF_STATE_NAME="production"

tofu init \
  -backend-config="address=${CI_SERVER_URL}/api/v4/projects/${CI_PROJECT_ID}/terraform/state/${TF_STATE_NAME}" \
  -backend-config="lock_address=${CI_SERVER_URL}/api/v4/projects/${CI_PROJECT_ID}/terraform/state/${TF_STATE_NAME}/lock" \
  -backend-config="unlock_address=${CI_SERVER_URL}/api/v4/projects/${CI_PROJECT_ID}/terraform/state/${TF_STATE_NAME}/lock" \
  -backend-config="username=gitlab-ci-token" \
  -backend-config="password=${GITLAB_TOKEN}" \
  -backend-config="lock_method=POST" \
  -backend-config="unlock_method=DELETE" \
  -backend-config="retry_wait_min=5"

gdzie:

CI_PROJECT_ID - id projektu w gitlab
CI_SERVER_URL - serwer URL
TF_STATE_NAME - nazwa instancji state

Terraform state z procesu CI

Dokumentacja: https://docs.gitlab.com/ee/user/infrastructure/iac/terraform_state.html

Importowanie obiektów do tfstate

Wed, 27 May 2026 00:00:00 GMT

W poprzednich artykułach użyłem tofu import, ale nie wyjaśniłem dokładnie co robi to polecenie. Dziś się bardziej niemu przyjrzymy.

`tofu Import` – Co to jest i do czego służy?

tofu import to polecenie w OpenTofu, które umożliwia wprowadzenie istniejących zasobów do stanu (state) OpenTofu, bez konieczności ich tworzenia od zera. Jest to przydatne, gdy mamy zasoby zarządzane ręcznie lub przez inne narzędzia i chcemy przejąć nad nimi kontrolę za pomocą OpenTofu.

Do czego służy OpenTofu import?

Przejmowanie kontroli nad istniejącymi zasobami – jeśli masz już zasoby w chmurze (np. VM w AWS, projekt w GitLab, użytkowników w Azure), możesz je zaimportować do OpenTofu bez ich ponownego tworzenia.
Unikanie usuwania i ponownego tworzenia zasobów – jeśli ręcznie utworzony zasób nie znajduje się w stanie OpenTofu, ale istnieje, można go dodać do state, zamiast niszczyć i tworzyć od nowa.
Migracja do OpenTofu – jeśli zarządzałeś zasobami ręcznie lub przy pomocy innego narzędzia (np. Ansible, CloudFormation), możesz je przenieść do OpenTofu.

Przykłady importowanie obiektów

importowanie grupy gitlab

import {
  to = module.dev-rachuna.module.infrastructure.module.opentofu.module.group_modules.gitlab_group.group
  id = "100726684"
}

albo

tofu import module.dev-rachuna.module.infrastructure.module.opentofu.module.group_modules.gitlab_group.group 100726684

importowanie projektu gitlab

import {
    to = module.dev-rachuna.module.infrastructure.module.opentofu.module.modules.module.gitlab_group.gitlab_project.project
    id = "66189322"
}

albo

tofu import module.dev-rachuna.module.infrastructure.module.opentofu.module.modules.module.gitlab_group.gitlab_project.project 66189322

Zarządzanie projektami w gitlab

Tue, 26 May 2026 00:00:00 GMT

W poprzednim poście opisałem jak zarządzać grupami za pomocą opentofu. Dziś opowiem jak to robić z projektami.

Wymagania

zainstalowany opentofu
repozytorium iac-gitlab z zestawem definicji, który pozwala w deklaratywny sposób tworzyć i utrzymywać grupy oraz projekty w GitLabie.
Dwa moduły:
- gitlab-group - moduł opentofu do zarządzania grupami
- gitlab-project - moduł opentofu do zarządzania projektami

Krop po kroku

Przygotowanie devcontainer

profiles/opentofu
Napisanie logiki dla modułu gitlab-project

Wydanie wersji 1.0.0

Utworzenie definicji w `iac-gitlab-com` dla grup

Definicja repozytorium dev.rachuna/artifacts/opentofu/gitlab-group
Definicja repozytorium dev.rachuna/artifacts/opentofu/gitlab-project

Definicja repozytorium dev.rachuna/infrastructure/gitlab-com/iac-gitlab

tofu import module.pl_rachuna-dev.module.artifacts.module.opentofu.module.gitlab-group.gitlab_project.project 82399936
tofu import module.pl_rachuna-dev.module.artifacts.module.opentofu.module.gitlab-project.gitlab_project.project 82423317
tofu import module.pl_rachuna-dev.module.infrastructure.module.gitlab-com.module.iac-gitlab.gitlab_project.project 82399007

Jak zbudowane jest repozytorium `iac-gitlab` ?

Struktura katalogów odzwierciedla hierarchię GitLaba:

iac-gitlab-com
├── data/                                 # listy do walidacji (typy projektów, avatary, etykiety)
├── dev.rachuna/                          # główna grupa i jej podgrupy
│   ├── apps/        
│   │   └── docs.tf.json
│   ├── artifacts/
│   │    └── opentofu/
│   │         ├── gitlab-group.tf.json
│   │         └── gitlab-project.tf.json
│   └── infrastructure/
│       └── gitlab-com/
│           └── iac-gitlab.tf.json
└── _providers.tf.json                    # konfiguracja providerów (m.in. GitLab)

Tworzenie projektu

Moduł gitlab-project umożliwia definiowanie parametrów projektu:

{
  "module": {
    "iac-gitlab": {
      "source": "git::https://gitlab.com/dev.rachuna/artifacts/opentofu/gitlab-project.git?ref=1.0.0",
      "name": "iac-gitlab",
      "description": "IAC do zarządzania obiektami GitLab (gitlab.com).",
      "visibility": "public",
      "parent_group": "${local.parent_name}",
      "project_type": "opentofu-iac",
      "environments": {
        "production": {
          "external_url": "https://gitlab.com/dev.rachuna/infrastructure/gitlab-com/iac-gitlab/-/terraform"
        }
      }
    }
  }
}

Zarządzanie grupami w gitlab

Mon, 25 May 2026 00:00:00 GMT

OpenTofu coraz częściej wykorzystywany jest nie tylko do budowy infrastruktury chmurowej, lecz także do zarządzania całym ekosystemem usług.

Po co IaC dla GitLaba?

Automatyzacja: grupy i projekty tworzą się automatycznie na podstawie kodu.
Powtarzalność: każda zmiana jest opisana w repozytorium, a tofu plan pokazuje różnice.
Rozliczalność: pełna historia zmian wraz z informacją kto, gdzie i kiedy je zlecił.
Porządek: struktura katalogów odpowiada strukturze GitLaba, co ułatwia nawigację i odnalezienie definicji konkretnej grupy czy projektu.

Wymagania

zainstalowany opentofu
repozytorium iac-gitlab z zestawem definicji, który pozwala w deklaratywny sposób tworzyć i utrzymywać grupy oraz projekty w GitLabie.
Moduł:
- gitlab-group - moduł opentofu do zarządzania grupami

Krop po kroku

Przygotowanie devcontainer

profiles/opentofu
Utworzenie obiektów

Grupy:
- dev.rachuna
- dev.rachuna → artifacts
- dev.rachuna → artifacts → opentofu
- dev.rachuna → infrastructure
- dev.rachuna → infrastructure → gitlab-com
Repozytoria
- dev.rachuna → infrastructure → gitlab-com → iac-gitlab
- dev.rachuna → artifacts → opentofu → gitlab-group
Napisanie logiki dla modułu gitlab-group

Wydanie wersji 1.0.0

Utworzenie definicji w `iac-gitlab-com` dla grup i import

Definicja grupy dev.rachuna

tofu import module._pl_rachuna-net.gitlab_group.group 82399007

Definicja grupy dev.rachuna/apps
Definicja grupy dev.rachuna/artifacts
Definicja grupy dev.rachuna/devtools

Definicja grupy dev.rachuna/infrastructure

tofu import module.pl_rachuna-net.module._apps.gitlab_group.group 132755809
tofu import module.pl_rachuna-net.module._artifacts.gitlab_group.group 132732346
tofu import module.pl_rachuna-net.module._devtools.gitlab_group.group 132751910
tofu import module.pl_rachuna-net.module._infrastructure.gitlab_group.group 132730200

Definicja grupy dev.rachuna/artifacts/opentofu

tofu import module.pl_rachuna-net.module.artifacts.module._opentofu.gitlab_group.group 132732367

Definicja grupy dev.rachuna/infrastructure/gitlab-com

tofu import module.pl_rachuna-net.module.infrastructure.module._gitlab-com.gitlab_group.group 132730215

Wdrażanie zmian z opentofu
```
tofu apply -auto-approve
```

Jak zbudowane jest repozytorium `iac-gitlab-com` ?

Struktura katalogów odzwierciedla hierarchię GitLaba:

iac-gitlab-com
├── data/                # listy do walidacji (typy projektów, avatary, etykiety)
├── dev.rachuna/      # główna grupa i jej podgrupy
│   ├── apps/        
│   ├── artifacts/
│   │    └── opentofu/
│   ├── devtools/        
│   └── infrastructure/
│       └── gitlab-com/
└── _providers.tf        # konfiguracja providerów (m.in. GitLab)

Przykładowa definicja grupy

{
  "module": {
    "_devtools": {
      "source": "git::https://gitlab.com/dev.rachuna/artifacts/opentofu/gitlab-group.git?ref=main",
      "parent_group": "${local.parent_name}",
      "name": "devtools",
      "description": "Narzedzia i skrypty dla developerów",
      "visibility": "public",
      "avatar": "images/devtools.png"
    },
    "devtools": {
      "source": "./devtools/"
    }
  }
}

Statyczna strona na Gitlab pages

Fri, 22 May 2026 00:00:00 GMT

W tym wpisie pokaże wam, jak opublikować statyczną stronę internetową. Wykorzystam framweork astro

Pobranie repozytorium z moją stroną

git clone https://gitlab.com/dev.rachuna/apps/web.git

Krop po kroku

Utworzenie projektu astro
```
npm create astro@latest
```
Dostosywanie strony

Tworzymy prosty pipeline `.gitlab-ci.yml`

stages:
  - build
  - deploy

image: node:20-alpine

cache:
  key:
    files:
      - package-lock.json
  paths:
    - node_modules/

pages:
  stage: deploy
  script:
    - npm ci
    - npm run build
    # GitLab Pages wymaga artifactu w katalogu public
    - rm -rf public
    - mv dist public
  artifacts:
    paths:
      - public
  # rules:
  #   # publikuj tylko z domyślnej gałęzi
  #   - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Publikujemy stronę

Informacje o twojej stronie znajdziesz w Deploy → Pages

W moim przypadku otrzymałem taką stronę
```
https://web-2d99ae.gitlab.io/
```

Utworzenie domeny w pages

Repozytorium → Settings → Pages → kliknij New Domain

Ustawienie domeny rachuna.dev

GitLab wygeneruje dwa rekordy DNS:

ALIAS:

  docs.rachuna.dev.  ALIAS  dev.rachuna.gitlab.io.

TXT:

_gitlab-pages-verification-code.docs.rachuna.dev.  TXT  gitlab-pages-verification-code=<wygenerowany_kod>

Dodanie rekordów do DNS
Danger
Na podstawie instrukcji custom domains. Dla domen głównych nie można użyć ALIAS/CNAME, należy użyć rekordu A.
```
rachuna.dev.   A   35.185.44.232
```
GitLab automatycznie zweryfikuje rekordy i wygeneruje certyfikat SSL (Let’s Encrypt)

Przydatne linki

Moje środowisko LAB

Thu, 21 May 2026 00:00:00 GMT

W ostatnim czasie postanowiłem zrealizować długo odkładaną wizję – stworzyć własne laboratorium IT w domu, które pozwoli mi ćwiczyć i testować technologie DevOps w praktyce. Pomysł powstał z potrzeby eksperymentowania w środowisku zbliżonym do produkcyjnego, ale przy minimalnych kosztach i maksymalnej elastyczności.

Wybór sprzętu: Mini PC jako fundament laboratorium

Do budowy mojego LAB-a wybrałem trzy kompaktowe Mini PC. Powody są proste: niski pobór energii, cicha praca i wystarczająca moc obliczeniowa do uruchamiania wielu maszyn wirtualnych. Każda z maszyn będzie pełnić rolę węzła wirtualizacyjnego, na którym zainstaluję Proxmox VE – sprawdzone narzędzie do zarządzania wirtualizacją i kontenerami LXC/VM. Dzięki temu będę miał pełną kontrolę nad maszynami wirtualnymi, snapshotami i klastrami HA, co jest kluczowe przy testach infrastruktury.

Storage na Synology

Kluczowym elementem mojego LAB-a będzie centralny storage. Postawiłem na NAS Synology, który zapewnia nie tylko przestrzeń dyskową, ale również funkcje zaawansowanego zarządzania danymi, backupu i dostępności przez sieć. Wszystkie Mini PC będą korzystać z Synology jako magazynu dla maszyn wirtualnych i obrazów systemów, co pozwoli mi w prosty sposób tworzyć i przenosić VM-y pomiędzy węzłami. Dodatkowo, Synology umożliwia implementację iSCSI czy NFS, co idealnie integruje się z Proxmoxem.

Sieć zarządzana przez Mikrotika

Żeby móc testować złożone scenariusze sieciowe i DevOpsowe, potrzebowałem elastycznego rozwiązania do zarządzania siecią. W tym celu wybrałem router MikroTik. Dzięki niemu mogę tworzyć VLAN-y, testować routing, firewall, VPN-y i QoS. To pozwoli mi symulować środowiska produkcyjne, gdzie różne usługi i zespoły korzystają z odseparowanych segmentów sieci. MikroTik zapewnia też świetny interfejs do monitorowania ruchu i diagnostyki problemów w sieci.

Plany rozwoju: Kubernetes i DevOps

Budowa laboratorium to dopiero początek. Moim celem jest stopniowe wdrażanie technologii kontenerowych i DevOpsowych. W najbliższym czasie planuję postawić Kubernetes na trzech węzłach Mini PC, co pozwoli mi testować skalowanie aplikacji, zarządzanie konfiguracją, automatyczne deploymenty i monitoring usług.

Dalej chcę zintegrować narzędzia typowe dla DevOps, takie jak:

CI/CD – Jenkins, GitLab CI/CD lub ArgoCD,
Monitoring i logowanie – Prometheus, Grafana, Loki,
Kontenery i obrazowanie – Docker i Harbor,
Zarządzanie konfiguracją – Ansible, Terraform, Helm.

Dzięki temu będę mógł ćwiczyć całe cykle DevOpsowe – od budowy aplikacji, przez automatyzację wdrożeń, aż po monitoring i optymalizację wydajności.

Zalety własnego LAB-a

Posiadanie własnego środowiska testowego daje nieocenione możliwości:

Eksperymentowanie bez ryzyka – mogę testować konfiguracje produkcyjne bez obawy o wpływ na rzeczywiste systemy.
Praktyczna nauka – od wirtualizacji, przez sieci, po Kubernetes i CI/CD.
Elastyczność – możliwość szybkiego tworzenia i usuwania maszyn wirtualnych, wdrażania usług i testowania scenariuszy awaryjnych.
Nauka DevOps od A do Z – zrozumienie, jak wszystkie warstwy infrastruktury współpracują ze sobą.

Podsumowanie

Budowa domowego laboratorium DevOps na Mini PC, z Proxmoxem, Synology jako centralnym storage’em i siecią zarządzaną przez MikroTika, to nie tylko świetna zabawa, ale też praktyczna inwestycja w rozwój umiejętności IT. W przyszłości planuję rozbudować LAB o Kubernetes, narzędzia CI/CD i monitoring, co pozwoli mi w pełni odtworzyć środowisko zbliżone do rzeczywistego centrum danych. To idealne miejsce do nauki, testowania i eksperymentowania z nowoczesnymi technologiami DevOps.

RACHUNA.DEV | Blog

Instalacja Gitlab Runner

Krok po kroku

Utworzenie maszyn wirtualnych

Utworzenie repozytoriów

Utworzenie projektu ansible

Napisanie roli ansible

Uruchomienie procesu CI/CD

Image builder

Kluczowe cechy

Krok po kroku

Utworzenie repozytoriów

Utworzenie kontenera mechanizmem .devcontainer i opublikowanie w gitlab

Przygotowanie procesu CI

Napisanie konfiguracji dla obrazu buildah

Skalowanie dla pozostałych kontenerów

Konfiguracja .gitconfig

Tożsamość autora commitów

Czytelniejszy log

Commity i praca z branchami

Szybka poprawka ostatniego commita

Wspólne ignore i hooki

Zaufane repozytoria w /repo

Pager i zewnętrzny diff

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

Do czego służy Dev Containers w VS Code?

Jak zbudowane jest repozytorium?

Dostępne profile

Pierwsze uruchomienie

Przejdź do repozytorium projektu

Podepnij profil

Otwórz projekt w kontenerze

Poczekaj na zbudowanie obrazu

Dlaczego ścieżka projektu się nie zmienia?

Dwa sposoby podpinania profilu

Wariant 1: symlink do profilu

Wariant 2: renderowanie konfiguracji do projektu

Co znajduje się w profilu?

Build obrazu

Integracja użytkownika i repozytoriów

Rozszerzenia VS Code

Jak rozwijać repozytorium?

Zmiana wspólnego narzędzia

Aktualizacja istniejącego profilu

Dodanie nowego profilu

Utwórz katalog profilu

Dodaj Dockerfile

Dodaj devcontainer.json

Sprawdź profil lokalnie

Walidacja zmian

Kiedy używać którego wariantu?

Nadpisanie teraform states

Popsułem terraform state, ale mam backup :)

Integracja z projektem gitlab

Ustawienie terraform state w ustawieniach repozytorium

Terraform state z procesu CI

Importowanie obiektów do tfstate

tofu Import – Co to jest i do czego służy?

Przykłady importowanie obiektów

importowanie grupy gitlab

importowanie projektu gitlab

Zarządzanie projektami w gitlab

Krop po kroku

Przygotowanie devcontainer

Napisanie logiki dla modułu gitlab-project

Utworzenie definicji w iac-gitlab-com dla grup

Jak zbudowane jest repozytorium iac-gitlab ?

Tworzenie projektu

Zarządzanie grupami w gitlab

Po co IaC dla GitLaba?

Krop po kroku

Przygotowanie devcontainer

Utworzenie obiektów

Napisanie logiki dla modułu gitlab-group

Utworzenie definicji w iac-gitlab-com dla grup i import

Wdrażanie zmian z opentofu

Jak zbudowane jest repozytorium iac-gitlab-com ?

Przykładowa definicja grupy

Statyczna strona na Gitlab pages

Krop po kroku

Zaufane repozytoria w `/repo`

Dodaj `devcontainer.json`

`tofu Import` – Co to jest i do czego służy?

Napisanie logiki dla modułu `gitlab-project`

Utworzenie definicji w `iac-gitlab-com` dla grup

Jak zbudowane jest repozytorium `iac-gitlab` ?

Napisanie logiki dla modułu `gitlab-group`

Utworzenie definicji w `iac-gitlab-com` dla grup i import

Jak zbudowane jest repozytorium `iac-gitlab-com` ?

Tworzymy prosty pipeline `.gitlab-ci.yml`