フォルダを開く
Segment Routeを起動し、設定ファイルとルーティングファイルを含む作業フォルダを開きます。ファイルツールはこのフォルダ内で動作するため、このドメインに関連するファイルのみを含むクリーンなフォルダを使用すると、差分が短くなり、検索結果も読みやすくなります。ライブファイルがあなたが所有するサーバー上にある場合は、まずそれらをフォルダにコピーするか、コマンド用にSSH環境を選択し、計画をフォルダ内に保持してください。
ワークフロー
計画ファイルから確認済みの結果へ：HTTPプロキシルーティング
03
1つのドメインのルーティングを設定する
基本的なリバースプロキシの設定には、3つの判断だけで十分です。このガイドでは、ホスト名、パス、バックエンドの各項目について支援を提供します。HTTPプロキシ検索は、フォワードプロキシまたはリバースプロキシのいずれかを意味する可能性があります。ここでは、あなたが管理するサーバーを計画し、確認します。エージェントは、どのホストやパスが適切かをあなたに代わって決定しません。あなたが指示した内容を書き出し、変更点を差分として表示し、各コマンドの実際の結果を報告します。これにより、次の判断を行う前に、各判断の影響を確認できます。以下の4つのステップを順に実行し、ルーティング計画を、最初のコマンドから最後のリクエストまで、あなたとエージェントが共に従う文書として扱ってください。
計画を書く
エージェントにルーティング計画ファイル（routing-plan.txt）を作成させ、ルーティング、リダイレクト、および各リクエストに対して期待するステータスコードを含めてください。計画はプレーンテキストであり、編集可能で、最終的な実際の結果と比較するためのリストとなります。すべてのルーティングとリダイレクトに対して期待値を1つずつ指定し、チェック対象のルールが漏れないようにしてください。ファイルは短く、読みやすく保ちましょう。
編集とテスト
各ルールの差分を確認し、リロード前にShellで設定テストコマンドを実行させてください。[Ask first]モードでは、エージェントは変更のたびに一時停止し、テストカードには実際の終了コードと完全な出力が表示されます。テストが成功するまでリロードしないでください。また、新しい動作が確認されるまで、前のファイルのバックアップを保持してください。
結果を確認する
リクエストコマンドで各アドレスにアクセスし、ステータスコードとLocationヘッダーを読み取り、それらを計画と比較してください。値が一致しない場合は、バックアップを復元し、リロードしてルールを1つ変更してください。計画内の期待値がすべて結果と一致するまでこれを繰り返し、最終的な計画を、設定が何を意図しているかの記録として保持してください。
プレーンテキストのルーティング計画
自分のドメイン用のルーティング計画ファイル（routing-plan.txt）を作成してください。ルーティング、リダイレクト、および各リクエストに対して期待するステータスコードを含めます。
- list_dir
.3ファイル - read_file
routes.conf読み込み済み - write_file
routing-plan.txt保存済み - Shell
your request command記録済み
次のステップに進む前に承認を待機中拒否承認
routing-plan.txt
# 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各行は1つのルールまたは1つの期待値を表します。最初に作成された計画は、変更のたびに実際のステータスコードと比較するための基準となり、期待値に違反する変更は容易に検出できます。ホスト、パス、サービスは例示であり、それらを実際のものに置き換えてください。計画は、それが記述する設定ファイルの隣に保持してください。コード付きの「redirect」という単語があれば、エージェントは必要な記述を把握できます。
HTTPプロキシ変更の安全な手順
ルールを保持するファイルを見つける
サービスの前にリバースプロキシサーバーを配置したこのセルフホスティングガイドでは、まずルールがどこに保存されているかを確認することから始めます。list_dirは作業フォルダを表示し、globはルーティングリストのように見えるファイルを一覧表示し、grepは「route」や「redirect」という単語でそれらを検索します。結果は、ファイル名と行番号を含む短いリストになります。まだ何も変更されません。自分のドメインのルールを保持するファイルを選択し、read_fileで開き、リクエストコマンドで各アドレスにアクセスして、現在のステータスコードを記録してください。エージェントに作業の順序を提案させたい場合は、[Plan only]モードでリストを確認し、最初のステータスコードが記録されるように、メモをルーティング計画の隣に保存してください。
1つのルールずつ編集する
小さな差分は判断しやすいため、1つのルールずつ変更してください。edit_fileはファイルを読み込み、新しい行を提案し、追加および削除された行を示す差分を表示します。サブドメインのリダイレクトルールに関する質問が発生した場合、エージェントはルールとそれに対応するコードを表示し、あなたが判断します。[Ask first]モードでは、承認されるまで保存されません。[Auto-run]では即座に保存されるため、復元可能なファイルでのみ使用してください。古いファイルはバックアップとして保持し、差分を受け入れて次のステップに進みます。1行が予期しない内容だった場合は差分を拒否し、より小さな変更を依頼してください。
リロード前にテストする
壊れたファイルでのリロードは稼働中のサイトをダウンさせる可能性があるため、まずテストしてください。Shellは設定テストコマンドを実行し、成功は実際の終了コードによって判断されます。合格コードはファイルが正常に解析されたことを意味し、それ以外は古い構成のまま留まることを意味します。カードはエラーの行番号を含む完全な出力まで展開されます。小さな差分でそれを修正してください。テストが合格した後、リロードし、アドレスに再度アクセスして、古い実行と新しい実行のHTTPステータスコードを比較してください。合格テストは構文が有効であることを示すだけで、ルーティングが正しいことを意味するわけではないため、出力は自分で確認してください。
コードを読み取り、ロールバックする
ステータスコードは最初の桁でグループ化されます：2xxは成功、3xxはリダイレクト、4xxはクライアントエラー、5xxはサーバーエラーです。プロキシの場合、502はバックエンドからの無効な応答、503はサービスが利用不可、504はバックエンドの応答が遅すぎた、404は見つからないことを意味します。http_getは自分のサービスの1ページを取得し、リクエストコマンドはリダイレクトの新しいアドレスを表示します。コードが計画と異なる場合は、バックアップファイルを復元し、リロードして再度テストしてください。その後、計画またはルールを変更し、1ラウンドで1つのルールずつ繰り返してください。短いルーティング計画とバックアップファイルがあれば、ロールバックは十分可能です。
