Red Hat Ansible Automation Platform に関心をお寄せいただきありがとうございます。Ansible Automation Platform は、組織全体のユーザーが、シンプルで強力なエージェントレスの技術的実装により、自動化コンテンツを共有、精査、および管理できるようにします。IT 管理者は、自動化を個々のチームに適用する方法に関するガイドラインを提供できます。一方、自動化開発者は、複雑なツールやフレームワークに準拠するという運用上のオーバーヘッドなしに、既存の知識を使用するタスクを自由に作成できます。これは、ハイブリッドクラウドからエッジまで、エンドツーエンドの自動化ソリューションを展開するためのより安全で安定した基盤です。
Ansible Automation Platform には automation controller が含まれます。これにより、ユーザーは企業全体で自動化を定義、運用、拡張、および委譲できます。
Playbook の実行はリアルタイムで確認でき、チェックインしているすべてのホストが表示されるため、特定のタスクやホストの結果を詳細に調べることが容易になります。特定のタスクやホストを検索してその結果のみを確認することも、修正の必要なエラーのみを簡単に確認することもできます。
Web インターフェースでは、最小限のクリックでお気に入りのプロジェクトにアクセスしたり、実行を再度トリガーできます。automation controller は入力変数を要求し、認証情報を求めるプロンプトを表示し、ジョブのキックオフおよび監視を実行して、一定期間、結果およびホストの履歴を表示します。
Automation controller では、ロールベースのアクセス制御 (RBAC) を使用して、複数の異なるチームや明示的なユーザーに対し、特定のタスク (ファイルの表示、作成または変更など) を実行するパーミッションを付与できます。
一部のプロジェクトをプライベートに設定し、一部のユーザーがチェック (ドライラン) またはライブモードで特定のシステムでのみ Playbook を実行できるようにすることができます。また、特定のユーザーに認証情報を公開しなくても、それらのユーザーが認証情報を使用することを許可することができます。実行内容にかかわらず、automation controller は編集したオブジェクトや起動したジョブを含む操作やそれを実行したユーザーを記録します。
ユーザーフィードバックに基づいて、automation controller のロールベースのアクセス制御が拡張されるとともに、簡素化されました。ジョブテンプレートの表示/非表示の設定は、インベントリー、プロジェクト、認証情報のパーミッションの組み合わせでは指定されなくなりました。ジョブテンプレートを使用するパーミッションをユーザーまたはチームに付与する場合は、ジョブテンプレートに直接パーミッションを付与します。同様に、認証情報は、automation controller の RBAC システム内で完全なオブジェクトとなり、複数のユーザーやチームが使用できるようにそれらに割り当てることが可能になりました。
Automation controller には「監査者」タイプがあります。このタイプには、システムの自動化のすべての側面が表示されますが、自動化を実行したり変更したりすることはできません。自動化の実行や変更にはシステムレベルの auditor パーミッションが必要です (REST API から自動化情報を取得するサービスアカウントにも役立つ場合があります)。詳細は、「ロールベースのアクセス制御」を参照してください。
automation controller の今後のリリースでは、より詳細なパーミッションを設定できるようになり、組織内での委譲が簡単になり、自動化のボトルネックが解消されます。
Automation controller は、ノードが設定をオンデマンドで要求できるようにする強力なプロビジョニングコールバック機能を特長としています。これは任意の機能ですが、Cobber などのプロビジョニングサーバーと統合したり、アップタイムが予測できない管理システムを処理する場合などのクラウド自動スケーリングのシナリオに最適なソリューションとなります。リモートノードに管理ソフトウェアをインストールする必要がないため、コールバックソリューションは、「curl」または「wget」の単純な呼び出しでトリガーでき、init スクリプト、キックスタート、または preseed に簡単に埋め込むことができます。アクセスは、インベントリー内のマシンのみが設定を要求できるように制御されます。
automation controller REST API は、すべてのリソースの完全な検出、ページネーション、検出、およびモデル化を可能にするシステム管理アプリケーションの最適な RESTful API です。設定された API ブラウザーからは、API root (http://<server name>/api/) で API を調査することができ、すべてのリソースおよび関係が表示されます。ユーザーインターフェースで実行できるすべてのこと、またそれ以上のことを API で実行できます。
システムのバックアップやリストア機能が Ansible Automation Platform の設定 Playbook に統合され、必要に応じてインスタンスを簡単にバックアップし、複製できるようになりました。
自動化の説明というコンテキストでは、「Don’t Repeat Yourself」を省略した DRY という表現が頻繁に使用されます。Ansible Galaxy の場合のような Ansible ロールの一元管理されたコピーを使用することで、このアプローチを Playbook に反映することができます。Ansible Galaxy の要件である .yml ファイルをプロジェクトディレクトリーに組み込むと、automation controller は Galaxy、GitHub、またはローカルソースコントロールから Playbook が必要とするロールを自動的に取得します。詳細は、「Ansible Galaxy サポート」を参照してください。
Ansible は 誰にとっても使いやすい OpenStack の作成に取り組んでいます。その取り組みの一環として、OpenStack の動的インベントリーサポートが追加されています。これにより、OpenStack クラウドで実行している仮想マシンまたはイメージのいずれかを簡単にターゲットとして設定できます。
いくつかのホストに 1 つの単純なタスク (単一ユーザーの追加、単一セキュリティー脆弱性の更新、または正常に動作しないサービスの再起動など) のみを実行すればよい場合がよくあります。Automation controller にはリモートのコマンド実行機能が組み込まれ、1 つの Ansible プレイとして定義できるすべてのタスクをインベントリー内のホストまたはホストのグループで実行できるようになりました。システムの管理が迅速かつ容易になり、また RBAC エンジンのサポートおよび詳細な監査ログが提供されるようになったため、誰がどのマシンに何を実行したかなどを改めて調べる必要がなくなりました。
ファクトのキャッシュ機能を使用してファクトを収集できます。詳細は、「ファクトのキャッシング」を参照してください。
automation controller では自動化のステータスを簡単に追跡できるようになりました。ジョブテンプレートやプロジェクト、または組織全体のスタック可能な通知を設定し、ジョブの開始、ジョブの成功、ジョブの失敗、およびジョブの承認 (ワークフローノードの場合) についての各種の通知を設定できます。サポートされる通知ソースは以下のとおりです。
メール
Grafana
IRC
Mattermost
PagerDuty
Rocket.Chat
Slack
Twilio
Webhook (他のツールと統合するには、任意の Webhook に POST 要求を送信)
さらに、上記の通知タイプごとに customize notification messages を行うことができます。
Red Hat Satellite 6 の動的インベントリーソースがサポートされています。
柔軟な Ansible コマンドラインを取り入れることで、以下のいずれかについてのプロンプトを出すことができます。
インベントリー
認証情報
ジョブタグ
制限
automation controller は Red Hat Insights との統合をサポートしています。これにより、Insights Playbook を Tower プロジェクトとして使用できます。
ユーザーインターフェースのレイアウトが再構成され、ナビゲーション要素が改善されました。情報がひと目で分かるように表示され、今まで以上に直感的に、必要な自動化を見つけ出し、使用できるようになります。縮小および展開表示モードでは、必要に応じて情報を表示および非表示でき、さまざまなビルドインの属性を簡単にソートできます。
カスタムの Ansible 環境サポートでは、さまざまなチームやジョブに対して、各種 Ansible 環境を設定し、カスタムのパスを指定できるようになりました。
automation controller では、LDAP、SAML、およびトークンベースの認証がサポートされるようになりました。LDAP と SAML のサポートが強化されたことで、エンタープライズアカウントの情報をこれまで以上に柔軟に統合できるようになります。トークンベースの認証では、統合された OAuth 2トークンサポートを使用して、automation controller でサードパーティーのツールやサービスを簡単に認証できるようになりました。
クラスターグループのランタイム管理では、簡単に設定可能なスケーリングができるようになりました。
Ansible Automation Platform は、Red Hat OpenShift Container Platform のコンテナー化された Pod サービスとして使用できるようになり、必要に応じてスケールアップとスケールダウンが可能になりました。
複雑なプロビジョニング、デプロイメント、オーケストレーションのワークフローのモデル化を向上するため、automation controller は複数の方法でワークフローの機能を拡張しました。
ワークフローのインベントリーの上書き: ワークフローの定義時間または起動時に、ワークフロー全体のインベントリーを上書きできるようになりました。アプリケーションデプロイメントを定義した後に、簡単に複数の環境で再利用できます。
ワークフローの収束モード: 複雑なプロセスをモデル化する時に、場合によっては、続行する前に複数のステップが完了するまで待つ必要があります。現在、automation controller のワークフローでこれを簡単に複製できるようになり、前のワークフローの手順が複数完了するのを待ってから続行できるようになりました。
ワークフローのネスト化: 規模のより大きいワークフローのコンポーネントとして、個別のワークフローを再利用します。たとえば、プロビジョニングとアプリケーションデプロイメントワークフローを 1 つのマスターワークフローに統合する場合などです。
ワークフローの一時停止および承認: ユーザーの介入が必要な承認ノードを含むワークフローを構築できます。これにより、ユーザーが Playbook 間でワークフローを停止して、ワークフローの次のステップに進むための承認 (または拒否) ができるようにします。
自動化が企業全体に広がると、自動化の規模を拡大する必要があります。Automation controller では、何千台ものマシンからファクトを収集して設定ジョブを実行し、個別のジョブスライスに分割して、automation controller クラスターに分散することで、信頼性の向上、ジョブの完了時間の短縮、クラスターの使用率の上昇などを図ることができます。大規模な環境において 15000 個のスイッチ全体でパラメーターを変更したり、何千ものノードがある RHEL のエステートで情報を収集する必要がある場合に、簡単に実現できるようになります。
FIPS など制限のあるモードで環境を実行する必要がある場合に向け、automation controller では、このような環境でデプロイと実行が行います。
大規模な組織の多くが、多数の組織間でインスタンスを共有しています。1 つの組織で全ライセンスホストが利用されてしまわないように、スーパーユーザーはこの機能を使用して、各組織に割り当て可能なライセンスホスト数の上限を指定できます。automation controller アルゴリズムは、組織内の制限や、全組織に存在する合計ホスト数に加えられた変更を組み込みます。インベントリーを同期することで組織がポリシーに準拠しなくなった場合、インベントリー更新は失敗します。さらに、スーパーユーザーは、警告付きで、上限以上のライセンスを割り当てることができます。
インベントリーの更新が Ansible 2.9 で実行されている場合は、アップストリームコレクションの以下のインベントリープラグインを使用するように automation controller を更新
amazon.aws.aws_ec2
community.vmware.vmware_vm_inventory
azure.azcollection.azure_rm
google.cloud.gcp_compute
theforeman.foreman.foreman
openstack.cloud.openstack
ovirt.ovirt.ovirt
awx.awx.tower
シークレット管理システムでは、外部の認証情報が保存されて、automation controller で使用できるようにし、直接指定する必要がありません。
Automation Hub will act as a content provider for automation controller, which requires both an automation controller deployment and an Automation Hub deployment running alongside each other.