OSC2016 Kyoto での発表資料です。

1. OpenStack Heat + Ansible + JupyterNotebook
動的に変化する環境への自動化適用例
2017/7/30
Tomoaki Nakajima @irix_jp
1
OSC2016 Kyoto

2. 発表者
 中島倫明（Tomoaki Nakajima） @irix_jp
o 日本OpenStackユーザ会 ボードメンバー（初代会長 2013-2015）
o 東京大学 非常勤講師（S1/S2 月曜 2限）
o 国立情報学研究所／TOPSE 講師
o 一般社団法人クラウド利用促進機構 技術アドバイザー
2

3. Infrastructure as a Code
 ITの現場から「不確定」な要素を取り除き、品質向上と結果としてのコ
スト削減を実現する。
o 人為的ミス（見間違え、入力ミス、やったつもり、対象間違えなど）の防止
o 確実な再発防止
 単純リソースの提供ではなく、「機能」を提供していくためにも有効。
o 開発チームが使いやすい、手間の少ない環境を提供
o 単純リソースの提供がしたいならパブリッククラウドでほとんどのケースは十分。
o 「機能」を提供することでプライベートクラウドの意味が出てくる。
 ツールチェーンで実現
o そのツールが得意とする機能のみを利用して、複数の機能を連結。
o 昔は１つのツールを使いこなしていくのが主流。
 ライセンスの問題。 ↔ 主流機能のOSS化
 １つのツールに依存することになる。 ↔ １つのツールへの依存度が低くなる
 苦手な事もこのツールをやりくり（学習コスト高）。 ↔ 得意なことだけをやる（低）
 新しいツールが世に出ても容易に組み込めない。 ↔ 容易に組み込める
3

4. ツールチェーンのポイント
 インフラを「特別扱い」しない
o サーバーやネットワークもツールチェーンを構成する一機能として扱う。
o 逆にツールチェーンの一部として扱えないような環境はもはや論外。
4
環境の作成要求
チケット発行
Notebook
実行
Job実行
プレイブックノートブック
Playbook
実行
環境の構築
テスト
結果の保存
結果の確認
チケットクローズ
環境の利用
★
★
★

5. OpenStack
 インフラ層の抽象化
o 物理・仮想マシン、ストレージ、ネットワークが主な対象
o 実行層の隠蔽
o 標準化されたAPIの提供
5
仮想サーバ
コントローラ
（Nova）
仮想NW
コントローラ
（Neutron）
仮想ストレージ
コントローラ
（Cinder）
認証/ユーザ管理
（Keystone）
ユーザアプリケーション
OpenStack API
OpenStackコントローラ
ドライバ
（OSS/製品）
ドライバ
（OSS/製品）
ドライバ
（OSS/製品）
実行層
管理層
サーバ
仮想化機能
汎用サーバ
仮想
サーバ
仮想
サーバ
ストレージ
仮想化機能
汎用サーバ/
ストレージ製品
ネットワーク
仮想化機能
汎用サーバ/
NW製品
仮想
ルータ
仮想
FW
API/独自インタフェース
（検証された組み合わせを提供）
※簡略化のため主要機能の概略のみ記載
仮想ストレージ
WebUI
（Horizon）
実行層のエコシステム
アプリ層のエコシステム

6. Heat
 OpenStackのコンポーネントの1つで、OpenStack上のリソース
（仮想マシンや仮想ネットワーク）を操作する事に特化している。
 システムを構成するリソースをデータ構造(YAML)として定義し、
それをHeatに読み込ませることで、実際のシステム環境を構築す
る。
 このデータ構造を定義するファイルをHOT(Heat Orchestration
Template)と呼ぶ。
6
parameters:
cluster_size:
type: number
label: Cluster size
description: Number of
instances in cluster.
default: 2
resources:
tiny_cluster:
type:
OS::Heat::ResourceGroup
properties:
count: { get_param:
cluster_size }
resource_def:
type: OS::Nova::Server
HOT
WEBサーバー APサーバー DBサーバー
実際のシステム環境
Heatにロードさせる
OpenStack環境

7. Ansible
 手順をまとめて「仕事」という単位でPlaybookという形式で記述する。
 記述した順番通りに実行される「手順ベース」の考え方。
 手順実行を助けてくれる便利な「モジュール」がたくさんある。
 Ansibleは実行元ホストで実行可能なファイルを生成し、SSH経由で他ホストへ転送し
てから実行します。そのため、エージェントレスで動作し、SSHが到達可能な範囲であ
ればどこでも実行することが可能となります。
7
Ansible
実行可能ファイル
実行可能ファイル
ping
モジュール
setup
モジュール
Inventory
ファイル
sshd1
2
3
指定されたモジュールをインポートする
生成された実行可能ファイルを実行先ホストへ
送信する
指定されたグループのホスト群に
関する情報を取得する
モジュールから実行ファイルを生成
する

8. Jupyter Notebook
 実行可能・再現可能な「手順書」をノートブックという形式で作
成し、実行する手順や実行結果を保存できる。
o Literate Computing for Reproducible Infrastructure
 自動化の課題を解決
o 結局、ある処理をまとめて自動化しても、誰かがその自動化のトリガーを
実行する必要がある。
o 自動化を実装することで、その自動化を利用するための作法が作られるの
で、それ如何に間違いなく実行するか？
 ノートブックで出来ること
o そのまま実行可能なコマンドを記述できる（コピペの必要なし）
 一部のオプションを変更した実行も可能
o 実行のための前提条件等をMarkdownで記述できる。
o 実行結果を保存できる。
o テキスト形式なので git 等のバージョン管理システムとの相性良し。
 ちょっと工夫が必要。
8Literate Computing for Reproducible Infrastructure についてはこちらを参照
http://www.slideshare.net/nobu758/literate-computing-for-infrastructure-ipython-jupyter-notebook

9. デモ（シンプルなツールチェーン）
 ポイント
o 入力した変数によって、構築される環境の構成（サーバー台数）が変わる。
o サーバー台数を検出して手順が実行される先が変更される。
 Ansible のダイナミックインベントリ
o 基本的には結果を確認しながらエンターを押すだけ。
9
変数の入力
手順の実行
HOT実行
環境の構築
Playbook
実行
ソフトの設定
結果の確認結果の確認

10. まとめ
 自動化は進化しています。
o 操作対象が動的に変化しても対応可能
 ツールチェーンという考え方
o 得意な機能をつなげてやりたいことを実現していく
o インフラもチェーンの一部
 手順書にも一工夫
o 実行可能な手順書
10

11. 11
ご静聴ありがとうございました