Relay クライアントをデプロイする

ネットワーク内のマシンに Relay クライアントをインストールして起動し、Test Cloud への送信トンネルを確立します。開始する前に、リレーグループを設定し、クライアント設定文字列を準備しておきます。

前提条件

ハードウェア要件

プロファイル	vCPU	RAM	リレーグループ	グループあたりのエンドポイント	ユースケース
標準	1	2 GB	10 個まで	最大 50	ほとんどのデプロイ
大	2	4 GB	10 以降	最大 50	ハイスループット環境や大規模環境

これらは、リレークライアントプロセスの最小要件です。マシンで他のワークロードが実行されている場合は、それに応じて追加のリソースをプロビジョニングします。

ディスクの要件

プロファイル	最小空きディスク
標準 (1 〜 10 グループ)	200メガバイト
大規模 (10+ グループ)	1 GB

サポートされているオペレーティング システム

アーキテクチャ	Linux	Windows
x86_64 (AMD64)	サポート対象	サポート対象
ARM64 (aarch64)	サポート対象	サポート対象

ネットワーク要件

Relay クライアントには、送信のみの接続が必要です。受信ファイアウォール規則は必要ありません。

プロトコル	ポート	ターゲット	TLS パススルーが必要	目的
https	443	cloud.uipath.com	必須ではない	認証とリレー登録
TCP	443	<region>-relay.uipath.com	Required	リレー サーバーへの永続的なトンネル (未加工の TLS ラップ TCP)

<region> は、ご自身の Test Cloud テナントのリージョンに置き換えてください。

リージョン	リレーサーバーのホスト名
米国	us-relay.uipath.com
EU	eu-relay.uipath.com
カナダ	ca-relay.uipath.com
スイス	ch-relay.uipath.com
オーストラリア	au-relay.uipath.com
シンガポール	sg-relay.uipath.com
日本	jp-relay.uipath.com
韓国	kr-relay.uipath.com
アラブ首長国連邦	ae-relay.uipath.com
英国	uk-relay.uipath.com
GXP EU	gxp-eu-relay.uipath.com
GXP 米国	gxp-us-relay.uipath.com

注:

テナントのリージョンが上記のリストにない場合は、UiPath サポートに連絡してリレー サーバーのホスト名を確認してください。

リレー ノードの物理的な場所ではなく、UiPath Cloud テナント のリージョンに一致するリージョンを選択します。たとえば、テナントが米国リージョンにプロビジョニングされている場合は、リレー自体が別の地域で実行される場合でも、 us-relay.uipath.com を使用します。

待機時間に関する考慮事項: トラフィックは UiPath Cloud → リレー サーバー→リレー ノード→オンプレミス サービスを通過するため、テナントのリージョンに地理的に近い場所にリレー ノードを配置すると、ラウンドトリップ時間が最小限に抑えられ、全体的なスループットが向上します。

ファイアウォールと TLS 検査プロキシまたは DLP アプライアンスを構成して、 <region>-relay.uipath.com:443の TLS パススルーを許可します。この宛先の TLS インスペクションは、リレー トンネルを切断します。

また、Relay クライアントを実行するマシンは、公開する予定のすべてのオンプレミス サービスに直接ネットワーク アクセスできる必要があります。それに応じて、リレー クライアントの配置を計画します。

重要:

リレー ノードは、実行時にホスト名を解決し、リレー グループ内のすべてのエンドポイントの登録済みポートへの接続を開くことができる必要があります。ルーティング パスは柔軟で、リレー ノードからの接続が成功する限り、直接ネットワーク ルート、企業のエグレス プロキシ、またはジャンプ ホストはすべて受け入れられます。グループ内のすべてのエンドポイントが到達可能なままになるように配置を計画します。

帯域幅

制御チャネル (ハートビートと認証) は、アイドル時に約 1 〜 2 KB/分 を使用します。データトラフィックは、クラウドサービスがオンプレミスエンドポイントに送信するリクエストの量に応じてスケーリングされ、リレーは透過的なトンネルとして機能し、TLSフレーミングを超えるオーバーヘッドはありません。

