consulとstretcherによるデプロイの検証

概要


consulのevent発行=>event watchの機能をフルに使ったデプロイになります。
event watchで起動されるデプロイツールがstretcherになります。

前提条件


オートスケーリングをする
ソースgzとかしてS3においておく
各サーバがS3からソースをダウンロードして展開する(stretcher)
オートスケーリングの仕組みは別途あるものとする

検証


consulの基本的な設定
webの場合
#/etc/consul.d/web.conf

/etc/consul.d/event.conf

インスタンスの作成時

サーバの起動スクリプトに以下を仕込んでおく
/usr/local/bin/stretcher s3://example/manifest.yml
アプリのリリース時
s3にリリースするソースファイルをアップしておく
s3のmanifest.ymlを更新しておく
consul event発行

クラスタリスタートさせる場合

/etc/consul.d/web.confに定義出来る

  • name
  • service
  • tags

の設定で頑張る事でなんとかなりそう。
具体例
/etc/consul.d/web.conf(クラスタ1のグループのサーバ)

/etc/consul.d/web.conf(クラスタ2のグループのサーバ)

クラスタ1のリスタートイベント発行

クラスタ2のリスタートイベント発行

1台だけ新しいソースにして動作確認する

これはサーバイメージの更新の時もありうるので
オートスケールの最低台数を+1する想定だけど
新しいmanifest-prerelease.ymlとかを作成して
/usr/local/bin/stretcher s3://example/manifest-prerelease.yml
として手で叩くでも良い。
それか、例えば、nginx.jsonに以下のような設定を入れ
サーバ1

サーバ2

サーバ3

サーバ4

consul reloadしてから

とすると、サーバ1だけにイベントが飛びます。

とすると、サーバ1とサーバ2にイベントが飛びます。

とすると、サーバ3だけにイベントが飛びます。
/etc/consul.d/nginx.jsonを、直接いじりたい場合(例えば、一台だけprerelease機にしたい場合)に
直接入ってファイルをいじって、consul reloadすれば、設定が更新されます。
その後に

とすれば、1台だけリリース可能。

全台デプロイ完了の検知

全台デプロイを検知する仕組みとして
consulの持つKey/Valueの仕組みを利用すると実現可能。
手順
deployイベント発行時にデプロイスクリプトであらかじめ

をしておく。

渡すmanifestファイルを以下のように

としておく。

としておく。
デプロイ時のスクリプトなどで
consul event〜〜
発行後

を監視。
keysがなくなれば全台デプロイ作業完了
最後に

を取得し
エラーがないことをチェックしてデプロイフローの完了となる。

感想

という事で、イベントを送る先をtagsで良い感じに制御出来ればconsulとstretcherによるデプロイは良さそうな気がします。
全台デプロイ完了の検知は、consulのイベントとかステータスとかだけでやりたかった。けど、なかなか上手くいかない。
引き続き良い方法があれば調べたい。
manifest.ymlはデプロイスクリプト(capistrano?)で自動で更新されるようにしたいため、ここにhook処理が羅列されるのは嬉しくない。
ソースを固めてs3に上げてmanifest.ymlを作るという部分はまだ考慮しきれていない。
各サーバでserviceにcheckという設定(このページではconsulの基本的な設定のweb.json)を付けると、指定したチェックが通るまではserviceとしては追加されないので
ロードバランサにぶら下げるときにも
consulのヘルスチェックを見てゴニョゴニョ出来たらいいのかと思ったりしました。

補足

イベント発行のAPI

見やすさアップ。gendosu.jpのデザインを修正しました

実は、一つまえのgendosu.jpは、全体的に字が大きくて

お年寄り向けになっていた(おい!!)気がしたので

今回思い切って新しいデザインに変えてみました。

old-site

こんな感じから…….

new-site

こんな感じへ。

アイキャッチ画像も出るようにしました。

そして、なんかヘッダ周辺、最近っぽくないですか??

個人的にはなんか良い感じになったと思います。

検索もボタンが付いてわかりやすい。

レスポンシブなので、スマホで見てもタブレットで見ても

