はじめに
Bluemix上で動作中のアプリケーションをダウンタイムなしで更新するサービスがベーター版ですが提供されているようなので試してみました。
Active DeployとBlue-Green Deploymentはどちらも利用者へのサービスの中断を避けるという基本原則は共通していますが、デプロイプロセスは少し異なるようで、Blue-Greenはデプロイ中の2つのバージョンが存在するときに片方にしかトラフィックが発生しないように制御されるが、Active Deployは両バージョンにトラフィックが使用可能になるタイミングがあるようです。
準備
- CLI 用 Active Deploy サービス・プラグインのインストール
cf add-plugin-repo bluemix http://plugins.ng.bluemix.net/
cf install-plugin active-deploy -r bluemix
※Cloud Foundry CLIプラグインを未インストールの方は事前に下記よりインストールしておいてください。
Cloud Founry CLIのダウンロード
2. Active Deployサービスをカタログから追加
3. アプリケーションの準備
本番環境用に任意の名前のNode.jsランタイムを追加し、スターターコードをダウンロードします。
同様にテスト環境用にもう一つ任意の名前のNode.jsランタイムを追加し、こちらもスターターコードをダウンロードしておきます。
今回は、本番用アプリを「active-deploy001」、テスト用アプリを「active-deploy002」という名前に設定しました。
テスト用アプリケーションのスターターコードのindex.htmlを編集し、cf pushでテスト用アプリに更新ファイルを反映させます。
これでテスト用のアプリケーションは更新されたアプリケーションになります。
（開発者用のテスト環境を想定しているためここではダウンが発生してもユーザーには影響はありません。）
■本番環境 (旧バージョン)
■テスト環境（新バージョン）
今回は、旧バージョンで動いている本番環境「active-deploy001」を更新済で動作チェック済みの「active-deploy002」のバージョンに経路(URL)を変更せずに無停止で切り替えを行います。
Active Deployの実行
- cf active-deploy-create current_version new_version コマンドの実行
それでは、変更を加えたアプリケーションをActive-Deployコマンドでデプロイを実行してみます。
cf active-deploy-create current_version new_version
・current_version
アプリの元のバージョンを指します。
・new_version
デプロイする新しいアプリケーションを指します。
下記エラーが返ってきました。
Creating deployment from active-deploy001 to active-deploy002 in space ebc41676-6c7a-4656-be7b-7e80c6285af2...
FAILED
BXNAD6210: Successor CF app 'active-deploy002' already has route 'active-deploy002.mybluemix.net'. Start successor with --no-route
Active Deployで利用する新バージョンの環境に経路情報が含まれているとダメなようです。
テスト用アプリ「active-deploy002」にコマンドライン上で移動し、下記コマンドを実行します。
cf push --no-route
これでテスト用アプリの経路情報が無くなります。
では、この状態で再度active-deployコマンドを実行します。
cf active-deploy-create active-deploy001 active-deploy002
うまく実行できれば下記のような実行結果が返ってきます。
本番用アプリケーションがダウンしないことを確認するために、pingコマンドなどで死活監視をしておきます。
2. 実行経過の確認
BluemixのダッシュボードからActive Deployサービスにアクセスします。
管理ページを表示すると進捗が表示されています。
実行中のデプロイを選択すると更に詳細を確認することができます。
起動フェーズ、テストフェーズ、停止フェーズという流れでデプロイメントが実行されることを確認できます。
各フェーズの時間を指定しなかった場合はデフォルトで下記の時間が設定されるようです。
- 起動フェーズ：5分
- コマンドオプション：-u, --rampup time - テストフェーズ：15分
- コマンドオプション：-t, --test time - 停止フェーズ：5分
- コマンドオプション：-w, --rampdown time
ページ内の[現行のトラフィック]を見てみると、テスト用のアプリケーション側にトラフィックが移っていることが確認できます。
各フェーズが全て実行されたあと、ダッシュボードを確認してみると、active-deploy001からactive-deploy002に経路情報が移行されていることを確認できます。
ping監視結果を見てみると特にダウンすることなく移行できたことを確認することができました。
Active Deployの実行により今度は「active-deploy001」側の経路情報がなくなったので、手動で経路を設定してやることで、こちらをテスト用環境として新バージョンのアプリ開発に着手することができます。
このように本番環境とテスト環境を交互に入れ替えながら開発することで、旧バージョンと新バージョンをダウンタイムなしで更新していくことが可能になります。
こうなると怖いのは人的ミスで、違う方にcf pushしてしまうことです。
本番環境へのcf pushを制限し、Active Deployのみを受け付けるようにする独自ツールでも開発しますかね。
コマンドリファレンス
active-deployで使えるコマンドは下記の通りです。
- cf active-deploy-create
- デプロイを開始
- cf active-deploy-advance
- デプロイを次のフェーズに進める
- cf active-deploy-check-phase
- デプロイのフェーズが期待するフェーズかどうかを検査する
- cf active-deploy-check-status
- 現在のデプロイ状況が期待する状況と一致するかどうかを検査する
- cf active-deploy-delete
- 完了したデプロイまたはロールバックされたデプロイをリスト結果から削除する
- cf active-deploy-list
- 稼働中のデプロイをリスト
- cf active-deploy-pause
- 現行フェーズを一時停止し、フェーズ間の遷移を行わないようにする
- cf active-deploy-resume
- 一時停止したデプロイを再開
- cf active-deploy-rollback
- デプロイを停止し、初期状態に復元
- cf active-deploy-service-info
- Active Deploy サービスの現在稼働しているバージョンとその health_check 状況に関する情報を表示
- cf active-deploy-show
- デプロイの詳細を表示
まとめ
Active Deployを使うことで本番環境をダウンタイムなしで新バージョンに切り替えることができました。
次は簡単なアプリではなく、様々なサービスをバインドした状態での動作チェックをしてみたいと思います。