HackerTackle @ 2015/09/26

1. GMO Pepabo, Inc.
UCHIO KONDO2015/09/26 HackerTackle
インフラ自動化と
Hashicorp tools

2. me

4. 近藤うちお
> GMOペパボ
> 技術基盤チーム
> 福岡支社勤務

5. 東三河出身
> 大学入学とともに東京へ
> 2013年から福岡
> 名古屋じゃないに∼
この辺

6. 興味
> Ruby / Golangを少々
> Puppet / Docker / Hashicorp tools
> OpenStack

7. 7 years old Rubyist
> Rails 2.1.0 ごろからのルビースト(2008 )
> Rubyをこじらせて著作あり

9. 松江遠征（予定）
スタバの数で圧倒してきます！

10. いままで
> 新卒入社の最初の2年ぐらい社内SE
> その後はずっと 開発系な人
> （自社サービスの会社にしかいたことがない）

11. ペパボで
> 技術基盤チームに所属
> Puppetなどを書いたり
> サーバ追加や監視をしたりしていた
> でも一度も「インフラエンジニアになるぞ∼」
と思ったことはない…

12. インフラってなんだ？

13. Webエンジニア念能力…
> フロントエンド
> アプリケーション
> ミドルウェア/アーキテクト
> インフラ
> （開発手法、QA）
http://udzura.hatenablog.jp/entry/2013/03/04/114728

14. インフラ系技術の流れ
> 最近のウェブ界隈での「インフラ」という用語の使
われ方には、色々異論もあるようだけど、ここでは
ごく最近使われるようになってきた、OS からミド
ルウェアといったソフトウェアレイヤーを指す言葉
としてのインフラについて触れる。
（英語圏でも同様の意味で使われているようなので、
ある程度市民権を得たと言っても良さそうだし。）
http://mizzy.org/blog/2013/10/29/1/

15. Webエンジニア念能力…
> フロントエンド
> アプリケーション
> ミドルウェア/アーキテクト
> インフラ
> （開発手法、QA）
http://udzura.hatenablog.jp/entry/2013/03/04/114728
このへんで！

16. 今日はあえて
DevOpsって言わない

17. しかも今日はずっと
OSより上、ミドルウェアの話ですね
……

18. Hashicorp tools

19. Hashicorpとは？
> Vagrant、Packer、Serf、Consulの作者、
ミッシェル=ハシモト氏により立ち上げられた
スタートアップ
> 様々なインフラ運用・開発を revolutionizing
するための企業
> 具体的には様々なツール（OSS）の開発とその
サポートをしている

20. Hashicorpとは？
> The Tao of HashiCorp
> https://hashicorp.com/blog/tao-of-hashicorp.html

21. Workflows, not
Technologies

22. Simple, Modular,
Composable

23. Codification,
Codification, Codification

24. Codification =
Code + ify + ation

25. 参考
> Hashicorpのツール群とオーケストレーション
> http://www.slideshare.net/zembutsu/hashicorp-
orchestration-tools-introduction

26. 自分とHashicorp tools
> 自分の好きなこと
> DSLを設計したり書いたりする
> プラグインを作ったり公開する
> ピタゴラスイッチ

27. 自分とHashicorp tools
> 自分の好きなこと
> DSLを設計したり書いたりする
> プラグインを作ったり公開する
> ピタゴラスイッチ
Hashitoolっぽい
Hashitoolっぽい
めちゃくちゃ
Hashitoolっぽい！！

28. 最近のHashitool事例
> 先日のYAPCなどからいくつか

29. 最近のHashitool事例
> Consulと自作OSSを活用した100台規模の
Webサービス運用
> 「Consulってこんなに一般化してたのか」的な感想をち
らほら見かけるのですが、これはおそらく世間的には全然
そんなことはないんじゃないですかね…
http://sfujiwara.hatenablog.com/entry/2015/08/23/173803

30. 最近のHashitool事例
> 我々はどのように冗長化を失敗したのか
http://blog.kenjiskywalker.org/blog/2015/08/22/yapcasia2015/
https://twitter.com/kenjiskywalker/status/635659731550408704

