AWXのインストールから最初のプレイブックの立ち上げまで-Ansible集中管理のセットアップ

インフラストラクチャ内のサーバーの数はすでに800を超えていますが、1年前には約500でした 。 これに取り組むために、誰もがRed Hatのソリューションを積極的に使用しています。 FreeIPAについて-Linuxサーバーのアクセスを整理および管理するために-すでに書いたので、構成管理のトピックに触れたいと思います。 これらの目的のために、Ansibleを使用し、最近ではAWXが追加されました-プレイブック、ローンチスケジュール、在庫管理、サーバーにアクセスするための資格情報、およびサーバー側。

多くのことが原因で、すぐに統合してメインのWar Robotsプロジェクトと連携させることはできませんでしたが、AWXをチェックするためのフィールドはたくさんありました。 まず、同社は開発/ステージ環境、そしてもちろん本番環境を将来必要とする新しいプロジェクトを開発しています。 そして最近、内部分析のためのプロジェクトがこれに追加され、完全に新しいクラスターが必要になりました。

それでは始めましょう！

AWXは2017年9月に導入されました-これはApache-2.0ライセンスの下で配布される無料のオープンソースプロジェクトであり、商用プロジェクトAnsible Towerのアップストリームです。 一般に、これは他のRed Hatプロジェクトと同じ原則です。RedHat Cloud Forms-ManageIQ。 RHEV-Ovirt; Red Hat識別管理-FreeIPAなど。

この記事は、AWXのインストールから最初のプレイブックの立ち上げまでのガイドです。 しかし、最初に、AWXの主な機能をリストしましょう。

• バージョン管理システムとの統合（git / mercurial / subversion）。
• プレイブックのステータスをリアルタイムで追跡します。
• プレイブックの自動起動のスケジュール設定。
• 単一のワークフローで複数のプレイブックを実行します。
• プレイブックなしのコマンドのリモート実行（Ansible ad hoc）。
• コールバックメカニズムのサポート。これにより、新しいサーバーがそれぞれの部分の構成を要求できます。
• アンサンブルのインベントリ管理。AWS/ Azure / OpenStackプラットフォームなどと統合する機能、ダイナミックインベントリを生成するためのネイティブスクリプトのサポートなど。
• アクセス権の差別化の柔軟なシステム。 LDAP / SAML / Active Directoryなどとの統合
• 電子メール/ Slack / PagerDuty / HipChat / MatterMost / IRCの組み込み通知サポート。
• 外部ログ集約システムとの統合：Logstash / Splunk / Loggly / Sumologic。

設置

現在、いくつかのインストールオプションがサポートされています。

1. Kubernetes。
2. オープンシフト。
3. Docker / Docker Compose。

それらはすべてGitHubのドキュメントで説明されています。たとえば、純粋なDockerのオプションを検討してください。これは、OpenShift / Kubernetesの追加構成を必要としない最速のオプションです。

Centos 7にすべてをインストールします。Dockerのインストールについては公式ドキュメントにも記載されているため、この記事では触れません。

次に、ansibleとdocker-pyモジュールをインストールする必要があります。 これは、pipから実行できます。

pip install ansible pip install docker-py 

AWXリポジトリのクローンを作成します。

 git clone https://github.com/ansible/awx.git cd awx/installer 

インベントリファイルを編集します。 まず、変数postgres_data_dirを修正することをお勧めします。 デフォルトでは、/ tmp / pgdockerと同じですが、このままにしておくと、しばらくするとAWXが使用するpostgresqlデータベースが失われる可能性があります。

外部データベースを使用する場合は、変数を指定します。

 pg_hostname pg_username pg_password pg_database pg_port 

その後、実行します：

 ansible-playbook -i inventory install.yml 

このコマンドは、プレイブックを開始し、目的のdocker-imagesをロードし、AWXと追加コンポーネント（Postgres、MemCached、RabbitMQ）でコンテナを直接起動します。

