2013年8月にはジェローム・Petazzoniがドッカーにドッカーを作成し、dind短いため、これはドッカーコンテナはドッカーコンテナの内部を作成することが許可され、この機能は、結果として非常に人気が証明したジェロームのGitHubのリポジトリ千の星と300本のフォークを超える受けます。

2年後の2015年8月にリリースされたDocker 1.8の時点では、DockerのDockerは、そのままDockerによって直接サポートされています。ただし、DockerでのDockerの使用には、Jérômeの投稿：CIまたはテスト環境でDocker-in-Dockerを使用していますか？考え直してください。これは、DockerのDockerが継続的インテグレーションに適した選択肢ではない理由に焦点を当てています。

DockerでDockerを使用するのはなぜ悪いと考えられるのですか？それは単にカメを完全に回避するためのケースですか？またはパフォーマンスの考慮事項？

継続的インテグレーションの懸念

要するに、Docker（dind）のDockerは並行性をうまく処理しません。

CIにdindを使用すべきではない理由は、Dockerがストレージに使用するディレクトリ（通常は/var/lib/docker）に排他的にアクセスするように設計されているためです。すべての子プロセスがこのディレクトリを同時に使用するため、Dindはこれを尊重しません。（たとえばCIから）再ビルドするたびに、このディレクトリ内のアプリに関連するものはすべて消去され、ゼロから強制的に開始される可能性があります。ユーザーが支払いの詳細を入力し、「購入」をクリックして、ログイン画面に突然何もしなかったように戻った場合、ユーザーはどのように気に入るでしょうか？それはちょうど良いUXではありません。一度に2つの再構築が発生しますか？関係者全員（データの整合性を含む）にとって、それは本当にひどく終わるでしょう。

その他の懸念

OPが投稿したリンクから、明示的に禁止されていない限り、下位コンテナが外部コンテナのリソースにアクセスできる「CSSに似た」方法でシステムがセキュリティポリシーを適用しようとするため、セキュリティ上の懸念が生じます。「mywebsite.com/../another_folder/private_resource.txt」などの操作を行ってWebサーバーリソースにアクセスできることを覚えていますか？また、ファイルシステムがこのようにネストされていると、ファイルシステムが互いにうまく機能しないことがあります。

修正

ありがたいことに、OPのブログ投稿にはこの問題に対する優れた解決策があります。「Dockerで実行しているCIシステム自体からDockerコンテナーをビルド/実行/プッシュ」でニーズが満たされない場合を除き、Dockerソケット（通常）で-vモード（コンテナーにデータボリュームを追加/var/run/docker.sock:/var/run/docker.sock）を使用して、 「共有」データボリュームに必要なアクセス。これらのコンテナは、下ではなく親と一緒に開始され、同期IOを強制します。これで、（ほぼ）dindと同じものが得られますが、Dockerに付随する欠点はありませんが、並行性のためにビルドされるわけではありません。

参照（OPから）：CIまたはテスト環境にDocker-in-Dockerを使用していますか？考え直してください。