ネットワーク

Azure または AWS のネットワーク リソースをプロビジョニングして構成する必要があります。これは、クラスター上の Automation Suite がクラウド インフラストラクチャの前提条件 (ストレージ、データベース、キャッシュ、DNS など) に接続し、アクセスするために必要です。 ネットワーク アーキテクチャによっては、Vnet/VPC、DNS、サブネット、NSG/セキュリティ グループ、NAT ゲートウェイ、Elastic IP、インターネット ゲートウェイなどの構成が必要になる場合があります。詳しくは、「デプロイのシナリオ」をご覧ください。

ワークロードのスケーリングに基づいて、さらにレプリカが必要になる場合があります。 デフォルトでは、HA モードでは 2 つのレプリカが必要で、最大 10 個以上のレプリカを使用できます。 ネットワークがこのスケーリング レベルをサポートしていることを確認します。

ポッドが相互に通信できる限り、任意の CNI を使用できます。

Azure CNI や Amazon VPC CNI など、内部ポッドまたはプライベートポッドネットワーキングサブネットをサポートしていないクラウド CNI には特別な考慮事項があります。 Automation Suite に必要なポッドの数は、製品の選択とワークロードのスケーリングによって異なります。 たとえば、すべてのサービスが有効で使用率が高いデプロイの場合、スケーリング要件をサポートするために 400 を超える IP が必要になる場合があります。 このため、/23 以上の CIDR 範囲を割り当てることをお勧めします。

重要:

Automation Suite は IPｖ6 インターネット プロトコルをサポートしていません。

注:

IP テーブルの変更は推奨されておらず、サポートもされていません。

カスタムのイングレス コントローラー

カスタムの Ingress コントローラー (NGINX) を使用する場合は、「NGINX Ingress コントローラーを構成する」を参照し、このページの残りの部分はスキップしてください。

ロード バランサーの構成

Automation Suite は、インストール中にユーザーに代わってロード バランサーをプロビジョニングします。受信 FQDN 要求をルーティングするには、ロード バランサーにパブリックまたはプライベート IP アドレスを割り当てる必要があります。ロード バランサーを構成するには、次の 2 つのオプションがあります。

• 事前割り当て IP: ロード バランサーにパブリック IP またはプライベート IP を割り当て、DNS レコードを構成して FQDN をこれらの IP にマッピングし、その IP を input.jsonの ingress セクションの一部として指定します。
• 動的割り当て IP: IP アドレスを指定しない場合、IP は Automation Suite によってクラスター サブネットからロード バランサーに動的に割り当てられます。

ロード バランサーのネットワーク セキュリティ グループは、ポート 443 経由のエンド クライアントからの HTTPS トラフィックを許可する必要があります。 既定では、定期的な TCP 正常性チェックを実行するようにロード バランサーを構成します。

NGINX などの独自のイングレスを使用する場合は、「 NGINX イングレス コントロールを構成する」に記載されているネットワーク要件を満たしていることを確認してください。NLB をデプロイする Istio を使用する場合、通常、ポート 80、443、15021 の 3 つのリスナーが作成されることに注意してください。ただし、これは一般的な設定であり、実際の要件は実際の状況によって異なる場合があるため、必要に応じて調整してください。

事前割り当て IP

次のサービス注釈を input.json の ingress セクションに指定する必要があります。

EKS のサービス注釈のリストについては、AWS ロード バランサーのドキュメントをご覧ください。

AKS のサービス注釈のリストについては、Azure Load Balancer のドキュメントをご覧ください。

EKS の注釈の例

以下の例は、input.json に ingress.service_annotations セクションを作成する方法を示しています。この例を正しく動作させるには、インストールの前に EKS クラスターに AWS ロード バランサー コントローラーをデプロイする必要があります。

次の例では、AWS から Elastic IP を割り当てて、パブリック ロード バランサーをプロビジョニングする方法を示します。この例を構成の開始点として使用する場合は、IP を実際の値に置き換えてください。

"ingress": {
    "service_annotations": {
      "service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
      "service.beta.kubernetes.io/aws-load-balancer-eip-allocations": "<elastic_ip_id_0>,<elastic_ip_id_1>",
      "service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
      "service.beta.kubernetes.io/aws-load-balancer-scheme": "internet-facing",
      "service.beta.kubernetes.io/aws-load-balancer-type": "nlb"
    }
  }

