Puppet of-2015-forupload

  • CategoryTechnology

  • View2582

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