2026.10.17 自動化

Ansible Towerとは：automation controllerへの改称とSurvey・Webhook・RBACの設定手順【AAP 2.7】

Ansible Towerは、Ansibleの実行をWeb画面とREST APIから管理するRed Hatの製品でした。2021年のAnsible Automation Platform（AAP）2で名称が「automation controller」に変わり、現在はAAPの一部として提供されています。この記事では改称の経緯とAnsible Engineとの違いを押さえたうえで、ジョブテンプレート、Survey、GitHub Webhook、REST APIからの起動、RBACによる権限委譲をコード付きで解説します。旧Towerの資料と現行のAAP 2.7系で異なる画面名とAPIパスも、本記事での解説対象です。

まとめ｜Ansible Towerの機能はautomation controllerが継承

Ansible Towerという名前の製品は、もう新しくは提供されていません。後継はAAPに含まれるautomation controllerで、ジョブテンプレート、Survey、Webhook、RBAC、スケジュールといった機能はそのまま引き継がれました。上流のAWXは無償ですが、2024年7月を最後にリリースが止まっています。

AAP 2.7系ではTower時代の/api/v2/を直接叩くスクリプトが401で止まるため、移行時はAPIパスを最初に確認してください。導入の判断軸は「Playbookを書かない人に実行を任せるか」と「誰が何を実行したか監査する必要があるか」の2点です。どちらも当てはまらない数名のチームなら、CLI運用のままで足ります。

Ansible Towerの改称経緯とAnsible Engine・AWXとの違い

検索で見つかるTowerの記事は、2016年前後のTower 3.x系を前提にしたものが多く残っています。名称の対応を先に整理しておくと、旧資料を現行版へ読み替えやすくなります。

2021年のAAP 2でTowerがcontroller 4.0に改称された理由と変更点

Red Hatは2021年10月5日の公式ブログ「What’s new in Ansible Automation Platform 2: automation controller」で、automation controller 4.0を「改良され、名称が変わったRed Hat Ansible Tower」と説明しています。改称の理由は、Towerが担っていた機能の一部を切り離したことでした。

切り離されたのは主に実行部分です。Tower 3.x系ではPlaybookの実行に使うPythonの依存ライブラリやコレクションがTowerのサーバーと密結合していましたが、AAP 2では「automation execution environment」というコンテナイメージに分離されました。Red Hatの日本語製品ページも、Automation Controllerを「Ansible Towerに代わる」コマンド＆コントロールセンターと位置づけています。現行ドキュメントでTowerの機能を調べるときは「automation controller」で探すのが近道です。

Ansible EngineとTowerの役割の違いとansible-coreの扱い

Ansible Engineは、コマンドラインのAnsible本体にRed Hatのサポートを付けた製品でした。Towerはその上で動く管理基盤で、Web画面、REST API、権限管理、実行履歴を担っていました。

旧名称	担っていた役割	AAP 2以降
Ansible Engine	Playbookを実行するCLI	実行環境内のansible-core
Ansible Tower	画面・API・権限・履歴	automation controller
Towerの仮想環境	実行時の依存ライブラリ	execution environment

前述のブログは、実行環境を「Ansible Core、Ansibleコンテンツ、追加の依存関係を含む自己完結型のイメージ」と説明しています。Engineを別に入れる代わりに、ansible-coreがイメージに同梱される形へ変わったわけです。Playbookの書き方そのものは変わらないので、基本はAnsible Playbookの書き方と実行手順で確認できます。

上流のAWXとcontroller・AAPの関係と2024年からのリリース停止

Towerには、ソースコードが公開された上流プロジェクトのAWXがあります。画面構成やAPIの多くが共通なので、AWXの文書はcontrollerの機能を確かめる一次情報としても使えます。

ただしAWXのGitHubリポジトリには「最終リリースは2024年7月2日。大規模なリファクタリングの間、リリースを停止する」と明記されており、最新は24.6.1のままです。本番で使い続けると、脆弱性の修正版が出ない期間を自分で抱えることになります。AAPの費用とAWXを選ぶ場合の負担はAnsible Automation Platformの費用と導入判断で整理しました。

ジョブテンプレートの作成項目とVMwareなどインベントリソースの同期設定

controllerでPlaybookを実行する単位がジョブテンプレートです。「どのPlaybookを、どのホストに、どの認証情報で実行するか」の組み合わせを保存したもので、インベントリや認証情報が未登録だと作成画面で選択肢が出てきません。

Automation Execution＞Templatesの入力項目と起動時の上書き

AAP 2.7系の手順はRed Hatのジョブテンプレート作成手順にあります。ナビゲーションの「Automation Execution」から「Templates」を開き、「Create template」の一覧で「Create job template」を選びます。

