Docker - использование меток для влияния на последовательность запуска - PullRequest
Новая
       62

Docker - использование меток для влияния на последовательность запуска

1 голос
/ 19 апреля 2020

My Django приложение использует Celery для регулярной обработки задач. К сожалению, это приводит к тому, что у каждого из 3 континентов (App, Celery Worker, Celery Beat) есть собственный сценарий запуска оболочки вместо docker сценария точки входа. Поэтому моя идея заключалась в том, чтобы иметь один сценарий точки входа, который мог бы обрабатывать метки, которые я ввел в моем docker -compose.yml. На основании ярлыков контейнер должен начинаться с экземпляра App, Celery Beat или Celery Worker. Я никогда раньше не делал такую ​​реализацию, но спрашивал себя, возможно ли это, так как я видел нечто подобное в проекте trabik 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"
      ...

Я не нашел хорошего материала в соответствии с этим на в Интернете, или о том, как реализовать такой сценарий, или, если возможно, так, как я думаю здесь. Smb сделал это раньше или мне лучше остаться с 3-мя отдельными сценариями оболочки, по одному для каждой службы?

Ответы [ 2 ]

1 голос
/ 19 апреля 2020

  1. Вы можете получить доступ к этикеткам из контейнера, но это не так просто, как другие варианты, и я не рекомендую его. См. этот вопрос StackOverflow .

  2. Если ваши варианты использования (== точки входа) более чем одинаковы, вероятно, проще использовать три точки входа или три команды.

  3. Если ваши варианты использования более похожи, то проще и понятнее просто использовать переменные окружения.

  4. Еще одна хорошая альтернатива, которая мне нравится чтобы использовать его для создания одного сценария оболочки точки входа, который принимает аргументы - поэтому у вас есть одна точка входа, и аргументы предоставляются с использованием определения command.

Метки предназначены для используется ядром docker и другими приложениями, которые работают на уровне хоста или docker -orchestrator, а не на уровне контейнера.

1 голос
/ 19 апреля 2020

Я не уверен, как проект traefik использует эту реализацию. Если они его используют, это вполне возможно.

Однако , я бы рекомендовал использовать переменные окружения вместо docker меток. Переменные среды являются рекомендуемым способом обработки параметров конфигурации в облачном приложении. Использование меток больше связано с метаданными службы, поэтому вы можете идентифицировать и фильтровать определенные c службы. В вашем сценарии вы можете получить что-то вроде этого: 

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

Затем вы можете использовать переменную окружения SERVICE_TYPE в вашей точке входа docker, чтобы запустить указанную службу c.

Однако (снова), нет ничего плохого в том, чтобы иметь 3 разных docker изображения. На самом деле, это идея контейнеров (и микросервисов). Вы инкапсулируете процессы в изображения и создаете их экземпляры в контейнерах. У каждого из них будут разные цели и жизненные циклы. В целях разработки нет ничего плохого в вашей реализации. Но в производстве я бы порекомендовал разделить сервисы на разные изображения. В противном случае у вас есть большие изображения, использующие только треть функциональности в каждом сервисе и жестко связывающие жизненный цикл сервисов.

...