GitHub ActionsとSelf-hosted RunnerでVPC内DBにmigrateを実行する方法
AppRun構成でCI/CDを成立させる実践設計
📚 さくらのクラウドで作るモダンアーキテクチャ（全5回）
- 第1回：さくらのクラウドで作るモダンアーキテクチャ入門
- 第2回：さくらのクラウドVPC設計完全解説
- 第3回：GitHub Actions × Self-hosted Runner（イマココ）
- 第4回：AppRun専有型と共用型の違い
- 第5回：Terraformで再現するさくらのモダンアーキテクチャ
はじめに
AppRunを使ったモダン構成で、ほぼ確実にぶつかる問題があります。
それが
VPC内部にあるデータベースに、CI/CDからどうやってmigrateを流すか
という問題です。
通常のCI/CDでは、
- GitHub Actions
- GitLab CI
- CircleCI
などのクラウドCIが使われます。
しかしこれらは インターネット上の環境で実行されるため、VPC内部には直接アクセスできません。
今回の構成では、
- データベースはVPC内
- DBはグローバル公開しない
- AppRun専有型を利用
という設計なので、
CIからDBに直接アクセスすることができません。
なぜ普通のCIではダメなのか
構成を整理します。
GitHub Actions
↓
Internet
↓
AppRun
↓
VPC Router
↓
Database
ここで問題になるのは
GitHub ActionsはVPCの外にいる
という点です。
つまり、
- DBを公開しない限り
- CIはDBに接続できない
という状態になります。
しかしDBを公開するのは、セキュリティ的に好ましくありません。
解決策：Self-hosted Runner
この問題を解決するのが
Self-hosted Runner
です。
これは簡単に言うと、
GitHub Actionsの実行環境を自分のサーバーに置く仕組み
です。
つまり、
- RunnerをVPC内に配置
- GitHub ActionsのジョブをRunnerで実行
することで、
CIからVPC内部のリソースにアクセスできるようになります。
Runner配置の構成
今回のシリーズでは以下の構成を採用します。
GitHub Actions
↓
Self-hosted Runner
↓
VPC Router
↓
Database
RunnerをVPC内部に配置することで、
- DBアクセス
- migrate実行
- 内部API接続
が可能になります。
Runnerを配置するセグメント
第2回で紹介したネットワーク構成を思い出してください。
VPC
├─ public-app-seg
├─ private-db-seg
└─ runner-seg
Self-hosted Runnerは
runner-seg
に配置します。
理由は以下です。
- AppRunと役割が異なる
- DBアクセスを制御しやすい
- CI用リソースを分離できる
CI用のサーバーは、必ず専用セグメントに分離するのが安全です。
Runnerのもう一つの問題：インターネットに出られない
RunnerをVPC内部に配置すると、もう一つ問題が発生します。
それは
Runnerがインターネットに出られない
という問題です。
RunnerはCI実行時に以下の通信を行います。
- GitHub Actions API
- pip install
- npm install
- Docker image pull
- 外部APIアクセス
そのため 外向き通信が必須になります。
NAT VMの役割
ここで必要になるのが
NAT VM
です。
NAT VMは、
VPC内部のサーバーがインターネットへ出るための出口
として機能します。
構成は以下のようになります。
Runner
↓
VPC Router
↓
NAT VM
↓
Internet
RunnerはNAT VMを経由してインターネットへ接続します。
AWSとの違い
AWSでは
- NAT Gateway
を利用します。
一方、さくらのクラウドでは
NATはVMで構築する
のが一般的です。
ただしメリットもあります。
- コストが安い
- 構成の自由度が高い
- 通信制御が細かくできる
NAT VMを含めた全体構成
最終的なネットワーク構成は以下になります。
Internet
↓
Cloudflare
↓
AppRun[VPC]
├─ public-seg
│ └─ NAT VM
│
├─ runner-seg
│ └─ Self-hosted Runner
│
└─ private-db-seg
└─ Database
通信フロー：
Runner → NAT VM → Internet → GitHub
Runner → VPC Router → Database
この構成により
- CI/CD
- VPC内部通信
- DB保護
を両立できます。
Runnerセットアップ
RunnerはGitHubからスクリプトを取得して起動します。
mkdir actions-runner
cd actions-runnercurl -o actions-runner.tar.gz -L https://github.com/actions/runner/releases/latest/download/actions-runner-linux-x64.tar.gztar xzf actions-runner.tar.gz./config.sh --url https://github.com/your-repo --token TOKEN
./run.sh
これでRunnerがGitHubと接続されます。
GitHub Actions設定例
Djangoのmigrate実行例です。
name: migrateon:
push:
branches:
- mainjobs:
migrate:
runs-on: self-hosted steps:
- uses: actions/checkout@v4 - name: Install dependencies
run: |
pip install -r requirements.txt - name: Run migrate
run: |
python manage.py migrate
重要なのはここです。
runs-on: self-hosted
これによりジョブは
VPC内部のRunner
で実行されます。
Runner運用で気をつけること
Runnerは公開しない
RunnerはCI実行環境です。
外部公開すると攻撃対象になります。
必ずVPC内部に配置します。
Runnerは専用セグメントに置く
CI環境は分離します。
理由：
- セキュリティ
- 負荷分離
- トラブル影響範囲
Runnerは使い捨ても可能
高度な構成では
- Runner自動生成
- Job終了後削除
という設計もあります。
今回はシンプル構成を採用します。
まとめ
AppRun構成でCI/CDを成立させるには
Self-hosted Runner + NAT VM
が必要になります。
理由はシンプルです。
- DBはVPC内部
- CIはインターネット
- Runnerは内部
- Runnerは外に出る必要がある
だから
RunnerをVPC内に置き
NAT VMでインターネットに出る
この構成が最もシンプルで安全です。
次回予告
次回は
AppRun専有型と共用型の違い
を解説します。
ここを理解していないと、
- VPC接続できない
- スイッチ接続できない
- ネットワーク設計が破綻する
という事故が起きます。
AppRun設計の核心です。
よくある質問（FAQ）
Q1. GitHub ActionsからVPC内のデータベースに接続できますか？
通常のGitHub Actionsはインターネット上で実行されるため、VPC内部のデータベースには直接接続できません。
そのため、VPC内にSelf-hosted Runnerを配置し、そのRunner上でCIジョブを実行する構成が必要になります。
Q2. Self-hosted Runnerとは何ですか？
Self-hosted Runnerとは、GitHub Actionsのジョブを自分のサーバーで実行できる仕組みです。
通常はGitHubのクラウド環境でジョブが実行されますが、RunnerをVPC内に配置することで内部リソースへ安全にアクセスできます。
Q3. Self-hosted Runnerはどこに配置するべきですか？
Self-hosted Runnerは専用のセグメント（例：runner-seg）に配置するのが推奨です。
AppRunやデータベースと役割が異なるため、ネットワークを分離することでセキュリティと運用性が向上します。
Q4. Runnerはインターネットに接続する必要がありますか？
はい。Runnerは以下の通信を行うため、外向き通信が必要です。
- GitHub Actions API
- パッケージダウンロード（pip / npm）
- Dockerイメージ取得
- 外部APIアクセス
そのためVPC内のRunnerはNAT VMなどを経由してインターネットへ接続する必要があります。
Q5. NAT VMとは何ですか？
NAT VMとは、VPC内部のサーバーがインターネットへアクセスするための出口となるサーバーです。
RunnerはNAT VMを経由することで、GitHubやパッケージリポジトリへアクセスできます。
Q6. AWSの場合はどう構成しますか？
AWSでは通常、
- NAT Gateway
- ECS / EC2 Runner
- GitHub Actions
の組み合わせで同様の構成を作ります。
さくらのクラウドではNAT Gatewayの代わりにNAT VMを構築するケースが多いです。
Q7. データベースをグローバル公開してCIから接続するのはダメですか？
可能ではありますが推奨されません。
DBを公開すると攻撃対象が増えるため、VPC内部に閉じたままSelf-hosted Runner経由で操作する方が安全です。