プレイブックを完了すると、次のコンテナが表示されます。

 docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES b1bd94f83420 ansible/awx_task:latest "/tini -- /bin/sh ..." 6 days ago Up 6 days 8052/tcp awx_task abf30fd81335 ansible/awx_web:latest "/tini -- /bin/sh ..." 6 days ago Up 6 days 0.0.0.0:80->8052/tcp awx_web b13ee3c7cbb7 memcached:alpine "docker-entrypoint..." 2 months ago Up 6 days 11211/tcp memcached 3c4cac5a4ce5 rabbitmq:3 "docker-entrypoint..." 2 months ago Up 6 days 4369/tcp, 5671-5672/tcp, 25672/tcp rabbitmq b717c6019e02 postgres:9.6 "docker-entrypoint..." 2 months ago Up 6 days 5432/tcp postgres 

次のようにAWXインストールプロセスに従います。

 docker logs -f awx_task 

AWXは、ポート80のサーバーアドレスで利用できます（インベントリファイルでポートを変更していない場合）。

デフォルトのユーザー名とパスワード：

 Admin:password 

使用法と例

次に、AWXに直接アクセスしますが、最初にすべてがどのように構成されているかを見ていきます。

まず、プロジェクトのセクションに興味があります。 AWX用語のプロジェクトとは、AWXサーバーまたはリポジトリにローカルに配置された一連のプレイブックを意味します。

最初のプロジェクトを作成します。



-名前：プロジェクトの名前。firstprojectにします。
-組織：AWXでは、これはアクセスの制御に使用されるエンティティです。 組織には、インベントリ、ユーザー、ユーザーグループ、プレイブックが含まれる場合があります。 デフォルトを選択します。
-SCM TYPE：リポジトリタイプ。ローカルディレクトリまたはバージョン管理システムのいずれかを選択できます：git、mercurial、subversion。
-SCM Url：リポジトリのURL。
-SCMブランチ/タグ/コミット：オプションで、必要なブランチ/タグ/コミットを指定できます。
-[SCM資格情報]フィールドで、リポジトリへのアクセスに使用される詳細を選択できます。

チェックボックスをオフにすることもできます：

-クリーン：更新する前にすべてのローカル変更を削除します。
-更新時に削除：プロジェクトを更新するときに、ローカルコピーを削除し、リポジトリの新しいコピーを再読み込みします。
-起動時に更新：このプロジェクトからプレイブックを開始するたびに、リポジトリのローカルコピーを現在のバージョンに更新します。 更新時に削除と組み合わせて使用​​できますが、リポジトリとの同期の終了を待つ必要があるため、プレイブックの実行時間が長くなる可能性があります。

起動時にクリーンアップと更新を選択します。 [保存]をクリックし、その後、最初のプロジェクトの作成が完了します。

[プロジェクト]セクションに移動して、プロジェクトの[scm更新の開始]ボタンをクリックします。 リポジトリの最初のダウンロードが完了するまで待機します（更新のステータスは[ジョブ]セクションで監視できます）。

リポジトリにあるプレイブックを見てみましょう。 HabréにはAnsibleとそのプレイブック/ロールの構造について説明する記事がたくさんありますので、この点については詳しく説明しません（たとえば、 1、2、3の記事があります）。

 firstproject/ ├── ansible.cfg ├── group_vars/ ├── host_vars/ ├── roles/ │ └── requirements.yml └── run.yml 

AWXは、firstprojectディレクトリのルートにある.ymlファイルをプレイブックとして扱います。

run.ymlファイルの内容：

 --- - name: Test Role hosts: - all gather_facts: true roles: - roleawx 

つまり、事実を収集した後、単にroleawxを実行します。 AWX自体でホストとグループホストを指定できるため、すべてを指定するホスト。

興味深い点は、roles / requirements.ymlファイルの内容です：

 - src: git@gitlab.example.com:ansible-roles/roleawx.git scm: git 

Projectを同期するとき、AWXは、requirements.ymlファイルに従ってすべてのロールをロールディレクトリにインストールします。 この場合、gitリポジトリからroleawxロールをインストールします。

次のコマンドを使用してロールを作成します。

 ansible-galaxy init roleawx 

ロールの構造は次のとおりです。

 roleawx/ ├── README.md ├── defaults │ └── main.yml ├── files ├── handlers │ └── main.yml ├── meta │ └── main.yml ├── tasks │ └── main.yml ├── templates ├── tests │ ├── inventory │ └── test.yml └── vars └── main.yml 

