Een basisreverse proxyconfiguratie vereist slechts drie beslissingen, en deze gids biedt hulp bij elk: de hostnaam, het pad en de backend. Een HTTP-proxyzoekopdracht kan een forward of reverse proxy betekenen, en hier plan en controleer je een server die je zelf draait. De agent besluit nooit voor jou welke host of welk pad juist is. Hij schrijft wat je vraagt, toont elke wijziging als een diff en rapporteert het echte resultaat van elk commando, zodat je het effect van elke beslissing kunt zien voordat je de volgende neemt. Werk de vier onderstaande stappen in volgorde door en behandel het routingplan als het document dat jij en de agent van het eerste commando tot het laatste verzoek volgen.
Start Segment Route en open de werkmap die je configuratie- en routebestanden bevat. De bestandstools werken in deze map, dus een schone map met alleen de bestanden die voor dit domein relevant zijn, houdt de diffs kort en de zoekresultaten leesbaar. Als je live bestanden op een server staan die je eigendom is, kopieer ze dan eerst naar de map, of kies de SSH-omgeving voor de commando's en houd het plan in de map.
Vraag de agent om routing-plan.txt te schrijven met je routes, je redirects en de statuscode die je voor elk verwacht. Het plan is platte tekst, je kunt het bewerken en het is de lijst waarmee je de echte resultaten aan het eind vergelijkt. Noem één verwachting voor elke route en elke redirect, zodat geen regel zonder controle blijft. Houd het bestand kort en leesbaar.
Keur de diff voor elke regel goed, laat Shell dan je configuratietestcommando uitvoeren voordat je herlaadt. In Ask first-modus pauzeert de agent voor elke wijziging, en de kaart voor de test toont de echte exitcode en de volledige uitvoer. Herlaad nooit voordat de test is geslaagd, en houd de back-up van het vorige bestand aan tot het nieuwe gedrag is bevestigd.
Vraag elk adres op met je request-commando, lees de statuscode en de Location-header, en vergelijk ze met je plan. Als één waarde verschilt, herstel dan de back-up, herlaad en wijzig nog één regel. Herhaal dit totdat elke verwachting in het plan overeenkomt met het resultaat, houd dan het definitieve plan als record van wat de configuratie zou moeten doen.
.3 bestandenroutes.confgeladenrouting-plan.txtopgeslagenyour request commandvastgelegd# 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 planElke regel is één regel of één verwachting. Het plan, dat eerst wordt geschreven, geeft je iets om de echte statuscodes mee te vergelijken na elke wijziging, en een wijziging die een verwachting verstoort, is eenvoudig op te merken. Hosts, paden en services zijn alleen voorbeelden; vervang ze door je eigen en houd het plan naast de configuratie die het beschrijft. Het woord redirect met een code is genoeg voor de agent om te weten wat hij moet schrijven.
Deze self hosting-gids met een reverse proxy-server voor je services begint met het vinden van waar de regels staan. list_dir toont de werkmap, glob somt de bestanden op die lijken op routelijsten, en grep zoekt erin naar de woorden route en redirect. Het resultaat is een korte lijst met bestandsnamen en regelnummers. Er verandert nog niets. Kies het bestand dat de regels voor je eigen domein bevat, open het met read_file en vraag elk adres op met je request-commando om de huidige statuscode vast te leggen. Bekijk de lijst in Plan only-modus als je wilt dat de agent eerst de werkvolgorde voorstelt, en sla de notities op naast je routingplan zodat de eerste statuscodes geregistreerd zijn.
Wijzig één regel tegelijk, omdat een kleine diff eenvoudig te beoordelen is. edit_file leest het bestand, stelt de nieuwe regel voor en toont een diff met de toegevoegde en verwijderde regels. Wanneer er een vraag komt over een subdomein-redirectregel, toont de agent de regel naast de code die hij zou moeten retourneren, en jij beslist. In Ask first-modus wordt niets opgeslagen totdat je accepteert. Auto-run zou direct opslaan, dus gebruik het alleen op bestanden die je kunt herstellen. Houd het oude bestand als back-up, accepteer de diff en ga naar de volgende stap. Wijs de diff af als één regel je verrast, en vraag om een kleinere wijziging.
Een herladen met een kapot bestand kan een werkende site offline halen, dus test eerst. Shell voert je configuratietestcommando uit, en succes wordt beoordeeld aan de hand van de echte exitcode: een slagen code betekent dat het bestand is geparsed, alles anders betekent dat je bij de oude configuratie blijft. De kaart vouwt uit naar de volledige uitvoer, inclusief het regelnummer van een fout. Herstel het met een andere kleine diff. Na een geslaagde test, herlaad, vraag het adres opnieuw op en vergelijk de HTTP-statuscodes van de oude en de nieuwe run. Beoordeel de uitvoer zelf, omdat een geslaagde test alleen zegt dat de syntaxis geldig is en niet dat de route juist is.
Statuscodes zijn gegroepeerd op hun eerste cijfer: 2xx succes, 3xx omleiding, 4xx clientfout, 5xx serverfout. Voor een proxy betekent 502 een ongeldig antwoord van de backend, 503 betekent dat de service niet beschikbaar is, 504 betekent dat de backend te langzaam antwoordde, en 404 betekent niet gevonden. http_get haalt één pagina van je eigen service op, en je request-commando toont het nieuwe adres van een redirect. Als een code verschilt van je plan, herstel dan het back-upbestand, herlaad en test opnieuw. Wijzig dan het plan of de regel en herhaal, één regel per ronde. Een kort routingplan en een back-upbestand zijn alles wat je nodig hebt voor een rollback.
