Christoph Emsenhuber
1b413b41f3
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>
71 lines
4.0 KiB
Markdown
71 lines
4.0 KiB
Markdown
# 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.
|