Red Hat Ansible Automation Platform 2Red Hat Ansible Automation Platform 2 は、Red Hat の信頼できるエンタープライズ・テクノロジーの専門家が手掛けた次世代の自動化プラットフォームです。今回リリースされる Ansible Automation Platform 2 に、Red Hat Ansible Tower が改良を経て改名された、自動化コントローラー 4.0 が搭載されることをお知らせできることを嬉しく思います。

自動化コントローラーは、企業全体で自動化を定義、運用、および委任するための標準化された方法を提供します。また、新しく刺激的なテクノロジーと強化されたアーキテクチャを導入し、自動化チームが迅速に自動化を拡張、提供できるようにし、増加するビジネスニーズに対応します。

なぜAnsible Towerは、自動化コントローラーへと改名されたのか?

Ansible Automation Platform 2 が進化を続けるにつれ、特定の機能が、これまで Ansible Tower として知られていたものから切り離されてきました(2.1 でも継続して切り離される予定)。

今回の呼称の変更は、これらの機能強化と Ansible Automation Platform スイート内での全体的な位置づけをより適切に反映させるためのものです。

自動化コントローラーを使うのは誰か?

自動化チームのメンバーはすべて、直接的または間接的に自動化コントローラーと対話するか、自動化コントローラーに依存します。

  • 自動化の作成者たちは、Ansible Playbook、各役割、およびモジュールを開発します。

  • 自動化アーキテクトたちは、チーム全体の自動化を向上して、IT プロセスに合わせ、採用を合理化します。

  • 自動化オペレーターたちは、自動化プラットフォームとフレームワークが運用可能であることを実証します。

これらの役割は、必ずしも個人またはチームが特化して負う役割ではありません。多くの組織は、複数の役割を複数の人に割り当てたり、そのニーズに基づいて特定の自動化タスクを外部に委託したりしています。

概して自動化オペレーターは、その責任に基づき自動化コントローラーと直接対話できる、最上位に就く個人です。

このブログでは、自動化コントローラーにおいて改善されたアーキテクチャ、強化された機能、そしてこれらがどのように役立つかをご説明します。

アーキテクチャの改善点

自動化コントローラーが持つ改善された分散型アーキテクチャにより、自動化オペレーターは、多様に異なるさまざまなプラットフォームにインスタンスをデプロイできるようになり、自動化を迅速に拡張して、ますます増大する需要に対応できます。

以前のAnsible Tower のアーキテクチャと、アップデートされたコントローラーのアーキテクチャとを比較してみましょう。

以前の Ansible Tower3.8 のアーキテクチャー
Ansible Tower architecture

Ansible Tower アーキテクチャ

堅固で緊密な結合

自動化チームは、自律的に、またその他の場合には協調と共同で、成果を提供する必要があります。

Ansible Tower アーキテクチャは、制御プレーンと実行プレーンを緊密に結合しているが、需要が高く、これを満たすためにスケーリングするときに、オーバーヘッドが高まり効率が低下することがあります。

たとえば、ネットワークチームが netaddr 0.7.20 Python パッケージに依存する新しい自動化コンテンツを作成する場合を考えてみましょう。セキュリティチームは、それより新しいバージョンの netaddr を使用して自動化を開発していたとします。両方のチームが自動化を正常に実行するには、それぞれチームに一意の netaddr バージョンが必要です。自動化オペレーターは、多大な時間を費やして別々のバージョンの netaddr が利用可能か否か、なおかつ Ansible Automation Platform インスタンス全体で一貫しているか否かを確認するか、もしくは各チームとそれぞれの依存関係を共同で管理します。

さらに多くのチームが参加し、デプロイされたインスタンスが増加し、自動化コンテンツが拡大するにつれて、実行の一貫性の保証に必要なオーバーヘッドがどんどん増加していく様を想像してみてください。

一貫性のない実行

自動化チームは、自動化コンテンツが企業全体で一貫して実行されることを実証する必要があります。

オペレーターたちは、一貫した自動化を実行するために、別々の Ansible Automation Platform インスタンス間で依存関係をデプロイし、管理するための補助ツールを必要としています。

これらの依存関係には、Python パッケージ、Python バージョン、フレームワーク、Ansible コンテンツが含まれることがあります。

Ansible Tower は Python 仮想環境を使用して依存関係を管理していましたが、この方法では課題がありました。

  • 複数の Ansible Tower インスタンスにわたって Python 仮想環境を管理すると、非本番システムと本番システムとで一貫性が失われるのを防ぐために付加的な労力が必要になったため、開発サイクルが遅くなっていました。

  • カスタム依存関係が Ansible Tower インスタンス全体で一貫していることを裏付けようとすると、デプロイメントが増えるにつれて、そしてより多くのユーザーがそれとやり取りするにつれて、複雑さが増します。

  • Python 仮想環境は、Ansible Tower インスタンス間での移植が困難であり、コントロールプレーンに緊密に結合されていました。

  • Ansible Automation Platform デプロイメント全体のカスタム依存関係を管理するために、Red Hat によってサポートされ、保守されるツールはありません。

