Ich bin 19, studiere Informatik und arbeite nebenbei als Minijobber im Kino. Das Studium macht Spaß, aber mir war ziemlich schnell klar: Wenn ich einen vernünftigen Werkstudentenjob im Bereich Cloud oder DevOps haben will, reicht Theorie allein nicht aus. "Ich hatte mal Java im ersten Semester" zieht bei Bewerbungen nicht. Ich brauchte ein echtes Projekt für mein Portfolio.
Deshalb habe ich mich an die Cloud Resume Challenge gesetzt. Rückblickend habe ich extrem viel gelernt, aber es gab Momente, in denen ich am liebsten meinen Laptop zugeklappt hätte.
Mein persönlicher Endgegner: Das API Gateway
Eigentlich dachte ich, das Backend wäre recht fix erledigt. Tja, falsch gedacht. API Gateway hat mich anfangs echt Nerven gekostet. Die Developer Experience war für mich erstmal miserabel. Ich habe gefühlt hundertmal Ressourcen angelegt, getestet und wieder gelöscht, bis ich überhaupt das Konzept von Stages und Invoke URLs richtig verstanden habe.
Als ich dachte, ich hätte es, kam die Lambda-Funktion ins Spiel. Die Kommunikation zwischen API Gateway, Lambda und DynamoDB über boto3 hatte ein paar ordentliche Stolpersteine für mich parat:
Typisierung: Ich habe ewig nach dem Fehler gesucht, warum der Counter nicht richtig rechnet. Irgendwann habe ich realisiert: Die Besucherzahl aus der Datenbank wird als String ausgelesen. Ein simples
int()in Python hat mein Problem gelöst.JSON Syntax: Das API Gateway verzeiht nichts. Wenn im Response-Body von Lambda die JSON-Syntax nicht zu 100 % stimmt, fliegt dir alles um die Ohren.
CORS: Der absolute Klassiker der Webentwicklung. Ich habe natürlich vergessen, CORS im API Gateway zu aktivieren, und durfte mich erstmal durch die Fehlermeldungen im Browser debuggen.
Automatisierung & CI/CD: Kein manuelles Hochladen mehr
Wenn man schon eine Architektur in der Cloud baut, will man den Code ja nicht jedes Mal manuell als ZIP-File hochladen. Deshalb habe ich mich in GitHub Actions eingearbeitet und eine CI/CD-Pipeline gebaut. Sobald ich neuen Code in mein Repo pushe, wird das Frontend automatisch in meinen S3-Bucket geladen und der CloudFront-Cache invalidiert. Das gleiche gilt für Änderungen im Backend. Es ist ein extrem cooles Gefühl, wenn man pusht und Sekunden später ist alles live.
Mein eigenes Setup: Terraform & IP-Tracking
Die Challenge gibt die grobe Richtung vor, aber ich wollte ein paar Dinge anders machen.
Infrastructure as Code mit Terraform:
Statt die Ressourcen einfach in der AWS Console zusammenzuklicken, habe ich die komplette Infrastruktur mit Terraform hochgezogen. Das hat zwar länger gedauert, aber IaC ist in der Praxis nun mal Standard. Jetzt steht mein gesamtes Setup sauber und reproduzierbar im Code.IP-Check für den Visitor Counter:
Am Standard-Setup hat mich gestört, dass der Zähler bei jedem Seiten-Refresh (F5) einfach nach oben geht. Das ist ja kein echtes Tracking. Ich habe mir über Terraform eine zweite DynamoDB-Tabelle angelegt, in der die IP-Adresse der Besucher geloggt wird. Bevor der Zähler hochgeht, prüft Lambda, ob die IP schon existiert. Damit die Tabelle nicht endlos wächst, nutze ich die TTL-Funktion (Time to Live) von DynamoDB, die den IP-Eintrag nach exakt 24 Stunden automatisch löscht.DevSecOps: CodeQL & GPG Signing:
Sicherheit wird oft erst am Ende bedacht, aber ich wollte es direkt richtig machen. Ich habe CodeQL in meine GitHub Actions Pipeline integriert, um meinen Code bei jedem Push automatisch auf Schwachstellen zu scannen. Außerdem habe ich GPG Signing für meine Git-Commits eingerichtet. Dieses kleine grüne "Verified"-Badge auf GitHub sieht nicht nur gut aus, sondern zeigt auch, dass ich mich mit sicheren Workflows auseinandergesetzt habe.
Fazit
Es war nicht immer einfach und ich musste mich in viele Themenbereiche wie AWS, Boto3 und Terraform komplett neu reinfuchsen. Aber genau das hat sich gelohnt. Ich habe jetzt ein viel besseres Verständnis dafür, wie die Cloud-Komponenten in der Praxis wirklich zusammenspielen.
Die Seite läuft, die Infrastruktur steht. Jetzt fehlt nur noch der passende Werkstudentenjob.
Top comments (0)