Entwurf aus dem Einreichungsformular. Wird in Sprint 1 mit US.2 finalisiert.

Übersicht

graph LR
    A[GitLab MR-Pipeline] -->|sqs:SendMessage| B[SQS FIFO Queue]
    B -->|Trigger| C[Lambda Python]
    B -.->|nach Wiederholungen| D[Dead-Letter-Queue]
    C -->|RunInstances / Terminate| E[EC2 Review-Instanz]
    C -->|SSM Run Command| E
    C -->|Environment-URL| F[GitLab API]
    E -->|docker pull| G[GitLab Container Registry]

Jede Umgebung ist eine EC2-Instanz mit der Demo-Anwendung als Container, identifiziert über die Tags Projekt und MR-ID.

Lebenszyklus

Ereignis	Auslöser	Ablauf
MR eröffnet	MR-Pipeline, Job «deploy» mit Environment review/<MR-ID>	Image bauen und in die GitLab Registry pushen, Auftrag «deploy» einreihen. Die Lambda findet keine Instanz mit dem MR-Tag und startet eine neue aus dem Launch Template. Danach trägt sie die URL über die GitLab-API im Environment ein, so erscheint sie im MR.
Neuer Commit	Gleiche Pipeline erneut	Auftrag «deploy» mit neuem Image-Tag. Die Lambda findet die bestehende Instanz und aktualisiert sie über SSM Run Command (neues Image ziehen, Container neu starten). Instanz und URL bleiben gleich.
MR gemerged oder geschlossen	Bei MR-Pipelines startet GitLab automatisch den on_stop-Job	Auftrag «destroy» einreihen. Die Lambda terminiert alle Instanzen mit dem MR-Tag, auch solche, die noch starten.
Vergessen oder Fehler (Kann)	auto_stop_in und zeitgesteuerte Aufräum-Lambda	Entfernt Instanzen ohne aktives Environment oder älter als die TTL.

Abgrenzung Terraform

Terraform verwaltet die langlebige Basis-Infrastruktur: VPC, Subnetze, Security Groups, Queue mit Dead-Letter-Queue, IAM-Rollen, Lambdas und das Launch Template der Review-Instanzen. Die Review-Instanzen selbst sind bewusst nicht im Terraform-State. Sie leben nur Stunden bis Tage und entstehen ausschliesslich aus dem versionierten Launch Template. Ihre Konfiguration bleibt so im Code definiert, ohne dass jede Umgebung einen eigenen State braucht.

Nebenläufigkeit

Ein Tag allein verhindert keine Doppelanlage, wenn zwei Aufträge gleichzeitig laufen. Deshalb hat jeder MR eine eigene FIFO-Message-Group, die Lambda verarbeitet also pro MR höchstens einen Auftrag gleichzeitig. Doppelte Nachrichten filtert die FIFO-Deduplizierung (Pipeline-ID), zusätzlich bekommt jeder Start ein EC2-ClientToken, mit dem EC2 bei einer Wiederholung keine zweite Instanz anlegt.

Sicherheit

• Least Privilege für IAM-Rollen, der Runner darf nur sqs:SendMessage.
• Keine Secrets im Repository: geschützte CI/CD-Variablen, GitLab-Token im SSM Parameter Store.
• Kein SSH, Zugriff auf die Instanzen nur über SSM. Security Groups nur HTTP/HTTPS.