私たちはフィードバックに耳を傾け、認識していましたが、自動化のスケーリングは困難でした。これに対応して、私たちは、改善された分散型アーキテクチャを導入しているところです。

新しく改良された自動化コントローラー 4.0 アーキテクチャー

自動化チームは、ビジネス上それが必要となるなら、時と場所を選ばずに、迅速に自動化を提供しなければならず、自分が属する組織の自動化を支援して成長する必要があります。

自動化コントローラーは、制御プレーンと実行プレーンが分離された分散型のモジュラー・アーキテクチャを導入します。これにより各チームは、オーバーヘッドを低減し、速度を増しながら自動化を拡張し、提供できるようになります。

Automation controller 4.0 architecture

自動化コントローラー4.0アーキテクチャー

自動化実行環境

移植性は信頼性

Ansible Automation Platform 2 は、自動化実行環境を導入します。自動化実行環境は、自己完結型イメージで、ここで Ansible Core、Ansible コンテンツ、追加の依存関係など、すべての自動化が実行されます。

 

Automation execution environments

自動化実行環境

自動化実行環境を使用すると、複数のプラットフォーム全体で一貫した自動化が実行できます。カスタム依存関係はすべて開発フェーズで定義され、もはや制御プレーンに緊密に結合されることはなくなります。その結果、開発サイクルが高速化され、スケーラビリティ、信頼性、および環境間での移植性が向上します。

自動化実行環境の詳細については、Anshul Behl が書いたこのブログをご参照ください。

PostgreSQL 12

Ansible Automation Platform 2 には、Red Hat Enterprise Linux 8 モジュールからインストールされた PostgreSQL12 がデフォルトで添付されています。

PostgreSQL 12 では、多数の重要な改良が行われました。特に、Ansible Automation Platform 2 では、パーティション化されたアクセスを採用し、パフォーマンスが向上しています。

自動化コントローラーのインストール

自動化チームには、ハイブリッドクラウドにまたがる単一の自動化ソリューションが必要です。

Ansible Automation Platform 2 は、物理環境、仮想環境、コンテナ化環境の全体で、慣れ親しんだインストール・エクスペリエンスを提供し続けます。

Ansible Automation Platform Operator

Ansible Automation Platform 2 は、Ansible Automation Platform Operator を導入しており、OpenShift 環境に、新しい Ansible Automation Platform インスタンスのクラウドネイティブ型のプッシュボタン・デプロイメントを提供します。

Ansible Automation Platform Operator では、データ管理、データ移行、プラットフォームが容易にアップグレードできます。さらに、リソース・オペレーターで、自動化をクラウドネイティブ・プロセスに簡単に統合できます。

ユーザー・インターフェース・エクスペリエンス

自動化コントローラーのユーザー・インターフェースは、多くの改良が加えられている一方で、使い慣れた操作感を提供しており、Ansible Automation Platform 2 への移行や導入が簡単にできます。

PatternFly 4

インターフェースには、PatternFly 4 フレームワークを使用しています。この変更により、パフォーマンスが向上し、ほかの Ansible Automation Platform 2 コンポーネントや Red Hat オファリングとの整合性が確保されます。

Automation controller 4.0 dashboard

自動化コントローラー4.0ダッシュボード

可観測性、相互作用、セキュリティの向上

改良されたインターフェースでは、自動化コントローラーのオブジェクトとコンポーネントの明瞭で見分けやすい表示と編集用の一覧表示が導入されました。これは、お客様からたくさんのリクエストをいただいた機能です。

Distinct view and edit perspectives

明瞭で見分けやすい表示と編集用の一覧表示

また、自動化コントローラーは、直感的に使用できるフィルターも提供しており、これを自動化オペレーターが使用すると、現在実施中のタスクに関連する情報を簡潔に表示できます。

Ansible Automation Platform Operator は、自動化コントローラー 4.0 の Job 出力をフィルター処理して、以下に例示の「 Host Unreachable 」イベントを表示します。これにより、エラーの特定と修正が簡単にできます。

Automation controller 4.0 job output filter

自動化コントローラー4.0のJob出力をフィルター処理

コンテンツ・セキュリティ・ポリシー

自動化コントローラーのインターフェースは、厳格なコンテンツ・セキュリティ・ポリシーを含むよう設計し直されており、一般的なサイバーセキュリティの脅威を検出し、軽減する保護レイヤーが追加されています。

追加の機能強化

自動化コントローラー 4.0 は、閲覧可能な API、役割ベースのアクセス制御、ジョブ・スケジューリング、統合された通知、グラフィカルな在庫管理、ワークフロー視覚化機能など、プラットフォーム全体にわたる改良がなされています。

