osc2016 kyoto heat + ansible + jupyter
TRANSCRIPT
OpenStack Heat + Ansible + JupyterNotebook動的に変化する環境への自動化適用例
2017/7/30
Tomoaki Nakajima @irix_jp1
OSC2016 Kyoto
発表者
中島倫明(Tomoaki Nakajima) @irix_jp
o 日本OpenStackユーザ会 ボードメンバー(初代会長 2013-2015)
o 東京大学 非常勤講師(S1/S2 月曜 2限)
o 国立情報学研究所/TOPSE 講師
o 一般社団法人クラウド利用促進機構 技術アドバイザー
2
Infrastructure as a Code
ITの現場から「不確定」な要素を取り除き、品質向上と結果としてのコスト削減を実現する。
o 人為的ミス(見間違え、入力ミス、やったつもり、対象間違えなど)の防止
o 確実な再発防止
単純リソースの提供ではなく、「機能」を提供していくためにも有効。
o 開発チームが使いやすい、手間の少ない環境を提供
o 単純リソースの提供がしたいならパブリッククラウドでほとんどのケースは十分。
o 「機能」を提供することでプライベートクラウドの意味が出てくる。
ツールチェーンで実現
o そのツールが得意とする機能のみを利用して、複数の機能を連結。
o 昔は1つのツールを使いこなしていくのが主流。
ライセンスの問題。 ↔ 主流機能のOSS化
1つのツールに依存することになる。 ↔ 1つのツールへの依存度が低くなる
苦手な事もこのツールをやりくり(学習コスト高)。 ↔ 得意なことだけをやる(低)
新しいツールが世に出ても容易に組み込めない。 ↔ 容易に組み込める
3
ツールチェーンのポイント
インフラを「特別扱い」しないo サーバーやネットワークもツールチェーンを構成する一機能として扱う。
o 逆にツールチェーンの一部として扱えないような環境はもはや論外。
4
環境の作成要求
チケット発行
Notebook実行
Job実行
プレイブックノートブック
Playbook実行
環境の構築テスト
結果の保存
結果の確認
チケットクローズ
環境の利用
★
★
★
OpenStack
インフラ層の抽象化o 物理・仮想マシン、ストレージ、ネットワークが主な対象
o 実行層の隠蔽
o 標準化されたAPIの提供
5
仮想サーバコントローラ
(Nova)
仮想NWコントローラ(Neutron)
仮想ストレージコントローラ(Cinder)
認証/ユーザ管理(Keystone)
ユーザアプリケーション
OpenStack APIOpenStackコントローラ
ドライバ(OSS/製品)
ドライバ(OSS/製品)
ドライバ(OSS/製品)
実行層
管理層
サーバ仮想化機能
汎用サーバ
仮想サーバ
仮想サーバ
ストレージ仮想化機能
汎用サーバ/ストレージ製品
ネットワーク仮想化機能
汎用サーバ/NW製品
仮想ルータ
仮想FW
API/独自インタフェース(検証された組み合わせを提供)
※簡略化のため主要機能の概略のみ記載
仮想ストレージ
WebUI(Horizon)
実行層のエコシステム
アプリ層のエコシステム
Heat
OpenStackのコンポーネントの1つで、OpenStack上のリソース(仮想マシンや仮想ネットワーク)を操作する事に特化している。
システムを構成するリソースをデータ構造(YAML)として定義し、それをHeatに読み込ませることで、実際のシステム環境を構築する。
このデータ構造を定義するファイルをHOT(Heat Orchestration Template)と呼ぶ。
6
parameters:cluster_size:type: numberlabel: Cluster sizedescription: Number of
instances in cluster.default: 2
resources:tiny_cluster:type:
OS::Heat::ResourceGroupproperties:count: { get_param:
cluster_size }resource_def:type: OS::Nova::Server
HOT
WEBサーバー APサーバー DBサーバー
実際のシステム環境
Heatにロードさせる
OpenStack環境
Ansible
手順をまとめて「仕事」という単位でPlaybookという形式で記述する。
記述した順番通りに実行される「手順ベース」の考え方。
手順実行を助けてくれる便利な「モジュール」がたくさんある。
Ansibleは実行元ホストで実行可能なファイルを生成し、SSH経由で他ホストへ転送してから実行します。そのため、エージェントレスで動作し、SSHが到達可能な範囲であればどこでも実行することが可能となります。
7
Ansible
実行可能ファイル
実行可能ファイル
pingモジュール
setupモジュール
Inventoryファイル
sshd1
2
3
指定されたモジュールをインポートする
生成された実行可能ファイルを実行先ホストへ送信する
指定されたグループのホスト群に関する情報を取得する
モジュールから実行ファイルを生成する
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
デモ(シンプルなツールチェーン)
ポイント
o 入力した変数によって、構築される環境の構成(サーバー台数)が変わる。
o サーバー台数を検出して手順が実行される先が変更される。
Ansible のダイナミックインベントリ
o 基本的には結果を確認しながらエンターを押すだけ。
9
変数の入力手順の実行
HOT実行
環境の構築
Playbook実行
ソフトの設定
結果の確認結果の確認
まとめ
自動化は進化しています。
o 操作対象が動的に変化しても対応可能
ツールチェーンという考え方
o 得意な機能をつなげてやりたいことを実現していく
o インフラもチェーンの一部
手順書にも一工夫
o 実行可能な手順書
10
11
ご静聴ありがとうございました