In dieser Laborumgebung ist der Zugriff nur auf die AWS-Services beschränkt, die zum Ausführen des Labs erforderlich sind. Wenn Sie versuchen, auf andere Dienste zuzugreifen oder Aktionen auszuführen, die über die in diesem Lab beschriebenen hinausgehen, können Fehler auftreten.
Für den ersten Challenge der Kompetenz **KN06** wechseln Sie ins elfte Modul **Module 11 - Load Balancers and Caching**. Hier finden Sie die praktische Übung **Lab 11 - Load Balancing**. Diese ist Schritt für Schritt geleitet.
Die folgenden Challenges bauen auf diesem ersten Lab auf. Versuchen Sie deshalb die Schritte so zu dokumentieren, dass Sie darauf zurückgreifen können.
Das Lab dauert ca. 30'. Führen Sie alle Schritte konzentriert und der Reihe nach durch. Für den Leistungsnachweis zeigen Sie neben der Doku auch noch gleich live, dass der Loadbalancer funktioniert (Browser mehrmals hintereinander reloaden)
Der **Load Balancer** aus dem letzten Challenge und die **Auto Scaling Group** können unabhängig voneinder eingesetzt werden. Gemeinsam Kombiniert sind diese beiden Dienste allerdings unschlagbar und in einer **High Availability Umgebung** nicht wegzudenken.
Momentan aber schauen wir diese beiden Dienste losgelöst voneinander an. Im folgenden Auftrag geht es deshalb nur um die Vorzüge des **Auto Scalers**. Er stellt sicher, dass meine Ressourcen **immer** dem gewünschten Zustand (Desired state) entsprechen. Im folgenden Challenge setzen wir diese Dienst so auf, dass **immer mindestens zwei** EC2-Instanzen laufen. Falls eine Instanz wegfällt (z.B. versehntlich terminiert, SW-Issue oder technischer Defekt) wird automatisch eine neue Instanz hochgefahren.
Kombiniert man diesen Dienst mit dem **Loadbalancer** aus dem letzten Challenge, kann man sicherstellen, dass der Service eine um einiges höhere Verfügbarkeit erhält. Beim Ausfall einer Site (z.B. Datacenter Stromausfall) wird der Traffic automatisch auf die andere Site umgeleitet. Zusätzlich kann man diesen Dienst auch noch ergänzten mit Metrics. Z.B. Falls die CPU-Auslastung einen Grenzwert überschreitet, soll dynamisch eine weitere Instanz hochgefahren werden. Das ganze funktioniert auch umgekehrt. Falls die CPU-Auslastung unter den Grenzwert fällt, wird die zusätzliche Instanz automatisch terminiert. Man spricht in diesem Fall von **Elasticity**. Im Gegensatz zum Begriff **Scalability** (z.B. Einbau einer weiteren SSD) kann die Plattform "on-demand" Ressourcen hinzufügen oder entfernen.
#### Anleitung:
Als erstes werden Sie ein Launch Template erstellen.
Setzen Sie als erstes ein Launch-Template auf. Wählen Sie dazu links in der **Navigation Bar** unter **`Instances`** den Buttom **`Create Launch template`** aus. Dann konfigurieren Sie das LaunchTemplate mit folgenden Parametern:
- [**diesen Code**](https://gitlab.com/ser-cal/m346-scripts/-/blob/main/KN06/user-data-az.md?ref_type=heads) eingeben (Copy/Paste). Bitte darauf achten, dass **nur** der Code eingegeben wird. Die Erklärungen helfen Ihnen lediglich, den Code zu verstehen. Später, beim Leistungsnachweis, wird von Ihnen erwartet, dass Sie diesen bis ins Detail erklären können.
Wählen Sie wieder links in der **Navigation Bar** unter **`Auto Scaling`** das Unterverzeichnis **`Auto Scaling Groups`** aus. Dann klicken Sie auf den orangen Buttom **`Create Auto Scaling group`**. Danach erscheint eine neue Seite mit dem Titel **Choos launch template**, welches Sie wie folgt ausfüllen:
- Name:
- Auto Scaling group name: `KN06_XXX_AutoScalingGroup`
- Launch Template: `KN06_XXX_LaunchTemplate`
...sonst nichts ändern und mit **Next** bestätigen.
