次世代クラウド勉強会 　テーマ：【Docker、DevOpsを取り巻くマイクロサービスのコンセプト】 http://connpass.com/event/20426/

1. 背景画像CREDIT:videodoctor / PIXTA(ピクスタ)
https://pixta.jp/@prof306848
HashiCorp
の考える Microservices と
Nomad,Otto
@zembutsu
#ms_study
次世代クラウド勉強会
Docker、DevOpsを取り巻く
マイクロサービスのコンセプト
Oct 9, 2015

2. 背景画像CREDIT:videodoctor / PIXTA(ピクスタ)
https://pixta.jp/@prof306848
HashiCorp
の考える Microservices と
Nomad,Otto
今日の内容
‣ HashiCorpとは？
‣ NomadはDockerスケジューラ
‣ OttoはVagrantの後継ソフト
HashiCorpについてと、先週に
発表されたNomadとOttoの概要
そして使い方をご紹介。
@zembutsu
#ms_study
次世代クラウド勉強会
Docker、DevOpsを取り巻く
マイクロサービスのコンセプト
Oct 9, 2015

3. 3
自己紹介
‣ @zembutsu a.k.a. 前佛雅人
- Technology Evangelist; Creationline, Inc. – 1.5 yrs
- Data Center Operations Engineer – 15+ yrs
興味関心：運用監視自動化、趣味でOSSやクラウド系の検証・情報発信
- SlideShare http://slideshare.net/zembutsu
- Blog http://pocketstudio.jp/log3
書籍・記事
- Serf/Consulで管理を自動化！ (Gihyo.jp)
http://gihyo.jp/admin/feature/01/serf-consul
- HashiCorpのツール群からみる
インフラ構築運用の未来 (Think IT)
http://thinkit.co.jp/book/2015/03/05/5700
Why am I here?
+MasahitoZembutsu
ISBN-10: 4774174416 ISBN-10: 4844338145 ISBN-10: 4798139785

4. 会社としてはパートナーですが

5. 目的や設計なく無理にツールを
導入しようとしても、おそらく
失敗するのではないでしょうか。

6. コンテナについても同様であり
目的なき導入は、炎上不可避
（案件的に）と考えています。

7. Docker
Dockerです。
ご指導ご鞭撻、よろしくです。
コンテナ管理
とはいえ、猫も杓子もドッカー
ドッカーなご時世です。

8. Microservices
SOA
Service Oriented Arcitecture
マイクロサービスも流行の言葉
として「バズってる」感じです。

9. しかし目的なく導入してしても
あとには無残な残骸だけが、
負債として残るかも知れず、
現場は疲弊してしまうのでは
ないでしょうか。

10. 背景画像CREDIT:videodoctor / PIXTA(ピクスタ)
https://pixta.jp/@prof306848
HashiCorp
■□□
それをHashiCorpのツールで
解決できるのでは…？という話

11. 11
HashiCorp
“Powering the software-managed datacenter.”
‣ 2012年設立
Mitchell Hashimoto氏が2010年に開発・発表したVagrantが前身
‣ データセンタ管理に革命をもたらす目的
仮想・物理・コンテナ・クラウド等を組みあわせる状況、その時に生まれる溝を埋めるものを提供
‣ オープンソースで開発過程が公開
設立以後も、コードが公開されているだけでなく、GitHub・IRC で誰でも意見表明できる
HashiCorp(ハシコープ)という
会社名です。コードはすべてが
オープンに公開されています。

12. 12
‣ 技術ありきではなく、どのように実現するか？
最も簡単にするためのワークフローを考え、そこに対応するツールが無ければ作るという設計思想
‣ 単純・モジュール型・組みあわせ可能
Unix哲学と同様、全体の問題を解決するのではなく、個々の要素（コンポーネント）に分解
‣ コードで管理・弾力的システム・実用主義
システムや基盤に対するバージョン管理や自動化によって、システムにとっても人にとっても利点となる
The Tao of HashiCorp
※参考：The Tao of HashiCorp 日本語参考訳 | Pocketstudio.jp log3
http://pocketstudio.jp/log3/2015/03/14/the-tao-of-hashicorp/
彼らは問題を解決するために
各種のツールを作っています。

