多个Docker容器，相同的映像，不同的配置 [英] Multiple Docker containers, same image, different config

问题描述

我是Docker的新手，所以感谢您的耐心等候。

I'm totally new to Docker so I appreciate your patience.

我正在寻找一种方法来部署具有相同映像的多个容器，但是我需要将不同的配置（文件）传递给每个人？

I'm looking for a way to deploy multiple containers with the same image, however I need to pass in a different config (file) to each?

现在，我的理解是，一旦构建了映像，就可以部署它，但是对我来说，问题是我看不到构建多个映像的意义。

Right now, my understanding is that once you build an image, that's what gets deployed, but the problem for me is that I don't see the point in building multiple images of the same application when it's only the config that is different between the containers.

如果这是正常的情况，那么我将不得不处理它，但是如果存在那么请以其他方式使我摆脱痛苦！ ：）

If this is the norm, then I'll have to deal with it however if there's another way then please put me out of my misery! :)

谢谢！

推荐答案

我想看看下面的例子容易理解可以为您提供最好的画面。

I think looking at examples which are easy to understand could give you the best picture.

您要执行的操作是完全有效的，映像应该是您需要运行的任何内容，而无需进行配置。

What you want to do is perfectly valid, an image should be anything you need to run, without the configuration.

要生成配置，您可以：

在容器启动时使用卷并装入文件 docker run -v my.ini：/etc/mysql/my.ini percona （与 docker-compose ）。
请注意，您可以根据需要多次重复此操作，因此可以将几个配置装入您的容器（因此，映像的运行时版本）。
您将在运行容器之前在主机上创建这些配置，并且需要将这些文件与容器一起运送，这是这种方法的缺点（可移植性）

use volumes and mount the file during container start docker run -v my.ini:/etc/mysql/my.ini percona (and similar with docker-compose). Be aware, you can repeat this as often as you like, so mount several configs into your container (so the runtime-version of the image). You will create those configs on the host before running the container and need to ship those files with the container, which is the downside of this approach (portability)

大多数高级docker镜像确实提供了一个复杂的所谓入口点，该入口点消耗了启动时传递的ENV变量图片，为您创建配置，例如 https://github.com/docker-library/percona/blob/master/5.7/docker-entrypoint.sh

Most of the advanced docker images do provide a complex so called entry-point which consumes ENV variables you pass when starting the image, to create the configuration(s) for you, like https://github.com/docker-library/percona/blob/master/5.7/docker-entrypoint.sh

因此在运行此映像时，您可以执行 docker run -e MYSQL_DATABASE = myapp percona ，这将启动percona并为您创建数据库percona。
这全部由

so when you run this image, you can do docker run -e MYSQL_DATABASE=myapp percona and this will start percona and create the database percona for you. This is all done by

1. 在此处添加入口点脚本 https://github.com/docker-library/percona/blob/master/5.7/Dockerfile#L65


2. 不要忘记在映像构建期间复制脚本 https://github.com/docker-library/percona/blob/master/5.7/Dockerfile#L63


3. 然后在映像启动期间，您的ENV变量将导致此事件触发： https ：//github.com/docker-library/percona/blob/master/5.7/docker-entrypoint.sh#L91

1. adding the entry-point script here https://github.com/docker-library/percona/blob/master/5.7/Dockerfile#L65
2. do not forget to copy the script during image build https://github.com/docker-library/percona/blob/master/5.7/Dockerfile#L63
3. Then during the image-startup, your ENV variable will cause this to trigger: https://github.com/docker-library/percona/blob/master/5.7/docker-entrypoint.sh#L91

当然，您可以执行此操作。例如，这将配置一个常规的门户图像： https://github.com/EugenMayer/docker-rancher-extra-catalogs/blob/master/templates/registry-slim/11/docker-compose.yml
具有此入口点 https://github.com/EugenMayer/docker -image-portus / blob / master / build / startup.sh

Of course, you can do whatever you like with this. E.g this configures a general portus image: https://github.com/EugenMayer/docker-rancher-extra-catalogs/blob/master/templates/registry-slim/11/docker-compose.yml which has this entrypoint https://github.com/EugenMayer/docker-image-portus/blob/master/build/startup.sh

因此，您看到的切入点策略非常普遍而且功能强大，

So you see, the entry-point strategy is very common and very powerful and i would suppose to go this route whenever you can.

也许出于完整性考虑，图像衍生策略，因此您有一个名为 myapp的图像，并为安装X创建了一个新图像

Maybe for "completeness", the image-derive strategy, so you have you base image called "myapp" and for the installation X you create a new image

from myapp
COPY my.ini /etc/mysql/my.ini
COPY application.yml /var/app/config/application.yml

并将其命名为myapp：x-显而易见的问题是，最终相比之下，与a）相比，它具有很多图像。

And call this image myapp:x - the obvious issue with this is, you end up having a lot of images, on the other side, compared to a) its much more portable.

希望有帮助

这篇关于多个Docker容器，相同的映像，不同的配置的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！