プロビジョニングツールと Itamae についての雑感

公開日: カテゴリー: infrastructure タグ: 、、、
プロビジョニングツールと Itamae についての雑感

プロビジョニングツール、あるいは Infrastructure as Code には興味がありつつ、これまでは

  • サーバは既に自分以外の誰かが構築済み(もしくは構築担当)
  • 自分はそのサーバで動く Web アプリの開発と、それに関わるミドルウエアの設定・チューニング

というケースが仕事で多かったので、仕事としてはあまりインフラ回りを担当したことがなかったのですが、最近ちょくちょくとインフラ回りを触る機会が増えてるので「これはきっとプロビジョニングツールとか Infrastructure as Code とかにチャレンジする機会っ!!」と思って少々勉強中です。

今回のひとまずの目標は

  1. 開発環境に Vagrant を利用するので、その開発環境を構築する
  2. 開発環境を構築した際のコードが本番環境の構築に再利用できる(と良いな)

辺りに設定してみます。

Itamae

プロビジョニングツールについては今のところ、インフラ構築がコード化されるとはどういうことか?というところに主眼をおいてるので、

  • 手軽であること
  • ドキュメントが困らない程度にあること(日本語ならなお嬉しい)
  • 困ったらソースを追えること

という点を重視してみました。

ansible でも良いかな?と思ったんですけど、何をやってるか追いたい時に個人的には Ruby の方が助かるので、今回は Itamae を試してみました。クックパッド株式会社のエンジニアが作っていることもあって、日本語のドキュメントが多いこともありますし。

Itamae については Qiita にドキュメントが揃っていて、そのほとんどが2015年の記事なんですが、現在の最新バージョンでもその知見を活かせます。初学からひとまずやりたいことを一通りレシピにまとめるところまでなら、

この辺りが特に参考になるでしょう。あと、英語なのですが GitHub の Wiki に重宝する情報が多くて、これのおかげでコードを追わなくても済んだ場面もままあったり。あと、ある程度まとまったレシピファイルを作る予定なら Best Practice には目を通しておくと良さそうです。

Itamae の雑感

Ruby でプロビジョニングツールと言えば Chef ですが、クックパッドのサーバプロビジョニング事情 – クックパッド開発者ブログ の冒頭、

Puppet, Chef, Ansible, SaltStack を検討した結果、

  • 言語特性の観点では、Ruby DSL な Chef が良い
  • アーキテクチャ・エコシステムの観点では、シンプルな Ansible が良い

といった点から、どれも決め手に欠ける状況で、Ruby DSL で記述できるシンプルなプロビジョニングツールが必要とされていました。
そこで、以前から筆者が細々と開発していたItamae（当時は Lightchef と呼んでいました）が採用され、開発が進められました。

とあるように、Chef ライクだけどシンプルでとても使いやすいツールです。実際にあれこれ記述し始めると細かい部分の書き方が分からなくて調べることになるのですが、Itamae の概要をざっと知るだけならば、先の Itamae – Infra as Code 現状確認会 // Speaker Deck だけで事足りるでしょう。

逆に、日本語のドキュメントが多いと書きましたが、いわば「使ってみた」系のドキュメント比重が多いので、細かい部分で調べてもなかなか見つからない、ということも少なくありません。

例えば、template resource で変数を代入するケースですが、複数の変数を代入する場合

まずはテンプレート
# template.erb
<%= @greeting %>;, <%= @message %>
次にレシピファイル
# recipe
template "/path/to/dest" do
  action :create<br>  source "template.erb"
  variables(greeting: "Hello", message: "World")
end

と variables に引数を続けていくのが正しいのですが、

# この記述は間違いです
variables(greeting: "Hello")
variables(message: "World")

としがちで、しかもエラーもなくそのまま実行できてしまうんですよね。ほかにも directory resource で「すでに存在するディレクトリのパーミッションだけ変更したい」という時にどうするの?とか、気になりだすとすごく気になることが多いという印象も抱きました。

まとめ

前述通り、Itamae は「使ってみた」系のドキュメント比重が多いので、細かい部分で調べてもなかなか見つからないことも少なくないので、慣れないうちは TRY & ERROR で実際に挙動を確かめてみたりコードを読んだりする機会も多いのですが、Itamae 自体がシンプルなので、その点は(その時々は面倒に感じますが)それほど困らないと思います。

今回は Itamae を試してみましたが、ツールが何かに関わらずサーバ設定をコード化できるというのは、色々メリットが大きいという点を今回は実感できました。

  1. サーバ構築がレシピファイルという形で明文化される
  2. そのレシピファイルが実行可能なので、同じ環境がコマンド一つで再現できる
  3. サーバ設定を変更した場合、Git などバージョン管理システムで履歴管理ができる

ひとまず試しに導入してみた、という段階でもこの程度のメリットはすぐに実感できるのではないでしょうか。

今回は開発環境を構築した際のコードが本番環境の構築に再利用できる(と良いな)も目標としていましたが、この点については利用する想定がはっきりしてないと中途半端なサーバセッティングになりやすいので、実際に利用するプロビジョニング・ツールでできること/できないことの把握や、どの範囲をプロビジョニング・ツールで賄うのか?は事前に検討しておいた方が良いでしょう。

今回は開発環境が Vagrant で、本番環境は VPS だったのですが、Vagrant は最初から vagrant ユーザが存在してるので、いざ本番環境を構築しようとした際に「そういえば通常アカウントの作成は手動でやるべき? レシピを作るべき?」とか、開発環境と本番環境で違う設定が必要な場合に「このまま実行したら開発環境と同じ設定になってまずいなぁ……」とか起こりがちですｗ

とはいえ、この辺は利用機会が増えると見極めができるようになっていくでしょうから、サーバ設定をコード化できるメリットをみんなが享受できるようになると良いなと思います。