Skip to content
Snippets Groups Projects
Select Git revision
  • dev protected
  • main default protected
  • prod protected
  • t-6-deploy-app-on-kubernetes
  • t-5-allocate-vm-cloud
  • t4-build-publish-container
  • t3-build-container-image
  • t2-vagrant
8 results
Compare
Forked from DevOps (Lecture FB VI) / webservice
This fork has diverged from the upstream repository.
user avatar
fix pipeline
schnarkus authored
d0d4114e
History
user avatar d0d4114e
History
Name Last commit Last update
configuration
gcp-cluster
local-environment
metrics
routing
state
.gitignore
.gitlab-ci.yml
Containerfile
Lifecycle.png
Makefile
README.md
entrypoint.sh
go.mod
go.sum
main.go
README.md

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, jedoch auch ohne Administratorrechte benutzbar.
  • 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 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 Redis-Datenbank
  • Kubernetes Engine: Autopilot-Cluster für Webservice und Ingress-Controller

Infrastruktur

Die Produktivumgebung 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, welches in einer separaten Compute Engine-Instanz innerhalb der GCP-Umgebung 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 der Basis der Pipeline-ID

Lifecycle

Lifecycle

  • Pipeline Trigger: Die Pipeline wird durch Merge-Requests oder Pushes auf den Branches main, dev oder prod getriggert. Nach einem erfolgreichen Durchlauf der Pipeline wird ein Container-Image als Artefakt erstellt.
  • Artifakte: Ein Commit auf den dev-Branch erzeugt ein mit dev getaggtes Artefakt, das für Tests in der Entwicklungsumgebung verwendet wird. Diese Tests erfolgen durch lokale Ausführung 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 von GCP-Monitoring überwacht.
  • TLS: Wird wie DNS nur in der Entwicklungsumgebung konfiguriert. Durch ein selbstsigniertes Zertifikat erfolgt die Kommunikation über Nginx, welches den HTTPS-Traffic auf Port 8443 leitet.
  • DNS: In der /etc/hosts-Datei konfiguriert; es wird überprüft, ob die Seite über einen Alias per HTTPS verfügbar ist.