Furyu
[フリュー公式]

Tech Blog

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

2016年06月27日

Kayo

Ansible Meetup in Tokyo 2016.06に行ってきました!

みなさん、こんにちは。コンテンツ・メディア第1事業部インフラ担当の藤本佳世です。前回のブログの続き、「OpenStack構築手順」などご紹介する予定ですが、その前に2016年6月1日(水)に開催された「Ansible Meetup in Tokyo 2016.06」に参加したお話しをしたいと思います。自称「Ansible女子」の私。3年前にも参加したことがあり、今回は3回目の参加でした。

詳細URL http://ansible-users.connpass.com/event/31222/

Ansible

Ansibleとは、今回Meetupの会場でもあるレッドハットが開発するオープンソースの構成管理自動化ツールです。
ssh通信を利用して、クライアントサーバに直接命令を送り込むことができます。
フリューでは約3年前にAnsibleを導入し、ミドルウェアのインストールなどサーバ構築・管理には欠かせないツールとして利用しています。Ansibleを使うメリットはとても大きく、導入したことで、今まで手動で3時間もかかっていたサーバ構築作業を、1時間以内まで時間短縮を実現することができました。
使い始めた頃は、参考書も少なく、公式HPの英語ドキュメントを参考にしていましたが、今年の4月にO’Reillyから本も発売され、ますます注目されています。

公式ホームページ https://www.ansible.com/

発表内容

  • 「Ansible Core 2.0 Overview and future releases」 by Dylan Siliva
  • 「Jupyter+AnsibleによるLiterate Computing(手順書 as a Code)への挑戦」 @ enakai00
  • 「共通言語Ansible」 @seri_wb
<LT詳細>
  • 「ansible-vaultについて何か」 (ynn)
  • 「Ansibleの教育トレーニングはじめました」 (spchildren)
  • 「Ansible2.0とOpenStackの関係」 (saito_hideki)
  • 「Playbookからのドキュメント自動生成やってみてる」 (h-hirokawa)
  • 「Ansibleとterraformで実現するタグベース複数環境プロビジョニング実例」 (takuya_onda_3)

内容まとめ

Ansible2.0新機能と今後のリリース関連

  1. 200以上の新しいモジュールが追加された
  2. エラーメッセージの改善:よりわかりやすくエラーメッセージ内容を記載するようになった
  3. アーキテクチャが変更され、より簡単に開発できるようになった
  4. ansible-vaultと呼ばれる機密情報が書かれたファイルを暗号化するツールがリリースされた
  5. 36個の OpenStackモジュール追加され、バージョン1と比べて、とても使いやすく親和性が高い
  6. sudo機能が使えなくなる予定。ansible_ssh_hostnameを ansible_hostname, ansible_userに変更する必要がある
  7. 約400以上のモジュールをリリース予定(Dockerモジュールも追加予定)
  8. python3対応予定
  9. クラウド技術にも力を入れる予定 (AWS, OpenStackなど)

運用について

  1. 開発とインフラの作業ラグをなくす取り組みについて、ミドルウェアバージョンアップなどインフラではなく、開発メンバーにAnsibleを実行してもらっている
  2. ansible-vaultと呼ばれる機密情報が書かれたファイルを暗号化するツールの利用
  3. Ansibleは自動化だが、やはりメンテナンスする必要がある。複雑なplaybookを書いてしまい、結果ブラックボックス化してしまう。手順書を用いることで、だれが見ても分かるようにする
  4. Ansibleコードをシンプルに保つことが大切

感想

Ansibleバージョン2.0の新機能や今後リリース予定のモジュールなどの紹介がありました。
個人的には、【Jupyter+AnsibleによるLiterate Computing(手順書 as a Code)への挑戦 @ enakai00 】の発表が非常に興味深かったです。手順書作成の必要性について、いかにAnsible(コード)だけに頼らず、うまく手順書にAnsibleを載せるかについて紹介されていました。

私が所属するインフラチームは、Ansibleを導入して約3年ほど経ちます。新規サーバ構築以外に、ミドルウェアのアップデート、脆弱性対応など、様々なケースで利用しています。しかし、Ansibleの構成が複雑化してしまい、他のメンバーが使いこなす事が非常に難しい状態です。そんな時、やはり手順書があればと思っていました。発表で「Jupyter」を使った手順書作成についてのお話しを聞くことができました。Jupyterの知識はゼロですが、是非検証してみたいなと思いました。

その他にもOpenStackについて、Ansibleバージョン2以降、とても使いやすくなったとの発表もありました。
前回のブログで紹介したOpenStackは、Ansibleを使って構築しました。今後のブログで、その手順をご紹介するので、是非読んでいただければ嬉しいです。


2014年11月4日

kunihira

Vagrantで簡単Ansible実行環境を配布する

