HPE Blog, Japan
キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 

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

yoshihiko1989

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

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

 

Ansibleの登場人物

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

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

図1.png

 

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

 

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

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

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

 

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

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

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

 

varsファイル

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

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

roles

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

site.yml

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

図2.png

 図1:Ansibleのディレクトリ設計例

 

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

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

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

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

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

図3.png図2:実際のPlaybookに沿ったディレクトリ構造

 

Playbookの記載例①(vm_backup.yml

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

図4.png

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

 

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

3include_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に分けて流用することがAnsiblerolesの考え方です。

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

図5.png

  図4:backup_selected_vms.ymlの中身

 

Playbookの記載例③(create_vm_backup

最後に実際のバックアップ処理を担うPlaybookcreate_vm_backup.yml」のサンプルを見てみましょう(図5)。

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

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

図6.png

 図5:create_vm_backup.ymlの中身

 

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

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

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

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

図7.png

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

 

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

0 感謝
作者について

yoshihiko1989

日本ヒューレット・パッカード株式会社で Server / HCI / Composable / CloudNative関連のプリセールスを主に担当してます。