Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- fiberops-platform [07:37 27/01/2026] – [FiberOps Platform – DevOps Showcase] 10.8.0.4
+++ fiberops-platform [04:33 06/02/2026] (aktuell) – Externe Bearbeitung 127.0.0.1
@@ Zeile 182: / Zeile 182: @@
-===== Fazit =====
-Dieses Projekt zeigt keinen theoretischen Aufbau,
+====== ---------- ======
-sondern eine realistische DevOps-Arbeitsweise:
-  * Infrastruktur wird geplant, nicht „zusammengeklickt“
+====== FiberOps Platform – Showcase & Demo-Anleitung ======
-  * Betrieb ist automatisiert und beobachtbar
-  * Entscheidungen sind bewusst getroffen und begründet
+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
-Es dient als technisches Showcase für DevOps-Rollen
-mit Fokus auf Kubernetes, Virtualisierung und Betrieb.