Skip to content
Snippets Groups Projects
Forked from DevOps (Lecture FB VI) / webservice
This fork has diverged from the upstream repository.
user avatar
schnarkus authored
5d8a6572
History

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

Lifecycle

  • Pipeline Trigger: Die Pipeline wird durch Merge-Requests oder Pushes auf den Branches main, dev oder prod ausgelöst. Nach einem erfolgreichen Durchlauf der Pipeline wird ein Container-Image als Artefakt erstellt. Zusätzlich gibt es einen manuellen Genehmigungsschritt im prod-Branch, um unbeabsichtigte Änderungen der Produktionsumgebung zu verhindern.
  • Artefakte: Ein Commit auf den dev-Branch erzeugt ein mit dev 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 den prod-Branch den Build eines Container-Images auslösen. Dieses wird anschließend von Kubernetes im Google Cloud Cluster anhand des prod-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.