接続を確認する

リレークライアントをインストールする前に、ポート443の送信トラフィックが両方の必要な宛先に許可されていることを確認してください。

Linux

nc -zv cloud.uipath.com 443
nc -zv <region>-relay.uipath.com 443

Windows (PowerShell)

Test-NetConnection -ComputerName cloud.uipath.com -Port 443
Test-NetConnection -ComputerName <region>-relay.uipath.com -Port 443

成功した結果には、Windows では TcpTestSucceeded : True 、Linux では succeeded が表示されます。いずれかのチェックに失敗した場合は、ファイアウォールルールを確認し、リレーサーバーのホスト名に TLS パススルーが構成されていることを確認します。

プロキシを構成する (該当する場合)

ネットワークが送信トラフィックをプロキシ経由でルーティングする場合は、実行する前に次の環境変数を設定します relay start。リレークライアントは、すべてのアウトバウンド接続にプロキシを適用します。

変数	目的
HTTPS_PROXY / https_proxy	プロキシ URL (最初に確認)
HTTP_PROXY / http_proxy	プロキシ URL (フォールバック)
NO_PROXY / no_proxy	プロキシをバイパスするコンマ区切りのホストまたはドメイン

プロキシ URL は、 http://、 https://、 socks5://、または ntlm://のいずれかのスキームを使用する必要があります。形式: scheme://[user:password@]host:portです。

https://プロキシの場合: Relay クライアントは、プロキシの TLS 証明書を OS 信頼ストアと照合して検証します。プロキシが企業 CA または自己署名 CA を使用している場合は、リレーを開始する前に、その CA をリレー クライアント マシンの信頼ストアに追加します。そうしないと、TLS ハンドシェイクは証明書検証エラーで失敗します。

TLS インスペクションをバイパスするようにプロキシを設定し <region>-relay.uipath.com:443。PAC ファイル、WPAD 自動検出、およびプロキシ チェーンはサポートされていません — プロキシ URL を明示的に設定します。プロキシが検出されると、前提条件の確認の結果、出力に via proxy と表示されます。

セキュリティ： Relay クライアントは、ログ内のプロキシ パスワードを編集します。ただし、環境変数に設定された資格情報は、プロセスリストや systemd ユニットファイルに表示される場合があります。専用のサービス資格情報を使用し、それに応じてリレー ノードへのアクセスを制限します。

信頼できる IP を設定する (該当する場合)

組織において IP アドレスでアクセスを制限している場合は、Relay クライアントを実行しているマシンの NAT IP を UiPath Administration で信頼できる IP リストに追加します。Relay クライアントの送信トラフィックはこの IP アドレスから Test Cloud に到達するため、この IP アドレスを明示的に許可する必要があります。

手順については、「 信頼できる IP 範囲を追加する」をご覧ください。

ライセンス契約に同意します

Relayクライアントを起動する前に、ライセンス契約に同意する必要があります。次のいずれかの方法を選択します。

オプション 1 (環境変数) — LICENSE_AGREEMENT 環境変数を accept に設定します。

Linux

export LICENSE_AGREEMENT=accept

Windows

$env:LICENSE_AGREEMENT=accept

オプション 2 (インライン パラメーター) — relay start コマンドに --accept-license-agreement を追加します。

./relay start --config "<your-config>" --accept-license-agreement

セットアップ ガイド

運用環境のデプロイについては、ご使用のオペレーティング システム向けのプラットフォーム ガイドをご覧ください。そのガイドでは、ディレクトリ構造、サービスの管理、セキュリティ フレームワークの設定、アンインストール手順について説明されています。

プラットフォーム	ガイド
Linux	Linux での Relay クライアントのデプロイ
Windows	Windows への Relay クライアントの導入

操作

接続の回復性

リレークライアントは、トンネルを自動的に維持します。