このほか、このブログに載せきれない機能強化の一覧は、以下です。

  • Python 3.8 使用の自動化コントローラー

  • Nginx はバージョン 1.18 に更新され、RHEL 8 暗号化プロファイルを使用

  • 自動化オペレーターは、ローカルユーザーを自動化コントローラー 4.0 に追加する機能の無効化が可能で、設定された ID プロバイダーを介した認証のみを許可可能

  • 自動化コントローラー4.0は、新しい Prometheus メトリクスを提供し、ジョブイベントのパフォーマンスを追跡し、デバッグ

  • オペレーターは、追加の awx-manage サブコマンドを使用して、ホスト自動化の詳細を抽出可能

  • GitHub Enterprise は、サポートされているIDプロバイダー

Automation Controller 4.0 が導入する変更の詳細については、automation controller release notes をご確認ください。

移行時の検討事項

Ansible Automation Platform 2 は刺激的な新機能を提供します。ただし、これらの変更に伴い新たな要件と依存関係が発生するため、Ansible Automation Platform 2 に移行する前に、これらを慎重に検討する必要があります。以下は、本ブログで取り上げたトピックに関連する重要な検討事項です。自動化コントローラーのインストールページで、すべての要件を必ずご確認ください。

Ansible Automation Platform 2 は分離ノードをサポートするか?

Ansible Automation Platform 2.0(現在利用可能)は、分離ノードをサポートしていないものの、Ansible Automation Platform 2.1 ロードマップにはこの機能が含まれており、2021 年 11 月にリリースされる予定です。

Ansible Automation Platform 2 は以前の PostgreSQL バージョンをサポートしているのか?

いいえ、サポートしていません。現在、Ansible Automation Platform 2 でサポートされているデータベースは、PostgreSQL 12 のみです。移行計画を作成する際は、この点にご注意ください。

実行環境を実行するには、RedHat OpenShiftが必要か?

いいえ、必要ありません。Ansible Automation Platform をすべての Red Hat プラットフォームに対応させることは、私たちの重要な使命です。Ansible Automation Platform 2 は、データセンター、クラウド、エッジなどのニーズに合わせて、Red Hat Enterprise Linux(x86_64)、Red Hat OpenShift、またはその両方を組み合わせて導入することができます。

Ansible Automation Platform 2 のインストールでサポートされているオペレーティング・システムは何か?

Ansible Automation Platform 2 は、物理環境または仮想環境へのインストールにおいて、Red Hat Enterprise Linux 8.3(x86_64)以降をサポートします。

重要なポイント

多くの組織は、自動化の拡張ができないため、自動化の潜在能力を十分に認識していません。

IT システムが進化し続け、自動化の導入が進むにつれて、自動化の範囲の拡大に対する需要が高まっています。Automation controller 4.0 には、自動化チームが拡張性を高めてこのような需要を満たすことに重点を置いた新機能が搭載されています。

私たちの目標は、簡単に Ansible Automation Platform 2 へ移行、採用できるようにすることです。

自動化コントローラー 4.0 とその機能を紹介するにあたり、自動化チームが慣れ親しんでいるエクスペリエンスを提供し、物理、仮想、コンテナ化などの複数のインストール・プラットフォームを引き続きサポートしています。

自動化コントローラーの新しいアーキテクチャは、自動化の実行環境を活用し、依存関係の管理を簡素化し、信頼性と一貫性を向上させ、Ansible Automation Platform インスタンス全体にわたる配信を加速します。

自動化コントローラーのアップグレードされたユーザーインターフェースは、新しいフィルタリング機能と明確でわかりやすい表示により、セキュリティとパフォーマンスを向上させ、観測性を向上させます。

Ansible Automation Platform Operator は、Red Hat OpenShift 上で Ansible Automation Platform 2 インスタンスをクラウドネイティブにデプロイし、その管理を行います。

さらに、リソース・オペレーターは、自動化をクラウドネイティブ・プロセスに簡単に統合できます。

今回リリースされた Ansible Automation Platform 2 は、自動化コントローラー 4.0 を搭載し、多くの新しい刺激的なテクノロジーが導入され、自動化チーム、ビジネスの意思決定者、エンドユーザーのいずれもが慣れ親しんだエクスペリエンスを向上させます。

Red Hat Ansible Automation Platform

Red Hat Ansible Automation Platform

次の行先


About the author

Craig Brandt is a Principal Technical Marketing Manager for Ansible Automation Platform. Prior to this position, Craig served as a Solution Architect representing Red Hat at the IBM Services Integration Hub. He focused on large, complex deals that covered EMEA, LATAM and Canada regions. He brings over 16 years of experience in the IT field that covers automation, containerisation, management, operations, development and solution design

Read full bio