移行後の手順

移行後の手順は必須であり、以下のとおりです。

手順 1: シークレットと Identity Server の構成を更新する

以前に保存された ID 構成データで ID アプリケーション シークレットを更新する

次の手順を実行します。

1. kubectl edit secret platform-service-secrets -n uipath を実行し、Base64 でエンコードされた値を使用して identity.sqlConnectionString、identity.hostAdminUsername、identity.hostAdminPassword を更新します。
2. 「ID トークン署名証明書を管理する」に記載された手順を実行します。
3. SAML を使用している場合は、kubectl edit secret identity-saml-certificates -n uipath を実行し、復号された秘密キーを使用して current.saml2.pfx と future.saml2.pfx を、Base64 でエンコードされた値を使用して currentCertPassword と futureCertPassword を更新します。
4. Kerberos を使用している場合は、kubectl edit secret krb5-keytab -n uipath を実行し、krb5.keytab の値を更新します。

古い ID キャッシュ キーを削除する

次の手順を実行します。

1. kubectl --kubeconfig <directory of SF cluster yaml file> get secrets/redb-redis-cluster-db -n uipath --template '{{ .data.password }}' を実行して Redis のパスワードを取得します。Base64 の値をデコードします。
2. kubectl --kubeconfig <directory of SF cluster yaml file> get secrets/redb-redis-cluster-db -n uipath --template '{{ .data.port }}' を実行して Redis のポートを取得します。Base64 の値をデコードします。
3. kubectl  --kubeconfig <directory of SF cluster yaml file>  exec -i -t -n redis-system redis-cluster-0 -c redis-enterprise-node "--" sh -c "clear; (bash || ash || sh)" を実行して Redis のノードに入ります。
4. 前のコマンドで取得したポートとパスワードを使用して redis-cli -p <Port number> -a <Password> --scan --pattern is:* | xargs redis-cli -p <Port number> -a <Password> del を実行し、古いキーを削除します。
5. exit を実行して処理を抜けます。

Identity Server DataMigrator CLI を実行する

以下のパラメーターを使用して、ドメインに参加しているマシンから Identity Server DataMigration を実行します。移行ツールの実行可能ファイルは、Orchestrator のインストール フォルダー内にあります。例: C:\Program Files (x86)\UiPath\Orchestrator\Identity\Tools\DataMigrator.Cli

• .\UiPath.DataMigrator.Cli.exe kube-migrate -d <identity.sqlConnectionString for the k8s env>

  移行ツール コマンドの実行後に、identity-service-api を再起動します。

手順 2: テナントをスタンドアロンのインストールから Automation Suite にリンクする

(Linux 用)

前提条件

MSIToAutomationSuiteTenantMigrator ツールには、.NET 6.0 以降が必要です。.NET 6.0 以降が存在しない場合は、MSIToAutomationSuiteTenantMigrator ツールを使用する前に、Linux 用の .NET ランタイムをダウンロードしてインストールしてください。

RHEL に .NET ランタイム 3.1 をインストールするには、次のコマンドを実行します。 sudo yum install dotnet-sdk-6.0 -y

ツールをダウンロードする

MSIToAutomationSuiteTenantMigrator ツールは、こちらからダウンロードできます。

ツールを実行する

注: シェルの種類が異なる場合は、必ず一般的なエスケープ手順に従ってください。Bash では、特殊文字の前に \ を追加します。

テナントをスタンドアロンのインストールから Automation Suite にリンクするには、以下を実行します。

./MSIToAutomationSuiteTenantMigrator -s '<Orchestrator DB connection string (the one cloned from the standalone installation server)>' -p '<Platform DB connection string (Automation Suite)>' -t '<List of tenant names separated by comma, e.g. orchTenant1,orchTenant2>'

(Windows 用)

前提条件

MSIToAutomationSuiteTenantMigrator ツールには、.NET 6.0 以降が必要です。.NET ランタイム 6.0 以降が存在しない場合は、MSIToAutomationSuiteTenantMigrator ツールを使用する前に、Windows 用の .NET ランタイム 6.0.3 をダウンロードしてインストールしてください。

ツールをダウンロードする

MSIToAutomationSuiteTenantMigrator ツールは、こちらからダウンロードできます。

ツールを実行する

