dwango エンジニア ブロマガ

こんにちは！
先月ドワンゴは歌舞伎座に引っ越したので"銀座"にあうように人生初の美容院に行ったけど、結果は床屋で切ったのと変わりなかった氏家です。

前回はChefとはなんぞや、というところで終わってしまいましたが、今回は導入編で、

- 最新のChef Solo 11.6.0、Knife Solo 0.3.0 限定
- 導入から実行するまでの、迷わない セットアップ手順 及びファイル構造の新定番！

を提案したいと思います。

それは、私がChef Soloを導入しようとしたときに引っかかった

• インストールして使い始めるまでのとっつきにくさ
• 開発環境と本番環境をどうCookbookで表せばいいのか
• 用途の違う複数のサーバーや、複数のプロジェクトを、どう管理するのがよいか
• 開発メンバーにも秘密にしたい秘匿情報は…

といった問題をどう解決したか、そして少しでもChef導入の手助けになればと思っています。

※素のOSにChefを導入する前提の話になります。Vagrantとの連携前提の話については割愛させてください。

おさらいですが、Chef ServerとChef Solo・Knife Soloの違いを図にしてみたいと思います。

Chef Serverの場合は、セットアップするサーバーの情報をChef Serverに登録、Chef Client側で通信先のChef Serverを登録しておいて"chef-client"を実行


Chef Soloは、サーバーの情報もすべてファイルとして保存しておき、Cookbook含めそれらのファイルをセットアップサーバーにコピーして、セットアップサーバーにSSHでログインして"chef-solo"を実行


Knife Soloを使うと、上記Chef Solo実行時に手動で行ったファイルコピーをすべて代わりにやってくれるので、SSHでログインすることなく"chef-solo"が実行される

Chef Serverはセットアップ情報をChef Server自身が管理しますが、Chef Soloの場合はセットアップ情報はファイルとして管理するので、それをgit管理しておくこともできます。
開発者目線で考えると、gitで情報を管理できるしChef Serverをインストールする必要もないChef Soloの方が扱いやすいかと思います。

さて、本題です。

Chefを解説しているホームページを見ていると、いろんな人がいろんなやり方でChefを実行するためのインストール手順をまとめてくれています。が、情報が古い、Chef Serverの手順だった、Knife Soloを使ってないという要因で、手順が人によっていろいろ異なっています。

また、Chefはruby上で実行されますが、rubyは既にインストール済みの前提で、手順は省かれてる場合も多いように見受けられます。

そこで、rubyも入ってない素のOS上から、実際にKnife Soloを使うまでの手順を、最新のChef Solo 11.6.0、Knife Solo 0.3.0 にて解説していきます。

「これを見れば誰でもChefを始めることができる！」

※Chef自体はrubyが入ってればどの環境でも動きますが、WindowsでCygwinにて動かそうとすると、現状ではCygwinのrubyのパフォーマンスが悪いせいか他の環境に比べ実行時間が多めにかかります。ご注意ください。

Knife Soloを実行する作業マシン

• ruby（chefを実行するために必要）
• rubygems（knife soloをインストールするために必要）
• Chef Solo
• Knife Solo

Chef Soloが実行される、セットアップされるサーバー

• ruby（chefを実行するために必要）
• Chef Solo

意外と盲点なのは、セットアップ対象先のサーバーにはKnife Soloは必要ないことです。なるべく不要なものは入れないようにしましょう。

1. curl -L https://www.opscode.com/chef/install.sh | bash
2. /opt/chef/embedded/bin/gem install knife-solo --no-ri --no-rdoc

これだけです。

1. で行ってるのは、chefの公式サイトからrpmやdebといったChef Soloのパッケージをダウンロードしてインストールしています。そしてここ重要な点ですが、このパッケージの中にはrubyも含まれています。

元からrubyがインストールされてたり、yumでインストールするように書かれてるサイトもありますが、現在のChef Soloはruby1.9.2以降でないと一部正しく動作しません。
（特にRedhat系の場合、yumでインストールされるrubyは現状1.8系）

