Ansible Tower に興味を持っていただきありがとうございます。Tower は、オープンソース IT オーケストレーションエンジンである Ansible の Web インターフェースおよび REST API エンドポイントからアクセスできるグラフィック対応のフレームワークです。操作タスクをチームと共有する場合でも、Tower REST API で Ansible と統合する場合でも、Tower は自動化を容易にするための強力なツールを数多く提供します。
Playbook の実行はリアルタイムで確認でき、チェックインしているすべてのホストが表示されるため、特定のタスクやホストの結果を詳細に調べることが容易になります。特定のタスクやホストを検索してその結果のみを確認することも、修正の必要なエラーのみを簡単に確認することもできます。
Web インターフェースでは、最小限のクリックでお気に入りのプロジェクトにアクセスしたり、実行を再度トリガーできます。Tower は入力変数を要求し、認証情報を求めるプロンプトを出し、ジョブのキックオフおよび監視を実行して、一定期間、結果およびホストの履歴を表示します。
Ansible Tower では、ロールベースのアクセス制御 (RBAC) を使って、複数の異なるチームや明示的なユーザーに対し、特定のタスク (ファイルの表示、作成または変更など) を実行するパーミッションを付与できます。
一部のプロジェクトをプライベートに設定し、一部のユーザーがチェック (ドライラン) またはライブモードで特定のシステムでのみ Playbook を実行できるようにすることができます。また、特定のユーザーに認証情報を公開しなくても、それらのユーザーが認証情報を使用することを許可することができます。実行内容にかかわらず、Tower は編集したオブジェクトや起動したジョブを含む操作やそれを実行したユーザーを記録します。
ユーザーフィードバックに基づいて、 Ansible Tower のロールベースのアクセス制御が拡張されるとともに、簡素化されました。ジョブテンプレートの表示/非表示の設定は、インベントリー、プロジェクト、認証情報のパーミッションの組み合わせでは指定されなくなりました。ジョブテンプレートを使用するためのパーミッションをユーザーまたはチームに付与する場合は、ジョブテンプレートに直接パーミッションを付与します。同様に、認証情報は、Tower の RBAC システム内で完全なオブジェクトとなり、複数のユーザーやチームが使用できるようにそれらに割り当てることが可能になりました。
「監査者」タイプが新しく Tower に追加されました。このタイプには、システムの自動化のすべての側面が表示されますが、自動化を実行したり変更したりすることはできません。自動化の実行や変更にはシステムレベルの auditor パーミッションが必要です (Tower API から自動化情報を取得するサービスアカウントにも役立つ場合があります)。詳細は、ロールベースのアクセス制御 を参照してください。
Ansible Tower の今後のリリースでは、より詳細なパーミッションを設定できるようになり、組織内での委譲が簡単になり、自動化のボトルネックが解消されます。
Tower の特長として、強力なプロビジョニングコールバック機能が挙げられ、この機能により、ノードがオンデマンドで設定を要求できます。これはオプションの機能ですが、Cobber などのプロビジョニングサーバーと統合する場合や、アップタイムが予測できない管理システムを処理する場合などのクラウド自動スケーリングのシナリオに最適なソリューションとなります。リモートノードに管理ソフトウェアをインストールする必要がないため、このコールバックソリューションは、「curl」または「wget」の単純な呼び出しでトリガーでき、init スクリプト、キックスタートまたは preseed に簡単に埋め込むことができます。インベントリー内のマシンのみが設定を要求できるように、アクセスが制御されます。
Tower REST API は、全リソースがすべて検出可能でページネーションされており、検索可能なだけでなく、適切にモデル化されており、システム管理アプリケーションに理想的な RESTful API となっています。styled API ブラウザーからは、API root ( http://<Tower server name>/api/) で API を調査することができ、すべてのリソースおよび関係が表示されます。ユーザーインターフェースで実行できる操作以上のことが API では実行できます。
システムのバックアップやリストア機能が Tower の設定 Playbook に統合され、必要に応じて Tower インスタンスを簡単にバックアップし、複製できるようになりました。
自動化の説明というコンテキストでは、「Don’t Repeat Yourself」を省略した DRY という表現が頻繁に使用されます。Ansible Galaxy の場合のような Ansible ロールの一元管理されたコピーを使用することで、このアプローチを Playbook に反映することができます。Ansible Galaxy の要件である .yml ファイルをプロジェクトディレクトリーに組み込むと、Tower は Galaxy、GitHub、またはローカルソースコントロールから Playbook が必要とするロールを自動的に取得します。詳細は、Ansible Galaxy サポート を参照してください。
Ansible は 誰にとっても使いやすい OpenStack の作成に取り組んでいます。その取り組みの一環として、OpenStack の動的インベントリーサポートが追加されています。これにより、OpenStack クラウドで実行している仮想マシンまたはイメージのいずれかを簡単にターゲットとして設定できます。
いくつかのホストに 1 つの単純なタスクのみを実行すればよい場合がよくあります。たとえば、これには単一ユーザーの追加、単一セキュリティー脆弱性の更新、または正常に動作しないサービスの再起動などが含まれます。バージョン 2.2.0 以降、Tower にはリモートのコマンド実行機能が組み込まれ、単一の Ansible プレイとして定義できるすべてのタスクをインベントリー内のホストまたはホストのグループで実行できるようになりました。システムの管理が迅速かつ容易になり、また Tower の RBAC エンジンのサポートおよび詳細な監査ログが提供されるようになったため、誰がどのマシンに何を実行したかなどを改めて調べる必要がなくなりました。
Ansible Tower バージョン 3.2 以降でシステム追跡 (履歴ファクト) 機能が非推奨となりました。ただし、ファクトキャッシュ機能を使用してファクトを収集できます。詳しい情報は、ファクトのキャッシング を参照してください。
バージョン 3.0 より、Ansible Tower では自動化のステータスを簡単に追跡できるようになりました。ジョブテンプレートやプロジェクト、または組織全体のスタック可能な通知を設定し、ジョブの成否についての各種の通知を設定することができます。Slack、メール、 SMS (Twilio 経由)、HipChat、Pagerduty、IRC、Webhook (他のツールへの統合の場合は任意の webhook にポスト) などの通知のソースがサポートされています。
Ansible Tower 3.0 は Red Hat Satellite 6 および Red Hat CloudForms の動的インベントリーソースも追加しています。
柔軟なコマンドラインを Tower に取り入れることで、以下のいずれかについてのプロンプトを出すことができます。
インベントリー
認証情報
ジョブタグ
制限
Ansible Tower 3.1 は Red Hat Insights との統合をサポートしています。これにより、Insights Playbook を Tower プロジェクトとして使用できます。
Ansible Tower 3.3 では、ユーザーインターフェースのレイアウトが再構成され、ナビゲーション要素が改善されました。詳細にわたる情報がひと目で分かるように表示され、今まで以上に直感的に、必要な自動化を見つけ出し、使用できるようになります。
カスタムの Ansible 環境サポートでは、さまざまなチームやジョブに対して、各種 Ansible 環境を指定できるようになりました。
Ansible Tower 3.3 では、LDAP と SAML サポートが強化され、トークンベースの認証が導入されました。LDAP と SAML のサポートが強化されたことで、エンタープライズアカウントの情報をこれまで以上に柔軟に統合できるようになります。トークンベースの認証では、integrated OAuth 2トークンサポートを使用して、Tower でサードパーティーのツールやサービスを簡単に認証できるようになりました。
クラスターグループのランタイム管理では、簡単に設定可能なスケーリングができるようになりました。
Tower は、Red Hat OpenShift Container Platform のコンテナー化された Pod サービスとして使用できるようになり、必要に応じてスケールアップとスケールダウンが可能になりました。
複雑なプロビジョニング、デプロイメント、オーケストレーションのワークフローのモデル化を向上するため、Ansible Tower は複数の方法でワークフローの機能を拡張しました。
ワークフローのインベントリーの上書き: ワークフローの定義時間または起動時に、ワークフロー全体のインベントリーを上書きできるようになりました。アプリケーションデプロイメントを定義した後に、簡単に複数の環境で再利用できます。
ワークフローの収束モード: 複雑なプロセスをモデル化する時に、場合によっては、続行する前に複数のステップが完了するまで待つ必要があります。現在、Ansible Tower のワークフローでこれを簡単に複製できるようになり、前のワークフローの手順が複数完了するのを待ってから続行できるようになりました。
ワークフローのネスト化: 規模のより大きいワークフローのコンポーネントとして、個別のワークフローを再利用します。たとえば、プロビジョニングとアプリケーションデプロイメントワークフローを 1 つのマスターワークフローに統合する場合などです。
自動化が企業全体に広がると、自動化の規模を拡大する必要があります。Ansible Tower 3.4 では、何千台ものマシンからファクトを収集して設定ジョブを実行し、個別のジョブスライスに分割して、Ansible Tower クラスターに分散することで、信頼性の向上、ジョブの完了時間の短縮、クラスターの使用率の上昇などを図ることができます。大規模な環境において 15000 個のスイッチ全体でパラメーターを変更したり、何千ものノードがある RHEL のエステートで情報を収集する必要がある場合に、簡単に実現できるようになります。
FIPS など制限のあるモードで環境を実行する必要がある場合に向け、Ansible Tower ではこのような環境でデプロイと実行が可能になりました。