注意
本記事は Deis v1.x について書いています。
最新の Deis は v2.0.1 で、基盤が Fleet から Kubernetes になるなど大きな変更がありましたので、本記事は参考になりません。
この記事の目的
Engine Yard さんが主導して開発を進めている Micro PaaS 実装の Deis は，類似実装よりも安定して稼働します．
大人の事情で Heroku が使えない職場でも，Hubot や，ちょっとした業務改善 Rails アプリをお気軽にデプロイできるようになるので，かなりオススメです．
しかし，日本語でも英語でも情報が断片的で，最初はインストールでハマります．…というか，私は大いにハマりました．ので，メモ．
(コンテナデプロイ中の暇な時に，加筆していきます．)
Azure の記事の内容を鵜呑みにしてはいけない
ググると，Deis 本家の情報よりも上位に Azure の記事が出る場合があります．Azure の記事は日本語版 もあり，つい頼りたくなりますが，本稿執筆時点ではお勧めしません．
記述の内容と，Azure が github.com で公開しているスクリプトの内容とが一致しない上に，かなり古いバージョンの CoreOS がインストールされるため，一手間かけないと DockerHub からコンテナをデプロイできません．
どう一手間をかければよいのかは，私が Deis の issue に残してありますが，本家の情報に従ったほうが確実です．
ただし，本家の情報もいろいろ足りていないところがあるので，一読しておくことは無駄ではありません．
再デプロイ時には，create-azure-user-data の再実行を忘れない
最初の頃は，いろいろと設定に失敗して，Azure のリソースグループの削除と再デプロイを行うことになると思います．
その際，は，他の設定はそのままでも create-azure-user-data の再実行は忘れずに行わなければなりません．
$ ./create-azure-user-data $(curl -s https://discovery.etcd.io/new)
これを忘れると，issue に上がっているようなエラー で先に進めなくなります．
加えて，azure-user-data が書き換わったわけですから，BASE64 化して， parameter.json の書き換えすることもお忘れなく．
parameter.json に記入する公開鍵は空パスワードで作る
これを忘れるとどういうエラーになるのかは忘れましたが，うまく行きません．
この公開鍵に対応する秘密鍵はあとで deisctl コマンドでインストールしますが，
その後の運用では登場しません．
platform のインストール完了後に deis コマンドで(ユーザや管理者が)使う鍵ペアはこれとは別に管理されますし，むしろ一緒にしないようがセキュリティ上も宜しいかと思います．
Azure へのリソースデプロイ時の進捗確認や失敗原因分析
Deis のデプロイに限らないので，別の記事にしました．
バージョン不一致に注意する
これは，何ヶ月か前にデプロイを経験したインストール職人が陥りやすい罠です．
Deis は下記の3つの要素から成り立っています．
- platform (CoreOS 上にある)
- deisctl コマンド (クライアント側にある)
- deis コマンド (クライアント側にある)
これらのバージョンは，必ず一致させてください．
不一致な場合でも，運が良ければ動きます．でも大抵の場合，よくわからない 500 エラーなどが出て悩まされます．
「マイナーバージョンが上がった場合，互換性はほぼ無い」くらいに思っておいたほうが安全です．
DNS の設定は，秘密鍵のインストール後にする
DNS の設定が伝搬されるには，それなりの時間がかかります．
そして，インストールに失敗して Azure への再デプロイをした場合には IP アドレスは変わります．
よって，ほぼ失敗は無いという確証が得られるまで， DNS の設定は遅延させたほうがトラブルが少なくなります．
また，下記列挙のようなことも考慮すると良いと思います．
- ワイルドカードのレコードは A ではなく CNAME にする
- A レコードの TTL は可能な限り短くしておく
- Route53 や AzureDNS など，クラウドとの親和性の高い(伝搬の早い) DNS サービスを選ぶ