Commit 435963b5 authored by Nane Kratzke's avatar Nane Kratzke
Browse files

Finished

parent adf35dfb
# Lab 09: Content-based Traffic Management
Im vorherigen Lab haben Sie gesehen, wie Sie bestehende Cloud-native Applikationen mittels eines Service Meshs instrumentieren können. Ihnen wurden auch bereit Basis Traffic-Management Fähigkeiten gezeigt.
Im vorherigen Lab haben Sie gesehen, wie Sie bestehende Cloud-native Applikationen mittels eines Service Meshs instrumentieren können, um sich so beispielsweise die Topologie einer Cloud-nativen Applikation automatisiert ableiten zu lassen. Es wurden auch Basis Traffic-Management Fähigkeiten von Service-Meshs behandelt.
In diesem Lab geht es darum, tiefer in dieses Traffic Management einzusteigen. Dies geschieht am Beispiel eines einfachen Space Surveillance Dienstes, der auf Basis des offenen [Open-Notify-Services](http://api.open-notify.org) realisiert ist. *Open-Notify* stellt mittels dreier HTTP-basierter APIs aktuelle Positions-, Überflugs- und Besatzungsdaten der Internationalen Raum Station (ISS) in einem JSON-Format zur Verfügung.
In diesem Lab geht es darum, tiefer in dieses Traffic-Management einzusteigen. Dies geschieht am Beispiel eines einfachen Space Surveillance Dienstes, der auf Basis des offenen [Open-Notify-Services](http://api.open-notify.org) realisiert ist. *Open-Notify* stellt mittels mehrerer HTTP-basierter APIs aktuelle Positions-, Überflugs- und Besatzungsdaten der Internationalen Raum Station (ISS) in einem JSON-Format zur Verfügung.
Der in diesem Lab entwickelte Space-Data-Service bündelt zwei dieser APIs, um in einem Schritt aktuelle Positions- und Besatzungsdaten der ISS laden zu können.
Sie werden an diesem kleinen Fallbeispiel den konzeptionellen Unterschied zwischen
- Quantitativen Routing
- und Content-basiertem Routing
sowie die damit zusammenhängenden Grenzen von Service-Mesh-Technologien kennen lernen.
## Inhaltsverzeichnis
- [Lab 09: Content-based Traffic Management](#lab-09-content-based-traffic-management)
- [Inhaltsverzeichnis](#inhaltsverzeichnis)
- [Vorbereitung](#vorbereitung)
- [Übung 01: Deploy des Space-Data-Service](#übung-01-deploy-des-space-data-service)
- [Übung 02: Instrumentieren des Space- Data-Service](#übung-02-instrumentieren-des-space--data-service)
- [Übung 03: Gewichtetes Routing innerhalb des Space-Data-Service](#übung-03-gewichtetes-routing-innerhalb-des-space-data-service)
- [Übung 04: Context-Based Routing innerhalb des Space-Data-Service](#übung-04-context-based-routing-innerhalb-des-space-data-service)
- [Übung 03: Quantitatives Routing innerhalb des Space-Data-Service](#übung-03-quantitatives-routing-innerhalb-des-space-data-service)
- [Übung 04: Content-Based Routing innerhalb des Space-Data-Service](#übung-04-content-based-routing-innerhalb-des-space-data-service)
- [Übung 05: Shutdown](#übung-05-shutdown)
- [Links](#links)
- [Was Sie mitnehmen sollten?](#was-sie-mitnehmen-sollten)
......@@ -76,9 +83,9 @@ Wir instrumentieren nun den Space-Data-Service wie bereits im vorherigen Lab mit
![Kiali Topologie](kiali-space-topologie.png)
- Vergleichen Sie die Topologie mit der Topologie, die Sie in Übung 01 manuell abgeleitet haben.
## Übung 03: Gewichtetes Routing innerhalb des Space-Data-Service
## Übung 03: Quantitatives Routing innerhalb des Space-Data-Service
Wir wollen nun den
Wir wollen nun den Space-Data-Service mit dem *Istio* Service Mesh instrumentieren (analog zum vorhergehenden Lab).
- Starten Sie nun in Gitlab (`CI/CD -> Pipelines`) den manuellen `space-traffic`-Job der `traffic`-Stage.
- Warten Sie ab, bis der Job komplett durchgelaufen ist.
......@@ -91,9 +98,9 @@ Wir wollen nun den
Nun gut, diese Art des Routings haben wir im vorherigen Lab allerdings auch schon gesehen.
## Übung 04: Context-Based Routing innerhalb des Space-Data-Service
## Übung 04: Content-Based Routing innerhalb des Space-Data-Service
Sie werden aber auch zwei weitere Matching-Regeln in diesem Manifest finden. Diese werten HTTP-Header des HTTP-Protokolls aus und sollen Routing-Entscheidungen anhand dieser Header (also des Kontexts) treffen.
Sie werden aber auch zwei weitere Matching-Regeln in diesem Manifest finden. Diese werten HTTP-Header des HTTP-Protokolls aus und sollen Routing-Entscheidungen anhand dieser Header (also des Inhalts der Anfrage) treffen.
- Eine Regel wertet den `User-Agent`-Header aus (also ob der User mit Firefox, Chrome, Safari, etc. surft). User, die mit Firefox surfen, sollen soll auf die v2-Versionen der Apps geleitet werden, ansonsten gilt die Default Regel (also die 70-20-10 Aufteilung).
- Und eine Regel wertet einen nur für diese Demo definierten `Routing`-Header aus. Ist dieser mit dem Wert `demo` gesetzt, soll der Traffic an die v3-Versionen der Apps gehen, ansonsten gilt die Default Regel (also die 70-20-10 Aufteilung).
......@@ -131,9 +138,16 @@ 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.
- 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.
- Reloaden Sie diese Seite mit dem Firefox-Browser. Sie werden in den `from`-Attributen nun nur `v2`-Apps sehen.
- Reloaden Sie diese Seite nun mit einem anderen Browser ihrer Wahl. Sie werden in den `from`-Attributen nun nicht nur `v2`-Apps sehen. Es werden also tatsächlich unterschiedliche Browser in der Topologie anders geroutet.
- Starten Sie `hey` mit dem `Routing: demo` Header
```bash
hey -c 5 -z 30s -H Routing:demo http://localhost:8888
```
und sehen Sie sich das Resultat auf Kiali an. Alle `hey`-initiierten Requests landen in den `v3`-Apps.
## Übung 05: Shutdown
......@@ -141,4 +155,17 @@ Um Ihren Namespace wieder "freizumachen", navigieren Sie in Gitlab bitte auf `CI
## Links
## Was Sie mitnehmen sollten?
\ No newline at end of file
- Istio [HTTPMatchRequest](https://istio.io/latest/docs/reference/config/networking/virtual-service/#HTTPMatchRequest)
- Tool to [parse User-Agent Headers](https://developers.whatismybrowser.com/useragents/parse/?analyse-my-user-agent=yes#parse-useragent)
- [List of User-Agents](https://github.com/tamimibrahim17/List-of-user-agents)
## Was Sie mitnehmen sollten?
- 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.
- 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.
- 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