私の自動ビルドはDockerコンテナ内で遅く実行されるのはなぜですか？

Question

私は現在、Rowley Associates CrossStudioで開発された様々な組み込みファームウェアプロジェクト用の自動ビルド/ CIシステムに取り組んでいます。プロジェクトは、それぞれCrossBuildを使用してコマンドラインでビルドすることができます。ドッカー部分への今

、：

我々は一貫性のビルド環境を保証する方法が必要です。ビルドは、すべてのエンジニアワークステーションまたはビルドサーバーで同じに実行する必要があります。 CrossBuildの実行を含むビルドのすべてのステップがコマンドラインLinux環境で実行できるので、Dockerコンテナを使用して環境の一貫性を保証することを選択しました。

私の意図は、以下の方法で使い捨ての「ビルボット」としてDockerコンテナを使用することです。ビルドが開始されると（エンジニアまたは自動ビルドプロセスによって）、適切なイメージからコンテナが作成され、プロセスが完了し、出力が永続ストレージにコピーされ、コンテナが破棄されます。

現時点では、私は期待通りにすべてが機能することを証明するために手動で構築手順を歩いている途中です。それはありません！

適切なツールがインストールされたDockerコンテナがあり、手動でCrossBuildを呼び出してプロジェクトを正常にビルドすることができます。残念ながら、ビルドには約30分かかります。 Windowsワークステーションで同じツールを直接使用すると、ビルド時間は約1.5分になります。

私はWindows 7（x64）ワークステーションを持っており、Dockerコンテナを実行するために、私はVirtualBoxでBoot2Dockerを使用しています。私は（どちらかBoot2Docker VM内のps -auxを実行しているか、WindowsタスクマネージャでBoot2Docker VMのリソース使用量を観測することによって）ドッカーコンテナのCPUとメモリの使用状況を観察する場合は、ほとんどすべてのリソースが使用されている

（< 5％のCPU使用率、数十MBのRAM）。 Windowsで直接CrossBuildを使用してプロジェクトをビルドすると、CPU使用率は変動しますが、ピークは25％（つまり、4つのスレッドのうちの1つを最大にする）です。

原則として、Dockerコンテナ内のプロセスは、Pythonで単純な無限ループを作成し、それを実行し、ホストPC上のタスクマネージャでCPU使用率を監視することによって、利用可能なCPUリソースをすべて占有できることを証明しました。予想どおり、単一のコアが完全に利用されました。舞台裏

さらに情報

• 、そしてCrossBuildは、の中やドッカーコンテナのうちデータを取得するために
• GCC-ARMを駆動している私はVirtualBoxの共有フォルダを使用していますし、各共有に対して-v引数を使用してコンテナを作成します。問い合わせ

  の

現在の行は、私はインスピレーションの瞬間があったと私はとアウトでデータを取得しています方法によって引き起こされる読み取り/書き込み帯域幅の制約があるかもしれないかどうかを疑問に思い始めました（すなわち、ほとんどの時間が読み取りおよび書き込みを待つのに費やされるので、CPUが完全に利用されることはありません）。私はこの可能性を調査します。

Answer 1

WindowsからVirtualBoxにドライブを共有するのは非常に遅いです。ローカルマシンからビルドする場合は、代わりにDocker for Windowsを使用してください。あなたはクラウドCI環境を複製する場合は、ボリュームを作成

docker volume create --name mydata 

アップロードデータ、それに

docker run -v mydata:/data --name temp alpine top 
docker cp /my/local/dir temp:/data 
docker rm -f temp 

あなたの他のCIの容器に、必要に応じてその後（そのステップを含めることができるドッキングウィンドウのボリュームをマウント上記のように）。

実際のCIの場合、データはgithubのような他のソースから来る可能性があることに注意してください。その場合、データをドッカーボリュームにダウンロードするためだけにコンテナを作成することができます。