log.fstn

技術よりなことをざっくばらんにアウトプットします。

Itamae Meetup #1 に参加してきた

概要

f:id:foostan:20151211161145p:plain

↑ ついにロゴができた。

connpass: http://itamae.connpass.com/event/22857/

開催概要

OSSの構成管理ツールであるItamaeのミートアップです。日頃お使いいただいているユーザの方々にいろいろ発表してもらいます。

日時: 12/9（水） 19時10分開場　19時30分開始 場所: クックパッド株式会社（地図） 東京都渋谷区恵比寿4-20-3 恵比寿ガーデンプレイスタワー12F 受付にて受付番号をお伝え下さい 軽食と飲み物を用意する予定です。

タイムテーブル

19:30-19:50 @ryot_a_rai オープニング 19:50-20:10 @sonots 「ぼくのかんがえた Itamae/Serverspec 構成フレームワーク 〜 板前の献立 〜」 20:10-20:30 @toritori0318 「Chef-soloからItamaeに完全移行した話＋」 20:30-20:40 休憩 20:40-20:50 @sugamasao 構成管理ツールを渡り歩いてItamaeに辿り着いた話 20:50-21:00 @hfm 「構成管理ツールとWebオペレーション研修」 21:00-21:10 @rrreeeyyy 「MSPでのItamae利用事例」 21:10-21:20 @k0kubun 「Itamaeを楽しく使うための工夫」 LT

21:20-21:25 @nobu666 「Itamaeで幸せになった話」 21:25-21:30 @sue445 「社内Itamaeプラグインとか作ってる話」 21:30-21:35 @chiastolite 「vagrant-itamae」 （順番は変更される可能性があります / タイトルは追って更新されます）

@ryot_a_rai オープニング

🍣 と 🍺 は自由におとりください

  • 元々 light-chef というレポジトリ名で、コンセプトは名の通り軽量のChef(Chefのcookbookの機能だけを取り出したようなもの)
  • Specinfraを内部で利用している(Serverspecと共通)
  • Ansibleのようにリモートに対してsshで実行することが可能(ク社ではレシピをtarballにしてS3にアップして、各ホストでpullしてローカル実行)
  • 便利オプション？
    • --recipe-graphオプション: 依存関係を可視化(dot形式出力)
    • --profileオプション: 実行したコマンド毎にかかった時間を出力
  • omnibus-itamae: ruby本体を含めて rpm/deb でパッケージングしたもの
  • Itamae Server: itamaeを実行したりログをためておくサーバ(Chef Serverとはコンセプトが全然ちがう）

@sonots 「ぼくのかんがえた Itamae/Serverspec 構成フレームワーク 〜 板前の献立 〜」

  • kondate
    • https://github.com/sonots/kondate
    • itamae/serverspec の薄いラッパー
    • ディレクトリ構成を整えたり、直感的に itamae/serverspec を実行できる環境を用意する

@toritori0318 「Chef-soloからItamaeに完全移行した話＋」

  • 前半はよくあるChefのつらいはなし
  • Chefのディレクトリ構造からはなるべく変えずにitamaeに以降
  • 機密情報は itamae-secrets を利用(https://github.com/sorah/itamae-secrets)
  • itamaeの実行はconsul watchでやっていく予定

@sugamasao 構成管理ツールを渡り歩いてItamaeに辿り着いた話

todo: スライド公開されたら追加

  • fabric -> chef -> itamae の順に渡り歩いてきた

@hfm 「構成管理ツールとWebオペレーション研修」

  • プロビジョニングの研修にitamaeを使った話
  • 研修のように日程がキツキツの場合、シンプルなitamaeは適している
  • このスライド、プロビジョニングのこと綺麗にまとめられていて個人的にオススメ

@rrreeeyyy 「MSPでのItamae利用事例」

※ スライドは多分公開しないということ

  • Ansibleしんどい -> itamae
    • Ansible
      • 覚えることが結構ある
      • 失敗したら実行する系が綺麗にかけない
      • 便利なモジュールはいっぱいある
  • 既存の技術の組み合わせで扱いやすい
    • thor
    • specinfra
  • in MSP
    • お客さんのサーバにむやみにファイルを置けない
    • リモートで実行できるAnsible(Itamae)が推奨されている
    • Serverspec必須
      • Itamae(ssh)と同時に使いやすい
  • シンプル(暗黙のルールがないから)だから rake ファイルを作りやすい
  • もう少しプラグインが増えるといいな

@k0kubun 「Itamaeを楽しく使うための工夫」

  • itamae のコマンドを高速した話

@nobu666 「Itamaeで幸せになった話」

  • よくあるChefのつらい話 -> itamae
    • 知り合いが作者だから何かあったときにゴリ押しできるんじゃないか、という観点で乗り換え(多分半分本気)
    • ほぼすべて itamae に移行済み

@sue445 「社内Itamaeプラグインとか作ってる話」

https://sue445.github.io/itamae-meetup-01/#/

@chiastolite 「vagrant-itamae」

  • vagrantのitamaeプロビジョナーを作った話
  • vagrant-itamae の余命は短い

所感

  • みんなChefなりAnsibleに疲れている
    • chef-soloを使い続けている方もいて
      • chefの周辺ツールは一切使ってなくて、chef-solo + stretcher で実行していて構成はかなりシンプルになっている
      • Chefで疲れるのは、コミュニティクックブック使ったり、Berkshelf使ったりし始めるあたりから、という話をした
    • Ansibleつらい話は、"ymalでプログラミングするな" ってことをだいたい共通認識として持っていた
      • 弊社はAnsibleに移行して間もないので、itamaeにするか！とはなかなかならないだろうけど、選択肢の一つとして考えるのはありなのかと
      • RubyのDSLで書ける利点とかかなりあって、確かにyamlでガリガリ条件書くのはつらいよなーっと
  • プロビジョニングツールは基本何を使ってもいいんだけど、大事なのは結果だから、Serverspecしっかりしてればいいよね、って話をした
    • 全くもってそのとおりなのでServerspecはちゃんと整備していきたいところ