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 です。設定された 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 以降でシステム追跡 (履歴ファクト) 機能が非推奨となりました。ただし、ファクトキャッシュ機能を使用してファクトを収集できます。詳しい情報は、ファクトのキャッシング を参照してください。
Ansible Tower では自動化のステータスを簡単に追跡できるようになりました。ジョブテンプレートやプロジェクト、または組織全体のスタック可能な通知を設定し、ジョブの開始、ジョブの成功、ジョブの失敗、およびジョブの承認 (ワークフローノードの場合) についての各種の通知を設定できます。サポートされる通知ソースは以下のとおりです。
メール
Grafana
HipChat
IRC
Mattermost
PagerDuty
Rocket.Chat
Slack
Twilio
Webhook (他のツールと統合するには、任意の Webhook に POST 要求を送信)
さらに、上記の通知タイプごとに:ref:`customize notification messages <ug_custom_notifications>`を行うことができます。
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 のサポートが強化されたことで、エンタープライズアカウントの情報をこれまで以上に柔軟に統合できるようになります。トークンベースの認証では、統合された OAuth 2トークンサポートを使用して、Tower でサードパーティーのツールやサービスを簡単に認証できるようになりました。
クラスターグループのランタイム管理では、簡単に設定可能なスケーリングができるようになりました。
Tower は、Red Hat OpenShift Container Platform のコンテナー化された Pod サービスとして使用できるようになり、必要に応じてスケールアップとスケールダウンが可能になりました。
複雑なプロビジョニング、デプロイメント、オーケストレーションのワークフローのモデル化を向上するため、Ansible Tower は複数の方法でワークフローの機能を拡張しました。
ワークフローのインベントリーの上書き: ワークフローの定義時間または起動時に、ワークフロー全体のインベントリーを上書きできるようになりました。アプリケーションデプロイメントを定義した後に、簡単に複数の環境で再利用できます。
ワークフローの収束モード: 複雑なプロセスをモデル化する時に、場合によっては、続行する前に複数のステップが完了するまで待つ必要があります。現在、Ansible Tower のワークフローでこれを簡単に複製できるようになり、前のワークフローの手順が複数完了するのを待ってから続行できるようになりました。
ワークフローのネスト化: 規模のより大きいワークフローのコンポーネントとして、個別のワークフローを再利用します。たとえば、プロビジョニングとアプリケーションデプロイメントワークフローを 1 つのマスターワークフローに統合する場合などです。
Workflow Pause and Appproval: ユーザーの介入が必要な承認ノードを含むワークフローを構築できます。これにより、ユーザーが Playbook 間でワークフローを停止して、ワークフローの次のステップに進むための承認 (または拒否) ができるようにします。
自動化が企業全体に広がると、自動化の規模を拡大する必要があります。Ansible Tower 3.4 では、何千台ものマシンからファクトを収集して設定ジョブを実行し、個別のジョブスライスに分割して、Ansible Tower クラスターに分散することで、信頼性の向上、ジョブの完了時間の短縮、クラスターの使用率の上昇などを図ることができます。大規模な環境において 15000 個のスイッチ全体でパラメーターを変更したり、何千ものノードがある RHEL のエステートで情報を収集する必要がある場合に、簡単に実現できるようになります。
FIPS など制限のあるモードで環境を実行する必要がある場合に向け、Ansible Tower ではこのような環境でデプロイと実行が可能になりました。
大規模な組織の多くが、多数の組織間で Tower インスタンスを共有しています。1 つの組織 で全ライセンスホストが利用されてしまわないように、スーパーユーザーはこの機能を使用して、各組織に割り当て可能なライセンスホスト数の上限を指定できます。Tower のアルゴリズムは、組織内の制限や、全組織に存在する合計ホスト数に加えられた変更を組み込みます。インベントリーを同期することで組織がポリシーに準拠しなくなった場合には、インベントリー更新は失敗します。さらに、スーパーユーザーは、警告付きで、上限以上のライセンスを割り当てることができます。
さまざまなソース向けに、Ansible バージョン 2.8 以降で実行するインベントリーの更新でインベントリープラグインを使用する機能を追加しました。
シークレット管理システムでは、外部の認証情報が保存されて、Tower で使用できるようにし、Tower に直接指定する必要がありません。