13. これらはHashiCorpが提供する
ツールやサービスです。

14. 米ポートランドでHashiCorpの
カンファレンスが開催

15. https://nomadproject.io/
https://ottoproject.io/
ここで、２つの新しいツールが
発表されました。

16. vagrant up packerbuild terraform apply
従来はAtlasが各サービスを結
びつける役割でしたが

17. otto dev otto build otto deploy
Ottoは開発者視点で全ツールを
とりまとめる役割。

18. オープン
ソース
Web
インター
フェース
セキュリ
ティ
CLI 共同作業 管理機能コア機能
Git GitHub
Otto Atlas
こんな役割分担。

19. 背景画像CREDIT:videodoctor / PIXTA(ピクスタ)
https://pixta.jp/@prof306848
Nomad
■■□
では１つめの"Nomad"とは…？

20. Nomad
分散スケジューラ
Distributed Scheduler
デプロイを簡単に
Easily Deploy Applications
ジョブの詳細設計
Job Specification
あらゆるリソース管理とスケ
ジュールを処理するもの。

21. コンテナ化
Containerized
仮想化
Virtualized
スタンドアローン
Standalone
Docker
Qemu / KVM
Java Jar
バイナリの実行
Nomad対応環境
Docker以外の環境も同じように
管理できるのが特徴です。

22. Nomad
アプリのデプロイ
Application Deployment
Dockerコンテナ対応
Docker
柔軟なワークロード
Flexible Workloads
リソースを最大限に集約
Bin Packing
HCLによるジョブ定義
HCL Job Specifications

23. 23
‣ マイクロサービスのプラットフォーム
MicroservicesやSOAはアプリケーションの設計が複雑化しているが、その基盤としてNomadを使う
‣ パブリック・クラウドへのデプロイ
マルチリージョン＆マルチデータセンタ機能により、複数のクラウド環境、物理環境を併用できる
‣ ECサイト
長期間稼働するウェブサービスやバッチ処理のバックエンドにおいて、
あらゆるワークロードをクラスタで共有するので、稼働率の向上やコスト削減につながる
使用例の一部 様々なパブリック・クラウドや
物理環境も問わず一括管理。

24. 24
Nomad Amazon ECS Dockre Swarm HTCondor Kubernetes
Mesos with
Aurora,Marathon Terraform Hadoop YARN
ツールの役割
クラスタ管理とスケ
ジューラ
EC2に対応したクラス
タ・マネージャ
Dockerコンテナ向け
のクラスタリング・ソ
リューション
グリッド/コンピュー
ティング環境における
バッチ処理
Dockerを基盤とした
クラスタ管理、スケ
ジューリング、サービ
ス・ディスカバリ、管
理、シークレット管理
リソースマネージャと、
フレームワークと組み
あわせたスケジューリ
ングやジョブ管理
インフラ環境の自動
的な構築・変更と、
バージョン管理
リソース管理とジョブ
スケジューリング
クラスタ管理対象 あらゆる環境 AWSのみ Docker コンテナのみ あらゆる環境 Docker コンテナ あらゆる環境 あらゆる環境 あらゆる環境
対応環境 パブリッククラウド ○ △ ○ ○ ○ ○ ○ ○
プライベートクラウド ○ × ○ ○ ○ ○ ○ ○
仮想化環境 ○ × ○ ○ ○ ○ ○ ○
物理サーバ ○ × ○ ○ ○ ○ ○ ○
リソース管理 ○ ○ ○ × ○ ○ △ ○
ジョブの抽象化 ○ ○ × ○ ○ ○ × ○
アプリケーションの実行 ○ ○ ○ × ○ ○ × △
可用性 ○ ○ △ × ○ ○ △ ○
スケーラビリティ ○ ○ ○ ○ ○ × ○ ○
マルチ・データセンタ ○ × × × × × ○ ×
Nomad vs. スケジューラ
参考：Nomad vs. Other Software - Nomad by HashiCorp
https://nomadproject.io/intro/vs/index.html
ざっくり比較（もしかしたら
変な所があるかも…）

