DevOps Projekt 3: Re-Factoring der Java-Webanwendung „profile“ auf AWS (Cloud-Native)

User → Route 53
Der Benutzer ruft die Anwendung über den Domainnamen auf.
Route 53 löst den Domainnamen in den CloudFront-Endpunkt auf.

Route 53 → CloudFront (CDN)
CloudFront dient als globaler Einstiegspunkt.
Statische Inhalte werden gecacht, dynamische Requests weitergeleitet.

CloudFront → Application Load Balancer (ALB)
CloudFront leitet Anfragen sicher per HTTPS an den ALB weiter.
Der ALB terminiert TLS/HTTPS.

ALB → Elastic Beanstalk (Tomcat Auto Scaling Group)
Der ALB verteilt den Traffic auf mehrere Tomcat-Instanzen,
die von Elastic Beanstalk automatisch verwaltet und skaliert werden.

Application → Managed Backend Services
Die Java-Webanwendung greift auf folgende AWS-Services zu:

• Amazon RDS für MySQL-Datenbankzugriffe
• Amazon ElastiCache (Memcached) für Caching
• Amazon MQ (ActiveMQ) für Messaging

Monitoring & Health Checks

• ALB Health Checks prüfen die Anwendung
• Elastic Beanstalk & CloudWatch überwachen Instanzen und skalieren automatisch

1) Login to AWS Account

- Ziel:

- Warum:

- Wie (Vorgehen):

• In die AWS Console einloggen
• Region auswählen (z.B. us-east-1)
• Überprüfen: EC2, VPC, RDS, Elastic Beanstalk sind verfügbar

2) Create Key Pair for Beanstalk Instance Login

- Ziel:

- Warum:

- Wie (Vorgehen):

• EC2 → Key Pairs → Create key pair
• Name setzen ( profile-rearch-key)
• Format: .pem downloaden und sicher speichern

3) Create Security Group for Backend (ElastiCache, RDS & ActiveMQ)

- Ziel:

- Warum:

- Wie (Vorgehen):

• EC2 → Security Groups → Create security group (name: profile-backend-SG)
• Inbound nur aus dem Beanstalk-SG erlauben (später, nachdem Beanstalk existiert)

4) Create Backend Managed Services: RDS, Amazon ElastiCache, Amazon ActiveMQ

- Ziel:

- Warum:

- Wie (Vorgehen)

4.1 RDS (MySQL)

• Amazon RDS → Parameter Group (Konfiguration) herstellen:
  • In AWS wird das Verhalten von MySQL (Datenbank-Parameter) nicht „direkt“ an der RDS-Instanz konfiguriert, sondern sauber über eine DB Parameter Group
• Amazon RDS → Subnet Groups herstellen:
  • Ein DB Subnet Group definiert, in welchen Subnets (und Availability Zones) eine RDS-Datenbank betrieben werden darf und für sichere und hochverfügbare Platzierung der Datenbank im VPC
• Amazon RDS → database herstellen:
  • Engine: MySQL
  • Parameter Group
  • Subnets auswählen (private)
  • Security Group: SG-backend (profile-backend-SG)
  • DB-Name/User/Password definieren
  • Endpoint notieren (für App-Config)

4.2 ElastiCache (Memcached)

• Amazon ElastiCache → Parameter Group herstellen
• Amazon ElastiCache → Subnet Groups herstellen
• Amazon ElastiCache → database herstellen:
  • Memcached
  • Parameter Group
  • Subnets Group
  • Security Group: SG-backend (profile-backend-SG)
  • Name

4.3 Amazon MQ (RabbitMQ)

• Amazon MQ → Create broker → RabbitMQ
• Ein Broker ist der zentrale Nachrichtenserver, der Nachrichten entgegennimmt, speichert und weiterleitet.
• VPC/Subnets (default) auswählen
• Security Group: profile-backend-SG
• Broker Endpoint + User/Password notieren

Screenshot-Idee: RDS Endpoint / ElastiCache Endpoint / MQ Broker Details

5) DB aus der App-Quellcode in RDS-Datenbank initialisieren

- Ziel:

- Warum:

• Die Applikation erwartet eine vordefinierte Datenbankstruktur
• Amazon RDS startet ohne Tabellen oder Daten
• Der Import stellt sicher, dass:
• Tabellen korrekt angelegt sind
• Constraints & Relationen vorhanden sind

- Wie (Vorgehen):

Die Initialisierung erfolgt einmalig über eine temporäre EC2-Instanz (MySQL-Client). Nach dem Import wird die Instanz wieder gelöscht.

1. Temporäre EC2 erstellen (mysql-client)
   Ubuntu-Instanz mit eigene Security Group nur für den Import. Inbound: SSH (22) → MyIP.
2. Temporäre EC Per Git Bash verbinden
   

   ssh -i project-prod-key.pem ubuntu@<PUBLIC_IP_MYSQL_CLIENT>

3. mysql-client & git installieren (Verbindung zu Amazon RDS / git → Source Code klonen)
   

   sudo apt update
   sudo apt install mysql-client git -y

4. RDS Security Group öffnen (nur für mysql-client)
   Inbound Rule in RDS-SG: MySQL (3306) → Source: SG der mysql-client EC2.
5. Source Code klonen & Branch wechseln
   

   git clone https://github.com/<username>/profile.git
   cd profile
   git checkout awsrefactor
   cd src/main/resources

   Hier liegt db_backup.sql (Schema + Initialdaten).
6. Schema in RDS importieren
   

   mysql -h <RDS_ENDPOINT> -u <RDS_DB_USERNAME> -p <RDS_DB_NAME> < src/main/resources/db_backup.sql

