serverspec

ufw = Uncomplicated FireWall です。 レシピはこんなのを作りました。opscode のレシピとか使うと、何設定し ているか分からず結局全部読むことになるので自前で書いてます。 execute 'ufw reload' do action :nothing end execute 'ufw default deny' do not_if 'ufw status verbose | fgrep "Default: deny (incoming)"' notifies :run, 'execute[ufw reload]' end execute 'ufw allow http' do not_if 'ufw status | egrep "^80 +ALLOW"' notifies :run, 'execute[ufw reload]' end execute 'ufw allow ssh' do not_if 'ufw status | egrep "^22 +ALLOW"' notifies :run, 'execute[ufw reload]' end execute 'ufw enable' do command 'yes | ufw enable' not_if 'ufw status | fgrep "Status: active"' end serverspec はだいたいこんな感じです。...

[2014-01-09-1] からWerckerを使い始めて1年とちょっと。このたび CircleCIに移行しました。理由は以下のとおり。 会社のJenkinsが壊れてCircleCIを使い始めた。2つ覚えているのが面倒 [2015-01-25-1] の継続的bundle updateをやりたい(WerckerはAPIがないっぽい) [2014-01-09-1] 当時と違いCircleCIは1コンテナまで無料になった Werckerは自分のBoxを簡単に作れたのが良かったんですけどね。 (masutaka/wercker-box-rvm-vagrant-aws の更新は停止します。) 特殊なことはしていないので、Vagrantfileとcircle.ymlを晒すだけにし ておきます。 CircleCIはコンテナにsshログイン出来るのは良いけど、EC2インスタンス が起動されてそのままになるような。。。さっさとDockerに移行しないと。

[2014-09-14-1] に書いたとおり、このmasutaka.netではサーバのCIをして います。 今までテストが通ってから、手動でCook+Serverspecして不便に感じてませ んでしたが、試しにWerckerのデプロイ設定をしてみたら、案外便利でよく 使っています。 wercker.ymlはこんな感じです。 管理画面からDeploy targetを作る必要があります。ちょっと管理画面が古 いですが、こちらを参考にしてください。 wercker + Capistrano で自動デプロイ - milk1000cc’s blog 私はTarget nameをProductionにして、SSH keysで作った鍵を $WERCKER_SSH_KEY_PRIVATEという名前でwercker.ymlから参照できるように しました。 ブラウザからWerckerのサイトに行くのが面倒だけど、個人でChatOpsやっ てもなあ…。とはいえ、やるかもしれませんが。

[2014-01-09-1] からmasutaka.netのCIを開始したが、残念ながら masutaka.netに直接serverspecする、なんちゃってCIだった。 masutaka.netにcookしてからPRを出して、WerckerにCIさせていた。 WerckerとAWSを連携させて、テストのたびにサーバをまっさらな状態から 作り、終わったら破棄することが可能になったので、ここに記録しておく。 去年くらいに話題になったこの辺の話。 Vagrant + Chef Solo + serverspec + Jenkins でサーバー構築を CI - naoyaのはてなダイアリー naoya/circleci-serverspec なんで今までやらなかったかというと、cookが一発で通らないレシピになっ ていたから。。気づいてはいたんだけど、本番サーバのテストが通りさえ すればよかったし。。。 インフラ系技術の流れ - Gosuke Miyashita こちらの記事でいうところの、Orchestrationの仕事までChefにやらせてい たのが敗因。GitHubのprivateリポジトリにおいてあるdotfilesや、 growthforecast、tiarra、mobircまでもChefにインストールさせていた。 ユーザmasutakaに依存しないレシピに変更して、手元の Vagrant+VirtualBoxで一発でspecが通るまでがステップ１。 次に手元のVagrant+AWSで同じことが出来るまでがステップ２。 これをWercker上で実行できるようにwercker.ymlを書き換えたのがステッ プ３。 最終的なVagrantfileとwercker.ymlは以下のとおり。 いくつかハマったけど、凡ミスだったので特には触れない。上の設定に従 えば同じことは出来るはず。(CircleCIだと各インスタンスにssh出来るの で、調査は早かったんだろうと夢想。) でも一点だけad hocな対応をしていて、plenvやrbenvを使ったPerl/Rubyの インストールはビルド済みのtar ballを展開するだけに変更した。 Werckerはビルドが5分間止まると失敗だと見なすから。ビルド全体の時間 は25分までOK。 そもそもImmutable Infrastructure的にplenvやrbenvを使うのはどうなの？ という節もあって、そこは今後変えるかもしれない。 wercker.ymlも毎回Vagrantをインストールして、vagrant upするという無 駄なことをしているので、Docker使って時短させるかもしれない。 とりあえずCI出来るようになったので、今回はこれで良しとする。

