创建docker-compose.yml文件哪个更好 [英] Which is better to create docker-compose.yml file

问题描述

我有两个Web应用程序，它们都是通过域名访问的，nginx作为代理，有两种创建docker-compose.yml文件的方法

I have two web applications, all of them are visited through their domain names, nginx as their proxy, there are two methods to create docker-compose.yml file

1. 仅创建一个带有所有应用程序配置的docker-compose.yml文件，如下所示

webapp1:
  image:nodejs
  command: node app.js
webapp2:
  image:nodejs
  command: node app.js
nginx:
  image:nginx
  ports:
    - "80:80"
  depends_on:
    - webapp1
    - webapp2

1. 创建三个docker-compose.yml文件，如下所示

webapp1

webapp1:
  image:nodejs
  command: node app.js

webapp2

webapp2:
  image:nodejs
  command: node app.js

nginx

nginx:
  image:nginx
  ports:
    - "80:80"

哪种方法更好?我更喜欢第二种方法，因为Web应用程序会经常更改，如果我使用第一种方法，则其他应用程序可能会受到影响，第二种方法将不会出现此问题.

Which method is better? I prefer the second method, because web applications will be changed often, if I use the first method, other applications might be affected, the second method will not have this problem.

如果使用第二种方法，则此处无法使用如何将nginx与webapp1，webapp2，depends_on链接.有什么想法吗?

If I use the second method, how to link nginx with webapp1, webapp2, depends_on can't be used here. Any ideas?

已更新:webapp1和webapp2之间没有关系，我只想在一台服务器上运行它们.

updated: There's no relationship between webapp1 and webapp2, I just want to run them on one server.

推荐答案

您应该更喜欢为应用程序及其所有依赖项编写一个docker-compose.yml文件.

You should prefer to write one docker-compose.yml file for an application and all of its dependencies.

您注意到，最喜欢这样做的最直接原因是您可以一次运行docker-compose up并获取整个应用程序堆栈.使用单独的Compose文件，不仅每个服务都需要运行一次该命令，而且使它们彼此对话的接线非常棘手.

As you note, the most straightforward reason to prefer this is that you can run docker-compose up once and get the entire application stack. With separate Compose files, not only do you need to run that command once per service but the wiring to get them to talk to each other is tricky.

我不会特别担心较大的Compose文件中的部件会影响其他容器堆栈.标准的微服务风格是，不同的服务不应该共享存储，在Docker中，每个服务都可以直接运行数据库，因此每个Compose文件都应该完全独立，并且在一个文件中重新启动(某些)服务应该'不会影响其他任何地方.

I would not especially worry about parts in a larger Compose file affecting other container stacks. Standard microservices style is that different services shouldn't share storage, and in Docker it's straightforward to run a database per service, so every Compose file should be able to be completely self-contained, and restarting (some) services in one file shouldn't affect anything anywhere else.

最后，就更改时重新部署容器而言，您具有以下优点:(a)如果没有任何更改，重新运行docker build很快，而如果您的上游依赖项没有更改，则仍然非常快(例如，您的package.json不变)，并且(b)重新运行docker-compose up -d仅会影响以某种方式更改的容器.如果你举个例子

Finally, as far as redeploying containers on change goes, you have the advantages that (a) re-running docker build is very quick if nothing has changed and still pretty fast if your upstream dependencies haven't changed (e.g., your package.json is unchanged), and (b) re-running docker-compose up -d will only affect containers that change in some way. If you for example

docker-compose up --build -d

不会影响未更改的数据库容器之类的东西，并且如果您未更改某些特定的应用程序组件，它仍将被重建，但最终将显示相同的图像.

that won't affect things like your database containers that are unchanged, and if you haven't changed some particular application component, it will still get rebuilt but you'll wind up with the same image out.

这篇关于创建docker-compose.yml文件哪个更好的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！