tasks / main.ymlファイルの内容：

 --- # tasks file for roleawx - name: Test Message debug: msg: "AWX and Ansible" 

開始するには、「AWX and Ansible」というメッセージを表示するだけです。

requirements.ymlファイルで指定されたロールをAWXが自動的にインストールするためには、ロール自体でmeta / main.ymlファイルが正しく生成される必要があることに注意してください（ansible-galaxy initを使用してロールのテンプレートを作成し、次にmeta / main .ymlは問題なく、AWXはこのロールをロードできます）。

したがって、プレイブックのあるリポジトリと、ロールのあるリポジトリがあります。 また、192.168.10.233、192.168.10.234、および192.168.10.239のアドレスを持つ複数の仮想マシンがあります。

プレイブックを開始する前に、AnsibleがAWXサーバーからホストに到達できることを確認する必要があります（この場合、SSH経由）。 プレイブック内の変数で直接パスワードを指定できますが、これは面白くありません。 AWXはサーバーにアクセスするための詳細を管理できます。これを使用します。

[資格情報]タブに移動し、[追加]ボタンをクリックします。



-名前：詳細に名前を付けます。
-資格情報タイプ：ここで、詳細のタイプを選択できます。 マシンを使用してサーバーにアクセスすることに興味があります。 さらに、AWXは、scm（git、svn、mercurial）、Red Hat Insight、AWS、Azure、Red Hat Satellite、RHEV、Vmware、OpenStackなどのさまざまなサービスと統合するために使用できるさまざまな種類のアクセス詳細を提供します。 独自の種類の資格情報を作成することもできます。
-ユーザー名：ルートを選択します。
-パスワード：キーアクセスを使用するため、空白のままにします。
-プライベートキーパスフレーズ：キーがパスワードで作成されている場合、キーのパスワード。 この場合、キーにはパスワードが含まれていないため、フィールドは空白のままにします。
-特権エスカレーション方法：特権エスカレーション方法。 例：sudo、su、pfexecなど。
-PRIVILEGE ESCALATION USERNAME：Ansibleが特権を受け取るユーザー。
-特権エスカレーションパスワード：特権エスカレーション用のパスワード。

ルートとしてログインするため、権限昇格に関連するフィールドは空のままにします。

注：いくつかのフィールドには[起動時にプロンプ​​トを表示する]チェックボックスがあります。 このチェックボックスを有効にすると、対応するフィールドが提供され、プレイブックが開始されるたびに手動で入力され、これらの詳細が関連付けられます。 したがって、AWX内にパスワードを保存することはできませんが、プレイブックを開始するたびにパスワードを要求できます。

そのため、サーバーにアクセスするためのプロジェクトと詳細を作成しました。 次に、インベントリが必要です。

[インベントリ]セクションに移動し、[追加]ボタンをクリックします。 以下を作成するための選択肢が提供されます。

-インベントリ：通常のインベントリ。
-スマートインベントリ：既存のホストに基づいて、たとえばオペレーティングシステムのタイプなどのパラメータに基づいて、インベントリを生成できます。

通常のインベントリを作成します。



-[名前]フィールドで、名前を指定します。
-デフォルトの組織を選択します。
-[変数]フィールドで、後でプレイブックから使用できる変数を指定できます。

次のことを示しています：

 --- awxinvvar: "Test" 

インベントリを保存するまで、残りのタブは非アクティブです。

保存して、インベントリセクションに戻ります。 インベントリがリストに表示されました。 それに行きましょう：上部タブを作成した後、アクティブになりました。

-権限：これは、どのユーザーまたはユーザーグループがインベントリにアクセスできるかを制御します。
-グループ：ホストグループのリスト。
-ホスト：ホストのリスト。
-ソース：インベントリのソースのリスト。 AWS / Azure / OpenStack / RHEVおよび多数のサービスからインベントリをアンロードできます。プロジェクト内にあるインベントリファイルを指定することも、Dynamic Inventoryがソースとして生成する独自のスクリプトを指定することもできます。
-完了したジョブ：現在のインベントリのホストに関連付けられた実行中のプレイブックのリスト。

ホストがほとんどいないため、インベントリを手で埋めます。 [ホスト]タブに移動して、いくつかのホストを作成します。