それらしく表示されます。

これでアクセスがアップ!

となれば良いのですが。

 

 

 

 

 

 

 

ま、ただのテーマ変えですが。。

開発サイクルをブースト!するかもしれない。Dokku触ってみた(初期編)

開発環境って、一度作るとあとはそれほどいじらないのでいいんですが

適当に作ったけど適当に社内で公開したい場合にお気軽にデプロイしたい。

Capistrano使ったりするのもいいんだけど…。

それに、小さめのツール類が多いんだけど、毎回nginx立ててポート変えてとかconfでゴニョゴニョして公開するの、面倒。

サクッとデプロイしたら即公開みたいな環境ないかなー。herokuみたいな。

と思って探したらdokkuというのがあったので、触ってみました。

dokkuとは


OSSのherokuライクなPaaS実装。
dokkuを入れたサーバに対してgitでプッシュするだけでデプロイ完了します。
バックエンド(MySQLとかRedisとか)はプラグインで対応。

公式

https://github.com/dokku/dokku

調査


まずは手元で動作確認。

vagrantを使っての動作確認をしていきます。

まず、何も入っていないvagrantのvmを起動します。

バージョン違いで動かないのは嫌なので、公式通りUbuntu14使います。

調査用Vagrantfile
https://github.com/gendosu/vagrant-dokku

以下のdokkuのインストールをvagrantのprovisionに入れてあるので、自分で手順を試す場合は

としてください。

しばらく待つと起動する。

起動したらvmにログインします。

続いて、dokkuのインストール。

公式にある通りにコマンドを入れます。
https://github.com/dokku/dokku

で初期設定画面が待機しているので、開いてこれが完了すると、

http://[dokkuを入れたサーバのIP]/

id_rsa.pubのキーとドメイン名を設定して初期設定します。
初期設定画面で入れるドメインは、とりあえず触る程度であれば
ドメイン名にIPを含ませて叩くと常にそのIPを返してくれるという
xip.ioというサービスがあるので、これを使います。
もしdokkuを本番に組み込むようなことがある場合、自分でワイルドカードドメインを設定する必要があると思います。
ということで、vagrantで起動したvmのIPを使ってドメイン名を作ります。
dokku.172.28.128.5.xip.io

dokku-domain-setting

こんな感じになるかと思います。
Finish Setupボタンを押すと、設定が完了します。
続いて、ローカルのマシンの方にdokkuのクライアントを入れていきます。
多分公式のshellでやるのが手っ取り早いので、そのままコマンド実行します。

ローカルに適当にテスト用のrailsプロジェクトを作ってデプロイしてみましょう。これでローカルのマシンでdokkuコマンドが使えるようになりました。

今回は本当にとりあえずなので、公式サイトの
Deploying an Application
からサンプルリポジトリを使ってデプロイします。

サーバに入って、postgreSQLのプラグインを入れておきます。

再びローカルで、postgresqlサービスを作成して、アプリにリンクさせておきます。

デプロイはherokuとほとんど一緒です。これで、デプロイ準備は整いました。

でdokku

が追加されていると思います。(dokku apps:createで作成される)
このリポジトリに対してpushするだけでアプリがデプロイ出来ます。

早速デプロイされたアプリにアクセスしてみます。
http://ruby-rails-sample. dokku.192.168.1.1.xip.io
以上です。

感想


heroku cloneそのままという印象。
裏でdockerが動いているが、ほぼ意識しなくて良い。
dokkuはスタンドアローンな仕組みなので、スケールさせるサービスには向かないと思います。
社内で適当にサイトを立ち上げてプレビューするとか
外部公開でも絶対にアクセスが増えないとか
ローカルだけどherokuみたいに気軽にデプロイしてサーバで動いているのを確認したいとか
そーいう用途向きのプロダクトに感じました。
スケールさせることが前提なのであれば
deisやflynnといったプロダクトを使ってみるのがいいかもしれません。
最近だとDocker社がApache Auroraを手中に収めてたりするので
DockerでいくのであればApache Mesosあたりを試してみるのもいいかもしれません。

参考サイト