トップ 追記

人徳ゼロ日記


2015-12-18

_ スマホから強烈に見づらかったので、ブログのテーマをスマホ対応になっているtDiaryのデフォルトに変更した

普段、自分のサイトは投稿の時しか見る機会がないので、スマホから見ることはほとんどありませんでした。

昨日のPuppet Advent Calendar向け記事をスマホから見たら、箇条書きは異常に横幅細くなるは、画像ははみ出るは、ひどかったです。さすがにまずいと思って、tDiaryデフォルトのCSSに変更して、暫定対処。

もともと使っていたCSSの修正もしないとな。


2015-12-17

_ GeppettoというPuppetのIDEを使ってみた感想(Puppet Advent Calendar 2015)

Puppet Advent Calendar 2015の17日目の記事です。

PuppetのIDEでGeppetto というソフトがあります。前から知ってはいましたが (2年前の記事)から知ってはいましたが なかなか使う機会がありませんでした。 今回、試しに使っていましたので、感想を書きます。
GeppettoはもともとCloudsmithという会社で開発していたのですが、 2013年7月にPuppetlabsが買収して、公式のツールになりました。

(脱線)Geppettoを試すきっかけ

ちょうど私の子どもが幼稚園のお遊戯会でピノキオの劇をすることになったのですが、 子どもが口ずさんでいた歌で「…ゲペットじいさん…」という歌詞があり、 「はっっ!ゲペットさんってPuppet IDEのGepettoの語源か!!」 と気づいたのでした。(ゲペットさんは、ピノキオを作ったおじいさんのことです)

Geppettoって何て読むの?げっぺっと?何語だろうか、 という程度の認識だったのですが、 人形のパペットがらみでつながっていることにうれしくなり、 ちょうどPuppet Advent Calendarで何か書きたいな、 と思っていたところだったので記事にしました。

Geppettoを1日試してみた感想

使用したのは1日だけなので、使用感に誤りがある可能性があることはご了承ください。 公式ドキュメント(執筆時の最新バージョン4.2用) に一通りの機能が記載してあるので参照してください。

メリット

  • IDEの一般的な良さを受けられる。
    • (Geppetto固有ではないが)ファイルをたくさん開いても大丈夫。 Puppetでは、site.pp、hieraのyaml、モジュールのclass、テンプレート等、 多数のファイルを開いて作業することになるが、 IDEの良さで1画面にコンパクトに収まる。

      Geppetto画面例

    • 文法認識エディタの利点。文法ハイライトできる。文法エラーが即座にわかる。 まあ、この辺りはemacsとかvimとかのような他のエディタもPuppetモードがあるようなので (使ったことはないので使い心地はわからない)、一方的な利点ではないです。


  • Geppettoならではのメリット。
    • プロジェクト内にあるclass名、パラメタ名を認識して、存在しない識別子にはエラーが出るのですぐ気づく。 個人的に、単なる文法を認識してくれるだけかな、と想像していたのですが、 存在しない識別子にエラーが出ていて、良い意味で驚きました。

      識別子エラー

    • モジュール名、クラス名、パラメタ名を選択してF3で定義にジャンプできる。 この機能も期待していなかったのですが、良かった。 他人の作ったモジュール、クラスを追っかけるときは必須です。
      他のエディタだとタグジャンプを駆使すればそれとなくできそうですが、 だいぶ工夫が必要そうですね(やっている人はどこかにいるかも)。 ただ、モジュール名とクラス名は識別子上にカーソルを乗せているだけではだめで、 識別子全体を選択していないとジャンプできませんでしたので、ちょっと面倒です。 これは私の使い方が悪い?

    • Puppet Moduleのウィザードでは、 きれいなPuppet Moduleを作るためのプラクティスが入れ込んである。 私の周りでは、Puppet Forgeに公開できるようなポータビリティの高い モジュールの作り方は全然浸透していないので、 ウィザードで優れたひな形が出るのは良いと思いました。 と言いつつ、社内の特定プロジェクト特化のモジュールばかり作っていますが…

      Moduleウィザードの結果


    • 予約語はマウスオーバーラップで説明が表示される。 ちょい微妙かな。 まあ、基本的な予約語は覚えているのでそれほどうれしいことは少ないですが、 初めてPuppet使う人にはそれなりに意味があるかと思います。

