- 概要
- 要件
- インストール
- インストール後
- クラスターの管理
- 監視とアラート機能
- 移行とアップグレード
- 製品固有の設定
- ベスト プラクティスとメンテナンス
- トラブルシューティング
- インストール時にサービスをトラブルシューティングする方法
- クラスターをアンインストールする方法
- オフライン成果物をクリーンアップしてディスク領域を改善する方法
- Redis データをクリアする方法
- Istio ログを有効化する方法
- ログを手動でクリーンアップする方法
- sf-logs バケットに保存されている古いログをクリーンアップする方法
- AI Center のストリーミング ログを無効化する方法
- 失敗した Automation Suite インストールをデバッグする方法
- アップグレード後に古いインストーラーからイメージを削除する方法
- Longhorn のスナップショットを自動的にクリーンアップする方法
- TX チェックサム オフロードを無効化する方法
- ArgoCD のログ レベルを手動で Info に設定する方法
- 外部レジストリーのエンコードされたpull_secret_valueを生成する方法
- TLS 1.2 で弱い暗号に対処する方法
- RHEL 8.4 OS でオフライン インストールを実行できない
- バンドルのダウンロード中のエラー
- バイナリがないため、オフライン インストールが失敗する
- オフライン インストールでの証明書の問題
- Longhorn のセットアップ中に最初のインストールが失敗する
- SQL 接続文字列の検証エラー
- selinux iscsid モジュールの前提条件の確認が失敗する
- Azure ディスクが SSD としてマークされない
- 証明書の更新後のエラー
- ウイルス対策が原因でインストールの問題が発生する
- OS のアップグレード後に Automation Suite が動作しない
- Automation Suite で backlog_wait_time を 0 に設定する必要がある
- リソースが利用できないことの影響を受ける GPU ノード
- ワークロードの準備ができていないためボリュームをマウントできない
- サポート バンドルのログ収集の失敗
- 管理ポータルのタイムアウト期間を設定する
- 基になるディレクトリ接続を更新する
- 移行後に認証が機能しない
- Kinit: Cannot find KDC for realm <AD Domain> while getting initial credentials
- kinit: Keytab contains no suitable keys for *** while getting initial credentials
- 無効なステータス コードが原因で GSSAPI 操作が失敗した
- Alarm received for failed kerberos-tgt-update job
- SSPI Provider: Server not found in Kerberos database
- アカウントが無効なため AD ユーザーのログインに失敗した
- ArgoCD へのログインに失敗した
- サンドボックス イメージを取得できない
- ポッドが ArgoCD UI に表示されない
- Redis プローブの障害
- RKE2 サーバーの起動に失敗する
- UiPath 名前空間でシークレットが見つからない
- 初回インストール後に ArgoCD が進行中ステートになる
- ArgoCD の読み取り専用アカウントにアクセスする際の問題
- MongoDB ポッドが CrashLoopBackOff になるか、削除後に PVC プロビジョニングの保留中になる
- クラスターの復元またはロールバック後にサービスが異常になる
- Init:0/X でポッドがスタックする
- Prometheus が CrashloopBackoff ステートにあり、メモリ不足 (OOM) エラーを伴う
- Ceph-rook のメトリックが監視ダッシュボードに表示されない
- プロキシ環境でポッドが FQDN と通信できない
- Automation Suite 診断ツールを使用する
- Automation Suite サポート バンドル ツールを使用する
- ログを確認する
証明書を管理する
インストール プロセスによって、ユーザーに代わって自己署名証明書が生成されます。これらの証明書は FIPS に対応しており、90 日で有効期限が切れるので、インストールが完了したら速やかに、信頼された証明機関 (CA) によって署名された証明書に置き換える必要があります。証明書を更新しないと、90 日でインストールが動作を停止します。
Automation Suite を FIPS が有効化されたホストにインストールした後で証明書を更新する場合は、その証明書が FIPS に対応していることを確認してください。
インストール バンドルでは、インストール後に証明書を更新できるクラスター管理ツールを提供しています。このツールにアクセスするには、インストーラー バンドルの保存場所に移動します。
cd /opt/UiPathAutomationSuite/
cd /opt/UiPathAutomationSuite/
CSR および秘密キーを生成するには、次のコマンドを実行します。
# copy the machine openssl configuration locally
cp /etc/pki/tls/openssl.cnf ./openssl.tmp.cnf
# Replace the [AUTOMATION_SUITE_FQDN] value. For example, "automationsuite.corp.com"
AS_FQDN=[AUTOMATION_SUITE_FQDN]
cat >> ./openssl.tmp.cnf <<EOF
[SAN]
subjectAltName=DNS:$AS_FQDN,DNS:alm.$AS_FQDN,DNS:monitoring.$AS_FQDN,DNS:registry.$AS_FQDN,DNS:objectstore.$AS_FQDN,DNS:insights.$AS_FQDN
EOF
# create the certificate request
openssl req -new -sha256 -newkey rsa:2048 -nodes -keyout server.key -subj "/C=xx/ST=xx/O=xx/OU=xx/CN=$AS_FQDN" -reqexts SAN -config openssl.tmp.cnf -out ${AS_FQDN}.csr
# copy the machine openssl configuration locally
cp /etc/pki/tls/openssl.cnf ./openssl.tmp.cnf
# Replace the [AUTOMATION_SUITE_FQDN] value. For example, "automationsuite.corp.com"
AS_FQDN=[AUTOMATION_SUITE_FQDN]
cat >> ./openssl.tmp.cnf <<EOF
[SAN]
subjectAltName=DNS:$AS_FQDN,DNS:alm.$AS_FQDN,DNS:monitoring.$AS_FQDN,DNS:registry.$AS_FQDN,DNS:objectstore.$AS_FQDN,DNS:insights.$AS_FQDN
EOF
# create the certificate request
openssl req -new -sha256 -newkey rsa:2048 -nodes -keyout server.key -subj "/C=xx/ST=xx/O=xx/OU=xx/CN=$AS_FQDN" -reqexts SAN -config openssl.tmp.cnf -out ${AS_FQDN}.csr
IT チームが、取得した値を使用して署名証明書を生成します。生成された秘密キーはローカルのままです。
サーバー証明書の詳細情報を表示するには、次のコマンドを実行します。
sudo ./configureUiPathAS.sh tls-cert --help
sudo ./configureUiPathAS.sh tls-cert --help
出力:
************************************************************************************
Manage cluster tls and server certificate
Usage:
configureUiPathAS.sh tls-cert [command]
configureUiPathAS.sh tls-cert [flags]
Available Commands:
update Update the tls / server certificate
get Get the tls / server certificate
Flags:
-h|--help Display help
************************************************************************************
************************************************************************************
Manage cluster tls and server certificate
Usage:
configureUiPathAS.sh tls-cert [command]
configureUiPathAS.sh tls-cert [flags]
Available Commands:
update Update the tls / server certificate
get Get the tls / server certificate
Flags:
-h|--help Display help
************************************************************************************
./configureUiPathAS.sh tls-cert
コマンドを使用して実行できる操作について説明します。
オンライン インストール: サーバー証明書の確認方法
istio-system
名前空間内に istio-ingressgateway-certs
という名前で確認できます。
証明書ファイルについては、以下のリストをご覧ください。
- サーバー TLS 証明書は
tls.crt
として保存されます。 - サーバー TLS 秘密キーは
tls.key
として保存されます。 - CA バンドルは
ca.crt
として保存されます。
次のコマンドを使用して、シークレットを確認できます。
kubectl -n istio-system get secrets istio-ingressgateway-certs -o yaml
kubectl -n istio-system get secrets istio-ingressgateway-certs -o yaml
証明書は UiPath 名前空間にも保存されます。これは、受信呼び出しを信頼するために証明書情報を必要とするすべての UiPath® 製品に適用されます。詳細については、「証明書に関連するコンテナー アーキテクチャを理解する」をご覧ください。
オフライン インストール: サーバー証明書の確認方法
rootCA.crt
と tls.crt
を使用する場所が他に 2 つあります。ArgoCD と Docker レジストリです。証明書は、Docker と ArgoCD の両方の名前空間に保存されます。
次のコマンドを使用して、シークレットを確認できます。
# For docker registry
kubectl -n docker-registry get secrets docker-registry-tls -o yaml
# For Argocd
argocd cert list --cert-type https
# For docker registry
kubectl -n docker-registry get secrets docker-registry-tls -o yaml
# For Argocd
argocd cert list --cert-type https
サーバー証明書の更新方法
証明書キーを復号するには、次のコマンドを実行します。
# replace /path/to/encrypted/cert/key to absolute file path of key
# replace /path/to/decrypt/cert/key to store decrypt key
# Once prompted, please entry the passphrase or password to decrypt the key
openssl rsa -in /path/to/encrypted/cert/key -out /path/to/decrypt/cert/key
# replace /path/to/encrypted/cert/key to absolute file path of key
# replace /path/to/decrypt/cert/key to store decrypt key
# Once prompted, please entry the passphrase or password to decrypt the key
openssl rsa -in /path/to/encrypted/cert/key -out /path/to/decrypt/cert/key
configureUiPathAS.sh
スクリプトを実行し、証明書を更新します。3 つの証明書ファイルのそれぞれに対するパスが必要です。証明書ファイルは、いずれも PEM
形式である必要があります。
- 証明機関バンドル - このバンドルには TLS サーバー証明書への署名に使用するチェーン証明書のみを含める必要があります。チェーンの制限は最大 9 個の証明書です。
- サーバー証明書 - 公開サーバー証明書です。
-
秘密キー - サーバー証明書の秘密キーです。
sudo ./configureUiPathAS.sh tls-cert update --ca-cert-file /path/to/cacert --tls-cert-file /path/to/tlscert --tls-key-file /path/to/tlskey
sudo ./configureUiPathAS.sh tls-cert update --ca-cert-file /path/to/cacert --tls-cert-file /path/to/tlscert --tls-key-file /path/to/tlskey
/directory/path/to/store/certificate
に保存されます。
証明書ファイルを出力するには、証明書が保存されているディレクトリを指定して、次のコマンドを実行します。
sudo ./configureUiPathAS.sh tls-cert get --outpath /directory/path/to/store/certificate
sudo ./configureUiPathAS.sh tls-cert get --outpath /directory/path/to/store/certificate
生成された証明書が信頼できることを確認するのはユーザーの責任です。
証明書をホスト仮想マシンの信頼ストアに追加するには、クラスター内のすべてのノードで次のコマンドを実行します。
# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trust
# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trust
追加の CA 証明書の詳細情報を表示するには、次のコマンドを実行します。
./configureUiPathAS.sh additional-ca-certs --help
./configureUiPathAS.sh additional-ca-certs --help
出力:
***************************************************************************************
Manage additional CA certificates, this can be used to add sql server CA
Usage:
configureUiPathAS.sh additional-ca-certs [command]
configureUiPathAS.sh additional-ca-certs [flags]
Available Commands:
update Update the additional trusted CA certificates.
get Get the additional trusted CA certificates
Flags:
-h|--help Display help
***************************************************************************************
***************************************************************************************
Manage additional CA certificates, this can be used to add sql server CA
Usage:
configureUiPathAS.sh additional-ca-certs [command]
configureUiPathAS.sh additional-ca-certs [flags]
Available Commands:
update Update the additional trusted CA certificates.
get Get the additional trusted CA certificates
Flags:
-h|--help Display help
***************************************************************************************
./configureUiPathAS.sh additional-ca-certs
コマンドを使用して実行できる操作について説明します。
このコマンドにより、既存の構成済み CA 証明書を更新または置換できます。
./configureUiPathAS.sh additional-ca-certs update --ca-cert-file /path/to/ca/certs
./configureUiPathAS.sh additional-ca-certs update --ca-cert-file /path/to/ca/certs
--replace
を付加してください。
.pem
形式である必要があり、複数の証明書を含めることができます。
設定済みの CA 証明書をダウンロードするには、次のコマンドを実行します。
./configureUiPathAS.sh additional-ca-certs get --outpath /path/to/download/certs
./configureUiPathAS.sh additional-ca-certs get --outpath /path/to/download/certs
生成された証明書が信頼できることを確認するのはユーザーの責任です。
証明書をホスト仮想マシンの信頼ストアに追加するには、クラスター内のすべてのノードで次のコマンドを実行します。
# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trust
# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trust
追加の ID トークン署名証明書の詳細情報を表示するには、次のコマンドを実行します。
sudo ./configureUiPathAS.sh identity token-cert --help
sudo ./configureUiPathAS.sh identity token-cert --help
出力:
************************************************************************************
Manage Identity token signing certificate
Usage:
configureUiPathAS.sh identity token-cert [command]
configureUiPathAS.sh identity token-cert [flags]
Available Commands:
update Update secondary certificate to signing
the authentication token
rotate Switch secondary certificate as a primary
token signing certificate
get Get token signing certificate
Flags:
-h|--help Display help
************************************************************************************
************************************************************************************
Manage Identity token signing certificate
Usage:
configureUiPathAS.sh identity token-cert [command]
configureUiPathAS.sh identity token-cert [flags]
Available Commands:
update Update secondary certificate to signing
the authentication token
rotate Switch secondary certificate as a primary
token signing certificate
get Get token signing certificate
Flags:
-h|--help Display help
************************************************************************************
./configureUiPathAS.sh identity token-cert
コマンドを使用して実行できる操作について詳しく説明します。
新しい証明書をアップロードしてトークンに署名するには、次のコマンドを実行します。
次のコマンドでは、既存のトークン署名証明書は置換されません。
.pem
形式であることを確認します。
sudo ./configureUiPathAS.sh identity token-cert update --cert-file-path /path/to/cert --cert-key-file-path /path/to/certkey
sudo ./configureUiPathAS.sh identity token-cert update --cert-file-path /path/to/cert --cert-key-file-path /path/to/certkey
古い証明書をローテーションしたり、新しい証明書に置換したりするには、次のコマンドを実行します。
sudo ./configureUiPathAS.sh identity token-cert rotate
sudo ./configureUiPathAS.sh identity token-cert rotate
証明書の更新とローテーションの間には、約 24 - 48 時間のリード タイムが必要です。
このリード タイムは、キャッシュされている、古い証明書によって署名されたトークンの認証を引き続きサポートするために必要となります。
キャッシュ トークンの有効期限の満了を待たずに証明書をローテーションすると、ダウンタイムが発生する場合があります。さらに、すべてのロボットの再起動が必要になる可能性もあります。
既定では、RKE2 証明書は 12 か月で有効期限が切れます。有効期限の 90 日前に RKE2 を再起動すると、証明書がローテーションされます。
詳細については、「RKE2 - Advanced Options - Certificate rotation」をご覧ください。
# Directory path to check
if [[ -d "/var/lib/rancher/rke2/server/tls" ]];
then
dir="/var/lib/rancher/rke2/server/tls"
else
dir="/var/lib/rancher/rke2/agent/tls"
fi
# Loop through each .crt file in the directory
for file in "$dir"/*.crt;
# Extract the expiry date from the certificate
do
expiry=$(openssl x509 -enddate -noout -in "$file" | cut -d= -f 2-)
# Get the file name without the path
filename=$(basename "$file")
# Print the filename and expiry date in a pretty format
printf "%-30s %s\n" "$filename:" "$expiry"
done
# Directory path to check
if [[ -d "/var/lib/rancher/rke2/server/tls" ]];
then
dir="/var/lib/rancher/rke2/server/tls"
else
dir="/var/lib/rancher/rke2/agent/tls"
fi
# Loop through each .crt file in the directory
for file in "$dir"/*.crt;
# Extract the expiry date from the certificate
do
expiry=$(openssl x509 -enddate -noout -in "$file" | cut -d= -f 2-)
# Get the file name without the path
filename=$(basename "$file")
# Print the filename and expiry date in a pretty format
printf "%-30s %s\n" "$filename:" "$expiry"
done
得られる出力は、次の画像のようになります。
RKE2 の証明書をローテーションするには、最初にサーバー ノードで一連の操作を実行してから、エージェント ノードでいくつかの手順を続行します。
- RKE2 サーバーを停止します。
systemctl stop rke2-server.service
systemctl stop rke2-server.service - 残りの RKE2 プロセスをすべてクリアします。
rke2-killall.sh
rke2-killall.sh /var/lib/rancher/rke2/server/tls/
にあるdynamic-cert.json
ファイルを削除します。- RKE2 サーバーを再起動します。
systemctl start rke2-server.service
systemctl start rke2-server.service注: クラスターに複数のサーバー ノードがある場合、手順 1 から 4 を完全には実行できないことがあります。これは etcd がリーダーの選出を完了できないためです。この場合は、他のサーバー ノードで手順 1 から 4 を繰り返します。 kube-system
名前空間からrke2-serving
シークレットを削除します。kubectl delete secret -n kube-system rke2-serving
kubectl delete secret -n kube-system rke2-serving注:マルチノード デプロイでは、必要な数のサーバー ノードで最初の 4 つの操作を完了するまで、kubectl
コマンドを実行できない場合があります。これは、etcd クォーラム要件を満たすためです。rke2-serving
シークレットは、RKE2 サーバーが起動したらすぐに削除できます。
kubectl get nodes
コマンドが正常に実行されたことを確認できます。サーバー ノードの準備ができたら、エージェント ノードの操作に進んで証明書を再生成できます。
エージェント ノードで次の手順を実行します。
- RKE2 サーバーを停止します。
systemctl stop rke2-agent.service
systemctl stop rke2-agent.service - 残りの RKE2 プロセスをすべてクリアします。
rke2-killall.sh
rke2-killall.sh - RKE2 サーバーを再起動します。
systemctl start rke2-agent.service
systemctl start rke2-agent.service