[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に移行しないと。
WERCKER-BOX-RVM-VAGRANT-AWS - wercker Vagrant-1.7.2に対応しました。 Vagrant-1.7.1で必要になったworkaroundを削除出来ました。 CHANGELOG のこれが相当するのかな installer: SSL cert bundle contains 1024-bit keys, fixing SSL verification for a lot of sites. 会社のJenkinsマシンに入れているVagrantもバージョンアップしよう。
WERCKER-BOX-RVM-VAGRANT-AWS - wercker Ruby-2.2.0に対応しました。 このPRがマージされるのを待ってました。 https://github.com/wercker/box-rvm/pull/9
WERCKER-BOX-RVM-VAGRANT-AWS - wercker Vagrantを最新の1.7.1にしました。 メジャーバージョンも思い切って'1’に上げました。 今のvagrant-aws(v0.6.0)とUbuntu-12.04の組み合わせだとvagrant (up|destroy)に失敗しますが、うまく対策出来たのでリリース＆アナウン スすることにしました。 ‘1.0.0’で対策なし、‘1.0.1’で間違ったworkaroundを追加、‘1.0.2’で修 正したので無駄にバージョンが上がっています。 こうしたらうまくいったよコメント 実際に対策した修正 P.S. werckerでvagrant-awsを含むBoxは自分の含めて2つしかないけど、EC2使っ たサーバのCIって需要少ないのかな？不思議。
WERCKER-BOX-RVM-VAGRANT-AWS - wercker Ruby 2.1.4がリリースされたので。 とは言え、こいつが使っているBOX-RVMのバージョンを上げて デプロイし ただけです。 WerckerはDockerに似たBOXを使用するので、継承元のBOXが更新されたら デプロイし直す必要があります。 Wercker上でAWSを使ったサーバのCIする方法は[2014-09-14-1] 、 WERCKER-BOX-RVM-VAGRANT-AWS自体の説明は[2014-09-15-1] をどうぞ。
[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-09-14-1] の記事より。 wercker.ymlも毎回Vagrantをインストールして、vagrant upするという無 駄なことをしているので、Docker使って時短させるかもしれない。 この場合Dockerは間違い。Wercker的にはBox使うのが正解なので作ってみ ました。(このくらいのBoxはあるかと思ったらなかったのが意外でした。) 以下のようにinheritsを使うと、任意のBoxを継承できるみたいです。 ちょっと前までwercker.ymlに複数書けばそうなるかと思ってました。 inherits: wercker/rvm@2.0.1 実コードはスクリプトのベタ書きだけです。 script: | VAGRANT_VERSION=1.6.5 wget https://dl.bintray.com/mitchellh/vagrant/vagrant_${VAGRANT_VERSION}_x86_64.deb sudo dpkg -i vagrant_${VAGRANT_VERSION}_x86_64.deb vagrant plugin install vagrant-aws unf あとはWerckerの管理画面からGitHubのリポジトリを登録し、Wercker directoryにデプロイすれば使えます。Public Appにすることをお忘れなく。 wercker.ymlはこのようになりました。昨日 と比べるとBoxがwercker/rvmか らmasutaka/rvm-vagrant-awsに変わったことと、vagrantやvagrant-awsプ ラグインをインストールしてないのが分かると思います。 Boxの作り方自体はこちらが参考になると思います。 werckerで自分のBOXを作ってみた - 紺屋高尾 11分33秒かかっていたテストが10分46秒に短縮されました！ って、あれ、あんまり変わってない。。 パフォーマンス云々より、Dockerっぽく改善できたので良しとします。 今度はEC2使わずにWerckerでDocker立ち上げてCIしたいなあ。
[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出来るようになったので、今回はこれで良しとする。
[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に追加しました。