【ツール活用｜実務向け】GitHub ActionsのService ContainersでDB疎通を爆速設定する実践テクニック

導入: CI/CDにおける「DB接続エラー」を撲滅する

開発現場において、CIパイプライン上で結合テストを実行する際、最も頭を悩ませるのが「テスト用DBコンテナとの疎通」です。特にGitHub Actionsを利用していると、ローカル環境では動くのにCI上では「Connection Refused」や「Authentication Failed」で落ちるというケースが多発します。本記事では、サービスコンテナのネットワーク特性を理解し、クリーンで安定したテスト環境を構築するためのTipsを解説します。

基礎知識: GitHub Actionsのネットワーク共有の仕組み

GitHub Actionsのサービスコンテナ機能では、同一ジョブ内で定義されたコンテナは同一のDockerネットワーク上に配置されます。

・localhost接続の誤解: 注意すべきは、テストコード側から「localhost」でDBへ接続する場合、実はコンテナが提供するポートをホスト（ランナー）側にマッピングする必要がある点です。
・サービスエイリアス: コンテナ間の直接通信では、サービス名をホスト名として利用できます（例: mysql:3306）。しかし、アプリケーションコードが固定でlocalhostを向いている場合、ポートマッピングが必須となります。

実装/解決策: ネットワーク設定のベストプラクティス

接続を成功させる鍵は「ポートバインディング」と「環境変数の注入」の2点です。テストを実行するコンテナに対して、DBコンテナのポートを明示的に開放し、テストコードが期待する環境変数（DB_HOST, DB_PORT等）を渡すことで、CI上での疎通を安定させます。

サンプルプログラム: GitHub Actionsワークフロー設定

以下のYAMLは、MySQLサービスを立ち上げ、テストを実行する標準的な構成です。

jobs:
  test:
    runs-on: ubuntu-latest
    services:
      mysql:
        image: mysql:8.0
        env:
          MYSQL_ROOT_PASSWORD: password
          MYSQL_DATABASE: test_db
        # 3306ポートをホストの3306にマッピング
        ports:

3306:3306

        # ヘルスチェックを設定して、DB起動完了を待機する
        options: --health-cmd="mysqladmin ping" --health-interval=10s --health-timeout=5s --health-retries=3

    steps:

uses: actions/checkout@v3

      

name: Run Tests

        env:
          # アプリケーションが接続するための情報を環境変数で渡す
          DB_HOST: 127.0.0.1
          DB_PORT: 3306
          DB_USER: root
          DB_PASS: password
        run: |
          # ここでテストコマンドを実行
          npm test

応用・注意点: 現場で陥りやすいバグの回避策

1. DBの初期化待ち: コンテナが立ち上がった瞬間にテストコードが走ると、まだDBが準備中で接続エラーになります。上記のサンプルにあるヘルスチェック（–health-cmd）を必ず記述してください。これがないと、DB接続エラーのデバッグに時間を浪費することになります。
2. ポート競合の回避: ランナー上に既存のDBプロセスが動いていると、3306ポートのバインドに失敗します。ランナーの環境をクリーンにするか、ポート番号をずらす（例: 3307:3306）運用も検討してください。
3. 認証情報のハードコード: サンプルでは分かりやすさのために直書きしていますが、本番に近い環境ではGitHub Secretsを利用し、秘匿情報を適切に管理することが重要です。

この構成を導入することで、CI上の結合テストは非常に堅牢になります。ぜひプロジェクトのCI設定に組み込んでみてください。