• デフォルトでは30秒ごとのハートビート(--heartbeat-intervalを介して設定可能、最小10秒)。トンネル タイムアウトはハートビート間隔の 3× です。ファイアウォール、プロキシ、または NAT がアイドル状態の TCP 接続を 30 秒前に切断する場合は、間隔を短くします。

  relay start --config "<config>" --heartbeat-interval 10
  relay restart <id> --heartbeat-interval 10
  

• 20秒間隔への指数バックオフスケーリングを使用して、切断時に自動再接続します。
• プロセスがクラッシュした場合のサービスの自動再起動。Linux では systemd 、Windows では Windows サービス コントロール マネージャーによって管理されます。
• システムの再起動時にサービスが自動的に開始します。

プロアクティブな再接続

一部のネットワーク(企業プロキシ、ロードバランサー、またはアイドル接続タイムアウトのあるファイアウォールの背後)は、有効期間の長いTLS接続をサイレントに終了します。プロアクティブ再接続は、これを防ぐために、固定スケジュールで制御接続を再確立します。

--reconnect-interval フラグを付けて有効化します。

relay start --config "<config>" --reconnect-interval 1800

有効な最小値は 1800 秒 (30 分) です。間隔をネットワークアプライアンスのアイドルタイムアウトの約半分に設定します(たとえば、60分のファイアウォールタイムアウトの場合は1800秒)。アイドル接続タイムアウトなしで安定したネットワークで無効のままにします。

優雅な排水。この間隔が経過すると、Relay クライアントは新しい作業の受け入れを停止し、インフライト接続が完了するのを待機し (最大 300 秒のドレイン タイムアウト)、古い接続を閉じて新しい接続を開きます。ドレインのタイムアウトに達したときにまだ処理中の要求は終了します。

高可用性複数の Relay クライアントが同じグループにデプロイされている場合、一度に 1 つのクライアントのみがドレインされるように調整されます。グループは、各再接続サイクルを通じてトラフィックを提供し続けます。

プロアクティブな再接続が必要であることを示す兆候: ログには、基盤となるネットワークが安定しているにもかかわらず、定期的な unexpected EOF エラーやサイレント切断が記録されています。これは通常、ファイアウォール、プロキシ、ロードバランサーで 30 分から 60 分のアイドルタイムアウトが原因です。

構成を再読み込みする

relay reload <id>

Test Cloud からプロキシ構成を再取得し、再起動せずに適用します。クラウド側での変更 (新しいエンドポイント、健全性チェックのパスの更新) は、実行中の Relay クライアントに自動的にプッシュされ、通常は再読み込みの必要はありません。このコマンドは、新しく追加したエンドポイントが 404 を返す場合にのみ、フォールバックとして使用してください。

ログ

設定	値 (Value)
既定のレベル	info
回転	毎日
retention	7 日
ログ ファイル	relay.log (現在)、 relay.YYYYMMDD-HHMMSS.log (回転)

既定のログ レベルを [ --log-level trace/debug/info/warn/error] で上書きします。

管理コマンド

操作	Linux	Windows (管理者 PowerShell)
リレー クライアントのリストを取得	relay list	.\relay.exe list
リスト (JSON 出力)	relay list --json	.\relay.exe list --json
ログを表示	relay logs <id>	.\relay.exe logs <id>
ストリームログ	relay logs <id> --follow	.\relay.exe logs <id> --follow
構成を再読み込みする	relay reload <id>	.\relay.exe reload <id>
停止	sudo relay stop <id>	.\relay.exe stop <id>
再実行	sudo relay restart <id>	.\relay.exe restart <id>
削除する	sudo relay delete <id>	.\relay.exe delete <id>
強制削除	sudo relay delete <id> --force	.\relay.exe delete <id> --force
バージョン	relay version	.\relay.exe version

[削除時の --force ] は、認証情報が読み取れない場合 (仮想マシンのクローン作成や再イメージ化の後など) や、クラウド側リレー グループがすでに削除されている場合に使用します。

コマンド リファレンス

relay start

新しい Relay クライアントをプロビジョニングし、バックグラウンド サービスとして開始します。

構成 (1 つが必要)

