BMitch

这似乎是一个错误 bug in the docker CLI .这应该不会对基础摘要产生任何影响。如果您知道要查询的图像,那么查看该图像的摘要可能会更容易:

$ docker image inspect nginx:latest --format '{{index .RepoDigests 0}}'
nginx@sha256:644a70516a26004c97d0d85c7fe1d0c3a67ea8ab7ddf4aff193d9f301670cf36

docker分层文件系统是写时拷贝,该拷贝位于文件级别,而不是单个文件系统块。这意味着对具有chmod的文件的权限位进行更改会导致将整个文件复制到新层:

COPY /target/$JAR_FILE app.jar
RUN chmod 775 app.jar

结果是一个30MB的文件将占用2倍的空间,每层一次,权限不同。理想情况下,您应该在源位置修复文件权限,以避免对文件进行chmod。然后,在运行中只需要复制步骤,而不需要添加chmod:

COPY /target/$JAR_FILE app.jar

在詹金斯的管道里,你需要逃离 $ . 您还在Jenkins和运行的命令中使用单引号。您可以使用与Jenkins不同的shell语法,而不是转义命令中的命令:

sh """
  docker ps -a \
    | awk '{ print \$1,\$2 }' \
    | grep imagename \
    | awk '{print \$1 }' \
    | xargs -I {} docker rm -f {}
  """

我进行了一次测试,没有任何问题:

$ cat .env
ENV=default
USER_NAME=test2
SPECIAL=field=with=equals;and;semi-colons

$ cat docker-compose.env.yml
version: '2'

services:
  test:
    image: busybox
    command: env
    environment:
      - SPECIAL

$ docker-compose -f docker-compose.env.yml up
Creating network "test_default" with the default driver
Creating test_test_1_55eac1c3767c ... done
Attaching to test_test_1_d7787ac5bfc0
test_1_d7787ac5bfc0 | PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
test_1_d7787ac5bfc0 | HOSTNAME=d249a16a8e09
test_1_d7787ac5bfc0 | SPECIAL=field=with=equals;and;semi-colons
test_1_d7787ac5bfc0 | HOME=/root
test_test_1_d7787ac5bfc0 exited with code 0

当运行不需要保持停止状态的容器时,使用 docker run --rm ... 自动清除已停止的容器。

如果容器生成卷,则在 docker volume ls ,一旦不再需要数据,您可能会希望清除这些数据与 --rm 标志运行时,将自动删除匿名卷(显示为长唯一id)。

Docker还提供命令:

docker system prune

它可以自动清理图像、容器、网络甚至卷请注意,在运行该命令之前,尤其是在自动执行该命令之前,您应该花时间了解它的作用编写此命令脚本时,可以使用 -f 标记以绕过提示。

在进行修剪之前,您可以检查:

docker system df

查看每个组件使用了多少磁盘,每个组件都有自己的prune命令,例如。 docker container prune 和 docker volume prune ,如果你只想清理一个区域。

有关prune命令的详细信息,请参见: https://docs.docker.com/engine/reference/commandline/system_prune/

要么你发现了一个bug,要么是有什么东西把容器打开了。我能找到的最接近的问题是相当古老的 #30927 是的。我将开始调查dockerd和os日志,看看是否有任何错误,你可以找到那里。对于Dockerd来说 journalctl -u docker 对于系统环境。在操作系统上,/var/log下的任何内容都可以开始调试。我可以想象的潜在阻碍因素包括:

• 一个失败的填充进程,可能是一个陷入僵尸状态的runc
• 一个无法释放的挂载,可能有东西试图读取docker文件系统中的文件
• 查询尚未退出的容器的命令,可能是拖拽大量管道等待卸载管道/缓冲器的日志。

如果您找不到任何东西,moby/moby repo中的问题可能是合适的,但是如果没有任何错误日志来指出原因或复制的方法,则将很难修复。

错误消息指示您试图下载的图像已损坏。我能想到的地方有几个:

• 在远程注册表服务器上
• 在途中
• 记忆中
• 在磁盘上
• 根据申请