こんにちは。 最近、英語の勉強にハマっている国平です。

少し前の話になりますが、Bashに脆弱性が見つかった際にみなさまどのように対応されたでしょうか? 私の部署ではサーバのBashのバージョンアップを1台ずつログインして手動で実行していました。

このバージョンアップ作業自体は1コマンドで完了するのですが、サーバ台数が多く1台ずつに順にsshでログインしコマンドを実行するのは結構な手間が掛かりました。

そこでAnsibleを使って複数のサーバの状態をまとめて変更できるようにしました。

Ansibleによるサーバの管理自体は資料も多くすぐに実行出来ました。 以前、このブログでAnsibleを取り上げたときには参考にできる情報が少なかったのですが、 現在では非常に多くの優れた資料が公開されていますので、Ansibleを利用する事自体はそれほど難しくないかと思います。

しかし、次の課題としてチーム全員がAnsibleを利用できるようにしなくてはいけません。 Ansibleの利用に集中できるように簡単にAnsibleの実行環境を構築できるような仕組みづくりを目指して、 Vagrantを利用して実行環境も含めてGitで管理し、配布できるようにしました。

今回のポイント

今回の課題は、チーム全員が簡単にAnsible実行環境を使えるようにするということです。 AnsibleのPlaybook自体はGitでバージョン管理出来ているので、同様にGitで実行環境も管理できると、 便利で配布がしやすくなりそうです。

そのため、今回はVagrantの設定ファイルをPlaybookとセットでGit管理し、Vagrantを実行するだけで、 Ansibleがインストール済みで、Playbookも利用できる仮想マシンにアクセスできるような仕組みづくりを行いました。

Ansibleとは

Ansibleはリモートマシンのあるべき状態をPlaybookというファイルに記述し、実行する事で、リモートマシンの環境を整えるツールです。 以前にもこのブログの記事でも取り上げました。

最近では急速に普及が進んで、利用するための情報も多く公開されていますし、電子書籍ですが入門Ansibleという本も公開されています。

Vagrantとは

Vagrantは仮想環境をコマンドラインから利用するツールです。 VirtualBoxをコマンドラインから利用する事ができる他、ネット上で公開されているBoxを取得して実行したり、 仮想マシンの起動時にShellスクリプトやChef、Puppetなどを利用してプロビジョニングを行う事も出来ます。

こういった設定を全てVagrantfileにRubyのDSLとして記述する事ができるので、Vagrantfileとプロビジョニングに使うファイルをGitにコミットしておけば、どこからでも同一状態の仮想マシンを利用する事が出来ます。

今回の方針

今回は、PlaybookとVagrantfile、そして仮想マシンのプロビジョニングファイルを1つのGitリポジトリにまとめてコミットしておきます。 プロビジョニングには、チームメンバーが誰でも読み書きできる前提で、Shellスクリプトを利用することにしました。

今回作成したGitリポジトリのサンプルはこちらです。

仮想環境構築のポイント

Vagrantで仮想環境を複数人で利用するためのポイントは下記の3点です。

  • Boxを自動的に取得するようにする
  • 仮想マシンを起動したら自動でPlaybookを実行できるようにする

Boxを自動的に取得するようにする

Vagrantでは仮想マシンの起動の際にベースとなるイメージファイルをBoxと呼びます。 最初にVagrantを利用する際にはBoxを取得して利用するのですが、 チームメンバーが個々にBoxを取得するのも面倒です。

なので、全員がおなじBoxを利用できるようにVagrantfile内で config.vm.box_url を設定しておきます。 これにより、Vagrantを実行するホストマシンに config.vm.box で指定したBoxが存在しなければ、指定したURLからBoxを取得して起動するようになります。 サンプルではCentOS6のBoxを取得して、furyu_blog_sample という名前で利用できるように設定しています。

仮想マシンを起動したら自動でPlaybookを実行できるようにする

この処理には2つのポイントがあります。

ホストのディレクトリを同期

まずは、仮想マシンとホストマシンのディレクトリを同期する設定をします。 Vagrantfileで config.vm.synced_folder "<HOST_DIR>", "<VM_PATH>" を設定すると、ホストマシンの指定したディレクトリを、仮想マシンから参照できるようになります。

サンプルで公開しているリポジトリの場合ですと、下記のように設定する事でサンプルリポジトリ全体を仮想マシン上では /playbook ディレクトリとして扱う事が出来ます。

仮想マシンをShellプロビジョニング

もう一つのポイントは、Vagrantのプロビジョニング機能を利用して仮想マシンにAnsibleやその実行のために必要なツールをインストールすることです。