25. サーバ
(リーダー)
サーバ
(フォロワー)
サーバ
(フォロワー)
クライアント クライアント クライアント
RPC RPC RPC
レプリケーション レプリケーション
転送 転送
基本はConsulと同じように、
サーバ・クライアント型です。

26. 26
‣ セットアップ
Nomad の使い方
$ cd /tmp
$ wget -O nomad.zip https://dl.bintray.com/mitchellh/nomad/nomad_0.1.2_linux_amd64.zip
$ unzip nomad.zip
$ sudo mv nomad /usr/bin/nomad
$ sudo chmod 755 /usr/bin/nomad
$ sudo mkdir /etc/nomad.d
$ sudo 757 /etc/nomad.d
使うのは非常にシンプルです。
このバイナリ1個を準備します。

27. zem@dev:~$ sudo nomad agent -dev
==> Starting Nomad agent...
==> Nomad agent configuration:
Atlas: <disabled>
Client: true
Log Level: DEBUG
Region: global (DC: dc1)
Server: true
==> Nomad agent started! Log data will stream in below:
2015/10/08 23:02:28 [INFO] serf: EventMemberJoin: dev.docker.jp.global 127.0.0.1
2015/10/08 23:02:28 [INFO] nomad: starting 1 scheduling worker(s) for [service batch _core]
2015/10/08 23:02:28 [INFO] raft: Node at 127.0.0.1:4647 [Follower] entering Follower state
これでテスト用の環境が、すぐ
立ち上がります。

28. zem@dev:~$ nomad node-status
ID DC Name Class Drain Status
2b4b3259-f143-2abf-46d4-62905268263e dc1 dev.docker.jp <none> false ready
zem@dev:~$ nomad server-members
Name Addr Port Status Proto Build DC Region
dev.docker.jp.global 127.0.0.1 4648 alive 2 0.1.2 dc1 global
状態確認のIDですが、エージェ
ントごとにUUIDが割り当てられ
ます。Serf・Consul風のメンバ
管理コマンドです。

29. # There can only be a single job definition per file.
# Create a job with ID and Name 'example'
job "example" {
# Run the job in the global region, which is the default.
# region = "global"
# Specify the datacenters within the region this job can run in.
datacenters = ["dc1"]
# Service type jobs optimize for long-lived services. This is
# the default but we can change to batch for short-lived tasks.
# type = "service"
# Priority controls our access to resources and scheduling priority.
# This can be 1 to 100, inclusively, and defaults to 50.
# priority = 50
# Restrict our job to only linux. We can specify multiple
# constraints as needed.
constraint {
attribute = "$attr.kernel.name"
value = "linux"
}
# Configure the job to do rolling updates
update {
# Stagger updates every 10 seconds
stagger = "10s"
# Update a single task at a time
max_parallel = 1
}
# Create a 'cache' group. Each task in the group will be
# scheduled onto the same machine.
group "cache" {
# Control the number of instances of this groups.
# Defaults to 1
# count = 1
# Define a task to run
task "redis" {
# Use Docker to run the task.
driver = "docker"
# Configure Docker driver with the image
config {
image = "redis:latest"
}
# We must specify the resources required for
# this task to ensure it runs on a machine with
# enough capacity.
resources {
cpu = 500 # 500 Mhz
memory = 256 # 256MB
network {
mbits = 10
dynamic_ports = ["6379"]
}
}
}
}
}
zem@dev:~$ nomad init
Example job file written to example.nomad 設定ファイルのサンプルです。
ここでリソースやジョブを定義

