Github ActionsでECSに自動デプロイできているのに想定通りの挙動にならなかったエラーをご紹介

本記事について

本記事は、先日Github ActionsにてECSへCI/CDパイプラインを構築した際に自身がハマってしまった2つのエラーについて備忘録も込めて記載します。
GitHub Actionsではエラーにならずに通ったものの、サイトを確認してみると想定通りの挙動になっていなかった部分となります。
※初学者のため、間違い等ございましたらご指摘いただけますと幸いです。

環境

• MacOS: Ventura13.0.1
• Ruby:3.12
• Rails:7.0.4

①Railsの環境変数Master.keyの不足によるエラー

ポートフォリオの作成中、まずCircleCIでパイプラインを構築したのちに、Github Actionsに移行したので、そこまで大きいエラーはないと思っていましたが、エラーに遭いました。

起きた事象

Github ActionsではエラーにならずECRへpush後、ECSへデプロイできていましたが、サイトを開くとfrontendとbackendの通信がうまくいっていなかったです。

cloudwatch log

/usr/local/bundle/gems/railties-7.0.4/lib/rails/application.rb:581:in `validate_secret_key_base': Missing `secret_key_base` for 'production' environment, set this string with `bin/rails credentials:edit` (ArgumentError)

このエラーはCircleCIでは見たこともないエラーだったので困惑しました。。
また調べた結果、Master.keyが必要な記事を発見しました。
ただ値は元々送っていたんですよね、、原因の追求に時間がかかりました。

解決：環境変数の変数名が違う

記載通りなんですが、Master.keyの値を入れる環境変数名が違うことによるエラーでした。
なぜCircleCIではうまくいっていたのか謎ですが、環境変数名を変えるだけで解決できました。

自身はインフラをterraform化していたので、下記部分を修正して

ecs.tf(一部抜粋)

secrets = [
                {
                    # name: "APP_KEY"
                    name: "RAILS_MASTER_KEY"
                    valueFrom: data.aws_ssm_parameter.app_key.arn
                },
                
            ]

terraformでインフラを再作成し、githubにpushすることでエラーが解消しました。

②ECSのtask definitionが更新されていない

Github ActionsでCI/CDパイプラインを構築するにあたり、並列処理を実施しようと思いました。
またECSではサービス内に複数のコンテナが存在しており、色々と大変でした。。
自動デプロイが完了して処理は通ったのですが、サイトが更新されていないことに気づきました。
imageをlatest運用せず、commit idで運用していたので、当初はcommit idの付与の仕方が問題だと思っていたのですが、そうでもなさそうでした。

起きた事象

コード自体は公式ドキュメントを参考にしていたので、間違ってはいないはず、、と思っていました。
確認していく中で、AWS ECS画面から対象のタスク定義のjsonデータを見てみると、imageが前回のまま変更されていませんでした。

解決：変更されたtask definitionを使う

下記を参考に修正したらうまくいきました。

• before

workflow.yml

- name: download task definition
    run: |
        aws ecs describe-task-definition --task-definition $ECS_TASK_DEFINITION_BACKEND --query taskDefinition > task-definition-backend.json
- name: render ecs task definition for first container
    id: render-container-backend-nginx
    uses: aws-actions/amazon-ecs-render-task-definition@v1
    with:
        task-definition: task-definition-backend.json

- name: render ecs task definition for second container
    id: render-container-backend-rails
    uses: aws-actions/amazon-ecs-render-task-definition@v1
    with:
        ### ↓注目 ###
        task-definition: task-definition-backend.json
          
- name: Deploy ECS task backend
    uses: aws-actions/amazon-ecs-deploy-task-definition@v1
    with:
        ### ↓注目 ###
        task-definition: task-definition-backend.json

• after

workflow.yml

- name: download task definition
    run: |
        aws ecs describe-task-definition --task-definition $ECS_TASK_DEFINITION_BACKEND --query taskDefinition > task-definition-backend.json
- name: render ecs task definition for first container
    id: render-container-backend-nginx
    uses: aws-actions/amazon-ecs-render-task-definition@v1
    with:
        task-definition: task-definition-backend.json

- name: render ecs task definition for second container
    id: render-container-backend-rails
    uses: aws-actions/amazon-ecs-render-task-definition@v1
    with:
        ### ↓注目 ###
        task-definition: ${{ steps.render-container-backend-nginx.outputs.task-definition }}
          
- name: Deploy ECS task backend
    uses: aws-actions/amazon-ecs-deploy-task-definition@v1
    with:
        ### ↓注目 ###
        task-definition: ${{ steps.render-container-backend-rails.outputs.task-definition }}

task definitionだけわかりやすく記載しております。
aws-actions/amazon-ecs-render-task-definitionはjsonデータを書き換える処理を実施します。
beforeでは書き換えたデータを参照せずに一番最初のjsonデータをそのままecsへデプロイしたことによりimageが変更されなかったんだと思います。
複数コンテナがある場合は、全て一個前のtask definitionを参照して更新したデータを参照し続けないとどこかで乖離が生まれてしまうようです。

まとめ

CI/CD部分に限らずですが、うまくいったからと言って安堵せずに、細かい部分まで確認したほうが良いなと思いました。
②のエラーについては、最初からうまくいっていなかったのに、更新されていないことに気づくのに時間がかかりました。
ページに変化を持たせる等して、最新版に更新されていることの前後比較をしたほうが良いかもしれませんね。

Github Actionsの並列処理では、冗長的な書き方をしているので、なんとかしたいです。。

終わり