kacperor
6ed7a7f4d2
- 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
3.6 KiB
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 -rfna 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