微妙な点

  • hieraを使っていると、単なるyamlとして扱われるだけで、class名、パラメタ名を認識してくれず、F3でのジャンプができない。 これは痛いです。hieraはかなり活用しているのですが、 yamlだけ見てもどこに飛ぶのかわかりづらいので、ジャンプできてほしい。 特に、hiera_include(classes)を使っていると、ノードのyamlからクラスにたどれてほしい。 yamlは単なるデータなので、Puppetの構造情報がないですし、 hieraの階層構造も認識しないといけないので技術的に簡単ではないのはわかりますが…
    このあたり、単に正規表現で検索するほうが安直だけどそれなりなレベルで実現できるのかもしれない。

  • テンプレートファイルへのF3ジャンプができない。 これも痛いです。試験面やサーバ種別ごとにテンプレートを使い分けているときなど、 たどりたい。これも単なる文字列だったり、パラメタでテンプレート名を渡したり いろんなパターンがあるので簡単ではなさそうです。

試せていない点

  • rspec-puppet等のPuppetコードレベルの単体テストはIDE上で動かせるはず

  • Puppet Enterprise、PuppetDBとの連動(いまいち何をするものかわかっていない)

結論

  • 思ったより使える。特にクラス名、パラメタ名でF3ジャンプできるところは良いです。

  • hieraのyamlからF3ジャンプできないのは残念。

  • 初心者が混じったグループでPuppet使うなら、Geppettoで統一するの1つの手だと思いました。 特に、私の周りではJavaのプロジェクトが多く、Eclipseが統一で導入されることが多いので、 導入しやすいと思いました。

  • お気に入りのエディタで特に困っていないなら、 わざわざ乗り換えるほどでもないです。

インストール方法

インストール方法を細かく紹介してもしょうがないので、ポイントだけ。

公式ページ からたどれるdownloadページだと、 Eclipse込みのパッケージを配っています。
私は既にEclipse使っていましたので、既存のEclipseへGeppettoをインストールする方法を紹介します。 内容は公式ドキュメントAdd Geppetto to an Existing Version of Eclipse に書いてあります。

  • メニュー Help → Install New Software
  • Work Withの右のAddを押す。取得先URLを記入する。 http://geppetto-updates.puppetlabs.com/4.x
  • Geppetto for Eclipse IDEを選択
  • その他、yamlエディタは入れたほうが良い。Geppetto公式ドキュメントではyeditを紹介している。 Eclipse Marketplaceで入れる。 http://marketplace.eclipse.org/content/yedit

2015-12-16

_ 第1回日本Puppetユーザ会で発表した

第1回Puppetユーザ会 で発表をしてきました。開催から1か月半くらい経過してしまいましたが、書いておきます。

ユーザ会はまだ第1回なので、Puppetでどんなメリットがあるのか、大雑把なところを説明しました。 Puppet Manifestの書き方のテクニック、悩んだところなど、言いたいことは多いのですが、 今後のユーザ会で出していければよいな、と思っています。

特に、汎用性の高いモジュールと、わかりやすさ(シンプルさ)の両立は まだ答えがあるわけではなく試行錯誤の途中なので、 議論が進められるとうれしいです。


2015-05-18

_ Puppetの活用レベルの高い低いの議論から、インフラ自動化の成熟度モデルを妄想した

