レッドハットの杉村です。Ansible のテクニカルサポートをしています。
この記事は Ansible Advent Calendar 2022 の9日目の記事です。
Ansible Automation Platform (AAP) は比較的足の速い製品で、頻繁に新しいリリースを出しています。リリース後およそ1年半でサポート終了 (End Of Life, EOL) となるため、いつもアップグレードをお願いしているという状態になっています。実際の問い合わせでもアップグレードについての問題が結構な数を占めます。
今回の記事では、新しいバージョンを使うと何がうれしいのか、古いバージョンを使い続けるとどのように困るのかということについてまとめてみました。
ライフサイクル
AAP のライフサイクルはこちらのサイトにバージョンごとにまとめています。
リリースから EOL まで、いくつかのフェーズを段階的に経るようになっています。
ソフトウェアの更新には大きく分けますと3つの種類がありまして、フェーズごとに対象のものが異なっています。
- RHSA (Security) : セキュリティ問題
- RHBA (Bug Fix) : 不具合
- RHEA (Enhancement) : 機能改善
他の製品のライフサイクルについてはこちらのサイトから探してください。
General availability
リリース日です。この日を起点として、各フェーズが進んでいきます。カスタマーポータルからダウンロードできるようになった日です。
AAP のダウンロードはこちらです。カスタマーポータルのアカウントをお持ちであればダウンロードしていただけます。
https://access.redhat.com/downloads/content/480/access.redhat.com
Full Support Phase
半年程度はこのフェーズとして設定されます。
- RHSA (Security) : セキュリティ問題 ... 全てが対象
- RHBA (Bug Fix) : 不具合 ... 致命的で重大度の高い修正や、その他の修正できた不具合を提供
- RHEA (Enhancement) : 機能改善 ... 利用可能になった機能改善の修正を提供
なお、機能改善要求は非常に多くの数を受けておりまして、開発リソースの制約などから優先度をつけて対応しています。主な指標としてはこのようなものがあります。
- リクエストの数
- 実装の難易度
- 他の回避方法や実現方法の有無
- ビジネスの重大度
社内のエンジニアリングチームが実装するものだけでなく、Upstream プロジェクトで OSS として開発されたものが取り込まれることも日常的に行われています。
Maintenance Support 1 Phase
リリースから半年ほど経過してこのフェーズになりますと、修正が提供される範囲が少々狭まります。
重大な不具合であっても致命的ではないものや、機能改善についての修正は原則として提供されません。
Maintenance Support 2 Phase
リリースから1年が経過しますとこのフェーズになります。基本的にはセキュリティ問題の修正のみを提供します。
End Of Life
Maintenance Support 2 が終了しますと、End Of Life (EOL) となります。一切の修正は提供されません。
サブスクリプションをご契約いただいている間はカスタマーポータルからドキュメントを検索したり製品ドキュメントをご参照いただくことはできますが、テクニカルサポートからの案内としてはサポートできるバージョンにアップグレードするようお願いすることのみとなります。
このように1年から1年半ほどでほとんど修正もされなくなりその後はほとんど何もお手伝いできなくなりますので、もしアップグレードを適用するために半年以上の計画が必要なことがありましたら、常時準備していただくくらいに構えておくことをお勧めします。
サポートエンジニア側としても EOL となった製品については教育を行っていないことがあるため、問い合わせされましても期待されるような回答が得られない場合があります。
AAP の構成要素
AAP は昔の印象ですと Ansible Tower + Ansible Engine と捉えていらっしゃる方が多いように思いますが、現在は多くのプロダクトから構成されています。
下記に掲載するもの以外にも、ここでは触れていないものもあります。
Ansible automation controller
Upstream の AWX を元にしています。昔は Ansible Tower と呼ばれていたものです。
AWX のリリースと controller のリリースは同期しておらずソースコードも別々に管理しているため、AWX の修正がいつ controller に入っているのかというお問い合わせに回答することが難しいことがあります。
また、AWX は Kubernetes 環境で動作するようになっていますが、controller はコンテナ実行環境の OpenShift に加えて、RHEL でも動作させることができるという違いがあります。
controller の機能もさらに分割して役割別(hybrid, hop, execution)に構成を分けることができるのですが、今回の記事では触れません。そのような Automation Mesh の機能を提供する receptor についてはリンクだけ紹介しておきます。
Execution Environments
Ansible Core を含む実行環境です。以前の Ansible Engine に相当します。
Upstream のリポジトリはこちらです。AWX とは異なり、Ansible Core の部分については製品として配布しているものと大きな違いはありません。
Execution Environments (EE) は Podman のコンテナイメージとなっていて、Ansible Core 以外にもさまざまなものがインストールされています。コンテナイメージとして固まっていることで、Ansible の処理を行うための雑多な環境構築作業から解放されて playbook などを書くことに専念できるようになっています。AAP 2.3 では主にこれらのパッケージがインストールされています。
- RHEL 8.7 ベース
- Python 3.9.13
- Ansible Core 2.14.0
- Ansible Runner 2.3.0 https://github.com/ansible/ansible-runner
- Ansible Lint 6.8.2 https://github.com/ansible/ansible-lint
- Ansible Sign 0.1.1 https://github.com/ansible/ansible-sign
- サポートする Ansible Collections やそのために必要な Python のライブラリ
Ansible Navigator
EE のコンテナイメージを使って playbook などを実行するためのコマンドラインツールです。
昔は ansible-playbook コマンドで実行することがよくありましたが、実行のために必要な構成が複雑になったことにより、コマンドラインからはこの ansible-navigator を使って実行することを主に案内しています。
Upstream はこちらです。
Ansible Builder
提供している EE では機能が足りない場合や、特別な設定を入れてカスタマイズしたい場合などに使うツールです。作成した EE は controller に登録して使うこともできます。
Upstream はこちらです。
Private Automation Hub
collections や EE を格納するためのリポジトリを提供します。これらの Upstream プロジェクトが元となっています。
- pulp https://github.com/pulp/pulpcore
- galaxy_ng https://github.com/ansible/galaxy_ng
- ansible-hub-ui https://github.com/ansible/ansible-hub-ui
- pulp_container https://github.com/pulp/pulp_container
- pulp_ansible https://github.com/pulp/pulp_ansible
Red Hat Hybrid Cloud Console 上で稼働する SaaS
インターネットに接続されている環境で controller をお使いであれば、SaaS で提供している機能もご利用いただけます。
- Automation Hub
- Automation Analytics
- Red Hat Insights との連携
機能差分の追いかけ方
世界的なイベントとして Ansible Fest を毎年開催しておりまして、新しいバージョンがこのイベントに合わせて出てくることが多いです。
Upstream の各プロジェクトに詳しい方の中には「そろそろこんな機能が出そうだ」ということがわかってしまう方もいらっしゃるかもしれませんが、イベントのために計画しているようなものの場合は特に、言いたくても言えないことがあったりします。
実際に AAP としてのリリースが出ますと、ブログ として掲載されることが多いようです。AAP 2.3 のときはこの記事などがありました。
automation controller や Ansible Core の機能をお使いの方がほとんどだと思いますので、普段追いかけるときにはリリースノートを追っていくのがわかりやすいです。
automation controller はこちらです。
Ansible Core はブランチごとになっていまして、例えば 2.14 ですとこちらです。以前のバージョンを確認したいときは、changelogs/ のディレクトリでブランチを切り替えて CHANGELOG-vX.Y.rst のファイル名になっているものを参照してください。
Changelog 以外にも porting guides としてまとまっているドキュメントがありまして、新しいバージョンを使うときの互換性について気になる方はこちらのほうが便利なことがあります。バージョン番号の付け方が Ansible と Ansible Core で混乱することがありますが、いろいろな事情でこのようになっています。
まとめ
今回は AAP の構成やライフサイクルなどについて紹介しました。
新しいリリースが頻繁に出るものでサポートする側としても大変ではあるのですが、特に大規模なユースケースでお使いの方には効果的な機能が多く追加されている傾向にありますので、ご活用いただけましたらと思います。
Ansible Automation Platform の評価ライセンスリクエストはこちらからご利用いただけます。60日間利用できます。
Happy Automation!
