首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >与using脚本相比,使用docker-复合文件版本3的优势?

与using脚本相比,使用docker-复合文件版本3的优势?
EN

Stack Overflow用户
提问于 2017-07-18 19:05:37
回答 1查看 988关注 0票数 6

我创建一个docker的最初原因是为了利用诸如build:depends-on:这样的特性来创建一个文件,该文件构建了所有的映像并在容器中运行。然而,我注意到第3版降低了大多数这些功能,我很好奇为什么我会使用它来构建一个these脚本。

这是当前运行我所有容器的would脚本(如果我使用它,那么这就是版本3的docker文件将替换的内容):

代码语言:javascript
复制
echo "Creating docker network net1"
docker network create net1

echo "Running api as a container with port 5000 exposed on net1"
docker run --name api_cntr --net net1 -d -p 5000:5000 api_img

echo "Running redis service with port 6379 exposed on net1"
docker run --name message_service --net net1 -p 6379:6379 -d redis

echo "Running celery worker on net1"
docker run --name celery_worker1 --net net1 -d celery_worker_img

echo "Running flower HUD on net1 with port 5555 exposed"
docker run --name flower_hud --net net1 -d -p 5555:5555 flower_hud_img

码头群依靠堆叠吗?如果是这样的话,我可以看到一个码头-写作和堆栈的用途,但我似乎找不到答案在网上。我会使用版本3,因为它是兼容的群,不像版本2,如果我所读到的是真的。也许我完全忽略了码头写作的意义,但我对它带给餐桌带来的东西感到有点困惑。

EN

回答 1

Stack Overflow用户

回答已采纳

发布于 2017-07-18 20:28:58

可读性

将示例shell脚本与相同的YAML版本进行比较:

代码语言:javascript
复制
services:
  api_cntr:
    image: api_img
    network: net1
    ports:
      - 5000:5000
  message_service:
    image: redis
    network: net1
    ports:
      - 6379:6379
  celery_worker1:
    image: celery_worker_img
    network: net1
  flower_hud:
    image: flower_hud_img
    network: net1
    ports:
      - 5555:5555    

至少在我看来,通过读取YAML来确定应用程序的总体架构要比读取shell命令容易得多。

清理

如果您使用坞-撰写,那么运行docker-compose down将停止和清理一切,删除网络等。要做到这一点,在您的外壳脚本,您必须分别编写一个删除部分,以停止和删除所有的容器和网络。

多次继承YAML文件

在某些情况下,例如对dev &test,您可能希望有一个主YAML文件,而另一个文件则覆盖dev/test工作的某些值。

例如,我有一个应用程序,其中有docker-compose.ymldocker-compose.dev.yml。第一个包含我的应用程序的所有生产设置。但是"dev“版本有一套更有限的东西。它使用相同的服务名称,但有一些不同之处。

  1. 将代码目录的挂载添加到容器中,覆盖图像中内置的代码的版本。
  2. 向外部公开postgres端口(因此我可以连接到它以进行调试)--这在生产中没有公开。
  3. 使用另一个挂载来伪造用户数据库,这样我就可以轻松地让一些测试用户连接到我真正的身份验证服务器上,仅仅是为了开发。

通常,服务只使用docker-compose.yml (在生产中)。但是当我做开发工作时,我会这样运行它:

代码语言:javascript
复制
docker-compose -f docker-compose.yml -f docker-compose.dev.yml up -d

它将首先从docker-compose.yml加载普通参数,然后读取docker-compose.dev.yml第二,并且只覆盖在dev文件中找到的参数。其他参数都保留在生产版本中。但我不需要两个完全独立的YAML文件,在这两个文件中我可能需要更改相同的参数。

易维护性

我在最后几段中描述的所有内容都可以使用shell脚本来完成。这样做需要做更多的工作,而且可能更难维护,更容易出错。

您可以通过让shell脚本读取一个配置文件来使它更容易.但在某些时候,你必须问你是否只是在重新实现你自己版本的对接-撰写,以及这对你是否值得。

票数 7
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/45175126

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档