-[ホスト名]フィールドで、サーバーのIPアドレスまたはそのDNS名を指定できます。
-[変数]フィールドで、ホストの1つに対してawxinvvar変数をオーバーライドしてみます。

 --- awxinvvar: "Host1" 

ホストを作成したら、[グループ]タブに移動して、ホストのグループを作成します。



同様に、グループ名を指定し、いずれかのグループのawxinvvar変数を再定義します。

[ホスト]タブに戻り、リストからホストの1つを選択し、このホストの[グループ]タブに移動して、[グループの関連付け]をクリックします。



ホストの組積造では、各ホストがどのグループで構成されているかを確認できます。



ところで、[実行]コマンドボタンは、[ホスト]タブと[グループ]タブでも使用できます。 これは、プレイブックなしでリモートホストでアクションを実行できるAnsibleのアドホックコマンドに類似しています 。

やってみましょう。 リストからホストを選択し、前に作成したSSHアクセスのキーを選択し、シェルモジュールを使用してdateコマンドを実行します。



起動をクリックします。 進行状況をリアルタイムで監視できるページに移動する必要があります。 また、プレイブック/アドホックコマンドのすべての起動は、ジョブセクションに表示されます。



アドホックチームは正常に完了しました。

それでは、プレイブックを起動してみましょう。 [テンプレート]セクションに移動し、[追加]ボタンをクリックして、[ジョブテンプレート]を選択します。

用語では、AWXテンプレートは、プレイブックを起動するために使用されるパラメーターのセットです。 最小限のフォームでは、テンプレートの名前を指定し、プロジェクトを選択し、プレイブックを選択し、インベントリを選択する必要があります。

テンプレートの作成は次のようになります。



-名前と説明：テンプレートの名前と説明。
-ジョブの種類：実行または確認。 つまり、プレイブックを開始するか、変更を加えずにプレイブックをチェックする（ドライラン）だけです。
-インベントリ：プレイブックが起動されるインベントリ。
-プロジェクトとプレイブック：プレイブックとプロジェクトから特定のプレイブックを含むプロジェクトを選択するように設計されています。
-制限：プレイブックが起動されるホストとグループのリスト。
-冗長性：Ansibleが実行結果をどの程度詳細に出力するか（-v -vv -vvvスイッチのアナログ）。
-ジョブタグ：タグのリスト-開始する必要のあるタスク。 指定しない場合、ロールに記述されているすべてのタスクが実行されます。
-タグをスキップ：タグのリスト-実行されないタスク。
-ラベル：このテンプレートに関連付けられるラベル。 AWX自体のフィルタリングに使用できます。
-差分の表示：Ansibleによる変更を表示します（--diffキーのアナログ）。

プロジェクトを保存し、テンプレートセクションに戻って、プレイブック（ロケットの形のボタン）を起動します。



万歳、私たちのプレイブックが開始され、必要な役割をダウンロードして正常に完了しました。 ちなみに、同じページで、プレイブックの結果をダウンロードできます。 プレイブックの出力を検索することもできます。

いくつかの場所にawxinvvar変数を追加したことを覚えていますか？ 彼女を連れてきて、何が起こるか見てみましょう。

tasks / main.ymlファイルのロールに次を追加します。

  - name: Print var debug: msg: "{{ awxinvvar }}" 

そして、テンプレートを再度実行します。



プレイブックは、Inventoryで定義した変数を参照し、変数の使用の優先順位に従って正しく再定義します 。

ところで、変数は、必要に応じてhost_vars group_varsディレクトリのリポジトリに保存することもできます。 ただし、この場合、AWX自体のインベントリには表示されません。

結論の代わりに

現在、AWXを数か月使用しており、これまでのところすべてに満足しています。 もちろん、これは新しいプロジェクトであるため、さまざまな種類の問題（主にインターフェイスの小さなバグ）に定期的に遭遇しますが、それらは重大ではなく、作業に干渉しません。

注：新しいリリースは現在頻繁にリリースされており、更新に問題がある可能性があります。 バックアップを作成してください！

このマニュアルは、AWXの基本機能を理解するために書かれたものであり、興味深い場合は、動的インベントリ、コールバックなどのソースとの統合など、追加の有用な機能について記述します。

PSところで、ここでは、インフラストラクチャの一部に使用するAWXダッシュボードのように見えます。