Landscape Networking

Die Services innerhalb eines Landscapes können uneingeschränkt miteinander kommunizieren, während das Landscape als Ganzes von der Außenwelt isoliert ist. Traffic aus dem Internet oder aus anderen Landscapes gelangt nur über einen einzigen, selbst definierten Einstiegspunkt hinein.

Diese Seite beschreibt die drei Bestandteile dieses Modells:

1. Wie Services innerhalb eines Landscapes miteinander kommunizieren.
2. Wie Traffic von außen in das Landscape gelangt.
3. Wie der Workspace Router eingehenden Traffic auf mehrere Services und externe Ziele verteilt.

Kommunikation zwischen Services innerhalb eines Landscapes

Jeder Service in einem Landscape ist von jedem anderen Service im selben Landscape aus erreichbar. Es ist keine zusätzliche Konfiguration erforderlich.

• Reactive Services werden unter einem festen Hostnamen angesprochen:

  ws-server-<workspace-id>-<reactive-service-name>.workspaces

  Anfragen gehen an die Ports, die für diesen Service konfiguriert wurden. Ein Backend-Service namens api im Workspace 12345, der auf Port 8080 lauscht, ist zum Beispiel erreichbar unter:

  http://ws-server-12345-api.workspaces:8080

  Ports müssen konfiguriert werden

  Ein Service ist nur auf den Ports erreichbar, die in seiner Konfiguration deklariert sind. Siehe Ports konfigurieren.

• Virtual Machines werden unter einem festen Hostnamen angesprochen:

  ws-vm-<workspace-id>-<virtual-machine-name>.workspaces

• Managed Services haben, abhängig vom Managed Service Provider, eigene Hostnamen. Anbieterspezifische Verbindungsdetails sind in der Managed Service Provider Reference zu finden.

Nur intern

Hostnamen für Reactives und Virtual Machines werden nur innerhalb des Landscapes aufgelöst. Sie sind weder über einen Browser noch von einem anderen Landscape oder dem öffentlichen Internet aus erreichbar. Managed Services haben je nach Anbieter unterschiedliche Isolationsstufen.

Eingehender Traffic (Ingress)

Jeder Workspace ist unter seiner Dev-Domain erreichbar. Zusätzlich kann der Workspace über einen Pfad an eine eigene Domain angebunden werden. Die Einrichtung ist unter Eigene Domain verbinden beschrieben.

Der gesamte Traffic, der über die Dev-Domain oder eine eigene Domain eingeht, wird zu einem einzigen Endpunkt innerhalb des Landscapes geleitet. Dieser Endpunkt wird als landscapeGateway bezeichnet. In der Landscape-Konfiguration wird festgelegt, welcher Service und welcher Port als Landscape-Gateway fungieren.

Entsprechende barrierefreie Textbeschreibung

UI

1. Den Landscape Config Editor im Workspace öffnen.
2. Auf das Badge Traffic Routed to klicken, um die Konfiguration zu öffnen.
3. Den gewünschten Service als Landscape-Gateway auswählen und den Port festlegen, der HTTP-Traffic bedient.

Auswahl eines Reactive Service, der als Landscape-Gateway-Service verwendet werden soll.

YAML

run:
  frontend:
    network:
      ports: [3000, 8080]
      landscapeGateway:
        httpPort: 8080
  backend:
    network:
      ports: [3000]

• network.landscapeGateway.httpPort: Der Port, der den gesamten von außen in das Landscape eingehenden Traffic empfängt.

Ein Gateway pro Landscape

Ein Landscape hat höchstens ein Landscape-Gateway. Der als httpPort deklarierte Port muss auch in den Ports des Services deklariert sein.

Ein Landscape mit nur einem Service benötigt nichts weiter. Der Service ist das Gateway und empfängt alle eingehenden Anfragen.

Workspace Router

Sollen mehrere Services unter verschiedenen HTTP-Pfaden von außen erreichbar sein, kann dem Landscape ein Codesphere Workspace Router hinzugefügt und als Landscape-Gateway verwendet werden. Dies ist die empfohlene Konfiguration für Landscapes mit mehreren Services.

