为什么我的自动构build在Docker容器内运行得如此缓慢？
目前，我正在为Rowley Associates CrossStudio开发的各种embedded式固件项目开发自动化构build/ CI系统。 这些项目可以使用CrossBuild在命令行构build。
现在，到Docker部分：
我们需要一种保证一致的构build环境的方法。 构build必须在任何工程师工作站或构build服务器上以相同的方式运行。 由于所有构build步骤（包括运行CrossBuild）都可以在命令行Linux环境中执行，所以我select使用Docker容器来保证环境的一致性。
我的意图是以如下方式使用Docker容器作为一次性的“构build机器人”。 当一个构build开始时（无论是由工程师手动还是通过自动构build过程），都会从相应的映像创build一个容器，stream程运行完成，输出复制到永久性存储，然后容器被丢弃。
目前，我正在手动完成构build步骤，以certificate一切正常。 它不！
我有一个Docker容器与适当的工具安装，并可以手动调用CrossBuild，并成功地build立我的项目。 不幸的是，构build需要大约30分钟才能完成。 相比之下，如果我在Windows工作站上直接使用相同的工具，build立时间约为1.5分钟。
我有一个Windows 7（x64）工作站，所以要运行Docker容器，我在VirtualBox上使用Boot2Docker。
如果我观察Docker容器的CPU和内存使用情况（通过在Boot2Docker虚拟机内运行ps -aux或在Windows任务pipe理器中观察Boot2Docker虚拟机的资源使用情况），几乎不使用任何资源（CPU使用率<5％ ，几十兆字节的RAM）。 如果我直接在Windows上使用CrossBuild构build项目，则CPU使用率会波动，但会达到25％的峰值（即最大化我的4个线程中的一个）。
我已经certificate，原则上，Docker容器中的进程可以通过在Python中编写一个简单的无限循环，运行它并观察主机上的任务pipe理器中的CPU使用情况来占用所有可用的CPU资源。 正如所料，一个核心被充分利用。
更多信息
- 在幕后，CrossBuild正在推动GCC-ARM
- 为了使数据进出Docker容器，我使用了VirtualBox共享文件夹，然后使用每个共享的-v参数创build容器。
目前的调查线
我只是有一点灵感，开始怀疑是否可能有读取/写入的带宽限制，因为我得到的数据进出容器的方式（即CPU从来没有被充分利用的大部分时间花在等待读取和写入）。 我会调查这种可能性。
从Windows到VirtualBox共享驱动器的速度非常慢。 如果要从本地机器构build，请改用Docker for Windows 。 如果要复制云CIconfiguration环境，请创build一个卷
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。 在这种情况下，您可以创build一个容器，将数据下载到泊坞窗卷中。