Ansible Tower での Ansible Content Collections のインベントリープラグインの使用

IT環境はますます複雑になっています。 このような状況では、IT 自動化システムがネットワーク内に存在し、処理の対象となるノードに関する最新の情報を保持していることが重要です。 Red Hat Ansible Automation Platform では、この問題はいわゆるインベントリ (インベントリー) – 管理対象ノードのリスト。

最も単純な形式では、インベントリは静的ファイルです。 これは、Ansible の使用を開始する場合には理想的ですが、自動化が進むにつれて不十分になります。

そしてそれが理由です：

1. 状況が常に変化し、ワークロード、そしてその後ワークロードが実行されるノードが出入りする場合、監視対象ノードの完全なリストをどのように更新して維持すればよいでしょうか?
2. 特定の自動化を適用するノードを具体的に選択するために、IT インフラストラクチャのコンポーネントを分類するにはどうすればよいでしょうか?

動的インベントリは、これら両方の質問に対する答えを提供します (動的インベントリ) – 信頼できる情報源を参照して、自動化するノードを検索するスクリプトまたはプラグイン。 さらに、動的インベントリーはノードを自動的にグループに分類するため、特定の Ansible 自動化を実行するターゲット システムをより正確に選択できます。

インベントリプラグイン Ansible ユーザーは、外部プラットフォームにアクセスしてターゲット ノードを動的に検索し、インベントリの作成時にこれらのプラットフォームを信頼できる情報源として使用できるようになります。 Ansible のソースの標準リストには、クラウド プラットフォーム AWS EC2、Google GCP、Microsoft Azure が含まれており、Ansible 用のその他のインベントリ プラグインも多数あります。

Ansible Tower にはいくつかの機能が付属しています インベントリプラグインこれらは箱から出してすぐに動作し、上記のクラウド プラットフォームに加えて、VMware vCenter、Red Hat OpenStack Platform、および Red Hat Satellite との統合を提供します。 これらのプラグインの場合、ターゲット プラットフォームに接続するための認証情報を指定するだけで、Ansible Tower でインベントリ データのソースとして使用できるようになります。

Ansible Tower に含まれる標準プラグインに加えて、Ansible コミュニティでサポートされている他のインベントリ プラグインがあります。 への移行に伴い、 Red Hat Ansible コンテンツ コレクション これらのプラグインは、対応するコレクションに含まれ始めました。

この投稿では、顧客がすべてのデバイスに関する情報を CMDB に保存することが多い人気の IT サービス管理プラットフォームである ServiceNow のインベントリ プラグインを使用する例を取り上げます。 さらに、CMDB には、サーバー所有者、サービス レベル (運用/非運用)、インストールされている更新プログラム、メンテナンス時間帯に関する情報など、自動化に役立つコンテキストを含めることができます。 Ansible インベントリ プラグインは ServiceNow CMDB と連携でき、コレクションの一部です。 サービスナウ ポータルで galaxy.ansible.com.

Gitリポジトリ

Ansible Tower のコレクションからインベントリ プラグインを使用するには、それをプロジェクト ソースとして設定する必要があります。 Ansible Tower では、プロジェクトは git リポジトリなど、ある種のバージョン管理システムとの統合であり、自動化プレイブックだけでなく変数やインベントリ リストの同期にも使用できます。

私たちのリポジトリは実際には非常にシンプルです。

├── collections
│   └── requirements.yml
└── servicenow.yml

servicenow.yml ファイルには、プラグイン インベントリの詳細が含まれています。 この例では、使用する ServiceNow CMDB 内のテーブルを指定するだけです。 また、ノード変数として追加されるフィールドと、作成するグループに関する特定の情報も設定します。

$ cat servicenow.yml
plugin: servicenow.servicenow.now
table: cmdb_ci_linux_server
fields: [ip_address,fqdn,host_name,sys_class_name,name,os]
keyed_groups:
  - key: sn_sys_class_name | lower
	prefix: ''
	separator: ''
  - key: sn_os | lower
	prefix: ''
	separator: ''

これは、接続先の ServiceNow インスタンスを指定するものではなく、接続のための資格情報も指定するものではないことに注意してください。 これらすべてを後で Ansible Tower で設定します。

ファイル collections/requirements.yml Ansible Tower が必要なコレクションをダウンロードして、必要なインベントリ プラグインを取得できるようにするために必要です。 それ以外の場合は、このコレクションをすべての Ansible Tower ノードに手動でインストールして維持する必要があります。