項目	入れる値	起動時の上書き
Job type	Run または Check	可
Inventory	対象ホストの一覧	可
Project	Playbookを置いたGit	不可
Playbook	プロジェクト内のYAML	不可
Execution Environment	実行用イメージ	可
Credentials	SSH鍵やクラウドの鍵	可
Forks	並列数（0で既定の5）	可

Checkはansible-playbook --checkと同じドライランです。本番用テンプレートでJob typeとLimitの「Prompt on launch」にチェックを入れておけば、実行者が起動のたびにCheckかRunかと対象ホストを選べます。まず1台だけRunし、問題が無ければ全台へ広げる段階実行が画面操作だけで組めるわけです。なお公式手順は、control-plane-eeを実行環境に選ばないよう警告しています。内部用のイメージで、Playbookの依存関係が足りずに失敗する可能性があるためです。

VMware vCenterやAWS EC2をインベントリソースで同期する手順

「ansible tower vmware」で探す人の多くは、vCenter上の仮想マシンを自動で対象ホストにしたい人です。AWXのインベントリ文書では、外部から取り込むインベントリソースとしてAmazon EC2、Microsoft Azure Resource Manager、VMware vCenter、Red Hat Satellite 6、Terraform Stateなどが選べます。

vCenterを使う場合は、先にvCenterの認証情報を作り、インベントリソースの画面で指定します。同期のたびに仮想マシンの一覧が更新されるため、台数が増減する環境ほど手書きより保守の負担を軽くできる仕組みです。対象にするフォルダやタグを先に決めておかないと、検証機まで本番用ジョブの対象に入ってしまいます。

SurveyでPlaybookの変数を画面入力させる設定とsurvey_specのJSON

Surveyは、ジョブの起動時に質問フォームを出し、回答をPlaybookの変数として渡す機能です。運用担当者に「版と対象環境だけ選んで実行してもらう」用途で使います。

Surveyの質問タイプ7種と変数名・必須・最小最大の指定方法

AWXのジョブテンプレート文書によると、回答の型は次の7種類です。

Text：1行のテキスト。最小・最大の文字数を指定できる
Textarea：複数行のテキスト
Password：実際のパスワードと同じく機密情報として扱われる
Multiple Choice（single select）：選択肢から1つ
Multiple Choice（multiple select）：選択肢から複数
Integer：整数。最小と最大を指定できる
Float：小数

各質問には、Playbookで参照する変数名を指定します。空白を含む名前は使えません。対象環境のように取り得る値が決まっている項目は、Textで自由入力させずMultiple Choiceにしてください。typoした環境名がそのまま渡ると、意図しないホストグループに当たる原因になります。

survey_specをawx.awx.job_templateでコード管理する手順

画面だけでSurveyを作ると、誰がいつ質問を変えたかがGitに残りません。JSONの構造はAWXのソースにあるsurvey_specの仕様書に定義されており、typeにはtext、password、integer、float、multiplechoice、multiselectを指定します。

{
  "name": "deploy",
  "description": "アプリのデプロイ先と版を選ぶ",
  "spec": [
    {
      "type": "multiplechoice",
      "question_name": "対象環境",
      "question_description": "stgで確認してからprdを選ぶ",
      "variable": "target_env",
      "choices": ["stg", "prd"],
      "required": true,
      "default": "stg"
    },
    {
      "type": "text",
      "question_name": "アプリの版",
      "question_description": "例 1.4.2",
      "variable": "app_version",
      "min": 5,
      "max": 20,
      "required": true,
      "default": ""
    }
  ]
}

これをsurvey/deploy.jsonとして保存し、awx.awx.job_templateモジュール（コレクション24.6.1）でテンプレートごと作成します。

# controller_setup.yml（AWXに対して実行する例）
- name: ジョブテンプレートをコードで作る
  hosts: localhost
  gather_facts: false
  tasks:
    - name: deployテンプレートを作成または更新
      awx.awx.job_template:
        controller_host: "https://awx.example.com"
        controller_oauthtoken: "{{ lookup('ansible.builtin.env', 'CONTROLLER_OAUTH_TOKEN') }}"
        name: "deploy-app"
        organization: "Default"
        project: "app-playbooks"
        playbook: "deploy.yml"
        inventory: "web-servers"
        credentials:
          - "deploy-ssh"
        job_type: "run"
        ask_job_type_on_launch: true
        ask_limit_on_launch: true
        survey_enabled: true
        survey_spec: "{{ lookup('ansible.builtin.file', 'survey/deploy.json') }}"
        state: present

