1
Zmieniaj tylko jedną rzecz naraz
Jeśli poprawisz 5 rzeczy na raz:
- nie wiesz, która coś naprawiła
- nie wiesz, która coś zepsuła
- cofasz o kilka minut, nie dni
Dlatego:
Zrób zmianę → sprawdź → logi → dopiero następna zmiana.
Zrób zmianę → sprawdź → logi → dopiero następna zmiana.
2
Najpierw sprawdź rzeczy podstawowe, nie zaawansowane
Bardzo często źródłem problemu jest:
literówka • zła ścieżka • brak uprawnień • brak wolumenu • config w złym miejscu • proces nie działa
Dlatego pierwsze pytania brzmią:
- Czy to w ogóle działa?
- Czy proces żyje?
- Czy port jest nasłuchiwany?
- Czy ścieżka istnieje?
- Czy plik jest tam, gdzie myślę?
3
Izoluj problem: "kto właściwie nie działa?"
Zawsze ustal:
- czy problem jest po stronie A (np. GitLab)
- czy po stronie B (np. Runner)
- czy na połączeniu między nimi
Przykłady:
Runner → API żyje?
API → Rails padł?
Rails → PG nie odpowiada?
PG → autoryzacja padła?
PG działa → może tylko konfiguracja niedostępna?
Runner → API żyje?
API → Rails padł?
Rails → PG nie odpowiada?
PG → autoryzacja padła?
PG działa → może tylko konfiguracja niedostępna?
Wyznacz granicę błędu.
4
Nie zakładaj — sprawdzaj
Jeśli wydaje Ci się, że:
„baza działa" • „config się załadował" • „proces jest uruchomiony" • „połączenie jest dobre" • „runner ma poprawny token"
…to nie zakładaj tego. Udowodnij to prostymi testami:
psql -U user -h host -d db
docker exec container cat /etc/gitlab-runner/config.toml
curl -I http://gitlab/api/v4
docker exec container cat /etc/gitlab-runner/config.toml
curl -I http://gitlab/api/v4
Każde założenie, którego nie zweryfikujesz, może Cię wpakować w 3h szukania czegoś, co nie istnieje.
5
Patrz zawsze w logi — nie w GUI
GUI często kłamie lub jest opóźnione.
Logi nie.
Kiedy jest błąd — logi są jedyną prawdą.
6
Najpierw zrozum, potem naprawiaj
Nigdy nie rób zmian na oślep, np.:
restart • reinstall • „może to, może tamto"
restart • reinstall • „może to, może tamto"
Najpierw ustal:
- co właściwie się zepsuło
- kiedy się zepsuło
- dlaczego się zepsuło
Dopiero potem działaj.
7
Mierz, czy system reaguje na zmianę
Zmieniłeś config → sprawdź:
- czy GitLab go widzi?
- czy logi pokazują reconfigure?
- czy nowy parametr wszedł?
- czy runner zmienił status?
Jeśli nie ma reakcji, to wiesz, że:
nie działa reconfigure • config nie jest wczytywany • albo zmieniłeś niewłaściwy plik
nie działa reconfigure • config nie jest wczytywany • albo zmieniłeś niewłaściwy plik
8
Nigdy nie poprawiaj dwóch warstw naraz
Np. nie rób:
zmian w docker-compose i zmian w configu i restartów i reconfigure i edycji bazy
zmian w docker-compose i zmian w configu i restartów i reconfigure i edycji bazy
Wtedy nie masz pojęcia, co zadziałało.
Najpierw jedna warstwa → sprawdzenie → dopiero następna.
9
"Wyzerowanie" zmiennych często rozwiązuje problem
Usunięcie:
cache • starych wolumenów • starego configu • starego tokenu • starego runnera
…rozwiązuje więcej problemów, niż byś pomyślał.
Bo systemy często trzymają śmieci.
10
Zakładaj, że problem jest prosty
Najczęściej winny jest:
jeden brakujący plik • jedna linijka • jeden zły user • jeden port • jeden błąd w configu
Skomplikowane problemy są rzadkie.
11
Sprawdzaj: "czy to na pewno ten kontener/plik/proces?"
Nagle okazuje się, że:
- edytujesz config w złym wolumenie
- restartujesz niewłaściwy kontener
- patrzysz w logi nie tej usługi
- edytujesz TOML, który nie jest mountowany
- patrzysz w ścieżkę hosta, a nie kontenera
To klasyk.
12
Ostateczne rozwiązanie: zacznij od czystego stanu
Jeśli debugowanie trwa ZA długo, to reset jest szybszy niż kopanie:
docker compose down -v
# od nowa konfiguracja
# od nowa runner
# od nowa konfiguracja
# od nowa runner
Systemy typu GitLab są deterministyczne — jeśli dasz im czysty stan, działają poprawnie.