半年くらい前、Puppetの活用ノウハウをまとめたドキュメントの中身を議論する機会がありました。 以前からの書き方から、コミュニティでの動向を取り入れて、Hiera(過去記事: Puppet3.0の新機能Hiera auto-lookupの使い方)や、Role-Profileモデル(参考: http://www.craigdunn.org/2012/05/239/)の説明を入れたいね、 と話していると、「あなたの部署ならHieraが使いこなせるだろうが、他の部署やグループ会社だと使いこなせないから、説明に入れないほうが良いのでは」ということを言われて、そんな保守的に考えなくても良いのでは、Hieraは柔軟性も保守性もあがるので使って損はないのに、と思ったことがありました。

ただ、確かにRole-Profileは使いどころが難しくて使ったことがないのも事実です。 Puppet活用度の高い低いって一体何が違うのだろう、使う側のレベルにあった使い方はなにか、 を考えてみるきっかけになりました。

自分を振り返ってみると、こんな流れで発展してきています。

  • Hadoop等で大量のサーバの同じ構築をする時にピンポイントでKicstart,Puppetで自動化(効率化)
  • 一度に大量でなくても、開発環境をA面、B面、C面、D面……と複数回適用できると案外台数が多い(使いまわし)
  • 事前にKickstart,Puppetマニフェストを作っておいて何度も何度もインストール検証をして確かめておき、サーバ調達ができたら安心して構築(品質向上、作業のコード化でモビリティ出す)
  • オープンソースではない商用ミドルも含めて、Puppetを使って当たり前の状態

確かに、だんだんと進化していますねぇ。 きっかけは台数が多いことへの対処でしたが、 時間の効率化より、全サーバ・全環境で同じ変更ができることによる品質確保、コード化することでの持ち運び可能になることなどが効果として強くなってきています。

Puppet活用の成熟度モデルの妄想

そこで思いついたのは、CMMIの成熟度モデルでした。 最初は、単純に「5段のレベル分け」というところだけまねて、Puppetの使い方の進化を書いてみました。

当初の案:

  • 0.「手順書なく作業している」
      ~~~~~~~~~~~~~~~~~~~~~~ 手順化の壁
  • 1.「手順書で作業している」
      ~~~~~~~~~~~~~~~~~~~~~~ Puppet導入の壁
  • 2.「Puppetを小規模で利用している」
        Node定義、Module定義の組み合わせ
      ~~~~~~~~~~~~~~~~~~~~~~ Hiera導入の壁
  • 3.「Puppetを大規模、維持管理で利用している」
        Hieraでパラメタを管理、全台共通のパラメタと個別ノードのパラメタが区別して管理する
      ~~~~~~~~~~~~~~~~~~~~~~ Module再利用の壁
  • 4.「Puppet Moduleを流通、再利用している」
        Moduleのリポジトリ管理、PuppetマニフェストのUnit testを実施
      ~~~~~~~~~~~~~~~~~~~~~~ 構成情報DB導入の壁
  • 5.「Puppetを直観に合う最適な粒度で管理している」
        Role-Profileモデルで構成、ソフトウェアスタック図と1対1対応する
        (サーバ種別=Role、ソフト=Profile)

これに対する意見:。

  • Puppetに異存せず、ChefやAnsibleなど他のツールにも適用できるように、ツールに依存した記述はしないほうが良い
  • CMMIは汎用性が高いので、CMMIのレベルの定義に合う形で記述したほうが良い(これはいわれたのではなく、改めて見たときの自分の意見)

いずれももっともな気がするので、考えて行きたいです。


2013-08-21

_ Puppetのパラメタ名、変数名など命名規則案が参考になる

Puppetで再利用性の高いモジュールを作ろうとすると、 多数のパラメタを準備して柔軟性を確保することになります。 そうすると、多数のパラメタ名が必要になってくるのですが、 名前の決め方がバラバラだと、他人が見たときに何のパラメタなのか 分かりづらくなります。

Puppet Userメーリングリストで、命名規則の案が投稿されていました。 Modules Naming Standards

数多くのPuppet Moduleを公開していて、Puppet Userメーリングリストでも活躍している Alessandro Franceschi氏(Lab42, Example42)が作成しています。

いざPuppetのModuleを作成するとなると、 確かにパラメタ名をどうつけるか迷います。 クラス名は、対象のソフト名や設定ファイル名から決まってくるのでそれほど迷いませんが、 パラメタ名は自由度が高いので迷います。特に、他人に使ってもらうことを考えるとなおさらです。

個人的に迷ったのは、各種ディレクトリ名、ファイル名を示す パラメタ名をどうするか、でした。例えば、命名規則の中で気になるのはこれです。

  • file_template テンプレートのファイル名(ファイル名のみ?フルパス?))
  • file 設置先のファイル名(ファイル名のみ?フルパス?)

まだこの命名規則では曖昧で、 フルパスか、ファイル名だけか、ディレクトリ名フルパスか、単体のディレクトリ名か、等が 迷うことなく同じ名前で決められると、誤解がなくとてもよいです。 具体的には、/etc/apache2/httpd.conf、httpd.conf、/etc/apache2、apache2の 区別がつくパラメタ名が命名規約でみんなで共有できているとうれしい。


2013-08-08

_ PuppetlabsにModule Teamができたので、Puppet Forgeのモジュールの改善が進みそう

Puppetlabs内にModule Teamができて、Puppet Forge内のPuppetlabsが作成しているモジュールの 開発を加速するとのこと。 Pupet Userメーリングリストの記事:

メーリングリストの投稿では、以下のモジュールの名前があがっていました。

  • puppetlabs/mysql
  • puppetlabs/apt
  • puppetlabs/apache
  • puppetlabs/ntp/
  • puppetlabs/firewall

PostgreSQLのようにPuppetDBで使うからという理由で盛んに開発しているモジュールもあれば、 放置状態でPull Requestがたまっているモジュールもあるみたいなので、 ここで力を入れて取り組むようです。単に作るのではなく、 ドキュメント、テストもちゃんと入れて、コミュニティとの対話を重視するとのこと。

今までのPuppet Forgeのモジュールは正直言ってあまり使えない印象でした。 品質レベルがばらばらですし、設計方針もばらばら、 同じApacheでもいろんな人が似てことなるモジュールを作っていたり、 数だけ多いが再利用を意識していないオレオレモジュールが多かったです。 ここで、多くの人が使いそうなモジュールをPuppetlabsが主導で品質をあげて、 再利用できるようにしてモジュールの分断化を防げるのであれば、 とても素晴らしいことだと思います。 新しいモジュールを作るときもお手本になるので、全体的な底上げになると思います。


