Files
infra/docs/runbooks/30-usuwanie.md
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

139 lines
3.6 KiB
Markdown

# 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:
```bash
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:**
```bash
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
```bash
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
```bash
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
```bash
docker images | grep <projekt>
docker rmi <obraz> # tylko jeśli nic innego go nie używa
docker network rm <projekt>-internal
```
---
## Krok 6 — kod
```bash
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
```bash
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:
```bash
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:
```bash
docker image prune -a # tylko nieużywane obrazy
docker builder prune # cache budowania — zwykle największy zysk
```