最初のプロキシを設定する

リポジトリに含まれる config/bearust.example.toml は完全な出発点です。api.example.com へのトラフィッ クを api アップストリームプールにルーティングします。クローン不要のクイックスタートに従った場合は、 自分で書いた bearust.toml に同じブロックを追加してください。

[server]
bind = "0.0.0.0:8080"
control_bind = "0.0.0.0:8081"

[health]

[[upstream_pools]]
name = "api"
algorithm = "round_robin"

[[upstream_pools.backends]]
address = "127.0.0.1:9001"
health_check = "http"
health_path = "/health"

[[upstream_pools.backends]]
address = "127.0.0.1:9002"
health_check = "tcp"

[[routes]]
name = "api-v1"
host = "api.example.com"
path_prefix = "/v1"
upstream_pool = "api"

control_bind = "0.0.0.0:8081" はコンテナネットワーク内からコントロールサービスに到達できるようにしま す。同梱の Docker Compose ファイルでは、ホストへの公開は引き続き 127.0.0.1:8081 に限定されており、そ の Compose のマッピングが安全境界となります。信頼できないホストインターフェースでこの bind を直接使用し ないでください。コントロールプレーンは loopback-only に保つか、アクセス制御付きの HTTPS ゲートウェイの 背後に配置してください。

[server] はリスナーと永続パスを設定します。[health] は値が省略された場合のヘルスチェックのタイミン グのデフォルトを提供します。各 [[upstream_pools]] はロードバランスされるバックエンドグループに名前を 付け、その [[upstream_pools.backends]] エントリが到達可能なアドレスと、TCP チェックまたは health_path を伴う HTTP チェックを定義します。各 [[routes]] はホストとパスプレフィックスを照合し、 プールを選択します。同じホストが /v1 以外のパスも扱う必要がある場合は、例の / ルートを追加してくだ さい。

検証とリロード

実行中のプロキシを変更する前に、マウントされた設定を検証します:

docker compose exec bearust bearust validate --config /etc/bearust/bearust.toml

設定した TOML をアトミックに置き換えた後、Compose サービスを再起動せずにリロードします:

docker compose kill -s HUP bearust

ルーティングを検証する

例のホスト名はルーティングキーなので、Docker ホストから明示的な Host ヘッダーでテストします:

curl -i -H 'Host: api.example.com' http://127.0.0.1:8080/v1

フィクスチャのバックエンドが起動していないか、ヘルスチェックに失敗している場合、503 が想定される結果 です: ルートは一致したものの、選択可能な健全なバックエンドがなかったことを意味します。404 が返る場合 は、通常ホストまたはパスプレフィックスが一致していません。本番デプロイでは、フィクスチャのアドレスをコ ンテナまたはネットワーク経由で到達可能なバックエンドに置き換え、503 をプロキシの障害とみなす前にその ヘルスエンドポイントを確認してください。