Базове налаштування зворотного проксі потребує лише трьох рішень, і цей посібник допомагає з кожним з них: ім'я хоста, шлях та бекенд. Пошук http proxy може означати як прямий, так і зворотний проксі, і тут ви плануєте та перевіряєте сервер, яким керуєте самостійно. Агент ніколи не приймає рішення за вас щодо того, який хост чи шлях є правильним. Він записує те, що ви просите, показує кожну зміну як diff та звітує про реальний результат кожної команди, щоб ви бачили вплив кожного рішення перед наступним. Пройдіть чотири кроки нижче послідовно та розглядайте план маршрутизації як документ, якому ви та агент слідуєте від першої команди до останнього запиту.
Запустіть Segment Route та відкрийте робочу папку, яка містить ваші конфігураційні файли та файли маршрутів. Інструменти роботи з файлами працюють у цій папці, тому чиста папка, що містить лише файли, важливі для цього домену, забезпечує короткі diff та читабельні результати пошуку. Якщо ваші робочі файли знаходяться на сервері, яким ви володієте, скопіюйте їх у папку спочатку, або виберіть середовище SSH для команд та збережіть план у папці.
Попросіть агента створити routing-plan.txt з вашими маршрутами, перенаправленнями та кодом статусу, який ви очікуєте для кожного. План — це звичайний текст, який ви можете редагувати, і це список, з яким ви порівнюєте реальні результати в кінці. Вкажіть одне очікування для кожного маршруту та кожного перенаправлення, щоб жодне правило не залишилося без перевірки. Зберігайте файл коротким та читабельним.
Підтверджуйте diff для кожного правила, а потім дозволяйте Shell запустити команду тестування конфігурації перед будь-яким перезавантаженням. У режимі Ask first агент робить паузу перед кожною зміною, а картка тесту показує реальний код виходу та повний вивід. Ніколи не перезавантажуйте, доки тест не пройшов, і зберігайте резервну копію попереднього файлу, доки нова поведінка не буде підтверджено.
Зробіть запит до кожної адреси за допомогою вашої команди запиту, прочитайте код статусу та заголовок Location, і порівняйте їх із вашим планом. Якщо одне значення відрізняється, відновіть резервну копію, перезавантажте та змініть одне правило знову. Повторюйте, доки кожне очікування в плані не збігатиметься з результатом, а потім збережіть фінальний план як запис того, що має робити конфігурація.
.3 файлиroutes.confзавантаженоrouting-plan.txtзбереженоyour request commandзаписано# 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 planКожний рядок — це одне правило або одне очікування. Написаний спочатку, план дає вам щось, з чим можна порівняти реальні коди статусу після кожної зміни, і легко помітити зміну, яка порушує очікування. Хости, шляхи та служби є прикладами; замініть їх на свої власні та тримайте план поруч із конфігурацією, яку він описує. Слово redirect із кодом достатньо, щоб агент знав, що писати.
Цей посібник з самостійного хостингу з сервером зворотного проксі перед вашими службами починається з пошуку того, де живуть правила. list_dir показує робочу папку, glob перелічує файли, які схожі на списки маршрутів, а grep шукає в них слова route та redirect. Результат — короткий список з іменами файлів та номерами рядків. Нічого ще не змінюється. Виберіть файл, що містить правила для вашого власного домену, відкрийте його за допомогою read_file та зробіть запит до кожної адреси за допомогою вашої команди запиту, щоб записати поточний код статусу. Перегляньте список у режимі Plan only, якщо хочете, щоб агент запропонував порядок роботи спочатку, і збережіть нотатки поруч із вашим планом маршрутизації, щоб перші коди статусу були зафіксовані.
Змінюйте одне правило за раз, тому що невеликий diff легко оцінити. edit_file читає файл, пропонує новий рядок та показує diff із доданими та видаленими рядками. Коли виникає питання щодо правила перенаправлення піддомену, агент показує правило поруч із кодом, який воно має повернути, і ви приймаєте рішення. У режимі Ask first нічого не зберігається, доки ви не приймете. Auto-run збереже одразу, тому використовуйте його лише для файлів, які можна відновити. Зберігайте старий файл як резервну копію, прийміть diff та переходьте до наступного кроку. Відхиліть diff, якщо одна рядка здивує вас, і попросіть меншу зміну.
Перезавантаження з пошкодженим файлом може зупинити роботу робочого сайту, тому спочатку протестуйте. Shell запускає вашу команду тестування конфігурації, а успіх оцінюється за реальним кодом виходу: код, що пройшов, означає, що файл розпарсено, будь-який інший означає, що ви залишаєтеся на старій конфігурації. Картка розгортається до повного виводу, включаючи номер рядка помилки. Виправте її іншим невеликим diff. Після успішного тесту перезавантажте, зробіть запит до адреси знову та порівняйте коди статусу http старого та нового запуску. Перегляньте вивід самостійно, оскільки успішний тест говорить лише про те, що синтаксис дійсний, а не про те, що маршрут правильний.
Коди статусу групуються за першою цифрою: 2xx успіх, 3xx перенаправлення, 4xx помилка клієнта, 5xx помилка сервера. Для проксі 502 означає недійсну відповідь від бекенду, 503 означає, що служба недоступна, 504 означає, що бекенд відповів занадто повільно, а 404 означає не знайдено. http_get завантажує одну сторінку вашої власної служби, а ваша команда запиту показує нову адресу перенаправлення. Якщо код відрізняється від вашого плану, відновіть файл резервної копії, перезавантажте та протестуйте знову. Потім змініть план або правило та повторіть, одне правило за раунд. Короткий план маршрутизації та файл резервної копії — це все, що потрібно для відкату.
