Docker - 使用标签影响启动顺序

Docker - using labels to influence the start-up sequence

我的 Django 应用程序使用 Celery 定期处理任务。遗憾的是,这导致有 3 个容器(App、Celery Worker、Celery Beat),每个容器都有自己的启动 shell-脚本而不是 docker 入口点脚本。 所以我的想法是有一个单一的入口点脚本,它能够处理我在 docker-compose.yml 中输入的标签。根据标签,容器应作为 App、Celery Beat 或 Celery Worker 实例启动。 我以前从未做过这样的实现,但我问自己这是否可能,因为我在 trafik loadblancer 项目中看到了类似的东西,例如:

  loadbalancer:
    image: traefik:1.7
    command: --docker
    ports:
      - 80:80
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock 
    networks:
      - frontend
      - backend
    labels:
      - "traefik.frontend.passHostHeader=false"
      - "traefik.docker.network=frontend"
      ...

我没有找到任何好的 material 根据网络上的内容或如何实现这种情况,或者我在这里的想法是否可行。 smb 以前是那样做的吗?还是我应该最好继续使用 3 个 shell 脚本,每个服务一个?

我不确定 traefik 项目是如何使用该实现的。如果他们用的话,应该是完全可以的。

但是,我建议使用环境变量而不是 docker 标签。环境变量是在云原生应用程序中处理配置参数的推荐方式。标签的使用与服务元数据更相关,因此您可以识别和过滤特定服务。在你的场景中,你可以有这样的东西:

version: "3"

services:
  celery-worker:
    image: generic-dev-image:latest
    environment:
      - SERVICE_TYPE=celery-worker
  celery-beat:
    image: generic-dev-image:latest
    environment:
      - SERVICE_TYPE=celery-beat
  app:
    image: generic-dev-image:latest
    environment:
      - SERVICE_TYPE=app

然后您可以在 docker 入口点使用 SERVICE_TYPE 环境变量来启动特定服务。

然而(再次),拥有 3 个不同的 docker 图像并没有错。事实上,这就是容器(和微服务)的理念。您将流程封装在图像中并在容器中实例化它们。它们中的每一个都有不同的目的和生命周期。出于开发目的,您的实施没有任何问题。但在生产中,我会建议将服务分成不同的镜像。否则,您的镜像很大,每个服务只使用了三分之一的功能,并且硬耦合了服务的生命周期。

  1. 您可以从容器内访问标签,但它似乎不像其他选项那样直接,我不推荐它。见 .

  2. 如果您的用例(== 入口点)差异大于相同,则使用三个入口点或三个命令可能更容易。

  3. 如果你们的用例比较相似,那么单纯使用环境变量会更简单明了

  4. 我喜欢使用的另一种不错的选择,它创建一个入口点 shell 脚本,它接受参数 - 所以你有一个入口点,并且参数是使用 command 定义.

标签旨在供 docker 引擎和在主机或 docker-orchestrator 级别而非容器级别工作的其他应用程序使用。