まとめ

CI環境でDinD使うとport forwardで詰まる可能性が高い！
CodeBuildの記事少なくて辛かったので備忘
追記:CodeBuildの特権モードを使えば解決できるらしい（未検証）

背景

コード管理にはCodeBuildを利用
開発環境はメインプロセスがホストで動くよう設計されている

開発環境のDocker化

Dockerがローカル開発環境（や本番環境）に使われるようになり多くの時間が流れました。
最大のメリットは、環境同一化による些末な差分発生の抑止であると考えます。デメリットは、コンピュータリソース使用量の増加と通信量増加による実行速度低下ですが、小規模な開発では現代では問題になることは少ないと考えます。

ホスト・コンテナ間の通信

以下は、DBサーバがDocker上で動いてる時に、アプリケーションの動作環境がホストの場合と同じDockerにいる場合のイメージ図です。

矢印が通信のイメージです。前者は、ホストOSとDocker上で動くOS間で通信が発生するため、port forwardingの設定が必要です。ここまでは、前述のメリデメはありますが、問題ありません。
次に、以下が上記の前者をそのままCI環境（CodeBuild）に載せた時のイメージ図です。

課題

CodeBuild実行環境はおそらく、Dockerに類するコンテナ管理が行われているでしょう。問題はこの時、「CodeBuild実行環境のポートを自由に触る権限が与えられているか」です。あくまでやりたいことはCodeBuild実行環境とその上のDockerのポートを繋ぎたいのですが、さらに大元の環境（図でAWSと書いた部分）に影響を及ぼさせるのはサービスとして危険です。
だからかわかりませんが、ローカル環境とは異なり、アプリ(+CodeBuild実行環境のbash)からDBサーバに接続することはできませんでした。

対応

試したこと

開かないものは開かないので仕方ないのですが、せっかくなので調査時に試したことをリスト化しておきます。

CodeBuild実行環境OS（AmazonLinux）をローカルに持ってきてDinD構成で色々試す
- ローカルだとポート開くことを確認
上記OSの変更(AmazonLinux -> CentOS) -> 変わらず
docker logs, inspect等のコマンド叩きまくる -> よくわからないが良さそう
docker exec -> OK
docker exec して ps aux -> OK
psql -> NG
ツールが全然入ってないので、入れて検証 -> これでようやく出来ないことを確信した
- apt update; apt install net-tools; netstat -nap|grep LISTEN; apt install lsof; lsof -i -P | grep "LISTEN"; ls', // 失敗しても後続を実行

その他に辛かったこと

IaC管理されており、CodeBuildの調査に加えIaC記法の調査が挟まる
特定ブランチへのマージや運用チームへのデプロイ依頼などが発生し、GUIポチポチで試行錯誤を高速に回せなかった
docker hubのpull制限に引っかかる
(以降自主規制)

対応方針

アプリケーションをホストで動かす（DinD）のではなく、docker-compose構成に変更

まとめ（感想）

フロントエンドアプリケーションはホスト、APIサーバはコンテナ化、など常識レベルの構成も、改めてハマってみると色々な背景があるのだなぁと身をもって実感した（これも極論だが）
薄々原因に気づいても、納得するまで調査したくなるのは、エンジニアの性だなぁ
アドベントカレンダーは25日までに書くのではなく、担当してる日に書かなきゃなぁ...