Docker
OCIイメージでProxerサーバーまたはクライアントを実行します。
イメージはDocker Hubのtinyrack/proxerとGHCRのghcr.io/tinyrack-net/proxerで公開されています。
バージョンを確認します。
docker run --rm tinyrack/proxer --versionサーバーを実行する
Section titled “サーバーを実行する”docker run --rm -p 8080:8080 \ -e PROXER_TOKEN="$PROXER_TOKEN" \ tinyrack/proxer \ server --listen 0.0.0.0:8080 --domain proxy.example.comサーバーにボリュームは不要です。トンネル登録はメモリ上にあり、クライアントが再接続すると再登録されます。
dev-tokenはローカルデモだけで使ってください。外部へ公開する環境では、長く使うトークンをコマンドラインに直接置かず、secret保存先からPROXER_TOKENとして渡すほうが安全です。
Docker Compose
Section titled “Docker Compose”services: proxer: image: ghcr.io/tinyrack-net/proxer:latest command: - server - --listen - 0.0.0.0:8080 - --domain - proxy.example.com environment: PROXER_TOKEN: ${PROXER_TOKEN:?set PROXER_TOKEN} PROXER_TRUSTED_PROXIES: loopback,private ports: - "8080:8080" healthcheck: test: ["CMD", "proxer", "--version"] interval: 30s timeout: 5s retries: 3クライアントコンテナ
Section titled “クライアントコンテナ”proxer http <port>は、クライアントプロセスの中から127.0.0.1:<port>へ転送します。コンテナで実行する場合、それはそのコンテナ内のloopbackです。
LinuxでアプリがDocker host上で待ち受けている場合は、host networkingを使うのが一般的です。
docker run --rm --network host \ -e PROXER_TOKEN="$PROXER_TOKEN" \ tinyrack/proxer \ http 3000 --server ws://127.0.0.1:8080 --subdomain demoDocker Desktopでは、host.docker.internalだけでは足りません。現在のクライアントにはupstream hostを指定するflagがありません。クライアントをhostで直接動かすか、到達したいアプリと同じコンテナまたは同じnetwork namespaceで動かしてください。
Kubernetes probe
Section titled “Kubernetes probe”プラットフォームがHTTPパスをprobeできる場合は、固定のヘルスエンドポイントを使います。
/__proxer__/health/live/__proxer__/health/ready制御エンドポイントも固定です。
/__proxer__/control制御エンドポイントはWebSocket upgradeを期待するため、probe先には使わないでください。
サーバーはPROXER_環境変数で設定できます。
docker run --rm -p 8080:8080 \ -e PROXER_LISTEN=0.0.0.0:8080 \ -e PROXER_DOMAIN=proxy.example.com \ -e PROXER_TOKEN="$PROXER_TOKEN" \ -e PROXER_TRUSTED_PROXIES=loopback,private \ ghcr.io/tinyrack-net/proxer server--trusted-proxyまたはPROXER_TRUSTED_PROXIESは、自分で管理するreverse proxyにだけ設定してください。