7. Ergebnis prüfen
   

   mysql -h <RDS_ENDPOINT> -u <DB_USERNAME> -p
   SHOW TABLES;

   

8. mysql-client EC2 löschen
   Instanz wird nicht mehr gebraucht → terminieren.

6) Create Elastic Beanstalk Environment

- Ziel:

- Warum

- Wie (Vorgehen)

Elastic Beanstalk – Architektur (ALB + Auto Scaling + Tomcat)

Elastic Beanstalk verwaltet das komplette Runtime-Setup: Load Balancer, Auto Scaling Group, EC2/Tomcat-Instanzen sowie Monitoring (CloudWatch). Das Artefakt (WAR) liegt in einem S3 Bucket.

6.1 IAM-Rolle für EB erstellen (EC2 starten, ALB konfigurieren, Logs schreiben: benötigen explizite Berechtigungen)

• Policy:AdministratorAccess-AWSElasticBeanstalk (Erlaubt EB, alle benötigten Ressourcen zu orchestrieren)
• Policy:AWSElasticBeanstalkWebTier (Zugriff für Web-/App-Komponenten (ALB, EC2, Health Checks)
• Policy:AWSELasticBeanstalkCustomPlatformforEC2Role
• Policy:AWSElasticBeanstalkRoleSNS

6.2 EB Application erstellen

• AWS Console → Elastic Beanstalk
• Platform: Tomcat

6.3 Environment konfigurieren (Tomcat)

• Platform: Sample Application auswählen(eigenes Artefakt (WAR) wird später deployed)
• Service Role: Automatisch erstellt von Elastic Beanstalk
• EC2 Instance Profile(zuvor erstellte IAM-Rolle, Key Pair)
• Environment Type: Load balanced
• Deployment Policy: Rolling Deployment(Keine Downtime, Instanzen werden nacheinander aktualisiert)

Egebnis, Nach wenigen Minuten erstellt Elastic Beanstalk automatisch:

• Application Load Balancer
• Auto Scaling Group
• EC2 Tomcat Instanzen
• Health Checks
• CloudWatch Monitoring

Die Umgebung ist bereit, das eigene WAR-File kann jetzt deployed werden

7) Deploy Artifact to Beanstalk

- Ziel:

- Warum

- Wie (deployment des Artefakts zu Elastic Beanstal)

1. Backend-Informationen im Code prüfen
   Sicherstellen, dass der Quellcode alle notwendigen AWS-Backend-Daten enthält:
   • Amazon RDS (Endpoint, Benutzername, Passwort)
   • Amazon MQ (Endpoint, Benutzername, Passwort)
   • Amazon ElastiCache (Endpoint)
2. Quellcode lokal klonen und öffnen
   Das Repository aus GitHub auf die lokale Maschine klonen und in VS Code öffnen.
3. Backend-Endpunkte konfigurieren
   Datei öffnen: src/main/resources/application.properties
   Die bisherigen lokalen Namen (db01, mc01, rmq01) durch die echten AWS-Endpoints von RDS, ElastiCache und Amazon MQ ersetzen.
4. Artefakt lokal bauen
   Im Projektverzeichnis über Git Bash den Build starten:

   mvn install

5. Artefakt prüfen
   Nach erfolgreichem Build wird der Ordner target/ erzeugt.
   Darin befindet sich das Deploy-Artefakt: profile-v2.war
6. Deployment zu Elastic Beanstalk
   In der AWS Console:
   • Elastic Beanstalk → Environments
   • Environment auswählen: profile-refactor-beanapp-prod
   • Upload and Deploy → profile-v2.war auswählen
   - Die Anwendung ist nun über die von AWS generierte Domain erreichbar (HTTP, noch nicht gesichert).
   
   
   

   Zugriff über die Elastic-Beanstalk-Domain (HTTP – „Nicht sicher“)

   Die Events zeigen den laufenden Deployment-Prozess.

   
7. HTTPS Listener konfigurieren
   Elastic Beanstalk → Configuration → Instance traffic and scaling → Load Balancer:
   • Neuen Listener hinzufügen
   • Protocol: HTTPS (443)
   • SSL-Zertifikat aus AWS Certificate Manager auswählen
8. Domain mit GoDaddy verbinden
   In GoDaddy einen neuen DNS-Record anlegen:
   • Name: profilerefarch
   • Value: Elastic Beanstalk / ALB Domain Name
   - Ergebnis: Die Anwendung ist nun über die eigene Domain mit HTTPS (sichere Verbindung) erreichbar.
   
   
   

Ergebnis: Die Java-Webanwendung läuft cloud-nativ auf Elastic Beanstalk, ist automatisch skaliert, überwacht und sicher per HTTPS erreichbar.

8) Create CDN with SSL Cert (CloudFront)

- Ziel:

- Warum

Wie (Vorgehen)

Aktuell zeigt unsere Domain noch direkt auf den Elastic-Beanstalk-Load-Balancer (Beanstalk-Endpunkt). Im nächsten Schritt wird dieser DNS-Eintrag entfernt und durch eine Amazon CloudFront Distribution ersetzt.

Dazu wird in GoDaddy der bestehende DNS-Record gelöscht, der auf den Beanstalk-Endpunkt verweist. Anschließend wird ein neuer DNS-Record erstellt, der auf die CloudFront-Distribution zeigt.

• CloudFront Distribution erstellen
• Origin: ALB/Beanstalk Endpoint
• ACM Zertifikat (für CloudFront: in us-east-1) wählen
• Cache Behavior konfigurieren