Puppet of-2015-forupload

Transcript

• 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なんて（ｒｙ、Ansibleでは？？？？？？
• 9. Puppet > 古い > 独自言語でとっつきにくい > MizzyさんのPuppet 2系の記事 > 古い > 時代はChef、いやChefすらオワコン、Itamaeで は？？？？ > いやRubyなんて（ｒｙ、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と同様（ｒｙ > librarian-puppet というやつでコミュニティのマ ニフェストを使える > ChefのBerkshelfと同様（ｒｙ
• 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が実現！！１
• 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]でｒｙ > もしくは会場の
 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