31. 最近のHashitool事例
> 3分でサービスのOSを入れ替える技術
> 愚直に経験があるもの、評価済みのものをひたすら組み合
わせることで、システムアーキテクチャも魔法のようなこ
とを実現できる
http://yapcasia.org/2015/talk/show/4f85e87a-f9ec-11e4-8262-8ab37d574c3a

32. 最近のHashitool事例
> #hashi_wantedly
> Working With Terraform
> Terraform + GitHub + CircleCI + Atlas
> インフラの変更をGitHubのMergeボタンに集約出来る
http://blog.glidenote.com/blog/2015/02/18/terraform-github-circleci-atlas-aws/
https://speakerdeck.com/glidenote/working-with-terraform

33. からの

34. toolsのご紹介
（独断と偏見ver.）

35. DSL度 ⭐⭐⭐⭐⭐
プラガブル度 ⭐⭐⭐
ピタゴラスイッチ度 ⭐⭐

36. Vagrant

37. Vagrant
> おなじみ
> DSLで開発用VM
立ち上げるやつ
> VirualBoxベースのことが多いけど、
VMWare、kvm、DigitalOcianなどいろいろ
バックエンドがあったりする
DSL度 ⭐⭐⭐⭐⭐
プラガブル度 ⭐⭐⭐
ピタゴラスイッチ度 ⭐⭐

38. Packer

39. Packer
> あらゆる種類の
「イメージを作る」
> もともと、VB用の
イメージを作るVeeWeeの代用としての紹介が多かっ
たが、実際には、AMI、qemu imageその他いろ
いろと作れる
> イメージを作る手順も共有できたりする
DSL度 ⭐⭐⭐
プラガブル度 ⭐⭐⭐⭐⭐
ピタゴラスイッチ度 ⭐⭐

40. Terraform

41. Terraform
> 複数のサーバ構成を
ある状態に収束させる
ツールとDSL
> Puppet/Chefなど構成管理ツールが、１台のサー
バをある状態に収束させるツールであることの連想
> みんな主にAWSで使ってるので、CloudFormation
のあのJSONよりはいいんだなと思う
DSL度 ⭐⭐⭐⭐
プラガブル度 ⭐⭐⭐⭐
ピタゴラスイッチ度 ⭐⭐⭐⭐

42. Serf

43. Serf
> クラスタ管理ツール
> サーバがクラスタに
追加、抜けるなどの
タイミングで、任意の処理を実行したりする
> マスターレス
> Orchestration（とgossip protocol）の単語を有
名にした最初のツール
DSL度 ⭐
プラガブル度 ⭐⭐⭐
ピタゴラスイッチ度 ⭐⭐⭐⭐⭐

44. Consul

45. Consul
> クラスタ管理ツール(2)
> Serfとかぶってる
どころか内部でSerf利用
> Serfとは、各サーバでエージェントとして動いている
点、ヘルスチェックによるサービスディスカバリを基
本にしている点が大きな違い。また、簡易KVSも用意
> see: Raft Algorithm
DSL度 ⭐⭐
プラガブル度 ⭐⭐⭐
ピタゴラスイッチ度 ⭐⭐⭐⭐⭐

46. Vault

47. Vault
> 期待の新人
> センシティブな情報を
安全に管理、共有、
そして監査する
> githubなどのアカウントチームを、Vault上の権限
とひも付けて、そしてMySQLやらConsulやらと
いい感じに連携
DSL度 ⭐⭐⭐
プラガブル度 ⭐⭐⭐⭐⭐
ピタゴラスイッチ度 ⭐⭐⭐

48. Atlas

49. Atlas
> ここまで紹介した
各種ツールを横軸で
まとめるウェブサービス
> ごめんな、これだけOSSとちゃうんや。SaaSなんやで。
> いまのところConsulの中央サーバ、Vagrant BOXの置
き場所などの用途。SaaSとしての安定性も含め、利用シー
ンは未知数なところが多い。UIもまだ渋い……
DSL度 ？
プラガブル度 ？
ピタゴラスイッチ度 ？

