Der Webservice wird auf der Google Cloud Platform (GCP) gehostet:
Die Produktivumgebung des Webservice wird auf der Google Cloud Platform (GCP) gehostet:
-**Details**: tbd
-**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 basierend auf den Anwendungsbedürfnissen zugewiesen und nach Bearbeitung wieder entzogen, um effiziente Nutzung der verfügbaren Google Cloud-Credits sicherzustellen
-**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
-**OpenTofu**: Deklarative Verwaltung der Cloud-Infrastruktur
-**Ansible**: Konfigurationsmanagement und Anwendungsbereitstellung
## Technologiewahl
...
...
@@ -25,54 +30,43 @@ Der Webservice wird auf der Google Cloud Platform (GCP) gehostet:
## Umgebungen
-**Entwicklung**: Lokal mit Vagrant
-**Staging**: Spiegelung der Produktionsumgebung mit reduzierten Ressourcen
-**Produktion**: Erweiterte Sicherheitsmaßnahmen und Monitoring
## Dienste
## Dienste <a id="Dienste"></a>
-**Webserver und Datenbank**: Einrichtung mit Ansible
-**Compute Engine**: Hostet VMs für Webservice und Redis-Datenbank
-**Cloud Monitoring**: Überwacht Leistung, bietet Einblicke in Logs, Metriken und Alarme
## Visuelle Hilfsmittel
-**Diagramme**: Erstellung mit draw.io (tbd)
-**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 prodBranch wird die Pipeline aktiviert.
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: Kompiliert Webservice für verschiedene Betriebssysteme und Architekturen, speichert Artefakte in der Package Registry
- Publish: Veröffentlicht die Build-Artefakte
-**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
## Persistenzschicht (Datenbank)
tbd
## Details zum Webservice
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.
### Dependencies, Run, Test, Build
```bash
go get -t ./...
go run .
go test-race-v ./...
go build -o ./artifact.bin ./*.go
```
## Persistenzschicht (Datenbank)
### Binary Ausführen
Für die Persistenz wird Redis verwendet, welches in einer separaten Compute Engine-Instanz innerhalb der GCP-Umgebung betrieben wird.
```bash
HOST=0.0.0.0 PORT=8080 ./artifact.bin
```
Die Einrichtung und Konfiguration erfolgt über Ansible.
### Zugriff
## Lifecycle
```bash
curl http://localhost:8080
```
-**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
### Health Check
## Weitere Konfigurationen
```bash
curl http://localhost:8080/health
```
-**Monitoring**: Die Anwendung wird mithilfe von GCP (siehe [Dienste](#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
