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

OSC2016 Kyoto Heat + Ansible + Jupyter

  • Upload
    irixjp

  • View
    547

  • Download
    1

Embed Size (px)

Citation preview

Page 1: OSC2016 Kyoto Heat + Ansible + Jupyter

OpenStack Heat + Ansible + JupyterNotebook動的に変化する環境への自動化適用例

2017/7/30

Tomoaki Nakajima @irix_jp1

OSC2016 Kyoto

Page 2: OSC2016 Kyoto Heat + Ansible + Jupyter

発表者

中島倫明(Tomoaki Nakajima) @irix_jp

o 日本OpenStackユーザ会 ボードメンバー(初代会長 2013-2015)

o 東京大学 非常勤講師(S1/S2 月曜 2限)

o 国立情報学研究所/TOPSE 講師

o 一般社団法人クラウド利用促進機構 技術アドバイザー

2

Page 3: OSC2016 Kyoto Heat + Ansible + Jupyter

Infrastructure as a Code

ITの現場から「不確定」な要素を取り除き、品質向上と結果としてのコスト削減を実現する。

o 人為的ミス(見間違え、入力ミス、やったつもり、対象間違えなど)の防止

o 確実な再発防止

単純リソースの提供ではなく、「機能」を提供していくためにも有効。

o 開発チームが使いやすい、手間の少ない環境を提供

o 単純リソースの提供がしたいならパブリッククラウドでほとんどのケースは十分。

o 「機能」を提供することでプライベートクラウドの意味が出てくる。

ツールチェーンで実現

o そのツールが得意とする機能のみを利用して、複数の機能を連結。

o 昔は1つのツールを使いこなしていくのが主流。

ライセンスの問題。 ↔ 主流機能のOSS化

1つのツールに依存することになる。 ↔ 1つのツールへの依存度が低くなる

苦手な事もこのツールをやりくり(学習コスト高)。 ↔ 得意なことだけをやる(低)

新しいツールが世に出ても容易に組み込めない。 ↔ 容易に組み込める

3

Page 4: OSC2016 Kyoto Heat + Ansible + Jupyter

ツールチェーンのポイント

インフラを「特別扱い」しないo サーバーやネットワークもツールチェーンを構成する一機能として扱う。

o 逆にツールチェーンの一部として扱えないような環境はもはや論外。

4

環境の作成要求

チケット発行

Notebook実行

Job実行

プレイブックノートブック

Playbook実行

環境の構築テスト

結果の保存

結果の確認

チケットクローズ

環境の利用

Page 5: OSC2016 Kyoto Heat + Ansible + Jupyter

OpenStack

インフラ層の抽象化o 物理・仮想マシン、ストレージ、ネットワークが主な対象

o 実行層の隠蔽

o 標準化されたAPIの提供

5

仮想サーバコントローラ

(Nova)

仮想NWコントローラ(Neutron)

仮想ストレージコントローラ(Cinder)

認証/ユーザ管理(Keystone)

ユーザアプリケーション

OpenStack APIOpenStackコントローラ

ドライバ(OSS/製品)

ドライバ(OSS/製品)

ドライバ(OSS/製品)

実行層

管理層

サーバ仮想化機能

汎用サーバ

仮想サーバ

仮想サーバ

ストレージ仮想化機能

汎用サーバ/ストレージ製品

ネットワーク仮想化機能

汎用サーバ/NW製品

仮想ルータ

仮想FW

API/独自インタフェース(検証された組み合わせを提供)

※簡略化のため主要機能の概略のみ記載

仮想ストレージ

WebUI(Horizon)

実行層のエコシステム

アプリ層のエコシステム

Page 6: OSC2016 Kyoto Heat + Ansible + Jupyter

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環境

Page 7: OSC2016 Kyoto Heat + Ansible + Jupyter

Ansible

手順をまとめて「仕事」という単位でPlaybookという形式で記述する。

記述した順番通りに実行される「手順ベース」の考え方。

手順実行を助けてくれる便利な「モジュール」がたくさんある。

Ansibleは実行元ホストで実行可能なファイルを生成し、SSH経由で他ホストへ転送してから実行します。そのため、エージェントレスで動作し、SSHが到達可能な範囲であればどこでも実行することが可能となります。

7

Ansible

実行可能ファイル

実行可能ファイル

pingモジュール

setupモジュール

Inventoryファイル

sshd1

2

3

指定されたモジュールをインポートする

生成された実行可能ファイルを実行先ホストへ送信する

指定されたグループのホスト群に関する情報を取得する

モジュールから実行ファイルを生成する

Page 8: OSC2016 Kyoto Heat + Ansible + Jupyter

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

Page 9: OSC2016 Kyoto Heat + Ansible + Jupyter

デモ(シンプルなツールチェーン)

ポイント

o 入力した変数によって、構築される環境の構成(サーバー台数)が変わる。

o サーバー台数を検出して手順が実行される先が変更される。

Ansible のダイナミックインベントリ

o 基本的には結果を確認しながらエンターを押すだけ。

9

変数の入力手順の実行

HOT実行

環境の構築

Playbook実行

ソフトの設定

結果の確認結果の確認

Page 10: OSC2016 Kyoto Heat + Ansible + Jupyter

まとめ

自動化は進化しています。

o 操作対象が動的に変化しても対応可能

ツールチェーンという考え方

o 得意な機能をつなげてやりたいことを実現していく

o インフラもチェーンの一部

手順書にも一工夫

o 実行可能な手順書

10

Page 11: OSC2016 Kyoto Heat + Ansible + Jupyter

11

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