Der Workspace Router läuft als zusätzlicher Service im Landscape. Er kann wie ein Reactive oder ein Managed Container skaliert werden, indem ein Plan und eine Replica-Anzahl gewählt werden. Image oder Startbefehle werden dafür nicht konfiguriert. Codesphere baut und betreibt den Router automatisch, basierend auf den definierten Pfaden.

Entsprechende barrierefreie Textbeschreibung

Service Networking

Service Networking bildet einen Pfad auf einen Service und Port innerhalb des Landscapes ab.

UI

1. Einen Codesphere Router-Service zum Landscape hinzufügen:

• Option 1: über das Add-New-Service-Modal Hinzufügen einer Codesphere Router Runtime zum Landscape über das Add-New-Service-Modal.

• Option 2: über das Landscape-Networking-Flyout Hinzufügen einer Codesphere Router Runtime zum Landscape über das Landscape-Networking-Flyout.

2. Unter Service Networking eine neue Route hinzufügen.
3. Den Pfad-Präfix eingeben, zum Beispiel /api.
4. Ziel-Service und Port auswählen. Hinzufügen von Service Networking über den Codesphere Router.

YAML

run:
  cs-router:
    type: router
    plan: 101
    replicaCount: 1
    network:
      isLandscapeGateway: true
      paths:
        - path: /
          service: frontend
          port: 8080
          stripPath: false
        - path: /api
          service: backend
          port: 3000
          stripPath: true

Routing zu benutzerdefinierten Zielen

Routing zu benutzerdefinierten Zielen bildet einen Pfad auf eine beliebige URL ab. Damit lässt sich Traffic an Endpunkte weiterleiten, die keine Services des Landscapes sind, zum Beispiel:

• Services in einem Virtual Kubernetes Cluster
• Managed Services
• Endpunkte außerhalb von Codesphere

UI

1. Einen Codesphere Router-Service zum Landscape hinzufügen oder die Einstellungen des vorhandenen Routers öffnen. (siehe Abschnitt 3.1)
2. Unter Custom Targets eine neue Route hinzufügen.
3. Den Pfad-Präfix eingeben.
4. Die Ziel-URL eingeben. Hinzufügen eines benutzerdefinierten Ziels über den Codesphere Router.

YAML

run:
  cs-router:
    type: router
    plan: 101
    replicaCount: 1
    network:
      isLandscapeGateway: true
      externalTargets:
        - path: /dashboard
          target: http://my-headlamp-x-kube-system-x-k8s.rg-${{ resourceGroup.id }}.svc.cluster.local
          stripPath: false

Pfad entfernen (Strip Path)

Jede Pfadzuordnung unterstützt das Flag stripPath. Ist es gesetzt, wird der übereinstimmende Pfad-Präfix aus der Anfrage entfernt, bevor diese an das Ziel weitergeleitet wird.

stripPath	Eingehende Anfrage	Weiterleitung an Ziel
false	/api/users	/api/users
true	/api/users	/users

stripPath: true setzen, wenn die Anwendung ihre Routen ab dem Root-Pfad bereitstellt. Bei false belassen, wenn die Anwendung den vollständigen Pfad erwartet. Siehe Pfadbasiertes Routing zur Vorbereitung einer Anwendung für einen Unterpfad.

Templates

In der Router-Konfiguration können Templates verwendet werden. Sie werden zur Laufzeit aufgelöst, sodass dieselbe Konfiguration für alle Workspaces funktioniert.

Template	Beschreibung
${{ workspace.id }}	Wird zur Workspace-ID aufgelöst
${{ resourceGroup.id }}	Wird zur Resource-Group-ID aufgelöst

${{ team.id }} funktioniert weiterhin als Alias für ${{ resourceGroup.id }}.

Abwägung bei einem benutzerdefinierten Gateway

Anstelle des Workspace Routers kann auch jeder beliebige eigene Service als Landscape-Gateway festgelegt werden. In diesem Fall übernimmt man das Routing selbst, und Pfadzuordnungen stehen nicht zur Verfügung. Außerdem benötigt der in Codesphere integrierte Request Browser einen Workspace Router, um Traces automatisch erfassen zu können.