30. zem@dev:~$ nomad run example.nomad
==> Monitoring evaluation "88fc77ac-d878-b27f-925c-c0e131658ac6"
Evaluation triggered by job "example"
Allocation "1170083d-dd2c-92ec-1e29-44f25eb3de75" created: node "2b4b3259-f143-2abf-46d4-629
05268263e", group "cache"
Evaluation status changed: "pending" -> "complete"
==> Evaluation "88fc77ac-d878-b27f-925c-c0e131658ac6" finished with status "complete"
2015/10/08 23:59:57 [DEBUG] driver.docker: docker pull redis:latest succeeded
2015/10/08 23:59:57 [DEBUG] driver.docker: using image 2f2578ff984f013c9a5d6cbb6fe061ed3f73…
2015/10/08 23:59:57 [INFO] driver.docker: identified image redis:latest as 2f2578ff984f013c…
2015/10/08 23:59:57 [DEBUG] driver.docker: using 268435456 bytes memory for redis:latest
2015/10/08 23:59:57 [DEBUG] driver.docker: using 500 cpu shares for redis:latest
2015/10/08 23:59:57 [WARN] driver.docker: no mode specified for networking, defaulting to bridge
2015/10/08 23:59:57 [DEBUG] driver.docker: using bridge as network mode
2015/10/08 23:59:57 [DEBUG] driver.docker: allocated port 128.199.223.107:44054 -> 6379 (mapped)
2015/10/08 23:59:57 [INFO] driver.docker: created container ca2c4efd37e4c5dee82da48fce248e…
2015/10/08 23:59:57 [INFO] driver.docker: started container ca2c4efd37e4c5dee82da48fce248e…
zem@dev:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS
PORTS NAMES
ca2c4efd37e4 redis:latest "/entrypoint.sh redis" 49 seconds ago Up 49
seconds 128.199.223.107:44054->6379/tcp desperate_mayer
コマンドを実行すると、勝手に
コンテナを起動してくれます。

31. zem@dev:~$ nomad status example
ID = example
Name = example
Type = service
Priority = 50
Datacenters = dc1
Status = <none>
==> Evaluations
ID Priority TriggeredBy Status
88fc77ac-d878-b27f-925c-c0e131658ac6 50 job-register complete
==> Allocations
ID EvalID NodeID
TaskGroup Desired Status
1170083d-dd2c-92ec-1e29-44f25eb3de75 88fc77ac-d878-b27f-925c-c0e131658ac6 2b4b3259-f143-2abf-
46
d4-62905268263e cache run running
こちらは状態確認コマンド。

32. zem@dev:~$ nomad run example.nomad
==> Monitoring evaluation "8a72b095-79fc-f521-acea-463fd049d36c"
Evaluation triggered by job "example"
Allocation "5f4dfa20-ed30-18fb-9a18-300a374f2eac" created: node "2b4b3259-f143-2abf-46d4-
62905268263e", group "cache"
Allocation "fa612324-877a-c589-4c03-87b393a7e721" created: node "2b4b3259-f143-2abf-46d4-
62905268263e", group "cache"
Allocation "1170083d-dd2c-92ec-1e29-44f25eb3de75" modified: node "2b4b3259-f143-2abf-46d4-
62905268263e", group "cache"
Evaluation status changed: "pending" -> "complete"
==> Evaluation "8a72b095-79fc-f521-acea-463fd049d36c" finished with status "complete"
zem@dev:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS
PORTS NAMES
376c15af6b8f redis:latest "/entrypoint.sh redis" 1 seconds ago Up Less
than a second 128.199.223.107:58268->6379/tcp prickly_visvesvaraya
2a78baaa8ec7 redis:latest "/entrypoint.sh redis" 1 seconds ago Up Less
than a second 128.199.223.107:29865->6379/tcp mad_fermi
ca2c4efd37e4 redis:latest "/entrypoint.sh redis" 5 minutes ago Up 5
minutes 128.199.223.107:44054->6379/tcp desperate_mayer
スケールするのも簡単。
コンテナが３つになりました。

33. 33
‣ リソース管理とスケジュールを簡単に行える
'nomad' コマンドを使うだけで、複雑になりがちな分散環境における任意のリソースを管理
‣ 環境に依存しない
特定のクラウド・仮想化システムによる制限を受けないし、併用して使い分けられる
‣ クライアント・サーバ型のアーキテクチャ
基本になっている技術は、Serf の Gossip プロトコル、Consul の Raft プロトコルと同じ
‣ Dockerコンテナを始めとして様々なジョブを処理
対応環境はDocker、仮想化、通常のバイナリに対応している
Nomad まとめ

34. One more thing...
コンテナのスケジュールが
Nomadで出来るのは分かった。
でも、開発環境と本番環境の
面倒さはどうしたらいいのよ？
それが…

35. 背景画像CREDIT:videodoctor / PIXTA(ピクスタ)
https://pixta.jp/@prof306848
Otto
■■■
Ottoという位置付けです。
Ottoは何をするものでしょう？

