Блог

Я вижу много вопросов, связанных с настройкой/изменением ИМЕНИ COMPOSE_PROJECT_NAME или ИМЕНИ ПРОЕКТА с использованием переменных ENV.

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

 version: "3.7"
services:
  app:
    build: DockerFile
    container_name: app
    volumes:
      - ./:/var/app
    networks:
      - the-net

  npm:
    image: ${project_name}_app
    volumes:
      - ./:/var/app
    depends_on:
      - app
    entrypoint: [ 'npm' ]
    networks:
     - the-net
 

npm здесь произвольный , надеюсь, тот факт, что он может быть запущен как собственный контейнер или другими способами, не отвлекает от вопросов.

можно ли ссылаться на имя проекта, не задав его вручную или сначала?

К сожалению, это невозможно.

Как указано, вы можете создать .env файл и заполнить его COMPOSE_PROJECT_NAME=my_name , но параметр конфигурации по умолчанию не отображается в вашей среде.

К сожалению, подстановка env в docker-compose довольно ограничена, что означает, что мы не можем использовать доступную PWD переменную env и жадно сопоставлять ее вообще

 $ cd ~
$ pwd
/home/tqid
$ echo "Base Dir: ${PWD##*/}"
Base Dir: tqid
 

Когда мы используем эту ссылку, у compose возникают проблемы:

 $ docker-compose up -d
ERROR: Invalid interpolation format for "image" option in service "demo": "${PWD##*/}"
 

Вероятно, в любом случае лучше быть явным, имя COMPOSE_PROJECT_NAME основано на вашем каталоге, и если кто-то клонирует новую папку, то она выходит из строя, включая .env файл в системе управления версиями, который обеспечит многоразовое и согласованное место для ссылки на имя

https://docs.docker.com/compose/reference/envvars/#compose_project_name

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

Укажите одинаковые build: параметры для обоих контейнеров.

Это кажется неэффективным, поскольку оно дважды вызовет последовательность сборки и docker images перечислит их оба. Однако, как работает кэширование слоев Docker, если одинаковые RUN команды выполняются для одинаковых входных изображений, результирующий слой будет просто использован повторно, и два конечных изображения будут иметь одинаковый идентификатор изображения; они будут буквально одним и тем же изображением с двумя именами.

Контекст, в котором я столкнулся с этим больше всего, связан с приложением на Python, где та же база кода используется для веб-сервера Django или Flask, а также для работника Сельдерея. Однако настройка на уровне докера довольно независима от языка: укажите одно и то же build: для обоих контейнеров и переопределите command: для контейнеров, которым необходимо выполнить задачу, отличную от задачи по умолчанию.

 version: '3.8'
services:
  app:
    build: .
    ports: ['3000:3000']
    environment:
      REDIS_HOST: redis
  worker:
    build: .                 # <-- same as app
    command: npm run worker  # <-- overrides Dockerfile CMD
    environment:
      REDIS_HOST: redis
  redis:
    image: redis
 

Также допустимо указывать build: и image: вместе в docker-compose.yml файле; это указывает имя образа, который будет создан. Часто бывает полезно явно указать это, потому что вам нужно будет указать на определенный концентратор Docker или другое расположение реестра, чтобы запустить созданный образ. Если вы сделаете это, то вы будете знать имя изображения и вам не нужно будет зависеть от имени контекста.

 version: '3.8'
services:
  app:
    build: .
    image: registry.example.com/my/app:${TAG:-latest}
  worker:
    image: registry.example.com/my/app:${TAG:-latest}
    command: npm run worker
 

Вам нужно будет вручную docker-compose build выполнить эту настройку. В рабочем процессе Compose нет способа указать, что сборка одного контейнера должна выполняться до запуска другого контейнера.