Compose ↔ docker run

機能

• 双方向を自動判定：compose の services 部分 ↔ 完全な docker run コマンド
• image・container_name・ports・volumes・environment・env_file・command・entrypoint・restart・network_mode・working_dir・user・hostname
• スイッチ系：privileged・read_only・tty・stdin_open
• healthcheck の test 配列を --health-cmd に変換。interval / timeout / retries も
• ポートは短縮形と長形式（target / published / protocol）の両方に対応。tcp 以外は接尾辞付き
• ボリュームの長形式（source / target / read_only）を `-v src:dst:ro` に
• ⚠️ depends_on・deploy・profiles・extends は個別に列挙し、対応物がない理由を説明します
• ⚠️ build・複数ネットワーク・名前付きボリューム・空の `KEY=` は意味が変わる箇所として明示します
• ⚠️ 解釈できない docker オプションは正直に報告し、結果に紛れ込ませません
• ⚠️ 行末の継続記号に対応 —— `docker ps` やドキュメントからコピーしたコマンドには必ず付いています
• ⚠️ イメージ以降の引数はコマンドとして切り分け、`-g` などを docker オプションとして捨てません
• すべてブラウザー内で完結します

使い方

1. compose の services 部分、または docker run コマンドを貼り付けます
2. 必要ならオプションで変換するサービスを 1 つ指定します
3. コマンドまたは断片を確認し、次に「引き継げなかったもの」と「意味が変わる点」を確認します

よくある質問

一部の設定が引き継がれないのはなぜですか？

`docker run` に対応物がないからです。最も分かりやすいのは `deploy` で、これはレプリカ数・リソース制限・ローリング更新の方針を設定するもので、オーケストレーション層に属します。一方 `docker run` はコンテナを 1 つ起動するだけなので、「3 レプリカ」は単一コマンドに存在しません（`docker service` やオーケストレーターが必要です）。`depends_on`（起動順）と `profiles`（切り替え）も同じです。表現できないものを黙って捨てると、そのコマンドが元のサービスと等価だと誤解され、配備して初めて気づくことになります。

変換後に相対パスが狂うことがあるのはなぜですか？

基準ディレクトリが異なるからです。compose の相対パスはcompose ファイルのあるディレクトリを基準に解決され、`docker run` の引数はカレントディレクトリを基準に解決されます。`./site:/usr/share/nginx/html` は、compose ファイルが `/srv/app/docker-compose.yml` にあるときは `/srv/app/site` を指しますが、変換したコマンドを別の場所で実行すればそのときいるディレクトリを指します。コマンドは同じに見えて、別の場所をマウントします。

`-d` と `--rm` が消えるのはなぜですか？

compose では service 定義の一部ではないからです。`-d`（バックグラウンド実行）は `docker compose up -d` というコマンドレベルのスイッチで、個々のサービスに書く意味はありませんし、`--rm` にも対応する compose のキーがありません。消えるのは正しい動作で、compose の意味論ではそもそも書くべきものではありません。

イメージの後の `-g` が捨てられないのはなぜですか？

docker の文法が `docker run [オプション] イメージ [コマンド]` であり、イメージ以降はすべてコンテナ内で実行するコマンドだからです。`docker run nginx -g "daemon off;"` の `-g` は nginx の引数で、docker のスイッチではありません。位置で切り分けることでコマンドにそのまま残ります。切り分けなければ、未知の docker オプションとして捨てられ、compose ファイルは完全に見えたままになります。

Podman や Kubernetes に変換できますか？

できません。ここで扱うのは compose と `docker run` だけです。Kubernetes への変換は桁が違います：Deployment を Service・ConfigMap・Secret にどう分割するかはクラスターの構成次第で、1 対 1 の対応ではありません。無理に作った YAML は動きますが、保守しにくいものになります。

daemon.json のアドレスプール設計はどこですか？

別のツール「Docker サブネット設計」です。こちらは compose と `docker run` の相互変換だけを行います：片方はサービス編成ファイル、もう片方は単一の実行コマンドです。アドレスプール（`default-address-pools`）と docker0 の `bip` は daemon レベルの設定で、コンテナの起動コマンドには対応物がありません。そのため別のツールに分け、1 ページで 2 つの事柄を混同しないようにしています。