次の例では、EKS クラスター サブネットからプライベート IP を内部ロード バランサーに割り当てる方法を示します。この例を設定の開始点として使用する場合は、IP とサブネットを実際の値で更新してください。

 "ingress": {
    "service_annotations": {
      "service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
      "service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
      "service.beta.kubernetes.io/aws-load-balancer-private-ipv4-addresses":""<IP_0>,<IP_1>"",
      "service.beta.kubernetes.io/aws-load-balancer-subnets": "SUBNET_ID_0>,<SUBNET_ID_1>",
      "service.beta.kubernetes.io/aws-load-balancer-scheme": "internal",
      "service.beta.kubernetes.io/aws-load-balancer-type": "nlb"
      "service.beta.kubernetes.io/aws-load-balancer-target-group-attributes": "preserve_client_ip.enabled=false"
    }
  }

重要:

IP とサブネットは一致している必要があります。

前の例では、<IP_0> は <SUBNET_0> で、<SUBNET_1> は <IP_1> です。

AKS の注釈の例

次の例では、Azure からパブリック IP を割り当てて、パブリック ロード バランサーをプロビジョニングする方法を示します。この例を構成の開始点として使用する場合は、IP を実際の値で更新してください。

...
"ingress": {
    "service_annotations": {
      "service.beta.kubernetes.io/azure-load-balancer-internal": "false",
      "service.beta.kubernetes.io/azure-load-balancer-ipv4": "<IP>"
    }
  }
...

次の例では、AKS クラスター サブネットからプライベート IP を内部ロード バランサーに割り当てる方法を示します。この例を構成の開始点として使用する場合は、IP とサブネットを実際の値で更新してください。

...
"ingress": {
    "service_annotations": {
      "service.beta.kubernetes.io/azure-load-balancer-internal": "true",
      "service.beta.kubernetes.io/azure-load-balancer-ipv4": "<IP>",
      "service.beta.kubernetes.io/azure-load-balancer-internal-subnet": "<SUBNET>",
    }
  }
...

DNS の構成

DNS レコードが、以下の UiPath® FQDN をロード バランサーにマッピングするように設定されていることを確認します。

• FQDN
• alm.FQDN
• monitoring.FQDN
• insights.FQDN (UiPath Insights をインストールする場合)
• apps.FQDN (UiPath Apps をインストールする場合)

注:

FQDN は、インストール前の前提条件の 1 つです。IP アドレスを指定しない場合、または FQDN マッピングがまだ完了していない場合、確認は失敗します。

DNS に Route 53 を使用する場合は、関連する DNS レコードを、インストール中に作成された Elastic Load Balancer (ELB) を直接指すエイリアスレコードに変更します。これにより、特に AWS 環境でのマルチ AZ インストール中に複数のパブリック IP が含まれる場合に、適切なルーティングと迅速な解決が保証されます。

動的割り当て IP

input.json で IP を指定しない場合、Automation Suite はワーカー ノード サブネットからプライベート IP を動的に割り当てます。このシナリオでは、次の方法で Automation Suite のインストールを実行します。

input.json の EKS の例

...
  "ingress": {
    "service_annotations": {
      "service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
      "service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
      "service.beta.kubernetes.io/aws-load-balancer-scheme": "internal",
      "service.beta.kubernetes.io/aws-load-balancer-type": "nlb",
      "service.beta.kubernetes.io/aws-load-balancer-internal": true
    }
  }
...

input.json の AKS の例

...
  "ingress": {
    "service_annotations": {
      "service.beta.kubernetes.io/azure-load-balancer-internal": "true"
    }
  }
...

インストールの手順

このシナリオでは、インストーラーを以下のように実行します。

1. インストーラーを実行します。ただし、ロード バランサーをプロビジョニングするまでの間だけにしてください。

   uipathctl manifest apply <INPUT_JSON> --versions <VERSIONS_JSON> --override=gateway
   

2. ロード バランサーのホスト名を取得します。

   kubectl get svc -n <istio-system> istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
   

3. ロード バランサーのエンドポイントまたは IP にマッピングされた FQDN で DNS を構成します。
4. インストーラーを再実行してインストールを完了します。

   uipathctl manifest apply input.json --versions versions.json
   

注:

DNS マッピングがない場合、FQDN の前提条件の確認は失敗します。前提条件の確認の目的は、Automation Suite をインストールする前に前提条件がすべて正しくプロビジョニング済みであることを確認することです。FQDN の確認によって Automation Suite をインストールできなくなることはありません。