50. To Be Continued?

51. Artifact Pipeline

52. https://www.hashicorp.com/blog/atlas-artifact-pipeline.html

53. 事例紹介

54. Packerの
プラグインを書いた話

55. Packer

56. Packer

57. http://www.slideshare.net/hsbt/advanced-technic-for-os-upgrading-in-3-minutes

58. Do scale-out

59. #3分で スケールアウト

60. http://udzura.hatenablog.jp/entry/2015/03/20/192619

61. やりました

62. Packer で、
やりました

63. じゃあ、それを
OpenStackでも

65. Nyahについて
> ネットワークに癖がある
> DHCPエージェントは使わない
> metadataエージェントも使わない
> なのでこうする
> 事前にport（仮想NIC）を作る
> IP、MAC addressなどをuserdataを使って流し込んで
ネットにつなぐ

66. 既存のopenstack builder
> ネットワークに癖がある
> DHCPエージェントは使わない
> metadataエージェントも使わない
> なのでこうする
> 事前にport（仮想NIC）を作る
> IP、MAC addressなどをuserdataを使って流し込んで
ネットにつなぐ
こういうカスタマイズには
対応していない！

67. じゃあどうしよう

69. packer-builder-nyah

70. Packerプラグインの
作り方

71. Pluginの種類
> Builder
> プラットフォームごとのアダプター
（AWS, Openstack, QEMUなど）
> Provisioner
> 立ち上げたソースサーバに実際のプロビジョニングをしていく
（Shell Script, Chef, Puppetなど）
> Post Processor
> 後処理（docker builderならdockerhubにpushするとか）

72. 今回必要なのは
Builder Plugin

73. 方針
> 既存のOpenStackプラグインの実装を参考に
する、どんどんパチる
> Nyah固有の必要な処理だけ自分で書く
> 先にPort用意して特別なuserdataを流すとこ
だけ書けばいい、はず。そのはずなんだ

74. How to write

75. 最低限のルール
> 以下を満たすインターフェース
> これが処理のエントリポイントになる
type Builder interface {
Prepare(...interface{}) error
Run(ui Ui, hook Hook, cache Cache) (Artifact, error)
Cancel()
}

76. Builder typeを
> これをコマンドのエントリポイントにして
> 普通にビルドすれば良い
> 利用するには、
packer-builder-nyah
という名前のバイナリにし
PATHを通す

77. それぞれのフェ∼ズ
Prepare(...interface{}) error
> 準備。主に、設定を読み込む。
> このフェーズでサーバはいじるべきではないとのこと
Run(ui Ui, hook Hook, cache Cache) (Artifact, error)
> 実際のサーバ立ち上げ処理。詳細後述
Cancel()
> キャンセル時/失敗時/正常終了時全部で呼ばれる後処
理。名前……

78. Runの中身
> Run(ui Ui, hook Hook,
cache Cache) (Artifact, error)
> packer.Artifactも、またインタフェース
> https://github.com/mitchellh/packer/
blob/master/packer/artifact.go という
便利ドキュメントを読んで頑張る（サーバIDとか
そういう情報を返せば良いとのこと）

79. まずは
> ビルドが
> できる
> とこまで…うう

80. いよいよ、Run()の
中身を書く

81. Run() 既存実装の詳細
> キーペア登録
> サーバ立ち上げ
> Floating IPの割り当て
> SSH接続、操作
> 終了処理
> イメージ作成

82. この辺をいじれば良さそう
> キーペア登録
> サーバ立ち上げ
> Floating IPの割り当て
> SSH接続、操作
> 終了処理
> イメージ作成
portの作成を事前にする
portの情報から
適切なuserdataを
作った上で立ち上げ
Floating IP は使わない
(portにIP情報がある)

83. Goを書くぞ

84. mitchellh/multistep
> Step構造体を定義して
それを並べるだけ
> Stepの再利用できる
> やることが、Stepという
単位で分割される