• -c、 --config <string> — base64 でエンコードされたインライン構成文字列。
• --config-file <path> — 構成文字列を含むファイルへのパス。推奨 — シェルの履歴から秘密を保ちます。

チューニング(オプション)

• --heartbeat-interval <sec> — トンネルのハートビート間隔。既定の 30です。トンネル タイムアウトは、この値の 3× です。ファイアウォール、NAT、またはプロキシがアイドル状態の TCP を 30 秒前にドロップする場合は、この値を下げます。
• --reconnect-interval <sec> — プロアクティブな再接続間隔。既定 0 (無効)。設定した場合、有効な最小 1800 (30 分)。
• --log-level <level> — trace、 debug、 info、 warn、または error。既定の infoです。
• -d、 --detach=false — バックグラウンド サービスとしてではなく、フォアグラウンドで実行されます。起動時の問題をデバッグするのに役立ちます。

既定以外のインストール パス (任意)

• --data-dir <path> — 構成ディレクトリ。
• --logs-dir <path> — ログファイルディレクトリ。
• --bin-dir <path> — バイナリインストールディレクトリ。

Linux のみ

• --user-mode — systemd ユーザーサービスとしてインストールします ( sudo は不要で、XDG パスを使用します)。

Windows のみ

• --service-account <DOMAIN\user> — 特定のアカウントで Windows サービスを実行します。既定値は LocalSystemです。
• --service-account-password <password> — --service-accountのパスワード。

relay restart <id>

リレークライアントサービスを停止し、再起動します。更新されたバイナリを検出し、サービス定義の変更を適用します。次のフラグは、再起動時にオーバーライドできます (すべて既定で変更されません)。

• --config / --config-file — クライアント設定を置き換えます。
• --log-level — ログ レベルを変更します。
• --heartbeat-interval — ハートビート間隔を変更します。変更しない 0 を渡します。
• --reconnect-interval — プロアクティブ再接続間隔を変更します。設定されている場合は最小 1800 (30 分)。0を渡して無効化します。

relay logs <id>

リレークライアントのログ出力を表示します。

• -f、 --follow — 新しいログ行を連続的にストリーミングします。
• -n, --lines <N> — 末尾からの行数既定の 50です。

relay list

このマシン上のすべてのリレークライアントを、ステータス、グループID、作成タイムスタンプ、およびサービスモードで表示します。

• --json — オートメーションとスクリプティング用の JSON 出力を出力します。

relay reload <id>

Test Cloud からプロキシ構成を再取得し、再起動せずに適用します。新しく追加したエンドポイントが 404 を返す場合にフォールバックとして使用します。

relay stop <id>

リレークライアントサービスを停止します。構成と資格情報は保持され、リレークライアントは後で再起動できます。

relay delete <id>

サービスを停止して Test Cloud から登録を解除し、ローカルの設定と資格情報をすべて削除します。

• -f、 --force — クラウドの登録を解除せずにローカルで削除します。資格情報が読み取れない場合、またはクラウド側のリソースがすでに削除されている場合に使用します。

relay support-bundle [id]

UiPath サポート チケットに使用する、設定、ログ、システム メタデータの編集済みのアーカイブを収集します。マシン上のすべての Relay クライアントをバンドルするには、[id] を省略します。資格情報と暗号化キーは一切含まれません。詳しくは、Relay のトラブルシューティングをご覧ください。

relay version

Relay クライアントのバージョン、ビルド日、および git コミットハッシュを出力します。

ウイルス対策とエンドポイント セキュリティ

組織でエンドポイント保護ソフトウェアを実行している場合は、リレーバイナリとそのデータディレクトリの除外を追加して、リレークライアントがブロックまたは隔離されないようにします。TLS 検査プロキシ、DLP アプライアンス、および IDS/IPS システムを設定して、 <region>-relay.uipath.com:443の検査をバイパスします。

ターゲット	ポート	プロトコル	操作
cloud.uipath.com	443	https	許可
<region>-relay.uipath.com	443	TLS	許可 + TLS インスペクションのバイパス