CodePipeline と Slack による ECS ChatOps 運用
この記事は ECS ChatOps with CodePipeline and Slack の日本語訳です
現在、Rails アプリケーションを ECS に移行する作業を進めています。現在のシステムでは Capistrano でデプロイを行っていますが、そろそろ限界が見えてきました。
EKS が使えるようになるのを待っている間、自分で Kubernetes のクラスターを管理するより ECS を採用することに決めました。当初、Lambda 関数を使って必要なタスク定義を作り、ECS サービスを更新する予定でしたが、プロジェクトの設計を開始する直前に CodePipeline の ECS デプロイの対応が発表されました 🎉。
現在のリソースは、CodePipeline と Slack を連携するためのいくつかの Lambda 関数、サービスごとに2つのCodePipeline パイプライン（本番用と検証用）、関連 ECS リソースです。
まず、デプロイするには、Slack チャンネルに deploy [environment] [service] と発言すると起動します。Slack は（API Gateway 経由で）Lambda にイベントを送信し、Lambda は CodePipeline パイプラインの実行を開始します（ CodePipeline API の仕組み上、複数の同時実行は扱いにくい）。この Lambda 関数は、DynamoDB のいくつかの基本的な状態（Slack チャンネル、ユーザー、タイムスタンプ）を記録します。この情報は、返信を送信するチャンネルと、デプロイプロセスの何かがステータスが変わったり失敗した場合に通知するために使われます。
CodePipeline がまず、Docker イメージを作成する CodeBuild を起動し、タスク定義を更新するための 新しい Docker イメージのタグが入った単純な JSON ファイル を生成します。
CodeBuild が終了すると、デプロイを続行する前に人の承認を要求するために「手動承認」アクションが使用されます。ここの例では検証環境用に有効にしていますが、通常は本番環境でのみ使用されます。本番環境では、まず1台のカナリアデプロイ、次に25%、残りの75%という三段階で運用しています。
[video width=“1096” height=“828” mp4="/wp-content/uploads/2017/12/approve.mp4" webm="/wp-content/uploads/2017/12/approve.webm" poster="/wp-content/uploads/2017/12/approve-cover.png" loop=“on”][/video]
残りの部分は比較的単純です。CodePipeline がイメージをデプロイするように ECS に指示します。途中でエラーが検出された場合、 rollback コマンドを使用して手動で変更をロールバックします。
デプロイが完了すると、Lambda 関数がデプロイ用チャンネルにメッセージを送信します。