Vagrantでは前述の通り仮想マシンの新規起動時にシェルスクリプトなどの実行をさせる事ができます。 なので、先ほど同期したリポジトリ内に、Ansibleのインストールなどを行う処理をまとめたシェルスクリプトを用意しておいて、実行するようにします。

今回は、リポジトリ内のvagrantディレクトリに置いてある、bootstrap.shを実行するようにします。

bootstrap.shは下記のような内容になっています。

Ansibleを実行する

サンプルリポジトリを使ってAnsibleを実行してみます。 なお、今回仮想マシンに利用しているCentOS6では、Ansibleが実行時にsshを自動的には利用してくれないので、-c オプションをつけて明示的にsshを利用するようにしています。 このサンプルは、Vagrantが利用できる事が前提となっています。

上記のコマンドを順に実行すると仮想マシンが立ち上がり、接続し、そしてplaybookが実行出来ます。

まとめ

今回の記事ではAnsibleの実行環境をVagrantを利用して配布しました。 これによって、チームメンバー全員が簡単にAnsibleを利用する事ができます。 簡易ながらVagrantを用いてプロビジョニングする事で、 サーバ環境だけでなく、実行環境にもべき等性を持たせる事が出来ました。 これでチームメンバーのローカルマシンの設定の差に影響を受けずに作業する事ができます。

関連記事


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を利用する上で役に立ったサイトを挙げておきます。


2013年06月26日

kunihira

関JavaでJavaでなくChefの話をしてきました

皆さま約一ヶ月ぶりです。
国平です。

先日、関西Javaエンジニアの会でChefの話をしてきました。参加してくださった方々にちょっとでもChefに興味を持っていただけたら大成功なのですが、いかんせん限られた時間での発表なので具体的な使い方やサンプルまでは踏み込めませんでした。なので、その分をこのブログで補足したいと思います。

発表内容

私の関Javaでの発表資料はこれです。

Chefとかプロビジョニングまわり from Kiyotaka Kunihira

いろいろと書いていますが、要するに

  • プロビジョニングフレームワークの導入で色々はかどる
  • Chefは便利なツール
  • knife-soloでリモート操作が便利になる
  • Berkshelfでcookbookの依存関係も解決出来る

という内容です。

私の前回の記事のChef周りの内容に加えてknife-soloとBerkshelfの紹介を足しています。 今回の記事では特にknife-soloとBerkshelfの利用についてまとめます。

knife-solo

knife-soloはknifeのサブコマンド群です。
この、knife-soloはChef-Serverで行うようなリモートサーバに対するChefの実行をChef-soloで実現してくれるツールです。

前回のブログ記事で、Chefは各サーバに対しインストールが必要で面倒だと書きましたが、このknife-soloを利用することでChefのリモートインストールが可能になり、Chefの利用が一気にはかどります。

インストール

knife-soloはgemでも提供されており、普通にgem installもできるのですが、デフォルトのバージョンが0.2.0となっています。 https://rubygems.org/gems/knife-solo

しかし、バージョン0.3.0で追加されたオプションもあり、なるべく0.3.0の利用をお勧めします。特に、knife-soloは開発が活発なので、なるべくならgemでなくソースからのインストールをお勧めします。

gemでインストールする

gemからインストールする場合は、バージョン指定せずにインストールすると前述の通り0.2.0がインストールされます。 なるべく最新のバージョンをインストールするために、以下のようにバージョンを指定して取得するといいと思います。

最新バージョンについてはここで確認してください。

]# gem install -v 0.3.0.pre4

ソースからインストールする

knife-soloのソースはGitHubで公開されています。 https://github.com/matschaffer/knife-solo

ソースからのインストールには次の3つがインストールされている必要があります。

  • rake
  • bundler
  • git

インストールの実行手順を下記にまとめました。 注意して頂きたいのは、knife-soloのGitリポジトリはsubmoduleに別れているので、サブモジュールの更新を実行する必要がある点です。

上記手順で、knife-soloのインストールが完了します。

コマンド

knife-soloには以下の5つのコマンドがあります。

  • init
  • prepare
  • cook
  • bootstrap
  • clean

今回は、関Javaで紹介したcook、prepareに加えてinitについて紹介しますが、残りのコマンドについてもhelpで確認出来ます。

knife-solo自体のヘルプを確認したい場合はknife solo -hで、各コマンドについて確認したい場合は、knife solo -h {command}で確認出来ます。

init

initコマンドを使う事で、新しくknife-soloに最適化されたChefRepository(Kitchen)を作成する事が出来ます。

knife solo init {DIRECTORY}

prepare

prepareコマンドは、リモートマシンに対してChef-soloのインストールを行います。 また、同時に指定したリモートマシンに対してデフォルトで実行される設定を書き込むjsonファイルがnodesフォルダに作成されます。

knife solo prepare {user}@{host}

cook

