在使用Docker时，在docker中的“命令”与进入容器后手动执行命令有什么区别？

Question

docker-Compose.yml启动文件“docker-Compose.yml”如下(省略了一些信息)：

version: '2'
services:
  container_1:
    image: ...
    ports: ...
    command: /worker/bin/init.sh
    volumes: ...
    extra_hosts: ...
    restart: always
    network: ...
    cap_add:
      - SYS_ADMIN
      - SYS_PTRACE

然后使用以下命令启动容器：

docker-compose -f docker-compose.yml up -d

进入容器执行命令的第二种方法实际上是基于docker-组合，因为我需要指定许多端口映射和文件映射，所以开始使用命令行很复杂。我将上述yml文件中的命令修改为(为了保持容器运行)：

command: vim tmpfile

使用相同的方法启动容器，并使用以下方法输入容器：

docker exec -ti container_1 bash

最后，手动执行脚本(/worker/bin/init.sh)。

在使用第一种方法时，我遇到了一个奇怪的问题。执行'init.sh‘脚本后，修改容器中某些文件的权限，并删除这些文件的读取权限()。但是在使用方法2执行相同的脚本之后，没有什么改变。

有没有人遇到过类似的问题？谢谢你的答复。

Answer 1

Docker容器通常只运行一个进程。这是在启动容器时由入口点和命令指定的。该进程在容器中具有进程ID 1，这在几个方面是特殊的。

如果使用docker exec启动调试shell或其他调试命令，则会在容器中创建附加进程。它不是进程ID 1(并且不会继承僵尸进程)。这个调试命令不会通过容器的入口点运行，这偶尔会导致一些不一致(特别是当入口点设置了环境变量时)。

在正常操作中，您不需要“进入容器执行命令”。您所做的任何更改，比如在这里运行init.sh，在启动时都不会被主容器进程看到，并且在容器退出时会丢失。将容器设置为能够初始化自身，可能使用entrypoint包装脚本。

...我需要指定很多端口映射和文件映射..。

这里的一个选择是docker-compose run一个辅助容器。这将从docker-compose.yml文件中获取大部分设置，但忽略ports:并重写command:。例如，在Python/Django应用程序中手动运行数据库迁移的一个好方法是

docker-compose run django \
  python manage.py migrate

其中将拾取组成网络和环境变量的配置，但仍然可以运行在主应用程序旁边。

需要考虑的另一件事是，如果可能的话，只需要减少部署时配置的数量。如果可能的话，将一些文件放到您的Docker映像中；在Dockerfile中设置一个CMD而不是Compose command:；设置一个DNS服务器而不是脆弱的extra_hosts:配置。这样就可以更容易地将图像转换为不同的设置。