GitHub Actions & ecspresso を用いたデプロイフローの改善

こんにちは。サーバーサイドエンジニアの TOC です。

本日はコネヒト株式会社で取り組んでいる Super X という活動の一環である「デプロイフロー改善」の取り組みを紹介しようと思います。

本記事で紹介した改善以外にも、デプロイフロー改善チームで取り組んだことは別エントリでお届けする予定です✨

はじめに
抱えていたデプロイフローでの課題
各課題の解決方法
- 開発環境で検証した Docker イメージを本番環境のデプロイで利用する
- ロールバック方法の確立
その他工夫した点
- デプロイジョブの並列化
- 並列化したジョブの結果を取得する workflow-conclusion-action の利用
まとめ
PR
参考

はじめに

そもそも Super X って何？と思われるかと思うので、取り組みのご紹介をしようと思います！

Super X はエンジニア組織として追っている目標のプロジェクト名で、開発組織の中で課題となってる負債の解消などに取り組んでいく活動です！

今回私は「デプロイフロー改善」を上期のテーマとして選び、活動を行ってまいりました。

抱えていたデプロイフローでの課題

※以下、「開発環境」は一般的に言うステージング環境を指しています。

弊社では過去に ecs-deploy を用いたデプロイを ecspresso に変更する取り組みがありました。（ref. GitHub Actions & ecspressoによるデプロイフロー構築）

上記取り組みで ecspresso 導入がされたものの、以下の課題が残っていました。

開発環境と本番環境で別々の Docker イメージが利用されている
ロールバックの方法が確立してない

1.については開発環境で検証した Docker イメージを本番環境でも利用した方が安心であるのと、本番環境デプロイ時に再ビルドが発生するので余計な時間がかかっているのを解消したいと思っていました。

2.については、ecspresso を使えば簡単にロールバックできるものの、その運用方法が社内で確立していなかったので、この際に他リポジトリに展開できるまで運用方法を確立しようという話になりました。

各課題の解決方法

開発環境で検証した Docker イメージを本番環境のデプロイで利用する

前提として、ecspresso を用いたデプロイフローはざっくり下記のようになっております。

1. 最新コードのチェックアウト
2. イメージをビルドし、ECR へプッシュ
3. ecspresso を利用して ECS タスク定義の更新・デプロイ

今回の改善では開発環境で上記のデプロイフローを行い、本番環境では下記のデプロイフローを行うことを目指します。

1. 最新コードのチェックアウト
2. ecspresso を利用して、開発環境で作成したイメージを参照するように ECS タスク定義の更新・デプロイ

このとき Docker イメージにつけるタグ名としては以下を満たす必要があると考えました。

開発環境デプロイ時に利用できるものであること
タグ名が :latest などに固定されないこと（ecspresso のロールバックを考慮する）

上記2点を考慮すると、コミットハッシュをタグにするのがいいのではないか、という話になりました。

コミットハッシュならば、Github Actions 内で github.sha で取得ができます。取得したコミットハッシュをイメージのタグ名として、イメージのビルド・ECR へのプッシュを行い、ecspresso でそのイメージを利用する形にすれば、開発環境で検証したイメージを本番環境デプロイ時に流用できる設計となりました。

これにより、本番デプロイの actions は以下のようになり、だいぶシンプルになりました（一部抜粋）。

on:
  push:
    tags:
      - '*'

env:
  AWS_ROLE_ARN: hogehoge

permissions:
  id-token: write
  contents: read
  actions: read
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      # 通知など前処理
      - name: Checkout
        uses: actions/checkout@v2
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          role-to-assume: ${{ env.AWS_ROLE_ARN }}
          aws-region: aws-region
      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v1
      - uses: kayac/ecspresso@v1
        with:
          version: latest
      - name: Deploy to Amazon ECS
        env:
          IMAGE_TAG: ${{ github.sha }}
        run: |
          ecspresso deploy --config .ecspresso/production/config.yaml
      # 後続処理

ロールバック方法の確立

デプロイが完了し、タスクは正常に起動したもののアプリケーションの動作に問題が発生したので戻したい場合には、ecspresso rollback コマンドを使用します。

ドキュメントによると、ロールバックをすると下記動作が走ります。

現在サービスに設定されているタスク定義の「ひとつ前」のリビジョンを見つける
ひとつ前のリビジョンのタスク定義をサービスに設定する

ref. ecspresso advent calendar 2020 day 6 - rollback

なので理論上、有効なリビジョンのタスク定義がある場合は無限にロールバック可能です。

このとき、--deregister-task-definition オプションをつけるとロールバックを行ったタスク定義を登録解除します。つまり、１回異常が起きたタスク定義はもう使わない、という思想のようで、ecspresso 作者の方も特別な事情がない場合はこのオプションをつけることをおすすめしています。

このオプションをつけることで、無限に戻れはするが、戻った際に過去ロールバックをした定義は使われない状態が作れます。なのでロールバック時はオプションを指定したコマンドを実行するように修正しました。

ecspresso rollback --deregister-task-definition --config .ecspresso/production/config.yaml

ちなみに ecspresso Roadmap to v2 を見ると、このオプションがデフォルトで true になるようなので、いずれオプション指定しなくても良くなりそうですね🙌

その他工夫した点

デプロイジョブの並列化

場合によっては複数の ECS 環境にデプロイを行いたい場合があるかもしれません。その際にジョブを直列で書くと、1つの環境でデプロイが終わらないと次のデプロイが始まりません。

そんな時はジョブを並列化するとデプロイ時間が短縮されます。

deploy_1:
  needs: build
  runs-on: ubuntu-latest
  steps:
    # デプロイ
deploy_2:
  needs: build
  runs-on: ubuntu-latest
  steps:
    # デプロイ
deploy_3:
  needs: build
  runs-on: ubuntu-latest
  steps:
    # デプロイ

上記のように needs: build でビルド作業が終わったら各ジョブが走るようにします。

actions の詳細を見ても上図のように並列実行できていることがわかります。

並列化したジョブの結果を取得する workflow-conclusion-action の利用

デプロイをする actions では最後にデプロイ結果を通知するジョブを用意しています。デプロイのジョブを並列化した場合、どれか１つでもジョブが失敗したら通知としては失敗と通知してほしい気持ちになります。

通常ジョブの成功/失敗は job.status で取得できますが、これは1つのジョブの成否になるので、ジョブが分かれた場合、前段のジョブが成功したのか、失敗したのかはわかりません。

そんな時は workflow-conclusion-action が便利です。

notify_end:
  needs: [ deploy_1, deploy_2, deploy_3 ]
  runs-on: ubuntu-latest
  if: always()
  steps:
    - uses: technote-space/workflow-conclusion-action@v2
    - name: Notify slack of deployment result
      uses: 8398a7/action-slack@v3
      with:
        status: ${{ env.WORKFLOW_CONCLUSION }}
        fields: repo,commit,ref,workflow,message
        author_name: ${{ github.actor }}
        text: |
          Deployment has ${{
            (env.WORKFLOW_CONCLUSION == 'success' && 'succeeded') ||
            (env.WORKFLOW_CONCLUSION == 'failure' && 'failed') ||
            'cancelled'
          }} to hogehoge.
      env:
        SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}