在Docker中使用覆盖入口点运行测试脚本是一种反模式吗？

Question

我有一个下面的Dockerfile

FROM python:3.6

WORKDIR /app
 
ADD main.py /app

ENTRYPOINT [ "python3",  "main.py" ]

我有一个在部署之前运行的先决条件测试，用于验证连接、输入文件等

所以我将测试脚本添加到Docker镜像中，如下所示

FROM python:3.6

WORKDIR /app
 
ADD main.py /app
ADD test.py /app

ENTRYPOINT [ "python3",  "main.py" ]

为了进行测试，我运行docker container，如下所示

docker run --entrypoint python3 myImage test.py 

这是Docker中的反模式吗？创建单独的测试容器镜像是不是更好的做法？

Answer 1

我通常推荐使用CMD而不是ENTRYPOINT，原因有两个。

CMD ["python3", "main.py"]  # not ENTRYPOINT

您用来运行测试脚本的调用演示了其中之一。覆盖ENTRYPOINT有点笨拙，但是覆盖CMD非常简单；您只需运行

docker run myImage \
  python3 test.py

命令更自然地组合在一起。

首选CMD的第二个原因与测试脚本所做的事情有关:它“验证连接、输入文件等”。在容器启动时运行此脚本是非常合理的，如果成功，则继续运行主应用程序。您可以编写一个包装器脚本，该脚本将一些命令作为参数，运行测试脚本，如果成功，则启动给定的命令：

#!/bin/sh

# Run the verification script
if ! python3 test.py ; then
  echo 'Pre-launch verification failed, exiting' >&2
  exit 1
fi

# If that succeeded, run the command passed to us as arguments
exec "$@"

现在，您可以使用该脚本作为图像的ENTRYPOINT。当您使用have both ENTRYPOINT and CMD时，CMD将作为参数传递给ENTRYPOINT，这正是此脚本所期望的。

FROM python:3.6
WORKDIR /app

# Prefer COPY to ADD, unless you specifically need URL fetching or
# archive unpacking.  Use a relative path for the COPY destination
# to avoid repeating the path name.
COPY main.py test.py entrypoint.sh .

ENTRYPOINT ["/app/entrypoint.sh"] # must be JSON-array syntax
CMD ["python3", "main.py"]        # can be any valid CMD

使用此设置时，如果在docker run命令中替换CMD，则ENTRYPOINT仍然有效。

# Get an interactive debugging shell in this container, but only
# after the startup-time tests pass.
docker run --rm -it myImage /bin/sh

# I don't know why the startup-time tests aren't passing; skip even
# that.
docker run --rm -it --entrypoint /bin/sh myImage

(对于更一般的测试概念，包括应用程序的单元测试和集成测试，我通常从Docker外部启动这些测试；我不会构建特殊的纯测试容器，也不会在我的生产映像中包含测试代码。这不同于启动时配置检查，这似乎是您想要的。)