Implementierung des ersten Sprints
Im ersten Sprint wurde der funktionale Kern des MVP umgesetzt. Grundlage bildeten die vorgängige Technologie-Evaluierung (Bash + AWS CLI als bevorzugte Lösung) sowie die Architekturentscheidung zugunsten eines funktional strukturierten Monolithen. Diese Vorentscheide erlaubten eine nachvollziehbare, endbenutzerorientierte Umsetzung mit klarer Fehlerbehandlung.
Die zu implementierenden Inhalte entsprachen den ersten drei User Stories des Sprint-Backlogs:
- US.0: Evaluierung der Lösungsmöglichkeiten
- US.1: EC2-Instanz via CLI deployen
- US.2: Interaktive Parameter-Abfrage
- US.3: Befüllen des
userdata.yml-Templates
Die technische Umsetzung erfolgte in der Datei source/main.sh mit einer klaren Funktionsgliederung (main, get_user_input, generate_userdata, deploy_instance, cleanup). Damit wurde das im Architekturteil definierte Prinzip “Monolith mit interner Modularisierung” direkt angewendet.
US.0: - Evaluierung der Lösungsmöglichkeiten
Ziel der User Story
Die Projektleitung soll eine Evaluierung der bestmöglichen technischen Implementierung dieses Projekts durchführen, so dass Kosteneffizienz wie auch Ease of Use gewährt sind.
Implementierung
Eine Evaluierung wurde anhand vorgegebener Kriterien durchgeführt und kann hier gefunden werden: docs.abyss.li
Damit ist Userstory 0 umgesetzt: Eine Analyse wurde durchgeführt und ein Gewinner ausgewählt.
US.1 - EC2-Instanz via CLI deployen
Ziel der User Story
Die Projektleitung soll eine EC2-Instanz ohne manuellen Klickpfad in der AWS Console starten können, um die Bereitstellung reproduzierbar und effizient auszuführen.
Implementierung
Die Bereitstellung wurde in der Funktion deploy_instance() realisiert. Der technische Kern besteht aus einem parametrisierten Aufruf von aws ec2 run-instances.
Verwendete Parameter:
--image-idfür die gewählte AMI--instance-typefür die Instanzgrösse--subnet-idfür die Netzzuordnung--user-data file://...für Cloud-Init/Userdata--security-group-ids "sg-0cf71c3fee7dd4c65"(hardcoded) um die korrekte Security Group zuzuweisen--associate-public-ip-address(hardcoded) Damit die EC2-Instanz von aussen erreichbar ist--region "us-east-1"(hardcoded) Definiert die Region, in welcher die EC2-Instanz deployed wird--tag-specifications "ResourceType=instance,Tags=[{Key=Name,Value=$HOSTNAME}]"Definiert einen Tag namens “Name”, damit die Instanz im EC2-Dashboard den definierten Hostnamen als Namen hat
Die Rückgabe wird mit --query 'Instances[0].InstanceId' --output text auf die Instanz-ID reduziert und anschliessend plausibilisiert. Falls keine Instanz-ID geliefert wird, bricht das Skript kontrolliert mit Fehlermeldung ab.
Qualitätssicherung und Fehlertoleranz
- Globale Sicherheitsoptionen:
set -euo pipefail - Vorprüfung gültiger AWS-Anmeldedaten via
aws sts get-caller-identity - Eindeutige Konsolenausgaben zur Nachvollziehbarkeit der ausgeführten Schritte
Damit ist US.1 im Sinne der Story umgesetzt: Der eigentliche Deployment-Vorgang ist automatisiert, reproduzierbar und mit Basisschutz gegen Fehlkonfigurationen versehen.
US.2 - Interaktive Parameter-Abfrage
Ziel der User Story
Endbenutzer sollen die benötigten Deploy-Parameter während der Laufzeit eingeben können, ohne das Skript anpassen zu müssen.
Implementierung
Die Funktion get_user_input() implementiert einen geführten Eingabedialog mit den Feldern:
- AMI-ID (Pflichtfeld)
- Instance Type (Pflichtfeld)
- Subnet-ID (Pflichtfeld)
- Hostname (optional)
Für die Pflichtfelder wurden while-Schleifen mit Leereprüfung umgesetzt. Leere Eingaben werden unmittelbar mit einer klaren Fehlermeldung quittiert, anschliessend erfolgt die erneute Abfrage.
Nutzen für Benutzerfreundlichkeit
- Keine Anpassung von Quellcode erforderlich
- Reduktion von Eingabefehlern durch unmittelbare Validierung
- Transparenter Ablauf durch konsistente Prompt-Texte
Die User Story ist dadurch erfüllt, da die Parametrisierung interaktiv, robust und für nicht-technische Anwender nachvollziehbar gestaltet ist.
US.3 - Befüllen des userdata.yml-Templates
Ziel der User Story
Die Konfiguration der Instanz soll standardisiert über eine Template-Datei erfolgen, damit wiederkehrende Basiskonfigurationen nicht manuell reproduziert werden müssen. Ebenfalls wird so eine homogene Systemlandschaft gewährleistet.
Implementierung
Die Funktion generate_userdata() verarbeitet die Datei userdata.yml.template und erzeugt daraus eine konkrete Laufzeitdatei unter /tmp/userdata_generated.yml.
Umsetzungsschritte:
- Existenzprüfung des Templates (
-f) - Kopie in eine temporäre Zieldatei
- Platzhalterersetzung `` per
sed - Fallback-Verhalten: Ist kein Hostname gesetzt, wird der Platzhalter entfernt
Dieser Ansatz stellt sicher, dass sowohl ein expliziter Hostname als auch ein “hostname-freier” Betrieb unterstützt werden.
Betriebssicherheit
Temporäre Artefakte werden über trap cleanup EXIT zuverlässig entfernt. Dadurch bleiben nach der Ausführung keine sensiblen oder veralteten Userdata-Dateien im Dateisystem zurück.
US.3 gilt damit als umgesetzt, da das Befüllen des Templates automatisiert, reproduzierbar und betrieblich sauber erfolgt.
Zusammenfassung Sprint 1
Die Umsetzung der User Stories US.1 bis US.3 bildet den lauffähigen MVP-Kern:
- Interaktive Erfassung der benötigten Eingabewerte
- Automatisiertes Generieren der Userdata-Konfiguration
- Ausführung des eigentlichen EC2-Deployments via AWS CLI
Gleichzeitig wurde die Architekturvorgabe des Projekts eingehalten: ein einzelnes, portables Skript mit interner Funktionsstruktur statt verteilter Sub-Skripte. Dies erhöht die Nachvollziehbarkeit für Abnahme und Review und entspricht den priorisierten Projektzielen.