Deliverable: Projektkonzept
Technologiewahl
- Go: Vorgegebene Programmiersprache für den Webservice.
- GitLab CI/CD: Das Hochschul-GitLab bietet die Infrastruktur für die CI/CD-Pipeline, inklusive Container-Registry und Quellcode-Verwaltung.
- Podman: Container-Runtime zur Verwaltung, ähnlich wie Docker, kann aber auch ohne Hyper-V und tiefgreifende Administratorrechte verwendet werden.
- Kubernetes: Plattform für Cluster- und Pod-Management, Schnittstelle zur Google Cloud sowie zahlreiche Dienste wie Redis und integrierte Dashboards zur Überwachung der Systeme.
- OpenTofu: Management-Tool für deklarative Infrastrukturverwaltung, ermöglicht den idempotenten Aufbau der Zielstruktur.
Umgebungen
- Entwicklung: Lokal mit Podman-Containern
- Produktion: Global über Kubernetes-Cluster in GCP
Dienste
- Compute Engine: Hostet VMs für Webservice und Prometheus
- Kubernetes Engine: Aufbau und Management des Clusters
Infrastruktur
Die Produktionsumgebung des Webservice wird auf der Google Cloud Platform (GCP) gehostet:
-
Details zur Infrastruktur:
- Maschinentyp: e2-medium (2 vCPUs, 4 GB RAM)
- Region: Frankfurt
- Betriebssystem: Ubuntu 22.04
- Festplatte: 20 GB
-
Cluster-Umgebung:
-
Google Kubernetes Engine Cluster:
devops24-autopilot-cluster
-
Netzwerk:
devops24-network
-
Subnetz:
devops24-subnetwork
- Kubernetes Deployment: Deployment mit drei Replikaten
- LoadBalancer-Service: Lastverteilung auf mehrere Pods oder Dienste im Cluster
- Ingress-Controller (Nginx): Routen von eingehendem HTTP(S)-Verkehr im Cluster
-
Google Kubernetes Engine Cluster:
-
Datenbank: Für die Persistenz wird Redis verwendet, das innerhalb des Webservice-Containers betrieben wird.
CI/CD Pipeline
Die Konfiguration für den Build des Webservices erfolgt in der GitLab CI/CD-Pipeline. Diese Pipeline unterscheidet die Stages Test, Build und Publish und wird bei Merge-Requests oder Pushes auf die Branches main
, dev
oder prod
aktiviert.
-
Test: Durchführung von Tests mit dem Docker-Image
golang:1.21
-
Build: Erstellung des Webservice-Binaries für
linux_amd64
und Speicherung der Artefakte in der Container-Registry - Publish: Veröffentlichung des Docker-Images in der Container-Registry mit Versionierung auf Basis der Pipeline-ID
Lifecycle
-
Pipeline Trigger: Die Pipeline wird durch Merge-Requests oder Pushes auf den Branches
main
,dev
oderprod
ausgelöst. Nach einem erfolgreichen Durchlauf der Pipeline wird ein Container-Image als Artefakt erstellt. Zusätzlich gibt es einen manuellen Genehmigungsschritt improd
-Branch, um unbeabsichtigte Änderungen der Produktionsumgebung zu verhindern. -
Artefakte: Ein Commit auf den
dev
-Branch erzeugt ein mitdev
getaggtes Artefakt, das für Tests in der Entwicklungsumgebung verwendet wird. Diese Tests erfolgen lokal mittels Podman. Wenn alles in Ordnung ist, kann ein Commit auf denprod
-Branch den Build eines Container-Images auslösen. Dieses wird anschließend von Kubernetes im Google Cloud Cluster anhand desprod
-Tags erkannt und in Pods ausgeführt.
Weitere Konfigurationen
-
Monitoring: Die Anwendung wird mithilfe eines Prometheus-Containers und exportierter Metriken des Webservice-Containers auf Port 8090 mit dem Endpoint
/metrics
überwacht. - TLS: Wird wie DNS nur in der Entwicklungsumgebung konfiguriert. Durch ein selbstsigniertes Zertifikat erfolgt die Kommunikation über Nginx, das den HTTPS-Traffic auf Port 8443 leitet.
-
DNS: In der Datei
/etc/hosts
konfiguriert; es wird überprüft, ob die Seite über einen Alias per HTTPS verfügbar ist.