引数にはtower_hostなどのエイリアスが残っており、Tower時代のPlaybookもそのまま読めます。このコレクションはAWX向けです。AAPに対しては、automation hubで配布される認定コレクションを使っているAAPの版に合わせて選んでください。

GitHub・GitLabのWebhookでジョブテンプレートを起動する設定手順

Webhookを使うと、リポジトリへのpushやプルリクエストを合図にジョブテンプレートを起動できます。CIツールを挟まずに、Playbookの更新を検証環境へ反映する流れが組めます。

Webhook URLとWebhook keyをGitHubのリポジトリ設定へ登録

ジョブテンプレートで「Enable webhook」をオンにすると追加の項目が表示されます。対応サービスはGitHubとGitLabの2つです。

「Webhook service」でGitHubかGitLabを選んで保存する
自動入力された「Webhook URL」と、自動生成された「Webhook key」を控える
GitHubのWebhook追加画面で、Payload URLにWebhook URLを貼る
Content typeをapplication/jsonにし、SecretにWebhook keyを貼る
起動の合図にするイベントを選び、Add Webhookで保存する

AWXのWebhook文書によると、ジョブの状態（pending・error・success）を書き戻せるのはGitHubではプルリクエスト、GitLabではマージリクエストのイベントだけです。書き戻しには「Webhook credential」として個人アクセストークンを登録します。ジョブが起動しないときは、GitHub側のWebhook画面に残る送信履歴で応答コードを確かめてください。

awx_webhook_payloadからブランチ名を取り出すPlaybookの書き方

Webhookで起動したジョブには、送られてきたJSONがawx_webhook_payloadという変数で渡されます。GitHubのpushイベントではrefにrefs/heads/mainの形でブランチ名が入るので、次のように取り出します。

- name: Webhookのブランチに応じて処理を止める
  hosts: localhost
  gather_facts: false
  tasks:
    - name: refからブランチ名だけを取り出す
      ansible.builtin.set_fact:
        pushed_branch: "{{ awx_webhook_payload.ref | regex_replace('^refs/heads/', '') }}"
      when: awx_webhook_payload is defined

    - name: main以外のpushでは何もしない
      ansible.builtin.meta: end_play
      when: pushed_branch | default('') != 'main'

Webhookは選んだイベントのすべてでジョブを起動し、テンプレート側にブランチを絞る項目はありません。この判定をPlaybookの先頭に置かないと、作業ブランチへのpushでも本番向けのジョブが走ります。手動起動（manual）やスケジュール起動（scheduled）と処理を分けたいときは、自動で付くawx_job_launch_type変数で判定できます。

REST APIからジョブを起動する手順とAAP 2.7で変わったAPIパス

画面でできる操作は、ほぼすべてREST APIでも行えます。監視ツールのアラートや社内ポータルからジョブを起動する連携はこのAPIを使います。

gateway経由のlaunchエンドポイントへ回答を送るcurl実行例

AAP 2.5系以降、controllerのAPIはplatform gatewayの配下に移り、パスが/api/controller/v2/で始まる形になりました。トークンはgatewayで発行し、Authorization: Bearerヘッダーに付けます。

# IDが42のジョブテンプレートを、Surveyの回答を付けて起動する
curl -s -X POST \
  -H "Authorization: Bearer ${AAP_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"extra_vars": {"target_env": "stg", "app_version": "1.4.2"}}' \
  https://gateway.example.com/api/controller/v2/job_templates/42/launch/

Surveyの回答はextra_varsとして渡します。Surveyも「Extra variables」のPrompt on launchも有効でないテンプレートでは、送った変数が反映されません。2.7の手順書によれば、再実行（Relaunch）はextra_varsを新たに受け取らず、元のジョブで計算された値を使います。

Tower時代のapi/v2を叩く既存スクリプトが401になる移行の注意

移行で最も見落としやすい点です。AAP 2.7のAPI変更点には「個々のコンポーネントへの直接のAPIアクセスは削除された」とあり、controllerのホストへ直接送ったリクエストはHTTP 401 Unauthorizedになります。認証情報やトークンもgatewayで作り直す必要があります。

Tower時代から使っているシェルスクリプトや監視ツールの連携は、ホスト名、パス、トークンの3点を書き換えます。アップグレード前に/api/v2/を含む設定を社内でgrepして洗い出しておけば、切り替え当日に連携が一斉に止まる事態を防げます。AAP 2.7はRed Hatが2026年6月10日に一般提供を発表した版で、2.4系から上げる組織ではこの作業が必須です。

RBACで実行だけを委ねるチーム設計と認証情報を見せない権限

Towerが選ばれてきた最大の理由は、実行権限を細かく委譲できる点にあります。CLIで同じことをすると、実行者全員にSSH鍵やクラウドの鍵を配ることになります。