考虑到图像的受欢迎程度,我将排除注册表服务器有问题的可能性。您可能有一个不稳定的服务器,在下载大图像时会触发内存或磁盘问题。在Linux上,您可能会在 dmesg 是的。

Docker的版本已经足够新了,任何过去关于它的问题早就被解决了。tar文件处理中只有一个与非常大的层(超过8gb)相关的问题,它不适用于您正在拉取的图像。tar处理直接嵌入到docker中,因此更改或升级tar二进制文件不会影响docker。

可能存在存储驱动程序和后端存储设备问题。如果Docker还没有默认设置为overlay2(您可以在 docker info 并用/etc/docker/daemon.json中的条目更改它)。

我在名单上的第一个猜测是“在途”部分。由于请求将通过https,因此不会来自坏包。但网络上拦截所有网络流量的代理可能是罪魁祸首。如果您有代理,请确保Docker已配置为登录并使用您的代理。有关详细信息,请参见 https://docs.docker.com/config/daemon/systemd/#httphttps-proxy

容器是运行进程的包装器(该包装器是命名空间和cgroup)。正在运行的进程由dockerfile的entrypoint和cmd行定义。您可以重写运行容器时要运行的映像的默认进程,对于cmd的值,重写涉及在映像名称后传递另一个命令。

所以当你的dockerfile以:

COPY setup.sh /setup.sh
RUN ["chmod", "+x", "/setup.sh"]
CMD ["/setup.sh"]

您已经在图像中定义了cmd的默认值。但是当你跑的时候:

docker build -t docker-test .; docker run -it docker-test bash

这个 ./setup.sh CMD值替换为 bash . 这意味着 setup.sh 永远不会跑。

你可以用几种方法解决这个问题。

1. 你可以跑你的 塞特普什 作为图像构建的一部分。如果脚本不依赖于容器的运行方式(例如外部卷、传入的环境变量等),则这是更好的选择。

2. 将脚本移动到入口点,并通过运行提供的命令完成脚本。当你同时定义一个入口点和一个CMD时,容器只运行一个进程,所以Docker的行为是把CMD作为参数传递给入口点。要运行cmd,需要在entrypoint脚本中执行该操作。

选项1看起来像您已经完成的解决方案,我建议您的答案是:

COPY setup.sh /setup.sh
RUN ["chmod", "+x", "/setup.sh"]
RUN ["/setup.sh"]
CMD bash

您需要在脚本的顶部包含shell,以便Linux知道如何运行它:

#!/bin/sh
# The #!/bin/sh above is important, you can also replace that with the path to bash
# get addons path
addons_path=`ls -d /mnt/extra-addons/* | paste -d, -s`
# can't use / because directory name contains, using #
sed -i -e "s#__addons__path__#${addons_path}#" /etc/odoo/odoo.cfg

如果每次运行容器时/mnt/extra addons/changes,选项2很有用。这看起来像:

COPY setup.sh /setup.sh
RUN ["chmod", "+x", "/setup.sh"]
ENTRYPOINT ["/setup.sh"]
CMD ["bash"]

在安装脚本中添加一行:

#!/bin/sh
# get addons path
addons_path=`ls -d /mnt/extra-addons/* | paste -d, -s`
# can't use / because directory name contains, using #
sed -i -e "s#__addons__path__#${addons_path}#" /etc/odoo/odoo.cfg

# this next line runs the passed arguments as pid 1, replacing this script
# this is how you run an entrypoint and fall through to a cmd
exec "$@"

对于一个 COPY 命令要缓存,则要复制的源上的校验和必须相同。您可以比较Docker历史输出中缓存映像和您刚刚构建的映像之间的校验和。最重要的是,除了文件内容外,校验和还包括诸如文件所有者和文件权限之类的元数据。文件中的空白更改(如在Linux和Windows样式之间更改为换行)也会影响此操作。如果从repo下载代码,元数据(如所有者)可能与缓存值不同。

在主机上和Docker映像内部使路径相同,例如。

