tbz-repos/m346
1
0
Fork 0
mirror of https://gitlab.com/ser-cal/m346.git synced 2024-11-22 17:52:01 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

Auftrag E) Einstieg

Browse Source
This commit is contained in:
Marcello Calisto 2023-10-18 13:11:07 +02:00
parent 3a0dc4f099
commit baedce2cb4
1 changed files with 4 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
KN06/KN06.md
View File

@ -528,13 +528,12 @@ Führen Sie nun folgende Schritte der Reihe nach durch, damit sie später **kein
#### Ausgangslage:
Sie wissen nun, wie man eine High Availability Plattform aufbaut und betreibt. Was nun noch fehlt ist, dass die Applikation **on-demand** weitere Instanzen hoch- und runterfahren kann. Im AWS Fachjargon nennt man diesen Prozess **Elasticity**. AWS Elasticity hilft, Geld zu sparen und gleichzeitig sicherzustellen, dass die Anwendungen immer reibungslos laufen.
#### Challenge +
##### Challenge +
:bulb:
Im letzten KN06-Challenge werden Sie **selbständig** eine solche Umgebung aufbauen. Erschwerend kommt jetzt also nur noch hinzu, dass Sie die Plattform so aufsetzen müssen, dass sie **elastisch skalieren** kann. Alles andere haben Sie bereits gemacht. Damit am Ende alles funktioniert, müssen sie für die neue **Auto Scaling Group** eine sogenannte **Dynamic scaling policy** erstellen. In diesem Fall mit dem **Target value = 20**. Das bedeutet, dass sobald Sie ihre Webseite mehr als 20x reloaden, automatisch weitere Instanzen hochgefahren und an den Load Balancer angehängt werden. Damit Sie dies auch beweisen können, erstellen Sie ein **neues Launch Template** mit leicht ergänztem Code. Dieser ist dafür verantwortlich, dass auf Ihrer Webseite unter der Availability Zone noch eine **zweite Zeile** erscheint mit der **Instanz-ID**. So kann man schön überprüfen, ob die neuen Instanzen auch vom Load Balancer angesprochen werden können.
Im letzten KN06-Challenge werden Sie **selbständig** eine **Elastic High Availability Plattform** aufbauen. Erschwerend kommt jetzt also nur noch hinzu, dass Sie die Umgebung so aufsetzen müssen, dass sie **elastisch skalieren** kann. Alles andere haben Sie bereits gemacht. Damit am Ende technisch alles funktioniert, müssen sie für die neue **Auto Scaling Group** eine sogenannte **Dynamic scaling policy** erstellen. In diesem Fall mit dem **Target value = 20**. Das bedeutet, dass sobald Sie ihre Webseite mehr als 20x reloaden, automatisch weitere Instanzen hochgefahren und an den Load Balancer angehängt werden. Damit Sie dies auch beweisen können, erstellen Sie ein **neues Launch Template** mit leicht ergänztem Code. Dieser ist dafür verantwortlich, dass auf Ihrer Webseite unter der Availability Zone noch eine **zweite Zeile** erscheint mit der **Instanz-ID**. So kann man schön überprüfen, ob die neuen Instanzen auch vom Load Balancer angesprochen werden können.
:bookmark_tabs: Die ergänzenden Skills bzgl. **elastischem** Setup werden Ihnen, wenn es soweit ist, step by step erklärt. Bzgl. Namenskonvention gibt es ebenfalls noch ein paar wichtige Informationen unten. Alles andere müssen Sie allerdings selber elaborieren.
Für das Setup nutzen Sie die Anleitung des letzten Challenges. Achten Sie darauf, dass die Namenskonvention **leicht angepasst** ist und dass Sie z.B. für das Launch Template ein **anderes Script** (ergänzt mit Instance-IDs) verwenden. Dies, weil Sie am Ende beweisen werden, dass Ihre Plattform am Ende in der Lage sein wird, **on-demand** neue Instanzen hinzuzufügen und dass der Load Balancer anschliessend auch darauf zugreifen kann.
:bookmark_tabs: Die ergänzenden Skills bzgl. **elastischem** Setup werden Ihnen, wenn es soweit ist, step by step erklärt. Bzgl. Namenskonvention gibt es ebenfalls noch ein paar wichtige Informationen unten. Alles andere müssen Sie allerdings **selber elaborieren**.
Nutzen Sie dazu die Anleitung des letzten Challenges. Achten Sie darauf, dass die Namenskonvention **leicht angepasst** wurde und dass Sie z.B. für das Launch Template ein **anderes Script** (ergänzt mit Instance-IDs) verwenden. Dies, weil Sie am Ende beweisen werden, dass Ihre Plattform in der Lage sein wird, **on-demand** neue Instanzen hinzuzufügen und dass der Load Balancer anschliessend auch darauf zugreifen kann.
Jetzt aber eins nach dem anderen.
Die Grafik unten zeigt, was mit **Elastic Load Balancing** gemeint ist.