また、rubyを使ったプログラムを同じサーバーで動かす場合、バージョン依存によるしがらみが発生してしまうかもしれません。

そのため現状のChef Soloのインストールは、rubyを含むパッケージでインストールするのがお薦めです。Chef用のrubyと、通常のパッケージで入れたruby共存することも可能です。

そして2. でKnife Soloを、rubyのgemにてインストールしています。（現状Knife Soloのパッケージはないため）ここで気をつけなければいけないのは、1.でインストールされたruby配下（/opt/chef/embedded/）のgemにてインストールを実行することです。

1. ※Knife Soloをインストールした作業マシン上で
   knife solo prepare root@[セットアップ先サーバーのIPアドレス]

これだけです。
これならインストールは簡単ですね。ただこれはセットアップ先のサーバーにてインターネットにつないでChef Soloのパッケージをダウンロード・インストールしています。そのため対象のサーバーがインターネットに繋がってないとエラーになってしまう欠点があります。（本番のDBサーバーだと外と疎通できないこともよくあります）

その場合は下記のページよりパッケージをダウンロードし、対象のサーバーに手動で転送してインストールすることでChef Soloがインストールできます。
http://www.opscode.com/chef/install/
※このパッケージもrubyが同梱されています

さて「いざ始めてみようか」となると、まずはChefを実行するためのベースとなるディレクトリを、Knife Soloコマンドを使ってひな形から作成することになります。
作業マシン上で、Cookbook等を作るディレクトリを決めて、そのディレクトリの中で
knife solo init [リポジトリ名]
と打つと、基本となるディレクトリが自動的に作られます。

[リポジトリ名]/
    cookbooks/      ※セットアップ手順などを書いたレシピ(recipe)はこの中に入ります
    data_bags/      ※主にパスワード情報などを保存しておく場所
    nodes/          ※Chefを実行するサーバーの情報はここに書いておきます
    roles/          ※役割（Webサーバー、DBサーバーなど）ごとの定義を書きます
    site-cookbooks/ ※特定のサイトに依存するcookbookはこちらの方に入れます

（注）上記コマンドはやってるのはあくまでひな形を元にディレクトリを作ってるだけなので、例えばgitにひな形を登録して 初回時pullするって運用でいくのであれば、上記コマンドを実行する必要ありません。

基本は上記のディレクトリ構成のままで構わないのですが、（最初始めたばかりだとそこまで気にしませんが）、Chef Soloはセットアップ手順やサーバーの情報含め、全てをテキストファイルで管理するので、どこにどういったファイルを置くかのディレクトリ配置が重要です。
ここをおざなりにすると後で管理が複雑でめんどくさくなってきます。

なぜ複雑になってしまうか。冒頭でも少し書きましたが、

• 開発環境と本番環境の設定をどう区分けしたらいいのか
• WebサーバーとDBサーバーで用途は違うけど共通の設定もある。どうしよう
• AプロジェクトとBプロジェクトどっちも並行でやることになった。
  A用Cookbook、B用Cookbookというように分けるべきか。
  でもそうするとほぼ同じCookbookが複数できてしまう

といった問題が、後々になって気づいて出てくるんです。はい。

そこで上記の問題を解決する、私の考えた、現状おすすめな構成がこれです！

cookbooks/
    プロジェクト共通のcookbook各種
Aプロジェクト/
    .chef/knife.rb
    data_bags/
    nodes/
        192.168.1.1.json
        192.168.1.2.json
    roles/
        common.rb
        web.rb
        db.rb
        _dev.rb
        _production.rb
    site-cookbooks/
        プロジェクト固有のcookbook各種
Bプロジェクト/
    ....

cookbooksディレクトリに入れるCookbookは、特定のプロジェクトに依存しない汎用的に書かれたものだけを置きます。
逆に特定のプロジェクトに依存するものはsite-cookbooksに入れます。そうすることで複数のプロジェクトでCookbookを共有してくことも可能になります。

そして例えば次のようなこともできます。

