Red Hat Ansible Automation Platform 2 のお客様への提供が開始されました。リリースされた Red Hat Ansible Automation Platform 2 は、組織全体の自動化の可能性を広げ、より安全で柔軟な基盤により、より高速で、良好なオーケストレーションで、革新的な自動化を構築、展開できます。

自動化の使用法、実践などが組織全体に広がるにつれて、さまざまなチームやユースケースに用いられている複数の自動化環境を管理することが困難になっていき、自動化が IT 組織全体に拡張し始めると、この難しさはより一層深まります。自動化は、継続的に重大ワークフローの一部であり続けるため、Ansible Automation Platform 2 では、以下のような機能強化が行われています。

  • Ansible Automation Platform 管理者が、ネットワークチームやクラウドチームなど、さまざまなグループに自動化実行環境(以下参照)を提供し、さらに管理できるようになります。一人一人が、それぞれの役割に固有のコンテンツに対するニーズを持っているので、個人として種々の複数環境に対応しなくてもよくなります。
  • 自動化開発者に、本番環境と同じ一貫性のある Ansible 環境を提供。これにより自動化開発者は、自動化環境と依存関係についての懸念が解消され、自動化コンテンツそのものにより深く集中できるようになります。
  • 自動化チームが、自動化環境を定義、構築、更新できるようになり、これに伴うプラットフォームの変更の際も、プラットフォーム管理者への連絡が不要になります。
  • 自動化実行環境を個人用の自動化ハブを介して構築、配布が可能で、なおかつ組織内の複数チーム間での一貫性と使いやすさを実現します。
  • サードパーティの開発者とパートナーが、新しくリリースされた ansible-builder コマンドラインツールを使用して、そのユーザーと顧客向けに独自の自動化実行環境を作成できるようになります。

自動化実行環境とは?

一貫性のある信頼性の高い自動化を実現することは、自動化の取り組みを成功へと導く鍵です。Ansible Automation Platform をお使いのとあるお客様においては、さまざまなチームが存在するため、管理チームは40を超える別々の仮想環境をメンテナンスしていました。複数の人々が別々のバージョンの Ansible を使用していたネットワークチームは、それぞれの特定デバイス用に別々の自動化コンテンツ(および依存関係)を必要とし、一方で開発チームは、テスト用に自分用の環境を構築していました。これらの環境をサポートし、維持するには、特定の Python 仮想環境の事実上のソリューションを示すドキュメントしか手段がなく、プラットフォームツールはありませんでした。

その結果、カスタム環境数が急増し、開発と本番の間で ドリフトが発生し、自動化のコストと複雑さが増加しました。さらに、プラットフォーム管理者には、すべてが運用可能となるようにメンテしながら記録をも残すという負担が重くのしかかりました。Ansible Automation Platform 2 は、自動化実行環境という新しい構造モデルを導入しています。各自動化実行環境は、すべての自動化が実行されるアトミック・イメージです。
各自動化実行環境は、以下の通りです。

  • RHEL UBI 8
  • Ansible 2.9 もしくは Ansible Core 2.11
  • Python 3.8
  • 任意の Ansible Content Collection
  • Collection python もしくは バイナリ依存関係

これにより、自動化を実行する環境を定義、構築、配布できる標準化された方法が実現されます。一言で言えば、自動化実行環境は、プラットフォーム管理者が簡単に Ansible を管理できるコンテナ・イメージです。

Ansible Automation Platform 2.0 における自動化実行環境の役割

Automation controller 4.0 architecture

自動化実行環境への移行は、Red Hat のアプローチの一環として、自動化開発者と管理者がより高い拡張性を実行できるよう、制御プレーンを実行プレーンから分離することです。自動化チームは、それぞれの自動化が複数のプラットフォーム間で一貫して実行できることを要求します。カスタム依存関係はすべて開発フェーズで定義されるようになり、もう管理、展開フェーズで定義されることはなくなります。

