はじめに
Dokploy は、VPS 上でアプリケーションや Docker Compose を管理できる OSS のデプロイツールです。
公式サイトでは、Linux サーバーに Dokploy をインストールし、ブラウザから管理画面へアクセスして初期設定を行う流れが紹介されています。
本来は VPS やクラウド VM にインストールして使うものですが、今回は実サーバーでの導入を検討するためにローカル Docker 環境で Dokploy の操作感を確認することにしました。
確認したかったことはシンプルです。
- Dokploy の管理画面をローカルで起動できること
- Dokploy から Docker Compose サービスを作成できること
- 初回デプロイで
こんにちはを返す API を公開できること - Compose の内容を変更して再デプロイし、
こんばんはを返せること
つまり、この記事は「本番構築手順」ではなく、Dokploy がどんな操作感なのかをローカルで触ってみるための検証メモです。
前提イメージ
Dokploy でアプリをデプロイする流れは、ざっくり以下のように考えるとわかりやすいです。
アプリのソースコード
↓
Dockerfile または Docker Compose
↓
Docker イメージ
↓
コンテナ
↓
起動中のアプリ
例えば TypeScript アプリであれば、src/、package.json、tsconfig.json、Dockerfile などを元に Docker イメージをビルドし、そのイメージからコンテナを起動します。
Dokploy は、このビルド、起動、再デプロイ、ログ確認などを管理画面から扱えるようにしてくれます。
今回の検証ではアプリコードのビルドまでは行わず、nginx:alpine イメージを使った簡易 API を Docker Compose で起動しました。
ローカル構成
構成は以下のイメージです。
ローカル Docker 環境
├─ devcontainer
├─ dokploy
├─ postgres
├─ redis
└─ hello-api
Dokploy 自体もコンテナとして起動します。
その Dokploy が、同じ Docker 環境上に hello-api コンテナを作成して管理します。
Dokploy 用 Docker Compose
ローカル検証用に、Dokploy、PostgreSQL、Redis を起動する Compose を用意しました。
name: dokploy-local
services:
postgres:
image: postgres:16
restart: unless-stopped
environment:
POSTGRES_USER: dokploy
POSTGRES_PASSWORD: dokploy
POSTGRES_DB: dokploy
ports:
- "5432:5432"
volumes:
- dokploy-postgres:/var/lib/postgresql/data
redis:
image: redis:7
restart: unless-stopped
ports:
- "6379:6379"
volumes:
- dokploy-redis:/data
dokploy:
image: dokploy/dokploy:latest
restart: unless-stopped
depends_on:
- postgres
- redis
environment:
DATABASE_URL: postgresql://dokploy:dokploy@postgres:5432/dokploy
REDIS_HOST: redis
PORT: "3000"
ADVERTISE_ADDR: 127.0.0.1
ports:
- "3000:3000"
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- dokploy-docker-config:/root/.docker
- ./dokploy-data:/etc/dokploy
volumes:
dokploy-postgres:
dokploy-redis:
dokploy-docker-config:
ポイントは Dokploy コンテナに Docker socket を渡しているところです。
volumes:
- /var/run/docker.sock:/var/run/docker.sock
これにより、Dokploy コンテナからローカル Docker 環境上に別コンテナを作成できます。
Dokploy を起動する
docker compose -f docker-compose.dokploy-local.yml up -d
起動後、以下にアクセスします。
http://localhost:3000
初回アクセス時は管理者アカウントを作成します。
プロジェクトとサービスを作成する
Dokploy の管理画面で、以下の順に作成しました。
- Project を作成
-
Create ServiceからComposeを選択 - Provider で
Rawを選択 - Docker Compose の内容を貼り付け
-
Deployを実行
プロジェクト作成後、サービス一覧画面から Compose サービスを作成します。
Compose サービスの作成時は、サービス名と説明を入力します。
作成後、Provider で Raw を選択し、Compose の内容を直接貼り付けます。
初回デプロイ: こんにちはを返す
まずは localhost:18080 で こんにちは を返す Compose を貼り付けます。
services:
hello-api:
image: nginx:alpine
restart: unless-stopped
ports:
- "18080:80"
command: |
sh -c "cat > /etc/nginx/conf.d/default.conf <<'EOF'
server {
listen 80;
location / {
default_type text/plain;
return 200 \"こんにちは\";
}
}
EOF
nginx -g 'daemon off;'"
デプロイ後、以下で確認します。
curl http://localhost:18080
結果:
こんにちは
変更デプロイ: こんばんはを返す
次に、Compose のレスポンス文字列だけを変更します。
- return 200 "こんにちは";
+ return 200 "こんばんは";
Dokploy の管理画面で保存し、再度 Deploy を実行します。
確認します。
curl http://localhost:18080
結果:
こんばんは
これで、Dokploy から Docker Compose サービスを作成し、設定変更後に再デプロイできることを確認できました。
GitHub 連携する場合のイメージ
Dokploy では、サービスごとに GitHub リポジトリとブランチを選択してデプロイ対象を決められます。
例えば以下のような運用が考えられます。
- 本番用サービスは
mainまたはreleaseブランチを対象にする - 検証用サービスは
developブランチを対象にする - 初回は管理画面から手動デプロイする
- Auto Deploy を有効にした場合、対象ブランチへの push を契機に自動デプロイする
つまり、release ブランチを Dokploy の対象にしておけば、release へ merge / push されたタイミングでデプロイする、といった運用ができます。
一方で Auto Deploy を無効にしておき、管理画面から内容を確認して手動デプロイする運用もできます。
実サーバーで試す場合
今回はローカル検証に留めましたが、実サーバーで試す場合は以下のような流れになります。
- サーバーを用意する
- Dokploy をインストールする
- Dokployにアクセスする
- 管理画面のログインアカウントを作成する
- 管理画面用のドメインと HTTPS を設定する
- Docker Compose サービスを作成してデプロイする
まとめ
GCPのCloudBuildと同等の事が出来ると感じました。
EC2等Linuxサーバを運用している場合は選択肢になると思いますので、まずはローカル環境で Dokploy の基本的な操作感を確認するのがよいと思います。
今回確認できたことは以下です。
- Dokploy 管理画面をローカルで起動できる
- Raw Docker Compose を使ってサービスを作成できる
- Dokploy からコンテナを起動できる
- Compose の変更後に再デプロイできる
- レスポンスの変更を確認できる