36. Otto
Vagrant後継ソフト
The Successor to Vagrant
Vagrantから学んだ多くの知見
それを反映したのが Otto
HashiCorpがVagrantから学んだ
知見を入れ込んだソフトという
位置づけです。

37. Otto
開発環境は類似
Development environments are similar
開発者はデプロイしたい
Developers want to deploy
マイクロサービスは未来
Microservices are the future
Atlasとは逆に、開発者向けに
アプローチしているツールです。

38. vagrant up packerbuild terraform apply
これまでは各ツールを別々に
ダウンロードして使い分ける
必用がありました。

39. otto dev otto build otto deploy
Ottoは「otto」コマンドで各
ツールを抽象化して扱います。

40. 40
Ottoの主な機能
‣ 開発環境の自動構築 ( otto dev, otto build )
アプリケーションの種類に応じて、依存関係のあるパッケージやサービスを自動的に構築する
‣ デプロイ ( otto deploy )
クラウド環境だけでなく、リモートでの環境構築やアプリケーションのデプロイを単一コマンドで実行可能
‣ HashiCorpのツールと連携
‣ 環境をコードで管理
Appfile ( Vagrantfile に相当するようなもの )
開発向け環境の良いところ取り

41. 41
application {
name = "my-app"
type = "ruby"
dependency {
source = "github.com/hashicorp/otto/examples/postgresql"
}
}
customization "ruby" {
ruby_version = "2.1"
}
Appfile これがVagrantfileにかわり
アプリケーションの状態を
管理するものになります。

42. 42
‣ otto dev ( vagrant up 相当 )
otto dev ssh
otto dev address
otto dev destroy
‣ otto infra ( terraform apply 相当 )
‣ otto build ( packer build 相当 )
‣ otto deploy
コマンド実行例 「vagrant up」のかわりに
「otto dev ～」を実行します。

43. 43
Ottoを使うには
‣ 対応OS
Windows, Mac OS X, Linux
‣ ダウンロード
https://ottoproject.io/downloads.html
‣ チュートリアル
https://ottoproject.io/intro/getting-started/install.html
$ cd /tmp
$ wget -O otto.zip https://dl.bintray.com/mitchellh/otto/otto_0.1.1_linux_amd64.zip
$ unzip otto.zip
$ sudo mv otto /usr/bin/
$ sudo chmod 755 /usr/bin/otto
$ otto -v
Otto v0.1.1
HashiCorpの他のツール同様に
コマンド１つを実行するだけ。

44. $ git clone https://github.com/hashicorp/otto-getting-started.git
$ cd otto-getting-started
$ otto compile
==> Loading Appfile...
==> No Appfile found! Detecting project information...
No Appfile was found. If there is no Appfile, Otto will do its best
to detect the type of application this is and set reasonable defaults.
This is a good way to get started with Otto, but over time we recommend
writing a real Appfile since this will allow more complex customizations,
the ability to reference dependencies, versioning, and more.
（省略）
==> Compiling main application...
==> Compilation success!
This means that Otto is now ready to start a development environment,
deploy this application, build the supporting infastructure, and
more. See the help for more information.
Supporting files to enable Otto to manage your application from
development to deployment have been placed in the output directory.
These files can be manually inspected to determine what Otto will do.
チュートリアルが機能を試す
のに非常に分かりやすいです。

45. $ otto status
==> App Info
Application: otto-getting-started (ruby)
Project: otto-getting-started
Infrastructure: aws (simple)
==> Component Status
Dev environment: NOT CREATED
Infra: READY
Build: NOT BUILT
Deploy: NOT DEPLOYED
こちらは状態確認するコマンド

46. $ otto infra
==> Detecting infrastructure credentials for: otto-getting-started (aws)
Cached and encrypted infrastructure credentials found.
Otto will now ask you for the password to decrypt these
credentials.
…
==> otto: Deleting temporary security group...
==> otto: Deleting temporary keypair...
Build 'otto' finished.
==> Builds finished. The artifacts of successful builds are:
--> otto: AMIs were created:
us-east-1: ami-27185642
==> Storing build data in directory...
==> Build success!
The build was completed successfully and stored within
the directory service, meaning other members of your team
don't need to rebuild this same version and can deploy it
immediately.
「aws」環境上に、セキュリ
ティ・グループなどインフラに
関連する情報を読み込みます。

