【cloud week 2015@hokkaido university】dockerとインフラ運用自働化とiot

Copyright © 2015 TIS Inc. All rights reserved.

Cloud Week 2015 @ Hokkaido University

Docker とインフラ運用自動化と IoT

2015 年 9 月 9 日

TIS 株式会社　戦略技術センター　エキスパート　松井暢之

Copyright © 2015 TIS Inc. All rights reserved. 2

松井暢之（まつい　のぶゆき）TIS 株式会社　戦略技術センター

～ 2003

2003 ～ 2008

2009

2010 ～ 2012

2013 ～

2015 ～

現場 PJ でアーキテクト兼モデラー兼プログラマ兼…を歴任

基盤技術センター（現戦略技術センター）で不芳 PJ の火消しに奔走

全社生産性向上の企画策定に従事

オープンでエッジな技術を活用した事業企画に従事

OSS クラウドオーケストレータ “ CloudConductor®” の開発に着手

IoT プラットフォーム関連の研究開発に着手

nbyk.matsui nmatsuinbyk.matsui@n_matsui


Agenda1. インフラ運用の自”働”化と Infrastructure as Code2. インフラ運用自働化のツール

3. Docker を用いたインフラ単体テストのデモ

4. クラウド &IoT 時代のインフラ運用自働化

5. まとめ


インフラ運用の現実

かつての（今も？）のインフラ運用の現実

手順書とパラメータシートを元に、エンジニアが手作業で一行一行コマンドを入力していた。

人為的ミスを防止するために、コマンドを実行する毎に複数人で再鑑するチェック体制が必要だった。

Marc and Lancelot in Redwood City by Sean Ellis, on Flickr



かつての（今も？）のインフラ運用の現実

Shell Script 等を用いてある程度はインフラ運用作業を自動化しているとしても、まだまだ不十分。

出展： REBELLABS, “IT OPS & DEVOPS PRODUCTIVITY REPORT 2013 “, 2013-04,　　　 http://zeroturnaround.com/rebellabs/rebel-labs-release-it-ops-devops-productivity-report-2013/4/



手作業の運用による弊害

コマンドのコピペミスによる障害発生

コマンドの実行順序を間違えたり、あるいは飛ばしたり重複実行してしまうことによる障害発生

環境の前提条件が異なっていることに気づかずに shell script を流してしまうことによる障害発生

苦労する割に障害が無くてあたりまえ、という心的外圧

・・・

76/365 - Tired by Shane Robinson, on Flickr


インフラ運用の自”働”化

自”働”化されたインフラ運用への転換

インフラ運用をいつでも正しく機械的に構築するスクリプト

インフラ運用の正当性を機械的に検証するスクリプト

スクリプトを用いてインフラの構築や運用を自”働”的に実施

インフラ運用の設計書

人が手作業でインフラ運用を構築し検証する

機械が自”働”的にインフラ運用を構築し検証する

インフラ運用の構築スクリプト

インフラ運用のテストスクリプト

インフラ運用のテスト手順書

インフラ運用のノウハウをプログラムとして資産化

これまでのインフラ運用今からのインフラ運用

ニンベンの付く「自働化」トヨタ生産方式で使われる言葉。作られたものが良品であれ不良品であれ、ただ単に機械的に動き続けることを意味する「自動化」とは異なり、「不都合を検知して停止」する行為をも自律的に行えることを意味する。「自働化」により、少なくとも「検知可能な不都合が起きていないこと」が保証される。


Infrastructure as Code インフラ運用の維持管理を、手順書やパラメータシートを用いた手

作業で行うのではなく、インフラ運用のあるべき姿をプログラム（コード）として書き下し、コードを元にインフラ運用を機械的に構成する仕組みのこと。

Infrastructure as Code により、次のようなメリットが得られる。

手作業によるミスや手間の削減

プログラムによる自働処理のため、人為的ミスが入り込まない。

人的リソースの限界に囚われず、大量のインフラを並列に構成することもできる。

設計と実装の乖離の防止

インフラ運用を構成しテストするプログラム自身がインフラ運用の設計書となるため、設計と現実の乖離が起きない。

