概要
個人での開発や、学習のための環境構築には「docker compose」コマンドを使用していましたが、実務でのdocker環境構築手順では「docker-compose」コマンドが使用されていました。
一見同じことができそうですが、正しい意味を知らずになんとなくコマンドを打つのは怖いので調査してみました。
結論
まず結論からです。
２つのコマンドには以下のような特徴があります。
また、互換性があり多くの機能がほぼサポートされています。
docker compose
- docker-composeをGoで実装し直したもの
- docker-composeに置き換わることを目標としている
- 現時点で未実装の機能もある
- 今後実装されない機能（compose ps --filter KEY-VALUE、compose rm --allなどdocker-composeで非推奨なもの）もある
- Docker Engine（Docker CLI）に含まれている
docker-compose
- pythonで実装されている
- Docker Engineに含まれていない
- 多くの動作はDocker Engineに依存する
- Docker Compose CLIに含まれている
Docker CLI 内のcomposeコマンドは、docker-composeコマンドとそのフラグをほぼサポートします。 このコマンドはdocker-composeと完全な互換性を持つものとしています。
Composeの機能の中でcomposeコマンドでは利用できないものを見つけた場合は、GitHub リポジトリ Compose に issue をあげてください。 優先度をあげて対応することができます。
compose コマンドの docker-compose との互換性
前者はdockerのcomposeコマンド,後者はdocker-composeコマンドという、
ほぼ同じことができる別のコマンドのイメージでいいと思います。
Docker Engineとは
Docker Engineは３つの主なコンポーネント（構成要素）を持ちます。
- dockerデーモン
- REST API
- Docker CLI
先述したcomposeコマンドはDocker Enigneに含まれており、docker-composeコマンドは含まれていないというのはここのことです。
ユーザーがコマンドを入力した際に、DockerクライアントやREST APIを介してdockerデーモンと通信します。
基本的な機能はあるので今後学習する人は「docker compose」で良さそう
個人的には学習や個人利用の範囲では「docker compose」を使用すると良いと思います。
以下のリファレンスに記載の通り、build、up、psなど使用頻度の高い機能は既に実装されており、どちらでも同じようなことができます。
また、将来的に「docker-compose」に置き換わることも理由の一つです。
docker-composeを使用する理由を考えた
では、「docker-compose」を使用している現場は、なぜ使用しているのでしょうか。
- 以前から使用しており、引き続き使用している。
- 「docker compose」コマンドに変更することによる想定外の問題を回避している。
- 現状使用できるあらゆる機能が実装済みであり、「docker compose」では未実装の機能が使える。
このような理由が考えられます。
したがって、同じようなことができるからといって自己判断でハイフンを付けたり省略するのはやめましょう。
まとめ
- 「docker compose」コマンドは「docker-compose」に置き換わることが目標
- 互換性があり、ほとんどの機能が同じように使える
参考文献
compose コマンドの docker-compose との互換性
Docker-docs-ja Docker Engine とは何ですか？
docker compose コマンドリファレンス