Furyu
[フリュー公式]

Tech Blog

フリュー株式会社の技術ブログです

2013年09月11日

kunihira

Packer+Chef-SoloでAMI作り

こんにちは。 自称Chef導入委員長の国平です。
立て続けの投稿になってしまいますが、今回はPackerの紹介記事を書かせて頂きます。

仮想マシンイメージの作成ツールであるPackerがChef-Soloからのマシンイメージ作成に対応しました。 今回は、その機能を利用して、AWSのEC2 AMIを作成してみます。

Packerとは

仮想環境のマシンイメージを作ってくれるツールです。 一つの設定を元に複数のプラットフォームに対してマシンイメージを作成出来ます。 シェルスクリプトやChef-Soloを使ってマシンイメージを構築します。

ChefやAnsibleの様なプロビジョニングフレームワークはマシン環境の構築にとどまらず、EC2の操作などかなり幅広く利用出来ます。反面、それらのツールで実行する役割を増やすほど設定が複雑化してしまいます。しかし、Packerを利用するとマシンイメージの作成をPackerにまかせることができ、ユーザはマシン設定に集中する事が出来ます。

Packerの利点

Packerを利用する事で以下のメリットを得られます。

  • インフラ構築の高速化
  • 複数プロバイダー間の連携
  • テスタビリティの確保

インフラ構築の高速化

Packerを利用する事で、そのマシンイメージの作成コストを下げることができ、マシンイメージを起動するだけで、利用可能な環境を手に入れる事が出来ます。

複数プロバイダー間の連携

PackerはAWS, VirtualBox, VMWareなど複数のプラットフォームに対応しています。Packerの設定一つで、AWSとローカルマシンの両方に同じ設定を行ったマシンイメージを作成する事が出来ます。 それぞれのプラットフォーム間の違いは、Packerが吸収してくれるので、最終的なマシンイメージを統一して用意する事が出来ます。

テスタビリティの確保

Packerを使う事で上記のように複数のプラットフォームにマシンイメージ作成できます。 そのため、一つの環境でテストを行う事で、他の環境が期待される結果になっている事を保証されます。

気に入った機能

個人的に気に入った機能が、fixコマンドです。 Packerがバージョンアップした際に、古いバージョンのJSONを新バージョンに変換してくれます。 変換結果は、標準出力に吐き出されるので、Linuxであれば以下のコマンドで、最新のJSONを取得できます。

一度書いた設定が動くことが保証される、もしくは、容易に動く状態にできるというのは、運用が長期化したり、運用するサーバ設定が複数ある場合に非常に助かると思います。

インストール

UNIX/Linuxでは、~/packerもしくは/usr/local/packerにインストールすることが推奨されています。 インストールするためには、公開されているzipファイルをhttp://www.packer.io/downloads.htmlからダウンロードし、解凍しパスを通します。

Linuxマシンに対してインストールを行うには以下のコマンドを実行します。 ご利用の環境に応じて、適宜ダウンロードURLは変更してください。

正常にインストールが完了し、パスが通っていれば、packerコマンドを実行すると以下のように、表示されます。

Macの場合は、Homebrewを使ったインストールも可能なようです。 詳しくは、公式サイトを参照してください。

とりあえず使ってみる

Packerを使って、NginxをインストールしたAWSのAMIを作成してみます。 まずは、以下のJSONを作成します。

ami-shell.json

builders には、どの様なマシンイメージを作成するかを設定します。 今回はAMIに設定するために typeamazon-ebsにし、resionなどの設定をしています。 access_key, secret_keyは、それぞれAWSアカウントで作成して入力します。

provisioners には、作成するマシンイメージに対して行う処理を設定します。 まずは、Packerの動作を確認するために、typeにshellを指定し、シェルスクリプトを実行してNginxをインストールしてみましょう。

JSONを作成したら以下のコマンドを実行します。

これでAMIの作成が開始されます。 AWSのConsoleから、EC2が起動する事が確認出来ると思います。 EC2が起動すると、provisionersで指定した通りのシェルが実行されます。 yumコマンドが実行されNginxがインストールされると、AMIの作成に入ります。 最終的にAMIが作成されると起動したEC2インスタンスはterminateされます。 ami_nameに指定したように、”Packer-“後にタイムスタンプが追加された名前のAMIが作成されます。

ProvisionarsにChef-Soloを利用する

Packerのバージョン0.3.6からProvisionersにChef-Soloを指定出来るようになりました。

Packer|ChangeLog

下準備 – 実行するChef Recipeを用意する

まずはChefRepositoryを用意します。 今回のお題もまたまたNginxをソースからインストールします。 レシピの準備を手軽に実施するために、Berkshelfを利用してChefRecipeを取得します。 Berkshelfについては、以前の記事や、以前の発表資料で紹介しています。

Berksfile

これで、site-cookbooks内にNginx Recipeと、Nginx Recipeが依存するRecipeが用意されます。 実行後はpacker-sampleフォルダ内は以下の状態になっていると思います。

Packer設定ファイルの用意

Chefリポジトリが用意出来たので、次にPackerの設定ファイルを記述します。 今回は、EC2 AMI を作成するので、以下のようなファイルを作成します。

ami-chef.json

provisioners には、Chef-Soloを利用するので、typechef-soloを指定し、cookbookのパスや、run_list、attributeを書いたJSONフィールドを設定しています。

まとめ

実は以前にPacker+Chef-Soloと同じ事をしてくれるフレームワークを自作してたりしてました。(ec2_automation)

しかし、当たり前ですがPackerの方がずっと使いやすいです。

  • 複数のプラットフォームに対応
  • Chef-Solo以外のProvisionerも利用可能

など、Packerの優位な点が非常に多くあります。 非常に素性がよく、設定も書きやすいので環境構築の自動化と高速化に取り組まれている方々にはPackerは非常にお勧め出来るツールです。

