Commit 11389122 authored by Nane Kratzke's avatar Nane Kratzke
Browse files

Final fixes

parent 435963b5
......@@ -41,9 +41,8 @@ sowie die damit zusammenhängenden Grenzen von Service-Mesh-Technologien kennen
- **Flags:** Selektieren Sie `Mask Variable`, damit das geheime Token in Log-Dateien maskiert wird.
4. Setzen Sie bitte analog zu Schritt 3 die `KUBECONFIG` Variable in `Einstellungen -> CI/CD -> Variables` auf den Inhalt der Kubeconfig-Datei, die Sie für dieses Modul als Access Credential für den bereitgestellten Kubernetes Cluster erhalten haben (Type: `File`). Hierdurch erhält die Build Pipeline für das Deployment Zugriff auf den Cluster.
5. **Falls noch nicht geschehen:** Installieren Sie **[Lens](https://k8slens.dev)** und ergänzen Sie den bereitgestellten Cluster, den Sie in Schritt 4 auch für die Build-Pipeline eingerichtet haben.
6. **Falls noch nicht geschehen:** Installieren Sie **[Python 3](https://www.python.org/downloads)**.
7. Installieren Sie einen **HTTP Load Generator** wie bspw. **[hey](https://github.com/rakyll/hey)**. *Sie können natürlich mit anderen HTTP Load Generatoren arbeiten. Diese Anleitung nutzt jedoch `hey`. Die genutzten Parameter lassen sich jedoch analog auf andere Tools übertragen.*
8. Installieren Sie **[Firefox](https://www.mozilla.org/de/firefox/new/)**, um Content-basiertes Routing nachvollziehen zu können. Das Deployment dieses Labs detektiert hierzu den Firefox-Browser *(wollen Sie diesen nicht installieren, können Sie die entsprechende Regel natürlich auch für andere Browser abändern)*.
6. Installieren Sie einen **HTTP Load Generator** wie bspw. **[hey](https://github.com/rakyll/hey)**. *Sie können natürlich mit anderen HTTP Load Generatoren arbeiten. Diese Anleitung nutzt jedoch `hey`. Die genutzten Parameter lassen sich jedoch analog auf andere Tools übertragen.*
7. Installieren Sie **[Firefox](https://www.mozilla.org/de/firefox/new/)**, um Content-basiertes Routing nachvollziehen zu können. Das Deployment dieses Labs detektiert hierzu den Firefox-Browser *(wollen Sie diesen nicht installieren, können Sie die entsprechende Regel natürlich auch für andere Browser abändern)*.
## Übung 01: Deploy des Space-Data-Service
......@@ -137,7 +136,7 @@ def load_url(url, headers):
Für das Routing mittels Headern ist es in Service-Meshs also erforderlich, dass die entsprechenden Routing-relevanten HTTP-Header "durchgeschliffen" werden. Für Sie ist dieses "Durchschleifen" bereits vorbereitet. Sie müssen die auskommentierten Zeilen nur wieder einkommentieren.
- Kommentieren Sie diese Zeilen also wieder ein und committen Sie das Resultat in den `master`-Branch.
- Kommentieren Sie diese Zeilen also wieder ein (z.B. in der Web-IDE von Gitlab) und committen Sie das Resultat in den `master`-Branch.
- Warten Sie den Abschluss des Container-Baus in der Pipeline ab (`space-container`-Job der `prepare`-Stage).
- Starten Sie dann in Gitlab (`CI/CD -> Pipelines`) den manuellen `space-traffic`-Job der `traffic`-Stage erneut und warten Sie ab, bis dieser erfolgreich durchgelaufen ist.
- Beenden Sie anschließend die Port-Weiterleitung `8888:80` aus Übung 01-03 mittels `Ctrl-C` im entsprechenden Lens-Terminal und starten Sie diese analog zur Übung 01 neu. Sie sollten nun unter [http://localhost:8888](http://localhost:8888) erneut aktuelle ISS-Daten sehen.
......@@ -161,11 +160,11 @@ Um Ihren Namespace wieder "freizumachen", navigieren Sie in Gitlab bitte auf `CI
## Was Sie mitnehmen sollten?
- Beim quantitativen Routing wird der Inhalt des Requests ignoriert. Der Inhalt eines Requests ist für Routing-Entscheidung unerheblich.
- **Beim quantitativen Routing wird der Inhalt des Requests ignoriert.** Der Inhalt eines Requests ist für Routing-Entscheidung unerheblich.
- Quantitatives Routing innerhalb von Cloud-nativen App-Topologien lässt sich so durch einfache Instrumentierung mit einem Service-Mesh realisieren.
- Beim Content-basierten Routing wird der Inhalt des Requests hingegen ausgewertet und für Routing-Entscheidungen herangezogen.
- **Beim Content-basierten Routing wird der Inhalt des Requests hingegen ausgewertet** und für Routing-Entscheidungen herangezogen.
- Content-basiertes Routing (bspw. auf Basis von HTTP-Headern) innerhalb von Cloud-nativen App-Topologien kann es allerdings erforderlich machen, neben einer Service-Mesh Instrumentierung auch die Aufruflogik einer Applikation anpassen zu müssen (z.B. zum "Durchschleifen" von für das Routing erforderlichen Headern).
- Beim quantitativen Routing ist hingegen meist kein Zugriff auf den Quelltext einer Applikation erforderlich.
- Beim **quantitativen Routing** ist hingegen meist **kein Zugriff auf den Quelltext** einer Applikation erforderlich.
- Content-basiertes Routing ermöglicht es allerdings (im Extremfall) sogar individuelle User mit individuellen Diensten (oder Versionen von Diensten) versorgen zu können.
- Verbaut man Komponenten, die Ihnen nicht als Quelltext zur Verfügung stehen (sondern nur als Container-Image, wie bspw. viele Datenbanken), kann es sein, dass diese Komponenten für Content-basiertes Routing relevante Informationen "schlucken" und entsprechendes Routing unmöglich machen.
- In diesen Fällen sollten solche Komponenten an den Enden von Aufruf-Topologien liegen *(was meist eh der Fall ist, hier finden sich häufig Standard-Komponenten wie Datenbanken und Standard-Komponenten wie Web-Server etc.)*.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment