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:

• reproduzierbare Infrastruktur
• klare Trennung von Verantwortlichkeiten
• automatisiertes Deployment
• stabiler, beobachtbarer Betrieb

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?

• Virtualisierung (KVM): saubere Isolation, typisch für On-Prem-Betrieb
• Kubernetes: deklarativer Betrieb, Self-Healing, saubere Updates
• k3s: gleiche Kubernetes-API bei geringerem Ressourcenbedarf
• Trennung von Anwendung und Monitoring

• Root-Server mit Debian 12
• Root-Zugriff
• 8 CPU-Kerne
• ca. 16 GB RAM empfohlen
• Internetzugang
• SSH-Zugriff

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:

• gleiche Kubernetes-API wie „vollwertiges“ k8s
• geringerer Overhead
• ideal für kleine bis mittlere Plattformen

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:

• Code-Änderung → Git Push
• CI baut Container-Image
• Image wird in Registry gespeichert
• Kubernetes rollt neue Version kontrolliert aus

Dadurch sind keine manuellen Deployments notwendig.

Monitoring erfolgt getrennt von der Anwendung:

• Prometheus sammelt Metriken
• Grafana visualisiert:
  • Node-Auslastung
  • Pod-Status
  • Verfügbarkeit des Services

Dies bildet die Grundlage für:

• Fehlererkennung
• Kapazitätsplanung
• spätere Alerts

• Kubernetes Probes überwachen die Anwendung
• Pods werden bei Fehlern automatisch neu gestartet
• Updates erfolgen als Rolling Update ohne Downtime
• Infrastruktur ist vollständig neu aufsetzbar

• Multi-Node Kubernetes
• GitOps (z. B. ArgoCD)
• Backups
• High Availability Control Plane
• Network Policies / RBAC-Härtung

Diese Anleitung dient als Live-Demo- und Erklärdokument für den Bewerbungsprozess. Sie zeigt nicht nur *was* gemacht wird, sondern warum genau diese Technologien und Schritte gewählt wurden (DevOps-Fokus).

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

Warum dieser Schritt?

• zeigt sofort: der Service läuft
• Health-Endpunkt wird auch von Kubernetes-Probes genutzt
• /segments zeigt den fachlichen Use Case (Glasfaserbetrieb)
• /metrics zeigt Betriebs- und Monitoring-Fähigkeit

→ Kein abstraktes Projekt, sondern ein nutzbarer Service.

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

Warum genau diese Befehle?

• get nodes → Cluster-Gesundheit
• get pods → Laufzeitstatus der Anwendung
• deploy/svc/ingress → Kernobjekte von Kubernetes
• rollout status → kontrollierte Updates (kein Blindflug)
• logs → Fehlersuche ohne SSH in Container

→ 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

Warum GitHub Actions + gh CLI?

• CI/CD ist reproduzierbar und versioniert
• kein manuelles Deployment auf dem Server
• gh CLI vermeidet UI-Klicken und ist skriptfähig

→ Ä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

Warum dieser Schritt?

• stellt sicher, dass das Deployment erfolgreich war
• zeigt, dass neue Versionen tatsächlich aktiv sind
• Verbindung zwischen CI/CD und laufender Anwendung

→ 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

• Änderung erfolgt ausschließlich über Git
• kein direkter Eingriff auf dem Server
• CI/CD baut, verteilt und deployed automatisch
• Ergebnis ist sofort überprüfbar

→ Genau dieser Zyklus beschreibt moderne DevOps-Arbeit.

• Repository: https://github.com/HannesFehre/m-IT_FiberOps
• Einstieg: README.md
• Architektur: docs/architecture.md
• Runbooks: runbooks/deploy.md, runbooks/operations.md

Warum Dokumentation?

• ermöglicht Übergabe an andere Teams
• reduziert Bus-Faktor
• zeigt strukturierte Arbeitsweise

• Kubernetes (k3s) statt Docker-only:

→ deklarativer Betrieb, Self-Healing, saubere Updates

• k3s statt volles k8s:

→ gleiche API, geringerer Ressourcenbedarf, ideal für On-Prem

• NodePort für Demo:

→ schnell sichtbar

  → in Produktion: Ingress + TLS

• Trennung Code / CI / Infrastruktur:

→ klare Verantwortlichkeiten

  → wartbar und erweiterbar