Northflank ── コンテナと DB をまとめてデプロイする
はじめに
Web アプリと PostgreSQL を Docker でまとめる（Django による Web システムの構築）と、次に出てくるのが「どこで動かすか」です。VPS を借りて gunicorn・nginx・DB・TLS・バックアップを自分で組むこともできますが、運用の手間は小さくありません。
Northflank は、そうしたコンテナと DB の運用をまとめて引き受けるプラットフォーム（PaaS）です。この記事では、何ができて、コンテナ化した構成をどう載せるのかを整理します。
Northflank とは
Northflank は、コンテナアプリ・データベース・ジョブ・ビルドパイプラインを扱う開発者向けのプラットフォームです。おおまかな特徴は次のとおりです。
- Git リポジトリを連携し、Dockerfile からビルドしてデプロイ（プレビルド済みイメージの指定も可）
- PostgreSQL / MySQL / Redis などをマネージドなアドオンとして追加（バックアップ付き）
- push を契機に自動ビルド・デプロイ、ブランチや PR ごとのプレビュー環境
- TLS 付きの公開 URL、独自ドメイン、サービス間の内部ネットワーク
- CLI・API・Terraform、構成をコード化する「テンプレート」
- Northflank 側のクラウドで動かすほか、自社のクラウドアカウント上で動かす形態（BYOC）にも対応
同種のサービスに Render、Railway、Fly.io などがあります。「コンテナと DB をまとめて面倒を見てほしい」という要件は共通で、機能の粒度や IaC の作り込みやすさで選ぶことになります。
構成の単位
Northflank の画面は、次の単位で組み立てます。
| 単位 | 役割 |
|---|---|
| プロジェクト | 環境のまとまり。この中のサービスは内部ネットワークでつながる |
| サービス | 実行単位。ビルド＋デプロイの「combined」、イメージ配備の「deployment」、単発・定期実行の「job」、ビルド専用の「build」など |
| アドオン | マネージドなステートフル要素。PostgreSQL などの DB がこれ |
| シークレットグループ | 環境変数・認証情報の束。複数サービスに紐づけられる |
Django の記事の compose.yaml でいえば、web がサービス、db がアドオン、environment: の中身がシークレットグループにあたります。
デプロイの流れ
- プロジェクトを作る
- GitHub / GitLab のリポジトリを連携し、combined サービスを作成
- ビルド方式に Dockerfile を選び、パスを指定
- 公開ポート（Django なら gunicorn の 8000）と、必要なら独自ドメインを設定
- 保存すると初回ビルド → デプロイ。以降は対象ブランチへの push で自動的に再ビルド
ブランチや Pull Request 単位でプレビュー環境を作れるので、レビュー時に実物の URL を共有できます。
データベース
PostgreSQL はアドオンとして追加します。バックアップやバージョンを画面から設定でき、接続情報（ホスト・ユーザー・パスワード・接続 URL）が生成されます。
この接続情報をシークレットグループ経由で web サービスの環境変数に注入すれば、アプリ側は DATABASE_URL を読むだけで済みます。同一プロジェクト内なら DB は内部ネットワークで参照でき、外部公開する必要はありません。
秘密情報と設定
SECRET_KEY、DEBUG、ALLOWED_HOSTS、DB 認証情報はシークレットグループにまとめ、サービスにリンクします。値を変更すると対象サービスが再デプロイされ、設定が反映されます。Django の記事で「環境変数から読む」と書いた設定は、そのままこの仕組みに乗ります。
コンテナ運用の手順はどう変わるか
Django の記事でデプロイ前に挙げた作業は、置きどころが変わります。
migrate：デプロイのたびに実行する「リリースジョブ」や、コンテナ起動時のエントリポイントに置くcollectstatic：Dockerfile のビルド段階で実行し、成果物をイメージに含める- gunicorn：コンテナの
CMDのまま。Northflank が前段のルーティングと TLS を持つ - HTTPS・証明書：公開 URL に自動で付く。独自ドメインは DNS を向けて設定するだけ
「WSGI サーバー＋リバースプロキシ＋証明書」の外側は、プラットフォームが引き受けます。
CI との分担
テストは GitHub Actions で push・PR ごとに走らせ、通ったものだけを Northflank がビルド・デプロイする、という分担が素直です。ビルドとデプロイもワークフローに寄せることはできますが、プレビュー環境や DB との結線はプラットフォーム側に任せたほうが手数が減ります。
構成をコード化する
画面でぽちぽち作った構成は、Northflank のテンプレート（JSON/YAML）や Terraform で記述できます。プロジェクト・サービス・アドオン・シークレットの定義をリポジトリに置いておけば、環境の作り直しや複製が再現可能になります。Git で版管理する対象に、この定義も含めておくとよいでしょう。
運用の注意
- 課金は使用量ベース：稼働リソースと時間で決まる。常時稼働なのか、落としてよいのかを見積もる
- リージョン：利用者に近い場所を選ぶ。DB とアプリは同一リージョン・同一プロジェクトに
- ログとメトリクス：画面から確認できる。エラー通知の設定もしておく
- ロールバック：デプロイ履歴から前のビルドに戻せる。移行を伴うときは DB との整合に注意
関連記事
- Django による Web システムの構築 — ここに載せるアプリと DB のつくり方
- Northflank で Service と PostgreSQL Addon を Secret Group でつなぐ — Variable Alias で接続情報を環境変数名に対応づける具体手順
- Docker の基本 — イメージ・コンテナ・ボリュームの考え方
- Hugo と GitLab で静的 Web サイトを作る — 動きの要らないサイトはこちら
- LaTeX コンパイルを GitHub Actions で自動化する — テストと CI の分担
まとめ
- Northflank はコンテナアプリと DB、ジョブ、パイプラインをまとめて運用する PaaS。自社クラウド上で動かす形態もある。
- 構成は プロジェクト／サービス／アドオン／シークレットグループ。コンテナ構成（
compose.yaml）とほぼ対応する。 - Git 連携で push ごとにビルド・デプロイ。TLS と内部ネットワークはプラットフォームが持つ。
migrateはリリースジョブ、collectstaticはビルド段階へ。構成はテンプレートや Terraform でコード化できる。
コンテナ化まで済ませてあれば、あとは載せ替え先を選ぶだけ ── という状態にしておけるのが強みです。