🐳 docker-compose.yml ジェネレーター
フォーム入力だけで完全な docker-compose.yml を生成。複数サービス追加・ポート・ボリューム・環境変数・依存関係・ネットワーク・トップレベル volumes / secrets まで対応。
🔒 プライバシーについて
- ・入力した内容はブラウザ内のみで処理されます
- ・サーバー送信・保存ログ・データベースは存在しません
compose ファイル version は 3.9 で固定 (現代版)
🌐 トップレベル定義
📄 docker-compose.yml
📖 つまずきやすいポイント
サービス・ポート・ボリューム・環境変数・依存関係・ネットワーク・secrets をフォームで指定すると、そのまま使える docker-compose.yml を組み立てます。処理はブラウザ内で完結し、入力は送信されません。このツールが保証するのは YAML の構文と構造だけです — イメージが実在するか、その中のアプリが起動するか、サービス同士が正しく繋がるかは検証できません。docker compose up が失敗する原因の大半は YAML の書式ではなく、この先の「順序」「経路」「権限」の 3 つにあります。以下はその 3 つです。
| ケース | 何が起きるか | どうする |
|---|---|---|
depends_on は「起動した」までしか待たない |
depends_on が保証するのはコンテナの起動順だけで、中のプロセスが接続を受け付ける状態になったかは見ていません。データベースは起動してから初期化とリカバリを終えるまで数秒から数十秒かかるため、アプリ側はまだ受け付けていないポートに接続しにいって落ちます。症状に特徴があります — 初回の up だけ失敗し、そのあと up し直すと動く。2 回目にはデータベースが既に温まっているからです。この「たまに失敗する」性質のせいで、ローカルでは見逃され CI で初めて顕在化することがよくあります。再現しないバグではなく、競合状態です。 |
依存される側に healthcheck を書き、依存する側で condition: service_healthy を指定してください。 PostgreSQL なら test: ["CMD-SHELL", "pg_isready -U postgres"]、interval: 5s、retries: 10、start_period: 10s が実用的な出発点です。ただしこれでも完全ではありません — 実行中にデータベースが再起動すれば、アプリはまた接続を失います。最終的な答えは、アプリ側に接続リトライを入れることです。起動順に頼らない設計にしておけば、compose でも Kubernetes でもマネージド DB でも同じように動きます。healthcheck は開発体験を良くするための補助と考えてください。 |
ports と volumes の左右を取り違える |
どちらも 左がホスト、右がコンテナです ("8080:80" はホストの 8080 をコンテナの 80 へ)。ここから 3 つの事故が生まれます。第一に、ports は既定で全インターフェースに公開されます — "3306:3306" と書けば、同じ LAN の誰からでもデータベースに到達できます。第二に、同じ compose ネットワーク上のサービス同士は、ポートを公開しなくてもサービス名で通信できます。db:5432 で届くので、アプリのために ports を書く必要は本来ありません。第三に、バインドマウントはイメージ側の中身を隠します — ./:/app と書くとイメージがビルド時に作った /app/node_modules は見えなくなり、compose のときだけ「モジュールが無い」と言われます。 |
外部に見せる必要があるものだけを ports に書き、それ以外は書かないでください。 手元から DB に繋ぎたいなら "127.0.0.1:3306:3306" と書いてループバックに限定します。node_modules 問題は「無名ボリュームで上書きする」のが定番の解で、volumes: に ./:/app と /app/node_modules の2 行を並べて書きます — 後者がバインドマウントの上に重なり、イメージ側の中身が生き残ります。権限のずれ (ホストの UID とコンテナの UID が違い、書き込めない・root 所有のファイルができる) は user: "${UID}:${GID}" で揃えられますが、Linux でのみ問題になります — macOS と Windows の Docker Desktop は仮想化層が吸収するため再現しません。 |
| 環境変数がどこから来ているのか分からなくなる | compose には名前が似ていて働きの違う仕組みが 3 つあり、これが混同の元です。(1) environment: はコンテナに渡す値。(2) env_file: は同じことをファイルから行うもの。(3) YAML 中の ${VAR} はcompose 自身が読み込み時に置換する変数で、値はホストのシェルとプロジェクト直下の .env からしか来ません。ここが最大の罠です — env_file: に書いた値は ${VAR} の解決には使われません。しかも未定義の ${VAR} は空文字になるだけでエラーになりませんので、image: myapp:${TAG} が黙って myapp: になり、latest が引かれます。 |
推測せず、docker compose config を読んでください。 これは置換をすべて解決した最終形の YAML を出力します — 実際に何が渡るのかを見られる唯一の場所です。空になっている値があれば、そこが未定義の ${VAR} です。機密の扱いについても方針を決めてください: environment: に直接書いた値はdocker inspect で誰でも読め、Git にも入ります。env_file: はファイルを .gitignore に入れられる分ましですが、コンテナの中では同じただの環境変数です。本番では compose の secrets: かシークレット管理サービスを使ってください — 前者はファイルとしてマウントされるので、環境変数のように子プロセスへ自動的に継承されません。 |
このツールが出力する version: '3.9' は、現在の Compose V2 では読み飛ばされます。the attribute version is obsolete という警告が出ますが動作には影響しません — 気になるならその 1 行を消してください。バージョン番号は Compose V1 の時代に機能セットを選ぶためのものでしたが、V2 は常に最新の仕様で解釈します。運用面でよく踏むものをあと 2 つ挙げておきます。restart: always は、起動直後に落ちるコンテナを無限に再起動させます — ログが繰り返しで埋まり、本当のエラーメッセージが最初の 1 回分だけになって見つけにくくなります。原因調査中は外してください。もうひとつ、docker compose down は名前付きボリュームを消しません。データベースの初期化スクリプトが「効かない」ときは、たいてい古いボリュームが残っています — 多くのイメージはデータディレクトリが空のときにしか初期化を実行しないためです。作り直すには docker compose down -v が必要で、このコマンドはデータを本当に消します。
📖 使い方
-
1
プリセット選択またはサービス追加LAMP・Next.js・Laravel など 6 種のプリセットから開始するか、空からサービスカードを追加します。
-
2
各サービスのフィールドを編集image / ports / volumes / environment / depends_on / restart / networks を入力。値はリアルタイムで YAML に反映されます。
-
3
コピーまたはダウンロード生成された YAML をワンクリックでコピー、または docker-compose.yml としてダウンロード。
❓ よくある質問
compose の version は何ですか？
入力したパスワードや API キーは送信されますか？
生成した YAML はそのまま docker compose up で動きますか？
🔗 関連ツール
🐛 このツールで問題が発生しましたか？
完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。
ご報告ありがとうございます！
運営者に届きました。改善の参考にさせていただきます。