Das Wichtigste zuerst: Was ist die Randschicht und warum brauchen wir sie? Die Edge-Schicht sorgt dafür, dass eine Anfrage, die von Ihrem Browser an eine auf Upsun gehostete Website gesendet wird, tatsächlich die richtige Website erreicht und die Antwort zurückgesendet wird. Sie stellt auch sicher, dass Sie sich auf dem richtigen Server befinden, wenn Sie upsun ssh in Ihr Terminal eingeben, und sorgt dafür, dass Anfragen genau dorthin geschickt werden, wo sie hingehören.
Aber wie genau sieht das Leben mit Upsun aus? Wie funktionieren die Anfragen? Und was sind die wichtigsten Dinge, die Sie über die Funktionsweise der Edge-Schicht wissen sollten?
Grundlegende Konzepte von Upsun
Bevor wir eintauchen, ist es nützlich, einige wichtige Teile des Puzzles zu verstehen, das wir Upsun nennen. Insbesondere sollten wir uns über die Hierarchie der Komponenten im Klaren sein, die Upsun verwaltet.
Die umfassendste Komponente ist die Region. Eine Region bezieht sich auf eine Cloud-Region von einem unserer zugrunde liegenden Cloud-Anbieter, insbesondere eine Virtual Private Cloud (VPC), die eine einzelne Upsun-Region darstellt. Eine Region verwaltet Hosts, d. h. virtuelle Maschinen (VMs), die vom Cloud-Anbieter der Region bereitgestellt werden. Es gibt verschiedene Arten von Hosts wie Gateways, Grid-Hosts und Koordinatoren, und ein einzelner Host kann viele Cluster enthalten, wobei ein Cluster mehrere Hosts umfassen kann. Ein Cluster ist eine logische Gruppierung von einigen zusammenhängenden Diensten.
A Dienst ist eine Abstraktion, die einen Dienst darstellt, den wir verwalten. Dabei kann es sich um die Datenbank (DB), den Cache oder die Anwendung des Kunden selbst handeln. Intern läuft ein Dienst in Containern. Ein Container ist wie eine leichtgewichtige Mini-VM, und wir verwalten eine Menge Container - ein einziger Host kann eine Menge Container haben! Jeder Dienst lässt sich entweder einem einzelnen oder mehreren Containern zuordnen, wenn er im Hochverfügbarkeitsmodus läuft.
Die Problemstellung
Jetzt kennen wir das Minimum, um unsere Problemstellung weniger vage zu formulieren: Wie nehmen wir eine Anfrage an eine auf Upsun gehostete Site entgegen, leiten sie an genau den Container weiter, der den Server für diese Site hat, und übermitteln die Antwort des Servers zurück an den Benutzer?
Der erste Schritt besteht darin, dass die Anfrage die richtige Upsun-Region erreicht. Dies wird erreicht, indem der Kunde einen DNS-Eintrag hinzufügt (vom Typ CNAME/ALIAS, falls Sie daran interessiert sind), der besagt: "Meine benutzerdefinierte Domain wird zur öffentlichen IP-Adresse dieser Upsun-Region aufgelöst." Dadurch sendet der Browser des Nutzers, der die Website aufruft, die Anfrage an die Upsun-Region, die die Website hostet.
Von diesem Punkt an übernimmt unser Edge-Layer die Kontrolle - Stichwort dramatische Musik.
Rückbau der Edge-Schichten
Die meisten unserer Hosts (d. h. die virtuellen Maschinen, die eine Upsun Edge Layer-Region bilden) haben nicht einmal eine öffentliche IP. Dies gilt auch für die Hosts, die die Server für die auf Upsun gehosteten Websites beherbergen. Die Hosts, die eine öffentliche IP haben, sind die Hosts am Rand. Jede Anfrage, die an die öffentliche IP einer Region gerichtet ist, trifft dann natürlich auf den Edge.
Erinnern wir uns, dass ein Edge-Host nur eine VM ist, die von einem Cloud-Anbieter bereitgestellt wird. Erinnern wir uns auch daran, dass ein Host Cluster enthalten kann. Vielleicht verlieren Sie jetzt die Geduld, weil wir Schicht um Schicht abtragen und nichts Wertvolles finden. Aber bleiben Sie dran, wir versprechen Ihnen, dass die nächste Edge-Schicht interessant sein wird!
Edge-Proxy
Die offizielle Beschreibung ist ein bisschen langatmig: Edge ist ein dynamischer, transparenter Multiprotokoll-Proxy.
Hier ist die Aufschlüsselung:
Dynamisch: Nuntius kann Änderungen abrufen und seine Konfiguration aktualisieren, ohne dass ein manuelles Eingreifen erforderlich ist.
Transparent: Die Welt braucht nicht zu wissen, was Nuntius ist oder wie es funktioniert. Sie senden einfach eine Anfrage an nuntius und erhalten die entsprechende Antwort, als ob der App-Server selbst direkt auf Sie antworten würde.
Mehrere Protokolle: Nuntius ist in der Lage, mit HTTP (v1.1 und 2), HTTPS und sogar SSH zu arbeiten!
Proxy: Das ist das Wichtigste: Nuntius selbst kann keine Anfragen bearbeiten, die in seine Richtung geschickt werden. Stattdessen leitet er sie an die richtige Stelle weiter, wartet auf die Antwort der richtigen Stelle und leitet diese Antwort an Sie zurück.
Mit anderen Worten: Der Edge-Proxy ist die erste Komponente, die etwas mit der Anfrage macht. Das bedeutet, dass er eine Reihe wichtiger Aufgaben hat:
Er fungiert als Proxy für Kundenprojekte
Funktion als Web Application Firewall
Als Proxy für die Upsun-API fungieren
Edge Proxy: Den Weg finden
In diesem Artikel konzentrieren wir uns auf die erste Rolle: ein Proxy, der eine Anfrage an die richtige Anwendung weiterleitet.
Jeder Container in der Region hat eine IP, die in dem (Overlay-)Netzwerk, in dem sich alle Container befinden, einzigartig ist. Das Ziel ist, dass der Proxy die Anfrage an den richtigen Container weiterleitet, in dem sich der App-Server des Projekts befindet. Damit dies funktioniert, verwaltet der Proxy eine Zuordnung von URLs zu Container-IPs. Diese Informationen sind dem Proxy nicht bekannt, also muss er etwas anderes fragen: die Container-Orchestrierung oder den verteilten Datenspeicher. Der Container-Orchestrator stellt Informationen über Routen zu Projekten, ACLs usw. über eine RPC zur Verfügung. Der Proxy nutzt dies, um zu wissen, a) ob der Benutzer, der diese Anfrage stellt, dazu berechtigt ist, und b) welcher Container diese Anfrage bedienen kann.
Die Container-IP, die der Proxy herausgefunden hat, befindet sich auf einer anderen VM. Und um die Dinge noch weiter zu verkomplizieren, können wir eine beliebige Anzahl von Container-Hosts in einer Region haben.
Mit anderen Worten: Wenn der Proxy eine Anfrage an die Container-IP weiterleitet, muss etwas herausfinden, auf welcher VM sich der besagte Container befindet. Dieses Etwas ist der ARP-Daemon. Das ist etwas irreführend, denn das ARP-Protokoll wird verwendet, um eine IP-Adresse in eine physische (d. h. MAC-) Adresse umzuwandeln. In unserem Fall findet der ARP-Daemon anhand der Container-IP heraus, auf welchem Grid-Host ein Container lebt, d.h. er wandelt die Container-IP in eine Host-IP um.
Tatsächlich gehören die Container-IPs nicht einmal zum selben Netzwerk wie die Hosts. Sie gehören vielmehr zu einem Overlay-Netzwerk. Für den Moment ist es wichtig zu wissen, dass der ARP-Dämon dafür sorgt, dass eine Anfrage, die an eine bestimmte Container-IP gerichtet ist, dort ankommt.
Die Pforten der Umgebung: der Router
Erinnern Sie sich, als ich Ihnen sagte, dass der Proxy die Container-IP des App-Containers herausfindet, damit er Anfragen an ihn weiterleiten kann? Nun, ich habe gelogen. Die Anfragen werden tatsächlich an einen speziellen Dienst namens Router weitergeleitet. Der Router-Dienst enthält einen einzelnen Router-Container, der der Gatekeeper für die Umgebung ist - ja, wir haben einen Router pro Umgebung.
Auf dem Router-Container läuft ein Caching-Reverse-Proxy. Ein Reverse-Proxy ist etwas, das vor Ihrem Server sitzt und Anfragen an ihn weiterleitet und Antworten von ihm erhält, während er gleichzeitig als Cache oder Lastausgleich fungiert.
Dies ist der Dienst, den Sie über die Datei routes.yaml in Ihrem Upsun-Projekt konfigurieren können. Auf diese Weise haben Sie einen Router pro Umgebung - wenn sich Ihre routers.yaml zwischen zwei Umgebungen unterscheidet, werden diese Umgebungen unterschiedlich konfigurierte Router haben.
Der Router sendet die Anfrage schließlich an den Anwendungscontainer, d. h. an den Server, der die Site tatsächlich bedient.
An diesem Punkt hat die Anfrage den Server endlich erreicht!
Alle Verbindungen zwischen den verschiedenen Knoten auf dem Weg einer Anfrage sind TCP-Verbindungen. Das Gute an TCP ist, dass die von einer Anfrage verwendete Verbindung offen gehalten werden kann. Das bedeutet, dass die Antwort des Servers denselben Weg zurück zum Host am Rande und in die Welt nehmen kann. Auf diese Weise erreicht die Antwort auf eine Anfrage den Benutzer.
Container-zu-Welt-Vernetzung und andere Dinge
Es gibt einen wichtigen Teil der Edge-Schicht, der in diesem Beitrag nicht behandelt wurde - wie kann man den App-Container mit dem externen Internet interagieren lassen?
Das ist viel schwieriger, als Sie vielleicht erwarten. Wir haben separate Routen für den ausgehenden Datenverkehr über die Edge-Hosts (manchmal nur für den ausgehenden Datenverkehr), die uns eine feinkörnige Kontrolle über den ausgehenden Datenverkehr aus unseren Regionen ermöglichen.
Wir sehen uns drüben!
Danksagungen
Vielen Dank an unsere Experten, die zu diesem Beitrag beigetragen haben: Ricardo Kirkner, Pilar Gomez, Colin Strickland, Krishna Kashyap, und Eder Leão Moosmann.
Ihr größtes Werk
steht vor der Tür
