【連載】次世代ハイパーコンバージド「HPE SimpliVity」を取り巻くエコシステム ー 第８回 SimpliVityを自動化ツールで触ってみよう！その２

[yoshihiko1989]

前回は構成管理ツールのデファクトスタンダード「Ansible」の概要について紹介させていただきました。

今回はAnsibleを使ったSimpliVityの制御を、Playbookの書き方のポイントとともに解説します。

Ansibleの登場人物

最初に、Ansibleのコンポーネントをご紹介します。

「よくある作業」を部品化したライブラリである「モジュール」、モジュールを組み合わせたり、自分で作成可能なコード化された手順書である「Playbook」。実行対象へログインする認証情報である「クレデンシャル」、その他プログラミングと同様に環境依存を排除して応用できるようにするための「変数」、IPアドレスで管理される実行対象の情報をまとめた「インベントリ」等が主な登場人物です。

SimpliVityでは現在Ansible専用モジュールの提供はしておりませんが(2019年6月時点)、本投稿で紹介するように簡単なエラーハンドリングを追記することで設計すれば問題なく汎用的なPlaybookは作成可能です。

コーディングルールの決定

プログラミング開発に携わる方なら当たり前かもしれませんが、Ansibleもコードを書きますので、

作る前にコーディングルール（そのようにPlaybookを設計していくか）を決めておくと良いでしょう。

Anisbleではディレクトリ構造にベストプラクティスがあります。

1つのPlaybook内にすべての処理をまとめることもできるのですが、他のPlaybookでも同一タスクを使うことを考えて、変数ファイルを作るなど効率的な運用をすることが望まれます。

下記はあくまで一例としてご参照いただければと思いますが、少しご紹介すると

varsファイル

グローバル変数をまとめたファイルです。

（ここでは全体で網羅的に使用する変数をsvt_config.ymlとし、細かいPlaybookでしか使用しない変数ファイルと分けるように設計しています）

roles

Playbookを個々の処理（ロール）毎に分けて配置するディレクトリです。

site.yml

多くの言語でいうメインルーチン「main()」であり、大元のタスクを実行するPlaybookです。※任意に変更可能

 図１：Ansibleのディレクトリ設計例

では、大元のPlaybookから順を追ってみていきたいと思います。図2を見てください。

大元のタスクを記載しているのがのvm_backup.ymlです。これが一般的なSite.ymlのPlaybookに該当します。

このPlaybookの中に、それぞれ役割毎に分割したPlaybookを配置します。

vm_backup.ymlの中には、例②のbackup_selected_vms.ymlを呼び出すように記述されており、さらにこのbackup_selected_vms.yml名義のPlaybookの中に具体的なタスクをパーツ毎に分割した細かなPlaybookを呼び出すように設計されています。

この中に含まれるのが、REST APIの講座でもおなじみに、トークン発行のPlaybookだったり、例③Create_vm_backup.ymlに上げられるような実際のバックアップタスクを実行するPlaybookが含まれているわけです。

図２：実際のPlaybookに沿ったディレクトリ構造

Playbookの記載例①（vm_backup.yml）

図2を一つずつ見ていくと、例えばバックアップのタスクを実行する「vm_backup.yml」と命名したsite.ymlがあります。このPlaybookを開いてみると（図3）、様々なファイルがロードされていることが分かります。つまり、これはメインルーチンであることを意図しています。

 図3：vm_backup.ymlの中身(バックアップジョブのメインルーチン)

「変数をどこのファイルから読み込む」とか「次のタスクはどのように実行するか」などについては、メインルーチンであるsite.ymlに記述することが好ましいです。

図3のinclude_roleでは、分割した各タスクのPlaybook（ロール）を読み込む動作を行い、最初にロードするタスクが「svt/backup_selected_vms」であることを意図しています。

Playbookの記載例②（backup_selected_vms）

次に、vm_backup.yml から最初にロードするように指定した「svt/backup_seleted_vms」の中身を見てみましょう（図4）。

OmniStack REST APIアクセストークンを取得するタスクである”get_token”、仮想マシン情報を取得するタスクである”get_vm_id”、該当仮想マシンのバックアップを取得するタスクである”create_vm_backup”、仮想マシンのバックアップタスクの完了を待つタスクである”wait_task_finish”など、それぞれのタスクを細かく分割したPlaybookに分けて流用することがAnsibleのrolesの考え方です。

なお、｛｛ ｝｝で括られている部分が変数を使用する書式となります。

  図4：backup_selected_vms.ymlの中身

Playbookの記載例③（create_vm_backup）

最後に実際のバックアップ処理を担うPlaybook「create_vm_backup.yml」のサンプルを見てみましょう（図５）。

中を見ると、URIモジュールを使用していることが分かります。そして全体の書式は、連載第6回でご紹介したREST APIでのバックアップタスクの実行と非常に似た書き方になっています。

あとは、このバックアップタスク処理結果を後続のPlaybookにて再利用できるようにregisterで変数に格納し、本当にバックアップ処理が完了しているか戻り値チェックを実施してあげると、専用モジュールが無くとも複雑にならず、うまくハンドリングさせることができます。

 図5：create_vm_backup.ymlの中身

いかがでしたでしょうか？

Ansibleを使うには少々ハードルが高いと感じられたかもしれません。可読性に優れているとは言え、Yamlに慣れていない方だとそのように感じてしまうかもしれません。ですが、昨今のIT業界では“自動化”のキーワードがにぎわい、その先のDevOpsや、新しいアーキテクチャーのインフラ/アプリケーション対応も求められる時代となっており、APIでの制御や自動化ツールの活用が必要不可欠となりつつあります。

SimpliVityだけのためにRESTやAnsibleを覚えるのはハードルが高いと思いますが、ネットワークスイッチを含め多くのインフラ製品がこれらに対応し始めているため、無駄にはならないはずです。

先を見据えてこの機会に学習してみるのはいかがでしょうか？

 図6：AnsibleやRESTで運用管理できる世界

次回は「SimpliVity x Ansible」のユースケースや活用方法を紹介したいと思います。