cookコマンドは、リモートマシンに対してChef-soloの実行を行います。 prepareコマンドでjsonが作成されているハズですので、そのjsonのrun_listに書かれているcookbookが順に実行されます。

knife solo cook {user}@{host}

sample

knife-soloを利用するサンプルとして、gitをリモートサーバにソースからインストールしてみます。

今回は、opsocodeが公開しているcookbookをgitから取得して実行します。 なお、今回は既にローカルマシンにはgitがインストール済みの前提で進めます。 もし、まだローカルマシンにgitをインストールしていない場合は、gitをインストールする、もしくはgit cloneを行っている箇所を、zipのダウンロードに読み替えてください.

まずはリポジトリを作成しましょう。

リポジトリの作成が出来たら、リモートサーバにChefをインストールします。

次に必要なcookbooksをダウンロードします。

git cookbookが直接依存するcookbookはhttp://community.opscode.com/cookbooks/gitのCookbooksの項にまとまっていますが、最終的にgit cookbookは次の6つのcookbookに依存します。 これは、git cookbookが依存するcookbookが更に依存するcookbookを持つためです。

  • runit
  • build-essential
  • dmg
  • yum
  • chef_handler
  • windows

これらのcookbookもダウンロードします。

必要なcookbooksがそろったら、実行するrun_listを設定します。

このjsonの設定で、knife-soloを実行するとリモートサーバの/usr/local/gitにgitがソースからビルドされます。 実行するには、knife solo cookコマンドを実行します。

これで、gitのインストールが実行出来るはずです。

Berkself

先ほどのknife-soloのサンプルでは、cookbookの依存関係を手動で解決しました。 しかし、gitだけで6つものcookbookに依存しているのに、さらに他のcookbookを実行するとなると、依存関係の解決は気の遠くなる作業になります。 そんな、cookbookの依存関係を自動的に解決してくれるツールがBerkselfです。

本家サイトでは、Chefを活用するためのbundler的なツールだと説明されていますが、関Javaな人にはMavenをイメージしてもらうのがわかりやすいと思います。 前述のknife-soloを利用したサンプルとしてgitをリモートサーバにインストールしましたが、その際にgitのcookbook以外にもbuild-essentialなどのcookbookをgitから取得しました。 これは、gitのcookbookがそれらのcookbookに依存しているためです。 Chefではrecipe中にinclude_recipe "..."と記述する事で、Chefのpath中にあるcookbooksに依存した処理を記述する事が出来ます。 これにより、誰かが公開しているcookbooksを別のcookbooksから利用しやすくなっているのですが、同時に必要なcookbookの数が増えてしまい、人力での管理が難しくなってしまいます。 こういった問題については、rubyであればbundler、JavaならMaven、Scalaならsbtを利用している方々はよくわかるんじゃないかと思います。

インストール

インストールは簡単でgem経由でインストールするだけです。

]# gem install berkshelf

Berksfile

Berkshelfの設定については、基本的にはリポジトリ直下にあるBerksfileを編集します。 そんなに難しい英語を使っているわけでも無いので公式サイトを一読して頂ければだいたいどんな事が出来るのかわかると思います。

コマンド  

Berksfileの編集が完了していれば、berks installコマンドで依存関係を解決する事が出来ます。

]# berks install

ただし、これだけ実行するとberkshelfの初期設定に従って、~/.berkshelf以下に依存するcookbookがインストールされます。 シンプルにChef-soloを利用するだけであれば、ローカルマシンのChefのパスは通っているのでこれで問題ないのですが、Chef-soloを利用してリモートサーバに対してインストールを実行しようとするとこれでは問題があります。

基本的にChef-soloはリポジトリ内のファイルをrsyncでリモートサーバに対して同期するだけなので、基本的にリポジトリ外の依存ファイルを同期する事が出来ません。 そのため、リポジトリ内にcookbookをダウンロードしてくる必要があります。

指定したpathにcookbookをダウンロードするには–pathオプションを利用します。

サンプル

knife-soloのサンプルとしてgitのcookbookを利用したサンプルを挙げましたが、次は、同じgitをBerkshelfを利用して実行してみます。 knife-sloの時は依存関係のあるcookbookを自力で全て取得していましたが、今回はBerkshelfの力を存分に発揮してもらいます。

まずは、リポジトリを作成します。今回は、berkrepoというリポジトリを作成します。

リポジトリが出来たらBerksfileを編集します。knife-soloのinitコマンドを利用して、リポジトリを作成すればデフォルトでBerksfileは作成されるので、以下のように編集します。

Berksfile

nodes/{host}.json

まとめ

knife-soloとBerkshelfについて、関Javaでの発表を補足しつつ紹介してみました。 ほんとうに、この組み合わせは鼻血が出るほど素敵なので、ご興味のある方は是非お試しください。