serverspecでは、このようなテストを書くことが多いと思います。 describe file '/var/www/vhosts' do it { should be_directory } it { should be_owned_by 'root' } it { should be_grouped_into 'www-data' } it { should be_mode 775 } end describe file '/home/masutaka/.ssh/authorized_keys' do it { should be_file } it { should be_owned_by 'masutaka' } it { should be_grouped_into 'masutaka' } it { should be_mode 600 } end テストはDRYにしすぎるべきではありませんが、数が増えてくるとさすがに 冗長なのでこのように変更してみました。 describe file '/var/www/vhosts' do it_behaves_like 'a directory root:www-data 775' end describe file '/home/masutaka/....

[2013-05-27-2] で書いたとおり、このブログのサーバmasutaka.netは Chef-soloでレシピを、serverspecでそのテストを書いています。 ソースコードはGitHubのプライベートリポジトリに置いており、お金をか けてまでやる気が出なかったのでCIはしていませんでした(※)。 ※ CircleCIの場合、一番安いプランで$19/month はてブのホットエントリでこちらの記事を見つけたので、serverspecのCI を設定してみました。 Githubのプライベートリポジトリでも無料で使えるCI、Werckerを使ってrails newからHerokuのデプロイまでやってみる｜mah365 serverspec固有の設定 基本的な手順は記事のとおりなので、詰まることはないと思います。 ただしserverspecはssh経由で動作するため、sshの設定が必要です。 (1) WerckerのサイトでSSH key pairを作成する (2) ユーザmasutakaとしてssh接続する設定をする (3) ssh接続した時にknown_hostsに追加するか聞かれない設定をする (1)は以下のサイトが参考になりました。 wercker + Capistrano で自動デプロイ - milk1000cc’s blog wercker.ymlの中で秘密鍵を $WERCKER_SSH_KEY_PRIVATE として参照できる ようになります。公開鍵はmasutaka.net:~/.ssh/authorized_keysに追記します。 最終的なwercker.yml (1)の秘密鍵$HOME/.ssh/id_rsaは39行目で作っています。 (2)と(3)は26行目で$HOME/.ssh/configに設定しています。 (2)は33行目の"User masutaka"、(3)は34行目の"StrictHostKeyChecking no"です。 見たまんまですが、serverspecは49行目で設定しています。 wercker.ymlの書式 基本的な書式は http://devcenter.wercker.com/articles/werckeryml/ で 分かると思います。wercker.ymlのValidaterもありました。 bundle-installやcreate-fileは拡張という扱いなのか、 https://app.wercker.com/#wercker にアプリとして存在してました。 ドキュメントもあるので、必要に応じてどうぞ。 ビルド結果 Werckerの各アプリのページでもちろん分かりますが、 各Pull Requstのページでも分かるので、今後はローカルでTest&Cookして Pull Requst出す、ビルドが通っていればmasterにマージという使い方をし そうです(Collaboratorはもちろん私一人)。 Werckerバッジ TravisCIやCircleCIでお馴染み、ビルドステータスが分かるバッジも 各アプリのページ、右上から取得できます。 README.mdに追加しました。