cookbooks/
    apache/
        recipe/
            default.rb
        template/
            default/
                httpd.conf.erb
Aプロジェクト
    site-cookbooks/
        apache/
            template/
                default/
                    httpd.conf.erb  ※こちらが優先される

この場合、cookbookのレシピは共通のものを使用するけど、httpd.confのテンプレートはAプロジェクトの方を参照します。

このような構成を可能にするためには、「.chef/knife.rb」の中で
cookbook_path ["cookbooks", "site-cookbooks"]
　を
cookbook_path ["../cookbooks", "site-cookbooks"]
のように書き換えることで対応できます。

サーバー構築する際は大概、WebサーバーとDBサーバーは構築するかと思います。
Webサーバー・DBサーバー共通のセットアップをする場合があれば、それぞれ個別のセットアップをする場合もあります。それらを定義できるのがRoleです。

私の場合は、"common.rb"、"web.rb"、"db.rb"というように定義を分け、Webサーバーでは"common.rb"と"web.rb"を、DBサーバーは"common.rb"と"db.rb"を参照するようにしています。

開発環境と本番環境で設定を分けたい場合どうするか。
Chef ServerではEnvironmentという概念があって、開発用・本番用の設定をそこに定義することが出来ます。
しかし残念ながら Chef Solo 11.6.0、Knife Solo 0.3.0では 一部Environmentの機能に対応したものの、実践で使うにはまだ機能が十分ではありません。

そのため私はRoleを使って便宜上Environmentと同様の定義をしています。

ちょっとだけChefをHackしてるので複雑そうに見えますが、結果はシンプルです。先のRoleの話も含め、実際に書いてることをリストアップします。

● nodes/192.168.1.1.json （dev用サーバーとする場合）
"run_list":[
    "role[web]"
],
"chef_environment": "_dev"  ※この書き方はChef 11.8でサポートされそうで、それを先取りしています

● roles/web.rb
#nodes/*.jsonで定義されてる”chef_environment”の値を取得する
@environment = "_default"
node_index = ARGV.index('-j') 
if node_index
    require 'json'
    node_json = JSON.parse(File.read(ARGV[node_index+1]))
    if node_json["chef_environment"]
        @environment = node_json["chef_environment"]
    end
end
#共通の設定、dev用設定を記述
env_run_lists = {}
env_run_lists["_default"] = [
    "role[common]",   ※web,db共通のセットアップ・設定
    "recipe[apache]", ※web.rbなのでapacheをインストール
]
env_run_lists["_dev"] = env_run_lists['_default'] + [
    "role[_dev]"      ※dev環境用の設定roleを読み込み
]
default_attributes(
    "apache" => {
        "port" => "443"
    }
)
run_list(env_run_lists[@environment])

● roles/common.rb
run_list([
    "recipe[共通で実行するレシピ]"
])
default_attributes(
    "apache" => {
        "server_name" => "www.example.com"
        "port" => "80"
    }
)

● roles/_dev.rb
default_attributes(
    "apache" => {
        "server_name" => "www.dev.example.com"
    }
)

ミソはweb.rbで nodeのjsonファイルを直接開いて、chef_environmentの値を取得してることですね。
上記のようにroleを分けることで、

• 共通で実行するレシピと Web,DBといった用途ごと
• 開発と本番

で

• 実行するレシピ
• 設定値

を分離することが出来ます。

---

Chef Serverの場合はAプロジェクト・BプロジェクトごとにChef Serverを立てることが多いでしょうが、Chef Soloの場合はこのようにうまくディレクトリ構成を工夫することで、複数プロジェクト分をまとめて管理でき、テキストファイル＝gitに登録できるメリットもあります。
こうしてみると開発者はもちろん、インフラ構築者でも意外とChef Solo使えるのではないでしょうか。（もちろんChef Serverにもメリットはたくさんあるので用途に応じて使い分けるのがよさそうですね）

そして今回でも書ききれないことが出てしまったので、また次に回したいと思います。

• 本番環境のようにインターネットにつながらない環境下前提のレシピの書き方
• attributeの書き方及びはまりどころ

