Tag: vagrant
nginx-proxy を使った Docker ベースの検証をしてたらリバースプロキシが急に表示できなくなった
メモとして残しておきます。 ansible-playbook で急に表示できなくなった 本番環境の CentOS7 と、その検証環境（Vagrant on Mac）で Ansible 経由で Docker をインストールして使っていたのですが、 ある日 ansible-playbook を実行すると急に表示できなくなりました。 （Chef を使ってたころはこういうの頻発してたなあ・・・） その間は Vagrant のアップデートくらいしかしてなかったので、 順に確認していくことに。 各種ログ nginx-proxy のログは lrwxrwxrwx 1 root root 11 Aug 24 03:51 access.log -> /dev/stdout lrwxrwxrwx 1 root root 11 Aug 24 03:51 error.log -> /dev/stderr のような感じで、特に何も指定してなければ外にログとして出るようになってます。 docker logs -f nginx-proxy などとしてログを表示させたりしても特に問題は見受けられず。 また、 /etc/nginx/conf.d/default.conf のファイルも特に問題なく、 コンテナが作られると適切に設定が書き換わっているようでした。 自動と手動 次に ansible のレイヤーで問題が起きている可能性を考えて、 自動で作った Docker コンテナをそのまま手動で作ってみました。 するとコンソールに見慣れないメッセージが。 WARNING: IPv4 forwarding is disabled. Networking will not work. なんだこれ。
vagrant global-status の代替方法、あるいは jq コマンドの使い方
VM（Docker も含む）が立ち上がっているかどうかを tmux の右下に表示しておくのはけっこう便利です。 tmux の set-option -g status-right で指定できるスクリプトは 一定間隔で常に呼ばれるような仕組みなのですが、 （更新間隔は set-option -g status-interval で設定可能） あまり間隔を空けすぎると確認しづらくなってしまうので 5 秒くらいに指定しています。 このスクリプト内で Vagrant 経由で起動している VM 名と Docker サービスが立ち上がっているかどうかを 集約して表示しているのですが、 この中で vagrant global-status を呼ぶコストが意外にも高い ことに今更ながらに気づきました。 （たぶんディレクトリツリーを全走査とかしてるんですかね・・・？） top とか ps とかで詳しく調べてみるとすげー CPU を使ってたっぽかったので、 （5 秒間隔で常に動作してるわけじゃなかったので気づかずにスルーしてました） これはなんとかしなくてはと思い、代替方法を検討しました。 ~/vagrant.d 内の設定ファイル 後の Vagrant のバージョンアップで変わるかもしれませんが、 以下の場所に仮想マシンの一覧情報がまとめられていて、 Vagrant の仮想マシンのステータスが変更されるたびにこのファイルが更新されます。 ~/.vagrant.d/data/machine-index/index こちらはただのテキストファイルなので、 5 秒間隔で tmux から重いコマンドを実行するよりは、 こちらの設定ファイルを読みにいった方がはるかに軽いです。 ただ、こちらのファイルは JSON ファイルを圧縮したようなファイルになっているので、 こちらを（あまりコストかけずに）さくっとフィルタリングして 必要な情報だけ抜き出したいですね。 jq は JSON ファイルをフィルタリングするコマンド Redirecting to jqlang.github.io stedolan.github.io
Scotch Box for local LAMP development
If you spend any amount of time working on LAMP stack development projects you should take a look at Scotch Box. It's a full-featured Vagrant Box and is far easier than fiddling with setting up a server directly on your dev machine.
Docker と Vagrant の明確な違い
そもそも比較するようなものではないものの、分かりづらい解説しかなかったので、 超個人的な主観でまとめておこうと思いました。 Docker の特徴 Linux 上でのみ動く (Windows, Mac 上では動かない) Linux のリソースを流用しつつも小さく閉じた環境を作ることができる 小さいので作っては捨て、が容易 例えるなら・・・ 病院の中に超小型隔離施設を作るようなもの 隔離されてるものの、診察も受けられるし隔離施設ごとトイレにも行ける Docker コンテナをたくさん作る ≒ 病院内に超小型隔離患者がたくさん、みたいなイメージ Vagrant の特徴 Windows / Mac / Linux それぞれにパッケージが用意されている 実際は VirtualBox や VMWare のような仮想環境を提供してくれるものとセットで使う 仮想環境としての Linux は、普通にインストールした Linux とほぼ変わらない構成 例えるなら・・・ 病院の敷地の中に病院を建てるようなもの 内側の病院も、普通に診察できるし手術もできるし遜色なく利用できちゃう Vagrant で VM たくさん作る ≒ 外側の病院敷地内に中小病院をたくさん建てる、みたいなイメージ 複数建てるときは資金力がいる Mac で Docker いじるってことは、超軽量な Linux を boot2docker とかでインストールして、その上で動いているケースが多く（あるいは他 VM を立ち上げてるとか）、結局 Docker は Linux 上でのみ動くってことになります。（今後 Windows 方面がサポートするかもしれないけど） たぶん本番環境の検証という意味では、Vagrant + Chef で本番環境にできるだけ近しい状態を構築して検証とかすべきなんですけど、開発環境をいくつも立ち上げては消しみたいなことをやりたいんだったら、Docker の方が軽くて良いのでは？と思っているところです。 もし本番環境に Docker を入れて色々利用したいのなら、まずは Vagrant + Chef の環境を手元に作って、Chef のレシピで Docker の環境を整えるレシピを書けばいいんだろうか。（まだその辺りはすっきりしてませんのでこれからですかね・・・）
Chef を本番投入してみた
メモレベルでごめんなさい。 サーバを移設してみました。 せっかくなので、移設ついでにブログのリニューアル（簡素化）と Chef cookbook を利用したプロビジョニングにも挑戦してみたよ、という記録です。 やったこと概要 Vagrant を利用してローカルに同じ環境を作る（空のVM） レシピを書きつつ、ローカルと本番環境との差異などを attributes に括り出す ローカル環境へのプロビジョニングが問題なければ、同じレシピを本番にも適用 本当は Serverspec なども試していきたいですが、そちらは今後やっていければと思います・・・。 多くのサードパーティ製レシピは、Chef Supermarket に登録してあるのですが、読み方や使い方が分かっていないと意味をなさないケースも多かったです。 レシピは大きく分けて2種類あり、attributes として json ファイルに値を書いていくスタイルのものと、もともと Chef に用意されている file, template のような、レシピ内に Chef の resources として記述するスタイルのものがあります。以下の記事にもわかりやすく紹介されてます。 さくらVPSの初期設定をChef Soloでやってみた〜サードパーティcookbookの使い方〜 | tsuchikazu blog tsuchikazu.net 例えば、今回レシピを適用したいマシンを仮に alpha としておいて、nodes/alphalocal.json と nodes/alphaproduction.json の2ファイル用意し、それぞれ設定を括り出しておきたいところを記述しておきます。 以下は nodes/alphalocal.json のサンプルです。（実際はもうちょい複雑ですが） { "name": "alphalocal", "automatic": { "ipaddress": "192.168.0.10" }, "fqdn": "alphalocal", "platform_family": "rhel", "platform": "centos", "platform_version": "6.6", "run_list": [ "recipe[selinux::disabled]", "recipe[yum]", "recipe[yum-epel]", "recipe[yum-remi]", "recipe[ntp]", "recipe[locale]", "recipe[timezone-ii]" ], "locale": { "lang": "ja_JP.utf8", "lc_all": "ja_JP.utf8" }, "ntp": { "servers": [ "ntp.nict.jp", "ntp1.jst.mfeed.ad.jp", "ntp2.jst.mfeed.ad.jp", "ntp3.jst.mfeed.ad.jp" ] }, "tz": "Asia/Tokyo" } これは前者の attributes として json ファイルに値を書いていくスタイルですね。後者の場合は、独自にレシピを書いていきつつも、レシピ内で独自の resources を使って書いていく感じです。
Vagrant で SSH の接続ポート番号を変える、という発想がそもそも間違ってた
2013年に書いていた、『Vagrant で SSH の接続ポート番号を変えると、けっこう複雑になるという話』（ https://girigiribauer.com/tech/20130726/ girigiribauer.com ）という記事の続きです。 2013年の段階では、まだまだ考え方みたいなものがまとまりきっておらず、Vagrant が用いる接続ポート番号を変えるという方向で色々考えていたのですが、今振り返ってみるとそもそも根本の考え方を見直すべきでした。 Vagrant の使いどころ・考えどころ ざっと『Vagrant の使いどころ・考えどころ』（ https://girigiribauer.com/tech/20150303/ girigiribauer.com ）に書いたのですが、Vagrant を用いる用途としては大きく2種類あると考えています。 ローカルの開発用としてローカルでのみ使い続ける 本番環境の検証用として、同じレシピを仮想マシン・リモート環境にそれぞれ適用 SSH の接続ポート番号を変えるという大きな理由はセキュリティにあると思います。 デフォルトの22番ポートで使っていると外部からのアタックに弱いため、ポート番号を変えたい、そのためのレシピを書きたい、という点が根本にあると思います。 つまり、2.の**『本番環境の検証用として、同じレシピを仮想マシン・リモート環境にそれぞれ適用』**ってのがやりたいわけです。 もし1.が目的だったのなら、わざわざポート番号を変える必要はありません。Vagrant で SSH の接続ポート番号を変えると、けっこう複雑になるという話 にもあるように、ホスト OS が 2424 番、ゲスト OS が 22 番で接続している最中に、**ゲスト OS を 22 番をレシピで別ポートに変更してしまうと接続が切れてしまいます。ローカルで動作しているのならわざわざ変える必要はありません。**何が面倒なのかは、詳しくはそちらの記事をご覧ください。 同じレシピをローカル、リモートに適用する 本番環境の検証用として利用したいという用途で、 同じレシピをローカル、リモートの両方に適用したいということであれば、json ファイルに設定をくくり出してやれば OK です。 ローカルは Vagrant で動いていますが、リモートはそうではないので、両方で同じレシピ適用方法が可能な knife コマンドを使いましょうー。 ローカル 以下は実際にそのまま使っているわけではないですが、nodes/localhost.json として Vagrant で動作しているローカル VM にレシピを適用するための設定ファイル（の一例）です { "name": "localhost", "automatic": { "ipaddress": "192.168.24.24" }, "fqdn": "localhost", "platform_family": "rhel", "platform": "centos", "platform_version": "6.6", "run_list": [ "recipe[openssh]" ], "openssh": { "server": { "port": 22, "password_authentication": "no" } } } あとは knife コマンドにて、
Vagrant を開発用 Web サーバとして利用するときの注意点
罠があるのでまとめておきます。（体験談） なお、box ファイルは CentOS6 ベースのもの、Web サーバは apache です。（本番環境を想定した開発環境なので、nginx は別のところで使っています） レシピを適用しても上手く表示されない レシピ適用した後で、 vagrant up や vagrant reload などで VM を起動したとしても、Web サーバがうまく動かなかったケースとかありませんでしたか？私はありました。 /var/www を synced folder に指定しているとはまります。 なんともならなかったので、毎回 ssh でログインして sudo service httpd restart してごまかしてましたが、なんだかはまる人多そうだなーと思ったのでこちらにまとめておきます。 Vagrant の動作順おさらい レシピの指定を Vagrantfile に書いているケース、knife コマンドを使うケースのいずれにおいても、 vagrant up --provision もしくは vagrant provision 時に以下のような順序で動作します。（ログ見れば分かりますが） box ファイルの設定、仮想マシンの電源ON（ブート処理） Vagrant が使う SSH のポートフォワーディング周りの設定 synced folder の設定 （Vagrantfile 内に記述があれば）レシピの適用 なお、古いバージョンの Vagrant では、vagrant up とするだけで up した後に vagrant provision を実行した時の処理が毎回走っていましたが、最近のやつは vagrant up するだけでは Vagrantfile 内に書かれたレシピは適用されなくなりました。（こちらが通常だと思います）
Vagrant で個人的に必須なプラグイン
先に Vagrant の使いどころ・考えどころ を見ると良いかもです。 先に列挙します。 Vagrant 1.6.5 時点で入れたやつなので、すぐに変わる可能性ありです。 vagrant-omnibus (1.4.1) vagrant-vbguest (0.10.0) sahara (0.0.17) vagrant-dnsmasq (0.1.1) landrush (0.18.0) 初回の vagrant up に重宝するプラグイン GitHub - chef-boneyard/vagrant-omnibus: A Vagrant plugin that ensures the desired version of Chef is installed via the platform-specific Omnibus packages. A Vagrant plugin that ensures the desired version of Chef is installed via the platform-specific … github.com
Vagrant の使いどころ・考えどころ
Vagrant, Chef 周りの知見が溜まってきたのでそろそろまとめていきたいと思っているのですが、 まだまだ自分の中で分からない部分も多く、 かつ自分はインフラエンジニアではないので、 正直どこまで書いたらいいのか迷っています。 また、chef-solo はなくなるから、これからは chef-zero だ、なんて言われても、 インフラに関する前提知識が薄いので、なかなかついていくことができません・・・。 とはいえ、少なくとも使っていく中で自分なりの思想みたいなものははっきりしてきたので、 まずはそこから書いてみようと思います。 Vagrant の用途を考える Vagrant が何なのかを知らない人に説明するとすれば、 仮想マシン（VM）をコマンドラインで統一的に扱えるインターフェースのようなものだと説明できると思います。 決して仮想環境そのものではなく、仮想環境を提供してくれるものとセットで使います。 例えば VirtualBox や VMWare 、あるいはリモートですが AWS(Amazon Web Service) なんかも選択肢になり得ます。 詳しくは Vagrant | HashiCorp Developer www.vagrantup.com からインストール手順などを参考にして、実際に試されると良いかと思います。 （今回はこの辺り、一切触れません） Vagrant をどういう用途で使うかというと、おそらく大きく2種類に分かれると思います。（主観） ローカルの開発用としてローカルでのみ使い続ける 本番環境の検証用として、同じレシピを仮想マシン・リモート環境にそれぞれ適用 1.は開発寄りの人が一番思いつきやすい用途だと思います。 全く同一でもない限り、ローカルで開発したものをリモート環境へ持っていくと、 少なからず環境による差異が問題になってきます。 2.は、運用寄り（インフラ寄り？）の人が一番思いつきやすい用途だと思います。 いくら Chef が便利だからといっても、本番環境にトライアンドエラーでレシピ適用して 問題がないケースはほとんどないと言っていいと思います。 この場合、手元の仮想マシンに対してレシピを適用して検証、問題なければ本番マシンに対して適用、 という流れが良いのではないかと考えています。 僕なりの Vagrant, Chef の使い方 ここからはポイントに絞ってまとめていきます。 開発と運用とで Vagrantfile を分けた 上記の用途の違いから、もし両方の用途が想定される場合は、 そもそも Vagrantfile を複数ディレクトリで分けて管理するとすっきりします。 Vagrantfile 上には、複数の仮想マシンの定義が記述できるため、 まとめて書こうと思えば全然書けてしまうのですが、 目的が全然異なっているので、使うレシピも共通化しないケースが多くなってくると思います。 （例えば開発用であれば、本番環境ほどセキュリティに過敏にならなくても良い場合があります）
Vagrant で SSH の接続ポート番号を変えると、けっこう複雑になるという話
2015/04/01追記：続き書きました。Vagrant で SSH の接続ポート番号を変える、という発想がそもそも間違ってた 最近は、隙を見つけて（あんまりないけど） Vagrant + Chef で色々検証をしてたりします。 現実のサーバ構築になるべく即した形でレシピを書こうとしたとき、 SSH のポート番号を変更する、といったケースは往々にして出てくるかと思います。（デフォルトは22ですが、そのまま22を使うとアタックを受けやすくなるので変えましょう、という記事は山のようにありますね） SSH 接続のポート番号を変更 | EasyRamble ただ、Vagrant で SSH のポート番号を変更すると、ちょっとしたところではまってしまって 思いのほか時間がかかったところがあったので、その部分だけメモっておきたいと思います。 なお、CentOS 6 での検証です。他のディストリビューションで設定ファイルなどが異なる可能性はありますが、考え方などはほぼ共通しているかと思いますので、適宜置き換えて考えていただければと思います。 通常のサーバの設定箇所 まず、Vagrant などを使わずに設定する場合、どのファイルをいじる必要があるかというと、以下のファイルになるかと思います。 /etc/ssh/sshd_config /etc/sysconfig/iptables 1.は、SSH のポート番号を何番にするか？などの設定ファイルです。（もちろん他にも色々項目ありますが） こちらに、 Port 22 という設定が書かれているので、これを適当な番号、 Port 12424 などとして、 /etc/init.d/sshd restart で SSH のサービスを再起動することで設定が有効になります。 2.は、そのポート番号の通信を許可するかどうか？などの設定ファイルです。 こちらに、 -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT という設定が書かれているので、こちらも先ほどの番号に合わせる形で -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 12424 -j ACCEPT などとします。 こちらも同様に /etc/init.d/networking restart でネットワークの再起動をすることで設定が有効になります。
Chef の サードパーティ Cookbook を利用して、yum のリポジトリを追加してみる
よーし、いろいろアプリケーションのインストールの自動化しちゃうぞー！ と思っていましたが、 先に試しておいた方が良さそうなものがあったので、そちらを先にやります。 yum のリポジトリの追加 RPM系Linuxディストリビューション、つまり CentOS だったり、 Fedora などの Linux のディストリビューションでは、 yum (Yellowdog Updater Modified) と呼ばれるパッケージ管理システムが採用されています。 yum に限らずですが、ソースコードから毎回インストールするのはかなり骨の折れる作業だったりします。 （もちろんやったことない場合には、絶対経験しておくべき作業ではあると思うのですが。） この yum は、パッケージのインストールがコマンド 1行で出来るので非常に便利ではあるものの、そのまま使うと場合によってはちょっと古めのパッケージ（PHP5.3, MySQL5.1 など）がインストールされてしまいます。 ゲストOS上で、sandbox モードになった状態で試しに PHP をインストールしてみます。 ※これは、ゲストOSに実際にログインして手作業でコマンド打ってます。 [vagrant@vmclient1 ~]$ sudo yum install php （略） Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: php x86_64 5.3.3-22.el6 base 1.1 M Installing for dependencies: apr x86_64 1.3.9-5.el6_2 base 123 k apr-util x86_64 1.3.9-3.el6_0.1 base 87 k apr-util-ldap x86_64 1.3.9-3.el6_0.1 base 15 k httpd x86_64 2.2.15-28.el6.centos updates 821 k httpd-tools x86_64 2.2.15-28.el6.centos updates 73 k mailcap noarch 2.1.31-2.el6 base 27 k php-cli x86_64 5.3.3-22.el6 base 2.2 M php-common x86_64 5.3.3-22.el6 base 524 k Transaction Summary ================================================================================ Install 9 Package(s) Total download size: 4.9 M Installed size: 16 M Is this ok [y/N]: （y と入力） （略） Installed: php.x86_64 0:5.3.3-22.el6 Dependency Installed: apr.x86_64 0:1.3.9-5.el6_2 apr-util.x86_64 0:1.3.9-3.el6_0.1 apr-util-ldap.x86_64 0:1.3.9-3.el6_0.1 httpd.x86_64 0:2.2.15-28.el6.centos httpd-tools.x86_64 0:2.2.15-28.el6.centos mailcap.noarch 0:2.1.31-2.el6 php-cli.x86_64 0:5.3.3-22.el6 php-common.x86_64 0:5.3.3-22.el6 Complete! 入りました。さてバージョンを表示してみます。
Chef の Data Bag を使ってユーザー作成の自動化をしてみる
Chef のユーザー管理を突き詰めてみるだけでも、色々と勉強になっていますね。 前回までで、Chef の Cookbook にユーザー作成やグループ作成のレシピを記述することで、 ユーザー作成の自動化を試してみましたが、今回はもうちょっと複雑なことをやりたいので、 別の方法を試してみようと思います。 『入門 Chef Solo』によると、 システムに追加されるべきユーザーの各種データなどはノードの「属性」でもないし Resource の「属性」でもないデータと見ることができます。 こういったドメインモデル的なデータは Chef のデータ管理の仕組みである Data Bag を使うほうが扱いやすい。 (『入門 Chef Solo』 #19 Attribute と Data Bag より引用) とのことで、データを扱うための仕組みが存在するようです。 また、 Data Bag はクックブック単位ではなく、レポジトリ全体にグローバルなスコープのデータです。 (『入門 Chef Solo』 #19 Attribute と Data Bag より引用) ともありますね。 ということで、今回は Data Bag の仕組みを使って、もうちょっと凝ったユーザー作成の自動化をやってみようと思います。 まずは Data Bag を使ってみる この Data Bag、Cookbook とは別のところに書いて、Cookbook 側から読み込んで使う類のものらしいです。 対象ディレクトリの下に、種別のサブディレクトリを区切って、その中に JSON ファイルをデータごとに用意するようです。 であれば、まずは自分で作った cookbooks ディレクトリと並列なところに、 data_bags というディレクトリでも作り、users というサブディレクトリを作っておきます。 $ mkdir -p data_bags/users $ cd data_bags/users で、それぞれのユーザーごとに [ユーザー名].json のファイルを作ります。 ちなみにこの JSON ファイルは、あくまで任意のデータを扱うためのもので、あとで Cookbook 側から読み込むために用意するので、 前回設定した項目がこちらに用意できればオーケーですね。前回と同じことが出来るところまで設定しましょう。
Vagrant と Chef でユーザー作成の自動化をしてみる
だんだんと Chef いじりが楽しくなってきた girigiribauer です、こんにちは。 この前**『入門 Chef Solo』**というKindle本（電子書籍）を購入して、休憩時などに少しずつ読み進めていたのですが、 ようやくざっと一通り目を通すことができました。 今回以降、この辺も見ながらいろいろ試してみようと思います。 レシピを書くとどんなことが設定できるの？ 前回までで、Vagrant と Chef を連携させて、 超シンプルなレシピを書いてみたわけですが、 今回はレシピを書くことで他にどんなことが出来ちゃうのかを、もう少し試してみようと思います！ 『入門 Chef Solo』に、この Cookbook はユーザーの設定やらグループの設定やらが一通り載っていて、 最初に全体像を見るのにいいよ！と書かれていたので、まずはこちらの GitHub - treasure-data/chef-td-agent: Chef Cookbook for td-agent (Treasure Agent or Fluentd) Chef Cookbook for td-agent (Treasure Agent or Fluentd) - treasure-data/chef-td-agent github.com を参考にしてみます。 ログデータの収集に使うツールと、それ専用のユーザーなりを設定してくれる Cookbook のようですね。 recipes/default.rb を早速見てみます。 # # Cookbook Name:: td-agent # Recipe:: default # # Copyright 2011, Treasure Data, Inc. # group 'td-agent' do group_name 'td-agent' gid 403 action [:create] end user 'td-agent' do comment 'td-agent' uid 403 group 'td-agent' home '/var/run/td-agent' shell '/bin/false' password nil supports :manage_home => true action [:create, :manage] end directory '/etc/td-agent/' do owner 'td-agent' group 'td-agent' mode '0755' action :create end （以下略） 中身は Ruby のコードとはいえ、見ると何をやっているのかは何となく分かりそうな感じです。
Vagrant と Chef で仮想マシンの環境をいろいろいじれるようにしたい！
前々回、前回までで、ようやく気軽に作って壊せる仮想環境が用意できたので、 ここからは実際に仮想環境に作っていくところをやりたいと思います。 ※まだあやふやな部分が多いので、明らかに違っていた箇所はあとで修正する可能性があります。 もちろんゴールは、実際に少し作れるところまでです。（ファイルを自動で配置するとか、アプリケーションインストール済みの状態にするとか） ただ、そこまで大規模なものは想定していないので（数百台を一元管理とかは絶対やらない）、ローカル環境だけで気軽に試せる方法をとっていきます。 以下、こんな感じで最小構成で進めていきます。 Vagrant を最低限使えるようにする（終わってます） Chef を最低限使えるようにする 簡単な Cookbook を用意する Vagrant, Chef を連携させて、仮想環境が変化するか見てみる Chef とは？ 最近かなり頻繁に聞くワードです。 サーバ構築、システム管理の自動化を助けてくれるツールです。アプリケーションのインストールや、OS・ミドルウェアの設定などを、Cookbook と呼ばれる設定ファイルに落とし込んでおくと、各プラットフォームの差異を吸収したうえで、その設定ファイルの状態に保ってくれます。 詳しくはまだまだこれからです。ただ気軽に試せる環境を用意したので、ここからどんどんと試してみようと思います。 また、自動化というメリットの他にも、こういう気軽に試して壊してが出来るってところは大きなメリットだなーと思います。 では早速。 Chef をインストール まず Chef に関連したパッケージを gem でインストールしてみます。gem ならば比較的すぐです。 $ gem install chef Fetching: chef-11.4.4.gem (100%) Successfully installed chef-11.4.4 1 gem installed $ chef-solo -v Chef: 11.4.4 chefというパッケージを入れると、chef-solo, chef-client, knife などのコマンドが一式用意されるようです。試しに chef-solo -v と打ってみたら、「Chef のバージョンは11.4.4ですよー」と表示されました。 ちなみに、数百、数千台とか管理するわけでもないので、Chef Server を用意してうんぬん・・・というのは今回やらずに、 サーバの役割を内包しつつ単独で動く、Chef Solo を使っていきます。 さてさて、何か Cookbook を作ってみることにします。 Cookbook を作る！ ※以下、2012年10月に発売された『Software Design / Chef 入門』を参考に進めます。
Vagrant に仮想マシンのスナップショットがとれる sahara というプラグインを入れた
個々の仮想マシンのアプリケーションを入れていく前に、仮想マシンの操作でよくある**『スナップショット機能』**的なものが使えるように、 Vagrant のプラグインの追加をしたいと思います。 sahara プラグインのインストール Vagrant 1.0 までは vagrant に続けて gem サブコマンドで入れられたようですが、 Vagrant 1.1 以降は、plugin サブコマンドを使うようです。 と思って試したら、どうやら Vagrant1.1 以降では対応してないようで・・・。 で色々と調べていたら、対応させている方が！素敵ですねー。 Vagrantの必須プラグインSaharaをVagrant 1.1に対応させました | Ryuzee.com こちらの方の記事にもあるように、『Vagrantを使っている人であれば必携のプラグイン』とあるので、 これはぜひとも入れておき、砂場のように作りは消し、作りは消しが簡単に出来るようにしておきたいですね！ （必携といわれるくらいなので、ひょっとしたら後で記事見直したら、この辺きちんと整備されているかもしれませんね。） $ git clone https://github.com/ryuzee/sahara.git （略） $ cd sahara $ bundle install Fetching gem metadata from http://rubygems.org/.......... Fetching gem metadata from http://rubygems.org/.. Resolving dependencies... Using rake (0.9.2.2) Installing Platform (0.4.0) Using bundler (1.3.5) Installing open4 (1.3.0) Installing popen4 (0.1.2) Installing thor (0.18.1) Using sahara (0.0.14) from source at . Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed. $ bundle exec rake build sahara 0.0.14 built to pkg/sahara-0.0.14.gem. bundle 使ってビルドすると、 sahara/pkg/ 以下に gem ファイルが出来ました。これを以下の代わりに
仮想環境を CUI（コマンドライン）でいじれる Vagrant を試してみた
もう最近では、OSの上にOSを動かす仮想環境が当たり前になってきていますが、そのソフトウェアの1つに VirtualBox というものがあります。 Vagrant は、元々この VirtualBox を CUI（コマンドライン）でいじれるツールだったのですが、 バージョン1.1以降で VirtualBox 以外のソフトウェアにも対応してくれるようになったため、 今では VirtualBox に限らず使えます。 ちなみに個人としては、Windows に関しては描画の再現性なども考慮して、Mac 上で VMWare Fusion （有料）を起動して、その上に Windows7 やら Windows8 やらをインストールして検証用に使っています。（それでもさくさく動く Retina MacBook Pro 最高ですね！） 一方で、サーバ用途に用いられるような、描画の再現性を考えなくてもよいOSについての検証は、VirtualBox を起動して、その上に CentOS などを入れて今後検証していこうかなと考えています。（まだまだこれからです） このような、後者のサーバ用途に用いるOSの検証で、いちいち VirtualBox（や他のソフトウェア） を GUI から立ち上げて、GUI でぽちぽちとインストールを行って、起動させるような作業を毎回繰り返す場合、Vagrant はかなり役に立ってくれるのではないかと思います。 まずは Vagrant の準備の仕方や考え方などを軽くまとめてみました。 VirtualBox, Vagrant のインストール まず、事前に VirtualBox を入れておきます。（Vagrant 1.1 からは必ずしも VirtualBox ではなくてもいいのですが、前述の通り今回はサーバ用途で VirtualBox を使うという前提での準備なので、VirtualBox でやります） Vagrant の 1.0 も入れたことがあるのですが、こちらは gem install vagrant で一発インストールだったのに比べ、1.1以降は専用のパッケージをインストールします。（ちなみに記事書いてる時点の最新は、1.2.2 のようです） なんか開発速度がめちゃ早いので、あとでこの記事見返したらバージョン古くなってることでしょう。 あとは普通にインストールをしていきます。 はい、インストール完了しました。