Eine grundlegende Reverse-Proxy-Einrichtung erfordert nur drei Entscheidungen, und diese Anleitung unterstützt Sie bei jeder einzelnen: dem Hostnamen, dem Pfad und dem Backend. Eine HTTP-Proxy-Suche kann einen Forward- oder einen Reverse-Proxy meinen; hier planen und prüfen Sie einen Server, den Sie selbst betreiben. Der Agent trifft nicht die Entscheidung, welcher Host oder Pfad richtig ist. Er schreibt, was Sie anfordern, zeigt jede Änderung als Diff an und meldet das echte Ergebnis jedes Befehls, sodass Sie die Wirkung jeder Entscheidung sehen, bevor Sie zur nächsten übergehen. Bearbeiten Sie die vier Schritte unten in der angegebenen Reihenfolge und behandeln Sie den Routing-Plan als das Dokument, das Sie und der Agent vom ersten Befehl bis zur letzten Anfrage gemeinsam befolgen.
Starten Sie Segment Route und öffnen Sie den Arbeitsordner, der Ihre Konfigurations- und Routendateien enthält. Die Dateiwerkzeuge arbeiten in diesem Ordner, daher halten ein sauberer Ordner mit nur den relevanten Dateien für diese Domain die Diffs kurz und die Suchergebnisse lesbar. Wenn Ihre Live-Dateien auf einem Server liegen, den Sie besitzen, kopieren Sie sie zunächst in den Ordner oder wählen Sie die SSH-Umgebung für die Befehle und halten Sie den Plan im Ordner.
Fordern Sie den Agenten auf, routing-plan.txt mit Ihren Routen, Ihren Weiterleitungen und dem Statuscode zu erstellen, den Sie für jede einzelne erwarten. Der Plan ist Klartext, Sie können ihn bearbeiten, und er ist die Liste, mit der Sie die echten Ergebnisse am Ende vergleichen. Benennen Sie für jede Route und jede Weiterleitung eine Erwartung, damit keine Regel ohne Prüfung bleibt. Halten Sie die Datei kurz und lesbar.
Genehmigen Sie den Diff für jede Regel, lassen Sie Shell dann Ihren Config-Testbefehl ausführen, bevor Sie neu laden. Im Modus „Ask first“ pausiert der Agent vor jeder Änderung, und die Karte für den Test zeigt den echten Exit-Code und die vollständige Ausgabe. Laden Sie nie neu, bevor der Test bestanden ist, und behalten Sie die Sicherung der vorherigen Datei bei, bis das neue Verhalten bestätigt ist.
Fordern Sie jede Adresse mit Ihrem request-Befehl an, lesen Sie den Statuscode und den Location-Header und vergleichen Sie sie mit Ihrem Plan. Weicht ein Wert ab, stellen Sie die Sicherung wieder her, laden Sie neu und ändern Sie eine Regel erneut. Wiederholen Sie dies, bis jede Erwartung im Plan mit dem Ergebnis übereinstimmt, und behalten Sie den finalen Plan als Aufzeichnung dessen bei, was die Konfiguration tun soll.
.3 Dateienroutes.confgeladenrouting-plan.txtgespeichertyour request commandprotokolliert# routing plan for my own domain
# one line per rule, written before any change
route 1: host app, path /api, goes to service api
route 2: host app, path /, goes to service web
route 3: host admin, path /, goes to service admin
redirect 1: old page to new page, code 301
redirect 2: www host to bare host, code 301
redirect 3: http to https, code 301
# status to expect after the change
expect 1: app path /api answers with a success code
expect 2: old page answers 301 and gives the new address
# keep the old configuration file as a backup
# end of routing planJede Zeile ist eine Regel oder eine Erwartung. Der zuerst geschriebene Plan gibt Ihnen etwas zum Vergleichen der echten Statuscodes nach jeder Änderung, und eine Änderung, die eine Erwartung bricht, ist leicht zu erkennen. Hosts, Pfade und Dienste sind nur Beispiele; ersetzen Sie sie durch Ihre eigenen und halten Sie den Plan neben der Konfiguration, die er beschreibt. Das Wort Weiterleitung mit einem Code reicht dem Agenten aus, um zu wissen, was er schreiben soll.
Diese Anleitung zum Self-Hosting mit einem Reverse-Proxy-Server vor Ihren Diensten beginnt damit, herauszufinden, wo die Regeln gespeichert sind. list_dir zeigt den Arbeitsordner, glob listet Dateien, die wie Routenlisten aussehen, und grep durchsucht sie nach den Wörtern route und redirect. Das Ergebnis ist eine kurze Liste mit Dateinamen und Zeilennummern. Noch ändert sich nichts. Wählen Sie die Datei, die die Regeln für Ihre eigene Domain enthält, öffnen Sie sie mit read_file und fordern Sie jede Adresse mit Ihrem request-Befehl an, um den aktuellen Statuscode zu notieren. Überprüfen Sie die Liste im Modus „Plan only“, wenn Sie möchten, dass der Agent zunächst die Arbeitsreihenfolge vorschlägt, und speichern Sie die Notizen neben Ihrem Routing-Plan, sodass die ersten Statuscodes dokumentiert sind.
Ändern Sie immer nur eine Regel, denn ein kleiner Diff ist leicht zu beurteilen. edit_file liest die Datei, schlägt die neue Zeile vor und zeigt einen Diff mit den hinzugefügten und entfernten Zeilen. Wenn eine Frage zu einer Subdomain-Weiterleitungsregel aufkommt, zeigt der Agent die Regel neben dem Code an, den sie zurückgeben soll, und Sie entscheiden. Im Modus „Ask first“ wird nichts gespeichert, bis Sie akzeptieren. Im Auto-run-Modus wird sofort gespeichert, verwenden Sie ihn also nur bei Dateien, die Sie wiederherstellen können. Behalten Sie die alte Datei als Sicherung bei, akzeptieren Sie den Diff und gehen Sie zum nächsten Schritt über. Lehnen Sie den Diff ab, wenn eine Zeile Sie überrascht, und fordern Sie eine kleinere Änderung an.
Ein Neuladen mit einer fehlerhaften Datei kann eine funktionierende Website lahmlegen, also testen Sie zuerst. Shell führt Ihren Config-Testbefehl aus, und der Erfolg wird am echten Exit-Code gemessen: Ein bestanden-Code bedeutet, dass die Datei analysiert wurde, alles andere bedeutet, dass Sie bei der alten Konfiguration bleiben. Die Karte erweitert sich zur vollständigen Ausgabe, einschließlich der Zeilennummer eines Fehlers. Beheben Sie ihn mit einem weiteren kleinen Diff. Nach einem bestandenen Test laden Sie neu, fordern die Adresse erneut an und vergleichen Sie die HTTP-Statuscodes des alten und des neuen Durchlaufs. Überprüfen Sie die Ausgabe selbst, da ein bestandener Test nur besagt, dass die Syntax gültig ist, nicht aber, dass die Route richtig ist.
Statuscodes werden nach ihrer ersten Ziffer gruppiert: 2xx Erfolg, 3xx Weiterleitung, 4xx Client-Fehler, 5xx Server-Fehler. Für einen Proxy bedeutet 502 eine ungültige Antwort vom Backend, 503 bedeutet, dass der Dienst nicht verfügbar ist, 504 bedeutet, dass das Backend zu langsam geantwortet hat, und 404 bedeutet nicht gefunden. http_get ruft eine Seite Ihres eigenen Dienstes ab, und Ihr request-Befehl zeigt die neue Adresse einer Weiterleitung. Weicht ein Code von Ihrem Plan ab, stellen Sie die Sicherungsdatei wieder her, laden Sie neu und testen Sie erneut. Ändern Sie dann den Plan oder die Regel und wiederholen Sie dies, eine Regel pro Runde. Ein kurzer Routing-Plan und eine Sicherungsdatei sind alles, was Sie zum Zurücksetzen benötigen.
