コンテンツにスキップ

GitHub ActionsとECS Run TaskでDB操作を自動化する

チェック

  • [ ] 本文を確認した
  • [ ] 概要を確認した
  • [ ] タグを確認した
  • [ ] inbox/ 直下へ移行した

概要

GitHub Actionsの workflow_dispatch とECS Run Taskを使い、マイグレーション、seed、データパッチ、任意スクリプトなどのDB操作をワークフロー化する記事。 Aurora Serverless v2がプライベートサブネットにある前提で、ローカルや踏み台からDBへ直接接続せず、VPC内のECSタスクとして安全に実行する。 本番操作の二重ゲート、ref指定による一時イメージビルド、ECSサービス設定からのネットワーク設定取得、entrypoint.shによる同一イメージ使い回しが実務的。

本文

背景

デプロイ以外にも、マイグレーション適用、マスタデータ投入、テストデータ投入、データパッチ適用などの運用タスクは繰り返し発生する。 これらを手動SSHやローカルDB接続で行うのは、セキュリティ面でもネットワーク面でも扱いづらい。

Aurora Serverless v2をプライベートサブネットに置いているため、ローカルから直接DBへ接続するより、GitHub ActionsからECS Run Taskを起動してVPC内で処理させる構成にしている。

db-operation.yml

GitHub Actionsは workflow_dispatch で手動実行する。 入力は次のような構成。

  • operation: migrate、seed-master、seed-dev、patch、custom-script、shell
  • environment: dev / prod
  • script_path: custom-script用
  • shell_command: shell用
  • ref: ビルド元ブランチ/タグ。未指定ならデプロイ済みイメージを使う
  • confirm_prod: prod実行時の確認文字列

サポートする操作

migrate はPrismaマイグレーションの適用。 ensure-schema.js、resolve-failed-migrations.js、prisma migrate deploy の順に実行する。 失敗マイグレーションが _prisma_migrations に残った状態でも復旧できるようにしている。

seed-master は全環境共通のマスタデータ投入。 seed-dev は開発用テストデータ投入で、prodでは明示的にブロックする。

patch はデータパッチ用。 custom-script は一回きりのデータ修正などをTypeScriptスクリプトとして実行する。 shell は npx prisma migrate status のような確認コマンド用。

安全策

prod環境では confirm_prod に yes が入っていなければ失敗させる。 さらにGitHub Environmentsのprotection rulesでprod操作には承認を要求する。 入力バリデーションとEnvironment承認の二重ゲート。

ただし、custom-script と shell は実質的に任意コマンド実行なので危険もある。 記事では、実行権限がリポジトリwrite権限と承認者ロールに紐づく前提で便利さを取っている。 組織規模によっては、明示的なoperationだけに限定した方が安全。

ref指定と一時タスク定義

ref を指定すると、マージ前のブランチに含まれるマイグレーションやスクリプトをdev/prodで事前テストできる。 ref指定時は、checkout、ECRログイン、イメージビルドとpush、一時タスク定義登録を行う。 未指定時は、デプロイ済みECSサービスのタスク定義をそのまま使う。

ECS Run Taskパターン

DB操作はECS Run Taskで実行する。 サブネットとセキュリティグループは固定値ではなく、ECSサービスの設定から動的取得する。 dev/prodごとの分岐を減らせる。

custom-script / shell は sh -c 経由で任意コマンドを渡し、標準操作は DB_COMMAND 環境変数でentrypoint.shのcaseを切り替える。 タスク終了後はexit codeを確認し、0でなければワークフローを失敗させる。

entrypoint.sh

DB_COMMAND が指定されていれば、該当するDB操作を実行して終了する。 未指定なら通常のアプリ起動へ進む。 未知の値は通常起動へフォールバックせず、エラー終了させる。

同一イメージを使い、ECSサービスとして動くときは常駐プロセス、Run Taskでは一回きりの処理として使い分ける。 DB操作以外のTTS音声キャッシュ生成なども同じパターンに乗せている。

要点

  • プライベートサブネット内のDB操作は、ECS Run Task化するとローカル接続や踏み台を避けられる。
  • workflow_dispatch の入力設計とGitHub Environment承認で、本番操作の安全策を作れる。
  • ref指定でマージ前のスクリプトを一時イメージとして実行できるのは、DB変更の事前検証に便利。
  • 任意コマンド実行は便利だが危険なので、権限境界と承認フローを明確にする必要がある。

タグ

aws #ecs #github-actions #database #ci-cd #operations