47. $ otto build
…
==> otto: Deleting temporary security group...
==> otto: Deleting temporary keypair...
Build 'otto' finished.
==> Builds finished. The artifacts of successful builds are:
--> otto: AMIs were created:
us-east-1: ami-27185642
==> Storing build data in directory...
==> Build success!
The build was completed successfully and stored within
the directory service, meaning other members of your team
don't need to rebuild this same version and can deploy it
immediately.
こちらはデプロイに向けて
マシン・イメージの自動構築。
後ろでpackerを使っています。

48. $ otto deploy
そして、実際にAWS上にインス
タンスをたて、コードもデプロ
イし、アプリが動きました。

49. このように、管理コンソール上
にも自動で反映されています。

50. 50
Ottoの現状とこれから
‣ デプロイ先のインフラは拡大予定
現状（バージョン 0.1 ）では Amazon Web Services の環境のみ
‣ Vaultと連携予定
シークレットの自動的な保管や管理
‣ Atlasとも機能統合予定
現在の開発者向けから、運用担当向けの監視やアプリケーションのメンテナンスもできるように
‣ 構成管理ツールとの棲み分けは？
個人的な疑問

51. 51
Vagrantの今後
‣ 今後も開発継続
機能改善もバージョンアップもあり
‣ Ottoと並列に開発が進む
Vagrantはマシンレベルの開発環境、Ottoはアプリレベルでの開発環境という位置付け
‣ Ottoの開発環境はVagrantと連携
https://ottoproject.io/intro/vagrant-successor.html
ottoは必用があれば内部的に
Vagrantを呼び出しており、
ローカルの開発にVagrantを使
うのであれば、これまでも、こ
れからも変わりません。

52. 52
Ottoまとめ
‣ Otto は Vagrant の後継ソフトウェアの位置付け
ただし、必ずしも Otto に移行を促すものではない
‣ 開発ツールでもあり、デプロイツールでもある
「otto」コマンドを使い、複数の環境を使い分ける事ができる
‣ Appflie で環境や依存関係を管理
‣ Dockerに対応している
Microservices 向けの複雑な環境も、Otto を使えば簡単に開発・デプロイ・運用可能になる
デプロイのために、Nomadとも
連携しています。

53. 背景画像CREDIT:videodoctor / PIXTA(ピクスタ)
https://pixta.jp/@prof306848
Wrap Up
***

54. 背景画像CREDIT:videodoctor / PIXTA(ピクスタ)
https://pixta.jp/@prof306848
HashiCorp
の考える Microservices と
Nomad,Otto
今日の内容
‣ HashiCorpとは？
‣ NomadはDockerスケジューラ
‣ OttoはVagrantの後継ソフト
どれも使うのはとても簡単です。
興味があれば使ってみてはいか
がでしょうか。

55. 背景画像CREDIT:videodoctor / PIXTA(ピクスタ)
https://pixta.jp/@prof306848
HashiCorp
の考える Microservices と
Nomad,Otto
この中で、
気になる所はありますか？(Q&A)
Q「Ottoが対応しているのはAWSだけ？」
→現時点ではAWSですが、今後は様々な環境への対応が
発表されています。
Q「弊社環境をOttoに対応したい」
→AWSやDigitalOceanの対応が早いのは、HashiCorp
自身が使っているからです。GitHubでIssueを挙げるの
が一番の近道だと思います。
Q「OttoがあればVagrantは不要？」
→いいえ、Ottoはローカル開発環境にVagrantを内部的に
呼び出しています。

56. 56
‣ Nomad
https://nomadproject.io/
‣ Otto
https://ottoproject.io/
‣ blog記事
Nomad
• https://hashicorp.com/blog/nomad.html
• http://pocketstudio.jp/log3/2015/09/29/nomad-ja/ (日本語参考）
Otto
• https://hashicorp.com/blog/otto.html
• http://pocketstudio.jp/log3/2015/09/30/otto-ja/ (日本語参考)
参考情報