Files
infra/docs/runbooks/20-domena.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

102 lines
3.4 KiB
Markdown

# Runbook 20 — domeny i DNS
Wszystkie trzy domeny są w OVH, DNS też w OVH. To upraszcza sprawę: Traefik może
używać API OVH do wyzwania **DNS-01**, więc dostajemy certyfikaty wildcard.
---
## 1. Dlaczego DNS-01, a nie HTTP-01
| | HTTP-01 | DNS-01 (nasz wybór) |
|---|---|---|
| Jak działa | Let's Encrypt puka na port 80 | Traefik wpisuje rekord TXT przez API |
| Wildcard | niemożliwy | możliwy |
| Nowa subdomena | osobny certyfikat, osobne wyzwanie | działa od razu, zero akcji |
| Usługi niepubliczne | nie da się | da się |
| Wymaga | otwartego portu 80 | kluczy API dostawcy DNS |
Przy wildcardzie `*.dfkk.cloud` dodanie `nowyprojekt.dfkk.cloud` to jeden rekord A
i restart kontenera. Certyfikatem nie zajmujesz się w ogóle.
---
## 2. Klucze API OVH — jednorazowo
1. Wejdź na stronę tworzenia tokenów API OVH dla właściwego regionu konta
(uwaga: konto jest w regionie **CA** — patrz adres panelu w `SERVER.md`,
to zmienia zarówno adres, pod którym generujesz token, jak i endpoint w konfiguracji)
2. Uprawnienia zawężone do stref DNS — `GET`, `POST`, `PUT`, `DELETE`
na `/domain/zone/*`. Nie dawaj tokenowi pełnego dostępu do konta.
3. Ważność: bez limitu, ale **wpisz token do `SERVER.md`, sekcja 9**, żeby wiadomo było,
co unieważnić przy incydencie
4. Trzy wartości — application key, application secret, consumer key —
lądują w `/srv/infra/stacks/traefik/.env`, `chmod 600`, poza repo
---
## 3. Nowa subdomena
```
Typ: A
Nazwa: <projekt>
Cel: <IP serwera>
TTL: 300 (na czas testów; potem można podnieść)
```
Sprawdzenie propagacji:
```bash
dig +short <projekt>.dfkk.cloud
```
Dopóki `dig` nie zwraca IP serwera, nie ma sensu debugować Traefika —
problem jest w DNS, nie w kontenerze.
---
## 4. Nowa domena (druga lub trzecia)
Wildcard obejmuje **tylko** `*.dfkk.cloud`. Kolejna domena wymaga:
1. Rekordu A na IP serwera
2. Dopisania nowej domeny do konfiguracji certresolvera w Traefiku
(osobny wpis `domains` z `main` i `sans`)
3. Sprawdzenia, że token API OVH ma uprawnienia **także do tej strefy**
4. Wpisu w `SERVER.md`, sekcja 2
---
## 5. Odpinanie domeny
Kolejność odwrotna niż przy podpinaniu:
- [ ] Usuń labele Traefika z compose i zrestartuj usługę
- [ ] Usuń rekord A w panelu OVH
- [ ] Sprawdź, że nie ma innych rekordów wskazujących na serwer (CNAME, MX)
- [ ] Wykreśl subdomenę z `SERVER.md`, sekcja 2
- [ ] Usuń monitor z Uptime Kuma
Martwy rekord A wskazujący na Twój serwer to nie tylko bałagan — jeśli kiedyś oddasz
to IP, ktoś inny odziedziczy ruch kierowany na Twoją nazwę.
---
## 6. Diagnostyka
| Objaw | Gdzie szukać |
|---|---|
| `dig` nie zwraca IP | DNS, panel OVH — nie ruszaj serwera |
| DNS ok, ale 404 z Traefika | literówka w `Host()` albo brak `traefik.enable=true` |
| DNS ok, ale połączenie odrzucone | kontener nie działa lub nie jest w sieci `edge` |
| Błąd certyfikatu | logi Traefika, klucze API OVH, uprawnienia do strefy |
| Certyfikat „fake" / staging | w konfiguracji został adres staging Let's Encrypt |
```bash
docker logs traefik --tail=100 | grep -i -E "acme|error|certificate"
```
> **Uwaga na limity Let's Encrypt.** Przy debugowaniu certyfikatów łatwo wpaść
> w limit żądań i zostać zablokowanym na tydzień. Jeśli certyfikat nie chce się
> wystawić — przełącz się na serwer **staging** Let's Encrypt, dopracuj konfigurację
> tam, i dopiero potem wróć na produkcyjny.