...

Puppet of-2015-forupload

by uchio-kondo

on

Report

Category:

Technology

Download: 0

Comment: 0

2,583

views

Comments

Description

Download Puppet of-2015-forupload

Transcript

  1. 1. GMO Pepabo, Inc. Uchio KONDO 2015/07/04 Pepabo Techconf in Fukuoka 2015年のPuppet
  2. 2. me
  3. 3. 近藤 うちお @udzura 技術基盤チーム アドバンスドシニア
  4. 4. 自動化厨 DevOps er
  5. 5. hashicorp太郎
  6. 6. Puppet?
  7. 7. Puppetと聞いて
 どう思った?
  8. 8. Puppet > 古い > 独自言語でとっつきにくい > MizzyさんのPuppet 2系の記事 > 古い > 時代はChef、いやChefすらオワコン、Itamaeで は???? > いやRubyなんて(ry、Ansibleでは??????
  9. 9. Puppet > 古い > 独自言語でとっつきにくい > MizzyさんのPuppet 2系の記事 > 古い > 時代はChef、いやChefすらオワコン、Itamaeで は???? > いやRubyなんて(ry、Ansibleでは??????
  10. 10. Puppetは2015年のいまも 継続的に開発されている アクティブなツールです
  11. 11. 本プレゼンテーションで Puppetの誤解を 少しでも解けるのなら、幸いです
  12. 12. Puppetのご紹介
  13. 13. Puppetとは > 構成管理のための言語です
  14. 14. Puppetとは > 構成管理のための言語です Chef っぽいやつ
  15. 15. Puppetとは…… > サーバのファイル、パッケージ、サービス、ユー ザその他設定をいい感じに収束させてくれて、 > なおかつコードとして残せる感じのやつです
  16. 16. じっと見ていると Perl Rubyに見えてくる
  17. 17. Puppetその他 > 中身はRuby > なので後述しますがChefと同様Rubyで!拡張機能が書けます > clientとmaster/agent構成を選べる > Chefと同様(ry > librarian-puppet というやつでコミュニティのマ ニフェストを使える > ChefのBerkshelfと同様(ry
  18. 18. Puppetとは > 構成管理のための言語です Chef っぽいやつ
  19. 19. Chef が分かれば すぐ覚えられます
  20. 20. Puppetの歴史(独断と偏見版) > 2005年 Puppetがリリースされたらしい > ∼∼∼ > 2010年 Puppet 2.6 > 2012年 Puppet 3 が出る
  21. 21. Puppetの歴史(独断と偏見版) > 2005年 Puppetがリリースされたらしい > ∼∼∼ > 2010年 Puppet 2.6 > 2012年 Puppet 3 が出る > 2013年 伊藤直也さんが入門Chefを刊行
  22. 22. 2014年からのPuppet > 2014年 いいかげんPuppet3.6とかになる >      突然puppetserverが出現、
      clojure で書かれる > 2015年 突然Puppet4が出る >      そして伝説へ……
  23. 23. 勢いあるね?
  24. 24. Why Puppet
  25. 25. ペパボでPuppetな理由 > 社内のノウハウが非常に蓄積されている > minneのような新規のPJもPuppetで構成管理をはじめ、 非常に多くのアドバイスのもと完了した > 一番スピードが出せる
  26. 26. ペパボでPuppetな理由 > 「RubyのDSLじゃない」ことのメリット > Rubyの機能をむやみに呼んでしまわない > Kernel#systemやFile.exist?を直接呼ぶ混乱 > 他のツールに比べると、
 勢いはあるが根本的な仕様変更は少ない > 良い枯れ方をしていると判断
  27. 27. ツール選びで大事なこと > ひとつのツールに精通する > ちゃんとそのコミュニティに貢献する > 今日はPuppetに貢献するぞ!
  28. 28. Puppet language update
  29. 29. puppetserverの JVM化
  30. 30. それまで > puppetmasterという名前だった > Ruby製 > Rack対応していて、Passengerで動かすなど していた
  31. 31. puppetserverの登場 > 2014/09 Puppetlabsのアナウンス > https://puppetlabs.com/blog/puppet-server-bringing-soa-to-a- puppet-master-near-you > 要約: Clojureにするわ > えっ。……?
  32. 32. _人人人人人人人人人人_ > 突然の      <  ̄Y^Y^Y^Y^Y^Y^Y ̄
  33. 33. 勢いある事例 > PuppetserverのためにClojureのWAFをつ くったらしい > Trapperkeeper という名前 > https://github.com/puppetlabs/trapperkeeper
  34. 34. 勢いある事例 > PuppetserverのためにClojureのWAFをつ くったらしい > Trapperkeeper という名前 > https://github.com/puppetlabs/trapperkeeper > 既存のPuppet parserはJRuby
  35. 35. 複数JVM言語カジュアル
  36. 36. こう変わった > 高速になったらしい > 今まで以上にインストールが楽 > yum install puppetserver 一発に > 運用も楽 > Apache/Passengerのノウハウはいらない > 設定ファイルが新しくなっている > 既存の設定も読んでくれる、徐々にマイグレートしよう……
  37. 37. Puppet4
  38. 38. Puppet3の時代の終焉 > Puppet 3.7 あたりからめちゃくちゃ deprecation warningが出るように…… > ついこないだ(2015/04)、
 Puppet4のリリースがされた! > https://puppetlabs.com/blog/say-hello-open- source-puppet-4
  39. 39. 消えた機能 > Ruby 1.8.7 サポートをやめる > Bad Practice的機能が消えている > Ruby DSL…… > import文 > node inheritance > ベストプラクティスに沿っていれば、何れにして も使わなそう
  40. 40. EPP(Embedded PuPpet) > ERBのようにPuppetを埋め込む…… > http://puppet-on-the-edge.blogspot.co.uk/2014/03/ templating-with-embedded-puppet.html
  41. 41. Ruby並みにイテレータが…… > each! map! filter!!!!
  42. 42. Ruby並みにイテレータが…… > each! map! filter!!!! type hinting!!
  43. 43. その他変更 > パッケージが All-In-One に > Autoloadingの挙動変更(依存をきっちり書かないと見えな くなる) > Optional Typing > 文法的変更(substring記法、Hashの展開など……) > その他たくさん…… > http://www.slideshare.net/PuppetLabs/puppet-language-40- puppetconf-2014
  44. 44. 既存のマニフェストは……? > deprecation warningを真面目に倒していれ ば問題は少ない > Rails的な乗り切り方ですね > 後述するFactorとかRubyな奴も動く > リモートのmoduleは……PRやforkで……
  45. 45. “– http://www.slideshare.net/PuppetLabs/puppet-language-40- puppetconf-2014 Yamata no Orochi
  46. 46. なお、今日のExcuse > あまりに最近出たのでPuppet 4の検証が十分 ではありません…… > 今日の色々な例は、Puppet 3.xの最新版(3.8 系)で確認しています…… > 「2014年のPuppet」かもしれない
  47. 47. Puppetを書く
  48. 48. ディレクトリのパターン
  49. 49. ここで登場する名著
  50. 50. このパターン . ├── Puppetfile ├── Vagrantfile ├── config/ ├── hiera/ ├── manifests/ ├── modules/ ├── roles/ ├── spec/ └── vendor/ └── modules/
  51. 51. このパターン . ├── Puppetfile ├── Vagrantfile ├── config/ ├── hiera/ ├── manifests/ ├── modules/ ├── roles/ ├── spec/ └── vendor/ └── modules/ …… 設定、capistranoとか …… hieraのデータ …… 実際に実行する、エントリポイント …… 全体で使うモジュール …… ロールとして扱うモジュール …… serverspecです! …… librarianで入れるモジュール
  52. 52. モジュールの中のディレクトリ > こっちはPuppet的に規約がある > manifests/init.pp が
 デフォルトで読まれる
 クラス consul になる > その他は manifests/config.pp なら
 クラス consul::config を定義する modules/consul ├── files/ ├── manifests/ └── templates/
  53. 53. tamplates/, files/ 配下は…… > 諸説ある > destとディレクトリを合わせた方がいいんじゃね?派 > /etc/foo/foo.conf なら templates/etc/foo/foo.conf > 名前だけ合わせればいいよ派 > /etc/foo/foo.conf なら templates/foo.conf だけ > 被ったらサブディレクトリを切るなど > 状況による。個人的に後者でも混乱しないことが多い
  54. 54. クラスを作る
  55. 55. 黄金パターン > dnsmasq を管理するモジュールなら: modules/dnsmasq/manifests/ ├── config.pp ├── init.pp ├── install.pp └── service.pp
  56. 56. init.pp > 他のクラスを読み込む > 依存を明示的に書く
  57. 57. その他 > install.pp > パッケージを入れる > config.pp > カスタマイズした場合設定を管理する > service.pp > サービスの状態(有効か、立ち上がっているか)の定義 > 定義しておけば、他のモジュールから notify でキックで再起動できる > config.ppは変更時にかならずservice.ppをnotifyするはず
  58. 58. それ以外っぽい要素は > 適宜クラスを作成すれば良い > 依存するyum repoを定義するのを切り出すとか > プラグインのインストールを切り出すとか
  59. 59. 一つのクラスの責務を 小さくするのがコツ
  60. 60. 依存関係の記述
  61. 61. Puppetの依存関係解決は自動じゃない > Chefのように「上から実行」とは限らない > -> と > がある > Resource[ A ] -> Resource[ B ] > AのあとにBを設定する > Resource[ A ] > Service[ B ] > Aを設定したら、サービスBを再起動する
  62. 62. 「一発で通す」ために > ChefにしてもPuppetにしても、「失敗するんで 何回かキックする」ということがあるはず > 冪等性万歳! > しかしPuppetの場合、「ここが足りないからエ ラーなんだな」というのを追いかければ、
 依存性を明示することで「通せる」ようにしやす い
  63. 63. 具体例 > Nagiosを入れる > Nagiosの自作プラグインを入れる
  64. 64. どっちが先かは実行時による > なので、「プラグイン」→「Nagios」の順だ と、 nagios-plugins-allパッケージの生成す るディレクトリが作られていないので、プラグ インのfileリソースが失敗する > なので nagios-plugins-all -> カスタムプラグ インの依存を明示したい
  65. 65. すればいいじゃない
  66. 66. 無事通るようになる > よかったですね
  67. 67. 「通知する」パターン > 典型的: 「zipを落として解凍したい」 > 解凍する処理が毎回走ると無駄なので、
 refreshonly にして notify でキック > Chefで言うと…… > action :nothing する > ダウンロードの処理とかで notify exec[unzip]
  68. 68. 例えばこう
  69. 69. Defined Types
  70. 70. Defined Types > 「ひとまとまりのリソース定義」を
 独立したリソースのように見せかけることがで きる > マクロ感覚 > コツとしては、Defined Typesの中でも
 依存関係を意識すること
  71. 71. ここでも具体例 > consulのcheck設定を
 defined typeにした > ディレクトリのために
 consulパッケージ
 が必須とする > テンプレートの場所は
 規約で。
  72. 72. こういう書き方ができるようになる > 依存記述が綺麗になる > <¦ ¦> はマニア機能だが、「∼に所属するすべて のリソース」ぐらいの意味
  73. 73. その他の
 ベストプラクティス
  74. 74. 参考便利スライド > http://www.slideshare.net/PuppetLabs/ upgrading-puppet > Puppet 4対応記法こそが良い記法です
  75. 75. Puppet in Action
  76. 76. Puppet in Action とは > あんまり日本語で説明している人がいないよう な機能を紹介します
  77. 77. Hiera
  78. 78. Hieraとは > Hierarchy Data > 環境別の設定項目をYAMLに切り出せる
  79. 79. Hieraの例です > hiera/hieta.yaml > hiera/development/common.yaml
  80. 80. Custom Function
  81. 81. Puppetの関数をrubyで書ける > rootfsがaufsかを判定する例 > Docker分岐カジュアル
  82. 82. Custom Facter
  83. 83. そもそもFacterとは > 設定対象サーバの様々なパラメータを動的に簡 単に取得するやつ > たとえばホスト名、OSの種類、メモリやCPU の情報、インタフェース、などなど…… > factor ではない
  84. 84. そもそもFacterとは > 設定対象サーバの様々なパラメータを動的に簡 単に取得するやつ > たとえばホスト名、OSの種類、メモリやCPU の情報、インタフェース、などなど…… > factor ではない > いろいろ言いましたが、Chefでいうohaiです
  85. 85. カスタムFactorもRubyで。
  86. 86. なんでFunctionよりFacterか > Facterは、環境変数で上書きできるので、色々 な意味で扱いやすい > FACTER_FOO で $::foo に値が入る
  87. 87. ☕ 休憩 ☕
  88. 88. PuppetとインフラCI
  89. 89. ここからの話題は Chef/Ansible/Itamaeにも 置き換えられるよ!
  90. 90. あと、ここから 難易度一気に上がる気がする……
  91. 91. 「壊れないマニフェスト」
  92. 92. 再掲:「一発で通す」ために > ChefにしてもPuppetにしても、「失敗するんで 何回かキックする」ということがあるはず > 冪等性征万歳! > しかしPuppetの場合、「ここが足りないからエ ラーなんだな」というのを追いかければ、
 依存性を明示することで「通せる」ようにしやす い
  93. 93. 再掲:「一発で通す」ために > ChefにしてもPuppetにしても、「失敗するんで 何回かキックする」ということがあるはず > 冪等性征万歳! > しかしPuppetの場合、「ここが足りないからエ ラーなんだな」というのを追いかければ、
 依存性を明示することで「通せる」ようにしやす い
  94. 94. 再現しないマニフェスト > 「本番なら動くけど手元で再現できないなあ ……」 > 逆に、「本番に適用するのこわくね?」 > 安心感が欲しい
  95. 95. apply恐怖症を克服する > そのためには、何度もカジュアルに
 puppetマニフェストを実行することが > 一番の近道である。 > なんども実行できるということは、
 どこでも実行できるということにつながる
  96. 96. よろしい ならばCIだ
  97. 97. Docker
  98. 98. DockerとインフラCI > Puppetのテストなので、「実際に」何かのマ シンにpuppetを流さないといけない > マシンの例: > VirtualBox……重い > kvm……重い、Mac上で動かせない > 世の中にはコンテナ技術というものがある……なるほど?
  99. 99. Dockerが解決すること > 軽量で、すぐに立ち上がること > ベースとなるイメージのコード化、使い回し > Macでも手軽に試せる > boot2dockerの存在
  100. 100. Dockerが解決しないこと > kernelは、ホストのLinuxのそれになる…… > なので一部のパッケージが動かなかったりする > まだまだバグ、undocumentedな挙動がある
  101. 101. cap_set_file問題
  102. 102. cap_set_file問題 > httpd、systemdなど一部のパッケージが
 aufsバックエンドでインストールできない > 原因は、aufs側の問題で、カーネルのバージョンをあげる と解決 > 3.18以降とのこと > https://github.com/boot2docker/boot2docker/pull/818 など > devicemapperでは問題は起きない
 (ただしパフォーマンスの問題はある)
  103. 103. 気持ちになって Dockerを使う
  104. 104. Serverspec
  105. 105. Serverspecとは > Puppetに限らず、サーバの状態を宣言的に、 手軽に検査する敷居の低いツール > rspecを利用 > specinfraという、サーバ操作をいい感じに抽 象化するライブラリを使う
  106. 106. なんだかPuppetと相性がいい気がする > 気のせい?
  107. 107. Puppetを流したあとで > もちろん、Serverspecも流す! > Puppet的には通過するけどいけてないパター ン(例: サービスが立ち上がったはいいけどす ぐに落ちる)もあるので、それを検知する
  108. 108. Ruby 2.0系のトラップ…… > コメントに日本語が混ざると、エンコーディン グってやつがね…… > RUBYOPT=-Eutf-8:utf-8 を渡して解決 > 詳細の話は > http://docs.ruby-lang.org/ja/2.2.0/method/ Encoding/s/default_external.html
  109. 109. Drone.io
  110. 110. って何? > CIするやつ > トラヴィスなんとかのようなことがOSSででき て、割と運用が楽 > 書いた: 「Drone.io のご紹介」 > ムックもある
 「Dockerエキスパート養成読本」 http://www.slideshare.net/udzura/droneio 
  111. 111. Drone loves Docker > 具体的には、ビルドごとにDockerのコンテナ を立ち上げるので、クリーンな環境でテストが できて便利である
  112. 112. Docker in Dockerする > Dockerコンテナからは、当然Dockerサーバ 自体が見えるので、 > そこをクライアントから叩けばコンテナないか ら別のコンテナを立ち上げ、アクセスできる > DockerによるインフラCIが実現!!1
  113. 113. docker-in-docker > Dockerfileです > refs: https://registry.hub.docker.com/u/igneoussystems/docker-client/dockerfile/
  114. 114. ここまでの全体の様子
  115. 115. ここまでの全体の様子 Puppetの
 コードをプッシュ
  116. 116. ここまでの全体の様子 Drone.io のジョブで 素のDockerコンテナを作成。 そのコンテナにPuppetを適用、 Serverspecも流す
  117. 117. ここまでの全体の様子 ※merge後のCIが成功したら、
 Puppetserverに自動でマニフェストを配備 (Continuous Delivery)
  118. 118. CIのコツ
  119. 119. ずばり、やりすぎないこと です……
  120. 120. インフラCIのyak要素 > そもそも本番と環境違うじゃん > Docker vs KVM, Xen……(時にはベアメタル) > 動かないマニフェストはどうしても動かない > エッジすぎる技術要素 > Dockerは人類には早すぎるのか?何度も思い、心 が折れそうになりました
  121. 121. CIでスキップする分岐があってもいいじゃない…… > 「何も動かさない」ことと「まあ、だいたい動 いてる」こととの間には越えられない壁がある
  122. 122. インフラCIの将来…… > そもそもOpenStack基盤できつつあるし
 そこでやればいいんじゃと思ってる
 (起動時間問題はある) > vagrant-kvm とかを試す
  123. 123. Puppetと
 未来のデプロイについて
  124. 124. 手動のサーバ構築を
 イメージをポンと
 起動するだけに
 したお話
  125. 125. イメージぽんのための概念 > Orchestration > Application Service Deployment > Configuration > System Configuration > Bootstrapping > OS install > Cloud or VM Image Launch http://mizzy.org/blog/2010/03/26/1/
  126. 126. 要するに > 秘伝のイメージを作る > できれば完全にコード化された形で作る > 秘伝のイメージの起動初期化処理を完璧にする > 既存サーバとの繋ぎこみを綺麗にする > これらすべてが自動化すれば、
 サーバ構築はすべて自動化できるということになる
  127. 127. バンド「The DevOps」 > メンバー紹介 > ドラム: Packer > ベース: cloud-init > ギター: Consul > ボーカルはあなたのWebアプリだ!
  128. 128. Packer
  129. 129. Packerがやってること > プラットフォーム別に起動・接続・イメージ化 を抽象化する(Builder) > 接続して様々なプロビジョニング処理を走らせ る(Provisioner) > 後処理をする(Post-Processor)
  130. 130. AWS/OpenStackなどのクラウドでは > あらかじめ公開 ペアをAPI経由で用意 > 最低限のイメージからインスタンスを立ち上げる > 立ち上げたインスタンスにつなぐ > シェル、ファイルアップロードなど
 各種プロビジョニングをする > イメージ化のAPIを叩いてイメージにする
  131. 131. AWS/OpenStackなどのクラウドでは > あらかじめ公開 ペアをAPI経由で用意 > 最低限のイメージからインスタンスを立ち上げる > 立ち上げたインスタンスにつなぐ > シェル、ファイルアップロードなど
 各種プロビジョニングをする > イメージ化のAPIを叩いてイメージにする ここはBuilderで やってくれる
  132. 132. AWS/OpenStackなどのクラウドでは > あらかじめ公開 ペアをAPI経由で用意 > 最低限のイメージからインスタンスを立ち上げる > 立ち上げたインスタンスにつなぐ > シェル、ファイルアップロードなど
 各種プロビジョニングをする > イメージ化のAPIを叩いてイメージにする ここはBuilderで やってくれる ※まあOpenStackのは自作したけど、それはまた別の機会で……
  133. 133. AWS/OpenStackなどのクラウドでは > あらかじめ公開 ペアをAPI経由で用意 > 最低限のイメージからインスタンスを立ち上げる > 立ち上げたインスタンスにつなぐ > シェル、ファイルアップロードなど
 各種プロビジョニングをする > イメージ化のAPIを叩いてイメージにする
  134. 134. プロビジョニングが うまくいかないとダメ
  135. 135. そこでPuppet
  136. 136. Puppetを流す! > masterをあらかじめ立てておけば、 > あとは puppet agent するだけで完成!
  137. 137. Puppetの質が重要 > そのために、一発で通るPuppetであることが 非常に重要 > なのでCIなど、壊さない工夫が重要になる > Packerのプラグインがあるけど…… > シェル数行なのでシェルプロビジョナでやればいいと思う
  138. 138. イメージはできた
  139. 139. それからどうする?
  140. 140. cloud-init
  141. 141. cloud-initって知ってますか…… > AWSerは「userdata」とかサラッと言ってる けど割と独特の概念 > OpenStack, GCEその他でも共通 > 今日は覚えて帰ってください
  142. 142. cloud-init概要 > クラウド系プラットフォームにおいて、 > イメージからVMを立ち上げて、直後に走らせ る処理を簡潔に書くミドルウェア > その「初期化指示書」がuserdataと呼ばれる > シェルスクリプト > 宣言的にyamlで記述もできる
  143. 143. yaml
  144. 144. こんなことをさせる > 起動時にHDDを拡張する > ホスト名を変える > mackerel、Consulなどの
 クラスタにジョインする > 起動したよ∼って通知する > などなど……
  145. 145. 深い話は > [cloud-init zetta.io] で検索するとわりといい ドキュメントが出る > [cloud-init kenchan per-xxx]でry > もしくは会場の
 linyowsさんに聞く
  146. 146. userdataの指定の様子 > nova boot 
 --flavor m1.xlarge 
 --image foo_base_image 
 --security-groups base,www
 --user-data ./userdata/foo.yaml
  147. 147. やった!起動したぞ
  148. 148. 起動したあとも いろいろあるんだわ……
  149. 149. Consul
  150. 150. Consul > クラスタをいい感じにしてくれるやつ > ヘルスチェックとか > クラスタの状態に応じて設定ファイルを
 自動生成するとか > やっぱり通知とか
  151. 151. 詳細は前回のやつで…… > [udzura consul]
  152. 152. まとめ
  153. 153. Puppetはナウい
  154. 154. Puppetは 枯れていつつも 開発が活発
  155. 155. 情報が 古いだけで古いイメージ
 よくない
  156. 156. Puppetは 扱いやすい!
  157. 157. Puppetでなくてもいいけど、 ツールの本質を掴んで 使いこなそう!
  158. 158. Puppetはナウい
  159. 159. Special Thanks
  160. 160. 圧倒的感謝 > 人間puppet masterこと
 @lamanotlama さん > 若手インフラ @hfm さん > Puppet学習初期のこのお二人のご指導なくし て、ここまで素早い学習はなかったと思います
  161. 161. 画像引用元 > タイトル画像 > https://commons.wikimedia.org/wiki/ File:Takarazuka_Grand_Theater05s4s3104.jpg > GFDL+creative commons2.5
  162. 162. [PR]
  163. 163. ペパボにはPuppetを使う仕事があります > 福岡でもインフラ絶賛募集! > ペパランチョンでお話を。 > https://pepabo.com/recruit/pepaluncheon/?fukuoka
Fly UP