# 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
```