Ansible Towerのクラウド連携機能による効率化を目指す
Ansible Towerのクラウド連携機能を試す
前回の記事では、Ansible Tower上でのPlaybookの実行方法を説明するとともに、想定される環境の例を交えてAnsible Towerのユーザー管理機能をご紹介しました。今回は、Ansible Towerに用意されているクラウド連携機能についてご紹介します。
Ansible Towerはクラウド連携を謳っており、AWS、VMware vCenterなどさまざまなクラウドサービスとの連携が可能であり、そのための機能をいくつか備えています。今回は、Cloud Credential機能を用いてOpenStackを操作する例を示すことで、Ansible Towerがどのようにクラウドと連携しようとしているかの一例を紹介します。
Cloud Credential
前回の記事で述べましたように、Ansible TowerにはCredentialという概念が存在します。Credentialは、Ansible Towerの操作対象となるサーバーの認証情報などを保持する仕組みです。前回では操作対象をサーバーとしましたが、これをさまざまなクラウドに適用することも可能です。Ansible Towerでは、この機能を「Cloud Credential」と呼んでおり、Job Templateを作成する際にCredentialとは異なる項目として設定します。下記は、実際のJob Templateの作成画面です。Machine CredentialとCloud Credentialを明確に区別していることが分かります。
Job Templateの作成画面
Machine Credentialは物理サーバーにアクセスした際の認証情報を所有しており、Playbookを実行する対象へのログインの際に使用します。Cloud Credentialも同様に、クラウドにアクセスした際の認証情報を所有しています。それでは、Cloud Credentialもクラウドへのログインのためだけの機能なのでしょうか？ 今回の検証の結果、Cloud CredentialはOpenStackの操作に用いることで、Playbookの数を減らし、PlaybookやProjectの管理を容易にする機能も備えているように思われます。以下では、このメリットを含めて詳しく説明します。
それではCloud Credentialの中身を具体的に確認してみましょう。下記はCredentialの編集画面です。Cloud Credentialを作成するには、Credentialの作成時にTypeの項目としてクラウドソフトウェアを選択する必要があります。今回の例では、OpenStackを選択しています。またType Detailの項目として、OpenStackの操作に必要な各種パラメータを入力します。これらの値については、OpenStackを利用したことがある方なら見覚えがあるかもしれませんね。
Credentialの編集画面
OpenStackをCUIで操作する場合は、一般的に下記のような認証情報とともにコマンドを発行します（認証情報は環境変数として扱うのが一般的です）。
OpenStackをCUIで操作する場合の認証情報の渡し方
これにより、OpenStackのクライアントからOpenStackの認証機構（Keystone）で認証が行われ、問題がなければ認証情報に応じてコマンドが実行されます（OpenStackの構築環境によって異なりますが、説明のため単純化しています）。Cloud Credentialには、このOpenStackの認証情報が入っていることになります。
Cloud CredentialはOpenStackの認証情報を含んでいる
認証情報にはテナントを含むことができ、この部分を変更することで操作対象のテナントを選択することができます。
Cloud Credentialを用いたPlaybookの作り方
それでは、Cloud Credentialを利用したOpenStackの操作について、実際のPlaybookを交えて説明します。今回の操作に使用した環境は下記のとおりです（OpenStackのディストリビューションにはRDOを用い、packstack --allinoneで構築しています）。
説明用の環境
Ansible Towerの機能を用いることでクラウド連携が可能になると述べましたが、実のところCloud Credentialを利用しなくても、Ansible自体がOpenStackに対応しており、Playbook内にパラメータを記述しておけばOpenStackの操作自体は可能です。
それでは、Ansible Towerを使うと何が便利なのでしょうか。その点を明らかにするために、今回はCloud Credentialを利用しない場合とした場合では何が違うのかという点に注目して、比較しながら説明していきたいと思います。
はじめにOpenStackを操作する2つのPlaybookについて説明します。どちらもOpenStack上にVolumeを作成するだけの簡単なPlaybookです。まず、下記はCloud Credentialを利用しないPlaybookです。
リスト1：Cloud Credentialを用いないPlaybookの例
- name: create a volume
hosts: all
gather_facts: False
tasks:
- name: create a volume
os_volume:
state: present
size: 2
display_name: volume2G
auth:
auth_url: http:// 192.168.1.1:5000/v2.0
username: admin
password: 8af7ac1793c84149
project_name: admin
次に、Cloud Credentialを利用するPlaybookです。
リスト2：Cloud Credentialを用いたPlaybookの例
- name: create a volume
hosts: all
gather_facts: false
vars:
config_file: "{{ lookup('env', 'OS_CLIENT_CONFIG_FILE') }}"
tasks:
- include_vars: "{{ config_file }}"
- name: create a volume
os_volume:
state: present
size: 2
display_name: volume2G
auth:
auth_url: "{{ clouds.devstack.auth.auth_url }}"
username: "{{ clouds.devstack.auth.username }}"
password: "{{ clouds.devstack.auth.password }}"
project_name: "{{ clouds.devstack.auth.project_name }}"
~
比較しやすいように並べてみましょう。差異は下図の赤枠の部分になります。
Cloud Credentialの有無によるPlaybookの差を比較
左側ではPlaybookに直接書かれている認証情報が、Cloud Credentialを用いるPlaybookではすべて変数に変わっています。このとき、具体的にはOS_CLIENT_CONFIG_FILEという名前の環境変数を読み込んでいます。本来であれば、Playbookが実行される環境でこの環境変数を与える必要がありますが、Ansible TowerではCloud Credentialに入力した値をこのOS_CLIENT_CONFIG_FILEという環境変数として割り当てることが可能です。これにより、同じPlaybookを用いていても、利用するユーザーやCloud Credentialが異なれば、異なる認証情報でOpenStackを操作することが可能になります。
このCloud Credentialを用いると、どういった点で便利なのでしょうか。具体的な例として、同じOpenStack環境を東京、大阪、名古屋でテナントを分けて利用している場合を考えてみましょう。Ansible TowerのOrganizationにそれぞれ所属しているユーザーは、OpenStackでも同じテナントに属しているとします。それぞれ地域のユーザーは、それぞれのテナントのVolumeを作成・利用しています。
OpenStackの利用状況の例
Cloud Credentialを利用しないPlaybookを用いる場合、各ユーザーが自分のユーザー名や所属するテナントにVolumeを作成しようとすると、その数だけ異なる認証情報を記載したPlaybookが必要となります。
Cloud Credentialを用いないPlaybookの適用
ユーザーごとにPlaybookが必要だと、Playbookの管理は非常に煩雑になると予想されます。
Cloud Credentialを用いたPlaybook
一方Cloud Credentialを用いれば、異なるユーザーが同じ操作を実施する際にも、1つのPlaybookがあれば、別のテナントにVolumeを作成することが可能になります。
単にPlaybookがCloud Credentialに置き換わったようにも見えますが、OpenStackのようにさまざまな操作が実行できる環境では、Playbookの数も膨大になりがちです。たとえば5つのPlaybookと5人のユーザーがいる環境で、Cloud Credentialを用いる場合のPlaybookとCredentialの数について考えてみます。PlaybookとUserを組み合わせたときに、Playbookが必要な場合に○をつけています。
Cloud Credentialを用いない場合の必要となるPlaybookの数
| Playbook＼User | User1 | User2 | User3 | User4 | User5 |
|---|---|---|---|---|---|
| Volume作成 | ○ | ○ | ○ | ○ | ○ |
| Instance作成 | ○ | ○ | ○ | ○ | ○ |
| Network作成 | ○ | ○ | ○ | ○ | ○ |
| Router作成 | ○ | ○ | ○ | ○ | ○ |
| User作成 | ○ | ○ | ○ | ○ | ○ |
Cloud Credentialを用いない場合、各ユーザーの認証情報が入ったPlaybookがそれぞれ必要となるため、全部で25種類のPlaybookが必要となります。
一方Cloud Credentialを用いる場合は、各Playbookを1つずつとCloud Credentialが1つずつで、合計10種類のPlaybookとCloud Credentialを作成すれば、これらを組み合わせることでCloud Credentialを用いない場合と同じ操作が可能です。ユーザー数とPlaybookの数がもっと増えれば、この差はさらに広がります。
Cloud Credentialを用いた場合
| Playbookの種類 | Cloud Credentialの種類 | ||
|---|---|---|---|
| Volume作成 | ○ | User1 | ○ |
| Instance作成 | ○ | User2 | ○ |
| Network作成 | ○ | User3 | ○ |
| Router作成 | ○ | User4 | ○ |
| User作成 | ○ | User5 | ○ |
さらに、Cloud Credentialの作成とJob Templateの作成は、一般ユーザーの権限でも実行可能です。一方でPlaybookを管理者が作成する場合、管理者が25点のPlaybookすべてを管理する必要があるため、各ユーザーが各自で必要とするCloud Credentialを用意したほうが管理の手間が軽減されます。新規ユーザーが追加された場合や、Playbookの一部を改修する場合を考えても、Cloud Credentialによる管理が有効となります。
Cloud Credentialを用いると管理者の手間は軽減できる
Cloud Credentialを用いたPlaybook実行までの手順
それでは実際に、既存のPlaybookに対して一般ユーザーがCloud Credentialを用いる手順について説明します。今回の環境では、管理者であるadminと、一般ユーザーであるuser1が存在しています。
一般ユーザーがJob Templateを作成するためには、ProjectとInventoryを選択する必要があります。まずはadminでログインし、user1にProjectとInventoryを利用する権限を付与します。
一般ユーザー（user1）にProject利用の権限を付与
一般ユーザー（user1）にInventory利用の権限を付与
続いてuser1でログインし、OpenStackの認証情報を用いて、user1のCloud Credentialを作成します。
Cloud Credentialの作成
最後にuser1でJob Templateを作成します。InventoryとProjectを選択し、OpenStackを操作するPlaybookを選択します。Machine CredentialとCloud Credentialを選択し、Job Templateを作成します。
Job Templateの作成
ProjectとInventoryが定まっていれば、一般ユーザー自身でCloud Credentialの作成が可能なことが分かるかと思います。
Cloud Credentialを用いたPlaybookの実行
実際にJob Templateを実行してみます。OpenStackのVolumeが空の状態で、Job Templateを実行します。OpenStackにログインし、Volumeが存在していないことを確認します。
まだVolumeがないことを確認
Ansible Towerから作成したJob Templateを実行します。
Job Templateを実行
Taskが成功したら、OpenStack側からVolumeを確認します。
Volume（volume2G）が作成されている
想定通り、Volumeが作成されていることが確認できます。
まとめ
以上、Ansible Towerによるクラウド連携機能の一例を紹介しました。Ansible Towerには他にもさまざまなクラウド連携機能があるためすべてを紹介することはできませんが、Ansible TowerがOpenStackのようなクラウドへどのようにアプローチしているかを示せたかと思います。
3回に渡り、Ansible Towerの概要とユーザー管理機能、クラウド連携機能についてご紹介しました。Ansible Towerを導入することで、運用管理ツールとして注目されているAnsibleを、より使いやすく、より組織的に利用することができるようになります。本連載がAnsible Towerご理解の一助となれば幸いです。
- Ansibleは、Red Hat, Inc.の米国およびその他の国における商標または登録商標です。
- OpenStack®の文字表記とOpenStackのロゴは、米国とその他の国におけるOpenStack Foundationの登録商標/サービスマークまたは商標/サービスマークのいずれかであり、OpenStack Foundationの許諾を得て使用しています。日立製作所は、OpenStack FoundationやOpenStackコミュニティの関連企業ではなく、また支援や出資を受けていません。