是非楽しみにしていてください。

そしてドワンゴでは、現在エンジニアを積極的に採用中です。 特に、このような環境構築自動化のノウハウを持ったインフラエンジニアは大歓迎です。 ご興味がある方は是非コチラからご応募ください！ニコニコ入社一時金制度もやっています。

（補足）
本文中で「サーバー」に「セットアップ」という用語を多用してますが、Cookbookのレシピを実行することは正確には「セットアップ」ではなく、ノード（サーバー）をあるべき姿に「収束(converge)させる」こと（何度実行しても同じ結果（サーバー状態）になること）になります。

こんにちは！
先月ドワンゴは歌舞伎座に引っ越しましたが、
"銀座"に着てく服がなくて毎日困ってる氏家と申します。

インフラエンジニアとしては新参者になるのですが、よろしくお願いいたします。

ドワンゴの中ではniconico系の事業を担当しているのですが、
2006年にニコニコ動画がスタートしてもう少しで7年になろうとしています。
昔からあるシステムはサーバー構築手順も確立されてるのですが、
新しめのプロジェクトではChefを導入してサーバー構築をしようとしています。

先日の参院選で、ニコ動アンケートが97.52%の的中率というニュースをご覧になられた
方もいるかと思いますが、あのアンケートシステムもChef Soloを使って構築しました。
大規模なシステムはChef Serverで構築してるところもあるのですが、
今回私が解説するのは、比較的小規模な構築に向いているChef Soloの話になります。

「Chefってサーバー構築を自動化できるんだー、やってみようかなー」
なんとなく興味をもって、とりあえずWebで軽く調べてみると、
「Chef ServerとSoloがあって、Serverはサーバーソフトウェアをインストールするんだ」
「Serverはめんどくさそうだな。Chef Soloでやってみようか。よしググってみよう」
そうしてググってみると…

・Chef Serverの話でした
　※『Chefです』「よし通れ」『残念、Chef Serverちゃんでした』
・Chef Soloで作りますよ
　※「うん、これこれ」
・Knife Soloを使うと便利だよー
　※「えっ、Chef Soloよりこっちがいいの？」
・よく見ると2011年ころの記事だった
　※「えー、この情報は古いの？？」
・人によって書き方に違いがある…
　※「昔新聞で７つの間違い探しやったなー（遠い目」
・くぁwせdrftgyふじこlp

※Webから情報を集めるのは大変ですが、今だと伊藤直也さんの書かれた「入門Chef Solo」がわかりやすくまとめられてるかと思うので、一読されるとよいかと思います。

●Chef？　bashスクリプト？　手作業？
え、Chefの話をしてるのにそこから？って感じですが、
やはり手作業での構築と比べたら、ミスが少なく速度も100倍くらい速いです。

手順をbashスクリプト化してる場合との比較だと、
・"レシピ"という共通な言語による可読性の高さ
・"レシピ"を何回実行してもエラーにならず、実行後のサーバーは同じ状態になる
というところが利点です。

●Chef Server？　Chef Solo？
下記の理由に当てはまるならChef Soloがよいかと思います。
・開発者
・Vagrantと組み合わせる
・導入するサーバーが数台程度
・Chef Serverをインストールしておけるサーバーが無い

●Chef Solo？　Knife Solo？
Chef Soloだと、cookbookファイルを置いたサーバーに対してセットアップが実行されます。

ただそれだと、別のサーバーにセットアップをしたい場合、
　cookbookファイル一式を手動で転送　→　別サーバーにログインしてChef Soloを実行
する必要があります。

上記作業を自動でやってくれるのがKnife Soloで、Chef Soloを便利に使えるようにするツールです。

少し長くなりそうなので、詳しくは次回に、とりあえず数台程度、お手軽にサーバー構築自動化を始めたい、という目的で、"Chef Solo 11.6.0" with "Knife Solo 0.3.0" での構築のテクニックを説明いたします。

