はじめに
今回は、AWXをKubernetes環境に移行する機会があり、その導入過程での記録や課題について共有します。
そもそも「AWXって何？」という方には、以下の記事が参考になりますのでぜひご参照ください。
背景
Ansible Playbookのコード管理はできていたものの、AWX自体の管理や運用にいくつかの課題がありました。 具体的には以下のような問題点がありました。
- リソースの効率的な利用が難しい
- AWX自体のデプロイ管理が手動で非効率
- ダウンタイムが発生しやすい
これらを解決するために、AWXをKubernetes環境で運用することを検討しました。Kubernetesを利用することで、以下のメリットが期待できます。
- リソース利用の効率化
- AWX自体のデプロイ管理の自動化
- ダウンタイムの最小化
なお、AWXのインストール方法として、現在ではAWX Operatorの使用が推奨されています。
詳細は以下のURLを参照してください。
AWX Operatorを導入
AWX Operatorの導入手順は公式ドキュメントで詳しく説明されています。
ここでは、私が実際に行った手順と注意点について記載します。
まずは、事前準備として、awxというNameSpaceを作成しました。
kubectl create namespace awx
次に、以下のkustomizationファイルを定義し、Kubernetesクラスターに適用しました。
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
# 最新のリリースタグはこちらから確認: https://github.com/ansible/awx-operator/releases
- github.com/ansible/awx-operator/config/default?ref=2.10.0
# 使用するイメージタグを指定
images:
- name: quay.io/ansible/awx-operator
newTag: 2.10.0
# AWXをインストールするNamespaceを指定
namespace: awx
適用コマンド：
kubectl apply -k .
今回はバージョン2.10を使用しました。
ただし、最近のバージョン（例えば2.11や2.12）では、PostgreSQLの管理方法やバージョンが変更されている可能性があるため、導入前にリリースノートを確認することをお勧めします。
導入時のハマりポイント
基本的な導入手順ではAWX Operatorを簡単にインストールできましたが、AWXインスタンス起動時にいくつか問題が発生しました。特に以下の問題が顕著でした。
問題点：PVCがPending状態に
特に、PVC（PersistentVolumeClaim）とPV（PersistentVolume）のBindがうまくいかず、PodがPending状態となる問題がありました。
AWXのデータストレージ用に割り当てるべきPVC（PersistentVolumeClaim）がPending状態となり、PV（PersistentVolume）のバインドが失敗しました。
調査の結果、以下のようにPVが自動作成されないことが原因で、PVCが満たされない状態になっていました。
解決策：EBS CSI Driverの導入
EKS環境では、EBSベースの動的プロビジョニングを利用することが推奨されています。これには、EBS CSI Driverを導入する必要があります。
実際に、検証用の一時的なEKSクラスタであったので、以下のコマンドで確認したところ、EBS CSI Driverがインストールされていないことがわかりました。
aws eks list-addons --cluster-name
公式ガイドを参考に、EBS CSI Driverをインストールしました。
AWXインスタンスの起動確認
EBS CSI Driverを導入後、AWX Operatorによって以下の4つのPodが正常に起動しました。
| Pod名 | 役割・詳細 |
|---|---|
awx-demo-postgres-13-0 |
PostgreSQLデータベースのPod。ユーザーデータや設定、ジョブの履歴などを格納。 |
awx-demo-task |
AWXのタスクを実行するPod。ジョブの実行、Playbookの適用など、実際のAnsibleのタスクを処理。 |
awx-demo-web |
AWXのウェブインターフェースを提供するPod。AWXのユーザーインターフェースやAPIへのアクセスを提供。 |
awx-operator-controller-manager |
AWX OperatorのコントローラーマネージャーPod。AWXのインストール、アップデート、設定を管理するKubernetesオペレーターの一部。 |
これらのServiceはNodePortで公開される設定がデフォルトです。
今回はdemo環境での動作確認のため、以下のコマンドでPort Forwardを使用し、ローカルマシンからAWXのWebコンソールにアクセスしました。
kubectl port-forward --namespace awx deployment/awx-demo-web 8052
管理ユーザー名はadminで、パスワードは以下のコマンドで確認できます。
kubectl get secret -n awx awx-demo-admin-password -o jsonpath="{.data.password}" | base64 --decode ; echo
コンソールにログインし、AWXの画面が表示されることを確認しました。
まとめ
AWX Operatorの導入は比較的容易に行えますが、運用面やアクセス管理については慎重に検討する必要があります。
特に、Serviceの公開種別については、環境やセキュリティ要件に応じた最適な方法を選択することが重要です。
以下の表では、AWXの管理WEBコンソールにアクセスするための3つの公開方法を比較しています。
それぞれの方法には特徴があり、組織の運用方針やセキュリティポリシーに応じて選択する必要があります。
| 公開方法 | 接続種別 | 詳細 |
|---|---|---|
| NodePort | プライベート | KubernetesのNodePortサービスを使用して、AWXの管理WEBコンソールのPodを公開する。 実装が容易だが、Node移動によりIPが変わるため管理が煩雑化するのでノード・IP固定化が必須。 |
| LoadBalancer | プライベート or パブリック | LoadBalancerサービスを使用して、内部 or パブリックALB経由で接続する。 実装と管理が容易で、内部接続が可能でありセキュリティ保護に優れる。 |
| Ingress Gateway | パブリック | Istio Ingress Gatewayを設定し、外部からのトラフィックをAWXへルーティングする。 パブリック接続が可能な構成。 ドメイン管理が可能で、SSO認証の実現ができる。 |
これらの公開方法は、運用の現場においてセキュリティと利便性のバランスを考慮しながら選択する必要があります。
たとえば、NodePortは設定が簡単である一方で、IP管理が煩雑になる可能性があり、固定IPの設定が必須となります。
一方、LoadBalancerはより簡便でセキュリティに優れた方法ですが、パブリックALBを使用する場合はネットワークセキュリティにも注意が必要です。
さらに、Ingress Gatewayを使用すると、ドメイン管理やSSOの実装が可能となり、外部からのアクセスを柔軟に制御できます。
最後に
AWX Operatorには多くの設定オプションがあり、運用に合わせたカスタマイズが可能です。
本記事では基礎的な導入手順をご紹介しましたが、今後は以下のようなトピックについても記事を公開していく予定です。
-
SSOを活用したアクセス管理の最適化
AWXのWebコンソールへのアクセスをSSO（シングルサインオン）で統一することで、利便性とセキュリティを両立する方法について解説します。 -
awxkitを使ったジョブテンプレート管理の効率化
CLIツールであるawxkitを利用し、ジョブテンプレートの作成や更新を効率的に管理する方法を紹介します。
引き続き、AWX Operatorの活用を進める中で得た知見やノウハウを共有していきます。
皆さんの運用に少しでも役立つ情報をお届けできれば幸いです！
参考資料
以下に、今回の導入に関連する参考資料をまとめます。