CNE AWS Ready: トラブルシューティング
Liferay Cloud Native Experience (CNE) の導入には、AWS インフラストラクチャ、Kubernetes、GitOps ワークフロー、Terraform 構成など、複数のコンポーネントが含まれます。 リソースに一貫性がなくなったり、想定されるワークフロー以外で変更されたりすると、問題が発生する可能性があります。
以下は、CNE AWS Ready環境のデプロイまたは管理において発生する可能性のある一般的な問題の解決方法です。
AWSリソースを手動で削除した後にTerraformで発生するエラー
Terraformなどのインフラストラクチャ・アズ・コード(IaC)ツールで管理されるインフラストラクチャは、それが作成するリソースの 真実のソースおよび制御 であり続けるべきです。 AWSコンソールでリソースが手動で変更または削除されると、IaCの状態が実際のインフラストラクチャと一致しなくなります。
この場合、Terraformはそれらのリソースが存在することを前提としているため、失敗する可能性があります。
例えば、EKSクラスターを手動で削除した場合、Terraformは次のようなエラーを返す可能性があります。
Error: Get "http://localhost/apis/storage.k8s.io/v1/storageclasses/gp3": dial tcp [::1]:80: connect: connection refused
with kubernetes_storage_class_v1.gp3_storage_class,
on eks.tf line 203, in resource "kubernetes_storage_class_v1" "gp3_storage_class":
203: resource "kubernetes_storage_class_v1" "gp3_storage_class"
...
これは、Terraformの状態に、既に存在しないKubernetesリソースへの参照が残っているために発生します。
- EKS Terraformディレクトリに移動します。
cd liferay-cne-bootstrap/cloud/terraform/aws/eks
- AWSで認証する:
aws sso login
- インフラを破壊しようとする試み:
terraform destroy -var-file="../../../cloud/scripts/global_terraform.tfvars"
コマンドが正常に実行されれば、問題は解決します。
- コマンドが失敗した場合は、Terraform が Kubernetes リソースを追跡しているかどうかを確認してください。
terraform state list | grep kubernetes
- リソースが表示された場合は、Terraform ステートから削除してください。
terraform state rm [resource_name]
- 以下のディレクトリでも同じ手順を繰り返してください。
bootstrap/cloud/terraform/aws/gitops/platform
bootstrap/cloud/terraform/aws/gitops/resources
無効な状態エントリを削除した後、Terraformは正常に完了するはずです。
Grafanaワークスペースのプロビジョニングが失敗します
ブートストラップの実行中に、AWS Managed Grafana (AMG) のプロビジョニングが次のようなエラーで失敗することがあります。
Error: creating Grafana Workspace: operation error grafana: CreateWorkspace, ...
lookup grafana.<region>.amazonaws.com ... no such host
これは断続的に発生する問題であり、選択したAWSリージョンによって異なる場合があります。
-
ブートストラップスクリプトを再実行してください。
./cloud/scripts/setup_aws.sh ./config.json ./cloud/scripts/versions_aws.tfvars -
問題が解決しない場合は、設定で可観測性を無効にしてください。
"observability_config": { "enabled": false }
可観測性を無効にすると、Grafanaのプロビジョニングがスキップされ、ブートストラッププロセスが完了します。
Bootstrapスクリプトには2つの引数が必要です
ブートストラップスクリプト の最新バージョンでは、2 つの引数が必要です。
次のようなエラーが表示された場合:
Usage: ./setup_aws.sh <configuration-json-file> <versions-tfvars-file>
必要な両方のファイルを指定してスクリプトを実行してください。
./cloud/scripts/setup_aws.sh ./config.json ./cloud/scripts/versions_aws.tfvars
config.jsonはデプロイメント構成を定義します。versions_aws.tfvarsはインフラストラクチャ コンポーネントのバージョンを定義します。
障害発生後の部分的なインフラストラクチャプロビジョニング
ブートストラップ プロセス が失敗した場合でも、一部の AWS リソースは作成される可能性があります。
これにより、
- 未完成のインフラ
- Terraformの状態の不整合
- その後のブートストラップの失敗
-
プロビジョニングを再開するには、ブートストラップスクリプトを再実行してください。
./cloud/scripts/setup_aws.sh ./config.json ./cloud/scripts/versions_aws.tfvars -
問題が解決しない場合は、 環境をクリーンアップしてから 再試行してください。
Argo CD にアクセスできません
http://localhost:8080で Argo CD にアクセスできない場合は、 ブートストラップ プロセス が正常に完了していない可能性があります。
Argo CD は、
- インフラストラクチャのプロビジョニングが完了しました
- Kubernetesリソースがデプロイされます
- GitOpsの同期が完了しました
-
ブートストラップスクリプトがエラーなく完了したことを確認してください。
-
スクリプトの実行に失敗した場合は、エラーを解決してからブートストラップ処理を再実行してください。
OpenSearch Initコンテナの失敗後、Liferay PodがNotReady状態のままになる
ブートストラップの後、 liferay-install-opensearch-modules init コンテナが失敗するため、CNE AWS Ready クラスター内の Liferay ポッドが NotReady 状態のままになることがあります。
initコンテナは、Pod起動時にパブリックミラーからOpenSearchコネクタモジュールをダウンロードします。 以下のいずれかの条件に該当する場合、失敗します。
- ミラーにアクセスできません(ネットワークポリシーまたはエアギャップ環境による)。
- DXPイメージバージョンには、対応するOpenSearchコネクタが公開されていません。
- ダウンロードURLがブロックされているか、設定が間違っています。
いずれの場合も、コンテナは次のようなエラーをログに記録します。
Unable to download OpenSearch modules for product version [version] from [url].
OpenSearch モジュールなしで Liferay を起動するには、override liferay.yaml で init コンテナを無効にします。 コンテナは x-liferay-install-opensearch-modules としてキー付けされ、 customInitContainers の下にあります。
liferay-default:
customInitContainers:
x-liferay-install-opensearch-modules: null
initコンテナをスキップすると、LiferayはイメージにバンドルされているサイドカーElasticsearchにフォールバックします。 Liferayは、開発環境でのみサイドカーをサポートしており、本番環境ではサポートしていません。 Sidecar または組み込み Elasticsearch の使用 を参照してください。
このオプトアウトは一時的な措置です。 サポートされている本番環境の検索エンジンについては、Elasticsearch をデプロイしてください。 Elasticsearch の使用 を参照してください。