docker run -v /var/run/docker.sock:/var/run/docker.sock \
  -v /home/user:/home/user -w /home/user/project parent_image ...

通过将卷作为/home/user安装在映像中的同一位置,命令如下 docker-compose up 使用相对绑定挂载将在与Docker套接字交谈时使用容器路径名,该套接字将与主机上的路径匹配。

/tmp存在于图像内部,您的问题在其他地方:

$ docker run -it --rm buildpack-deps:stretch-scm /bin/bash
root@c7fc40670734:/# ls -al /tmp
total 8
drwxrwxrwt 1 root root 4096 Nov 16 11:16 .
drwxr-xr-x 1 root root 4096 Dec 27 19:48 ..

注意/tmp应该设置为1777,而不是777,您需要粘性位来保证安全性

command: ["python2", "/usr/bin/supervisord", "--nodaemon", "--configuration", "/etc/supervisor/supervisord.conf"]

您提供的命令使用exec语法。见 documentation on CMD (同样适用于 RUN 和 ENTRYPOINT ):

如果使用 CMD ,然后 <command> 将执行 在里面 /bin/sh -c :

FROM ubuntu
CMD echo "This is a test." | wc -

如果你想 <命令> 如果没有外壳,你必须 将命令表示为json数组,并给出 可执行。此数组形式是 CMD . 任何 附加参数必须单独表示为 数组:

FROM ubuntu
CMD ["/usr/bin/wc","--help"]

在您的例子中,您需要一个bash shell来处理 .bashrc 文件,这意味着您需要以下内容:

command: ["/bin/bash", "-c", "python2 /usr/bin/supervisord --nodaemon --configuration /etc/supervisor/supervisord.conf"]

编辑:使用ubuntu:16.04中的/root/.bashrc,您将在文件顶部看到以下内容:

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

可以使用此sed命令在此行之前修改文件:

sed -i '4s;^;export PYTHONPATH=$PYTHONPATH:/models/research:/models/research/slim\n;' /root/.bashrc

我会考虑将它放在用于启动容器的脚本中,而不是破解.bashrc,例如start.sh:

#!/bin/sh
export PYTHONPATH=$PYTHONPATH:/models/research:/models/research/slim
exec python2 /usr/bin/supervisord --nodaemon --configuration /etc/supervisor/supervisord.conf

然后将其添加到图像中:

COPY start.sh /
RUN chmod 755 /start.sh # if your build server doesn't have this permission set
CMD [ "/start.sh" ]

您可以切换到 none 日志驱动程序,无论是作为所有新容器的默认值,还是基于每个容器。有关日志驱动程序的文档如下: https://docs.docker.com/config/containers/logging/configure/#supported-logging-drivers

要将其配置为新容器的守护进程默认值,请使用以下命令设置/etc/docker/daemon.json:

{
  "log-driver": "none"
}

或者运行单个容器而不记录日志:

docker run --log-driver none ...

如果不需要从主机访问这些卷文件,请使用命名卷而不是主机装载。Docker将初始化命名卷的内容,包括权限和所有权,避免这样的权限问题:

version: '2'

volumes:
  prometheus:
  grafana:

services:
  prometheus:
    image: prom/prometheus
    ports:
      - 9090:9090
    volumes:
      - prometheus:/prometheus
    command: 
      - --config.file=/etc/prometheus/prometheus.yml 

  grafana:
    image: grafana/grafana
    ports:
      - "3000:3000"
    volumes:
      - grafana:/var/lib/grafana

为了解决主机挂载的权限问题的一般解决方案,我的 docker-base 可以使用映像以及入口点以及对容器启动方式的更改来动态调整容器中的用户ID,使其与卷装入的用户ID相匹配。

这表示要推送到该存储库的指定层在该存储库中不存在,但它们确实存在于您具有读取权限的同一注册表服务器上的另一个存储库中。Docker不传输网络层,而是共享存储库之间的层。

这一变化是在 2.3 registry release 并被称为跨存储库blob装载。