開発者がcomposeを使用してクラウドネイティブアプリケーションを構築できるように、Compose仕様を開発するためのDockerはコミュニティをリリースした。Docker composeのさまざまな実装があり、KubernetesやAWS ECSなどのプラットフォームで機能するようになっている。しかし、Dockerはコミュニティと協力して、より良いサポートを提供し、Composeの未来を定義したいと考えている。Compose仕様は、人々がさまざまなプラットフォームでcomposeを使用し、Composeのファーストクラスの機能として新しい機能を作成できるようにすることである。
InfoQは最近、Compose仕様コミュニティについて詳しく学ぶため、DockerのセキュリティリーダであるJustin Cormack氏と話をした。
InfoQ: Compose仕様コミュニティとは何でしょうか ? 仕様はどのような種類の問題を解決しようとしているのでしょうか ?
Justin Cormack氏: 元々、Docker composeはPythonによる1つだけの実装がありました。しかし、Docker composeが何をするのかを調べ、可能な限り多くコピーを試みた実装が増えています。しかし、時には彼らは異なることもしています。Docker内でも、KubernetesまたはSwarm用のDocker composeのような3つの異なる実装があります。そのため、これらすべての実装は、私たちが行ったことをコピーして機能させる必要がありましたが、さまざまなプラットフォームでDocker composeを実装する方法には、実際のところいかなる影響もありませんでした。
Compose仕様は、人々がさまざまなプラットフォームでcomposeを使用し、Composeのファーストクラスの機能として新しい機能を作成できるようにすることで、コミュニティが仕様の進捗に影響を与えることを可能にします。Kubernetesではネットワークとボリュームの動作が異なるため、composeの実行に問題があることはわかっていました。また、AWS ECSのような他のプラットフォームには、他のAWSサービスと相互作用するための実装があります。そのため、Docker Swarmやデスクトップとは異なる他のプラットフォームでcomposeを使用できるように、オープンな仕様を作成するのが最善の方法だと考えました。
InfoQ: これまでの進捗状況はいかがでしょうか ? 仕様の現状はいかがでしょうか ?
Cormack氏: まだ完全な仕様ではありません。存在するパラメータのセットと、YAMLファイルに含めることができる他のセクションのみが含まれており、何をすべきかを正確に示せていません。既存の実装ではcomposeのどのビットがオプションであるかを含めてすべてが実装されていません。テストを実装するためのリファレンスもあります。
また、修正が必要と思われる多くの問題、気に入らない機能、またはコミュニティが提起した問題も見つかりました。コミュニティと定期的にミーティングを行い、現在の問題とその対処法について話し合います。たとえば、有効な実装を定義するための一連の適合性テストはまだありませんが、将来的にはそれを使用したいと考えています。
また、KubernetesやAWS ECSの場合のように、プラットフォーム固有の機能が非常に大きい場合に、カスタム拡張を実行できる方法を短期的に検討しています。次に、これらの機能のどれが一般的なクロスプラットフォーム拡張として意味があるかを後で調べます。
InfoQ: Docker composeは開発者に重点を置いています。Docker composeはプロダクション環境にも発展できると思われますか ?
Cormack氏: 現在、composeを使用する方法は2つあります。開発環境でcomposeを使用し、プロダクション環境ではまったく使用しない。彼らはテストにcomposeを使用しており、同じサービスを起動しないことと類似しています。また、開発者が作成ファイルを作成し、次に別のチームが対応する別のYAMLファイルを作成するワークフローを持っている人もいますが、これは自動バージョンではなく、異なるものになる可能性があります。
私たちは、composeをどこでどのように使用するかを人々に強制しようとはしていません。仕様を定義するときに私たちが見たものの1つは、composeを使用している人の数でした。GitHubだけで、700,000個のDocker composeファイルがあり、それらのほとんどは現在、プロダクション環境で使用されていないと思います。通常、これらのファイルはシステムを起動する方法の例を定義するだけなので、簡単に開始できますが、必ずしもシステムをプロダクション環境で実行する方法とは限りません。
ですから、開発者が気にかけているものとしてcomposeを維持し続けるべきだと感じています。そして、プロダクション環境でシステムを実行する方法に関しての運用を気にすること。したがって、composeファイルはプロダクション環境の完全な説明ではありません。それは開発者向けの部分にすぎません。これは一種の関心の分離です。
InfoQ: 仕様のロードマップには何が含まれているのでしょうか ? 何をご覧になりたいですか ?
Cormack氏: いくつかのアイデアはありますが、そのようなロードマップはありません。目的の一部は、コミュニティが行きたい場所にドライブし、早期に人々の抱えている問題を解決できるようにすることです。composeファイルで特定のバージョン番号を指定する必要がないようにするなど、私がやりたいことがいくつかあります。それよりも、機能駆動型アプローチを紹介します。使用している機能を調べるために「このプラットフォームで機能しますか ?」と言うと、それがない場合は、「この機能はこのプラットフォームではサポートされていません」という役立つメッセージを返します。