Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

インフラ自動化とHashicorp tools

10.116 Aufrufe

Veröffentlicht am

HackerTackle @ 2015/09/26

Veröffentlicht in: Technologie
  • DOWNLOAD FULL BOOKS, INTO AVAILABLE FORMAT ......................................................................................................................... ......................................................................................................................... 1.DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier

インフラ自動化とHashicorp tools

  1. 1. GMO Pepabo, Inc. UCHIO KONDO2015/09/26 HackerTackle インフラ自動化と
 Hashicorp tools
  2. 2. me
  3. 3. 近藤うちお > GMOペパボ > 技術基盤チーム > 福岡支社勤務
  4. 4. 東三河出身 > 大学入学とともに東京へ > 2013年から福岡 > 名古屋じゃないに∼ この辺
  5. 5. 興味 > Ruby / Golangを少々 > Puppet / Docker / Hashicorp tools > OpenStack
  6. 6. 7 years old Rubyist > Rails 2.1.0 ごろからのルビースト(2008 ) > Rubyをこじらせて著作あり
  7. 7. 松江遠征(予定) スタバの数で圧倒してきます!
  8. 8. いままで > 新卒入社の最初の2年ぐらい社内SE > その後はずっと 開発系な人 > (自社サービスの会社にしかいたことがない)
  9. 9. ペパボで > 技術基盤チームに所属 > Puppetなどを書いたり > サーバ追加や監視をしたりしていた > でも一度も「インフラエンジニアになるぞ∼」 と思ったことはない…
  10. 10. インフラってなんだ?
  11. 11. Webエンジニア念能力… > フロントエンド > アプリケーション > ミドルウェア/アーキテクト > インフラ > (開発手法、QA) http://udzura.hatenablog.jp/entry/2013/03/04/114728
  12. 12. インフラ系技術の流れ > 最近のウェブ界隈での「インフラ」という用語の使 われ方には、色々異論もあるようだけど、ここでは ごく最近使われるようになってきた、OS からミド ルウェアといったソフトウェアレイヤーを指す言葉 としてのインフラについて触れる。
 (英語圏でも同様の意味で使われているようなので、 ある程度市民権を得たと言っても良さそうだし。) http://mizzy.org/blog/2013/10/29/1/
  13. 13. Webエンジニア念能力… > フロントエンド > アプリケーション > ミドルウェア/アーキテクト > インフラ > (開発手法、QA) http://udzura.hatenablog.jp/entry/2013/03/04/114728 このへんで!
  14. 14. 今日はあえて DevOpsって言わない
  15. 15. しかも今日はずっと OSより上、ミドルウェアの話ですね ……
  16. 16. Hashicorp tools
  17. 17. Hashicorpとは? > Vagrant、Packer、Serf、Consulの作者、
 ミッシェル=ハシモト氏により立ち上げられた
 スタートアップ > 様々なインフラ運用・開発を revolutionizing 
 するための企業 > 具体的には様々なツール(OSS)の開発とその
 サポートをしている
  18. 18. Hashicorpとは? > The Tao of HashiCorp > https://hashicorp.com/blog/tao-of-hashicorp.html
  19. 19. Workflows, not Technologies
  20. 20. Simple, Modular, Composable
  21. 21. Codification, Codification, Codification
  22. 22. Codification = Code + ify + ation
  23. 23. 参考 > Hashicorpのツール群とオーケストレーション > http://www.slideshare.net/zembutsu/hashicorp- orchestration-tools-introduction
  24. 24. 自分とHashicorp tools > 自分の好きなこと > DSLを設計したり書いたりする > プラグインを作ったり公開する > ピタゴラスイッチ
  25. 25. 自分とHashicorp tools > 自分の好きなこと > DSLを設計したり書いたりする > プラグインを作ったり公開する > ピタゴラスイッチ Hashitoolっぽい Hashitoolっぽい めちゃくちゃ Hashitoolっぽい!!
  26. 26. 最近のHashitool事例 > 先日のYAPCなどからいくつか
  27. 27. 最近のHashitool事例 > Consulと自作OSSを活用した100台規模の Webサービス運用 > 「Consulってこんなに一般化してたのか」的な感想をち らほら見かけるのですが、これはおそらく世間的には全然 そんなことはないんじゃないですかね… http://sfujiwara.hatenablog.com/entry/2015/08/23/173803
  28. 28. 最近のHashitool事例 > 我々はどのように冗長化を失敗したのか http://blog.kenjiskywalker.org/blog/2015/08/22/yapcasia2015/ https://twitter.com/kenjiskywalker/status/635659731550408704
  29. 29. 最近のHashitool事例 > 3分でサービスのOSを入れ替える技術 > 愚直に経験があるもの、評価済みのものをひたすら組み合 わせることで、システムアーキテクチャも魔法のようなこ とを実現できる http://yapcasia.org/2015/talk/show/4f85e87a-f9ec-11e4-8262-8ab37d574c3a
  30. 30. 最近の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
  31. 31. からの
  32. 32. toolsのご紹介 (独断と偏見ver.)
  33. 33. DSL度 ⭐⭐⭐⭐⭐ プラガブル度 ⭐⭐⭐ ピタゴラスイッチ度 ⭐⭐
  34. 34. Vagrant
  35. 35. Vagrant > おなじみ > DSLで開発用VM
 立ち上げるやつ > VirualBoxベースのことが多いけど、
 VMWare、kvm、DigitalOcianなどいろいろ バックエンドがあったりする DSL度 ⭐⭐⭐⭐⭐ プラガブル度 ⭐⭐⭐ ピタゴラスイッチ度 ⭐⭐
  36. 36. Packer
  37. 37. Packer > あらゆる種類の
 「イメージを作る」 > もともと、VB用の
 イメージを作るVeeWeeの代用としての紹介が多かっ たが、実際には、AMI、qemu imageその他いろ いろと作れる > イメージを作る手順も共有できたりする DSL度 ⭐⭐⭐ プラガブル度 ⭐⭐⭐⭐⭐ ピタゴラスイッチ度 ⭐⭐
  38. 38. Terraform
  39. 39. Terraform > 複数のサーバ構成を
 ある状態に収束させる
 ツールとDSL > Puppet/Chefなど構成管理ツールが、1台のサー バをある状態に収束させるツールであることの連想 > みんな主にAWSで使ってるので、CloudFormation のあのJSONよりはいいんだなと思う DSL度 ⭐⭐⭐⭐ プラガブル度 ⭐⭐⭐⭐ ピタゴラスイッチ度 ⭐⭐⭐⭐
  40. 40. Serf
  41. 41. Serf > クラスタ管理ツール > サーバがクラスタに
 追加、抜けるなどの
 タイミングで、任意の処理を実行したりする > マスターレス > Orchestration(とgossip protocol)の単語を有 名にした最初のツール DSL度 ⭐ プラガブル度 ⭐⭐⭐ ピタゴラスイッチ度 ⭐⭐⭐⭐⭐
  42. 42. Consul
  43. 43. Consul > クラスタ管理ツール(2) > Serfとかぶってる
 どころか内部でSerf利用 > Serfとは、各サーバでエージェントとして動いている 点、ヘルスチェックによるサービスディスカバリを基 本にしている点が大きな違い。また、簡易KVSも用意 > see: Raft Algorithm DSL度 ⭐⭐ プラガブル度 ⭐⭐⭐ ピタゴラスイッチ度 ⭐⭐⭐⭐⭐
  44. 44. Vault
  45. 45. Vault > 期待の新人 > センシティブな情報を
 安全に管理、共有、
 そして監査する > githubなどのアカウントチームを、Vault上の権限 とひも付けて、そしてMySQLやらConsulやらと
 いい感じに連携 DSL度 ⭐⭐⭐ プラガブル度 ⭐⭐⭐⭐⭐ ピタゴラスイッチ度 ⭐⭐⭐
  46. 46. Atlas
  47. 47. Atlas > ここまで紹介した
 各種ツールを横軸で
 まとめるウェブサービス > ごめんな、これだけOSSとちゃうんや。SaaSなんやで。 > いまのところConsulの中央サーバ、Vagrant BOXの置 き場所などの用途。SaaSとしての安定性も含め、利用シー ンは未知数なところが多い。UIもまだ渋い…… DSL度 ? プラガブル度 ? ピタゴラスイッチ度 ?
  48. 48. To Be Continued?
  49. 49. Artifact Pipeline
  50. 50. https://www.hashicorp.com/blog/atlas-artifact-pipeline.html
  51. 51. 事例紹介
  52. 52. Packerの
 プラグインを書いた話
  53. 53. Packer
  54. 54. Packer
  55. 55. http://www.slideshare.net/hsbt/advanced-technic-for-os-upgrading-in-3-minutes
  56. 56. Do scale-out
  57. 57. #3分で スケールアウト
  58. 58. http://udzura.hatenablog.jp/entry/2015/03/20/192619
  59. 59. やりました
  60. 60. Packer で、 やりました
  61. 61. じゃあ、それを OpenStackでも
  62. 62. Nyahについて > ネットワークに癖がある > DHCPエージェントは使わない > metadataエージェントも使わない > なのでこうする > 事前にport(仮想NIC)を作る > IP、MAC addressなどをuserdataを使って流し込んで ネットにつなぐ
  63. 63. 既存のopenstack builder > ネットワークに癖がある > DHCPエージェントは使わない > metadataエージェントも使わない > なのでこうする > 事前にport(仮想NIC)を作る > IP、MAC addressなどをuserdataを使って流し込んで ネットにつなぐ こういうカスタマイズには 対応していない!
  64. 64. じゃあどうしよう
  65. 65. packer-builder-nyah
  66. 66. Packerプラグインの 作り方
  67. 67. Pluginの種類 > Builder > プラットフォームごとのアダプター
 (AWS, Openstack, QEMUなど) > Provisioner > 立ち上げたソースサーバに実際のプロビジョニングをしていく
 (Shell Script, Chef, Puppetなど) > Post Processor > 後処理(docker builderならdockerhubにpushするとか)
  68. 68. 今回必要なのは Builder Plugin
  69. 69. 方針 > 既存のOpenStackプラグインの実装を参考に する、どんどんパチる > Nyah固有の必要な処理だけ自分で書く > 先にPort用意して特別なuserdataを流すとこ だけ書けばいい、はず。そのはずなんだ
  70. 70. How to write
  71. 71. 最低限のルール > 以下を満たすインターフェース > これが処理のエントリポイントになる type Builder interface { Prepare(...interface{}) error Run(ui Ui, hook Hook, cache Cache) (Artifact, error) Cancel() }
  72. 72. Builder typeを > これをコマンドのエントリポイントにして > 普通にビルドすれば良い > 利用するには、
 packer-builder-nyah
 という名前のバイナリにし
 PATHを通す
  73. 73. それぞれのフェ∼ズ Prepare(...interface{}) error > 準備。主に、設定を読み込む。 > このフェーズでサーバはいじるべきではないとのこと Run(ui Ui, hook Hook, cache Cache) (Artifact, error) > 実際のサーバ立ち上げ処理。詳細後述 Cancel() > キャンセル時/失敗時/正常終了時全部で呼ばれる後処 理。名前……
  74. 74. Runの中身 > Run(ui Ui, hook Hook,
 cache Cache) (Artifact, error) > packer.Artifactも、またインタフェース > https://github.com/mitchellh/packer/ blob/master/packer/artifact.go という 便利ドキュメントを読んで頑張る(サーバIDとか そういう情報を返せば良いとのこと)
  75. 75. まずは > ビルドが > できる > とこまで…うう
  76. 76. いよいよ、Run()の 中身を書く
  77. 77. Run() 既存実装の詳細 > キーペア登録 > サーバ立ち上げ > Floating IPの割り当て > SSH接続、操作 > 終了処理 > イメージ作成
  78. 78. この辺をいじれば良さそう > キーペア登録 > サーバ立ち上げ > Floating IPの割り当て > SSH接続、操作 > 終了処理 > イメージ作成 portの作成を事前にする portの情報から 適切なuserdataを 作った上で立ち上げ Floating IP は使わない (portにIP情報がある)
  79. 79. Goを書くぞ
  80. 80. mitchellh/multistep > Step構造体を定義して
 それを並べるだけ > Stepの再利用できる > やることが、Stepという
 単位で分割される
  81. 81. mitchellh/mapstructure > 「賢いJSON」 > JSONのパーサライブラリ > 現実的なユースケースに
 色々対応していて
 コードがスッキリする https://github.com/mitchellh/mapstructure
  82. 82. gophercloud > Goライブラリのデファクトスタンダード > Rackspace社で保守 > APIは結構……あれだけど活発な開発 > 以前別のクライアントで使って、経験があった https://github.com/rackspace/gophercloud
  83. 83. ロゴが良い(...)
  84. 84. さて、どんな感じか中身を見てみよう…
  85. 85. fork………?????
  86. 86. 諸事情でforkされていた。。。だと
  87. 87. michellさん「Wow!」
  88. 88. そして足りない機能がある………… > サーバ立ち上げ時に、「ネットワーク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
  89. 89. forkをfork
  90. 90. $ 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
  91. 91. パッケージ名が合わない! > ミスマッチの対応のためのバッドノウハウ > ミスマッチするところは、そのimport文だけを 変えた形で
 本家から
 コピーして
 配置しておく
  92. 92. いろいろなYakを狩りまくり 最終的には……動いた!
  93. 93. そしてNヶ月が過ぎた
  94. 94. またまた∼
  95. 95. 突然の _人人人人人人人人人人_ > upstream変更 <  ̄Y^Y^Y^Y^Y^Y^Y ̄
  96. 96. どうしたか? > godepの導入 > packerの、動いている段階のビルドを探して
 ………………………………………………………
 ………………………………………………………
 ……………………………………………………… > fork
  97. 97. 得られた教訓 > 容赦なくupstreamが変わる、それがGoの世界 > とくに、packerは別にもとから外部向けのライブラリではなく、たま たまいい具合にパッケージが分かれていたのを使っただけなので、仕方 なさがある > 運用で使うようになったらgodeps > しかしGoは型があるので便利 > いざとなったらとにかくコンパイルエラーを直し、なんとかする > CIしようぜ!!! > すぐ気づける
  98. 98. おまけ > Provisioner Pluginも作ってみた > https://github.com/udzura/packer-provisioner-serverspec > 同じように、インタフェースを合わせれば良い。便利 > 詳細はコードで!
  99. 99. Consulを
 バーンと
 入れた話
  100. 100. http://www.slideshare.net/hsbt/advanced-technic-for-os-upgrading-in-3-minutes
  101. 101. Do scale-out
  102. 102. #3分で スケールアウト
  103. 103. 大事なことなので2回ry
  104. 104. サーバをカジュアルに増やす > from 12 facter app > V. Build, release, run > Strictly separate build and run stages > IX. Disposability > Maximize robustness with fast startup and graceful shutdown
  105. 105. 監視についても > Runしたら、自動で監視対象になってほしい > Terminateしたら、勝手に外れてほしい > イメージから立ち上げたはいいけど、アプリが 正常に動いていることを何かしら確認したい
  106. 106. Consul
  107. 107. Consul の機能 > クラスタリング、ヘルスチェック > Web UI を公式に用意している > consul-alerts なんかで通知もできる
  108. 108. 検証する価値はありそう
  109. 109. インストールして
 立ち上げてみた
  110. 110. 何これ怖い
  111. 111. vm.overcommit_memory=0
  112. 112. おおう……
  113. 113. strace 32 GB
 + 8 GB
  114. 114. メモリをガツッと確保する > 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
  115. 115. 立ち上がったので クラスタリングしてみようかな
  116. 116. めちゃくちゃ不安定…… > いろいろいじった結果、
 UDPのポート8301 をお互いに許可していな かった。。。。。。 > 開けたら安定した > 使うポート/プロトコルは↓ https://www.consul.io/docs/agent/options.html
  117. 117. よっしゃ導入OK!
  118. 118. それから数週間後
  119. 119. CPU 1個のインスタンスだと…… > consulは、 GOMAXPROCS=2 以上の設定 を強く推奨している > GOMAXPROCS=1、またはCPU 1個だと
 パフォーマンスで問題が起こる > 1個のものは、CPU2個以上で、作り直した
  120. 120. “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.
  121. 121. Tips: VirtualBoxで試すとき > IO/APIC を有効に
 しないとダメです > Vagrantなら以下の感じ
  122. 122. そんなこんなで 安定運用(?)
  123. 123. できなかったことが できるようになる
  124. 124. 内部DNS
  125. 125. OpenStackの内部DNS > 結構悩んでいた > DHCP agentは使えないし、自分でDDNS?
 うえ∼ > APIを叩いてhostsを定期更新、とかも手。
 だが……
  126. 126. DNS INTERFACE
  127. 127. 方針 > ドメインを minne.lan とかにする > dnsmasq を全台に導入 > *.node.minne.lan は dnsmasq から
 localhost:8600にフォワード、
 各サーバでは127.0.0.1をリゾルバに
  128. 128. あっさり導入完了
  129. 129. Consulが撃沈したり…… > DNS APIは、リーダーがいないと叩けない > 一時的にリーダーがいなくなるタイミングとか はどうしてもあるので > dnsmasqの設定にしてしまってキャッシュし ておく
  130. 130. これを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自体が使えないときはそもそも キャッシュが上書きされないようにしている
  131. 131. 便利 > クラスタにジョインしたら、すぐに内部の名前 でSSHできるようになった! > ConsulのAPIはめっちゃ軽いので良い
  132. 132. 副産物 > 踏み台+内部DNS+peco+Consul APIにより
 便利ログイン君ができて便利になった
  133. 133. 動的LB
  134. 134. ELB的なやつにほしい要素 > 動的なメンバー追加、削除 > 自動的なヘルスチェック > 高い可用性
  135. 135. consul-template
  136. 136. consul-templateで > 動的なメンバー追加、削除 > 自動的なヘルスチェック > この二つは実現できるぞ!
  137. 137. consul-templateの仕組み LB www www www フロントLBもNginxとする。 全台、consulのクラスタに ジョインする
  138. 138. consul-templateの仕組み LB www www www たとえばバックエンドのプロセス (NginxならNginx) に特定のタグを加えて Consulのチェックを追加する
  139. 139. JSONの例 sandbox-front というタグを特別につけている
  140. 140. consul-templateの仕組み LB www www www LB側では、「sandbox-front」 というタグに紐付いた サービスの状態を監視している
  141. 141. テンプレートを書く 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)のものを監視する
  142. 142. consul-templateの仕組み LB www www www たとえば、ここで1台の Nginxがダウンしたとする 💥
  143. 143. consul-templateの仕組み LB www www www consul-template は、 nginxのfailedを検知する 💥
  144. 144. consul-templateの仕組み LB www www www 変更を検知して、 passingなメンバーのみで ループを回し、 テンプレートを更新する 💥
  145. 145. consul-templateの良さ > 仕組み自体は理解できれば割とシンプル > チェック項目、フックなどのカスタマイズがわかりやすい > フロントのNginx自体には、
 何の手も加えていない > そのため、本来のNginxのパフォーマンスが出るし、
 チューニング等も特別なことはない
  146. 146. 制限事項 > 最後に残った、LB自体の可用性は、
 普通にLVSなりkeepalivedなりに
 頼ることになります……。 > ここは地道に頑張っている
  147. 147. インフラ運用で 新規ツールを導入する意義
  148. 148. ここから ビッグ主語
  149. 149. 運用と開発
  150. 150. きょうびのWeb開発 > バンバンバージョンアップされる > Railsが有名だが、PHPも激しいし、フロントエンド界隈、 nodejs、Go、Docker、iOS/Android開発…… > どんどん変わっていく > 動き続けないと、古くなる > 古くなると動きが遅くなる。どこかで、新しいこ とができなくなる
  151. 151. > 「運用とはユーザの価値を減らさないよう維持 することだ」 > by haras⚪u5さん > 重い言葉だと思う。ユーザが必ずしも変化を求 めているか? 一方、運用とは?
  152. 152. なお、インフラエンジニアは死んだらしいぞ
  153. 153. どうすればいいの? > Webに関わるソフトウェアの大きな潮流は、動 き続ける、変わり続けることに舵を切っている > 運用エンジニア・インフラエンジニアもこの潮 流を全く無視することはできないのではないだ ろうか?
  154. 154. リスクの例: 脆弱性 > 「変わらない」に舵を切った結果、
 CentOS 4 のサーバが残っていたらどうする?
  155. 155. 変化を恐れない
  156. 156. 動き続けるインフラ運用
  157. 157. 変化を適切に恐れる
  158. 158. よく知られた事実 > 新しくソフトウェアを書くと、
  159. 159. よく知られた事実 > 新しくソフトウェアを書くと、 > バグが起こることがある!!!
  160. 160. cf. バスタブ曲線 https://ja.wikipedia.org/wiki/%E6%95%85%E9%9A%9C%E7%8E%87%E6%9B%B2%E7%B7%9A
  161. 161. 一切ソフトウェアを書かなければ バグも起こらない
  162. 162. 動くことにもリスクがある > なので、我々は、動くことのリスクを最小限に しないとならない
  163. 163. リスクを減らすには?
  164. 164. ここでやっと
  165. 165. Hashicorp
  166. 166. 動き続けるインフラ運用に
 なぜHashicorpが効くか
  167. 167. より運用者に近いレイヤ
  168. 168. レイヤ分け > ミドルウェアの3分類 > 日常の作業のツール > 運用のためのデーモン > ユーザに直接関わるデーモン > 上の2つについては、新しいものを試しやすく、 切り戻しも比較的容易
  169. 169. レイヤ分け > ミドルウェアの3分類 > 日常の作業のツール > 運用のためのデーモン > ユーザに直接関わるデーモン > 上の2つについては、新しいものを試しやすく、 切り戻しも比較的容易 Vagrant, Packer, Terraform Consul, Serf, Vault (consul-template)
  170. 170. ツール自体のモダンさ
  171. 171. Hashicorp toolsの考え方 > ツール自体が大変近代的な開発 > githubでオープンに開発 > テストコード、CI完備 > Codification=設定は必ずコードになる > 設定変更を履歴管理ことを強く推奨する > Go言語を選択し、コードも綺麗 > 導入時の安定性
  172. 172. インフラCIをはじめとした、テスト > テストを、それも自動でする時代 > Serverspec、Infrataster > Dockerなどによるインフラのコンポネント化 > 「責務を小さく」することでのテスト容易性 > ミドルウェアにも洗練されたテストコード > Hashicorp toolsはテスト、開発のオープンさを重視している > なにより、監視 > 最近はmackerelのようなサービスもある
  173. 173. cf. サーバ開発自体のモダン化 > 検証環境を作るコストが格段に下がっている > AWSをはじめとしたクラウドのコモディティ化 > 構成管理ツール(Chef/Puppet/…)の普及 > Vagrantの出現 > コンテナ仮想化のブーム > その気になればステージングを丸ごともうひとつ > (そこでterraform?)
  174. 174. 「新しい」ことのアドバンテージ > モダンなOSS開発手法 > モダンなツール、言語、環境 > →ソフトウェア自体の質が向上している > このアドバンテージが「枯れているが、保守さ れていないミドルウェア」に勝る時代になって きているのではないか
  175. 175. TerraformのMakefile > CIのテスト、受入テスト、レースコンディショ ンの検知テストが全部コマンド一発(らしい)
  176. 176. 目的をはっきりさせる
  177. 177. 目的をはっきりさせる > ゴールデンイメージを作る手順を完全にコード化 したい > →Packerを使う > 動的な監視を、まずは実現したい
 (それ以上のことはおいおいでもいい) > →Consulを使う > 達成できない、とわかったらちゃんと引き返す
  178. 178. 既存のツールでいいときは冒険しない > 例えば: > サービスが落ちたのをconsulでチェック→
 落ちたことをフックにconsul watchでサービス再起動→
 やった!自動再起動できた! > それ、monitでできるよ……
  179. 179. ちゃんと2つ以上の何かを減らせるか? > 小さな、かつ新規性のあるツールを選ぶ > 何か新しいものを1つ入れるときは既存の何か を2つ以上減らせること > http://myfinder.hatenablog.com/entry/2015/03/27/141416
  180. 180. 非連続性に挑戦する
  181. 181. 連続性、非連続性 > 普通の運用は連続的 > 枯れたツールを使う > 変化を避けていく > 手順を継承する > 連続的に問題を解決することはめちゃくちゃ大 事である!!
  182. 182. どこかで、非連続性がほしい > 今までに解決していない問題を解決しないとい けない > 非連続性への 投資 > Yak刈りの結果、どんな問題が解決するか?
  183. 183. 非連続の先を見るために Yak刈りを厭わない
  184. 184. Hashicorp toolsは > 新しい概念(=非連続性)でOpsの問題を解決 するツール > 実際に、イメージ作成の簡易化、機密情報の管理、サービ スディスカバリ、動的設定変更など、これまで難しいとさ れてきた課題に答えを出しつつある > しかも、非常にオープンなツールで使いやすい
  185. 185. 総括
  186. 186. 動き続けるために
  187. 187. 動き続けるためのバランス > むやみな破壊をしない > むやみに守らない > ちゃんとバリューを出せる見込みを持って攻め 込んで行こう
  188. 188. Hashicorpツールから学ぶべきことは、
 ツール自体以上に、
 たくさんあるかもしれない
  189. 189. [PR]
  190. 190. ペパボにはHashitoolsを使う仕事があります > 福岡でもインフラ絶賛募集! > ペパランチョンでお話を。 > https://pepabo.com/recruit/pepaluncheon/?fukuoka
  191. 191. 画像ソース > タイトル写真 > https://commons.wikimedia.org/wiki/ File:Kings_Cross_Train_Station_London_England.jpg

×