はじめに
AAP(RedHat Ansible Automation Platform)は、RedHatが提供する Ansible Playbookを実行/管理するエンタープライズ向けプラットフォームです。Web UIでの管理/ジョブスケジューリング/外部システム連携などが可能で、これまでインフラエンジニアがPlaybookで自動化していた作業を 利用者自身で実行できる仕組みを作成できます。
AWXは、AAPの主要コンポーネントAutomation ControllerのOSS版プロダクトです。
本記事ではAWXの導入方法と初期設定について共有します。
導入方法
AWXは KubernetesのOperatorとして提供されているため、kubernetesクラスタ上へ導入する形になります。
導入手順はこちらです。
https://docs.ansible.com/projects/awx-operator/en/latest/installation/basic-install.html
※AAPは Kubernetes以外の環境にも導入可能です。導入可能な環境は以下で整理されています。
https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/tested_deployment_models/index
awx-operator導入
今回はEKS上にデプロイします。以下はすべてAWS Cloudshell上で実行します。
-
前提準備
- Cloudshell環境にeksctl・kustomiseを導入します。
$ cd /usr/local/bin $ curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C . $ eksctl version 0.224.0 $ sudo curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh" | bash v5.8.0 kustomize installed to /usr/local/bin/kustomize $ kustomize version v5.8.0- kubernetesクラスタ,名前空間を新規作成します。
$ eksctl create cluster --name <クラスタ名> --region <リージョン名> --nodegroup-name <ノードグループ名> --node-type t3.medium --nodes 2 --with-oidc $ aws eks --region <リージョン名> update-kubeconfig --name <クラスタ名> $ kubectl create namespace <名前空間名> -
前述のインストール手順の実施
- awx-operator のバージョンは
tags/2.19.1(2026/3時点最新)をcheckout
- awx-operator のバージョンは
-
手順中の不具合対応：Postgresのpod(
awx-demo-postgres...)が起動しない$ kubectl get pod NAME READY STATUS RESTARTS AGE awx-demo-postgres-15-0 0/1 Pending 0 21h awx-operator-controller-manager-... 2/2 Running 0 22h-
対応1：こちらの記事にある通りPVCがPendingになっていたため、EBS CSI Driverを導入します。
-
確認
$ kubectl describe pod awx-demo-postgres-15-0 ~略~ Warning FailedScheduling 14m (x254 over 21h) default-scheduler 0/2 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling. $ kubectl get pvc -n awx NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE postgres-15-awx-demo-postgres-15-0 Pending <unset> 23h -
対応
$ kubectl delete pvc -n awx postgres-15-awx-demo-postgres-15-0以下手順通りにCSIドライバーをインストール
https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/ebs-csi.html
https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/creating-an-add-on.html$ kubectl apply -k .
-
-
対応2：PVCバウンドができても以下のパーミッションエラーが出る場合は、こちらにある通りpostgresコンテナの初期化時のコマンドを追加します。
- 確認
$ kubectl get pod NAME READY STATUS RESTARTS AGE awx-demo-postgres-15-0 0/1 Pending 0 21h awx-operator-controller-manager-... 2/2 Running 0 22h $ kubectl get pvc -n awx NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE postgres-15-awx-demo-postgres-15-0 Bound pvc-0000000-0000-0000-0000-0000 8Gi RWO gp2 <unset> 42m $ kubectl logs awx-demo-postgres-15-0 -n awx mkdir: cannot create directory '/var/lib/pgsql/data/userdata': Permission denied - postgres_init_container_commandsを追加
awx-demo.yml
spec: service_type: nodeport postgres_storage_class: gp2 postgres_data_volume_init: true postgres_init_container_commands: | chown 26:0 /var/lib/pgsql/data chmod 700 /var/lib/pgsql/data - 反映
$ kubectl delete -k . $ kubectl apply -k .
- 確認
-
-
WebUI接続
-
今回は管理画面をポート80で公開したい要件があるため、Serviceの公開方法は LoadBalancer とします。
awx-demo.ymlspec: service_type: LoadBalancer -
kubectl apply -k .で反映します。 -
反映後のPodとServiceの稼働状況は以下の通りです。
$ kubectl get pod NAME READY STATUS RESTARTS AGE awx-demo-postgres-15-0 1/1 Running 0 21h awx-demo-task-xxxx 4/4 Running 0 21h awx-demo-web-xxxx 3/3 Running 0 21h awx-operator-controller-manager-xxxx 2/2 Running 0 21h $ $ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE awx-demo-postgres-15 ClusterIP None <none> 5432/TCP 21h awx-demo-service LoadBalancer 10.100.69.36 xxxx.ap-southeast-1.elb.amazonaws.com 80:31452/TCP 21h awx-operator-controller-manager-metrics-service ClusterIP 10.100.178.103 <none> 8443/TCP 21h -
導入は以上です。awx-demo-serviceのEXTERNAL-IPに記載されたELBのDNS名でブラウザ接続できるようになっています。
-
AWX初期設定
WebUIで必要最低限の設定をして、Playbookを実行してみます。
-
設定の全体像
※Playbook実行対象のEC2は別途用意-
Project
Playbookをどこから取得するかを定義します。今回はGitリポジトリを指定します。
-
Inventory
従来のinventoryと同じく、playbookを実行する対象ホストを定義します。 -
Credential
Projectで指定したソースへ接続するための認証情報や、playbook実行時にAWX実行コンテナから対象サーバへ接続するための認証情報を定義します。 -
Execution Environment
Ansibleを動かすコンテナイメージを定義します。まずはデフォルトのイメージAWX EEを使えば十分です。 -
Template
-
上記の各設定を束ねて、実際にどの設定でどのPlaybookを実行するかを定義します。
-
Job Templateでは1つのplaybook実行単位を定義し、Workflow Templateでは複数のJob Templateやその他ジョブをつなげてワークフローとして定義することができます。今回はJob Templateを作成します。
-
PlaybookはProjectで指定したソース上のymlファイルから選択できます。
今回指定したPlaybookの内容は以下の通りです。sample-playbook.yml--- - name: first awx test hosts: all gather_facts: false tasks: - name: ping test ansible.builtin.ping:
-
-
-
テンプレート実行
ジョブテンプレートを起動すると、以下の流れでPlaybookが実行されます。
- Projectで指定したGitリポジトリからPlaybookを取得する
- Execution Environment上でAnsibleを起動する
- Inventoryに登録したホストへ、Credentialの情報でSSH接続する
- 指定したPlaybookを実行する
WebUI上で出力が確認できます。ここまで確認できればジョブ実行は完了です。
おわりに
AWXの導入から、最低限の設定でPlaybookを実行するまでをご紹介しました。
ProjectやTemplate等の従来のAnsibleにないリソースが多くありますが、一度動かしてみると各リソースの役割が掴みやすくなると思います。
あとは必要に応じて、複数ホストのInventory管理、スケジュール実行、ワークフロー化へ広げていけます。