注: MSIToAutomationSuiteTenantMigrator ツールを正常に実行するには、SQL パスワードに特殊文字が含まれている場合、エスケープする必要があります。そのためには、すべての $ を `$ に置き換えます。

テナントをスタンドアロンのインストールから Automation Suite にリンクするには、以下を実行します。

MSIToAutomationSuiteTenantMigrator.exe -s "<Orchestrator DB connection string (the one cloned from the standalone installation server)>" -p "<Platform DB connection string (Automation Suite)>" -t "<List of tenant names separated by comma, e.g. orchTenant1,orchTenant2>"

SMTP 構成情報を更新する

ホスト用と、(必要に応じて) ホストと異なる SMTP 設定を使用する組織用に SMTP を構成します。

注: 既定の資格情報は使用できなくなるため、送信者のメール アカウントのユーザー名とパスワードを指定する必要があります。また、有効な TLS 証明書も必要です。ない場合は、接続をテストしようとしても、SMTP 接続が正常に動作しません。

手順 3: Active Directory との連携と認証を更新する

Active Directory との連携を構成する場合は、「SSO を構成する: Active Directory」をご覧ください。

スタンドアロン デプロイで Active Directory との連携と認証が有効化されている場合は、Automation Suite クラスターで次の手順を実行します。

• ドメイン コントローラーが Automation Suite クラスターで検出可能であることを確認します。検出可能でない場合は、Kube の DNS 構成を使用します。
• keytab ファイルを使用して、統合 Windows 認証と Kerberos 認証を構成します。
• ホスト管理者の下でポータルを経由して LDAP 連携を構成します。
• ホスト管理者の下でポータルを経由して Windows 認証を構成します。

• LDAP に安全に接続できるように LDAPS を構成します。

  注: LDAP 連携の構成に使用されるアカウントには、現在のフォレストと信頼できるフォレスト内の信頼できるすべてのドメインに対する読み取りアクセス権のみが必要です。

手順 4: Orchestrator の構成を更新する

Orchestrator の構成を更新します。以下を確認してください。

• UiPath.Orchestrator.dll.config のカスタム構成
• すべての web.config 設定
• ストレージ (パッケージ、実行メディア、バケット データ) - ほとんどが Storage.Type=FileSystem に適用可能
• カスタムの NLog ターゲット
• カスタムの資格情報ストア
• テナント構成ごとの暗号化キー

提供されている Orchestrator 構成ツールを使用することによって、以下の手順の多くを簡略化できます。

orchestrator_configurator.sh bash ツールでは Orchestrator のカスタム構成マップを更新し、Orchestrator の既知の BLOB ストレージの場所にファイルをアップロードできます。提案されたアクションの確認をスキップするには、-y パラメーターを使用します。

web.config を構成する

レンズや kubectl などのツールを使用して、orchestrator-customconfig 構成マップを編集します。

values.json ファイル内で要求の制限を設定します。この設定を変更すると、Orchestrator のデプロイが自動的に再実行されます。

{
  "Kestrel": {
    "Limits": {
      "MaxRequestBodySize": 314572800
    }
  }

アプリの設定を構成する

移行前の手順で編集した appSettings.custom.json ファイルに、appSettings セクションで必要なすべてのカスタマイズが含まれます。orchestrator-customconfig 構成マップ内のこの .json ファイルを、values.json ファイルの appSettings キーの下に配置する必要があります。

{
    "ExampleSetting.Enabled": true,
    "ExampleSetting.Type": "BasicExample",
    "ExampleSetting.Count": 3
}

Orchestrator 構成ツールは、カスタム appSettings 内のキーを構成マップ内に既に存在するキーとマージできます。-c|--app-settings パラメーターを使用してアプリの設定をアップロードできます。

./orchestrator-configurator.sh -c appSettings.custom.json

構成ツールを使用している場合は、すべての手順を実行して必要な appSettings の上書きをすべて集め、最後に 1 回スクリプトを実行します。

ストレージを構成する

ローカルの FileStore を使用しており、既存のストレージ コンテンツを Orchestrator にアップロードする必要がある場合は、/var/orchestator/data パスの任意の Orchestrator ポッドにそれらのコンテンツを配置してください。

Orchestrator 構成ツールでは、kubectl cp で -s|--storage-folder パラメーターを使用してファイルをアップロードできます。

./orchestrator-configurator.sh -s blobstoragefolder

スクリプトを実行すると、storage フォルダーの内容が /var/orchestrator/data フォルダーの内容になります。

ネットワーク FileStore を使用するには、Orchestrator ArgoCD アプリのパラメーターを編集し、以下を設定します。

• storage.type = smb
• storage.smb.domain
• storage.smb.password
• storage.smb.source
• storage.smb.username
• storage.smb.size

他のストレージ オプションを構成するには、Orchestrator ArgoCD アプリのパラメーターを編集し、以下を設定します。

• 目的のプロバイダー (Azure、AWS、Minio) に対する storage.type
• storage.connectionString

Orchestrator アプリのストレージ設定の概要:

Azure/Amazon S3 のストレージ バケット

Orchestrator による Amazon や Azure のストレージ バケットへの Web ブラウザー アクセスは、プロバイダー側の同一オリジン ポリシーにより制限される可能性があります。このようなバケットのコンテンツに正常にアクセスするには、Orchestrator からのクロス オリジン要求を許可するように各プロバイダーを設定する必要があります。

Orchestrator からのクロス オリジン要求を許可するように各プロバイダーを構成する方法については、こちらをご覧ください。

NLog を構成する

NLog 拡張機能をインストールするには、uipath バケット内の Ceph にこれらをコピーする必要があります。これで、起動時に Orchestrator ポッドがこれらを読み込むようになります。また、nlog.json ファイルの orchestrator-customconfig に構成を配置することも必要です。

構成ツールでこれを実行するには、-n|--nlog-extensions-folder パラメーターと -l|--nlog-config-file パラメーターを使用します。

./orchestrator-configurator.sh -n nlogextensions -l nlog.custom.json

プラグインは、ローカル パス /var/orchestrator/plugins/nlog にある Orchestrator ポッドで入手できます。構成ツールによって assemblyFile のパスが自動的に更新され、そのパスの先頭にプラグインのパスが付加されます。

資格情報ストアを構成する

資格情報ストアの構成変更は appsettings.custom.json に含まれているため、構成の更新は必要ありません。

手動で変更を加えるには、appSettings セクションにある orchestrator-customconfig の values.json ファイル内にこれらを配置します。

Secure Store のアセンブリも必要な場合は、/var/orchestrator/plugins/securestore/ パスにある任意の Orchestrator ポッド内にそれらを配置する必要があります。

これは、Orchestrator 構成ツールで、-p|--securestore-plugins-folder パラメーターを使用して実行できます。

./orchestrator-configurator.sh -p securestoreplugins

暗号化キーを構成する

暗号化キーを設定するには、APPSETTINGS__EncryptionKey の値を上書きして、暗号化キーを Kubernetes シークレット orchestrator-generated-secrets 内で置き換えます。

テナントごとに暗号化キーを構成する

テナントごとに暗号化キーを移行するには、次の手順を実行します。

1. Orchestrator アプリケーションのパラメーターの上書きとして、AzureKeyVault の設定と証明書を ArgoCD UI に追加します。
   • encryptionKeyPerTenant.certificateBase64
   • encryptionKeyPerTenant.certificatePassword
   • encryptionKeyPerTenant.clientId
   • encryptionKeyPerTenant.directoryId
   • encryptionKeyPerTenant.vaultAddress
   1. a次の構成キーの値を使用します (準備の手順を参照)。
      • Azure.KeyVault.VaultAddress
      • Azure.KeyVault.ClientId

      • Azure.KeyVault.DirectoryId

   2. 証明書を Base64 に変換し、これをパラメーターの上書きとして使用します。証明書を変換するには、以下のコマンドを使用します。

      PowerShell:

      [convert]::ToBase64String((Get-Content -path "path_to_certificate" -Encoding byte))

      Shell:

      base64 [_path_to_certificate_]

2. Orchestrator ArgoCD アプリケーションのパラメーターの上書きを適用し、Orchestrator 構成ツールを実行します。
3. ArgoCD に新しい構成が反映されたら、アプリケーションが再度同期されるまで待ちます。
4. 次のように、EncryptionKeyPerTenant 機能を有効化します。
   • appSettings.custom.json に配置された 2 つの設定を使用し、Orchestrator 構成ツールを実行します。
   • または、values.json ファイルの appConfig セクションの orchestrator-customconfig で、手動で有効化します。

   "EncryptionKeyPerTenant.Enabled": "true", "EncryptionKeyPerTenant.KeyProvider": "AzureKeyVault",

5. 変更を反映するために、クラスターから Orchestrator Automation Suite のデプロイを再実行します。
   注: Identity Server の SMTP 設定は、テナントごとのキーで暗号化されません。移行が完了したら、Automation Suite ポータルで必ず SMTP パスワードを再入力してください。

手順 5: Cluster_config.json を再作成する

移行を完了するには、cluster_config.json ファイルを再作成する必要があります。これにより、ArgoCD を介して加えたすべての変更が Automation Suite 構成ファイルに正しく確実に保存されます。

cluster_config.json を再作成するには、次のコマンドを実行します。

./configureUiPathAS.sh config get -i /path/to/old/cluster_config.json -o ./cluster_config.json

この手順の一部として、create_db を手動で false に設定する必要もあります。この操作を行わないと、インストーラーが SQL 接続文字列を上書きできず、クラスターの最新ステートを保持できません。

重要:

この段階では、cluster_config.json を介して Kerberos 認証を構成しないでください。この操作にはインストーラーの実行が必要ですが、実行すると SQL 接続文字列に加えた変更が元に戻ります。

Kerberos 認証を構成する別のオプションについて詳しくは、「Automation Suite を Kerberos クライアントとして構成する」をご覧ください。

手順 6: ロボットを再接続する

Automation Suite 内の Orchestrator にロボットを再接続します。