Act As Aws Architect: OpsWorksで動かすルールをvagrant+chef soloを使ってローカルでも試せるようにする

OpsWorksで動かすルールをvagrant+chef soloを使ってローカルでも試したい！
と思いませんか？

OpsWorksそれ自体はお金はかからないとはいえ、OpsWorksから起動されるec2と付随するいくつかのサービスにはお金がかかります。それを vagrant を使ってローカルで試行錯誤できればお金はかかりません。

OpsWorksはchefで作られていることは周知の事実です。
http://docs.aws.amazon.com/opsworks/latest/userguide/welcome.html にも以下の通り書かれています。

AWS OpsWorks uses its own Chef recipes to configure the instances on a stack. Chef Solo runs on every instance, and AWS OpsWorks sends commands to each instance to run recipes that set up, configure, and shut down the instance. You can extend these actions with your own custom recipes. You can also run your custom recipes on a specific instance or on all instances in your stack.

というわけで、ちょっとやってみましょう。

chefむけにかかれたルールはgitで管理するのが、よくある楽な方法です。そのため、一番ラクなのは「全てのシステム記述を一つのgitに書く」こと。
全てのシステム記述を同じgitに書いていれば、chef soloをopsworksの代わりに使うことでほぼテストはローカルでできる。

と、言いたいところですが、OpsWorksのGUIで設定する部分と、chef soloむけの設定には差異があるので、ちょっとしたコツが必要になります。

ec2の代わりとしてvagrantの中でUbuntuを動作するようにする。
OpsWorks代わりのchef solo環境をlocalに用意する
設定(site-coolbooks)はbitbucketに配置する

ここでのポイントは、手元につくったChef SoloはあくまでもOpsWorks代わりをさせるためであり、手元のChefSoloには最低限の設定ですませること。

ちなみに、bitbucketは無料でも秘密レポジトリを作れるので、OpsWorksむけにはgithubよりも楽だと思います。

これから書くことはこんなかんじ。OpsWorksの進化はきっととまらないので、今の時点での私のおすすめってことで！

vagrantのインストール ¶

vagrantは
http://downloads.vagrantup.com/
から、自分の環境にあったものをインストール。

昔はRubyGemをつかってインストールしていたが、今は違うので素直にパッケージを使うべきでしょう。

boxでubuntuを用意 ¶

vagrant box コマンドをキメる

$ sudo vagrant box add ubuntu-1204-server  http://goo.gl/8kWkm

initしてログインしてみる ¶

問題なくログインできるはず。

$ vagrant init ubuntu-1204-server
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'ubuntu-1204-server'…

$ vagrant ssh
Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-32-generic x86_64)

ここまでできてればひとまずOK。

$ sudo gem install chef chef-solo

あたりでOK。

Chef SoloでOpsWorks代わりのレポジトリ作り ¶

ここでのポイントは、手元につくったChef SoloはあくまでもOpsWorks代わりをさせるためであり、手元のChefSoloには最低限の設定ですませること。

まずは手元にchef soloの環境を作る。ここではcdn-dns-v2という名前。
これが大本のchef soloであり、

$ knife solo init cdn-dns-v2

つくったディレクトリに移動して

rm -rf site-cookbooks/

いったんgit登録。して、commit.

git add .
git status
git commit

設定(site-coolbooks)の用意 ¶

手元のChefSoloとOpsWorksの両方で共通で使う設定(site-cookbooks)は
bitbucketに配置させる。

まずは site-cookbooks作り。¶

共通で使う設定 であるため、可能な限りこのsite-cookbooksに詰め込むことになる。

knife cookbook create dnsbalance -o dnsbalance
** Creating cookbook dnsbalance
** Creating README for cookbook: dnsbalance
** Creating CHANGELOG for cookbook: dnsbalance
** Creating metadata for cookbook: dnsbalance

$ tree
.
└── dnsbalance
       └── dnsbalance
               ├── CHANGELOG.md
               ├── README.md
               ├── attributes
               ├── definitions
               ├── files
               │     └── default
               ├── libraries
               ├── metadata.rb
               ├── providers
               ├── recipes
               │     └── default.rb
               ├── resources
               └── templates
                      └── default

12 directories, 4 files

dnsbalance/dnsbalanceと、二段に深くなったディレクトリ構成だが、これはそういうもんだと諦めることにする。

共通で使う設定 であるため、可能な限りこのsite-cookbooksに詰め込むと

$ tree
.
└── dnsblance
      ├── .git/config (ここは略)
      └── dnsbalance
            ├── CHANGELOG.md
            ├── README.md
            ├── attributes
            │    └── default.rb
            ├── metadata.rb
            ├── recipes
            │    └── default.rb
            └── templates
                  └── default
                        ├── dns_balance.sbin.erb
                        ├── init.erb
                        ├── ssh-config.erb
                        ├── td-agent.conf.erb
                        └── td-agent.conf.erb~

という具合になる。このレポジトリをbitbucketに追加する。

bitbucketに登録 ¶

追加の仕方はいろいろだが、
git remote add origin ssh://git@bitbucket.org/ar1/chef-cookbook-dnsbalance.git
といった具合。このときの .git/configを抜粋すると

[remote "origin"]
        url = ssh://git@bitbucket.org/ar1/chef-cookbook-dnsbalance.git
        fetch = +refs/heads/*:refs/remotes/origin/*

親レポジトリのサブモジュールとして追加 ¶

親レポジトリ（OpsWorksの代理として動作するレポジトリ）のディレクトリに移動。
そこのトップで、
submoduleとして、追加する。

git submodule add git@bitbucket.org:ar1/chef-cookbook-dnsbalance.git site-cookbooks

その結果

$ tree
.
├── Berksfile
├── Berksfile.lock
├── cookbooks
├── data_bags
├── nodes
│   └── vagrant-ubuntu.json
├── roles
└── site-cookbooks ((ここより下が追加されている))
    └── dnsbalance
        ├── CHANGELOG.md
        ├── README.md
        ├── attributes
        │   └── default.rb
        ├── metadata.rb
        ├── recipes
        │   └── default.rb
        └── templates
            └── default
                ├── dns_balance.sbin.erb
                ├── init.erb
                ├── ssh-config.erb
                └── td-agent.conf.erb

10 directories, 12 files

という具合になる。

vagrantでつくったubuntuにデプロイさせる ¶

run_listに追加、実行 ¶

vagrantの中にデプロイするためにrun_listに追加

cdn-dns-v2/nodes$ cat vagrant-ubuntu.json
{"run_list":[
     "dnsbalance"
]}

これを加えれば、site-cookbooksの下にあるdnsbalanceの中にある recipes/default.rb を実行させることができる。

あとは
knife solo prepare vagrant-ubuntu

vagrant-ubuntuの中にchefが用意され、

後に
knife solo cook vagrant-ubuntu
を実行すれば、

親レポジトリの nodes/vagrant-ubuntu.json が読み込まれ、
その結果、recipes/default.rb を実行させることができる。

submodule内容変更時にやること ¶

submoduleで書いたコードに変更があれば

git submodule foreach 'git pull origin master'
を行う

できあがりました！あとはやるだけ！

Act As Aws Architect

2013年12月5日木曜日

OpsWorksで動かすルールをvagrant+chef soloを使ってローカルでも試せるようにする

vagrantのインストール ¶

boxでubuntuを用意 ¶

initしてログインしてみる ¶

vagrant ssh-configの出力を .ssh/configに登録し、vagrant-ubuntuという名前でログイン可能にする ¶

Chef Solo環境の用意 ¶

install ¶