自動化の実行を制御プレーンから切り離すことで、開発サイクルの高速化、拡張性、信頼性、および環境間での移植性が実現します。自動化実行環境により、Ansible Automation Platform を分散アーキテクチャに移行できるようになったため、お客様は組織全体に自動化を拡張できます。

ansible-builder とは何か?

自動化実行環境とそのメリット、そして Ansible Automation Platform 2 のリリースで果たす役割について理解できました。では、実際にどのように構築すればよいのでしょうか? ansible-builder は、 Ansible のコンテンツ作成者や Ansible Automation Platform の管理者が、自動化実行環境を活用できるようにするために作成されました。ansible-builder は、さまざまな Ansible Content Collection で定義された依存関係情報、そしてユーザーが定義した依存関係情報を使用して作成します。

上記 UBI8 と Ansible Automation Platform 2 のリリースにより、Red Hat Container Registry で利用可能な、予備構築済みのサポートされた自動化実行環境の一式セットがあります。これらのイメージは、組織の環境でさまざまな容量で使用でき、Ansible Automation Platform サブスクリプションの一部として提供されます。サポートされている自動化実行環境は、registry.access.redhat.com の ansible-automation-platform-20-early-access という親リポジトリでホストされています。
以下の事前に構築された環境が利用可能となっています。

  • Minimal(ee-minimal-rhel8)- UBI8 と python-3.8 の上に構築された Ansible-2.11 を含みます。このイメージはCollectionを含んでいません。このイメージをベースイメージとして、カスタムコレクションや、自動化ハブで利用可能な Ansible Certified Content Collections を使って、追加の自動化実行環境を構築することができます。
  • Supported (ee-supported-rhel8) - これは、自動化コントローラーで使用可能なデフォルトのイメージです。ミニマル・イメージ上に構築され、Red Hat がサポートする Ansible Content Collections を含みます。
  • Ansible 2.9 (ee-29-rhel8) - Ansible-2.9と必須のAnsible依存関係をすべて含みます。このイメージは、Ansible Automation Platform1.2からAnsible Automation Platform 2.0への移行を計画しているお客様に最適です。実行環境ビルダー(ansible-builder)を使用して、Ansible Automation Platform 2 を備えたイメージ上にレイヤー化することにより、カスタム自動化実行環境を構築できます。

ansible-builder の過去ブログをご確認いただき、カスタマー・ドキュメントのこのセクションを確認して、Ansible Automation Platform が提供するデフォルトの環境上に自分用の自動化実行環境を構築する方法をご理解ください。

ansible-builder を使うのは誰か?

自動化実行環境は、Ansible コンテンツ作成者と自動化プラットフォーム管理者の間の共通アーチファクトです。両社はいずれも、ansible-builder を用いた構築方法を理解する必要があります。コンテンツ作成者は、プラットフォーム管理者に自動化実行環境を提供します。その逆も同様です。ただし、ここで留意すべき共通のテーマは、「最終的な目標は、同じ自動化実行環境をコンテンツ作成者の開発マシンから本番環境に移行すること」です。その結果、複数の Python 仮想環境を手動で管理する必要がなくなります。

重要ポイント

今回リリースされた Ansible Automation Platform 2 には、自動化実行環境の概念を補完するために構築された、数え切れないほどの新機能が盛り込まれています。今回のリリースで、以下が可能となります。

  • 自動化実行環境を個人用の自動化ハブを介して構築、配布が可能、なおかつ組織内の複数チーム間での一貫性と使いやすさを実現します。
  • サードパーティの開発者とパートナーたちが、新しくリリースされた ansible-builder コマンドラインツールを使用して、そのユーザーと顧客向けに独自の自動化実行環境を作成できるようにします。

次の行先


About the author

Anshul is a Senior Software Engineer at Red Hat who is responsible for helping the ansible partners take the journey of creating an Ansible Integration for their product and certifying that integration with Ansible.

Read full bio