つい先日バージョン0.3.7がリリースされ、新たにPuppetをProvisionerとして利用出来るようになりました。 開発が活発でこれからどんどん便利になって行く事が期待出来ます。


2013年09月4日

kunihira

AnsibleでNginxインストールしてみた

全国のプロビジョニングフレームワークファンの皆さんこんにちは。 フリューChef導入委員長(自称)の国平です。

前回の記事から2ヶ月も間が開いてしまいました。 この2ヶ月間何をやっていたかというと、ネタLTしてみたり、フレームワーク作ってみたり、夏サミ2013に参加してみたり、あとはひたすらPlay2.1+Scalaと格闘していました。

さて、今回の記事ですが、プロビジョニングフレームワーク周りでChefの対抗馬として注目を集めているAnsibleを触ってみたので、その使用感をレポートしたいと思います。

目的

本記事の目的は、プロビジョニングフレームワークの検討です。 前々回の記事で、ChefとFabricを使ってみた感想をまとめましたが、同様にAnsibleを検証してみます。

Ansibleとは

http://www.ansibleworks.com/

Ansibleは最近話題の構成管理ツールです。 Python製のツールで、サーバの環境設定はPlaybookと呼ばれるyaml形式のファイルにまとめます。このPlaybookがChefのrecipeに相当します。 構成管理ツールとして作られているので、べき等性が保証されており、Playbookに記述した状態にリモートマシンを収束させます。

サーバに対する操作はsshで実行されるので、リモートマシンにAnsibleをインストールする必要がなく、Ansibleをインストールしたマシンが1台あれば利用出来ます。

使ってみる

今回もNginxのインストール手順をAnsibleで自作してみました。 Nginxインストールの要件は、以前の記事と同じで下記のようになっています。

  • Nginxをソースからビルドする
  • ビルドに必要なライブラリもインストールする
  • nginx.confを配備する
  • nginx.confはテンプレートを用意し、本番環境/開発環境で設定内容を書き換える
  • 本番環境は、AWS EC2のm1.largeを想定しworker_processを2に設定
  • 開発環境は、m1.smallを想定し worker_processを1に設定

ファイル構成

Ansibleを実行するための最小ファイル構成は、非常にすっきりしています。 公式ドキュメントでは、ディレクトリ構成などのベストプラクティスも紹介されていますが、今回は以下のディレクトリ構成となりました。 Chefに比べて非常にスッキリとしています。

このPlaybookはGistで公開しています。 Playbook|Gist

今回、環境ごとに変数を切り替える方法が調べきれなかったので、実行時に外部から–extra-varsオプションで変数を渡すことでnginx.confの出し分けを行いました。 (こういった出し分け方法をご存知の方がいらっしゃれば是非ご教授ください。)

使った感想

いろいろなところで、「Chefに挫折したのでAnsible」という記事をよく見かけますが、確かにChefより実行環境の構築が楽で、やりたい事が記述しやすいように思います。 特に、Push型の構成で、リモートサーバに対するインストールが不要というのが大きいと思います。 Chefの場合ですと、knife-soloを利用する事で、Push型に似せた実行が出来るのですが、やはりプラグインを追加でインストールしなくてはならない上に、あくまでPush型ライクな実行ができるだけにとどまっています。

Playbookもシンプルなので、これまでシェルスクリプトを書いていたり、実行していたコマンドを元に、書き起こしやすいと思います。

ただ、やはりyamlファイルなので、込み入った事がやりづらいという印象でした。 今回のような、変数の出し分けで、まずはPythonのDictionaryを使いたいと思ったのですが、yamlで扱う方法がわかりませんでした。 この辺り、ChefやFabricならRubyなりPythonなりでダーティーながらも、やりたい事を無理矢理書いて動かしてしまえました。 その一方で、Ansibleは、きちんと型に沿って利用するのが大前提になっているようです。

Chef/Fabricとの比較

どのツールでも、サーバに対する操作をソースコードにまとめられるので、Gitなどでバージョン管理する事が出来ます。 また、Ansibleはべき等性が保証されている点がChefと同様であり、リモートマシン環境を収束させるという使い方で実力を発揮します。

その一方で、Chefが基本的にはサーバ/クライアント構成のPull型アーキテクチャであるのに対して、AnsibleはFabric同様のPush型アーキテクチャになっています。

比較表

項目 Ansible Chef Fabric
構成 Ansibleサーバ → リモートマシン Chef-Solo Fabricサーバ → リモートマシン
言語 Python(2.6~) Ruby(1.9系) Python(2.5~)
設定ファイル yamlで記述 DSLで記述 Pythonで記述(シェルライク)
日本語ドキュメント 少ない 豊富 少ない
サンプル 少ない 豊富 少ない
サーバ追加の作業 少ない:実行先をhostsファイルに追加するだけ 多少多い: Chefインストールの手間がかかる 少ない:タスクの実行先を追加するだけ

まとめ

今回、話題のAnsibleを利用して、使い勝手を検討してみました。 環境構築が楽で、すぐに実行出来る点は非常に優れていますが、一方でyamlの記述力が物足りない感じでした。

また、あくまで現段階の比較ですが、Chefが既に膨大なrecipeが公開されているのに対して、Ansibleは参考になるPlaybookが見つけづらく、日本語の資料もまだまだ少ないようでした。 この辺りは、時間とともに充実してくると思いますが、現段階ではChefの方が情報がまとまっていて、扱いやすいように思いました。 また、VagrantはAnsibleも使えるようになったようですが、AWS OpsWorksやPackerなど利用されている範囲が広い点でも、まだChefが優位な様子です。

参考

最後に、Ansibleを利用する上で役に立ったサイトを挙げておきます。