Red Hat Ansible Automation Platform のライフサイクル
目次
- 概要
- ライフサイクルの日付
- ライフサイクルフェーズ
- Ansible Automation Platform のインストール要件
- サポート範囲
- OS および実行環境イメージとサポートされる Ansible Core バージョン
- Ansible Collection
- Configuration as Code Ansible Collection の要件
- MCP サーバーのライフサイクル
- Red Hat Ansible Automation 実行環境ライフサイクルページ
- Postgres データベースのサポート範囲
- Versioning and Release Strategy for Ansible Engineering Maintained Certified Collections
- Ansible Automation Platform のドキュメント
- Ansible Automation Platform リリースノート
- Ansible Automation Platform プレビューと非推奨機能
- Ansible Automation Platform セルフサービスポータル
Ansible Automation Platform のライフサイクル
概要
Red Hat Ansible Automation Platform (AAP) サブスクリプションの一部として、お客様はオンプレミスパッケージのサポート対象バージョンおよび Red Hat Hybrid Cloud Console で提供されるホスト型 Ansible サービスにアクセスできます。Red Hat は、Ansible Automation Platform の製品ライフサイクルを公開することで、お客様およびパートナー様がオンプレミスの自動化クラスターを適切に計画、デプロイ、サポート、保守できるようにします。また、Ansible Automation Platform サブスクリプションの一部として使用する Red Hat Hybrid Cloud Console の Ansible ホスト型サービスを運用できるようにしています。
お客様には、お使いの Ansible Automation Platform 環境を該当製品のサポートされる最新バージョンに適宜アップグレードすることが推奨されます。セキュリティーリスクの高いものに関する例外の可能性を除けば、機能およびバグ修正は製品の最新バージョンのみが対象になります。
このライフサイクルページでは、Ansible Automation Platform のバージョン、依存関係、および管理対象について、概要と詳細な説明を提供しています。
ライフサイクルの日付
Ansible Automation Platform のライフサイクル
* Extended Update Support Term 1 および Term 2 に適用されます。この EUS アドオンは、AAP 2.4 向けに購入可能です。購入には有効なサブスクリプションが必要です。詳細は、アカウント担当者までお問い合わせください。
対象範囲
サポートは、公開されている Red Hat Enterprise Agreement の「Appendix 1」の対象範囲に従った使用に対して提供されます。
Red Hat のエンタープライズ製品が備える高い安定性を維持しつつ、新たなテクノロジーの迅速な採用を促進するため、Red Hat Ansible Automation Platform の製品ライフサイクルは、以下に説明されているように 3 つのメンテナンスフェーズに分けられます。
運用フェーズ
| ライフサイクルフェーズ | ||||
|---|---|---|---|---|
| 説明 | フルサポート | メンテナンスサポート 1 | メンテナンスサポート 2 | Extended Life-cycle Support アドオン |
| 評価済みの影響度が「重大」のセキュリティー修正 | はい | はい | はい | はい |
| セキュリティーの修正 | 重大度が「重大」、「重要」、「中程度」(CVSS スコア 7.0 以上) の問題 | 重大度が「重大」および「重要」の問題 | 重大度が「重大」の問題 | いいえ |
| セキュリティーエラータ (RHSA) の随時リリース | はい | はい | はい | いいえ |
| バグ修正エラータ (RHBA)2 の随時リリース | はい | はい | いいえ | いいえ |
| 一部のソフトウェア機能拡張 | はい | いいえ | いいえ | いいえ |
| フェーズ | セキュリティーの修正 | バグ修正 | 機能修正/機能拡張 |
|---|---|---|---|
| メンテナンスサポート 1 | 重大度が「重大」および「重要」の問題 | 「重大」のみ | 新しい機能はありません |
| メンテナンスサポート 2 | 「重大」のみ | なし | 新しい機能はありません |
表 1.0 - メンテナンスサポートフェーズの説明
次の画像は、AAP リリースでデフォルトになっているか、表 1.1 AAP リリースライフサイクルに従って AAP で使用できる Ansible Core バージョン間の関係を示しています。
画像 1.1 - 現在の AAP と Ansible Core のライフサイクル
Ansible Automation Platform のインストール要件
次の表は、Ansible Automation Platform のオペレーティングシステムとデータベースの最小インストール要件を示しています。
| AAP バージョン | デフォルトの Ansible-core 1 | Operator に必要な OCP バージョン | RHEL が提供する PostgreSQL バージョン | RPM インストール OS | コンテナー化された OS |
|---|---|---|---|---|---|
| 2.7 | ansible-core 2.16 | 4.14-4.22 (未定) | 15-17 (未定) | 利用不可 | RHEL 9、RHEL 10 |
| 2.6 | ansible-core 2.16 | 4.14-4.20 | 15-17 | RHEL 9 | RHEL 9、RHEL 10 |
| 2.5 | ansible-core 2.16 | 4.12-4.20 | 15 | RHEL 8、RHEL 9 | RHEL 9、RHEL 10 |
| 2.4 | ansible-core 2.15 | 4.10-4.20 | 15 (v13 は 2025 年 11 月までサポートされます) | RHEL 8、RHEL 9 | RHEL 9 (テクニカルプレビュー) |
表 1.2 - オペレーティングシステムとデータベースの要件
1.Ansible-core プラットフォームバージョンは、サポートされているライフサイクルにおいて AAP を インストール および 運用 するために必要な Ansible Core のバージョンであり、プラットフォームにおける Core のデフォルトバージョンでもあります。Core のデフォルトバージョンは、アタッチされているプラットフォームバージョンのライフサイクル全体にわたってサポートされます。
2.AAP のバージョンは 2.5、2.4 などです。内部のコンポーネントとサービスはリリースごとにバージョン管理され、独立してバージョンアップされます。たとえば、既存のクラスター上でインストーラーを実行すると、そのインストーラーのリリースに対応するコンポーネントのみが更新されるため、変更された各コンポーネントは個別にバージョンアップされます。
サポート範囲
お客様提供のデータベース
お客様が提供するデータベースに対して、商業的に妥当な範囲でのサポートが提供されます。フルサポートによる解決のために、サポート対象のデータベース上で問題を再現していただくようお願いする場合があります。
Ansible Automation Platform では、標準的なアクティビティーがサポートされますが、以下に示すとおり、サポート対象外の共通の除外項目もあります。
| サポート対象の操作 | サポート対象外の操作 |
|---|---|
| インストール | データベースのレプリケーション/フェイルオーバー |
| アップグレード | プラットフォームと統合された外部アプリケーション (サードパーティーのロガー、ロードバランサー、認証など) |
| バックアップ/復元 | カスタムコンテンツ/コレクションの開発とデバッグ |
| 標準設定 | カスタム設定 |
| 用途 (API と UI) | カスタム API 統合 |
| 操作 | カスタムコンテンツ |
お客様提供の Kubernetes - コンテナーグループのみ
Ansible Automation Platform コントロールプレーン (Red Hat がサポートするプラットフォーム上で実行) と、Amazon EKS、Azure AKS、または Google Cloud GKE で実行される実行プレーン (コンテナーグループ) を組み合わせて活用したいお客様向けに、商業的に妥当な範囲でのサポートが提供されます。
クラウド Kubernetes サービスは、デプロイされる AAP バージョンでテストされた、サポート対象の OpenShift リリースに一致する Kubernetes API バージョンを実行している必要があります。サポートされている OpenShift のバージョンは、上記の Ansible Platform サービスとコンポーネント の表に記載されています。また、Kubernetes API のバージョンと OpenShift のバージョンの対応関係は、https://access.redhat.com/solutions/4870701 で確認できます。
OS および実行環境イメージとサポートされる Ansible Core バージョン
Ansible Core は、実行環境イメージを使用することで Ansible Automation Platform で利用できるようになります。お客様の自動化ニーズを満たすため、さまざまなバージョンの Ansible Core を含む実行環境イメージを提供しています。以下はその例です。
- Ansible Core 2.16 を搭載した EE - デフォルトのバージョンは、AAP 2.7、AAP 2.6、および AAP 2.5 です。RHEL8 のライフサイクル全体にわたるサポートが可能。AAP 2.5、AAP 2.6、および AAP 2.7 のライフサイクル全体にわたってサポートされる安定版です。
- Ansible Core 2.18 を搭載した EE - 最新機能を活用できる最新の Ansible Core。AAP 2.5、AAP 2.6、および AAP 2.7 のライフサイクル全体にわたってサポートされる安定版です。
- Ansible Core 2.20 を搭載した EE - AAP 2.7 では EE ストリームとして利用可能ですが、プラットフォームのデフォルトではありません。公開されている EE イメージを介して使用する場合、AAP 2.7 のライフサイクル全体にわたってサポートされます。RHEL 8 のコントロールノードまたは管理対象ノードのサポートが必要なお客様は、引き続きデフォルトの 2.16 を使用する必要があります。
- Ansible Core 2.17 を搭載した EE - サポート対象外となりました。
- Ansible Core 2.15 を搭載した EE - AAP 2.4 向け EUS をご購入のお客様は、Core のサポートを継続して受けるために、最低でも Core 2.16 にアップグレードすることを推奨します。Core 2.15 は 2026 年 6 月以降サポートされなくなるためです。
Red Hat は、"偶数" で終わる Ansible Core バージョンについては長期のライフサイクルを安定的にサポートし、"奇数" で終わる Ansible Core バージョンについては図 1.0 に示すように短期のライフサイクルを提供することを目的としています。
バージョンありおよびバージョンなしの実行環境イメージ
すべての実行環境イメージは、公式かつサポート対象のソースとして catalog.redhat.com に公開されています。バージョン付きの EE は、名前空間によって Ansible Automation Platform のバージョンにロックされますが、バージョンなしの EE はどのバージョンにもロックされず、すべてが ansible-automation-platform 名前空間にあります。
| バージョンありの EE | バージョンなし EE |
|---|---|
|
|
次の表は、サポートされているコントロールノードと管理対象ノードの範囲の詳細を示しています。Ansible Core ごとのサポート対象の日付については、AAP ライフサイクルの表 1.1 を参照してください。
| Ansible Core バージョン | 実行環境 (EE) イメージ | EE ベース OS | コントロールノードの Python バージョン | 管理対象ノードの Python バージョン | (2) 管理対象ノードの PowerShell バージョン | (1) サポート対象のマネージド OS(RHEL) |
|---|---|---|---|---|---|---|
| 2.20 3 | ee-minimal-rhel9 | RHEL 9 | 3.12 - 3.14 | 3.9 - 3.14 | 5.1 | RHEL 9 - 10 |
| 2.18 | ee-minimal-rhel8、ee-minimal-rhel9 | RHEL 8, 9 | 3.11 - 3.13 | 3.8 - 3.13 | 5.1 | RHEL 9 - 10 |
| 2.17 4 | ee-minimal-rhel8、ee-minimal-rhel9 | RHEL 8, 9 | 3.10 - 3.12 | 3.7 - 3.12 | 5.1 | RHEL 9 - 10 |
| 2.16 | ee-minimal-rhel8, ee-minimal-rhel9, ee-supported-rhel8, ee-supported-rhel9 | RHEL 8, 9 | 3.10 - 3.12 | 2.7、3.6 - 3.12 | 4 - 5.1 | RHEL 7 - 10 |
| 2.15 5 | ee-minimal-rhel8、ee-minimal-rhel9 | RHEL 8, 9 | 3.9 - 3.11 | 2.7、3.5 - 3.11 | 4 - 5.1 | RHEL 7 - 9 |
表 1.3 - コントロールノードと管理対象ノードのサポート範囲
1.すべての RHEL 環境において、管理対象のバージョンによっては、実行する自動化のユースケースに応じて Ansible と Python の依存関係を一致させる必要があります。そのため、ansible_python_interpreter を正しい Python パスに設定する必要がある場合があります。
2.Windows Server バージョン 2016、2019、2022、2025 (Ansible Core 2.18 以降が必要) がサポートされています。WDAC が有効になっている Windows Server は現在サポートされていません。OpenSSH は、Windows Server 2022 以降および Ansible Core 2.18 以降でサポートされています。さらに、デスクトップ/ラップトップデバイスおよびサポートされるオペレーティングシステム (Windows 10/11 など) のデスクトップバリアントを実行するデバイスは、合意された条件でサポートの例外が認められた場合を除き、商業的に妥当な範囲でのサポートの対象とはなりません。
3.Ansible Core 2.20 は、AAP 2.7 では EE ストリームとしてのみ利用可能であり、プラットフォームのデフォルトではありません。RHEL 8 は Core 2.20 の管理対象 OS としてサポートされていません。RHEL 8 のコントロールノードまたは管理対象ノードのサポートが必要なお客様は、デフォルトの 2.16 を使用する必要があります。
4.本稿執筆時点において、Ansible Core 2.17 はサポート対象外となりました。
5.Ansible Core 2.15 のサポートは 2026 年 6 月に終了します。AAP 2.4 向け EUS をご購入のお客様は、2026 年 6 月以降も Core のサポートを継続して受けるために、最低でも Core 2.16 にアップグレードすることを推奨します。
| その他のオペレーティングシステム | サポート対象の EE または Ansible コントロールノード | サポート対象のターゲット |
|---|---|---|
| (3)IBM オペレーティングシステム | Ansible Core バージョン 2.15 以降 | OpenSSH が有効な IBM Open Enterprise SDK for Python 3.11 以降 |
| IBM z (z/OS) | ||
| IBM i | ||
| IBM AIX | ||
| Arista EOS Cisco IOS、IOS-XE、IOS-XR、NX-OS Juniper Junos OS VyOS | 要件やベンダードキュメントについては、Ansible Collection を参照してください。 | |
| Ubuntu (x86_64 のみ) | AAP ライフサイクルに準じる | |
| 追加のオペレーティングシステム (例: リストにない RHEL バリアントなど) | 商業的に妥当な範囲でのサポート (つまり、サポート対象プラットフォームで問題を再現できる場合) に限定 | |
表 1.4 - その他のオペレーティングシステムのサポート
3.IBM が管理するノードは IBM によってテストおよびサポートされており、IBM との有効なサポート契約が必要です。詳細は以下を参照してください。IBM オペレーティングシステムとコンテンツにおける Ansible サポート
セキュリティー脆弱性修復ポリシー
最新の Red Hat 製品セキュリティー基準に準拠するために、Red Hat Product Security チームにより評価された CVSS v3 基本スコアに基づき、Ansible Automation Platform コンポーネントで特定された脆弱性には次の修復タイムラインが適用されます。
重大 (CVSS 9.0-10.0):直ちに修復を優先する必要があります。修正または緩和措置は、情報開示またはアドバイザリーの公開から 14 暦日以内に提供される必要があります。
高 (CVSS 7.0-8.9):修復は、情報開示またはアドバイザリーの公開から 30 暦日以内に計画および提供される必要があります。
スコアが 7.0 (中/低) 未満の脆弱性については、引き続きベストエフォート方式で標準的なリリースサイクルの中で対処されます。
定められた期限内に修正を提供できない場合は、緩和策の計画と改定後の完了日を含むリスク受容の書面をポートフォリオセキュリティーチームに提出する必要があります。
このポリシーは、AAP ライフサイクルで定義されている、現在フルサポートフェーズまたはメンテナンスサポートフェーズにあるすべてのサポート対象バージョンに適用されます。
Ansible Collection
Red Hat Ansible Automation Platform (AAP) では、ほとんどの自動化は Ansible Collections を通じて提供されます。つまり、ターゲットシステム (または "エンドノード") を自動化する場合、タスクはその特定のプラットフォームまたはテクノロジー専用に構築されたコレクションを使用して実行されます。
その結果、特定のエンドノードにおける自動化の ライフサイクルおよびサポート は、その管理に使用される 個々の Ansible Collection によって規定されます。
以下はその例です。
- Red Hat OpenShift の自動化は、 OpenShift Collection を通じて管理され、そのライフサイクルに従います。
- Microsoft Azure の自動化は、 Azure Collection を通じて管理され、そのライフサイクルに従います。
- Cisco ACI の自動化は、独自のライフサイクルを定義する Cisco ACI Collection を通じてサポートされます。
- NetApp の自動化は、独立したライフサイクルを持つ NetApp Collection を通じて処理されます。
このモデルは、Ansible Automation Platform 自体のサポートやライフサイクルには影響を与えない 点を留意することが重要です。使用されている個々のコレクションにかかわらず、Red Hat はこのプラットフォームをフルサポートの対象としています。詳細は、個々のコレクションのライフサイクルを参照してください。
Configuration as Code Ansible Collection の要件
次の表は、AAP リリースごとに、Configuration as Code を使用して Red Hat Ansible Automation Platform を管理するために必要なバージョンを示しています。
| AAP バージョン | ansible.controller | ansible.eda | ansible.hub | ansible.platform |
|---|---|---|---|---|
| 2.7 | >=4.8 | >=2.12.0 | >=1.0.6 | >=2.7* |
| 2.6 | >=4.7, <4.8 | Automation Hub で最新バージョンを使用します | >=1.0.4, <1.0.6 | >=2.6, <2.6.20260306 |
| 2.5 | >=4.6, <4.7 | Automation Hub で最新バージョンを使用します | >=1.0.0 | >=2.5, <2.6 |
| 2.4 | >=4.5.0, <4.6.0 | Automation Hub で最新バージョンを使用します | 利用不可 | 利用不可 |
*注記: infra.aap_configuration または infra.aap_configuration_extended を使用している場合は、最新の 2.7* コレクションを使用してください。
MCP サーバーのライフサイクル
Red Hat が提供する Ansible Model Context Protocol (MCP) サーバーは、Ansible Automation Platform を拡張し、AI アシスタントや大規模言語モデルとの統合を可能にします。MCP プロトコルと関連する AI エコシステムは、標準的な AAP コンポーネントのサイクルよりも速いペースで進化しています。そのため、MCP サーバーは GA リリースごとに、意図的に標準的な AAP ライフサイクルよりも短い 12 カ月という限定的なライフサイクルを採用しています。
MCP サーバーの各 GA リリースには、GA 日から 12 カ月間のサポート期間が設けられ、これは 2 つのフェーズに分かれています。
| フェーズ | 期間 | セキュリティーの修正 | バグ修正 | 新機能 |
|---|---|---|---|---|
| フルサポート | 0 - 8 カ月 | 「重大」、「重要」、「中程度」 (CVSS 7.0 以上) | すべての重大度 | はい - 拡張機能を選択 |
| メンテナンスサポート | 9 - 12 カ月 | 「重大」および「重要」のみ | 「重大」のみ | いいえ |
| ライフサイクル終了日 | 12 カ月目以降 | — | — | — |
表 2.0 — MCP サーバーのライフサイクルフェーズ
使用しているリリースの把握。各 MCP Server リリースには、{AAP_VERSION}.{YYYYMMDD}[.{patch}] というタグが付けられます。たとえば、2.6.20260315 の場合、2.6.20260315.1 はパッチのリビジョンを示します。サポート状況を確認するには、コンテナーイメージまたは RPM メタデータの日付スタンプを読み取ります。フルサポートはその日付から 8 カ月間提供され、メンテナンスサポートは 12 カ月目まで、12 カ月目以降はライフサイクル終了となります。{AAP_VERSION} というプレフィックスは、リリースがビルドおよびテストされた AAP マイナーであることを示しており、MCP サーバーはその AAP マイナーで実行された場合にのみサポートされます。{patch} は、サポート期間内の修正に応じて数字が増えます。
MCP サーバーのライフサイクルは、AAP プラットフォームのライフサイクルに連動していません。1 つの AAP マイナーが、そのライフサイクルを通して複数の MCP サーバーリリースをサポートする場合があり、また複数の MCP サーバーリリースが同時にサポートされる場合もあります。お客様は、サポート期間内に留まるために、デプロイメントを最新または N-1 MCP Server GA リリースに維持する必要があります。
サポートは有効な AAP サブスクリプションに含まれており、Gateway API 経由で AAP に対して認証を行う、Red Hat 提供の MCP サーバーを対象としています。サポート対象のデプロイメントトポロジー (AAP と並行して配置、独立したホスト上に配置、または将来のリリースで予定されているゲートウェイを前置した配置など) については、各 GA リリースの MCP サーバーインストールガイドに記載されています。お客様が開発した、またはサードパーティー製の MCP サーバーについては、商業的に妥当な範囲でのサポートのみ提供されます。LLM プロバイダーの統合および接続された AI モデルの動作は対象外です。
