在可能的情况下，不要使用其他答案中描述的构建参数。这是一个古老的混乱的解决方案。Docker的target属性解决了这个问题。

目标的例子

Dockerfile

FROM foo as base

RUN ...

# Build dev image
FROM base as image-dev

RUN ...
COPY ...

# Build prod image
FROM base as image-prod

RUN ...
COPY ...

docker build --target image-dev -t foo .

version: '3.4'

services:

  dev:
    build:
      context: .
      dockerfile: Dockerfile
      target: image-dev

现实世界中

dockerfile在现实世界中变得很复杂。使用buildkit & COPY——from可以获得更快、更可维护的dockerfile:

Docker在目标之上构建每个阶段，而不管它是否被继承。使用buildkit只构建继承的阶段。Docker必须是v19+。希望这很快会成为默认功能。 目标可以共享构建阶段。使用COPY——from来简化继承。

FROM foo as base
RUN ...
WORKDIR /opt/my-proj

FROM base as npm-ci-dev
# invalidate cache
COPY --chown=www-data:www-data ./package.json /opt/my-proj/package.json
COPY --chown=www-data:www-data ./package-lock.json /opt/my-proj/package-lock.json
RUN npm ci

FROM base as npm-ci-prod
# invalidate cache
COPY --chown=www-data:www-data ./package.json /opt/my-proj/package.json
COPY --chown=www-data:www-data ./package-lock.json /opt/my-proj/package-lock.json
RUN npm ci --only=prod

FROM base as proj-files
COPY --chown=www-data:www-data ./ /opt/my-proj

FROM base as image-dev
# Will mount, not copy in dev environment
RUN ...

FROM base as image-ci
COPY --from=npm-ci-dev /opt/my-proj .
COPY --from=proj-files /opt/my-proj .
RUN ...

FROM base as image-stage
COPY --from=npm-ci-prod /opt/my-proj .
COPY --from=proj-files /opt/my-proj .
RUN ...

FROM base as image-prod
COPY --from=npm-ci-prod /opt/my-proj .
COPY --from=proj-files /opt/my-proj .
RUN ...

开启实验模式。

sudo echo '{"experimental": true}' | sudo tee /etc/docker/daemon.json

启用buildkit进行构建。Buildkit默认构建时不带缓存-启用——build-arg BUILDKIT_INLINE_CACHE=1

CI构建工作。

DOCKER_BUILDKIT=1 \
    docker build \
    --build-arg BUILDKIT_INLINE_CACHE=1 \
    --target image-ci\
    -t foo:ci
    .

使用——cache-from从拉出的图像中缓存

生产工作

docker pull foo:ci
docker pull foo:stage

DOCKER_BUILDKIT=1 \
    docker build \
    --cache-from foo:ci,foo:stage \
    --target image-prod \
    -t prod
    .

出于某种原因，这里的大多数答案都没有帮助我(可能与Dockerfile中的From图像有关)

所以我更喜欢在我的工作空间中结合——build-arg创建一个bash脚本，以便在Docker构建时通过检查参数是否为空来处理if语句

Bash脚本:

#!/bin/bash -x

if test -z $1 ; then 
    echo "The arg is empty"
    ....do something....
else 
    echo "The arg is not empty: $1"
    ....do something else....
fi

Dockerfile：

FROM ...
....
ARG arg
COPY bash.sh /tmp/  
RUN chmod u+x /tmp/bash.sh && /tmp/bash.sh $arg
....

码头工人构建:

docker build --pull -f "Dockerfile" -t $SERVICE_NAME --build-arg arg="yes" .

注意:这将被用于bash脚本中的else (false)

docker build --pull -f "Dockerfile" -t $SERVICE_NAME .

备注:这将进入if (true)

编辑1:

经过几次尝试，我找到了下面的文章和这一篇 这让我明白了两件事:

1) FROM之前的ARG在构建之外

2)默认shell是/bin/sh，这意味着if else在docker构建中有一点不同。例如，你只需要一个“=”而不是“==”来比较字符串。

你可以在Dockerfile里面做这个

ARG argname=false   #default argument when not provided in the --build-arg
RUN if [ "$argname" = "false" ] ; then echo 'false'; else echo 'true'; fi

