Files

T

kacperor 6ed7a7f4d2 Init repo infra + poprawki runbooka bootstrap i HANDOFF

- Krok 9 (tmux): tee -> tee -a (nie nadpisuj configu), dodano
  focus-events on, poprawiono nazwę sesji na "bootstrap"
- Krok 10: struktura katalogów odzwierciedla stan faktyczny
  (/srv i /srv/infra już istnieją, brakuje apps i data)
- Krok 12: Claude Code oznaczony jako wykonany 20-08-2026,
  instalator natywny bez Node.js
- Nowy Krok 14: audyt po bootstrapie (SSH, ufw, fail2ban,
  unattended-upgrades, swap, Docker, porty, klucze)
- HANDOFF.md: poprawiona numeracja sekcji 6

2026-08-20 15:53:51 +00:00

3.6 KiB

Raw Permalink Blame History

Runbook 30 — usuwanie projektu

Najważniejszy runbook dla utrzymania porządku. Usunięcie projektu to nie jest docker compose down. Osierocone wolumeny, martwe rekordy DNS i wyłączone kontenery zajmujące gigabajty to dokładnie ten bałagan, którego ten serwer ma nie mieć.

Przechodzisz całą listę. Za każdym razem.

Krok 0 — zabezpieczenie danych

Zanim cokolwiek skasujesz:

cd /srv/apps/<projekt>
docker compose ps          # co faktycznie działa
docker compose config      # jakie wolumeny są w grze
du -sh /srv/data/<projekt> # ile tam danych

Baza danych — zrzut przed usunięciem, zawsze:

docker compose exec db pg_dump -U <user> <baza> > ~/<projekt>-final-$(date +%F).sql

Trzymaj zrzut poza /srv/data/<projekt> — inaczej skasujesz go razem z resztą. Rozważ przeniesienie na lokalną maszynę. „Na pewno już niepotrzebne" bywa weryfikowane dwa miesiące później.

Punkt zatrzymania: potwierdź z Kacprem, że dane są zbędne albo zabezpieczone. To operacja nieodwracalna.

Krok 1 — zatrzymanie

docker compose down            # BEZ -v na tym etapie
docker compose ps -a

-v kasuje wolumeny natychmiast. Zostawiamy je do kroku 4, żeby był margines na refleksję.

Krok 2 — DNS i Traefik

Usuń rekord A w panelu OVH
dig +short <projekt>.dfkk.cloud — ma nie zwracać nic
Sprawdź, że żadna inna usługa nie używa tej subdomeny

Krok 3 — monitoring

Usuń monitor z Uptime Kuma (inaczej dostaniesz alert o „awarii" usługi, którą sam skasowałeś)
Usuń ścieżki projektu z listy backupu

Krok 4 — dane i wolumeny

docker volume ls | grep <projekt>
docker volume rm <nazwa>            # świadomie, po jednym
sudo rm -rf /srv/data/<projekt>

Punkt zatrzymania: rm -rf na katalogu z danymi wymaga wyraźnej zgody. Przeczytaj ścieżkę na głos przed naciśnięciem Enter.

Krok 5 — obrazy i sieci

docker images | grep <projekt>
docker rmi <obraz>                  # tylko jeśli nic innego go nie używa
docker network rm <projekt>-internal

Krok 6 — kod

sudo rm -rf /srv/apps/<projekt>

Repo w Gitei: archiwizuj, nie kasuj. Archiwum jest tanie, kod czasem wraca. Kasowanie repozytorium ma sens tylko wtedy, gdy trafiły do niego sekrety — a wtedy i tak trzeba je najpierw unieważnić.

Krok 7 — dokumentacja

Wykreśl projekt z SERVER.md, sekcja 7
Wykreśl subdomenę z SERVER.md, sekcja 2
Usuń zadania cykliczne z sekcji 8, jeśli jakieś były
Wpis w dzienniku zmian, sekcja 10
Commit w repo infra

Krok 8 — kontrola

df -h /                      # miejsce faktycznie wróciło?
docker system df             # ile zajmują obrazy, kontenery, wolumeny
docker ps -a                 # brak śladów po projekcie
docker volume ls -f dangling=true

Jeśli miejsce nie wróciło — coś zostało. Szukaj, zanim uznasz sprawę za zamkniętą.

Sprzątanie osieroconych zasobów

docker system prune bywa kuszący. Zanim go użyjesz — sprawdź, co usunie:

docker volume ls -f dangling=true      # wolumeny bez kontenera
docker images -f dangling=true         # warstwy bez tagu

docker system prune -a --volumes potrafi skasować wolumen zatrzymanej usługi, która wcale nie miała zniknąć. Kasujemy pojedynczo, po sprawdzeniu każdej pozycji. Bezpieczna wersja, bez dotykania wolumenów:

docker image prune -a          # tylko nieużywane obrazy
docker builder prune           # cache budowania — zwykle największy zysk

3.6 KiB Raw Permalink Blame History