Podstawowa konfiguracja reverse proxy wymaga tylko trzech decyzji, a ten przewodnik pomaga w każdej z nich: nazwa hosta, ścieżka i backend. Proxy HTTP może być forward lub reverse, a tutaj planujesz i weryfikujesz serwer, który uruchamiasz samodzielnie. Agent nigdy nie decyduje za Ciebie, który host lub ścieżka są właściwe. Zapisuje to, o co poprosisz, pokazuje każdą zmianę jako diff i raportuje rzeczywisty wynik każdego polecenia, więc możesz zobaczyć wpływ każdej decyzji przed kolejną. Wykonaj cztery poniższe kroki w kolejności i traktuj plan tras jako dokument, który Ty i agent wykonujecie od pierwszego polecenia do ostatniego żądania.
Uruchom Segment Route i otwórz folder roboczy zawierający konfigurację i pliki tras. Narzędzia do pracy na plikach działają w tym folderze, więc czysty folder z plikami istotnymi dla tej domeny sprawia, że diffy są krótkie, a wyniki wyszukiwania czytelne. Jeśli Twoje aktywne pliki znajdują się na serwerze, którym dysponujesz, skopiuj je do folderu najpierw, lub wybierz środowisko SSH dla poleceń i zachowaj plan w folderze.
Poproś agenta o napisanie routing-plan.txt z Twoimi trasami, przekierowaniami i kodem statusu, którego oczekujesz dla każdej z nich. Plan to zwykły tekst, możesz go edytować, a na końcu porównujesz z nim rzeczywiste wyniki. Nazwij jedno oczekiwanie dla każdej trasy i każdego przekierowania, aby żadna reguła nie została bez sprawdzenia. Zachowaj plik krótkim i czytelnym.
Zatwierdź diff dla każdej reguły, a następnie pozwól Shell uruchomić polecenie testu konfiguracji przed jakimkolwiek przeładowaniem. W trybie Ask first agent pauzuje przed każdą zmianą, a karta testu pokazuje rzeczywisty kod wyjścia i pełne wyjście. Nigdy nie przeładowuj, dopóki test nie przejdzie pomyślnie, i zachowaj kopię zapasową poprzedniego pliku, dopóki nowe zachowanie nie zostanie potwierdzone.
Wyślij żądanie do każdego adresu za pomocą polecenia request, odczytaj kod statusu i nagłówek Location, i porównaj je z planem. Jeśli jedna wartość różni się, przywróć kopię zapasową, przeładuj i zmień jedną regułę ponownie. Powtarzaj, aż każde oczekiwanie w planie będzie pasować do wyniku, a następnie zachowaj końcowy plan jako zapis tego, co konfiguracja powinna robić.
.3 plikiroutes.confzaładowanorouting-plan.txtzapisanoyour request commandzarejestrowano# 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 planKażda linia to jedna reguła lub jedno oczekiwanie. Napisany najpierw, plan daje Ci coś, z czym możesz porównać rzeczywiste kody statusu po każdej zmianie, a zmianę, która narusza oczekiwanie, łatwo zauważyć. Hosty, ścieżki i usługi to tylko przykłady; zastąp je swoimi i trzymaj plan obok konfiguracji, którą opisuje. Słowo redirect z kodem wystarczy agentowi, aby wiedzieć, co napisać.
Ten przewodnik po self hosting z reverse proxy przed Twoimi usługami zaczyna się od znalezienia, gdzie żyją reguły. list_dir pokazuje folder roboczy, glob wylicza pliki, które wyglądają na listy tras, a grep wyszukuje w nich słowa route i redirect. Wynikiem jest krótka lista z nazwami plików i numerami linii. Nic się jeszcze nie zmienia. Wybierz plik, który zawiera reguły dla Twojej własnej domeny, otwórz go za pomocą read_file i wyślij żądanie do każdego adresu za pomocą polecenia request, aby zapisać obecny kod statusu. Przeglądaj listę w trybie Plan only, jeśli chcesz, aby agent zaproponował kolejność pracy najpierw, i zapisz notatki obok swojego planu tras, aby pierwsze kody statusu były w rejestrze.
Zmień jedną regułę na raz, ponieważ mały diff jest łatwy do oceny. edit_file czyta plik, proponuje nową linię i pokazuje diff z dodanymi i usuniętymi liniami. Gdy pojawia się pytanie o regułę przekierowania subdomeny, agent pokazuje regułę obok kodu, który powinna zwrócić, a Ty decydujesz. W trybie Ask first nic nie jest zapisywane, dopóki nie zaakceptujesz. Auto-run zapisze natychmiast, więc używaj go tylko na plikach, które można przywrócić. Zachowaj stary plik jako kopię zapasową, zaakceptuj diff i przejdź do następnego kroku. Odrzuć diff, jeśli jedna linia Cię zaskoczy, i poproś o mniejszą zmianę.
Przeładowanie z uszkodzonym plikiem może wyłączyć działającą stronę, więc przetestuj najpierw. Shell uruchamia Twoje polecenie testu konfiguracji, a sukces jest oceniany przez rzeczywisty kod wyjścia: przechodzący kod oznacza, że plik został przeanalizowany, cokolwiek innego oznacza, że zostajesz przy starej konfiguracji. Karta rozszerza się do pełnego wyjścia, w tym numeru linii błędu. Popraw go kolejnym małym diff. Po pomyślnym teście, przeładuj, wyślij żądanie do adresu ponownie i porównaj kody statusu http starego i nowego uruchomienia. Przeglądaj wyjście samodzielnie, ponieważ przechodzący test mówi tylko, że składnia jest poprawna, a nie, że trasa jest właściwa.
Kody statusu są pogrupowane według pierwszej cyfry: 2xx sukces, 3xx przekierowanie, 4xx błąd klienta, 5xx błąd serwera. Dla proxy, 502 oznacza nieprawidłową odpowiedź od backendu, 503 oznacza, że usługa jest niedostępna, 504 oznacza, że backend odpowiedział zbyt wolno, a 404 oznacza nie znaleziono. http_get pobiera jedną stronę Twojej własnej usługi, a Twoje polecenie request pokazuje nowy adres przekierowania. Jeśli kod różni się od Twojego planu, przywróć plik kopii zapasowej, przeładuj i przetestuj ponownie. Następnie zmień plan lub regułę i powtórz, jedną regułę na rundę. Krótki plan tras i plik kopii zapasowej to wszystko, czego potrzebujesz do cofnięcia się.