在docker构建中:

docker build --pull -f "Dockerfile" --label "service_name=${SERVICE_NAME}" -t $SERVICE_NAME --build-arg argname=true .

接受的答案可以解决这个问题，但是如果你想在dockerfile中有多行if条件，你可以把\放在每行的末尾(类似于你在shell脚本中的做法)，并以;结尾每个命令。您甚至可以将set -eux之类的命令定义为第一个命令。

例子:

RUN set -eux; \
  if [ -f /path/to/file ]; then \
    mv /path/to/file /dest; \
  fi; \
  if [ -d /path/to/dir ]; then \
    mv /path/to/dir /dest; \
  fi

在你的情况下:

FROM centos:7
ARG arg
RUN if [ -z "$arg" ] ; then \
    echo Argument not provided; \
  else \
    echo Argument is $arg; \
  fi

然后使用:

docker build -t my_docker . --build-arg arg=42

我看到了很多可能的解决方案，但没有一个适合我今天面临的问题。所以，我正在花时间用另一个对我有用的可能的解决方案来回答这个问题。

在我的例子中，我利用了众所周知的if ["$VAR" == "this"];然后重复“do that”;fi。警告是Docker，我不知道为什么，在这种情况下不喜欢双等号。所以我们需要这样写if ["$VAR" = "this"];然后重复“do that”;fi。

这里有一个完整的例子，适用于我的情况:

FROM node:16

# Let's set args and envs
ARG APP_ENV="dev"
ARG NPM_CMD="install"
ARG USER="nodeuser"
ARG PORT=8080
ENV NPM_CONFIG_PREFIX=/home/node/.npm-global
ENV PATH=$PATH:/home/node/.npm-global/bin
ENV NODE_ENV=${APP_ENV}

# Let's set the starting point
WORKDIR /app

# Let's build a cache
COPY package*.json .
RUN date \
 # If the environment is production or staging, omit dev packages
 # If any other environment, install dev packages
 && if [ "$APP_ENV" = "production" ]; then NPM_CMD="ci --omit=dev"; fi \
 && if [ "$APP_ENV" = "staging" ]; then NPM_CMD="ci --omit=dev"; fi \
 && npm ${NPM_CMD} \
 && usermod -d /app -l ${USER} node

# Let's add the App
COPY . .

# Let's expose the App port
EXPOSE ${PORT}

# Let's set the user
USER ${USER}

# Let's set the start App command
CMD [ "node", "server.js" ]

因此，如果用户传递了正确的build参数，docker build命令将为生产应用创建一个映像。如果没有，它将创建一个带有dev Node.js包的应用程序映像。

为了让它工作，你可以这样调用:

# docker build --build-arg APP_ENV=production -t app-node .

使用Bash脚本和Alpine/Centos

Dockerfile

FROM alpine  #just change this to centos 

ARG MYARG=""
ENV E_MYARG=$MYARG

ADD . /tmp
RUN chmod +x /tmp/script.sh && /tmp/script.sh

script.sh

#!/usr/bin/env sh

if [ -z "$E_MYARG" ]; then
    echo "NO PARAM PASSED"
else
    echo $E_MYARG
fi

传递参数: docker build -t test——build-arg MYARG="this is a test"。

....
Step 5/5 : RUN chmod +x /tmp/script.sh && /tmp/script.sh
 ---> Running in 10b0e07e33fc
this is a test
Removing intermediate container 10b0e07e33fc
 ---> f6f085ffb284
Successfully built f6f085ffb284

无参数: Docker build -t test。

....
Step 5/5 : RUN chmod +x /tmp/script.sh && /tmp/script.sh
 ---> Running in b89210b0cac0
NO PARAM PASSED
Removing intermediate container b89210b0cac0
....

直接使用“test”二进制代码就可以做到这一点。如果你不想指定一个“else”条件，你也应该使用noop命令“:”，这样docker就不会因为一个非零的返回值错误而停止。

RUN test -z "$YOURVAR" || echo "var is set" && echo "var is not set"
RUN test -z "$YOURVAR" && echo "var is not set" || :
RUN test -z "$YOURVAR" || echo "var is set" && :