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
1 commit behind, 24 commits ahead of the upstream repository.
user avatar
allocate a virtual machine in google cloud
schnarkus authored
6a0995a6
History
user avatar 6a0995a6
History
Name Last commit Last update
configuration
gcp-vm-setup
routing
state
.gitignore
.gitlab-ci.yml
Containerfile
Makefile
README.md
go.mod
go.sum
main.go
README.md

Deliverable: Projektkonzept

Infrastruktur

Die Produktivumgebung des Webservice wird auf der Google Cloud Platform (GCP) gehostet:

  • Details zur Infrastruktur:
    • Maschinentyp: e2-small (1 vCPU, 2 GB RAM)
    • Region: Berlin (wenn verfügbar, Europa)
    • Betriebssystem: Ubuntu 22.04
    • Festplatte: 20 GB
    • Tags für Firewall: http-server,https-server

Ressourcenmanagement

  • Dynamische Zuweisung: Ressourcen werden nach Bedarf zugewiesen und nach Nutzung entzogen, um Google Cloud-Credits effizient zu nutzen
  • Skalierung: Compute Engine-Instanzen werden nach Ressourcenbedarf skaliert

Bereitstellungsprozess

  • OpenTofu: Deklarative Verwaltung der Cloud-Infrastruktur
  • Ansible: Konfigurationsmanagement und Anwendungsbereitstellung

Technologiewahl

  • Programmiersprache: Go
  • Container-Runtime: Podman
  • CI/CD: GitLab

Umgebungen

  • Entwicklung: Lokal mit Vagrant
  • Produktion: Erweiterte Sicherheitsmaßnahmen und Monitoring

Dienste

  • Compute Engine: Hostet VMs für Webservice und Redis-Datenbank
  • Cloud Monitoring: Überwacht Leistung, bietet Einblicke in Logs, Metriken und Alarme

Visuelle Hilfsmittel

  • Architekturdiagramm: Erstellung mit draw.io
  • TODO

CI/CD Pipeline

Die Konfiguration für den Build des Webservices erfolgt in der GitLab CI/CD-Pipeline. Diese unterscheidet die Stages Test, Build und Publish. Bei Merge-Requests oder Pushes auf den main- oder prod-Branch wird die Pipeline aktiviert.

  • Test: Tests mit golang:1.21 Docker-Image
  • Build: Baut Webservice für linux_amd64-Systeme und speichert Artefakte in der Package Registry
  • Publish: Veröffentlicht Docker-Container in der Container Registry

Abhängig vom Branch führt die Pipeline Tests aus, erstellt ein Static Binary und veröffentlicht einen Docker-Container, bei welchem die Versionierung auf der Pipeline-ID basiert.

Persistenzschicht (Datenbank)

Für die Persistenz wird Redis verwendet, welches in einer separaten Compute Engine-Instanz innerhalb der GCP-Umgebung betrieben wird.

Die Einrichtung und Konfiguration erfolgt über Ansible.

Lifecycle

  • DEV: Workstation als GitLab Runner: Deploy-Job auf der lokalen Workstation wird durch Registrierung der Workstation als GitLab Runner ausgeführt. Der Runner wird im Hochschul-GitLab registriert und bei Pushes auf den dev-Branch getriggert.
  • MAIN: Main to Prod: Änderungen vom Hauptzweig (main) werden in die Produktionsumgebung (prod) übernommen
  • FEATURES: Feature to Prod: Feature-Zweige werden in den Hauptzweig gemerged und schließlich in die Produktionsumgebung überführt
  • Pipeline Trigger: Die Pipeline wird durch Merge-Requests oder Pushes auf main, dev oder prod aktiviert

Weitere Konfigurationen

  • Monitoring: Die Anwendung wird mithilfe von GCP (siehe Dienste) überwacht
  • Sicherheit: TLS-Terminierung erfolgt durch ein selbstsigniertes Zertifikat in der Entwicklungsumgebung
  • DNS: In der Entwicklungsumgebung wird die DNS-Auflösung in der /etc/hosts-Datei konfiguriert; es soll nachgewiesen werden, dass die Seite über einen Alias per HTTPS verfügbar ist