- 基本情報
- データのセキュリティとコンプライアンス
- 組織
- 認証とセキュリティ
- ライセンス
- テナントとサービス
- アカウントとロール
- AI Trust Layer
- 外部アプリケーション
- 通知
- ログ
- データ エクスポート
- 組織でのテスト
- トラブルシューティング
- Test Cloud に移行する
ネットワーク内のマシンに Relay クライアントをインストールして起動し、Test Cloud への送信トンネルを確立します。開始する前に、Relay グループを設定し、クライアント設定文字列を準備しておきます。
前提条件
ハードウェア要件
| プロファイル | 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 クライアントには、送信のみの接続が必要です。受信ファイアウォール規則は必要ありません。
Relay クライアント 26.4.2以降、新しい Relay クライアント設定では、標準の Automation Cloud URL cloud.uipath.comを介して永続トンネルを接続できます。これらの構成では、トンネルにリージョン固有のリレー ホスト名許可リストは必要ありません。
| Relay クライアントの構成 | プロトコル | ポート | ターゲット | TLS パススルーが必要 | 目的 |
|---|---|---|---|---|---|
26.4.2 以降のリレー クライアント | HTTPS / WSS | 443 | cloud.uipath.com | 必須ではない | 認証、リレー登録、および永続トンネル |
次のバージョンより前のリレー クライアント バージョン 26.4.2 | TLS | 443 | <region>-relay.uipath.com | Required | 永続トンネル |
26.4.2より前のバージョンのリレークライアントは、引き続き地域のリレーホスト名で動作します。これらのホスト名は、Relay クライアント 26.4.2 以降に移行し、 cloud.uipath.com経由で接続するまで、許可リストに登録したままにしてください。
26.4.2 より前のバージョンの Relay クライアントの場合は、<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 欧州 | gxp-eu-relay.uipath.com |
| GXP 米国 | gxp-us-relay.uipath.com |
テナントのリージョンが上記のリストにない場合は、UiPath サポートに連絡してリレー サーバーのホスト名を確認してください。
リレー ノードの物理的な場所ではなく、UiPath Cloud テナント のリージョンに一致するリージョンを選択します。たとえば、テナントが米国リージョンにプロビジョニングされている場合は、リレー自体が別の地域で実行される場合でも、 us-relay.uipath.com を使用します。cloud.uipath.comを介して接続するリレークライアント26.4.2構成では、この地域ホスト名は使用されません。
遅延に関する考慮事項
待機時間に関する考慮事項: トラフィックは UiPath Cloud → リレー サーバー→リレー ノード→オンプレミス サービスを通過するため、テナントのリージョンに地理的に近い場所にリレー ノードを配置すると、ラウンドトリップ時間が最小限に抑えられ、全体的なスループットが向上します。
Relay クライアント 26.4.2 の構成
cloud.uipath.com 経由で接続する Relay クライアント 26.4.2 構成の場合は、cloud.uipath.com:443 への HTTPS トラフィックと WebSocket のアップグレードを許可するようにファイアウォールとプロキシを構成します。
プロキシが TLS を検査して cloud.uipath.com を確認する場合は、Relay クライアントによって使用される OS の信頼ストアにプロキシの署名 CA をインストールし、プロキシで WebSocket アップグレードが許可されるようにします。
次のバージョンより前のリレー クライアント バージョン 26.4.2
26.4.2 より前の Relay クライアント バージョンの場合、ファイアウォールと、TLS 検査プロキシまたは DLP アプライアンスを、<region>-relay.uipath.com:443 の TLS パススルーを許可するように構成します。リージョンの Relay ホスト名に対して TLS 検査を行うと、Relay トンネルが切断されます。
また、Relay クライアントを実行するマシンは、公開する予定のすべてのオンプレミス サービスに直接ネットワーク アクセスできる必要があります。それに応じて、リレー クライアントの配置を計画します。
リレー ノードは、実行時にホスト名を解決し、リレー グループ内のすべてのエンドポイントの登録済みポートへの接続を開くことができる必要があります。ルーティング パスは柔軟で、リレー ノードからの接続が成功する限り、直接ネットワーク ルート、企業のエグレス プロキシ、またはジャンプ ホストはすべて受け入れられます。グループ内のすべてのエンドポイントが到達可能なままになるように配置を計画します。
帯域幅
制御チャネル (ハートビートと認証) は、アイドル時に約 1 〜 2 KB/分 を使用します。データトラフィックは、クラウドサービスがオンプレミスエンドポイントに送信するリクエストの量に応じてスケーリングされ、リレーは透過的なトンネルとして機能し、TLSと cloud.uipath.com 接続用の軽量WebSocketフレーミング以外のオーバーヘッドはありません。
接続を確認する
リレークライアントをインストールする前に、ポート443の送信トラフィックが構成に必要な宛先に許可されていることを確認してください。
Linux
nc -zv cloud.uipath.com 443
# Required only for Relay client versions earlier than 26.4.2
nc -zv <region>-relay.uipath.com 443
nc -zv cloud.uipath.com 443
# Required only for Relay client versions earlier than 26.4.2
nc -zv <region>-relay.uipath.com 443
Windows (PowerShell)
Test-NetConnection -ComputerName cloud.uipath.com -Port 443
# Required only for Relay client versions earlier than 26.4.2
Test-NetConnection -ComputerName <region>-relay.uipath.com -Port 443
Test-NetConnection -ComputerName cloud.uipath.com -Port 443
# Required only for Relay client versions earlier than 26.4.2
Test-NetConnection -ComputerName <region>-relay.uipath.com -Port 443
成功した結果には、Windows では TcpTestSucceeded : True 、Linux では succeeded が表示されます。必要なチェックに失敗した場合は、ファイアウォール ルールを確認してください。cloud.uipath.com経由で接続する Relay クライアント26.4.2構成の場合は、WebSocket のアップグレードが許可されていることを確認します。26.4.2より前のリレークライアントバージョンの場合は、リレーサーバホスト名に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 ハンドシェイクは証明書検証エラーで失敗します。
cloud.uipath.com 経由で接続する Relay クライアント 26.4.2 構成の場合は、cloud.uipath.com:443 への長時間の HTTPS 接続と WebSocket のアップグレードを許可するようにプロキシを設定します。プロキシが TLS を検査して cloud.uipath.com を確認する場合は、Relay クライアントによって使用される OS の信頼ストアにプロキシの署名 CA をインストールします。
26.4.2 より前の Relay クライアント バージョンの場合は、<region>-relay.uipath.com:443 に対する TLS の検査をバイパスするようにプロキシを構成します。PAC ファイル、WPAD 自動検出、およびプロキシ チェーンはサポートされません。プロキシの URL を明示的に設定してください。プロキシが検出された場合、前提条件の確認の出力に via proxy と表示されます。
セキュリティ: Relay クライアントは、ログ内のプロキシ パスワードを編集します。ただし、環境変数に設定された資格情報は、プロセスリストや systemd ユニットファイルに表示される場合があります。専用のサービス資格情報を使用し、それに応じてリレー ノードへのアクセスを制限します。
信頼できる IP を設定する (該当する場合)
組織が IP アドレスでアクセスを制限している場合は、[管理] で、Relay クライアントが実行されているマシンの NAT IP を信頼できる IP リストに追加します。Relay クライアントの送信トラフィックはこの IP アドレスから Test Cloud に接続するので、この IP アドレスを明示的に許可する必要があります。
手順については、「 信頼できる IP 範囲を追加する」をご覧ください。
ライセンス契約に同意します
Relayクライアントを起動する前に、ライセンス契約に同意する必要があります。次のいずれかの方法を選択します。
オプション 1 (環境変数) — LICENSE_AGREEMENT 環境変数を accept に設定します。
Linux
export LICENSE_AGREEMENT=accept
export LICENSE_AGREEMENT=accept
Windows
$env:LICENSE_AGREEMENT=accept
$env:LICENSE_AGREEMENT=accept
オプション 2 (インライン パラメーター) — relay start コマンドに --accept-license-agreement を追加します。
./relay start --config "<your-config>" --accept-license-agreement
./relay start --config "<your-config>" --accept-license-agreement
セットアップ ガイド
運用環境へのデプロイについては、ご使用のオペレーティング システム用のプラットフォーム ガイドをご覧ください。そのガイドでは、ディレクトリ構造、サービスの管理、セキュリティ フレームワークの設定、アンインストール手順について説明されています。
| プラットフォーム | ガイド |
|---|---|
| Linux | Linux での Relay クライアントのデプロイ |
| Windows | Windows への Relay クライアントの導入 |
| コンテナ― | Relay クライアントをコンテナとしてデプロイする |
操作
接続の回復性
リレークライアントは、トンネルを自動的に維持します。
- デフォルトでは30秒ごとのハートビート(
--heartbeat-intervalを介して設定可能、最小10秒)。トンネル タイムアウトはハートビート間隔の 3× です。ファイアウォール、プロキシ、または NAT がアイドル状態の TCP 接続を 30 秒前に切断する場合は、間隔を短くします。relay start --config "<config>" --heartbeat-interval 10 relay restart <id> --heartbeat-interval 10relay 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
relay start --config "<config>" --reconnect-interval 1800
有効な最小値は 1800 秒 (30 分) です。間隔をネットワークアプライアンスのアイドルタイムアウトの約半分に設定します(たとえば、60分のファイアウォールタイムアウトの場合は1800秒)。アイドル接続タイムアウトなしで安定したネットワークで無効のままにします。
-
優雅な排水。この間隔が経過すると、Relay クライアントは新しい作業の受け入れを停止し、インフライト接続が完了するのを待機し (最大 300 秒のドレイン タイムアウト)、古い接続を閉じて新しい接続を開きます。ドレインのタイムアウトに達したときにまだ処理中の要求は終了します。
-
高可用性複数の Relay クライアントが同じグループにデプロイされている場合、一度に 1 つのクライアントのみがドレインされるように調整されます。グループは、各再接続サイクルを通じてトラフィックを提供し続けます。
-
プロアクティブな再接続が必要であることを示す兆候: ログには、基盤となるネットワークが安定しているにもかかわらず、定期的な
unexpected EOFエラーやサイレント切断が記録されています。これは通常、ファイアウォール、プロキシ、ロードバランサーで 30 分から 60 分のアイドルタイムアウトが原因です。
構成を再読み込みする
relay reload <id>
relay reload <id>
Test Cloud からプロキシ構成を再取得し、再起動せずに適用します。クラウド側での変更 (新しいエンドポイント、健全性チェックのパスの更新) は、実行中の Relay クライアントに自動的にプッシュされるため、通常は再読み込みは必要ありません。このコマンドは、新しく追加したエンドポイントが 404 を返す場合にのみ、フォールバックとして使用してください。
ログ
| 設定 | 値 (Value) |
|---|---|
| 既定のレベル | info |
| 回転 | 毎日 |
| retention | 7 日 |
| ログ ファイル | relay.log (現在)、 relay.YYYYMMDD-HHMMSS.log (回転) |
既定のログ レベルを [ --log-level trace/debug/info/warn/error] で上書きします。Relay クライアント 26.4.2 以降で、ローテーションされたログの保持期間を relay start または relay restartの --log-retention-days <days> で上書きします。最小保持期間は 7 日間です。
コマンド リファレンス
リレー開始
新しい Relay クライアントをプロビジョニングし、バックグラウンド サービスとして開始します。
構成 (1 つが必要)
-c、--config <string>— base64 でエンコードされたインライン構成文字列。--config-file <path>— 構成文字列を含むファイルへのパス。推奨 — シェルの履歴から秘密を保ちます。
チューニング(オプション)
--heartbeat-interval <sec>— トンネルのハートビート間隔。既定の30です。最小10トンネル タイムアウトは、この値の 3× です。ファイアウォール、NAT、またはプロキシがアイドル状態の TCP を 30 秒前にドロップする場合は、この値を下げます。--reconnect-interval <sec>— プロアクティブな再接続間隔。既定0(無効)。設定した場合、有効な最小1800(30 分)。--log-level <level>—trace、debug、info、warn、またはerror。既定のinfoです。--log-retention-days <days>— ローテーションされたログファイルを保持する日数。既定の7です。最小7Relay クライアント26.4.2以降が必要です。-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 クライアント サービスを停止して再起動します。更新されたバイナリを検出し、サービス定義の変更を適用します。
再起動時に以下のフラグを上書きできます (特に記載がない限り、既定ではいずれも変更されません)。
--config/--config-file— クライアント設定を置き換えます。--accept-license-agreement— 再起動時にライセンス契約に同意します。ライセンスへの同意が持続しなかった古いインストール済みサービスをアップグレードする場合に役立ちます。--log-level— ログ レベルを変更します。--logs-dir <path>— インストールしたサービスのログディレクトリを移動します。Relay クライアント26.4.2以降が必要です。--log-retention-days <days>— ローテーションされたログの保持を変更します。最小7変更しない-1を渡します。Relay クライアント26.4.2以降が必要です。--heartbeat-interval— ハートビート間隔を変更します。最小10変更しない0を渡します。--reconnect-interval— プロアクティブ再接続間隔を変更します。設定されている場合は最小1800(30 分)。[0を渡す] で無効にするか、[-1] を変更せずにそのままにするかを指定します。
リレーログ
リレークライアントのログ出力を表示します。
-f、--follow— 新しいログ行を連続的にストリーミングします。-n,--lines <N>— 末尾からの行数既定の50です。
リレーのリスト
このマシン上のすべての Relay クライアントを、ステータス、バージョン、作成と更新のタイムスタンプ、およびグループ (使用可能な場合) と共に表示します。長いグループ名は、表の出力では切り捨てられます。
--json— オートメーションとスクリプト用の完全なグループ名を含むJSON出力を出力します。
relay describe (Relay クライアント26.4.2以降)
26.4.2以降)グループIDと名前、シークレットID、ステータス、バージョン、サービスモードと実行可能パス、設定されたハートビートと再接続の間隔、ログレベル、ローカルパス、タイムスタンプなど、1つのリレークライアントの詳細情報を表示します。
--json— オートメーションとスクリプティング用の JSON 出力を出力します。
リレーリロード
Test Cloud からプロキシ構成を再取得し、再起動せずに適用します。新しく追加したエンドポイントが 404 を返す場合にフォールバックとして使用します。
リレーストップ
リレークライアントサービスを停止します。構成と資格情報は保持され、リレークライアントは後で再起動できます。
リレー削除
サービスを停止して Test Cloud から登録を解除し、ローカルの設定と資格情報をすべて削除します。
-f、--force— クラウドの登録を解除せずにローカルで削除します。資格情報が読み取れない場合、またはクラウド側のリソースがすでに削除されている場合に使用します。
relay support-bundle [id]
UiPath サポート チケット用に、設定、ログ、システム メタデータの墨消し済みのアーカイブを収集します。マシン上のすべての Relay クライアントをバンドルするには、[id] を省略します。資格情報と暗号化キーは一切含まれません。詳しくは、Relay のトラブルシューティングに関するこちらのページをご覧ください。
リレーのバージョン
Relay クライアントのバージョン、ビルド日、および git コミットハッシュを出力します。
ウイルス対策とエンドポイント セキュリティ
組織でエンドポイント保護ソフトウェアを実行している場合は、Relay のバイナリとそのデータ ディレクトリを除外対象として追加し、Relay クライアントがブロックまたは隔離されないようにします。cloud.uipath.com 経由で接続する Relay クライアント 26.4.2 の構成の場合は、cloud.uipath.com:443 を許可します。
26.4.2 より前の Relay クライアント バージョンの場合は、TLS 検査プロキシ、DLP アプライアンス、および IDS/IPS システムを、<region>-relay.uipath.com:443 に対する検査をバイパスするように構成します。
| ターゲット | ポート | プロトコル | 操作 |
|---|---|---|---|
cloud.uipath.com | 443 | https | 許可 |
<region>-relay.uipath.com | 443 | TLS | 次の日付より前の Relay クライアント バージョンのTLS インスペクションを許可 + バイパスする 26.4.2 |
- 前提条件
- ハードウェア要件
- ディスクの要件
- サポートされているオペレーティング システム
- ネットワーク要件
- 帯域幅
- 接続を確認する
- プロキシを構成する (該当する場合)
- 信頼できる IP を設定する (該当する場合)
- ライセンス契約に同意します
- Linux
- Windows
- セットアップ ガイド
- 操作
- 接続の回復性
- プロアクティブな再接続
- 構成を再読み込みする
- ログ
- コマンド リファレンス
- リレー開始
- リレーの再起動
- リレーログ
- リレーのリスト
- relay describe
(Relay クライアント 26.4.2以降) - リレーリロード
- リレーストップ
- リレー削除
- relay support-bundle [id]
- リレーのバージョン
- ウイルス対策とエンドポイント セキュリティ