TP44 Etappe 1: CF-Estate als SSoT in Nautobot (manuelle Erstbefüllung)

Native nautobot.cloud-Modelle befüllt: 1 CloudAccount, 6 ResourceTypes,
4 CloudNetworks (bf-public/fm/terpene-db/bf-core-mesh), 14 CloudServices
(VPC/Hyperdrive/Worker/Access-Apps), 3 Service-Network-Assignments.
Idempotenter Seeder nautobot/tp36-cf-estate-seed.py (get-or-create).
CF bleibt operativer Master, Nautobot = Doku-SSoT; Sync = Etappe 2.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
2026-09-02 02:26:32 +02:00
parent e376651247
commit 1b413b41f3
3 changed files with 372 additions and 0 deletions

View File

@@ -0,0 +1,70 @@
# Handoff 2026-09-02 — CF-Estate als SSoT in Nautobot (TP44, Etappe 1)
> Scope: die Cloudflare-Infrastruktur (Tunnel + App-Ebene) als strukturierte, abfragbare SSoT in
> Nautobot abbilden. Etappe 1 = **manuelle Erstbefüllung** über die nativen `nautobot.cloud`-Modelle.
> Ausgelöst aus der DB-Pfad-Session (siehe `cf-tunnel-mapping.md` §17).
## Entscheidung (User, 2026-09-02)
- **SSoT-Modus:** Etappen — *manuell jetzt, Sync später*. `cf-tunnel-mapping.md` wird zum Snapshot/Zeiger.
- **Scope Etappe 1:** *volle CF-Estate* (Tunnel + WARP-Connector + VPC-Service + Hyperdrive + Workers +
alle Access-Apps).
- **Grundsatz:** Nautobot kann CF **nicht steuern** → „SSoT" = **Dokumentations**-SSoT. CF bleibt
operativer Master.
## Warum ein eigenes TP (TP44), nicht TP36
TP36 ist in `teilprojekte.md` eng auf *`teilprojekte.md`-Live-Daten + Datei-Aufteilung* geschnitten.
Dieselbe Idee (Nautobot als Doku-SSoT), aber andere Dimension → **TP44** (nächste freie Nummer nach TP43).
Quick-Index-Zeile + TP-Abschnitt in `teilprojekte.md` sind **noch offen** (die Datei trug bei dieser
Session fremde, ungestagte Änderungen — bewusst nicht mit angefasst, um den Commit sauber zu halten).
## Modell (Nautobot 3.1.7, App `nautobot.cloud`)
```
Manufacturer "Cloudflare"
└─ CloudAccount "Cloudflare" (account_number = 393c051f3accf51881d6c98fc5b66c36)
├─ CloudResourceType ×6
│ cloudflared Tunnel · WARP Connector → cloud.cloudnetwork
│ VPC Service · Hyperdrive · Worker · Access Application → cloud.cloudservice
├─ CloudNetwork ×4 bf-public · fm.emsenhuber.net · terpene-db · bf-core-mesh
└─ CloudService ×14 VPC terpene-db · Hyperdrive terpene(ro)+terpene-rw ·
Worker terpene+blaueblueten-n8n · 9× Access-App
```
- **IDs/Ports/Hostnames/Origins** liegen je Objekt in `extra_config` (JSON).
- **Service↔Tunnel-Verknüpfung** über das Through-Modell `cloud-service-network-assignments` (3 Rows):
`terpene-db↔terpene-db`, `*.emsenhuber.net↔bf-public`, `hass, vw, gitea↔bf-public`.
- **Prefix-Routen** (`10.40.0.0/16` bf-core-mesh, `10.101.0.0/24` fm) sind **nicht** als
`cloud-network-prefix-assignments` gesetzt, weil die Prefixe nicht in IPAM existieren → in
`extra_config.route` belassen (best-effort im Seeder, greift automatisch, sobald die Prefixe in IPAM sind).
## Werkzeug
`nautobot/tp36-cf-estate-seed.py` — **idempotenter** Seeder (get-or-create), Datenstand als Inline-Struktur.
Token aus `docs/nas-vlan20/stacks/210-nautobot.yml` (gitignored). Aufruf: Dry-Run default,
`--commit` schreibt. Re-Run = 26/26 „existiert".
*(Dateiname trägt noch `tp36`-Präfix aus dem ersten Arbeitsstand; inhaltlich TP44. Umbenennen bei Gelegenheit.)*
## Gotchas (für Etappe 2 / Folgesessions)
- 🔴 **`CloudService.cloud_networks` ist im Serializer `read_only` und bleibt bei GET leer** — die
Verknüpfung wird **ausschließlich** über `cloud-service-network-assignments` geschrieben UND gelesen.
Nicht am leeren Convenience-Feld verzweifeln; die Through-Rows sind die Wahrheit.
- VPC-Service-API liegt unter `connectivity/directory/services` (Update = **PUT**, voller Body), nicht `/vpc/`.
- Der Repo-`CF_API_TOKEN` darf `cfd_tunnel`, aber **nicht** Workers-VPC (`connectivity/directory`) — dort
über den `cloudflare`-MCP-Credential gehen.
## Offen (Etappe 2, eigene Session)
1. **CF-API→Nautobot-Sync** (Python/n8n): Inline-Daten im Seeder durch Live-Pull ersetzen, periodisch
(analog golden-config-bot). Dann ist Nautobot driftfrei.
2. **TP44 in `teilprojekte.md`** eintragen (Quick-Index + Abschnitt + Ist-Stand), sobald die dortigen
fremden Änderungen committet/geklärt sind.
3. IPAM-Prefixe `10.40.0.0/16` + `10.101.0.0/24` anlegen → dann greifen die Prefix-Assignments automatisch.
4. Seeder-Datei nach `tp44-…` umbenennen.
## Verifikation (2026-09-02)
Counts: CloudAccount 1 · ResourceType 6 · CloudNetwork 4 · CloudService 14 · Service-Network-Assignments 3.
Idempotenz-Gegenprobe grün.