・Chef Soloをゼロからインストールして実行するまでの省略無しの手順
・複数のプロジェクトを管理していくための提案
・Chef Soloで環境（開発・本番）、用途（Web・Manage）を使い分けるコツ
・外部疎通ができない環境での実行でのレシピの書き方

などを予定しています。ご期待ください！

そしてドワンゴでは、現在エンジニアを積極的に採用中です。 特に、このような環境構築自動化のノウハウを持ったインフラエンジニアは大歓迎です。 ご興味がある方は是非コチラからご応募ください！ニコニコ入社一時金制度もやっています。

ドワンゴでエンジニアの教育を担当している清水(@meso)です。
去る7/1に、ドワンゴ, ドワンゴモバイル, キテラスのドワンゴグループ3社のエンジニアが集まってのイベントを行いましたのでその様子をご報告いたします。

イベント概要

ドワンゴでは、毎年「エンジニア決起集会」と題したイベントを行なって参りました。エンジニアが一同に集まって、「よりよいサービスを作りだしていくぞ！」という思いを一丸にするという、まあ簡単に言うと飲み会なのですが、今年はより「エンジニア」っぽいイベントをしたいということで、半日使っての「ハッカソン」も行いました。

上述したドワンゴグループ3社のエンジニアを合わせると300人を超えるため、その人数が入れる会場を手配するのはもちろん、全員がノートPCを持ち込んで使えるように会場の電源を強化したり、全員が同時にネットワークを使えるように無線LAN環境を整備したりしました。

ハッカソンのテーマは「Dwango Readerを作るとしたら」です。当日が「Google Reader」のサービス終了日であったため、社内にフィードリーダーを立てれば「社内でもっとも購読されているフィードランキング」や「今日社員が最もはてブした記事ランキング」などを共有することで社内の情報共有がより促進されるのではないか、ということを狙ったテーマでした。

もちろん他に作りたいものがあるという方は自由に作ってもいいという緩いルールです。が、今回はひとつだけ制約を設けました。それは、「普段、業務で使っていない環境（言語/フレームワーク/プラットフォーム）で開発すること」です。例えば

• Scala / Play2
• Haskell / yesod
• Go / Revel
• Ruby / Rails
• PHP / Laravel
• Java(JVM) / Vert.x
• JavaScript(Node) / Express

などにチャレンジすることを推奨しました。

当日の様子

当日は、環境ごとに席を大まかに分けて着席していただきました。ほぼ300人近い方に参加していただき、14時半から19時半の5時間に渡って本部長から新入社員までが肩を揃えて黙々と開発をするという、とても異様な……でも素敵な空間でした。


中には、Oculus Riftを持ち込んで何か作ってる人も数名いましたし、フィードの内容を物理的にテープで吐き出すシステムを作ってる人もいました。

19時半になるとハッカソンは終了し、エンジニア決起集会へと移行しました。エンジニアの新入社員による自己紹介とチーム開発研修の結果発表を行い、ハッカソンの成果をLTで発表してもらいました。大量のビールとピザ、KFCのチキンを用意して大いに飲んで食べてもらいました。

このあとスタッフが美味しくいただきました。

何故こんなイベントをするのか

と、問われることがよくあります。それはやはり、「プログラミングの楽しさを忘れないでいて欲しいから」です。日々エンジニアとして働いていると、プログラミングをしていて辛さを感じてしまうということがどうしてもあります。「プログラミングは好きだけど、仕事としてするのは辛い」という思いを抱きながら開発をしているエンジニアは実は多いのではないでしょうか。

それは仕方のない面もあるかもしれません。でも僕は、ドワンゴのエンジニアには可能な限りそのような思いを抱いて欲しくないのです。「プログラミングって楽しい」「何かを開発するのって面白い」という、初めてプログラミングに触れたときに感じた思いを抱き続けて欲しい。そういう思いでイベントを開催しています。

最後に

そんなドワンゴでは、現在エンジニアを積極的に採用中です。ご興味がある方は是非コチラからご応募ください！ニコニコ入社一時金制度もやっています。

また、2015年卒業予定の学生向けインターンの参加者も募集中です。是非ご応募ください！