Robert RappandClaude Opus 5.5
50acfa6a95
ci / test (push) Failing after 24s
Admin-Schlüssel je Person auf ops (Bastion) aus sites/knaster/proxmox.yaml (access.ops_ssh_keys/_revoked), Playbook admins.yml, Test, Übergabe in BETRIEB §15. Einstieg für Agenten und neue Admins: AGENTS.md, Projektkarte, bekannte Probleme. Weg 2 (Verwaltung über NEX) als Entwurf in Phase 9. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
68 lines
5.3 KiB
YAML
68 lines
5.3 KiB
YAML
# Proxmox-Zielbild für "knaster" (Eingabe für platform/proxmox/tofu und ansible).
|
||
# Stand 12.10.2026: echte Knoten pve44–pve61. PCI-Adressen, IDs und IOMMU-Gruppen per
|
||
# `pvesh get /nodes/<knoten>/hardware/pci` gelesen. Gäste vorerst per DHCP (D5 zurückgestellt).
|
||
cluster:
|
||
endpoint: https://192.168.100.210:8006/
|
||
storage_iso: local
|
||
bridge: vmbr0
|
||
gateway: 192.168.100.1
|
||
dns: 192.168.100.120
|
||
ssh_public_key_file: ~/.ssh/id_ed25519.pub # Schlüssel auf dem Steuerrechner ops
|
||
lxc_template: debian-13-standard_13.6-1_amd64.tar.zst
|
||
# Ubuntu-24.04-Cloud-Image-Template je Knoten (VMIDs sind clusterweit eindeutig)
|
||
templates: {pve44: 9044, pve46: 9046, pve48: 9048, pve52: 9052}
|
||
zfs_arc_max_mb: 2048 # ZFS-Lesecache der GPU-Knoten (tank trägt nur Replikate und kleine Gäste); Rolle pve-host
|
||
|
||
pci_mappings: # Proxmox Resource Mappings (Datacenter → Resource Mappings → PCI)
|
||
gpu-m4000-pve44: {node: pve44, path: "0000:01:00", id: "10de:13f1", subsystem_id: "10de:1153", iommu_group: 1}
|
||
gpu-p2000-pve44: {node: pve44, path: "0000:02:00", id: "10de:1c30", subsystem_id: "10de:11b3", iommu_group: 8}
|
||
gpu-m4000-pve46: {node: pve46, path: "0000:01:00", id: "10de:13f1", subsystem_id: "10de:1153", iommu_group: 1}
|
||
gpu-p2000-pve46: {node: pve46, path: "0000:02:00", id: "10de:1c30", subsystem_id: "10de:11b3", iommu_group: 8}
|
||
gpu-m4000-pve48: {node: pve48, path: "0000:01:00", id: "10de:13f1", subsystem_id: "10de:1153", iommu_group: 1}
|
||
gpu-p2000-pve48: {node: pve48, path: "0000:02:00", id: "10de:1c30", subsystem_id: "10de:11b3", iommu_group: 8}
|
||
gpu-m4000-pve52: {node: pve52, path: "0000:01:00", id: "10de:13f1", subsystem_id: "10de:1153", iommu_group: 1}
|
||
|
||
# Zuteilung je GPU-VM (15.10.): alle 8 Threads des Knotens und 20 von 32 GB. Der Rest des Knotens: Proxmox
|
||
# selbst ~3 GB, ZFS-ARC 2 GB (cluster.zfs_arc_max_mb), dazu ops (2 GB, pve46), infra (4 GB, pve44), k3s (3 GB, pve48).
|
||
# RAM der GPU-VMs ist durch PCI-Passthrough fest reserviert (kein Ballooning), CPU darf überbucht sein.
|
||
vms: # eine GPU-VM pro Knoten mit allen Karten des Knotens (D2)
|
||
gpu-pve44: {node: pve44, vmid: 244, cores: 8, memory_mb: 20480, disk_gb: 40, models_disk_gb: 60, storage: local-lvm, gpus: [gpu-m4000-pve44, gpu-p2000-pve44], ip: dhcp, driver_generation: legacy}
|
||
gpu-pve46: {node: pve46, vmid: 246, cores: 8, memory_mb: 20480, disk_gb: 40, models_disk_gb: 60, storage: local-lvm, gpus: [gpu-m4000-pve46, gpu-p2000-pve46], ip: dhcp, driver_generation: legacy}
|
||
gpu-pve48: {node: pve48, vmid: 248, cores: 8, memory_mb: 20480, disk_gb: 40, models_disk_gb: 60, storage: local-lvm, gpus: [gpu-m4000-pve48, gpu-p2000-pve48], ip: dhcp, driver_generation: legacy}
|
||
gpu-pve52: {node: pve52, vmid: 252, cores: 8, memory_mb: 20480, disk_gb: 40, models_disk_gb: 60, storage: local-lvm, gpus: [gpu-m4000-pve52], ip: dhcp, driver_generation: legacy}
|
||
|
||
containers: # Infrastruktur als LXC (ADR-0001), HA + ZFS-Replikation (ADR-0002)
|
||
infra: {node: pve44, vmid: 101, cores: 4, memory_mb: 4096, disk_gb: 60, storage: tank, ip: 192.168.100.188/24, ha: true, replicate_to: [pve52, pve48]}
|
||
|
||
# Dienst-VMs ohne GPU (D6): k3s-Steuerung, geklont vom Template des Knotens, auf tank mit HA.
|
||
# Adresse per DHCP wie die GPU-VMs (D5); die Agents finden den Server über /etc/hosts (Rolle k3s-agent).
|
||
service_vms:
|
||
k3s: {node: pve48, vmid: 110, cores: 2, memory_mb: 3072, disk_gb: 20, storage: tank, ip: dhcp, pool: infra, ha: true, replicate_to: [pve52, pve44]}
|
||
|
||
replication_schedule: "*/15"
|
||
|
||
# Cluster-Grundkonfiguration (Phase 4, Rolle pve-cluster, Playbook playbooks/cluster.yml)
|
||
access:
|
||
admin_group: admins # Gruppe mit Administrator auf /; root@pam bleibt Notfallzugang
|
||
admin_users: [r.rapp] # persönliche Konten <name>@pve; Passwort und TOTP per scripts/pve-admin-user.sh
|
||
mail_to: ki@mygodel.de # Ziel der Proxmox-Benachrichtigungen (Backup, Fencing, Updates, Replikation)
|
||
# Verwaltung durch Personen statt durch ein Gerät (19.10., „Weg 1“): Jede Person kommt mit einem eigenen Schlüssel
|
||
# auf ops (Bastion) und arbeitet von dort (kubectl, Ansible, tofu). Öffentliche Schlüssel, kein Geheimnis.
|
||
# Ausrollen: playbooks/admins.yml auf ops. Übergabe und Entzug: docs/BETRIEB.md Abschnitt 15.
|
||
ops_ssh_keys:
|
||
- {name: r.rapp-laptop, key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHG5/rQMO4dtO8jOdAjQksFxZhdI7oSZAGNmFXVxQcoJ rrapp-laptop-2026-10-08"}
|
||
ops_ssh_keys_revoked: [] # ehemalige Schlüssel ({name, key}); playbooks/admins.yml entfernt sie von ops
|
||
firewall:
|
||
enable: true
|
||
# IPSET management: nur diese Quellen (plus alle Knoten) erreichen 8006, 22, 5900-5999, 3128 und
|
||
# 60000-60050 der Knoten. Corosync zwischen den Knoten erlaubt Proxmox von selbst.
|
||
# Achtung: Der Laptop läuft per DHCP (D5). ops und infra haben seit 14.10. feste Adressen (noch ohne
|
||
# Reservierung am DC). Wechselt die Laptop-Adresse, sperrt die Firewall diese Quelle aus. Rückweg: ssh über eine noch zugelassene Adresse (ops) oder Konsole.
|
||
management:
|
||
- {ip: 192.168.100.151, comment: Admin-Laptop WLAN per DHCP}
|
||
- {ip: 192.168.100.181, comment: Admin-Laptop USB-LAN im Dock per DHCP}
|
||
- {ip: 192.168.100.29, comment: appsrv08 LiteLLM mit PSE und n8n-Bruecke}
|
||
- {ip: 192.168.100.173, comment: ops CT 100 Ansible und tofu statisch}
|
||
- {ip: 192.168.100.188, comment: infra CT 101 pve-exporter statisch}
|
||
ping_from: 192.168.100.0/24
|