85. mitchellh/mapstructure
> 「賢いJSON」
> JSONのパーサライブラリ
> 現実的なユースケースに
色々対応していて
コードがスッキリする
https://github.com/mitchellh/mapstructure

86. gophercloud
> Goライブラリのデファクトスタンダード
> Rackspace社で保守
> APIは結構……あれだけど活発な開発
> 以前別のクライアントで使って、経験があった
https://github.com/rackspace/gophercloud

87. ロゴが良い（...）

88. さて、どんな感じか中身を見てみよう…

92. fork………?????

93. 諸事情でforkされていた。。。だと

94. michellさん「Wow!」

95. そして足りない機能がある…………
> サーバ立ち上げ時に、「ネットワークID」じゃ
なくて「ポートID」を指定する必要がある
> forkされた段階のgophercloudには未実装
$ nova help boot
--nic <net-id=net-uuid,v4-fixed-ip=ip-addr,v6-fixed-ip=ip-addr,port-id=port-uuid>
Create a NIC on the server. Specify option
multiple times to create multiple NICs. net-
id: attach NIC to network with this UUID
(either port-id or net-id must be provided),
v4-fixed-ip: IPv4 fixed address for NIC
(optional), v6-fixed-ip: IPv6 fixed address
for NIC (optional), port-id: attach NIC to
port with this UUID (either port-id or net-id

96. forkをfork

98. $ go test ./...
# git.***.***/tech/packer-builder-nyah
../../../../.go/src/git.***.***/tech/packer-builder-nyah/
builder.go:75: cannot use auth (type "github.com/mitchellh/
gophercloud-fork-40444fb".AccessProvider) as type "github.com/
udzura/gophercloud-fork-9419da4".AccessProvider in argument to
"github.com/udzura/gophercloud-fork-9419da4".Server:
"github.com/mitchellh/gophercloud-
fork-40444fb".AccessProvider does not implement "github.com/
udzura/gophercloud-fork-9419da4".AccessProvider (wrong type for
FirstEndpointUrlByCriteria method)
have FirstEndpointUrlByCriteria("github.com/
mitchellh/gophercloud-fork-40444fb".ApiCriteria) string
want FirstEndpointUrlByCriteria("github.com/
udzura/gophercloud-fork-9419da4".ApiCriteria) string

99. パッケージ名が合わない！
> ミスマッチの対応のためのバッドノウハウ
> ミスマッチするところは、そのimport文だけを
変えた形で
本家から
コピーして
配置しておく

100. いろいろなYakを狩りまくり
最終的には……動いた！

101. そしてNヶ月が過ぎた

103. またまた∼

106. 突然の
＿人人人人人人人人人人＿
＞ upstream変更 ＜
￣Y^Y^Y^Y^Y^Y^Y￣

107. どうしたか？
> godepの導入
> packerの、動いている段階のビルドを探して
………………………………………………………
………………………………………………………
………………………………………………………
> fork

109. 得られた教訓
> 容赦なくupstreamが変わる、それがGoの世界
> とくに、packerは別にもとから外部向けのライブラリではなく、たま
たまいい具合にパッケージが分かれていたのを使っただけなので、仕方
なさがある
> 運用で使うようになったらgodeps
> しかしGoは型があるので便利
> いざとなったらとにかくコンパイルエラーを直し、なんとかする
> CIしようぜ！！！
> すぐ気づける

110. おまけ
> Provisioner Pluginも作ってみた
> https://github.com/udzura/packer-provisioner-serverspec
> 同じように、インタフェースを合わせれば良い。便利
> 詳細はコードで！

111. Consulを
バーンと
入れた話

112. http://www.slideshare.net/hsbt/advanced-technic-for-os-upgrading-in-3-minutes

113. Do scale-out

114. #3分で スケールアウト

115. 大事なことなので２回ｒｙ

116. サーバをカジュアルに増やす
> from 12 facter app
> V. Build, release, run
> Strictly separate build and run stages
> IX. Disposability
> Maximize robustness with fast startup and graceful shutdown

117. 監視についても
> Runしたら、自動で監視対象になってほしい
> Terminateしたら、勝手に外れてほしい
> イメージから立ち上げたはいいけど、アプリが
正常に動いていることを何かしら確認したい

118. Consul

119. Consul の機能
> クラスタリング、ヘルスチェック
> Web UI を公式に用意している
> consul-alerts なんかで通知もできる

121. 検証する価値はありそう

122. インストールして
立ち上げてみた

124. 何これ怖い

125. vm.overcommit_memory=0

126. おおう……

127. strace
32 GB
+ 8 GB

128. メモリをガツッと確保する
> Consul makes use of LMDB internally for various
data storage purposes. LMDB relies on using
memory-mapping, a technique in which a sparse
file is represented as a contiguous range of
memory.
> vm.overcommit_memory=2 だったので、落ちた
> ※ 0.5.0では vm.overcommit_memory=2 でも落ちな
くなっていた
https://www.consul.io/docs/faq.html

129. 立ち上がったので
クラスタリングしてみようかな

131. めちゃくちゃ不安定……
> いろいろいじった結果、
UDPのポート8301 をお互いに許可していな
かった。。。。。。
> 開けたら安定した
> 使うポート/プロトコルは↓
https://www.consul.io/docs/agent/options.html

132. よっしゃ導入OK！

133. それから数週間後

136. CPU 1個のインスタンスだと……
> consulは、 GOMAXPROCS=2 以上の設定
を強く推奨している
> GOMAXPROCS=1、またはCPU 1個だと
パフォーマンスで問題が起こる
> 1個のものは、CPU2個以上で、作り直した

137. “https://groups.google.com/forum/#!msg/consul-tool/qewFEqgAoF8/b9hxhmy1v6gJ
The reason we recommend setting GOMAXPROCS is to avoid potential
starvation of the scheduler. The Go runtime uses green threads (M:N). If
a single goroutine blocks the scheduler (via cgo for example) it can cause
degraded performance. Having another kernel thread available helps to
mitigate those issues.

138. Tips: VirtualBoxで試すとき
> IO/APIC を有効に
しないとダメです
> Vagrantなら以下の感じ

139. そんなこんなで
安定運用（？）

140. できなかったことが
できるようになる

141. 内部DNS

142. OpenStackの内部DNS
> 結構悩んでいた
> DHCP agentは使えないし、自分でDDNS？
うえ∼
> APIを叩いてhostsを定期更新、とかも手。
だが……

143. DNS INTERFACE

144. 方針
> ドメインを minne.lan とかにする
> dnsmasq を全台に導入
> *.node.minne.lan は dnsmasq から
localhost:8600にフォワード、
各サーバでは127.0.0.1をリゾルバに

145. あっさり導入完了

146. Consulが撃沈したり……
> DNS APIは、リーダーがいないと叩けない
> 一時的にリーダーがいなくなるタイミングとか
はどうしてもあるので
> dnsmasqの設定にしてしまってキャッシュし
ておく

147. これを5分ごとに実行
CACHE_TMP=/tmp/consul-cns-cache.$$
TARGET=/etc/dnsmasq.d/999-nodes-cache.conf
set -e
set -o pipefail
curl -s localhost:8500/v1/catalog/nodes
| jq -r "map("address=/(.Node).node.minne.lan/(.Address)")[]"
> $CACHE_TMP
cp -af $CACHE_TMP $TARGET
systemctl restart dnsmasq
set -e してるので、
consul自体が使えないときはそもそも
キャッシュが上書きされないようにしている

148. 便利
> クラスタにジョインしたら、すぐに内部の名前
でSSHできるようになった！
> ConsulのAPIはめっちゃ軽いので良い

149. 副産物
> 踏み台+内部DNS+peco+Consul APIにより
便利ログイン君ができて便利になった

151. 動的LB

152. ELB的なやつにほしい要素
> 動的なメンバー追加、削除
> 自動的なヘルスチェック
> 高い可用性

153. consul-template

154. consul-templateで
> 動的なメンバー追加、削除
> 自動的なヘルスチェック
> この二つは実現できるぞ！

155. consul-templateの仕組み
LB
www
www
www
フロントLBもNginxとする。
全台、consulのクラスタに
ジョインする

156. consul-templateの仕組み
LB
www
www
www
たとえばバックエンドのプロセス
（NginxならNginx）
に特定のタグを加えて
Consulのチェックを追加する

157. JSONの例
sandbox-front というタグを特別につけている

158. consul-templateの仕組み
LB
www
www
www
LB側では、「sandbox-front」
というタグに紐付いた
サービスの状態を監視している

159. テンプレートを書く
upstream rails_apps {
{{range service "sandbox-front.nginx@nyah" "passing"}}
server {{.Address}}:80;{{end}}
}
server {
listen 80;
# server_name minne.com api.minne.com;
server_name _
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
location / {
proxy_pass http://rails_apps;
}
}
sandbox-frontというタグのついたnginxのチェックのうち
正常（passing）のものを監視する

160. consul-templateの仕組み
LB
www
www
www
たとえば、ここで１台の
Nginxがダウンしたとする
💥

161. consul-templateの仕組み
LB
www
www
www
consul-template は、
nginxのfailedを検知する
💥

162. consul-templateの仕組み
LB
www
www
www
変更を検知して、
passingなメンバーのみで
ループを回し、
テンプレートを更新する
💥

163. consul-templateの良さ
> 仕組み自体は理解できれば割とシンプル
> チェック項目、フックなどのカスタマイズがわかりやすい
> フロントのNginx自体には、
何の手も加えていない
> そのため、本来のNginxのパフォーマンスが出るし、
チューニング等も特別なことはない

164. 制限事項
> 最後に残った、LB自体の可用性は、
普通にLVSなりkeepalivedなりに
頼ることになります……。
> ここは地道に頑張っている

165. インフラ運用で
新規ツールを導入する意義

166. ここから
ビッグ主語

167. 運用と開発

168. きょうびのWeb開発
> バンバンバージョンアップされる
> Railsが有名だが、PHPも激しいし、フロントエンド界隈、
nodejs、Go、Docker、iOS/Android開発……
> どんどん変わっていく
> 動き続けないと、古くなる
> 古くなると動きが遅くなる。どこかで、新しいこ
とができなくなる

169. > 「運用とはユーザの価値を減らさないよう維持
することだ」
> by haras⚪u5さん
> 重い言葉だと思う。ユーザが必ずしも変化を求
めているか？
一方、運用とは？

170. なお、インフラエンジニアは死んだらしいぞ

171. どうすればいいの？
> Webに関わるソフトウェアの大きな潮流は、動
き続ける、変わり続けることに舵を切っている
> 運用エンジニア・インフラエンジニアもこの潮
流を全く無視することはできないのではないだ
ろうか？

172. リスクの例: 脆弱性
> 「変わらない」に舵を切った結果、
CentOS 4 のサーバが残っていたらどうする？

173. 変化を恐れない

174. 動き続けるインフラ運用

175. 変化を適切に恐れる

176. よく知られた事実
> 新しくソフトウェアを書くと、

177. よく知られた事実
> 新しくソフトウェアを書くと、
> バグが起こることがある！！！

178. cf. バスタブ曲線
https://ja.wikipedia.org/wiki/%E6%95%85%E9%9A%9C%E7%8E%87%E6%9B%B2%E7%B7%9A

179. 一切ソフトウェアを書かなければ
バグも起こらない

180. 動くことにもリスクがある
> なので、我々は、動くことのリスクを最小限に
しないとならない

181. リスクを減らすには？

182. ここでやっと

183. Hashicorp

184. 動き続けるインフラ運用に
なぜHashicorpが効くか

185. より運用者に近いレイヤ

186. レイヤ分け
> ミドルウェアの3分類
> 日常の作業のツール
> 運用のためのデーモン
> ユーザに直接関わるデーモン
> 上の２つについては、新しいものを試しやすく、
切り戻しも比較的容易

187. レイヤ分け
> ミドルウェアの3分類
> 日常の作業のツール
> 運用のためのデーモン
> ユーザに直接関わるデーモン
> 上の２つについては、新しいものを試しやすく、
切り戻しも比較的容易
Vagrant, Packer, Terraform
Consul, Serf, Vault
(consul-template)

188. ツール自体のモダンさ

189. Hashicorp toolsの考え方
> ツール自体が大変近代的な開発
> githubでオープンに開発
> テストコード、CI完備
> Codification＝設定は必ずコードになる
> 設定変更を履歴管理ことを強く推奨する
> Go言語を選択し、コードも綺麗
> 導入時の安定性

190. インフラCIをはじめとした、テスト
> テストを、それも自動でする時代
> Serverspec、Infrataster
> Dockerなどによるインフラのコンポネント化
> 「責務を小さく」することでのテスト容易性
> ミドルウェアにも洗練されたテストコード
> Hashicorp toolsはテスト、開発のオープンさを重視している
> なにより、監視
> 最近はmackerelのようなサービスもある

191. cf. サーバ開発自体のモダン化
> 検証環境を作るコストが格段に下がっている
> AWSをはじめとしたクラウドのコモディティ化
> 構成管理ツール（Chef/Puppet/…）の普及
> Vagrantの出現
> コンテナ仮想化のブーム
> その気になればステージングを丸ごともうひとつ
> （そこでterraform？）

192. 「新しい」ことのアドバンテージ
> モダンなOSS開発手法
> モダンなツール、言語、環境
> →ソフトウェア自体の質が向上している
> このアドバンテージが「枯れているが、保守さ
れていないミドルウェア」に勝る時代になって
きているのではないか

193. TerraformのMakefile
> CIのテスト、受入テスト、レースコンディショ
ンの検知テストが全部コマンド一発（らしい）

194. 目的をはっきりさせる

195. 目的をはっきりさせる
> ゴールデンイメージを作る手順を完全にコード化
したい
> →Packerを使う
> 動的な監視を、まずは実現したい
（それ以上のことはおいおいでもいい）
> →Consulを使う
> 達成できない、とわかったらちゃんと引き返す

196. 既存のツールでいいときは冒険しない
> 例えば：
> サービスが落ちたのをconsulでチェック→
落ちたことをフックにconsul watchでサービス再起動→
やった！自動再起動できた！
> それ、monitでできるよ……

197. ちゃんと2つ以上の何かを減らせるか？
> 小さな、かつ新規性のあるツールを選ぶ
> 何か新しいものを1つ入れるときは既存の何か
を2つ以上減らせること
> http://myfinder.hatenablog.com/entry/2015/03/27/141416

198. 非連続性に挑戦する

199. 連続性、非連続性
> 普通の運用は連続的
> 枯れたツールを使う
> 変化を避けていく
> 手順を継承する
> 連続的に問題を解決することはめちゃくちゃ大
事である！！

200. どこかで、非連続性がほしい
> 今までに解決していない問題を解決しないとい
けない
> 非連続性への 投資
> Yak刈りの結果、どんな問題が解決するか？

201. 非連続の先を見るために
Yak刈りを厭わない

202. Hashicorp toolsは
> 新しい概念（＝非連続性）でOpsの問題を解決
するツール
> 実際に、イメージ作成の簡易化、機密情報の管理、サービ
スディスカバリ、動的設定変更など、これまで難しいとさ
れてきた課題に答えを出しつつある
> しかも、非常にオープンなツールで使いやすい

203. 総括

204. 動き続けるために

205. 動き続けるためのバランス
> むやみな破壊をしない
> むやみに守らない
> ちゃんとバリューを出せる見込みを持って攻め
込んで行こう

206. Hashicorpツールから学ぶべきことは、
ツール自体以上に、
たくさんあるかもしれない

207. [PR]

208. ペパボにはHashitoolsを使う仕事があります
> 福岡でもインフラ絶賛募集！
> ペパランチョンでお話を。
> https://pepabo.com/recruit/pepaluncheon/?fukuoka

209. 画像ソース
> タイトル写真
> https://commons.wikimedia.org/wiki/
File:Kings_Cross_Train_Station_London_England.jpg