開発サイクルをブースト!するかもしれない。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あたりを試してみるのもいいかもしれません。

参考サイト


ローカルで環境ごとの仮想マシンを起動してるときにWARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!が出る場合の対処方法

というのは、SSHログインするときに
「SSH host key」というのを、確認してて
以前known_hostsに登録したものと違う場合に出すメッセージで
普段はほとんど出ないはずですが
仮想マシンで同じIPで別の仮想マシンを起動してたりすると
良く出ます。

たとえば、localhost:2200で仮想マシン1にSSHする時に

と聞かれて、yesとすることで

known_listsに仮想マシン1のHost Keyが登録されます。

この状態で
仮想マシン1を落として
仮想マシン2を再度localhost:2200で起動させた場合に

上記のワーニングが出ます。
これがめんどくさいので
localhostへのssh接続の場合は、このワーニングを出ないようにしたいと思います。

で、以下を追記

これでワーニングが出なくなります。