Dieses Projekt ist ein praxisnahes DevOps-Showcase und demonstriert den Aufbau, die Automatisierung und den Betrieb einer containerisierten Plattform für einen internen Glasfaser-/Netzbetriebsservice.
Die Dokumentation richtet sich bewusst sowohl an technische Entscheider als auch an nicht-technische Leser.
Ziel ist es zu zeigen, wie moderne DevOps-Arbeit in einer On-Prem- oder Cloud-nahen Umgebung aussieht:
Der fachliche Use Case orientiert sich an einem realen Szenario aus dem Glasfaserbetrieb (POP, OLT, Segmente, Incidents).
Root Server (Debian 12)
│
├─ KVM / QEMU / Libvirt
│
├─ VM 1: Kubernetes (k3s)
│ └─ FiberOps Webservice (Container)
│
└─ VM 2: Monitoring
├─ Prometheus
└─ Grafana
Warum diese Architektur?
Installation der notwendigen Komponenten auf dem Root-Server:
apt update apt install -y \ qemu-kvm \ libvirt-daemon-system \ libvirt-clients \ virtinst \ bridge-utils \ cloud-image-utils systemctl enable --now libvirtd
Optional: aktuellen Benutzer zur libvirt-Gruppe hinzufügen:
usermod -aG libvirt,kvm $USER
Die VMs werden per cloud-init automatisiert erzeugt. Dadurch ist das Setup reproduzierbar und ohne manuelle Installation.
Beispiel (verkürzt):
virt-install \ --name fiberops-k3s \ --memory 4096 \ --vcpus 4 \ --disk size=30 \ --os-variant debian12 \ --network network=default \ --graphics none \ --import
Eine zweite VM wird analog für Monitoring erstellt.
In der Kubernetes-VM:
curl -sfL https://get.k3s.io | sh - kubectl get nodes
k3s wurde bewusst gewählt:
Die Anwendung wird containerisiert und über Kubernetes betrieben.
Deployment ausführen:
kubectl apply -f k8s/namespace.yaml kubectl apply -f k8s/deployment.yaml kubectl apply -f k8s/service.yaml kubectl apply -f k8s/ingress.yaml
Status prüfen:
kubectl get pods -n fiberops kubectl get svc -n fiberops
Der Build- und Deployment-Prozess ist automatisiert:
Dadurch sind keine manuellen Deployments notwendig.
Monitoring erfolgt getrennt von der Anwendung:
Dies bildet die Grundlage für:
seed: internal/fiberops/data.go
Das System zeigt den Zustand eines Glasfaser-/Netzbetriebs in einer einfachen, klaren Form. Es liefert live Informationen zu Segmenten (gesund, degradiert, down) und zu aktuellen Incidents mit Priorität und Status, Operations-Dashboard-Backend, das jederzeit abrufbar ist.
curl http://185.207.106.68:30080/health curl http://185.207.106.68:30080/segments curl http://185.207.106.68:30080/incidents curl http://185.207.106.68:30080/metrics | head
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml kubectl get nodes -o wide kubectl get ns kubectl get pods -n fiberops -o wide kubectl get deploy,svc,ingress -n fiberops -o wide kubectl -n fiberops rollout status deploy/fiberops kubectl -n fiberops logs deploy/fiberops --tail=50
→ Zeigt operativen Kubernetes-Betrieb, nicht nur Deployment.
cd /home/boothtml/fiberops-platform gh auth status gh workflow run ci-cd.yaml --ref main -f deploy=true gh run list --workflow ci-cd.yaml --limit 5 gh run watch
GitHub Actions + gh CLI
→ Änderungen werden über Git gesteuert, nicht per Handarbeit.
kubectl -n fiberops get pods -o wide kubectl -n fiberops rollout status deploy/fiberops curl http://185.207.106.68:30080/version
→ Vertrauen in den automatisierten Prozess.
cd /home/boothtml/fiberops-platform apply_patch <<'PATCH' *** Begin Patch *** Update File: internal/app/config.go @@ - Version: getEnv("APP_VERSION", "dev"), + Version: getEnv("APP_VERSION", "demo-change"), *** End Patch PATCH git add internal/app/config.go git commit -m "demo: change default version" git push gh workflow run ci-cd.yaml --ref main -f deploy=true gh run watch curl http://185.207.106.68:30080/version
Warum dieser Ablauf wichtig ist
→ Genau dieser Zyklus beschreibt moderne DevOps-Arbeit.
Warum Dokumentation?
→ deklarativer Betrieb, Self-Healing, saubere Updates
→ gleiche API, geringerer Ressourcenbedarf, ideal für On-Prem
→ schnell sichtbar
→ in Produktion: Ingress + TLS
→ klare Verantwortlichkeiten
→ wartbar und erweiterbar