$ cat collections/requirements.yml
---
collections:

- name: servicenow.servicenow

この設定をバージョン管理にプッシュしたら、対応するリポジトリを参照するプロジェクトを Ansible Tower に作成できます。 以下の例では、Ansible Tower を github リポジトリにリンクしています。 SCM URL に注意してください。これにより、プライベート リポジトリに接続するためのアカウントを登録したり、チェックアウトする特定のブランチ、タグ、またはコミットを指定したりできます。

ServiceNow の認証情報の作成

前述したように、リポジトリの構成には ServiceNow に接続するための資格情報が含まれておらず、通信する ServiceNow インスタンスも指定されていません。 したがって、このデータを設定するには、Ansible Tower で認証情報を作成します。 によると ServiceNow インベントリ プラグインのドキュメント、たとえば次のように、接続パラメータを設定するための環境変数が多数あります。

= username
    	The ServiceNow user account, it should have rights to read cmdb_ci_server (default), or table specified by SN_TABLE

    	set_via:
      	env:
      	- name: SN_USERNAME

この場合、SN_USERNAME 環境変数が設定されている場合、インベントリ プラグインはそれを ServiceNow に接続するためのアカウントとして使用します。

SN_INSTANCE 変数と SN_PASSWORD 変数も設定する必要があります。

ただし、Ansible Tower には、ServiceNow にこのデータを指定できるこのタイプの認証情報はありません。 しかし、Ansible Tower を使用すると、 カスタム認証情報の種類、これについては記事で詳しく読むことができます 「Ansible Tower 機能のスポットライト: カスタム認証情報」.

この場合、ServiceNow のカスタム資格情報の入力構成は次のようになります。

fields:
  - id: SN_USERNAME
	type: string
	label: Username
  - id: SN_PASSWORD
	type: string
	label: Password
	secret: true
  - id: SN_INSTANCE
	type: string
	label: Snow Instance
required:
  - SN_USERNAME
  - SN_PASSWORD
  - SN_INSTANCE

これらの資格情報は、同じ名前の環境変数として公開されます。 これについては、インジェクター構成で説明します。

env:
  SN_INSTANCE: '{{ SN_INSTANCE }}'
  SN_PASSWORD: '{{ SN_PASSWORD }}'
  SN_USERNAME: '{{ SN_USERNAME }}'

必要な認証情報の種類を定義したので、次のように ServiceNow アカウントを追加し、インスタンス、ユーザー名、パスワードを設定できます。

在庫を作成します

これで、Ansible Tower でインベントリを作成する準備が整いました。 これを ServiceNow と呼びましょう。

インベントリを作成したら、データ ソースをインベントリにアタッチできます。 ここでは、前に作成したプロジェクトを指定し、ソース管理リポジトリ内の YAML インベントリ ファイルへのパスを入力します。この例では、プロジェクト ルートにある servicenow.yml です。 さらに、ServiceNow アカウントをリンクする必要があります。

すべてがどのように機能するかを確認するために、[すべて同期] ボタンをクリックしてデータ ソースとの同期を試してみましょう。 すべてが正しく構成されている場合は、ノードがインベントリにインポートされるはずです。

必要なグループも作成されていることに注意してください。

まとめ

この投稿では、ServiceNow プラグインを例として、Ansible Tower のコレクションからインベントリ プラグインを使用する方法を説明しました。 また、ServiceNow インスタンスに接続するための認証情報も安全に登録しました。 プロジェクトからインベントリ プラグインをリンクすると、サードパーティ プラグインやカスタム プラグインだけでなく、一部の標準インベントリの操作を変更するためにも使用できます。 これにより、ますます複雑化する IT 環境を自動化する際に、Ansible Automation Platform を既存のツールと簡単かつシームレスに統合できるようになります。

この投稿で説明したトピックや、Ansible の使用に関するその他の側面の詳細については、以下を参照してください。

• によるブログ Ansible を使用した ServiceNow の自動化.
• 独自のコレクションを作成する方法.
• Automation Hub Web サイトで Red Hat がサポートするコレクションのリスト (クラウド.redhat.com).
• Ansible 自動化プラットフォームの電子書籍.

*Red Hat は、ここに含まれるコードが正しいことを保証しません。 すべての資料は、特に明記されていない限り、非推奨に基づいて提供されます。

出所： habr.com