Question

我目前正在为Rowley Associates CrossStudio开发的各种嵌入式固件项目开发自动构建/ CI系统。可以使用CrossBuild在命令行中构建项目。

现在，转到Docker部分：

我们需要一种保证一致构建环境的方法。构建必须在任何工程师工作站或构建服务器上以相同方式运行。由于所有构建步骤（包括运行CrossBuild）都可以在命令行Linux环境中执行，因此我选择使用Docker容器来保证环境的一致性。

我的目的是使用Docker容器作为一次性使用的机器人和＃39;以下列方式。当启动构建时（由工程师手动或通过自动构建过程），从适当的映像创建容器，该过程运行完成，输出被复制到持久存储，然后容器被丢弃。

目前，我正在手动完成构建步骤，以证明一切都按预期工作。它没有！

我有一个安装了相应工具的Docker容器，可以手动调用CrossBuild并成功构建我的项目。不幸的是，构建大约需要30分钟才能完成。相比之下，如果我直接在Windows工作站上使用相同的工具，则构建时间约为1.5分钟。

我有一个Windows 7（x64）工作站，所以要运行Docker容器，我在VirtualBox上使用Boot2Docker。

如果我观察Docker容器的CPU和内存使用情况（通过在Boot2Docker VM中运行ps -aux或观察Windows任务管理器中的Boot2Docker VM的资源使用情况），几乎没有使用任何资源（＆lt; 5％的CPU使用率，数十兆字节的RAM）。如果我直接在Windows上使用CrossBuild构建项目，则CPU使用率会波动，但峰值为25％（即最大化我的4个线程中的一个）。

我已经证明，原则上，Docker容器内的进程可以占用所有可用的CPU资源，方法是在Python中编写一个简单的无限循环，运行它并观察主机PC上任务管理器中的CPU使用情况。正如所料，一个核心被充分利用。

更多信息

在幕后，CrossBuild正在推动GCC-ARM
为了将数据输入和输出Docker容器，我使用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容器中安装该docker卷（该步骤可以包含在上面）。

请注意，对于真实的CI，您的数据可能来自其他来源，例如github。在这种情况下，您可以创建一个容器，只是为了将数据下载到docker卷中。

为什么我的自动构建在Docker容器内运行得如此之慢？

1 个答案: