仅用于在不运行的情况下构建程序的Docker容器

如何解决仅用于在不运行的情况下构建程序的Docker容器

我有一个非常简单的问题（我认为）。拥有仅负责构建项目的docker容器是个好主意吗？我想在一个容器（容器A）中构建一个项目，然后将目标文件和库文件从docker卷中的容器A共享到另一个容器（容器B），我想在其中将目标文件用作目标程序中的参数（容器B）。这有点难以描述，所以如果您需要，我会尽力解释。非常感谢您的帮助。

编辑： 好吧，我将尝试描述我的情况。容器B包含一个用于复杂计算（模拟等）的程序。我的目标是创建一个将接收Dockerfile作为输入的应用程序，然后我将要以编程方式构建映像并运行Docker容器（结果，我将在容器A中构建项目）。接下来，我想将输出（二进制文件，类文件，库等）从容器A传递到容器B以运行模拟（例如：模拟运行myfilefromcontainerA）。之后，我需要收集模拟结果文件，并在主机级别的应用程序中对其进行处理。

解决方法

在某些情况下，仅包含构建工具的容器是合理的。但是，不要不要将代码或二进制文件放入Docker卷中。使用该构建工具容器来构建您的应用程序，并将其用作多阶段构建的第一步。

假设您有一个仅用于构建工具的映像。也许看起来像：

FROM ubuntu:18.04
RUN apt-get update \
 && DEBIAN_FRONTEND=noninteractive \
    apt-get install --no-install-recommends --assume-yes \
      build-essential \
      ... libfoo-dev ...
# no EXPOSE,USER,CMD,&c.

现在您有了本地源代码树，因此可以像调用该图像一样

sudo docker run \
  --rm \
  -v "$PWD:$PWD" \
  -w "$PWD" \
  -u $(id -u) \
  my/build-tools \
  ./build-everything.sh

这涉及并且需要在系统上具有管理员等效的特权（例如，您可以使用此调用来覆盖主机的/etc/sudoers文件），因此我不建议您每天使用此特权采用。它在两个地方很有价值：

1. 您有一个具有一堆副本的CI系统。与将所有副本更新为更新的工具链相比，将构建工具安装在CI系统可以运行并且可以自由更新的映像中要容易得多。
2. 您的构建系统具有许多主机级别的依赖项，因此必须针对一组特定的已知良好版本进行本地测试。

如果您希望以此为基础进行后续构建，则可以。通常，您希望构建的结果是可以推送并在其他位置运行的Docker映像。在多阶段构建中使用它看起来像：

FROM my/build-tools AS build
WORKDIR /build
COPY . ./
RUN ./build-everything.sh

FROM ubuntu:18.04
RUN apt-get update ... # to install runtime dependencies only
COPY --from=build /build/the_app /usr/bin/the_app
CMD ["the_app"]