5. AI Fabric アプリケーション インストーラーを実行する

アプリケーション インストーラーを実行します。エアギャップ インストールの場合、AI Fabric とすぐに使えるモデルがインストールされます。

管理コンソールにアクセスする

管理コンソールに移動します。アクセス先の URL は必ず <machine-ip>:8800 です。この管理コンソールで、アプリケーション インストーラーを構成します。このアドレスに移動すると、以下のページが表示されます。

[Continue to Setup] をクリックします。次のウィンドウが表示されます。

DNS を構成する (任意)

Linux マシンに DNS が構成済みで、完全修飾ドメイン名に基づいて AI Fabric アプリにアクセスするときに独自の自己証明書を使用する場合は、この設定画面を使用できます。

ホスト名を入力し、秘密キーと SSL 証明書の両方をアップロードします。ポート 8800、31443、31390 を介して AI Fabric にアクセスするネットワークからドメインに到達可能であることを確認します。ドメイン証明書の場合、証明書のバンドル ファイルに、ルート、中間、サーバー証明書の順にチェーンのすべての要素が含まれていることを確認します。また、2048 ビット サイズ以上の公開 RSA キーで公開キー証明書が発行されていない場合、検証は失敗します。

証明書の形式は .pem ファイル形式で、秘密キーは .key ファイル形式です。これらのファイルは .pfx 証明書から取得できます。

管理コンソールにログインする

上記の手順で DNS を設定した後 (または **[Skip & continue]** をクリックして手順を省略した後) は、以下のページが表示されます。

「手順 4. AI Fabric インフラストラクチャ インストーラーを実行する」で設定したパスワードを入力します。ログインに成功すると、ライセンス ファイルのアップロードを求めるメッセージが表示されます。

AI Fabric ライセンスが付属する YAML ファイルをアップロードします (AI Fabric ライセンスがない場合は、AI Fabric の担当者にお問い合わせください)。

インストールの種類を選択する

エアギャップ インストール

エアギャップ インストールを実行している場合は、この手順でインストール バンドルをアップロードする必要があります。

[Choose a bundle to upload] ボタンをクリックし、前の手順で展開した aif_services ファイルを選択します。

オンライン インストール

オンライン インストールに従っている場合は、ページの下部にある次のリンクをクリックします。 download AI Fabric from the internet

インストーラーを構成する

次の手順では、以下の画面を使用してインストーラーを構成します。

このページの各フィールドに入力する必要があります。以下の説明をご覧ください。

Ingress

Host (IP or FQDN) Linux マシンの IP。このマシンの DNS を構成し、上記の「DNSを構成する」の手順を完了している場合は、このマシンの完全修飾ドメイン名を入力します。

単一のデータベースと複数のデータベース

手順 2 で実行した処理に応じた適切なオプションを選択します。

SQL

• ホスト: 手順「2. データベースを構成する」で作成したデータベースが存在する SQL データベースの IP アドレスを入力します。
• ユーザー名: SQL データベース所有者のユーザー名を入力します。
• パスワード: SQL データベースのパスワードを入力します。
  注: Azure データベースを使用している場合は、必ず FQDN を使用してデータベースに接続してください。DNS を構成していれば、パブリック ドメイン名またはプライベート ドメイン名を指定できますが、プライベート IP を使用している場合は機能しません。詳細については、こちら (https://docs.microsoft.com/en-us/azure/private-link/private-endpoint-dns) をご覧ください。

Orchestrator

エンドポイント: Orchestrator のアドレスとポート番号 443 を入力します。http、https を含めないでください。Orchestrator エンドポイントはドメイン名 <domain-name>:443 でなければなりません。

重要: ドメイン名の後に ポート 443 を含めてください。ポートを含めないことが、インストール時のユーザー エラーの一般的な原因です。

一般的な誤りの例を以下に示します。

入力された Orchestrator エンドポイント	正しい表記
aicenter.orchestrator.cloudapp.azure.com:443	✓
https://aifabric.orchestrator.cloudapp.azure.com	✗
https://23.96.154:443	✗
23.96.154:443	✗

Identity Server

UiPath Identity Server が Orchestrator エンドポイントと異なる場合にのみ、この設定が必要です。

Identity Server のアクセス トークン

これは、Orchestrator から得られる ID トークンです。このトークンを生成するには、ブラウザーで <orchestrator-address>/identity に移動します。「既定」のテナントではなく、ホスト テナントにログインしていることを確認します。以下のページが表示されます。

表示されたページに、上記のような左側のナビゲーションがない場合は、既定のテナントにログインしていることが考えられます。必ずホスト テナントにログインします。

[インストール アクセス トークン]、[トークンを生成] の順にクリックし、2 つのカード アイコンを使用してこのトークンをクリップボードにコピーします。

このトークンを ID アクセス トークンのフィールドに貼り付けます。

重要: このトークンは 1 時間で期限が切れます。問題が発生するリスクを軽減するために、トークンを生成した直後に構成をデプロイする必要があります。構成を編集し、再度デプロイする必要がある場合は、必ず新しいトークンを生成します。

プレフライトのチェック

設定ページで [Continue] をクリックします。[Preflight checks] ページが表示されます。すべてのプレフライトのチェックに適合すると、以下のようなページが表示されます。

注意を払ったうえで無視できるプレフライトのチェックは、Total Memory です。控えめに見ても、マシンのメモリには 52GB RAM 以上の容量が必要です。メモリが少ない状態でのプロビジョニングで、AI Fabric の能力がどの程度制限されるかについては、「ハードウェア要件」をご覧ください。

プレフライトのチェックをトラブルシューティングする

プレフライトのチェックで緑色のチェックマークが表示されない場合は、このガイドを使用してエラーを修正します。

プレフライトのチェック
Orchestrator のチェック	以下のことを確認します。 パス /api/auth にある Orchestrator ドメインに接続できること Web.config が正しく設定されていることを確認します。 ソリューション: Linux マシンが Orchestrator に接続できるようにネットワーク ルールが設定されていることを確認します。Web.config が手順「3. Orchestratorを構成する」で正しく設定されていることを確認します。
Identity Server のチェック	パス /identity で Identity Server に接続できることを確認します。 ソリューション: Linux マシンが Identity Server に接続できるようにネットワーク ルールが設定されていることを確認します (Identity Server が Orchestrator と異なる場合)。
Identity Server アクセス トークンの検証	アクセス トークンが有効であることを確認します。 ソリューション: Identity Server のチェックに適合した場合は、新しいトークンがあることを確認します。トークンの有効期間は 1 時間です。
Orchestrator と Identity Server のチェックが失敗し、外部 DNS がない場合	Orchestrator ドメイン名または Identity Server ドメイン名を解決できる外部 DNS がない場合は、構成ファイルのアプリケーションが別途必要です。「高度なトラブルシューティング - DNS 解決」をご覧ください。
DB チェック	以下のことを確認します。 SQL Server の接続および資格情報が有効であること DB が存在すること 各 DB の db_owner ロールがユーザーに割り当てられていること ソリューション: SQL Server がそのポートでの受信接続を許可していて、SQL Server 認証が有効であることを確認します。DB の作成と適切なロールの作成は、「2. データベースを構成する」で取り上げているスクリプトによって自動的に処理されます。
Disk Space でのチェックがすべて失敗。	Orchestrator および SQL Server のネットワーク/ファイアウォールのルールを検証済みであるにもかかわらず、接続に関連するすべてのチェックに引き続き失敗する場合、ネットワーク構成上の微妙な問題がある IP マスカレードに原因があることが考えられます。この問題は、Linux マシンと Orchestrator/SQL Server が互いに別のサブネットにある場合に多く見られます。この問題が発生する場合は、以下のコマンドを実行します。 sysctl -w net.ipv4.ip_forward=1 iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE Linux マシンでプレフライトのチェックをリトライします。

プレフライトのチェックの失敗を解決できない場合は、サポートに連絡し、サポート バンドルを送信してください。サポート バンドルの作成方法については、「高度なトラブルシューティング - サポート バンドル」をご覧ください。

アプリケーション インストーラーを実行する

すべてのプレフライトのチェックに適合した場合は Continue をクリックします。以下のページが表示されます。

このページが表示される場合は、AI Fabric アプリケーション インストーラーが実行されています。すべての構成を正しく設定すれば、20 分から 30 分以内で実行が完了します。インストールが成功したかどうかを示すログを出力するには、以下をご覧ください。

アプリケーション インストーラーをトラブルシューティングする

ヒント:

大まかにいうと、アプリケーションのインストールをユーザー自身がトラブルシューティングするには以下の手順に従います (UiPath テクニカル サポートにサポート バンドルを送信いただいてもかまいません。以下をご覧ください)。

• プロビジョニング ログを参照して、どのような問題が発生しているかを確認します。最新のプロビジョニング ログを確認するには、kubectl logs -f provision-* を実行します。
• ログでエラーを確認した後、構成を修正し、編集します。
• 構成を保存し、Go to new new version、Deploy の順にクリックして、プロビジョニングを再トリガーします。

実行中のログ

Kubernetes のコマンドライン インターフェイスを使用して、実行中のログを表示できます。これは、アプリケーション インストーラーが Kubernetes 上で動作しているためです。

Kubernetes のコマンドを実行するには、bash -l を実行して bash シェルを再度読み込みします (ターミナル セッションごとに 1 回)。

構成を変更およびデプロイするたびに、アプリケーションをインストールする新しいジョブが実行されます (最初の構成ではデプロイが自動的に実行されますが、以降の構成では構成を保存してから [デプロイ] をクリックします)。

Linux マシン上で動作しているログを参照するには、以下のコマンドを実行します。

bash -l
kubectl get pods

以下のような内容が表示されます。

aif-admin@aifabric-onprem-int0:~$ kubectl get pods
NAME                                  READY   STATUS             RESTARTS   AGE
...
...
provision-rmvfg                       0/1     Running            0          1m

出力に provision-<identifier> のような形式の名前が表示されます。実行中のアプリケーション インストーラーを表示するには、以下のコマンドを実行します。

kubectl logs -f provision-rmvfg

ここで、「rmvgf」をターミナルに表示されている識別子に置き換えます (または kubectl logs -f provision と入力して TAB キーを押すと、オートコンプリートによって識別子が入力されます)。

これにより、プロセスが終了していない場合は実行中のログが表示され、プロセスが成功または終了していればその時点でのログが表示されます。すべてのユーザーとまではいわないまでも、ほとんどのユーザーが上記のコマンドのみを使用してトラブルシューティングを実行できます。

インストールの成功

インストールが正常であれば、プレフライトのチェックに適合してから 15 分から 20 分後に以下の画面が表示されます。

この画面が表示された場合は、「手順6. インストールを検証する」に進みます。

既知の問題

プレフライトのチェック適合後にのみインストールをトリガーすることを前提とすると、AI Fabric インストーラーで発生する可能性のある既知の問題が 1 つだけあります。この場合、ログに以下の出力が表示されます。

...
Starting ai-helper deployment ...Release "ai-helper" does not exist. 
Installing it now.
Error: etcdserver: request timed outHelm installation failed for ai-helper in namespace aifabric. 
Exiting !!!onebox provisioning failed. 
Exiting !!!

これは etcdserver の断続的な問題です。<ip>:8800 の管理コンソールからインストールをリトライします。まず、Config をクリックし、新しい Identity Server トークンを貼り付けます。Continue to new version をクリックし、最後に Deploy をクリックします。

この問題は、5 回目までのインストールで解決する必要があります。同じ問題 (Error: etcdserver: request timed out) が繰り返し発生し、インストールを再度試しても解決しない場合は、サポートにご連絡のうえ、サポート バンドルを作成してください。

OOB モデルをインストールする (エアギャップを適用したモデルのみ)

エアギャップ インストールの場合は、OOB モデルを手動でダウンロードし、AI Fabric マシンに「インストール」して使用できるようにする必要があります。追加するモデルごとに、AI Fabric マシンに移動する必要がある tar ファイルがあります。AI Fabric マシンで、ファイルごとに以下のコマンドを実行します。

tar -zxvf formextractor-1.tar.gz
cd formextractor
nohup sudo ./setup.sh > formextractor.out 2>&1

ログは formextract.out ファイルで確認できます。インストールには最長で 1 時間を要することがあるので、このコマンドに nohup を使用することをお勧めします。これにより、マシンへの接続が失われることで発生する問題を回避できます。

高度なトラブルシューティング

サポート バンドルを作成する

サポート バンドルを作成するには、管理者 UI (<machine-ip>:8800) に移動し、上部のナビゲーション バーにある [トラブルシューティング] をクリックします。このボタンをクリックすると新しいサポート バンドルが生成されるので、そのバンドルをダウンロードします。サポートに連絡するときは、そのバンドル ファイル (support-bundle.tar.gz) をチケットに添付します。

DNS 解決

上述のとおり、この問題が表面化するのはプレフライトのチェックのときです。Orchestrator ドメインまたは Identity Server ドメインを解決する外部 DNS がないときに、この問題が発生することにもう一度留意してください。

この問題に対処するには (経験豊富な Linux ユーザーでも、/etc/hosts にエントリを追加するだけでは解決できません)、この DNS がクラスターで認識されるように、クラスターの構成マップを編集する必要があります。このためには、以下のコマンドを実行する必要があります。

kubectl -n kube-system edit cm coredns

vi エディターが開き、以下のようなファイルが表示されます。

apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        health
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
           ttl 30
        }
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
        }
    }
kind: ConfigMap
metadata:
  creationTimestamp: "2020-11-30T12:25:28Z"
  name: coredns
  namespace: kube-system
  resourceVersion: "17667708"
  selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
  uid: 2bde7049-eda6-46eb-b523-beb8c421085f

Corefile セクションの loadbalance の後 (19 行目) に新しいセクションとして hosts を追加する必要があります。必要な数の DNS をそこに記述し、最後に fallthrough を追加します。

apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        health
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
           ttl 30
        }
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
        hosts example.hosts orchestrator-dns.com {
          1.2.3.4 example.hosts
          5.6.7.8 orchestrator-dns.com
          fallthrough
        }
    }
kind: ConfigMap
metadata:
  creationTimestamp: "2020-11-30T12:25:28Z"
  name: coredns
  namespace: kube-system
  resourceVersion: "17667708"
  selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
  uid: 2bde7049-eda6-46eb-b523-beb8c421085f

その後で DNS が構成され、クラスター内部で動作するようになります。

注: 編集後、coredns が適切な yaml ファイルであることを確認します。インデントの設定にはタブを使用せず、スペースのみを使用します。