(次ページに続く）


Infrastructure as Code( 前ページからの続き）

インフラ運用のバージョン管理

アプリケーション開発と同様、インフラ運用もバージョン管理ができるようになる（インフラの差分把握、レビュー、ブランチング等）。（都度生成されているデータは過去に戻せないので、注意が必要）

インフラ運用の継続的テスト

インフラ運用のあるべき姿をテストプログラムとして表現し、自動的・継続的にテストをし続けることで、インフラ運用の更改時に品質を維持することができる。


インフラ運用の自”働”化に関連する代表的なツールやサービス（便宜的な分類であり、複数のレイヤの機能を持つツールも多い）

構築テスト

インフラ運用の自”働”化に関連するツールやサービス

Bootstrapping　 OS の起動を自動化するツール

LXC

OpenStack Amazon Web Services

Software Defined Infrastructure　 API を通じて操作できるインフラ

Orchestration　アプリのデプロイや運用等を含め、　システム全体として協調動作させる　ツール

AWS OpsWorks

Configuration　 OS の設定やミドルウェアの　インストール・設定を自動化　するツール PuppetChef Ansible

Test Kitchen

宣伝


CloudConductor とは

デザイン指向クラウドオーケストレータ

システム構築のノウハウを込めたパターンを組み合わせ、クラウドへシステム全体を「自”働”構築」するツール。

パターン

パターン開発者

システム構築者

CI



システムのライフサイクルイベントごとに、各サーバが実行すべき処理をコードで記述しておけば、イベント発生時に各サーバが自律的に自らを望まれた状態へ構成する。

Setup

Configure

Deploy

BackupRestore

サーバ単体の構築

サーバを組み合わせシステム全体を構築

アプリケーションのデプロイ

バックアップ取得時DR, システム切替時



公式サイト　 http://cloudconductor.org

ソーシャルhttps://twitter.com/ccndctrhttps://www.facebook.com/cloudconductorhttps://github.com/cloudconductorhttp://www.slideshare.net/cloudconductor

平成 25 年度～平成 27 年度の経済産業省補助金事業に採択され活動中

開発成果は全てオープンソース（ Apache License 2.0 ）として公開



（株）あくしゅ様との共同研究

仮想データセンター　 VDC （ Virtual DataCenter ）

クラウドの差異を吸収し、クラウドの存在を意識することなく「単一の DC を指定した API で操作している」かのように扱う

・・・

仮想データセンター（ VDC ）クラウドを跨った資源管理（仮想マシン・仮想ネットワーク・仮想ストレージ等）

クラウド A 用のドライバ

ハードウェア資源（クラウド A ）

クラウド B 用のドライバ

ハードウェア資源（クラウド B ）

VDC API

OpenStack on VDCOpenStack API

OpenStack API で資源管理

仮想マシン

Docker on VDCDocker API

Docker API で資源管理

コンテナ・・・



大阪大学様との共同研究

海外を含む複数拠点を結ぶ広域分散ストレージ

弊社の DC 、 SoftLayer東京 DC 、 San Jose DC で分散ストレージを構築し、その上で実利用を想定した環境を構築して性能・耐障害性等を検証TIS DC (東京 )

Front Server

Backend Ring

Backend Ring

Backend Ring

SoftLayer TokyoDC

Front Server

Backend Ring

Backend Ring

Backend Ring

東京 POP

etherXENfor SoftLayer

(1Gbps)

SoftLayerDirectLink

SoftLayer San JoseDC

Front Server

Backend Ring

Backend Ring

Backend Ring

SoftLayer内部 NW

Web, AP, DB

同期

広域分散ストレージ

非同期

config WAL

data

config WAL

data

Web, AP, DB

Web, AP, DB

config WAL

data





5. まとめ


CloudConductor が利用しているインフラ運用自働化のための OSSツールをいくつか紹介する。

Configuration ： Chef 、 Serverspec 、 Test KitchenBootstrapping ： DockerSoftware Defined Infrastructure ： Openstack 、 AWS

インフラ運用自働化に関連するツールの紹介

構築テストConfiguration　 OS の設定やミドルウェアの　インストール・設定を自動化　するツール PuppetChef Ansible

Test Kitchen

Bootstrapping　 OS の起動を自動化するツール

LXC


Chef とは

Chef 社が開発しているインフラ構成管理ツール

コア機能（ Essentials ）は OSS公開されており、 Chef 自体の高可用性や管理機能のオプション、サポート等が有償販売されている

インフラの「あるべき姿」をコードとして記述しておけば、そのあるべき姿へ自動的にインフラが構成される。

今のインフラの状態を調査し、どのコマンドをどの順序で実行すれば良いか、などと考える必要はない。

そのためには、サーバに対してある操作を一度だけ実行した場合でも複数回実行した場合でも、同じ結果にならなければならない。（これを冪等性という）

Shell Script を冪等に書くのは非常に面倒だが、 Chef のルールに従ってインフラをコード化すれば、冪等性を容易に実現できる

Chef


Chef の cookbookインフラのあるべき姿を宣言したコードをまとめたもの。

（例えば「 apache2 の cookbook 」のような単位）

cookbook は以下のような要素で構成される。

recipe : インフラを構成するパーツのあるべき姿を記述する（ apache2 が入っていて、 port 80 が開いていて

…）

template : 設定ファイル等を動的に生成するための雛形（ httpd.conf の ServerName はコレで、…）

attribute : cookbook内で利用する変数のデフォルト値を定義する

（必要であれば実行時に上書きすることもできる）

等

これらの要素は Chef が独自拡張した Ruby DSL で書く。

Chef

後ほど実例を紹介


Serverspec とは

想定している「あるべき姿」通りにサーバが構成されているかをサーバの内部からテストするためのインフラツール。

apache2 が入っているか、 port 80 が開いていているか、httpd.conf の ServerName は正しく設定されているか、…

インフラ運用のテストを機械化することで、インフラ運用のコードがデグレードしたり不具合が混入していないことを継続的にチェックし続けることができる。（アプリケーション開発の「継続的インテグレーション」と同様）

Serverspec のテストスクリプトは、 RSpec という Ruby 業界では良く使われている Ruby DSL で書く。

Serverspec

後ほど実例を紹介


Test Kitchen Test Kitchen とは

Chef のテストフレームワークの一つ。

様々な Bootstrapping で自動的にテスト環境を立ち上げ、 cookbook を適用した後に、様々なインフラテストツールで自動的にテストを実行し、不要になったテスト環境を自動で削除する。

対応している Bootstrapping の例 : AWS 、 OpenStack 、 Docker…

対応しているインフラテストツールの例 : Serverspec 、 bats…


Docker とは

コンテナ技術を用いてアプリケーションの実行環境を簡単迅速にオーバーヘッド少なく立ち上げるための仕組み。

Docker には Dockerfile という独自の Infrastructure as Codeの仕組みがあり、 Docker 上で稼働する実行環境イメージをコードから構成することができる。

Chef とは異なり、 Dockerfile には冪等性を担保する仕組みが無い。

ただし Docker コンテナを使い捨てにする（インフラ構成を変更する場合はコンテナを作り直す）ならば、冪等性が無くても問題無い。（この考え方は、 Immuable Infastructure と呼ばれる）

Docker以外の環境も含めてインフラをコードで管理するのであれば、 Dockerfile に直接処理を書くのではなく、別途 Chef などのインフラ構成管理ツールを使うほうが良い。

Docker


Docker Docker とコンテナイメージの配布

Docker には Docker Regisgry という Docker イメージを集中管理する仕組みがある。

Dockerfile やその他の Infrastrucutre as Code から、あるいは手作業で生成された Docker イメージを登録する

Docker エンジンが動作しているサーバからの要求に従い、登録されたコンテナイメージを配布する

Dockerfile やcookbook 等

Docker イメージ

OS イメージ

ミドルウェア

フレームワーク

・・・

生成

Docker Registry

登録

Linuxカーネル

OS イメージ

ミドルウェア


・・・

Docker Engine

配布

要求

検証


インフラ運用自働化と Docker を組み合わせるメリット

インフラ運用単体テストのスピード向上

Infrastructure as Code の単体テストは、 Bootstrap が素早いDocker で行うと良い。

Infrastructure as Code の単体テストをクラウドで行うと、インスタンス立ち上げにどうしても時間がかかる。（パブリッククラウドだとさらにコストもかかる）

ただし Docker のネットワーキングは特殊なため、複数のサーバを組み合わせた結合テストは実際のクラウドで行うほうが良い。

インフラのポータビリティ向上

Docker エンジンが動作している様々なクラウドで同じイメージから Docker コンテナを立ち上げることができるため、インタークラウドでの移植性に優れる。





5. まとめ


Docker を用いたインフラ単体テストのデモ

デモを行うインフラ構成のあるべき姿

対象となるのは Webサーバ１台

Webサーバには apache2 と PHP がインストールされている

Webサーバを再起動しても apache2 は自動起動する

Webサーバの apache2 は起動している

デモ用の PHP ページが配置されており、次の URL で参照できる

http://<Webサーバの IP アドレス >/index.php


デモ用の cookbook Webサーバを構成する recipe

apache2 や PHP をインストールするために、最初にパッケージ設定ファイルをアップデート

apache2 と PHP をパッケージからインストール

apache2 の自動起動を設定し、再起動

デモ PHP ページをテンプレートから生成してapache2 の DocumentRoot に配置


デモ用の cookbook デモ PHP ページの template

<%= … %> の部分は recipe から与えられた変数に自動的に置き換えられる


デモ用の cookbook 変数のデフォルト値を定義した attributes

OS の種類ごとに異なるデフォルト値を定義


デモ用の serverspec script Webサーバがあるべき姿に構成されていることを確認するスクリプ

ト

apache2 と PHP パッケージがインストールされている

apache2 は自動起動するapache2 は起動中である

apache2 プロセスが動作している

ポート 80 が Listen している

http://localhost/index.php にアクセスした際のステータスコードが 200 OK である

http://localhost/index.php から得た結果には<h1>Web Test</h1> という文字が含まれる


Test Kitchen の設定ファイル

cookbook を Docker 上で単体テストするための設定ファイル

単体テストは Docker 上で実行

プロビジョニングは chef zero

単体テストをする OS は Ubuntu 14.04

単体テストをする recipe


デモ

Docker 上での単体テストログ





5. まとめ


クラウド &IoT 時代の到来

Google Trends における検索ボリュームの推移

2014 年から「 IoT 」や「 Internet of Things 」の検索ボリュームが急拡大している。

クラウド

IoT

Internet of Things

出展： Google Trends, http://www.google.co.jp/trends/explore#q=Internet%20of%20Things%2C%20iot%2C%20%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89&date=1%2F2007%20104m&cmpt=q&tz=Etc%2FGMT-9


クラウド &IoT 時代の到来

相互接続されるデバイス数の予測

2020 年には、最大で 500億個のデバイスが相互接続されると予測されている。

出展： IoT Analytics, "IoT Market – Forecasts at a glance“, 2014-10, http://iot-analytics.com/iot-market-forecasts-overview/


クラウド &IoT のインフラ運用

IoT に関わるデバイスの数は従来とは桁違いに多くなる。

IC タグのような安価で単機能なセンサー類は、使い捨てにすることもできる。

しかしスマートフォンやロボットのような、高価で高機能なデバイスは、ミドルウェアやアプリケーションの配布や更新、障害対応等の「インフラ運用」が必要となる。

出展：ヴィストン株式会社 , 普及型ロボットプラットフォーム「 Sota （ソータ）」 , http://www.vstone.co.jp/products/sota/


IoT のオーケストレーション

莫大な数の IoT デバイスを手作業で運用することは現実的ではない。「自働化」「自律化」、及び「オーケストレーション」が必須となる。

IoT のインフラ運用自働化の仕組みにはまだデファクトはないが、Infrastructure as Code とアプリケーション実行イメージの配布が使えるかもしれない

IoT デバイスのInfrastructure

as Codeデバイスのイメージ

OS イメージ

ミドルウェア


・・・

生成

Registry

登録

IoT OS

OS イメージ

ミドルウェア


・・・

コンテナエンジン

配布

要求

検証





5. まとめ


まとめ

旧来の手作業のインフラ運用から脱却し、 Infrastructure as Codeを基本としたインフラ運用の自”働”化を目指さなければならない。

インフラ運用の自働化に関連する様々な OSS ツールがあるので、実際に触ってみて適切に利用すると良い。

Docker を上手く組み込むことで、インフラ運用自働化の幅が広がる。

インフラ運用自働化のノウハウは、クラウド &IoT 時代においてもますます重要度を増すだろう。

【cloud week 2015@hokkaido university】dockerとインフラ運用自働化とiot

Technology