デプロイ済みの環境に対して、DB の中身を見るのに結構苦労したので顛末をメモしておきます。
承前
AWS Copilot で FastAPI による API をデプロイしています。
Alembic のマイグレーションでDBを更新するよう、コンテナのスタートアップスクリプトに書いているんですが、あるとき、このマイグレーションが適用されたのにされてない扱いになり、すでに適用されたファイルを再適用しようとして起動に失敗するようになってしまいました。
ローカル環境では Docker Compose で起動させてテストをしているので、 DB のコンテナに外から繋げます。なのでDB に直接繋いで alembic_version というテーブルを正しく修正すれば治ります。
しかし！ AWS Copilot でデプロイした RDS はコンテナからしか繋げないようにしてます。セキュリティ的には大正解ですが、さて困りました。
使えなかった方法
RDS には Data API というオプションがあり、AWS のコンソールからクエリを投げることが出来ます。いやこれで回受けツジャンと思ったんですが……、なんということでしょう、 Data API は Aurora Severless v2 の MySQL には非対応 なんです（普通のRDSや Aurora Severless v2 でも PostgreSQL ならできたのに）
manifest ファイルに書いてデプロイしようとしてもそれは使えないよって怒られてしまいました。
であればコンテナからつなぐしか
となるとコンテナから繋ぎたいのですが、繋ぐにはコンテナが起動している必要があります。
今回マイグレーションで失敗したらコンテナがそのまま立ち上がらない状態になっていました。
なので、まずは、マイグレーションが失敗しようがとにかくサービスが起動だけはするように変更しました。この状態では起動しているアプリケーションにマイグレーションが最新まで適用されているか保証できないので、今後うっかりミスがあったりすると面倒だなと思いつつ、仕方ないのでそういう修正をしました。
不整合のまま起動したコンテナ内からつなぐ
というわけでコンテナが起動するようにはなりました。コンテナには
aws copilot exec [サービス名]
こうやって繋げます。さて、繋いでそこから Aurora に繋ごうと思ったところ mysql コマンドをつうけつけてくれません。それもそのはず、そんな者は入っていないのです。
コンテナにMySQLクライアントを入れる
というわけで、コンテナの起動時に default-mysql-client をインストールするように書き換えました（Poetry をつかっているので、Poetryでクライアントがインストールされるようにしました。これただの mysql-client ではダメで、defaultをつけたら動かせるようになりました。
動作の確認自体はローカルでも出来るので起動してコンテナの中に入って mysql にパスワードなどを引数で渡して実行させることを確認します。
ちなみにcopilotでストレージもデプロイしているので、パスワードなどは環境変数にエクスポートされています。envでパスワードを確認してから接続しましょう。
（なお、デフォルトではコンテナに繋いだときの初期シェルがshなので不便すぎたのでbashと打ってから作業しました。このへん使ったイメージなどによって変わる部分かとは思います）