2013-08-07

_ PuppetマニフェストIDE(Eclipse Plug-in)のGeppettoを作っているCloudsmithをPuppetlabsが買収した

Puppet Enterprise3.0の話と同じく、発表から1ヶ月近く経ってしまいましたが、紹介です。 PuppetマニフェストのIDEでGeppettoと言うツール(Eclipse Plug-in)があります。 Geppettoページhttp://cloudsmith.github.io/geppetto/

このツールを作っていたCloudsmithと言う会社を、Puppetlabsが買収しました。 Blogでのアナウンス: Cloudsmith Joins Puppet Labs プレスリリース: Puppet Labs Acquires Cloudsmith

私は普通のテキストエディタで編集しているだけで、Geppettoは使ったことがないです。 他人にPuppetマニフェストを書いてもらう場合は、こういう環境があるととっつきやすくなるのは良さそうですね。 今度試してみたい。


2013-08-06

_ Puppet Enterprise 3.0が出た

オープンソース版のPuppet3が出てから半年以上かかりましたが、 商用版のPuppet Enterprise 3.0がでました。 出てから1ヶ月以上たってしまいましたが紹介します。

Announcing Puppet Enterprise 3.0

この紹介blog記事だとマーケティング色が強すぎて何ができるようになったか分かりづらいのですが、 中身のPuppet本体がPuppet2.7からPuppet3.0になったことが一番です。

こんなことを書きつつ、Puppet Enterpriseは一度も使っていないのでした。 1ノード$100くらいでそんなに高くないので、使う機会を探ってます。


2013-04-16

_ Chef Casual Talks Vol.1でPuppetの話をしてきた

ChefのイベントChef Casual Talks Vol.1でPuppetの話をしてきました。

発表したスライドはこちら

以下、感想です。

  • Chefを使い込んでいる人と、「入門Chef Solo」を読んで始めたばかりの人が半分づつくらい。
  • Vagrantで開発に使っている人が多い。自分のMacでVagrantという人がすごく多かった。本番適用は人数が少なめ。
  • Puppetを使っている会社はそれなりにある模様。
  • アプリのデブロイにchef使うべきか?とかPuppetと悩みは同じでした。

2013-03-07 Puppetモジュール書き方のBest Practiceは意外と知られていないので紹介する

_ Puppetモジュール書き方のBest Practiceは意外と知られていないので紹介する

Puppetを使い始めた時に困るのが、どのようにManifestを書くべきなのか、指針がなにもないことです。 雑誌の記事や、Webで紹介しているページでも、site.ppに直接リソースを書いてしまうような、 あくまでHallo World的な単純な例しかありませんでした。

Puppet Usersメーリングリストや、Puppet Forgetのモジュールの例、Puppetlabsの資料を色々見つつ、 手元で試していくと、だんだん書き方が分かってきました。 微妙なのが、色々見ているうちに何となくコミュニティでの傾向が分かってきただけで、 決定版になるようなページがないところです。

せっかくなので、過去を思い出しながら、参考にしたページを書いておきます。 まずはPuppetlabs公式ページにあるものから。 こうやって振り返ってみても、あらためてまとまって書いてあるページは少ないですねえ。 よくこれで使っているものだ。

  • Style Guide
    いわゆるコーディング規則です。 コメントの書き方、クォーテーションの書き方など良くある字句レベルでの決まりがかいてありますが、 後半のclass関係になると、設計レベルの話も入っていて参考になります。 ぜひ、ルール一つ一つちゃんと読むことをおすすめします。
  • Module Fundamentals
    Puppetの再利用の単位であるmoduleの基本的な考え方を説明してあります。 個人的には最重要な情報です。モジュール名、クラス名、テンプレート名の、 使う側での名前と実際のディレクトリ配置の対応が書いてあります。 以前はこの情報がまとまっていなくて、期待するclassが読めない、 テンプレートが読めない、というミスに苦しんだこともありました。 Puppet使う人は必ず読んだほうが良いです。
  • Writing Great Modules: An Introduction
    Puppetlabsのブログ記事です。主に、Puppet Forgeに登録するような汎用性の高く十分テストされた モジュールの作り方です。記事の中で作り方を説明しているというよりは、 他のドキュメントを紹介しているような形です。

その他、module内のクラス構成を

  • modulename::init
  • modulename::install
  • modulename::config_xxx (xxxは設定ファイル名)
  • modulename::service

にしろ、という話はどこかの資料で見た記憶があるのですが……、思い出せませんでした。 もしかしたら、Puppet Forgeのモジュールを色々見ているうちに 標準構成が分かってきただけだったかもしれません。これはまた後日。