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

Header Durchschleifen

parent b8af35b4
......@@ -11,9 +11,10 @@ Der in diesem Lab entwickelte Space-Data-Service bündelt zwei dieser APIs, um i
- [Inhaltsverzeichnis](#inhaltsverzeichnis)
- [Vorbereitung](#vorbereitung)
- [Übung 01: Deploy des Space-Data-Service](#übung-01-deploy-des-space-data-service)
- [Übung 02: Instrumentieren des Space Surveillance Dienstes](#übung-02-instrumentieren-des-space-surveillance-dienstes)
- [Übung 03: Content-basiertes Routing innerhalb des Space-Data-Service](#übung-03-content-basiertes-routing-innerhalb-des-space-data-service)
- [Übung 04: Shutdown](#übung-04-shutdown)
- [Ü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 05: Shutdown](#übung-05-shutdown)
- [Links](#links)
- [Was Sie mitnehmen sollten?](#was-sie-mitnehmen-sollten)
......@@ -34,7 +35,7 @@ Der in diesem Lab entwickelte Space-Data-Service bündelt zwei dieser APIs, um i
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. **[salvo](https://github.com/tarekziade/salvo)** mittels `pip install salvo` oder `python3 -m install salvo` (je nachdem wie Ihre Python-Umgebung aufgesetzt ist). *Sie können natürlich mit anderen HTTP Load Generatoren arbeiten. Diese Anleitung nutzt jedoch `salvo`. Die genutzten Parameter lassen sich jedoch analog auf andere Tools übertragen.*
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)*.
## Übung 01: Deploy des Space-Data-Service
......@@ -55,7 +56,9 @@ In diesem Schritt wird ein kleiner Open Notify aggrgierender Space-Data-Service
- `space/service.py` (Python-Implementierung des Space-Data-Services)
- `.gitlab-ci.yaml` (`space-services`-Job der `deploy`-Stage)
## Übung 02: Instrumentieren des Space Surveillance Dienstes
## Übung 02: Instrumentieren des Space- Data-Service
Wir instrumentieren nun den Space-Data-Service wie bereits im vorherigen Lab mittels *Istio*. Vollziehen Sie hierzu gerne den `space-services`-Job in der `deploy`-Stage der Build-Pipeline nach.
- Starten Sie nun in Gitlab (`CI/CD -> Pipelines`) den manuellen `instrumented-services`-Job der `instrument`-Stage.
- Leiten Sie nun den Port der Kiali-Oberfläche in einem neuen Lens-Terminal an Ihr lokales System weiter:
......@@ -65,19 +68,76 @@ In diesem Schritt wird ein kleiner Open Notify aggrgierender Space-Data-Service
- Navigieren Sie anschließend zur Kiali Oberfläche unter [http://localhost:20001](http://localhost:20001) und öffnen Sie die Applikation in Ihrem Namespace.
- Beenden Sie die Port-Weiterleitung `8888:80` aus Übung 01 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.
- Geben Sie mittels `salvo` für ca. 30 Sekunden (`-d 30`) etwas Traffic ins System.
- Geben Sie mittels `hey` für ca. 30 Sekunden (`-z 30s`) von 5 Nutzern (`-c 10`) etwas Traffic ins System.
```bash
salvo -d 30 http://localhost:8888
hey -c 5 -z 30s http://localhost:8888
```
- In Kiali (`Graph -> Versioned App Graph + Requests Percentage`) sollten Sie nun die Topologie sehen. Alle Requests sollten in etwa gleich über alle Services geroutet werden.
![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
Wir wollen nun den
- 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.
- Beenden Sie anschließend die Port-Weiterleitung `8888:80` aus Übung 02 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.
- Geben Sie nun erneut mittels `hey` für ca. 30 Sekunden (`-z 30s`) von 5 Nutzern (`-c 10`) etwas Traffic ins System.
```bash
hey -c 5 -z 30s http://localhost:8888
```
- In Kiali (`Graph -> Versioned App Graph + Requests Percentage`) sollten Sie nun die Topologie sehen. Alle Requests sind nun in etwa 70-20-10 über die v1, v2, v3 Versionen der `astros`- und `position`-Services geroutet werden. Vergleichen Sie hierzu gerne das `deploy/space-istio.yaml`-Manifest. Sie werden hier die entsprechenden Gewichtungen finden.
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
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.
- 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).
Probieren Sie dies gerne einmal mit dem Firefox-Browser aus.
- Navigieren Sie zu [https://localhost:8888](https://localhost:8888).
- In den `from`-Attributen sollten nur `v2`-Apps auftauchen.
- Stimmt das aber?
- Probieren Sie es nun mit `hey` aus, in dem Sie den `Routing`-Header setzen.
```bash
hey -c 5 -z 30s -H Routing:demo http://localhost:8888
```
- Inspezieren Sie den Traffic nun mit Kiali. Sehen Sie hier einen Unterschied in der Request-Verteilung zur Übung 04?
Die Antwort ist in beiden Fällen: Nein! Header-Informationen werden offenbar ignoriert. Woran liegt das?
Das Problem hier ist, dass die Applikationen untereinander zwar mittels HTTP-Requests kommunizieren, jedoch der Request mit den Header nur im "Eingang" ins Netz ausgewertet wird. Anschließend setzen die Applikationen eigene HTTP-Requests ab (hier mittels des Python `requests`-Modul). Dabei werden jedoch eigene Header gesetzt. Will man HTTP-Header zum Routing auswerten, kann es also erforderlich sein, dass man an das Innere von Applikationen heran muss.
Sehen wir uns die `space/default.py`-Datei an und hier die die `load_url()`-Funktion. Diese ist für das Laden von HTTP-Ressourcen innerhalb der Applikations-Topologie verantwortlich.
Diese sollte bei Ihnen in etwa so aussehen:
```Python
def load_url(url, headers):
print(f"Got these headers {dict(headers)}")
h = {}
# h = {
# "User-Agent": headers['User-Agent'],
# "Routing": headers.get('Routing', 'no')
# }
return json.loads(requests.get(url, headers=h, allow_redirects=True).content)
```
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.
- 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.
-
## Übung 03: Content-basiertes Routing innerhalb des Space-Data-Service
## Übung 04: Shutdown
## Übung 05: Shutdown
Um Ihren Namespace wieder "freizumachen", navigieren Sie in Gitlab bitte auf `CI/CD -> Pipelines` und triggern Sie manuell den `shutdown` Job in der `teardown` Stage.
Um Ihren Namespace wieder "freizumachen", navigieren Sie in Gitlab bitte auf `CI/CD -> Pipelines` und triggern Sie manuell den `shutdown`-Job in der `teardown`-Stage.
## Links
......
......@@ -33,7 +33,7 @@ spec:
subset: v2
- match:
- headers:
salvo:
routing:
exact: demo
route:
- destination:
......
......@@ -26,10 +26,10 @@ def index():
def load_url(url, headers):
print(f"Got these headers {dict(headers)}")
h = {}
h = {
"User-Agent": headers['User-Agent'],
"salvo": headers.get('salvo', 'no')
}
# h = {
# "User-Agent": headers['User-Agent'],
# "Routing": headers.get('Routing', 'no')
# }
return json.loads(requests.get(url, headers=h, allow_redirects=True).content)
@app.route('/data')
......
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