====== FiberOps Platform – DevOps Showcase ======

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 des Projekts =====

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).


===== Architekturübersicht =====

<code>
Root Server (Debian 12)
│
├─ KVM / QEMU / Libvirt
│
├─ VM 1: Kubernetes (k3s)
│   └─ FiberOps Webservice (Container)
│
└─ VM 2: Monitoring
    ├─ Prometheus
    └─ Grafana
</code>

**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


===== Voraussetzungen =====

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


===== Schritt 1: Virtualisierung vorbereiten =====

Installation der notwendigen Komponenten auf dem Root-Server:

<code bash>
apt update
apt install -y \
  qemu-kvm \
  libvirt-daemon-system \
  libvirt-clients \
  virtinst \
  bridge-utils \
  cloud-image-utils
systemctl enable --now libvirtd
</code>

Optional: aktuellen Benutzer zur libvirt-Gruppe hinzufügen:

<code bash>
usermod -aG libvirt,kvm $USER
</code>


===== Schritt 2: Virtuelle Maschinen erstellen =====

Die VMs werden per **cloud-init** automatisiert erzeugt.
Dadurch ist das Setup reproduzierbar und ohne manuelle Installation.

Beispiel (verkürzt):

<code bash>
virt-install \
  --name fiberops-k3s \
  --memory 4096 \
  --vcpus 4 \
  --disk size=30 \
  --os-variant debian12 \
  --network network=default \
  --graphics none \
  --import
</code>

Eine zweite VM wird analog für Monitoring erstellt.


===== Schritt 3: Kubernetes (k3s) installieren =====

In der Kubernetes-VM:

<code bash>
curl -sfL https://get.k3s.io | sh -
kubectl get nodes
</code>

k3s wurde bewusst gewählt:
  * gleiche Kubernetes-API wie „vollwertiges“ k8s
  * geringerer Overhead
  * ideal für kleine bis mittlere Plattformen


===== Schritt 4: Anwendung deployen =====

Die Anwendung wird containerisiert und über Kubernetes betrieben.

Deployment ausführen:

<code bash>
kubectl apply -f k8s/namespace.yaml
kubectl apply -f k8s/deployment.yaml
kubectl apply -f k8s/service.yaml
kubectl apply -f k8s/ingress.yaml
</code>

Status prüfen:

<code bash>
kubectl get pods -n fiberops
kubectl get svc -n fiberops
</code>


===== Schritt 5: CI/CD =====

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.


===== Schritt 6: Monitoring =====

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


===== Betrieb & Wartung =====

  * 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


===== Erweiterungsmöglichkeiten =====

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



====== ---------- ======

====== FiberOps Platform – Showcase & Demo-Anleitung ======

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.**


==== 1) Live-Service prüfen (sofort sichtbarer Nutzen) ====

<code bash>
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
</code>



  * Health-Endpunkt wird auch von Kubernetes-Probes genutzt
  * /segments zeigt den fachlichen Use Case (Glasfaserbetrieb)
  * /metrics zeigt Betriebs- und Monitoring-Fähigkeit



==== 2) Kubernetes-Betrieb zeigen ====

<code bash>
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
</code>


  * 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.


==== 3) CI/CD auslösen (Automatisierung demonstrieren) ====

<code bash>
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
</code>

**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.


==== 4) Deployment verifizieren ====

<code bash>
kubectl -n fiberops get pods -o wide
kubectl -n fiberops rollout status deploy/fiberops
curl http://185.207.106.68:30080/version
</code>


  * 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.


==== 5) Change → Deploy → Verify (DevOps-Kern) ====

<code bash>
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
</code>

**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.


==== 6) Repository & Dokumentation ====

  * 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


==== Wichtige Design-Entscheidungen ====

  * 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