Docker Run から Compose へのコンバーター
長い `docker run …` コマンドを同等の docker-compose.yml サービス定義に変換します — ポート、ボリューム、環境、ネットワーク、ヘルスチェック、リソース制限など多数対応。ブラウザで完全に実行されます。
入力
出力
このツールを使う他の方法
REST API
curl -X POST https://api.iotools.cloud/v1/tool/docker-run-to-compose-converter \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"dockerRunInput": "docker run -d \\\n --name nginx-proxy \\\n --resta…"
}'ご自身のアカウントのキーに差し替えてください。ツールのフィールドがそのままリクエストボディになります——ラッパーはありません。
AIエージェントに依頼する
Use the IOTools `docker-run-to-compose-converter` tool (Docker Run to Compose Converter) on this input:
YOUR_INPUT_HEREIOTools MCPサーバーに接続された任意のエージェントにこれを貼り付け、入力内容を追加してください。
埋め込みウィジェット
<iframe
src="https://iotools.cloud/embed/docker-run-to-compose-converter/"
width="100%" height="520" frameborder="0" scrolling="no" loading="lazy"
title="Docker Run から Compose へのコンバーター — iotools.cloud"
sandbox="allow-scripts allow-forms allow-same-origin allow-downloads allow-popups allow-popups-to-escape-sandbox"
allow="clipboard-write"
style="width:100%;border:1px solid #e5e7eb;border-radius:12px;overflow:hidden"></iframe>
<script src="https://iotools.cloud/embed.js" async></script>ご自身のページに貼り付けるだけ——無料、キー不要、リンクを掲載するだけです。
| API/MCP 1回あたりの費用 | 5クレジットから |
|---|---|
| クレジットが足りませんか? | 料金を見る |
次の方法でも利用可能
ガイド
Docker Run から Compose へのコンバーターは、長い docker run … コマンドを同等の docker-compose.yml サービス定義に変換します。通常はターミナルで入力するコマンドを貼り付けると、保存可能な Compose ファイルが得られます — 何十もの -p、-v、-e フラグを YAML に手で翻訳する必要はありません。
プロジェクトの README、ブログ記事、またはシェル履歴でコンテナを見つけて、それを宣言的に管理したい時のために作られています。Compose ファイルはコマンドラインフラグの壁よりもバージョン管理、レビュー、再起動が簡単です。
使い方
- Docker Run コマンドボックスに完全なコマンドを貼り付けます。例:
docker run -d --name web -p 8080:80 -v ./html:/usr/share/nginx/html nginx:alpine。 - docker-compose.yml 出力は入力時に更新されます。
- コピーまたは
docker-compose.ymlとしてダウンロードし、そのディレクトリでdocker compose up -dを実行します。
末尾にバックスラッシュ (\) がある複数行コマンドも正しく貼り付けられます — コンバーターは解析前に継続行を結合します。
変換対象
このツールは人々が実際に使用するフラグを理解します: -p/--publish (ポート)、-v/--volume (ボリューム)、-e/--env と --env-file (環境)、--name、--restart、--network、-l/--label、--user、--workdir、--entrypoint、capability (--cap-add/--cap-drop)、--device、--dns、--add-host、tmpfs、--ulimit、--sysctl、およびヘルスチェックフラグ (--health-cmd、--health-interval など)。リソースフラグ — --memory、--memory-reservation、--cpus、--cpu-shares — は deploy.resources ブロック下に出力されます。イメージ名の後のイメージ引数はサービスの command になります。
FAQ
バージョンキーを出力しますか?
いいえ。トップレベルの version: フィールドは現在の Compose Specification では廃止されており、意図的に省略されています。最新の docker compose はこれを無視します。
名前付きネットワークはどのように処理されますか?
--network host、none、bridge、または container:<id> の値は network_mode にマッピングされます。他のネットワーク名はユーザー定義ネットワークとして扱われます: サービスの networks: リストに追加され、ファイルの下部で external: true として宣言されます (事前に docker network create で作成したと仮定)。
なぜ --cpu-shares が 1024 で除算されるのですか?
Docker の CPU shares は相対的な重みで、1024 は 1 つの完全な CPU に相当します。Compose の reservations.cpus は分数のコア数を期待するため、値が変換されます (例えば 512 は "0.50" になります)。
認識できないフラグを処理しますか?
Compose に相当するものがないフラグ (--rm や -d など) は単に破棄されます。これらはサービス自体ではなく CLI がどのように実行されるかを説明するためです。入力が docker run で始まらない場合は、壊れたファイルではなく説明の短いコメントが表示されます。
完全な YAML バリデーターですか?
いいえ — クリーンで正しくクォートされた Compose ファイルを出力しますが、Compose Specification に対するスキーマ検証は行いません。デプロイ前に結果を確認してください。
プライバシー
変換はブラウザで完全に実行されます。コマンド — 環境変数やラベルのシークレットを含む — はサーバーに送信されません。そのため、本番環境の認証情報は貼り付けを避け、生成されたファイルを元のコマンドと同じ方法で扱ってください。