是否需要将此相对简单的docker pull and run命令转换为docker-compose.yml文件?

前端之家收集整理的这篇文章主要介绍了是否需要将此相对简单的docker pull and run命令转换为docker-compose.yml文件? 前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

我有三个命令用于通过选择的CI工具(Jenkins)“更新”,“重新运行”,然后“清理”我当前的Docker映像.为了简单起见,我没有包括“容器停止和移除”命令.

docker pull my.private.registry:443/my-awesome-app

docker run -d --env-file ./env.list -i -p 8080:8080 -p 9990:9990 my.private.registry:443/my-awesome-app

docker rmi $(docker images -f "dangling=true" -q)

我是docker-compose的新手,并且我了解大多数这些拉/运步骤可能可以在docker-compose.yml文件中完成.我希望有经验的人可以举一个例子,因为我发现的人似乎与我的需求有所不同.

此外,与列出的方法相比,docker-compose是否会给我一种更好的传递环境变量的方法

env.list是我传递给容器的环境变量的列表.这似乎可行,但是我注意到执行docker检查${CONTAINER_ID}会显示我传入的变量值.我觉得这种做法首先破坏了从配置文件提取值的目的.

最佳答案
首先,如果您简单地将run命令转换为docker-compose.yml文件,则会得到以下内容.例如,我将服务称为my-awesome-app,但您可以根据需要命名. (注意:此docker-compose文件以及下面的另一个文件均为新版本2格式,并且需要docker-engine 1.10和docker-compose 1.6才能运行).

version: '2'
services:
  my-awesome-app:
    image: my.private.registry:443/my-awesome-app
    ports:
      - "8080:8080"
      - "9990:9990"
    env_file:
      - ./env.list

要实现包括停止和删除旧容器但使用docker-compose的命令,您将运行(在工作目录中使用docker-compose.yml文件):

docker-compose pull

docker-compose up -d

docker rmi $(docker images -f "dangling=true" -q)

docker-compose pull-照锡说的做,将docker-compose.yml中的所有图像拉出.

docker-compose up -d-相当于docker run. -d将以分离模式运行(与docker run -d相同).此命令还将停止并删除容器的先前版本,然后再开始新版本.

docker rmi $(docker images -f“ dangling = true” -q)-与以前相同. Docker-compose没有任何清理图像的功能.

环境变量

上面的docker-compose.yml实现了与运行docker run –env-file ./env.list相同的添加环境变量的方法.如果您的环境变量数量很少(例如,大于3),则这是最佳方法.

替代方法涉及将环境变量放置在docker-compose.yml文件中,等效于运行docker run -e KEY1 = value -e KEY2 = value.

version: '2'
services:
  my-awesome-app:
    image: my.private.registry:443/my-awesome-app
    ports:
      - "8080:8080"
      - "9990:9990"
    environment:
      - KEY1=value
      - KEY2=value

最后,env文件解决的问题是拥有大量环境变量,而不必在docker-compose文件中将它们全部列出,也不必在docker run中将它们列出为-e标志.也可以由多个容器使用.无论环境变量来自env文件还是直接列出,它们仍然是容器配置的一部分,因此应该期望它们出现在docker inspect中.

此外,如果您担心其他应用程序会看到此信息,则该应用程序首先必须有权访问docker守护程序(因此它可以调用inspect).如果应用程序有权访问docker守护程序,则它也可以运行docker exec echo $YOUR_ENV_VAR并以任何方式检索它,因此在docker inspect中隐藏环境变量不会增加安全性.

希望能有所帮助.

猜你在找的Docker相关文章