mirror of
https://gitlab.com/ser-cal/m346.git
synced 2024-11-23 03:51:57 +01:00
486 lines
27 KiB
Markdown
486 lines
27 KiB
Markdown
[10]: https://git-scm.com/downloads
|
|
|
|
![TBZ Banner](../x_gitres/tbz_logo.png)
|
|
|
|
# KN04 Inhaltsverzeichnis
|
|
|
|
[TOC]
|
|
|
|
<br>
|
|
|
|
## Intro
|
|
|
|
Beachten Sie die [allgemeinen Informationen zu den Abgaben](../Abgaben.md).
|
|
|
|
Wir nutzen **Amazon Web Services** oder abgekürt **AWS**. Alles was wir hier umsetzen, bieten allerdings auch andere public cloud Anbieter (z.B. Microsoft Azure, Google Cloud Platform oder Linode).
|
|
|
|
|
|
<br>
|
|
|
|
## Challenges
|
|
|
|
### A) S3 Bucket erstellen und Objekte darin ablegen (Beginner)
|
|
|
|
#### Ausgangslage:
|
|
Amazon S3 ist ein **Object Store**. Die Daten werden in Form von "Objekten" gespeichert. Ein Objekt in S3 besteht aus den eigentlichen Daten (z. B. eine Bilddatei) und Metadaten (z. B. den Zeitstempel der Erstellung). Diese Objekte werden in sogenannten "Buckets" organisiert.
|
|
|
|
In diesem Auftrag werden Sie genau gleich, wie bereits in der Übung [KN02 Lab4.2](../KN02/KN02.md/#b-lab-42---s3) einen eigenen S3-Bucket erstellen und ein Bild darin ablegen. Dieses Bild müssen sie so berechtigen, dass **alle** darauf zugreifen können.
|
|
|
|
|
|
#### Die Verwaltung von Objekten bietet mehrere Vorteile:
|
|
|
|
1. Zuverlässige Datenspeicherung: Amazon S3 bietet eine hohe Verfügbarkeit und Haltbarkeit für gespeicherte Daten. Die Dateien werden automatisch auf mehreren Servern und Standorten repliziert, was Schutz vor Datenverlust bietet.
|
|
2. Skalierbarkeit und Flexibilität: S3 ermöglicht das Speichern und Abrufen von Daten jeder Größe. Dies ist ideal für das Hochladen von Bildern, Videos und anderen Mediendateien. Zudem können Sie problemlos weitere Buckets erstellen, wenn der Bedarf wächst.
|
|
|
|
|
|
|
|
#### Anleitung:
|
|
|
|
##### Schritt 1: Bucket erstellen
|
|
1. Öffnen Sie die [AWS Management Console](https://aws.amazon.com/console/).
|
|
2. Navigieren Sie zur S3-Dashboardseite.
|
|
3. Klicken Sie auf "Create bucket".
|
|
4. "Bucket name" eingeben. **Achtung:** Muss "unique" sein.
|
|
5. Public Access gewähren (Häckchen entfernen) **und** bestätigen, dass einverstanden (Häckchen hinzufügen)
|
|
6. Bucket erstellen (create)
|
|
|
|
##### Schritt 2: Permissions (Berechtigungen) für den Bucket setzen
|
|
1. Damit Sie später von überall her auf dieses Bild zugreifen können, muss eine entsprechende **Bucket policy** erstellt werden.
|
|
2. Bucket policy erstellen (Edit).
|
|
3. Bucket policy definieren (Allow-Regel für PublicRead einsetzen) gemäss Bild unten.
|
|
![Schema](./x_res/01_S3-Service_800.png)
|
|
|
|
|
|
##### Schritt 3: File hochladen
|
|
1. Unter **Objects** Klicken Sie auf **Upload**.
|
|
2. Es erscheint ein Window mit der Aufforderung **Datei hochladen**. Sie können dann mit **Add files** entsprechende Dateien (in unserem Fall ein Bild) hochladen.
|
|
3. Merken Sie sich die URL. Diese kann unter **Properties** nachgeschaut werden (wird bei der nächsten Übunge gebraucht)
|
|
|
|
|
|
#### Ziel der Übung
|
|
:bell: Sie wissen, wie man einen S3 Bucket erstellt, diesem Berechtigungen zuweist und sogenannte **Objects** darin ablegt. Objects können Bilder, Audiodateien, Scripts oder andere Dateiformate sein. Jedes einzelne Objekt besitzt einen einzigartigen **ARN** (Amazon Resource Name) - also einen eindeutigen Identifikator. Das heisst, dass ein Objekt individuell berechtigt werden kann und weltweit einzigartig ist. Ein Object-Store hat allerdings **keine** Hierarchie (Ordnerstruktur) und ist deshalb auch **nicht** für jeden Zweck einsetzbar. Überlegen Sie sich deshalb auch, in welchen Fällen diese Speicherart eher unvorteilhaft ist.
|
|
|
|
|
|
##### Leistungsnachweis
|
|
- [ ] Das hochgeladene Bild kann über die **Object URL** in einem beliebigen Webbrowser angezeigt werden.
|
|
- [ ] Differenziert und nachvollziehbar im persönlichen Repository dokumentiert.
|
|
- [ ] Fachgespräch mit Coach.
|
|
|
|
Beachten Sie ausserdem die [allgemeinen Informationen zu den Abgaben](../Abgaben.md).
|
|
|
|
|
|
:warning: **Hinweis:**
|
|
In der nächsten Übung wird dieses Bild nochmals benötigt. Sie bauen dann mit einem cloud-init Script einen Webserver und erzeugen darin eine PHP-Seite, welche das Bild auf einer Webseite anzeigt. Bitte erst **nach der Abgabe von KN04** löschen.
|
|
|
|
|
|
<br>
|
|
|
|
----
|
|
|
|
### B) Mit "Cloud-init" einen Webserver aufsetzen mit Zugriff auf Bild im S3-Bucket (Advanced)
|
|
|
|
#### Ausgangslage:
|
|
In diesem Auftrag werden Sie eine Amazon EC2-Instanz mit einem Cloud-Init-Script aufzusetzen. Schwerpunkt ist der Content dieses IaC-Scripts, welchen Sie mit Know-how aus der letzten Übung und ein bisschen Hilfe (siehe unten) selber zusammenbauen.
|
|
Das Script wird eine Ubuntu-Instanz mit einem Apache Webserver installieren und darauf die PHP-Webseite **test.php** einrichten, die das bereitgestellte Bild aus dem Amazon S3-Bucket einbettet.
|
|
|
|
#### Anleitung
|
|
|
|
Verwenden Sie den folgenden Inhalt für das **Cloud-init Script**. Gehen Sie Zeile für Zeile durch und ergänzen/korrigieren Sie diese wo nötig. Unter dem **zweiten write_files** erstellen Sie dann das PHP-File namens **test.php** nach Ihrem persönlichen Geschmack - passend zum Bild, das sie hochgeladen haben.
|
|
|
|
:warning: **Hinweis:**
|
|
Achten Sie darauf, dass im Bereich des zweiten **write_files** auch die Einzüge (indendations) nicht stimmen. Das führt dazu, dass das Script nicht sauber durchläuft, falls dies nicht überarbeitet wird.
|
|
|
|
|
|
```php
|
|
#cloud-config
|
|
users:
|
|
- name: <Ergänzen>
|
|
sudo: <Ergänzen>
|
|
groups: <Ergänzen>
|
|
home: <Ergänzen>
|
|
shell: <Ergänzen>
|
|
ssh_authorized_keys:
|
|
- ssh-rsa <Public-Key> <Name_des_Keybesitzers>
|
|
disable_root: <Ergänzen>
|
|
package_update: true
|
|
packages:
|
|
- <Ergänzen>
|
|
- <Ergänzen>
|
|
- <Ergänzen>
|
|
- <Ergänzen>
|
|
- <Ergänzen>
|
|
write_files:
|
|
- content: |
|
|
<?php phpinfo(); ?>
|
|
path: /var/www/html/info.php
|
|
permissions: '0644'
|
|
write_files: # Ab hier wird das gesuchte PHP-File erstellt
|
|
- content: |
|
|
<?php
|
|
$ihrname = "IhrNachname";
|
|
?>
|
|
|
|
<html>
|
|
<head>
|
|
<title><?php echo $ihrname; ?></title>
|
|
</head>
|
|
<body>
|
|
<h1>Passender Titel</h1>
|
|
<br />
|
|
<img src="URL des Bildes auf dem S3-Bucket" alt="Bild aus S3-Bucket">
|
|
</body>
|
|
</html>
|
|
path: <Pfad und Name des PHP-Files, gem. Vorgabe oben>
|
|
permissions: '0644'
|
|
runcmd:
|
|
- sudo systemctl <Ergänzen> <Ergänzen>
|
|
```
|
|
|
|
|
|
##### Schritte
|
|
1. Öffnen Sie die [AWS Management Console](https://aws.amazon.com/console/).
|
|
2. EC2 Instanz benennen (Der Begriff **KN04** soll darin enthalten sein).
|
|
3. Ubuntu AMI (Amazon Machine Image) auswählen.
|
|
4. Instance type und (bestehendes) Key pair auswählen.
|
|
5. Bestehende Security Group auswählen (Port 80 inbound offen).
|
|
6. Cloud-init Script erstellen gem. Vorlage oben (Kernelement dieses Auftrage) und launchen.
|
|
8. Resultat: Browser öffnen und IP oder DNS-Namen ergänzen mit "test.php" (Bild unten).
|
|
|
|
|
|
Endresultat: PHP-Webseite mit Name des Schülers und eingebettetem Bild |
|
|
:-------------------------:|
|
|
![Resultat](./x_res/02_EC2-Instanz_installieren_800.png) |
|
|
|
|
|
|
#### Ziel der Übung
|
|
:bell: **Verständnisvertiefung** für das Deployment von deklarativen Scripts und die gleichzeitige Nutzung von verschiedenen AWS-Services für eine Applikation (in diesem Fall EC2 und S3).
|
|
|
|
|
|
##### Leistungsnachweis
|
|
- [ ] Ihre angepasste Cloud-init Konfiguration als **Datei** im Git-Repository.
|
|
- [ ] Ein Screenshot der Webseite mit eingebettetem Bild aus S3-Bucket (gem. Beispiel oben).
|
|
- [ ] Differenziert und nachvollziehbar im persönlichen Repository dokumentiert.
|
|
- [ ] Fachgespräch mit Coach - _Technisch nachvollziehbare Erklärung, wie das Cloud-init Script funktioniert_.
|
|
|
|
Beachten Sie ausserdem die [allgemeinen Informationen zu den Abgaben](../Abgaben.md).
|
|
|
|
|
|
|
|
|
|
<br>
|
|
|
|
----
|
|
|
|
### C) AWS EC2 Windows 10 Server Instanz mit dynamisch hinzugefügtem EBS Volume (Advanced)
|
|
|
|
#### Ausgangslage:
|
|
Wenn Sie eine EC2-Instanz erstellen, nutzen Sie für das Betriebssystem ein besonderes Volume (SSD-Speicher). Dieser Speicher wird AWS Elastic Block Storage (EBS) genannt, ist sehr schnell aber auch teuer. SSDs (EBS Volumes) werden deshalb eher dort genutzt, wo Daten schnell verarbeitet werden müssen. Für "gewöhnliche" Dateiablagen bietet AWS Storage-Dienste wie **S3** (haben Sie im letzten Auftrag kennengelernt) oder **EFS** (vergleichbar mit einem NAS) an.
|
|
|
|
In diesem Challenge erstellen Sie eine Windows-Server EC2-Instanz mit einem MS Windows Server 2022 Base Image. Anschließend erzeugen Sie ein neues EBS Volume und fügen dieses der Instanz im laufenden Betrieb hinzu. Nachdem sie das eingehängte Volume formatiert haben, können sie dieses als ergänzenden Datenspeicher (Drive D:) verwenden.
|
|
Führen Sie diese Übung in der AWS-Academy im LearnerLab durch.
|
|
|
|
|
|
|
|
#### Anleitung:
|
|
|
|
##### Schritt 1: EC2-Instanz mit Windows 10 Server erstellen
|
|
1. Öffnen Sie die [AWS Management Console](https://aws.amazon.com/console/).
|
|
2. Navigieren Sie zur EC2-Dashboardseite.
|
|
3. Klicken Sie auf "Instanzen starten".
|
|
4. Wählen Sie Windows, AMI (Amazon Machine Image) **Microsoft Windows Server 2022 Base** aus.
|
|
5. Wählen Sie die Instanztyp **t2.micro** (free tier eligible).
|
|
6. Bei **Key pair** Wählen Sie den Namen des früher erstellten Schlüssels (ihr SSH-Key) aus.
|
|
7. Unter **Network settings** wählen Sie eine bereits bestehende Security Group aus - diese muss später noch mit einer inbound-rule für RDP ergänzt werden, damit Sie auf die Windows-Instanz zugreifen können.
|
|
8. Bei **Configure Storage** können die Defaultwerte übernommen werden.
|
|
9. Starten Sie die Instanz mit **Launch instance**.
|
|
|
|
##### Schritt 2: Inbound Rule für RDP-Verbindung zuweisen
|
|
1. Damit Sie später via RDP auf die EC2-Instanz zugreifen können, muss in der ausgewählten Security-Group noch die entsprechende Inbound-Rule für RDP (Port 3389) gesetzt werden.
|
|
|
|
![Schema](./x_res/05_win10-inst_800.png)
|
|
|
|
##### Schritt 3: RDP-Verbindung zur Windows Instanz und Volume checken
|
|
1. Bei der Windows-Instanz auf **Connect** clicken. Sie benötigen für die RDP-Verbindung folgende drei Angaben. Die ersten beiden Angaben werden vorgegeben. Das Passowrd müssen sie sich noch beschaffen.
|
|
- Public DNS Name
|
|
- Username: Administrator (immer gleich)
|
|
- **Password**
|
|
2. Klicken Sie auf **Get password**.
|
|
3. Es erscheint ein Window mit der Aufforderung, Ihren **private key** hochzuladen. Sie haben oben bereits ein Key-pair ausgewählt. Verwenden Sie den dazugehörigen private key (_Name.pem_).
|
|
4. Nachdem der private key hochgeladen wurde, mit **Decrypt password** bestätigen. Nun haben sie alle **drei** Angaben, die sie für RDP benötigen.
|
|
5. Öffnen Sie nun auf ihrem Laptop eine **Remotedesktopverbindung** und geben sie die drei Angaben ein, um eine RDP-Verbindung mit ihrer EC2-Instanz aufzubauen.
|
|
6. Checken Sie auf Windows nun, welche Drives eingebunden sind - öffnen sie dazu **Disk Management** - nur der C-Drive ist vorhanden.
|
|
|
|
##### Schritt 4: Neues EBS Volume erstellen und an Instanz anhängen
|
|
1. Wechseln sie zur AWS Management Console.
|
|
2. Überprüfen Sie zuerst, in welcher AZ Ihre Instanz läuft (das Volume muss in derselben AZ erstellt werden).
|
|
3. Danach navigieren Sie zur EC2-Dashboardseite.
|
|
4. Klicken Sie auf "Volumes" im linken Menü.
|
|
5. Klicken Sie auf "Volume erstellen".
|
|
6. Konfigurieren Sie Größe **20GB** und Availability Zone (muss dieselbe sein wie der EC2-Instanz zugewiesen wurde).
|
|
7. Klicken Sie auf **Volume erstellen**.
|
|
8. Suchen Sie die neu erstellte Volume-ID in der Liste der Volumes.
|
|
9. Markieren Sie das neue Volume und klicken Sie auf **Actions** > **Attach volume**.
|
|
10. Wählen Sie die zuvor erstellte Win10-Instanz aus und bestätigen Sie **Attach volume**
|
|
|
|
|
|
##### Schritt 5: EBS Volume im Betriebssystem einbinden, formatieren und verwenden
|
|
1. Wechseln sie nun wieder zurück zum RDP-Window (Windows10 Server).
|
|
2. Öffnen Sie das **Start**-Menü und suchen Sie "Laufwerksverwaltung" (Englisch; Disk Managemet).
|
|
3. Es ist jetzt eine weitere Disk erkennbar (Unknown / offline).
|
|
4. Klicken Sie mit der rechten Maustaste auf das neue Volume und wählen Sie **Online** und danach **Initialize Disk**.
|
|
5. Erstellen Sie eine einfache Volume-Konfiguration (sie können alles auf Default lassen).
|
|
6. Formatieren Sie das Volume mit einem Dateisystem. Innerhalb der neuen Partition mit rechter Maustaste das Pulldown-Menu öffnen und **New Simple Volume** auswählen.
|
|
7. Öffnen Sie den Windows Explorer, um auf das neue Volume zuzugreifen und Dateien zu speichern.
|
|
8. Erstellen Sie im neuen Volume ein Verzeichnis mit dem Namen **M346_IhrNachname>**.
|
|
|
|
|
|
#### Ziel der Übung
|
|
:bell: **Verständnisaufbau**, dass man **jederzeit** dynamisch weitere EBS Volumes erzeugen und bestehenden Instanzen hinzufügen kann, **ohne** dass diese heruntergefahren werden müssen.
|
|
Früher (bei den monolithischen Systemen) hätte man für dieses Vorgehen eine Downtime benötigt. Man musste den Server runterfahren, um die physikalische SSD anschliessend einzubauen. Bei produktiven Systemen war dies oftmals nur mit Wochenendarbeit zu realisieren.
|
|
|
|
|
|
##### Leistungsnachweis
|
|
- [ ] Sie wissen, wie man einer Security Group eine Inbound Rule hinzufügt (in diesem Fall **RDP**).
|
|
- [ ] Sie sind in der Lage via **RDP** eine Verbindung auf eine EC2-Instanz mit einem laufenden Windows Server Betriebssystem aufzubauen.
|
|
- [ ] Sie können ein EBS-Volume erzeugen und dieses dynamisch einer laufenden EC2 Instanz anhängen.
|
|
- [ ] Sie wissen, wie man ein EBS-Volume auf Windows Server einbindet, formatiert und als Datenablage nutzt.
|
|
- [ ] Differenziert und nachvollziehbar im persönlichen Repository dokumentiert.
|
|
- [ ] Fachgespräch mit Coach.
|
|
|
|
Beachten Sie ausserdem die [allgemeinen Informationen zu den Abgaben](../Abgaben.md).
|
|
|
|
|
|
|
|
:warning: **Hinweis:**
|
|
Dieses Volume wird **nicht** automatisch gelöscht. Sie müssen folgende Schritte durchführen, damit deswegen nach dem Lab **keine** Kosten anfallen:
|
|
1. Instanz **stoppen** oder **terminieren** (AWS Console unter **Instances**)
|
|
2. Volume **detachen** (AWS Console unter **Volumes**)
|
|
3. Volume **löschen** (AWS Console, Action, **Delete volume**)
|
|
|
|
|
|
|
|
|
|
<br>
|
|
|
|
----
|
|
|
|
|
|
|
|
UNTEN --> Ziel der Übung
|
|
Das Ziel dieser Aufgabe ist es, zu verstehen, wie man jederzeit dynamisch weitere EBS Volumes erzeugen und bestehenden Instanzen hinzufügen kann, ohne dass diese heruntergefahren werden müssen.
|
|
Früher (bei den monolithischen Systemen) hätte man für dieses Vorgehen eine Downtime benötigt. Man musste den Server runterfahren, um die physikalische SSD anschliessend einzubauen. Bei produktiven Systemen war dies oftmals nur mit Wochenendarbeit zu realisieren.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
-----------------------
|
|
|
|
TEMP SPÄTER LÖSCHEN
|
|
|
|
Erstellen Sie eine neue Instanz in AWS mit den folgenden Einstellungen:
|
|
- Ubuntu 22.04
|
|
- Bei "Key pair" verwenden Sie ihren **zweiten** Schlüssel.
|
|
- Keine Änderungen bei den restlichen Einstellungen.
|
|
- aber: verwenden Sie die [cloud-init Datei](./x_res/cloud-init.yaml) und ersetzen Sie den Schlüssel mit ihrem **ersten** öffentlich Schlüssel. Beachten Sie das Format `ssh-rsa <ihr-Schlüssel-ohne-zeilenumbrüche> random-name`
|
|
|
|
![Schema](./x_res/04_public-key_800.png)
|
|
|
|
- Sie können ihre Cloud-init Konfiguration einfach in dem Feld "*user data*" in der Sektion "*Advanced details*" reinkopieren.
|
|
|
|
**Hinweis**: In KN02 haben Sie sich per SSH mit der laufenden EC2-Instanz verbunden und dann sämtliche Installationsschritte per Hand (imperativ) ausgeführt. Wenn Sie nun aber ihre YAML-Datei in das Feld kopieren, wird AWS sämtliche Schritte automatisch durchführen und alles ohne Handeingabe installieren.
|
|
|
|
**Hinweis**: Stellen Sie sicher, dass die Zeile `#cloud-config` auch tatsächlich in der YAML-Datei steht, sonst wird der Inhalt nicht korrekt ausgeführt.
|
|
|
|
Sie haben nun aber ihren Public-Key zwei mal verwendet (einmal beim Feld "Key Pair" in der Management Console und einmal im Cloud-init Script).
|
|
Ein Schlüssel wird demzufolge vom anderen Schlüssel überschrieben. Welcher von welchem?
|
|
|
|
Die beiden unten Bilder verdeutlichen nochmals, dass der Public-Key aus dem Cloud-init Script übernommen wurde (links das Cloud-init Script und rechts das authorized_keys File von der EC2-Instanz).
|
|
|
|
Denken Sie nochmals an den Ablauf beim Erstellen der EC2-Instanz. Was wurde **wann** eingetragen? **Was ist genau passiert?**
|
|
|
|
|
|
Cloud-init Script | Eintrag in AWS EC2-Instanz (authorized_keys)
|
|
:-------------------------:|:-------------------------:
|
|
![keypair1](./x_res/05_cloud-init_600.png) | ![keypair2](./x_res/06_cloud-init_600.png)
|
|
|
|
|
|
Zeigen Sie nun, dass Sie **nur mit dem Key aus der Cloud-Init Datei** einloggen können.
|
|
|
|
Rufen Sie nun das cloud-init-log (`/var/log/cloud-init-output.log`) auf und merken Sie sich den Pfad **/var/log/** für zukünftige Aufträge für die Fehlerfindung.
|
|
|
|
|
|
|
|
#### Ziel der Übung
|
|
:bell: **Verständnisaufbau** für das Deployment von deklarativen Scripts und die Nutzung von Public-Keys.
|
|
|
|
|
|
##### Leistungsnachweis
|
|
- [ ] Ihre angepasste Cloud-init Konfiguration als **Datei** im Git-Repository.
|
|
- [ ] Ein Screenshot der Details oder Liste der Instanz, welcher den **verwendeten** Key zeigt.
|
|
- [ ] Screenshot mit dem ssh-Befehl und des Resultats unter Verwendung des **ersten** Schlüssels.
|
|
- [ ] Screenshot mit dem ssh-Befehl und des Resultats unter Verwendung des **zweiten** Schlüssels.
|
|
- [ ] Screenshot mit dem Auszug aus dem Cloud-Init-Log.
|
|
- [ ] Technisch nachvollziehbare Erklärung, weshalb nur einer der beiden Keys funktioniert.
|
|
- [ ] Differenziert und nachvollziehbar im persönlichen Repository dokumentiert.
|
|
- [ ] Fachgespräch mit Coach.
|
|
|
|
Beachten Sie ausserdem die [allgemeinen Informationen zu den Abgaben](../Abgaben.md).
|
|
|
|
|
|
<br>
|
|
|
|
----
|
|
|
|
### C) Template (Beginner)
|
|
|
|
#### Ausgangslage:
|
|
Damit Ihr Coach / Lehrperson ebenfalls auf Ihre Instanz zugreifen kann, ergänzen Sie Ihre cloud-init-Scripts auch mit dessen Public-Key. Fordern Sie diesen an und ergänzen Sie diesen unter ssh_authorized_keys. Dieser Auftrag ist erfüllt, wenn die Lehrperson anschliessend ohne Authentifikation auf Ihre Instanzen zugreifen kann.
|
|
|
|
#### Anleitung
|
|
Erstellen Sie sich ein Cloud-Init Template aufgrund der Datei aus B), welches Sie bei den folgenden Kompetenzen einsetzen.
|
|
|
|
Fügen Sie auch direkt den [öffentlichen Schlüssel für Lehrpersonen](../PublicKey/346.pub) hinzu, so dass die darin eingetragenen Lehrpersonen Zugriff auf Ihre Instanzen kriegen. Es ist gut möglich, dass der Public-Key Ihrer Lehrperson **nicht** auf der Liste ist. In diesem Fall melden Sie sich kurz bei Ihr.
|
|
|
|
#### Ziel der Übung
|
|
:bell: **Verständnisaufbau**, dass mehrere Public Keys (von diversen Benutzern) hinzugefügt werden können<br>
|
|
...ausserdem
|
|
- Zugriff für Coach/Lehrperson auf Ihre Instanzen
|
|
|
|
|
|
##### Leistungsnachweis
|
|
- [ ] Ihr Coach kann auf eine beliebige Instanz von Ihrem Account zugreifen.
|
|
- [ ] Differenziert und nachvollziehbar im persönlichen Repository dokumentiert.
|
|
- [ ] Fachgespräch mit Coach.
|
|
|
|
Beachten Sie ausserdem die [allgemeinen Informationen zu den Abgaben](../Abgaben.md).
|
|
|
|
<br>
|
|
|
|
----
|
|
|
|
### D) Auftrennung von Web- und Datenbankserver (Advanced)
|
|
|
|
#### Ausgangslage:
|
|
Früher dominierten Monolithen als vorherrschende Architektur die IT. Hierbei wurde die gesamte Anwendung als **eine einzige Einheit** entwickelt, getestet und bereitgestellt. Dazu gehörten neben der Hardware auch das Betriebsssystem, Storage- und Datenbankanwendungen. Dabei entstanden oftmals komplexe und untrennbare Abhängigkeiten. Wenn z.B. ein Kernel-Patch installiert wurde, musste das gesamte System heruntergefahren. Das bedeutete oft Wochenendarbeit für die IT-Mitarbeiter und Downtime für die Applikation. Mit dem Aufkommen von komplexen und skalierbaren Anforderungen haben sich deshalb Microservices als Alternative etabliert und inzwischen durchgesetzt. Microservices zerlegen die Anwendung in unabhängige, spezialisierte Dienste, was eine verbesserte Skalierbarkeit, Wartbarkeit und Flexibilität ermöglicht. Diese Verschiebung markiert einen Wandel hin zu agileren und anpassungsfähigeren Ansätzen in der heutigen Softwarelandschaft.
|
|
|
|
#### Anleitung
|
|
In KN02 hatten Sie eine virtuelle Instanz installiert mit Web- und Datenbankserver. Sie haben gesehen, dass viele Befehle ausgeführt werden müssen und dass die gesamte Anwendung schlussendlich auf nur einer Instanz läuft. Wenn Sie nun dieselbe Anwendung nochmals installieren, müssten Sie sämtliche Schritte immer wieder von Hand (imperativ) durchführen. Cloud-init hilft Ihnen die Installation zu vereinfachen/automatisieren. Man spricht dann von der **deklarativen Methode** und von **Infrastructure as Code**. Beide Begriffe werden Sie in ihrer Laufbahn als Plattformentwickler noch des öfteren hören und lesen.
|
|
|
|
**Die drei wichtigsten Vorteile von Cloud-init sind:**
|
|
|
|
1. **Automatisierte Bereitstellung:** Cloud-init ermöglicht die automatische Konfiguration und Initialisierung von virtuellen Maschinen, wodurch die Bereitstellung beschleunigt und vereinfacht wird.
|
|
2. **Skalierbarkeit:** Durch die Anwendung von identischen Konfigurationen auf mehreren Instanzen können Ressourcen leicht skaliert werden, um auf steigende Anforderungen zu reagieren.
|
|
3. **Zentrale Verwaltung und Aktualisierung:** Cloud-init ermöglicht eine zentrale Verwaltung von Konfigurationen und erleichtert die Aktualisierung und Wartung von VM-Instanzen, was Konsistenz und Wartbarkeit fördert.
|
|
|
|
---
|
|
|
|
In der nächsten Teilaufgabe werden wir die Datenbank und den Webserver **voneinander trennen** in zwei Unterschiedliche Instanzen. Für beide Instanzen werden Sie zudem eine Cloud-init Datei (***cloud-init-web.yaml, und cloud-init-db.yaml***) erstellen.
|
|
|
|
Das folgende Schema zeigt Ihnen unsere Zielarchitektur mit den entsprechenden Ports. **Beachten Sie den zusätzlichen Port, den Sie nun ebenfalls öffnen müssen (auf der richtigen Instanz).**
|
|
|
|
![Schema](./x_res/10_Topologie_1200.png)
|
|
|
|
**Aufgaben**:
|
|
|
|
- Lesen Sie das folgende kurz durch bevor Sie beginnen. Erstellen Sie dann **zuerst** den **Datenbank**-Server. Wenn dieser läuft und die Screenshots gemacht wurden, erstellen Sie den Web-Server. **Wichtig:** Der Datenbank-Server muss laufen, bevor Sie den Webserver installieren. Sie brauchen im Script des Webservers (Frontend) die **Interne IP-Adresse** des Datenbank-Servers für die Verbindung zwischen Front- und Backend (Port 3306).
|
|
- Installieren Sie die gleichen **Pakete** wie in KN02 via Cloud-Init. Verteilen Sie die Pakete korrekt auf die beiden Cloud-init Dateien. Dazu müssen Sie überlegen und genau verstehen, welche Befehle für welchen Dienst genutzt werden.
|
|
- In KN02 hatten Sie Dateien via GIT geklont und dann an die Zielorte kopiert. Sie gehen nun ein wenig anders vor. Sie verwenden die **write_files**-Anweisung von Cloud-init, um Dateien zu erstellen. Sie finden in der [Doku zu Cloud-init: Write Files](https://cloudinit.readthedocs.io/en/latest/reference/modules.html#write-files) weitere Informationen. Sie können die Datei-Inhalte vom [letzten Auftrag KN02/C)](../KN02/KN02.md#c-installation-von-web--und-datenbankserver) kopieren.
|
|
- In KN02 hatten Sie verschiedene Befehle ausführen müssen. Verwenden Sie die **runcmd**-Anweisung von Cloud-init, um Befehle auszuführen. Sie müssen natürlich nur noch die Befehle ausführen, die in den vorherigen Punkten nicht abgedeckt sind.
|
|
- Führen Sie den folgenden Befehl noch zusätzlich aus:
|
|
`sudo sed -i 's/127.0.0.1/0.0.0.0/g' /etc/mysql/mariadb.conf.d/50-server.cnf`. Dieser Befehl ändert die Konfigurationsdatei der Datenbank und lässt externe Verbindungen zu. In der Vorlage (cloud-init-db_Vorlage.yaml), ist der Anfang auf Zeile 19 bereits eingetragen).
|
|
- Fügen Sie das Paket *adminer* hinzu. Adminer bietet eine GUI, um Datenbanken zu administrieren. Sie müssen anschliessend die beiden folgenden Befehle ausführen (Die entsprechende Cloud-init-Anweisung kennen Sie bereits):
|
|
1. `sudo a2enconf adminer`. Dies fügt die Konfiguration für das Paket *adminer* der *apache* Config hinzu. In der Vorlage (cloud-init-web_Vorlage.yaml), ist der Anfang auf Zeile 45 bereits eingetragen.
|
|
2. Starten Sie den Apache Service neu.
|
|
|
|
<br>
|
|
|
|
**Templates für die IaC-Files**
|
|
- Als Hilfe dienen Ihnen die beiden IaC-Script-Vorlagen (unten). Sie können diese downloaden und wo nötig ergänzen.
|
|
- Erklären Sie im Script oder in Ihrer Doku **jede einzelne Zeile** (Text nach einem Hashtag **#** wird als Text interpretiert).
|
|
- Achten Sie auch auf die Zeileneinzüge (Indendations). Diese sind in den Vorlagen korrekt - daran müssen Sie nichts ändern. Bedenken Sie aber, dass sie in YAML-Files zu Fehlern führen, wenn sie **nicht** korrekt sind.
|
|
[IaC Vorlage cloud-init-db.yaml](./x_res/cloud-init-db_VORLAGE.yaml) | [IaC Vorlage cloud-init-web.yaml](./x_res/cloud-init-web_VORLAGE.yaml)
|
|
:-------------------------:|:-------------------------:
|
|
![cloud-init-db](./x_res/11_cloud-init-db_600.png) | ![cloud-init-web](./x_res/12_cloud-init-web1_600.png)
|
|
|
|
<br>
|
|
|
|
#### Ziel der Übung
|
|
:bell: **Verständnisaufbau** für das Erstellen und Anwenden von Cloud-init Scripts (IaC)<br>
|
|
...ausserdem
|
|
- Bedeutung der Aufteilung von **Services** auf verschiedene Instanzen und deren Vorteile
|
|
|
|
|
|
##### Leistungsnachweis
|
|
- [ ] Differenziert und nachvollziehbar im persönlichen Repository dokumentiert.
|
|
- [ ] Fachgespräch mit Coach.
|
|
|
|
...sowie folgende Punkte
|
|
|
|
- [ ] **Beweisführung DB Server**
|
|
|
|
1. Verbinden Sie sich mit dem Server (Shell) und zeigen Sie, dass, die Datenbankverbindung mit dem Benutzer *admin* funktioniert. Der Befehl dazu lautet `mysql -u admin -p`. Sie müssen dann anschliessend das Passwort eingeben. Erstellen Sie einen Screenshot, der den Befehl und die CLI von mysql zeigt.
|
|
2. Von ihrem lokalen System zeigen Sie, dass Sie von extern auf den Datenbank Server zugreifen können. Verwenden Sie dazu telnet mit dem Befehl `telnet <IP> 3306`. Erstellen Sie einen Screenshot des Befehls und des Resultats. Sie können den Telnet-Client über die Windows-Features aktivieren. Wenn Sie kryptische Zeichen als Antwort bekommen, funktioniert der Zugriff.
|
|
![Telnet](./x_res/07_telnet_1200.png)
|
|
|
|
3. Fügen Sie die Cloud-Init-Datei im Git-Repository hinzu.
|
|
|
|
- [ ] **Beweisführung Webserver**
|
|
|
|
1. Rufen Sie die Seiten index.html, info.php und db.php auf und erstellen Sie einen Screenshot der URL und des Inhalts.
|
|
2. Rufen Sie Adminer auf (http://ihre-ip/adminer/), verbinden Sie sich mit dem DB-Server und zeigen Sie mit Screenshots, dass die Verbindung funktioniert.
|
|
![Adminer](./x_res/08_Zugriff_1200.png)
|
|
|
|
...danach Zugriff auf die Datenbank
|
|
![Adminer](./x_res/09_Front-back_1200.png)
|
|
|
|
3. Fügen Sie die Cloud-Init-Datei im Git-Repository hinzu.
|
|
|
|
Beachten Sie ausserdem die [allgemeinen Informationen zu den Abgaben](../Abgaben.md).
|
|
|
|
### Häufige Fehlerquellen
|
|
|
|
- Sie vergessen die erste Zeile in der Cloud-init Datei `#cloud-config`. Diese ist notwendig!
|
|
- Einrückungen wurden nicht korrekt erstellt. Das Format können Sie hier überprüfen: <https://www.yamllint.com/>.
|
|
- Sie können auf dem Server die Log-Datei für Fehler durchsuchen: `/var/log/cloud-init-output.log`
|
|
- Das Format des SSH-Schlüssels ist falsch. Korrekt ist: `ssh-key XXXXXXXXXX aws-key`.
|
|
|
|
|
|
<br>
|
|
|
|
---
|
|
|
|
### Quellen
|
|
|
|
- [AWS EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html)
|
|
- [AWS S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)
|
|
|
|
<br>
|
|
|
|
---
|
|
|
|
> [⇧ **Zurück zu KN04**](./README.md)
|
|
|
|
---
|
|
|
|
> [⇧ **Zurück zur Hauptseite**](https://gitlab.com/ser-cal/M346)
|
|
|
|
---
|
|
|