Docker Compose YAML フォーマッター
ガイド
Docker Compose YAML フォーマッター
入力エリアに docker-compose.yml を貼り付け、または例のリンクのいずれかをクリックしてサンプルスタックを読み込んで、すぐにクリーンで一貫したフォーマットのファイルを取得します。サービス、ネットワーク、ボリュームがDocker Compose規約で期待される順序に並びます。このフォーマッターはファイルを現代のCompose仕様に照らして検証し、古くなったキー（古いトップレベル version フィールドやlegacy links）をフラグし、実行中に失敗する前に未定義のサービスオプションについて警告します。
使用方法
- あなたの
docker-compose.yml入力エリアに貼り付け、または例のリンクのいずれかをクリックしてサンプルスタックを読み込んでください。 - キーの順序を選択 — Compose規約 サービスを、イメージ、再起動、環境、ポート、ボリューム、…の順に並べます。 アルファベット順 A-Z順に並べます、または Preserve 元の順序を維持します。
- 2または4スペースのインデントを選択し、Compose仕様の検証をオンまたはオフに切り替えます。
- 検証パネルを読み、エラー、古くなったキーに関する警告、および暗黙のネットワーク参照に関する情報通知を確認します。
- 結果をコピーまたは、
docker-compose.yml.
機能
- Compose仕様検証 – トップレベル
services,networks,volumes,configs,secrets,profiles,includeおよび拡張フィールド（x-*）を認識し、それ以外の項目をフラグします。 - 古くなった項目の警告 – 過去のトップレベル
versionキー、links,external_linksおよびv2時代のリソース制限を、deploy.resources. - サービスに意識のあるキー順序 – 各サービスの識別キー（
image,build,container_name）を最初に、実行時の設定（environment,ports,volumes）を中央に、運用に関する項目（healthcheck,logging,deploy）を最後に配置します。 - 参照チェック – 定義されていないサービスに依存するサービスを検出し、サービスがトップレベルで宣言されていないネットワークを使用している場合に警告します。
- サービス要件 – すべてのサービスが少なくとも一つの
image,build,extends、 またはproviderを持っていることを確認し、restartが4つの有効なポリシーのいずれかを使用していることを確認します。 - ポート＋ヘルスチェックの整合性 – 間違ったポート文字列、長形式のポートに欠けた
target、およびヘルスチェックにないtest. - 3つの実行例 – Node + PostgresのWebアプリ、WordPress + MySQL + Redisスタック、およびプロファイルとリソース制限を含む複数サービスの構築例。
- ローカル＋プライベート – すべての解析、並べ替え、検証はブラウザ内で実行され、あなたのComposeファイルはページから離れません。
よくある質問
-
トップレベルのversionキーが古くなった理由は？
versionキーは、legacy Compose v1、v2、v3でdocker-compose CLIのスキームを選択するために使用されました。現在のCompose仕様はそれらのスキームを1つの継続的に進化する仕様に統合し、version宣言が何の変更も行わないため、最近のDocker Composeリリースはそれを無視し警告を表示します。このキーを削除することで、ファイルサイズを縮小し、読者がversion3の機能が宣言によって制限されていると誤解するのを回避できます。
-
Compose仕様とは何ですか？かつ、古いComposeファイル形式とはどのように異なりますか？
Compose仕様は、2020年までDocker Composeが使用していた各バージョンのスキームを置き換えたオープンでベンダー中立のスキームです。GitHubのgithub.com/compose-spec/compose-specで維持されており、Docker Compose、Podman Compose、およびその他の実行者によって実装されています。v2およびv3と比較して、仕様はversionフィールドを削除し、サービスが唯一の必須トップレベルキーとなり、Swarm専用フィールド（deployなど）をオプションのメタデータとして吸収し、オーケストレーターが消費できるようにしています。
-
共有ネットワークをリンクキーワードよりも優先する理由は？
linksはDockerのネットワーク時代以前から継承されたもので、デフォルトブリッジ上のコンテナ間のDNSエイリアスを設定するだけです。現代のユーザー定義ネットワークは、すべてのサービスにサービス名による自動DNS解決を提供し、1つのスタックに複数の隔離ネットワークをサポートし、DNSエイリアスをaliasesオプションで制御できます。そのため、Compose仕様はlinksを古くし、明示的なネットワーク参加を推奨しています。
-
各リスタートポリシーは実際に何をしますか？
noはコンテナを再起動しません。alwaysはコンテナが停止したときに常に再起動し、デーモンの再起動後も含みます。on-failureはコンテナが非ゼロステータスで終了したときにのみ再起動し、最大再試行数で制限できます。unless-stoppedはalwaysの動作に似ており、デーモンの再起動前に手動で停止したコンテナは停止状態を維持します。この4つの値は大文字小文字を区別する文字列であり、それ以外はComposeエンジンによって拒否されます。
-
Composeは画像を取得するか、構築するかをどのように決定しますか？
Composeはpull_policy、build、imageを一緒に見ます。pull_policy: alwaysの場合、Composeは毎回upの前に取得します。missingまたはif_not_present（imageのみ設定された場合のデフォルト）の場合、ローカルに存在しない場合にのみ取得します。neverの場合、取得しません。buildがimageと共に存在する場合、pull_policy: buildは再構築を強制し、結果をimageとしてタグ付けし、pull_policy: missingは画像がまだローカルに存在しない場合にのみ再構築します。