Execute・Use・Adminロールの違いと全員を管理者にする失敗

AWXのRBAC文書で定義されているロールのうち、実務でまず押さえるのは上の2つです。

ロール	付ける対象	できること
Execute	ジョブテンプレート	割り当てられたテンプレートの実行
Use	認証情報・インベントリ等	テンプレートの中で使う
Admin	組織・チーム・各リソース	設定の変更と削除
Read	組織・チーム・各リソース	閲覧のみ

運用担当者のチームにはジョブテンプレートのExecuteだけを付けます。同じ文書には、利用者に秘密情報を見せないまま必要な認証情報を使わせられると書かれています。SSH鍵の中身を知らない担当者でも、許可されたテンプレート経由なら本番への適用を実行できるわけです。AAP 2.7系では、ロールの一覧と独自ロールの作成が「Access Management」の「Roles」に集約されました。

導入初期に多い失敗は、権限設定を後回しにして全員を組織の管理者にする運用です。誰でもPlaybookの参照先やインベントリを書き換えられる状態では、実行履歴が残っても監査証跡になりません。テンプレートを作るチーム（Admin）と実行するチーム（Execute）は最初から分けてください。

automation controllerを導入する条件とCLI運用で見送る場面の判断

判断は、Playbookを書く人と実行する人が分かれているかどうかで決まります。

導入する条件：実行者が開発者以外で操作の監査が求められる場合

次の2つが両方当てはまるなら、controller（またはAAP）の導入を勧めます。1つ目は、夜間の運用担当者やヘルプデスクなど、Playbookを書かない人に定型作業を任せたい場合です。2つ目は、ISMSや内部統制の監査で「誰が、いつ、どの手順で本番を変更したか」を示す必要がある場合です。この2つが揃えば、Surveyで入力を絞り、Executeロールで実行を委ね、ジョブ履歴を証跡にする構成がそのまま効きます。

見送る場面：数名のインフラ担当がGitのPlaybookを直接実行できる体制

Playbookを書く人と実行する人が同じ3〜4名で、監査の要件も無いなら、controllerは過剰です。サーバー、データベース、実行環境イメージの保守が増える割に、得られるのは画面での実行と履歴だけになります。GitHub ActionsなどのCIからansible-playbookを実行すれば、履歴はCIのログに残ります。

リリース停止中のAWXを無償の代替として本番に入れる判断も勧めません。軽いWeb画面が欲しいだけならSemaphore UIの導入手順とAWXとの違いも比較対象です。Playbookの整備から実行基盤の設計、CI/CDへの組み込みまで外部に任せる場合は、DevOps・CI/CD導入支援でご相談を受け付けています。

よくある質問

Ansible Towerについて、検索されることの多い質問に答えます。

Ansible Towerは今でも使えますか？

Ansible Towerという名前の製品は、2021年のAAP 2でautomation controllerへ改称されました。新規に導入するならAAPを契約し、その中のcontrollerを使う形になります。Tower 3.x系を動かしている環境は、サポート期間とOSの対応を確かめたうえでAAPへの移行を計画してください。影響が大きいのはAPIパスと実行環境の変更です。

Ansible Towerは無料で使えますか？

controllerを含むAAPは有償のサブスクリプションで、料金は管理対象ノード数とサポート水準による見積もり制です。無償で同系統の機能を試すなら上流のAWXがあります。ただし2024年7月2日の24.6.1を最後にリリースが止まっており、本番利用は脆弱性対応を自前で抱える前提になります。

Ansible TowerとAWXの違いは何ですか？

AWXは、Tower（現automation controller）の上流にあたるオープンソースのプロジェクトです。ジョブテンプレートやSurveyなどの機能の多くは共通しています。違うのは、Red Hatのサポート、セキュリティ修正の提供、認定コンテンツの有無です。KubernetesへのAWXの導入手順は別の記事で扱います。

Ansible TowerのGUIでPlaybookを書けますか？

書けません。controllerの画面でできるのは、Gitリポジトリなどに置いたPlaybookを選んで実行し、結果を見ることです。Playbook本体はエディタで書き、プロジェクトに登録したリポジトリへコミットします。画面から編集できないぶん、変更履歴がGitに集まるという利点もあります。

Ansible TowerのWebhookはGitHub以外にも使えますか？

「Enable webhook」が標準で対応しているのはGitHubとGitLabの2つです。それ以外のサービスから起動したい場合は、REST APIのlaunchエンドポイントへPOSTします。AAP 2.5系以降はgateway経由の/api/controller/v2/を使い、トークンもgatewayで発行してください。