标签: docker-multi-stage-build

我想在Docker Multi Stage Build的构建阶段的一层中缓存Maven依赖项。

我的Dockerfile如下所示：

FROM maven:3-jdk-8 as mvnbuild
RUN mkdir -p /opt/workspace
WORKDIR /opt/workspace
COPY pom.xml .
RUN mvn -B -s /usr/share/maven/ref/settings-docker.xml dependency:resolve
COPY . .
RUN mvn -B -s /usr/share/maven/ref/settings-docker.xml package

FROM openjdk:8-jre-alpine
...

```

我基于Docker Multi Stage Build博客文章（也在Github上提供）中提供的示例创建了该Dockerfile 。

当我运行构建时，没有看到一次下载了依赖项dependency:resolve，然后再重复使用package，而是看到了两个步骤都下载了依赖项。

有人有这个工作吗？我在这里做错了什么？

当您在 ASP.NET Core 站点上的 Visual Studio 中单击“添加 Docker 支持”时，这是默认的多阶段 Dockerfile。

FROM microsoft/aspnetcore:2.0 AS base
WORKDIR /app
EXPOSE 80

FROM microsoft/aspnetcore-build:2.0 AS build
WORKDIR /src
COPY WebApplication1.sln ./
COPY WebApplication1/WebApplication1.csproj WebApplication1/
RUN dotnet restore
COPY . .
WORKDIR /src/WebApplication1
RUN dotnet build -c Release -o /app

FROM build AS publish
RUN dotnet publish -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "WebApplication1.dll"]

为什么他们选择使用四个阶段，开始和结束base阶段。另外，为什么要publish使用相同的build基本图像创建舞台。为什么 Dockerfile 看起来不像三个阶段：

FROM microsoft/aspnetcore-build:2.0 …

我们目前正在处理两个项目:

1个基于C++的项目

2基于Nodejs的项目

这两个项目是分开的,这意味着它们具有不同的代码库(git repoitory)和工作目录.

C++项目将生成一个.nodeNodejs项目将使用的节点绑定文件.

我们尝试使用多阶段为Nodejs项目构建一个docker镜像,如下所示:

from ubuntu:18.04 as u
WORKDIR /app
RUN apt-get........  
copy (?) .  #1 copy the c++ source codes
RUN make  

from node:10
WORKDIR /app
copy (?) .  #1 copy the nodejs cource codes
RUN npm install
copy --from=u /app/dist/xx.node ./lib/
node index.js

我将通过构建图像docker build -t xx (?) #2.

但是,如dockerfile和命令中所述,如何设置context目录(请参阅注释#2)？因为它会影响dockerfile中的路径(参见注释#1).

我应该把哪个项目放在上面dockerfile呢？

我是Docker的新手，正在尝试探索多阶段构建。我想在Docker上运行特定阶段docker build -t build-stage-tag --target build

我希望它可以运行以下阶段dependencies --> compile --> build并跳过test。但是碰巧它也运行测试阶段。

让我知道我对多阶段构建的理解--target是错误的还是我的docker文件中存在一些错误。

我想做的是运行build舞台而不运行，test反之亦然。

这是我的Dockerfile的外观：

# Pull base image
FROM openjdk:8u171 as dependencies

# Install Scala
## Piping curl directly in tar
// do some stuff

# Copy source into container
COPY . /usr/src/app

FROM dependencies as compile
WORKDIR /usr/src/app
# Test and build the jar in the same step to save time
RUN sbt -Dsbt.log.noformat=true compile
RUN sbt -Dsbt.log.noformat=true …

我有一个 Dockerfile，它分为两阶段多阶段 docker 构建。第一阶段生成一个基本的 gcc 构建环境，其中编译了许多 C 和 C++ 库。第二阶段使用该COPY --from=命令将库文件从第一阶段复制/usr/local/lib/libproto*到当前图像的。

我看到的问题是第一个图像包含从通用库文件名到特定版本文件名的符号链接。AFAIK 这是 Debian 和许多其他 Linux 系统中的常见做法。Docker 的COPY命令似乎不理解符号链接，因此制作了两个完整的库文件副本。这会导致更大的 Docker Image 大小和来自后续apt-get命令的警告到ldconfig: /usr/local/lib/libprotobuf.so.17 is not a symbolic link.

我的特定文件目前看起来像：

#Compile any tools we cannot install from packages
FROM gcc:7 as builder
USER 0
RUN \
  apt-get -y update && \
  apt-get -y install \
    clang \
    libc++-dev \
    libgflags-dev \
    libgtest-dev
RUN \
  # Protocol Buffer & gRPC
  # install protobuf …

我正在使用多阶段 Docker 构建构建 Quarkus 本机可执行文件，如中所述 Quarkus - Building a Native Executable 中所述

我的项目只包括 Hello World-Example 和一些添加的 ORM 功能（所以不是很多依赖项）。构建工作正常，但我的问题是，它在构建期间消耗了大量内存。这意味着最多6 GiB. 我认为构建时间也很长（总共约 4-6 分钟）。

当我在我们的 CI/CD 基础设施上构建时，问题就开始了。我们那里没有那么多内存，所以构建失败了Error: Image build request failed with exit status 137。

我做错了什么还是这只是正常行为？有没有可能至少减少内存消耗？

在多阶段 docker 构建中，我执行单元测试，生成覆盖率报告并在构建阶段构建可执行文件，然后将可执行文件复制到运行阶段：

FROM golang:1.13 AS build-env
COPY . /build
WORKDIR /build

# execute tests
RUN go test ./... -coverprofile=cover.out
# execute build
RUN go build -o executable

FROM gcr.io/distroless/base:latest
COPY --from=build-env /build/executable /executable
ENTRYPOINT ["/executable"]

如何cover.out在 Jenkins 环境中提取以发布覆盖率报告？

我想在多阶段 docker 构建中使用变量。类似于This question（在撰写本文时未回答。）

我的具体用例是在一个builder阶段构建我的 Go 项目并将完成的目录保存在一个变量中，并在下一阶段使用相同的变量：BUILD_DIR变量。

我的 Dockerfile 是（注释行中的示例不起作用。）：

FROM golang:1.11.5 as builder

WORKDIR /project-name
# What I want to do:
#ENV BUILD_DIR /project-name
#WORKDIR ${BUILD_DIR}


# Vendored dependencies of my project:
COPY ./vendor ./vendor
COPY ./*.go ./
# Source code:
COPY ./go.* ./

RUN GOFLAGS=-mod=vendor GOOS=linux go build .

FROM something-else:some-version

WORKDIR some-folder

# Executable from previous stage:
COPY --from=builder /project-name/executable-name .
# Config files:
COPY ./conf ./conf

# What I want to …

我尝试使用docker-multi-stage-build在私有公司网络中构建go图像：

FROM golang:latest as builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN  GO111MODULE="on" CGO_ENABLED=0 GOOS=linux go build -o main ${MAIN_PATH}

FROM alpine:latest
LABEL maintainer="Kozmo"
RUN apk add --no-cache bash
WORKDIR /app
COPY --from=builder /app/main .
EXPOSE 8080
CMD ["./main"]

Step 1/13 : FROM golang:latest as builder
 ---> 2421885b04da
Step 2/13 : WORKDIR /app
 ---> Using cache
 ---> 6555644dbd16
Step …