--- title: "Ansible AWXとは：AWX OperatorでKubernetesへ導入する手順とAAPとの違い【2.19.1】" url: "https://www.issoh.co.jp/tech/details/18461/" published: 2026-10-17 updated: 2026-10-17 categories: ["自動化"] publisher: "株式会社一創" --- # Ansible AWXとは：AWX OperatorでKubernetesへ導入する手順とAAPとの違い【2.19.1】 AWXは、Ansibleの実行をWeb画面とREST APIから管理できる無償のオープンソースです。Red Hat Ansible Automation Platform（AAP）に含まれるautomation controller（旧Ansible Tower）の上流に位置するプロジェクトです。この記事では、2024年7月から続くリリース停止の現状を確認したうえで、AWX Operator 2.19.1をkustomizeでKubernetesへ導入する手順を、設定ファイルの記述例と実行コマンドを添えて解説します。外部PostgreSQLの接続、AWXBackupでの退避、本番で使うかAAPを選ぶかの判断まで扱います。 ## まとめ｜AWXは検証用に無償で動くがリリース停止中で本番は条件付き AWXを試すだけなら、Kubernetesクラスタとkubectlがあれば、YAML 2つとコマンド数行で画面にログインできます。導入手段はAWX Operatorが公式の推奨で、Operatorの最新は2024年7月2日公開の2.19.1です。Helmチャートはコミュニティのリポジトリへ移り、OperatorHubからは外れました。 本番で使うなら、外部PostgreSQLとAWXBackupの定期取得を最初から組み込んでください。セキュリティ修正の新版が出ない状態を自社で引き受けられるかが、AWXを選ぶかAAPを契約するかの分かれ目です。監査や24時間の問い合わせ窓口が要件なら、AWXは選びません。 ## Ansible AWXの役割とTower・AAPとの関係、2024年7月からのリリース停止 AWXの位置づけを押さえておくと、古い解説記事と現在の状況を読み分けられます。 ### AWXと旧Tower・controllerの違いは機能でなく保守の主体 Ansible本体はコマンドラインでPlaybookを実行する道具です。AWXはその上に、ジョブテンプレート、スケジュール、権限管理、実行履歴、REST APIを載せます。「ansible tower oss」と検索されるとおり、Towerのオープンソース版と考えて差し支えありません。 | 観点 | AWX | controller（旧Tower） | | -------- | ------ | ------------------ | | 費用 | 無償 | AAPの年額契約 | | 提供元 | コミュニティ | Red Hat | | サポート | なし | 24時間365日 | | 版ごとの保守期間 | 公表なし | 最低18か月 | サポートと保守期間の値は、Red Hatの[AAPとコミュニティ版の比較ページ](https://www.redhat.com/ja/technologies/management/ansible/compare-awx-vs-ansible-automation-platform)によるものです。機能の多くは共通なので、ジョブテンプレートやSurveyの設定方法は[Ansible Towerの機能と設定手順](https://www.issoh.co.jp/tech/details/18459/)がそのままAWXにも当てはまります。違いは機能より、誰が不具合と脆弱性に責任を持つかにあります。 ### 最終リリース24.6.1とOperator 2.19.1で止まった開発の現状 [AWXのGitHubリポジトリ](https://github.com/ansible/awx)の冒頭には、最終リリースが2024年7月2日であること、大規模なリファクタリングの間はリリースを停止することが明記されています。2026年10月時点でも最新は24.6.1のままで、GitHub APIで確認した[AWX Operatorのリリース](https://github.com/ansible/awx-operator/releases)も同じ日の2.19.1が最後です。 開発そのものは止まっていません。リポジトリへのコミットは2026年10月にも続いています。ただし利用者が入れられる正式版は2年以上前のものだけです。依存するPythonライブラリやコンテナイメージに脆弱性が見つかっても、修正版のAWXは出てきません。この点を理解したうえで導入手順に進んでください。 ## AWX Operator導入用Kubernetesとkustomizeの前提条件 AWXの[インストールガイド](https://github.com/ansible/awx/blob/devel/INSTALL.md)は、バージョン18.0以降の推奨手段をAWX Operatorとしています。Docker上でも動かせますが、開発やテスト向けで公式のリリースは無いと書かれています。 ### クラスタ・kubectl 1.14以降・StorageClassの3点を確認 Operatorの[基本インストール手順](https://docs.ansible.com/projects/awx-operator/en/latest/installation/basic-install.html)が前提にするのは、稼働中のKubernetesクラスタと、kustomizeを内蔵したkubectl（1.14以降）です。検証ならMinikubeやKindでも構いません。 見落としやすいのは永続ボリュームです。Operatorが立てるPostgreSQLは、指定が無ければクラスタ既定のStorageClassで8GiBのボリュームを要求します。既定のStorageClassが無いクラスタではデータベースのPodが起動せず、AWX全体が待ち状態のまま止まります。導入前に`kubectl get storageclass`で「(default)」の付いた行があるか見ておきましょう。Kubernetesそのものの仕組みは[Kubernetesとは](https://www.issoh.co.jp/tech/details/2928/)で解説しています。 ### Helmチャートの移管とOperatorHub掲載終了で変わった入れ方 2024年8月2日、Ansibleの[フォーラムでOperatorの導入方法の変更](https://forum.ansible.com/t/upcoming-changes-to-awx-operator-installation-methods/7598)が告知されました。OperatorHubへの掲載は終わり、Helmチャートのコードはansible-community組織の新しいリポジトリへ移っています。kustomizeと`make deploy`は引き続き使えると明言されました。 移管先の[awx-operator-helm](https://github.com/ansible-community/awx-operator-helm)はライセンスがGPL-3.0で、チャートの最新は2026年3月12日の3.2.1です。古い記事にある`ansible.github.io/awx-operator`をHelmのリポジトリに登録しても更新は届きません。どちらでも入れられますが、公式手順と同じ形で版を固定できるkustomizeを本記事では使います。 ## kustomizeでAWX Operator 2.19.1をKubernetesへ導入 作業用のディレクトリを1つ作り、その中にYAMLを2つ置いて`kubectl apply -k`を2回実行する流れです。 ### kustomization.yamlの作成とawx名前空間へのOperatorのデプロイ まずOperatorだけを入れます。`ref`と`newTag`には同じ版を書いてください。食い違うと、Operatorのイメージが取得できずImagePullBackOffで止まります。 ``` # kustomization.yaml apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - github.com/ansible/awx-operator/config/default?ref=2.19.1 images: - name: quay.io/ansible/awx-operator newTag: 2.19.1 namespace: awx ``` 同じディレクトリで次を実行し、Operatorが動いているかを確かめます。 ``` kubectl apply -k . kubectl get pods -n awx kubectl config set-context --current --namespace=awx ``` `awx-operator-controller-manager`で始まるPodがRunningになれば準備完了です。最後の1行で既定の名前空間をawxに切り替えておくと、以降のコマンドで`-n awx`を省けます。 ### AWXカスタムリソースの作成とadminパスワードの取り出し 次に、AWX本体の定義を`awx-demo.yml`として書きます。`metadata.name`がそのままデプロイ名になり、Serviceや Secretの名前の頭に付きます。 ``` --- apiVersion: awx.ansible.com/v1beta1 kind: AWX metadata: name: awx-demo spec: service_type: nodeport ``` `kustomization.yaml`の`resources`に`- awx-demo.yml`を1行足し、もう一度`kubectl apply -k .`を実行します。進み具合は次のコマンドで追えます。 ``` kubectl logs -f deployments/awx-operator-controller-manager -c awx-manager kubectl get svc awx-demo-service kubectl get secret awx-demo-admin-password -o jsonpath="{.data.password}" | base64 --decode ; echo ``` 2行目でNodePortの番号を確かめ、ブラウザで`http://<ノードのIP>:/`を開きます。ユーザー名は`admin`、パスワードは3行目の出力です。Secret名は「デプロイ名-admin-password」の規則で決まるため、名前を変えたらここも合わせます。OpenShiftでは`service_type: clusterip`と`ingress_type: Route`に変えるとRouteが自動で作られます。 ログイン後の操作は、プロジェクトにGitリポジトリを登録し、インベントリと認証情報を作ってからジョブテンプレートを作る順になります。登録するPlaybookの書き方は[Ansible Playbookの書き方と実行手順](https://www.issoh.co.jp/tech/details/18457/)を参照してください。 ## 本番運用で決めておく外部PostgreSQLの接続とAWXBackupによる退避 デモの手順のままでは、データベースもバックアップもクラスタの中だけにあります。実行履歴や認証情報を失ってよい検証環境以外では、次の2つを先に決めます。 ### 外部PostgreSQLを使うSecretの書き方と既定のPostgreSQL 15 Operatorの[データベース設定の文書](https://github.com/ansible/awx-operator/blob/devel/docs/user-guide/database-configuration.md)によると、既定ではOperatorがPostgreSQL 15をAWXと同じ名前空間に立てます。公式にテストされているのはこの既定の版だけで、新しい版を使いたい場合に推奨されているのは、外部データベースを使う構成です。外部に置くときは、次のSecretを作ってAWXの`spec`から参照します。 ``` --- apiVersion: v1 kind: Secret metadata: name: awx-demo-postgres-configuration namespace: awx stringData: host: awx-db.example.internal port: "5432" database: awx username: awx password: ChangeMe2026 sslmode: prefer target_session_attrs: read-write type: unmanaged type: Opaque ``` AWX側には`postgres_configuration_secret: awx-demo-postgres-configuration`を`spec`に1行加えます。同じ文書は、パスワードにシングルクォート、ダブルクォート、バックスラッシュを含めるとデプロイやバックアップ、復元で問題が起きると注意しています。記号を含むパスワードを自動生成するツールを使っている場合は、生成規則から外してください。 ### AWXBackup・AWXRestoreで退避と復元を回す手順と注意点 バックアップもカスタムリソースで取ります。[backupロールの説明](https://github.com/ansible/awx-operator/blob/devel/roles/backup/README.md)に従い、退避元のデプロイ名を指定して適用します。 ``` --- apiVersion: awx.ansible.com/v1beta1 kind: AWXBackup metadata: name: awxbackup-2026-10-17 namespace: awx spec: deployment_name: awx-demo backup_storage_requirements: "20Gi" ``` バックアップはPVCの中にtarとして保存され、データベースのダンプに加えて`secret_key`や`admin_password`のSecretも含みます。`secret_key`は、データベース内の機密データを暗号化する鍵です。この鍵を失うと、データベースが残っていても登録済みの機密データを復号できません。バックアップ用PVCの閲覧権限は、本番の管理者と同じ範囲に絞るべきです。 復元は[restoreロールの説明](https://github.com/ansible/awx-operator/blob/devel/roles/restore/README.md)のとおり、`kind: AWXRestore`に`deployment_name`（復元先）と`backup_name`（上のmetadata.name）を書いて適用します。同じ名前で戻す場合は、先に古いAWXリソースとデータベースのPVCを消しておくことが必要です。[アップグレード手順](https://github.com/ansible/awx-operator/blob/devel/docs/upgrade/upgrading.md)は名前空間を消さないよう警告しています。名前空間ごと消すと、バックアップとそのPVCも一緒に消えるためです。バックアップ用PVCは別の名前空間に置くか、取得後にクラスタの外へ写してください。 ## AWXを本番で使う条件とAAP契約やCLI運用を選ぶ場面の判断 判断の軸は、リリース停止中のソフトウェアの脆弱性対応を誰が持つかです。機能の差ではありません。 ### AWXで足りる条件：社内ネットワーク限定で脆弱性対応を自前で持てる体制 次の3つがすべて当てはまるなら、AWXで運用して構いません。1つ目は、画面とAPIを社内ネットワークやVPNの内側だけに置き、インターネットに公開しないこと。2つ目は、Kubernetesとコンテナイメージの脆弱性を定期的に調べ、必要なら自分たちでイメージを作り直せる担当者がいること。3つ目は、AWXが止まってもCLIの`ansible-playbook`で同じ作業を続けられることです。 3つ目は見落とされがちです。Playbookとインベントリをすべてgitで管理しておけば、AWXは実行の窓口にすぎなくなり、障害時の逃げ道が残ります。 ### AWXを見送る場面：監査対応・外部公開・24時間の窓口が要件の組織 ISMSや内部統制の監査で、実行基盤の保守状況を問われる組織にはAWXを勧めません。「2024年7月以降、正式な修正版が出ていないソフトウェアで本番を変更している」と説明する必要が出るからです。この場合はAAPを契約するのが筋で、費用の見積もり方は[Ansible Automation Platformの費用と導入判断](https://www.issoh.co.jp/column/details/18090/)で整理しました。 逆に、Playbookを書く人と実行する人が同じ数名で、画面が欲しいだけならAWXは過剰です。Kubernetesとデータベースの保守が丸ごと増えます。GitHub ActionsなどのCIから`ansible-playbook`を走らせるか、軽量な[Semaphore UIの導入](https://www.issoh.co.jp/tech/details/12399/)を比べてください。どの構成が自社に合うか、実行基盤の設計からCI/CDへの組み込みまで相談したい場合は、[DevOps・CI/CD導入支援](https://www.issoh.co.jp/service/system/devops/)で承っています。 ## よくある質問 Ansible AWXについて、検索されることの多い質問に答えます。 ### Ansible AWXは無料で使えますか？ 使えます。AWXはオープンソースで、導入に使うAWX OperatorもApache-2.0ライセンスです。利用料はかかりません。必要なのは動かすためのKubernetesクラスタとストレージの費用です。ただし有償のサポートは無く、2024年7月2日の24.6.1以降は正式リリースが出ていません。障害対応と脆弱性対応は自社で持つ前提になります。 ### AWXとAnsible Towerの違いは何ですか？ AWXは、Ansible Tower（現在のautomation controller）の上流にあたるオープンソースのプロジェクトです。ジョブテンプレート、Survey、Webhook、RBACなど機能の多くは共通します。違いはRed Hatのサポート、版ごとの保守期間、認定コンテンツの有無です。Towerの改称の経緯と各機能の設定手順は[Ansible Towerとは](https://www.issoh.co.jp/tech/details/18459/)で扱っています。 ### AWXはKubernetesを使わずにDockerだけで動かせますか？ 動かすこと自体はできます。ただしAWXのインストールガイドは、Dockerでの実行を開発やテスト向けとし、公式に公開されたリリースは無いと明記しています。本番を想定するならOperator経由でKubernetesに入れてください。小さく始めたい場合は、1台のサーバーにK3sなどの軽量なKubernetesを入れる方法がよく取られます。 ### AWX Operatorはどの版を指定すればよいですか？ 新規に入れるなら、2026年10月時点の最新である2.19.1を`ref`と`newTag`の両方に書きます。`devel`ブランチを指定すると未リリースの変更を取り込み、手順書どおりに動かない場合があります。既存環境のOperatorを上げるときは、先にAWXBackupを取ってから版を1つずつ上げてください。 ### AWXのsecret\_keyを消してしまうとどうなりますか？ Operatorの[管理者アカウント設定の文書](https://github.com/ansible/awx-operator/blob/devel/docs/user-guide/admin-user-account-configuration.md)によると、この鍵はデータベース内の機密データの暗号化に使われます。アップグレードやPodの再作成でも必要になるため、消してはいけないSecretです。指定しなければ「デプロイ名-secret-key」として自動生成されます。GitOpsで構成を管理する場合は、自分で作ったSecretを`secret_key_secret`で渡しておくと、作り直しのたびに鍵が変わる事故を防げます。 ## 関連記事 - [Ansibleとは？エージェントレスの仕組みとメリット・デメリット、Red Hat AAPの制約](https://www.issoh.co.jp/tech/details/6533/)：AWXが実行するAnsible本体の仕組み。 - [Ansible Towerとは：automation controllerへの改称とSurvey・Webhook・RBACの設定手順【AAP 2.7】](https://www.issoh.co.jp/tech/details/18459/)：AWXと共通するジョブテンプレート・Survey・Webhookの設定。 - [Ansible Automation Platformの費用と導入判断：AWX・ansible-coreとの違いと契約すべき条件](https://www.issoh.co.jp/column/details/18090/)：AWXからAAPへ切り替える場合の費用と契約判断。 - [Ansibleによる運用自動化の進め方：対象作業の選び方と費用対効果・失敗パターン](https://www.issoh.co.jp/column/details/18092/)：AWXに載せる運用作業の選び方。 - [Ansible Moleculeとは？v26系のansible-native設定とmolecule testの実行手順](https://www.issoh.co.jp/tech/details/17630/)：AWXで実行する前にロールを自動テストする方法。 --- 出典: [Ansible AWXとは：AWX OperatorでKubernetesへ導入する手順とAAPとの違い【2.19.1】]()（株式会社一創）