{"id":29224,"date":"2026-09-12T08:00:00","date_gmt":"2026-09-12T06:00:00","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=29224"},"modified":"2026-09-11T21:47:47","modified_gmt":"2026-09-11T19:47:47","slug":"studyswipe-in-aws","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2026\/09\/12\/studyswipe-in-aws\/","title":{"rendered":"StudySwipe in AWS"},"content":{"rendered":"\n

StudySwipe ist eine Karteikarten-Anwendung: Man legt Ordner an, f\u00fcllt sie mit Karten und lernt sie im Swipe-Prinzip durch. Technisch besteht es aus einem Spring-Boot-Backend, einem React-Frontend und einer PostgreSQL-Datenbank. Entstanden ist es als Studienprojekt im dritten Semester, bis dahin lief es ausschlie\u00dflich lokal \u00fcber Docker Compose.<\/p>\n

Ausgangslage<\/h2>\n

F\u00fcr den Kurs Softw. Dev. Cloud Computing habe ich mich f\u00fcr ein Projekt entschieden, das folgendes Ziel hatte. Dieses Ziel hab ich mir am Anfang so notiert:<\/p>\n<\/div>\n\n\n\n

\n

\u201e1x Script laufen lassen und alles hochfahren k\u00f6nnen.”<\/p>\n<\/blockquote>\n\n\n\n

Was ich zu dem Zeitpunkt wusste war was eine EC2-Instanz grob ist, aber ich wusste nicht wie eine EC2-Instanz mit Docker zusammenspielt. Wie kommt ein Container, den ich lokal gebaut habe, \u00fcberhaupt auf die Maschine? Und was passiert eigentlich mit meiner docker-compose.yml<\/strong>, die bisher nur lokal existiert hat? Was haben AWS & Terraform damit zu tun?<\/p>\n

Genau diese Fragen zu beantworten war r\u00fcckblickend der eigentliche Kern des Projekts.<\/p>\n

Warum StudySwipe<\/h2>\n

Urspr\u00fcnglich wollte ich ein Projekt namens Aviation Photo nehmen, eine Datenbank f\u00fcr Flugzeugfotos mit Suche und Filtern.<\/p>\n

Ich habe w\u00e4hrend der Vorlesungen f\u00fcr Aviation Photo die Vorbereitungen getroffen, mich mit dem Projekt und AWS so vertraut wie m\u00f6glich gemacht, denn f\u00fcr dieses Projekt existierte bereits ein AWS Konto mit getrennter PROD\/TEST-Umgebung in produktiver Nutzung. In der letzten Vorlesung habe ich dann zusammen mit meinem Dozenten meine Optionen angeschaut, um mein Ziel zu erreichen. Dabei sind wir zu dem Entschluss gekommen, dass dieses Projekt nicht ideal daf\u00fcr geeignet ist. Da ich nicht vertraut war mit dem Tech-Stack, als auch das Projekt noch viele Fragezeichen aufgeschmissen hat. Ebenso w\u00fcrde ich nicht ohne Risiko arbeiten und eventuell etwas zerst\u00f6ren, wenn ich in einer bereits laufenden Umgebung arbeiten w\u00fcrde. Mit der gr\u00f6\u00dfte Punkt f\u00fcr StudySwipe war, dass StudySwipe bereits in GitLab versioniert war, mein SE3 Projekt war, der Tech-Stack (Java\/Spring Boot) war mir vertraut, und es fehlte genau das was ich mir als Ziel gesetzt habe: eine Deployment-Pipeline.<\/p>\n

Der direkte Vergleich der beiden Architekturen zeigt, wo ich bewusst einfacher geblieben bin:<\/p>\n<\/div>\n\n\n\n

<\/td>Aviation Photo<\/strong><\/td>StudySwipe<\/strong><\/td><\/tr>
Datenbank<\/td>RDS My SQL (managed)<\/td>Postgres im eigenen Container<\/td><\/tr>
Storage<\/td>S3 f\u00fcr Bilder<\/td>nicht ben\u00f6tigt<\/td><\/tr>
Domain\/HTTPS<\/td>Route 53 + Let’s Encrypt <\/td>nur IP, kein HTTPS<\/td><\/tr>
Umgebungen<\/td>PROD + TEST getrennt<\/td>eine einzige Instanz<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n

Aviation Photo hat eine deutlich produktionsn\u00e4here Infrastruktur. F\u00fcr mein Kurs-Projekt h\u00e4tten RDS und eine eigene Domain zus\u00e4tzliche Komplexit\u00e4t bedeutet, ohne dass ich dadurch mehr \u00fcber das gelernt h\u00e4tte, worum es mir ging. Ich wollte bei den Basics anfangen und verstehen, was jeder einzelne Baustein tut, statt m\u00f6glichst viele AWS-Dienste zu benutzen. Die rechte Spalte ist damit weniger eine Liste von L\u00fccken als eine bewusste Reihenfolge: erst das Fundament, der Rest kann sp\u00e4ter drauf.<\/p>\n

Erstmal: ein eigener AWS-Account<\/h2>\n

Bevor \u00fcberhaupt Code ins Spiel kam, brauchte ich eine Umgebung, in der ich gefahrlos experimentieren konnte. Zugriff auf ein bestehendes AWS-Konto hatte ich zwar, aber dort lief bereits etwas produktiv. Kein guter Ort, um Dinge auszuprobieren, deren Auswirkungen man noch nicht absch\u00e4tzen kann.<\/p>\n

Also eigener Account, und dann der Reihe nach das N\u00f6tigste: Root-Zugang mit Zwei-Faktor-Authentifizierung absichern, einen Budget-Alarm f\u00fcr den Fall, dass ich versehentlich etwas Teures laufen lasse, einen separaten IAM-Benutzer f\u00fcr die t\u00e4gliche Arbeit statt alles \u00fcber den Root-Account zu machen, und die AWS CLI lokal konfigurieren, damit Terraform sp\u00e4ter \u00fcberhaupt mit dem Konto sprechen kann.<\/p>\n

Klingt nach Formalit\u00e4ten, war aber r\u00fcckblickend eine der besseren Entscheidungen: Alles, was danach kam, inklusive mehrfachem kompletten L\u00f6schen und Neuaufbauen der gesamten Infrastruktur, konnte ich ohne Sorge machen. Im schlimmsten Fall w\u00e4re nur mein eigener Testaccount betroffen gewesen.<\/p>\n

Phase 1: Erstmal alles von Hand<\/h2>\n

Bevor ich irgendwas automatisiert hab, wollte ich die App einmal manuell auf einer EC2-Instanz zum Laufen bringen. Terraform hat mir daf\u00fcr eine leere Instanz erzeugt, den Rest hab ich per SSH selbst gemacht: Java installieren, Docker installieren, Postgres als Container starten, die Anwendung starten.<\/p>\n

Das war der Punkt, an dem ich das erste Mal richtig h\u00e4ngen geblieben bin. Die Anwendung fuhr hoch, aber ohne Datenbank-Anbindung:<\/p>\n

No bean named 'entityManagerFactory' available\n<\/code><\/pre>\n
Die Fehlermeldung selbst f\u00fchrt erstmal in die Irre, sie klingt nach einem Konfigurationsfehler in der Anwendung. Tats\u00e4chlich lag es am Build: Das Projekt hatte einen eigenen, selbstgebauten Mechanismus, um das Backend-Docker-Image zu erzeugen. Dieser hat alle Bibliotheken entpackt und in einen gemeinsamen Ordner zusammengef\u00fchrt, mit der Einstellung, bei Namenskonflikten einfach eine Version zu behalten und den Rest zu verwerfen:<\/p>\n
duplicatesStrategy(DuplicatesStrategy.EXCLUDE)\n<\/code><\/pre>\n
Das Problem: Mehrere Spring-Bibliotheken bringen jeweils eine Datei mit demselben Namen mit, eine Art Inhaltsverzeichnis, das Spring Boot sagt, welche Funktionen es beim Start automatisch aktivieren soll. Beim Zusammenf\u00fchren hat also nur eine dieser Dateien \u00fcberlebt, die anderen wurden stillschweigend weggeworfen. Darunter die f\u00fcr die Datenbank-Anbindung. Kein Fehler beim Bauen, keine Warnung, die App startete einfach unvollst\u00e4ndig.<\/p>\n
Nachweisen lie\u00df sich das mit einem Blick in die fertige jar-Datei. Der folgende Befehl listet ihren Inhalt auf und z\u00e4hlt, wie viele Eintr\u00e4ge davon im Bibliotheks-Ordner liegen:<\/p>\n
$ unzip -l application-plain.jar | grep -c 'BOOT-INF\/lib\/'\n0\n<\/code><\/pre>\n
Null Bibliotheken. Nach dem Fix, mit Spring Boots eigenem Build-Mechanismus\n(bootJar<\/strong> statt des selbstgebauten jar<\/strong>-Tasks), derselbe Befehl:<\/p>\n
$ unzip -l application-plain.jar | grep -c 'BOOT-INF\/lib\/'\n73\n<\/code><\/pre>\n
73 Bibliotheken, darunter der Postgres-Treiber, Hibernate und die\nSpring-Autokonfiguration, also genau das, was vorher gefehlt hat.<\/p>\n
Der Fix selbst waren am Ende zwei ge\u00e4nderte Zeilen:<\/p>\n
- copyFile jar.archiveFileName.get(), '\/app\/test_service.jar'\n+ copyFile bootJar.archiveFileName.get(), '\/app\/test_service.jar'\n<\/code><\/pre>\n
- from jar.destinationDirectory\n+ from bootJar.destinationDirectory\n<\/code><\/pre>\n
Beide Stellen verwiesen auf den Output des selbstgebauten jar<\/strong>-Tasks statt auf den von bootJar<\/strong>. Weil beide Varianten zuf\u00e4llig denselben Dateinamen erzeugen, ist nie aufgefallen, dass die falsche Datei ins Image gewandert ist. Der Weg dorthin war deutlich l\u00e4nger als der Fix selbst.<\/p>\n
Phase 2: Terraform und die Frage, was eigentlich wohin geh\u00f6rt<\/h2>\n
Terraform war von Anfang an dabei, die leere EC2-Instanz kam ja schon per terraform apply<\/strong>. Was ich in dieser Phase gelernt hab, war weniger die Syntax als die Frage, welche Ebene wof\u00fcr zust\u00e4ndig ist<\/strong>.<\/p>\n
Terraform beschreibt Infrastruktur: welche Maschine, welches Betriebssystem-Abbild, welche Netzwerk-Regeln, welche Zugriffsrechte. Was auf dieser Maschine dann l\u00e4uft, ist eine andere Ebene und daf\u00fcr gibt es in Terraform ein Feld namens user_data<\/strong>: ein Skript, das beim allerersten Hochfahren der Instanz automatisch ausgef\u00fchrt wird.<\/p>\n
Dort kam alles, was ich in Phase 1 manuell gemacht hatte rein. Der Ablauf verschob sich damit von \u201cich logge mich ein und richte ein\u201d zu \u201cdie Instanz richtet sich beim Booten selbst ein\u201d.<\/p>\n
Eine Eigenheit davon hat mich sp\u00e4ter nochmal besch\u00e4ftigt: user_data<\/strong> l\u00e4uft nur beim allerersten Boot<\/strong>. \u00c4ndere ich das Skript, passiert auf einer bereits laufenden Instanz gar nichts, Terraform speichert den neuen Wert zwar, ausgef\u00fchrt wird er aber nie. Um \u00c4nderungen daran zu testen, muss man die Instanz gezielt neu bauen lassen:<\/p>\n
terraform apply -replace="aws_instance.studyswipe_server"\n<\/code><\/pre>\n
In dieser Phase ist mir auch das erste Mal etwas passiert, das sich sp\u00e4ter wiederholt hat: Ich hatte postgres:latest<\/strong> verwendet, und latest<\/strong> zeigte inzwischen auf eine neue Hauptversion mit ge\u00e4ndertem internen Speicherformat:<\/p>\n
Error: in 18+, these Docker images are configured to store database\ndata in a format which is compatible with "pg_ctlcluster"\n<\/code><\/pre>\n
Ich hatte an meinem Setup nichts ge\u00e4ndert, aber die Umgebung hat sich unter mir ver\u00e4ndert. Dasselbe Muster kam sp\u00e4ter nochmal, als das gradle:alpine<\/strong>-Image in der CI-Pipeline eine viel neuere Gradle-Version enthielt als lokal und ein Build fehlschlug.<\/p>\n
Phase 3: Docker-Compose und ECR<\/h2>\n
Bis hierhin lief auf der Instanz eine Mischung, die ich mir selbst zusammengesetzt hatte: Backend direkt als systemd-Dienst, nur die Datenbank in einem Container, Nginx auf dem Host. Das funktionierte, war aber nicht die Struktur, die das Original-Projekt vorsah. Dort waren von Anfang an vier Container geplant: Datenbank, Backend, Frontend und Nginx, alle \u00fcber docker-compose.<\/p>\n
Ich hab mich f\u00fcr den Umbau entschieden, obwohl das, was ich hatte, bereits lief. Das war keine leichte Entscheidung.<\/p>\n
Dagegen sprach:<\/strong> Das bestehende Setup lief nachweislich, war getestet, und der Umbau bedeutete, Backend und Frontend erst zu containerisieren, ECR einzurichten und dabei den Fat-Jar-Bug im Original-Build zu finden. Arbeit f\u00fcr etwas, das schon funktionierte.<\/p>\n
Daf\u00fcr sprach:<\/strong> Das Original-Projekt war von Anfang an so gedacht. Ein einziger docker-compose up<\/strong> als Startbefehl liegt n\u00e4her an meinem Ziel als vier verschiedene Mechanismen nebeneinander (systemd f\u00fcrs Backend, Docker f\u00fcr die Datenbank, Nginx auf dem Host). Und f\u00fcr die Automatisierung wird das Provisionierungs-Skript dadurch deutlich einfacher: statt Java, Docker, Nginx und systemd einzeln zu installieren und zu konfigurieren, reicht \u201cDocker installieren, docker-compose up<\/strong>\u201d. Die ganze Komplexit\u00e4t steckt dann im Compose-File statt im Skript.<\/p>\n
Damit kam die Frage, die vorher gar nicht existiert hatte: Wie kommen vier fertig gebaute Container-Images automatisch auf eine neue Instanz? Genau hier hat sich die anf\u00e4ngliche Wissensl\u00fccke geschlossen. Die Antwort ist ECR, eine Container-Registry bei AWS. Ich baue die Images lokal, lade sie einmal hoch, und die Instanz zieht sie sich beim Booten selbst. Authentifiziert \u00fcber eine IAM-Rolle, ohne dass irgendwo ein Passwort im Skript steht.<\/p>\n
Damit war auch klar, wie sich lokale und entfernte Docker-Umgebung zueinander verhalten. Zwei komplett getrennte Docker-Installationen, die nichts voneinander wissen. Die eine baut, die andere f\u00fchrt aus. ECR ist das Bindeglied dazwischen.<\/p>\n
Das Timing-Rennen mit ECR<\/h2>\n
Nach dem ersten kompletten terraform destroy<\/strong> und terraform apply<\/strong> kam dieser Fehler:<\/p>\n
ERROR: for backend  failed to resolve reference\n"...studyswipe-backend:latest": not found\n<\/code><\/pre>\n
Die Ursache: Registry (ECR) und Server (EC2) lagen im selben Terraform-Projekt. Ein einziger apply<\/code> hat beides gleichzeitig erzeugt. Die Instanz war nach etwa anderthalb Minuten fertig gebootet und wollte sofort die Images abholen, aber die musste ich erst manuell hochladen und das dauerte l\u00e4nger, weil das Frontend-Image fast 800 MB gro\u00df ist.<\/p>\n
Der erste Gedanke war, schnell nachzupushen, w\u00e4hrend die Instanz noch bootete. Das hat funktioniert. Aber es war offensichtlich keine L\u00f6sung, sondern ein Test um zu sehen ob alles funktioniert soweit. Denn das n\u00e4chste Mal mit langsamerem Internet oder gr\u00f6\u00dferem Image h\u00e4tte es wieder nicht geklappt.<\/p>\n
Die eigentliche L\u00f6sung kam, als klar wurde, warum das Rennen \u00fcberhaupt entstehen konnte. Zwei Dinge mit v\u00f6llig unterschiedlicher \u00c4nderungsgeschwindigkeit lagen im selben Terraform-Zustand. Die Registry \u00e4ndert sich fast nie, die Instanz wird bei jedem Test neu gebaut, die Images \u00e4ndern sich bei jedem Code-Release.<\/p>\n
Ich hab beides in zwei getrennte Terraform-Projekte aufgeteilt:<\/p>\n
terraform\/\n\u251c\u2500\u2500 registry\/          \u2190 nur die ECR-Repositories\n\u2502   \u251c\u2500\u2500 main.tf\n\u2502   \u2514\u2500\u2500 outputs.tf\n\u2514\u2500\u2500 infrastructure\/    \u2190 Netzwerk, IAM, EC2, Elastic IP\n    \u251c\u2500\u2500 main.tf\n    \u251c\u2500\u2500 iam.tf\n    \u251c\u2500\u2500 user_data.sh.tpl\n    \u2514\u2500\u2500 ...\n<\/code><\/pre>\n
In infrastructure<\/strong> werden die Repositories nicht mehr erzeugt, sondern nur noch nachgeschlagen:<\/p>\n
data "aws_ecr_repository" "backend" {\n  name = "studyswipe-backend"\n}\n<\/code><\/pre>\n
Der Unterschied ist nicht die Ordnerstruktur an sich, sondern dass sie die richtige Reihenfolge erzwingt: erst Registry bauen, dann in Ruhe die Images hochladen, danach erst die Instanz starten, die garantiert etwas vorfindet. Vorher war diese Reihenfolge nur etwas, das ich mir selbst merken musste und deshalb vergessen konnte.<\/p>\n
Kleinere Stolpersteine<\/h2>\n
Nicht jedes Problem war eine gro\u00dfe Geschichte, aber es gab einige davon:<\/p>\n
SSH-Key-Rechte unter Windows.<\/strong> Mein privater Schl\u00fcssel lag in einem OneDrive-Ordner mit zu offenen Zugriffsrechten:<\/p>\n
UNPROTECTED PRIVATE KEY FILE!\nPermissions for 'studyswipe-key.pem' are too open.\n<\/code><\/pre>\n
Gel\u00f6st mit icacls<\/strong>, um die Rechte auf meinen eigenen Benutzer zu beschr\u00e4nken. Ein Windows-spezifisches Problem, das man auf einem Linux-Rechner so nie h\u00e4tte.<\/p>\n
Java-Versions-Chaos.<\/strong> Mein lokal installiertes Java war neuer als das, was der im Projekt hinterlegte Gradle-Wrapper verstand:<\/p>\n
Unsupported class file major version 69\n<\/code><\/pre>\n
Erschwerend kam dazu, dass java -version<\/strong> im Terminal eine andere Version anzeigte als die, mit der Gradle tats\u00e4chlich arbeitete. Auf meinem Rechner waren mehrere Java-Versionen gleichzeitig installiert, und je nachdem welches Werkzeug man fragte, bekam man eine andere Antwort.<\/p>\n
Prozesse, die an der SSH-Sitzung h\u00e4ngen.<\/strong> Als ich das Backend testweise direkt gestartet hatte, war es nach einem Verbindungsabbruch pl\u00f6tzlich weg. Ein Programm, das man im Vordergrund einer SSH-Sitzung startet, wird beendet, sobald die Verbindung endet, auch unbeabsichtigt. Die L\u00f6sung war, es als systemd-Dienst einzurichten, der unabh\u00e4ngig von der Sitzung l\u00e4uft und nach einem Neustart automatisch wieder hochkommt.<\/p>\n
Die alte GitLab-Pipeline.<\/strong> Sie war seit der Projektabgabe nicht mehr gelaufen und schlug fehl, weil in der settings.gradle<\/strong> ein Modul eingebunden war, dessen Ordner es gar nicht mehr gab. Lokal mit \u00e4lterem Gradle war das nur eine Warnung, mit der neueren Version im CI-Image ein harter Fehler. Zus\u00e4tzlich hab ich die Gradle-Version im Image festgenagelt, statt sie \u00fcber latest<\/strong> bestimmen zu lassen.<\/p>\n
Ein Fehler nachdem man dachte alles sei getan<\/h2>\n
Dieses Problem ist mir nach meiner Pr\u00e4sentation passiert. Als ich das Deployment eigentlich schon f\u00fcr fertig hielt ist beim erneuten Ausf\u00fchren von deploy.ps1<\/strong> der ECR-Login fehlgeschlagen:<\/p>\n
Error response from daemon: login attempt to\nhttps:\/\/...amazonaws.com\/v2\/ failed with status: 400 Bad Request\n<\/code><\/pre>\n
Was folgte, war eine Reihe von Theorien auf der Suche nach dem Fehler:<\/p>\n
Erste Theorie: Der Token ist abgelaufen.<\/strong> Klingt naheliegend, weil zwischen den Versuchen lag etwas Zeit. Stimmt aber nicht, denn der Token wird bei jedem Aufruf neu bei AWS angefordert, ein \u201calter\u201d Token existiert also gar nicht.<\/p>\n
Zweite Theorie: Die Uhrzeit meiner Docker-VM stimmt nicht.<\/strong> Docker Desktop l\u00e4uft unter Windows \u00fcber eine Linux-VM, die eine eigene Systemuhr hat. Und tats\u00e4chlich zeigte docker ps<\/strong> einen Container mit dem Erstellungsdatum \u201c2 years ago\u201d, den es unm\u00f6glich so lange geben konnte. AWS reagiert empfindlich auf falsche Systemzeiten. Nach einem Neustart der VM war der Zeitstempel korrekt, aber der Login-Fehler blieb.<\/p>\n
Dritte Theorie: Es liegt an der Terminal-Umgebung.<\/strong> Ein manueller Test in einem separaten PowerShell-Fenster hatte funktioniert, im IDE-Terminal nicht. Also lag es vermutlich an unterschiedlichen Umgebungsvariablen. Auch das lie\u00df sich widerlegen, da in einem komplett frischen externen Fenster derselbe Fehler auftrat.<\/p>\n
Was am Ende geholfen hat, war ein direkter Vergleichstest mit demselben<\/strong> Token. Diese Variante schlug fehl:<\/p>\n
aws ecr get-login-password --region $REGION `\n    | docker login --username AWS --password-stdin $REGISTRY\n<\/code><\/pre>\n
Diese funktionierte sofort:<\/p>\n
$token = (aws ecr get-login-password --region $REGION).Trim()\ndocker login --username AWS `\n    --password $token `\n    $REGISTRY\n<\/code><\/pre>\n
Der Unterschied ist die Pipe. Windows-PowerShell reicht scheinbar Text zwischen zwei externen Programmen anders durch als innerhalb der eigenen Umgebung. Dabei findet vermutlich eine Umkodierung statt, die bei normalem Text nie auff\u00e4llt, bei einem langen, zuf\u00e4llig aussehenden Token aber offenbar zu Besch\u00e4digungen f\u00fchren kann. Zumindest w\u00e4re das eine Erkl\u00e4rung f\u00fcr mich. Der Token sah am Bildschirm identisch aus, die L\u00e4nge stimmte und trotzdem kam bei Docker etwas anderes an.<\/p>\n
Drei falsche Theorien und jedes mal die Kette weiter in einzelne Teile zerlegt und jeden Teil einzeln getestet bis man das Problem gefunden hat.<\/p>\n
Der Smoke-Test<\/h2>\n
Eine Sache die ich noch unbedingt hinzuf\u00fcgen wollte war ein Smoke-Test. Da mein Deployment-Skript immer mit \u201cFertig\u201d endete, unabh\u00e4ngig davon, ob die App danach wirklich erreichbar war. terraform apply<\/code> sagt nur, dass die Ressourcen existieren und nicht, dass etwas funktioniert.<\/p>\n
Also hab ich am Ende einen Test erg\u00e4nzt, der wiederholt versucht, die Seite aufzurufen:<\/p>\n
for ($i = 1; $i -le $maxAttempts; $i++) {\n  try {\n    $r = Invoke-WebRequest -Uri "http:\/\/$ip" `\n        -UseBasicParsing -TimeoutSec 5\n    if ($r.StatusCode -eq 200) {\n      $success = $true\n      break\n    }\n  } catch {\n    Write-Host "... noch nicht bereit ($i von $maxAttempts)"\n  }\n  Start-Sleep -Seconds 10\n}\n<\/code><\/pre>\n
Ein echter Durchlauf sieht dann so aus:<\/p>\n
=== 5. Smoke-Test ===\n... noch nicht bereit (Versuch 1 von 18)\n... noch nicht bereit (Versuch 2 von 18)\n...\nApp erreichbar nach 120 Sekunden (Status 200)\n<\/code><\/pre>\n
Zwei Minuten von einer leeren AWS-Umgebung bis zur laufenden Anwendung und jetzt automatisch best\u00e4tigt statt manuell im Browser nachgeschaut.<\/p>\n
Beim ersten echten Einsatz hat der Test \u00fcbrigens sofort etwas gefunden: Er meldete, dass die App nicht antwortet, weil die Images gar nicht erst in ECR angekommen waren. Ohne den Test h\u00e4tte ich das erst gemerkt, wenn ich zuf\u00e4llig die Seite aufgerufen h\u00e4tte.<\/p>\n
Was am Ende steht<\/h2>\n
Ein Skript, das aus einer leeren AWS-Umgebung heraus die komplette Infrastruktur aufbaut, die Anwendung baut und ausliefert und am Ende \u00fcberpr\u00fcft, ob sie wirklich l\u00e4uft. Dazu drei weitere Skripte f\u00fcr den restlichen Lebenszyklus: destroy, pause, resume.<\/p>\n
Der Unterschied zwischen \u201cpause\u201d und \u201cdestroy\u201d ist das destroy<\/strong> und deploy<\/strong> beweisen, dass wirklich alles reproduzierbar aus dem Code entsteht, allerdings alle Daten daf\u00fcr ins Wasser fallen, weil eine neue Instanz mit neuer Festplatte entsteht. pause<\/strong> und resume<\/strong> erhalten die Daten, beweisen aber nichts \u00fcber den Neuaufbau. Am Ende brauchte ich beide, da ich unbedingt eine Option wollte, die Instanz runterzufahren oder zu pausieren ohne dabei zum Beispiel Karteikarten zu l\u00f6schen. Das w\u00fcrde den ganzen Sinn des StudySwipe Projekts besiegen.<\/p>\n
Damit pause<\/strong> und resume<\/strong> \u00fcberhaupt praktikabel sind, kam noch eine Elastic IP dazu, eine feste \u00f6ffentliche Adresse, die an die Instanz gebunden bleibt. Ohne sie bekommt eine gestoppte Instanz beim n\u00e4chsten Start eine v\u00f6llig neue IP, was jedes Lesezeichen und jeden SSH-Befehl ung\u00fcltig macht. In Terraform sind das drei Zeilen. Der eigentliche Punkt ist, dass die Zuordnung damit automatisch mitwandert, statt ein manueller Schritt zu sein, den man vergessen kann.<\/p>\n
Was als N\u00e4chstes m\u00f6glich w\u00e4re<\/h2>\n
HTTPS.<\/strong> Aktuell fehlt es, und konkret merkt man das an einer Stelle: Die App setzt beim Ordnerwechsel ein secure<\/strong>-Cookie, das Browser \u00fcber eine unverschl\u00fcsselte Verbindung grunds\u00e4tzlich ablehnen. Dadurch funktioniert die Lernkarten-Ansicht nicht. Um das sauber zu l\u00f6sen, braucht es eine Kette von Voraussetzungen: feste IP (habe ich inzwischen \u00fcber eine Elastic IP), dann eine Domain, auf die ein Zertifikat ausgestellt werden kann.<\/p>\n
Datenbank als eigener Dienst.<\/strong> Postgres l\u00e4uft aktuell als Container auf derselben Instanz. Mit RDS w\u00e4re die Datenbank unabh\u00e4ngig von der Instanz, Daten w\u00fcrden dann auch ein destroy<\/strong> \u00fcberleben.<\/p>\n
Die Pipeline weiter nach vorne ziehen.<\/strong> Aktuell baue und pushe ich die Images von meinem eigenen Rechner aus. Der n\u00e4chste logische Schritt w\u00e4re, das in die GitLab-CI zu verlagern, sodass ein Push auf den Branch den ganzen Ablauf ausl\u00f6st.<\/p>\n
Learnings<\/h2>\n
latest<\/code> ist kein fester Punkt.<\/strong> Zweimal ist mir die Umgebung unter den F\u00fc\u00dfen weggerutscht, ohne dass ich etwas ge\u00e4ndert hatte, einmal bei Postgres, einmal beim Gradle-Image in der CI. Seitdem pinne ich Versionen, sobald Reproduzierbarkeit eine Rolle spielt.<\/p>\n
Infrastruktur und Anwendung sind unterschiedliche Ebenen mit unterschiedlichen Lebenszyklen.<\/strong> Das ECR-Timing-Problem war im Kern kein Timing-Problem, sondern ein Struktur-Problem: Etwas, das sich fast nie \u00e4ndert (die Registry), lag im selben Zustand wie etwas, das bei jedem Test neu gebaut wird (die Instanz). Die Trennung hat nicht das Symptom behandelt, sondern die Ursache entfernt.<\/p>\n
Eine L\u00f6sung, die funktioniert, ist nicht automatisch die richtige.<\/strong> Das schnelle Nachpushen beim ECR-Problem hat funktioniert. Trotzdem war es keine L\u00f6sung, sondern eine Verlagerung des Problems auf mein Gl\u00fcck mit der Upload-Geschwindigkeit. Der Moment, in dem mir das aufgefallen ist, war r\u00fcckblickend wertvoller als der Fix selbst.<\/p>\n
Erst verstehen, dann automatisieren.<\/strong> Ich hab jeden Schritt zuerst von Hand gemacht, die App manuell auf der Instanz zum Laufen gebracht, die Container-Struktur manuell getestet, und erst danach automatisiert. Das hat sich mehrfach ausgezahlt: Wenn im automatisierten Ablauf etwas schiefging, wusste ich, wie das Ergebnis aussehen sollte, und konnte den Fehler eingrenzen, statt bei null anzufangen.<\/p>\n
Wenn eine Theorie nicht passt, weiter zerlegen statt weiter raten.<\/strong> Bei der Docker-Login-Geschichte hatte ich drei plausible Erkl\u00e4rungen, die alle falsch waren. Weitergeholfen hat erst, die Befehlskette in ihre Einzelteile zu trennen und mit demselben Token beide Varianten direkt gegeneinander zu testen. Das ist wahrscheinlich mein pers\u00f6nlich wichtigstes Learning aus dem Projekt, nicht ein technisches Detail, sondern eine Methode.<\/p>\n
Links<\/h2>\n