PaaSにおける3種類のデプロイ
アプリのデプロイ
利用者A→利用者Aのアプリ→利用者Aのシステム→PaaSバックエンドシステム
手動書による手動デプロイ 手動クラウドへのデプロイ 常時結合している
デプロイ 工数 理想値で8人日(実際は理想値の倍程)
ある種のドッグフーニング
→大きなデプロイ工数によるさぼり
既存のデプロイには差分だけ適用
新規顧客を探しに行きにくくなる
手動書→Chef Solo(記述が簡単+セットアップも楽)
- パッケージの集約
- ビルド後にパッケージ集約ジョブを呼び出す
- ビルドジョブからアーティファクトをコピー など
- マシンの用意
- 各種CloudPlugin(Amazon EC2 Pluginなど)
- 任意のタイミングでVM制御が必要
- デプロイ手順としてリブート
- マシンに直接ログインして試行錯誤
- Java, Git, Ruby, Chef-soloをインストールしたテンプレートVMを用意
- テンプレートからVMを作りそこにデプロイ
- デプロイの実行
- ノードにまたがって逐次実行など
- PaaSバックエンドシステムは複数台
- Parameterized Triggerで各スレーブにデプロイ
ソースレポジトリ ビルド用スレーブ デプロイ用スレーブ Jenkinsマスター
必要に応じてスレーブを作成する
スローデプロイ問題
- デプロイに60分かかる
- スローテスト問題は、テストケースを分割し、複数のマシンで並列にやらせるのが一つの解
- でもテストは並列化できるがデプロイは並列化できない
60分かかるデプロイのうち、45分はネットワークのI/Oまち
- VMスナップショットへの復元
VMを新しくテンプレから作るかわりにスナップショットを作る
(10分から3分に短縮できる)
- インターネットからの分離
rpmやgemのダウンロードが死ぬほど遅い。
事前にアーティファクトを集める (45分から2分に)
外部環境の原因を追求しやすい
自前と既成の分割と羃等性
f(f(x)) = f
自前パッケージ
自前のソースからビルドするパッケージ
既成パッケージ
他社が作ったパッケージ
更新頻度もインストール所要時間も自前のほうが短い
羃等ではない
$ tar zxf foo.tar.gz
羃等
$ rm -rf foo
$ tar zxf foo.tar.gz
自前と既成のパッケージを別々にインストールすることで、
最短2分でデプロイが終わることもありうる
(再度実行することも可能だから)
Fail Fast
失敗するなら早い失敗を目指す
設定ファイルではなく設定ファイル作成プログラム
環境の使い捨て
本番と同じ環境で開発
高速なデプロイと羃等なスクリプトのおかげ
ブランチごとにデプロイ
まとめ
- ビルドだけでなくデリバリーも自動化
- クリーンと羃等で反復可能に
- 自動化だけで終わらせずに高速化も検討する
- 迅速なフィードバック
- 速ければ使い方も変わる
