Compose: Определите службы, которые не запускаются по умолчанию

+1 за вариант 1

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

Некоторые из этих проблем (те, которые касаются контейнеров только данных, # 942, последний комментарий от @ cpuguy83) на самом деле уже исправлены в # 1754, я не думаю, что нам нужно больше рассматривать их как проблему (после 1.5 ).

Разрабатываем расширения для Magento. Для этого нам нужен простой способ запустить интернет-магазин на стеке LAMP. Compose упрощает эту задачу. Но мы также хотим запускать phpunit, различные инструменты статического анализа, построители документации и т. Д. На самом деле подавляющее большинство наших «сервисов» - это просто команды, например docker-compose run --rm phplint . В идеале неквалифицированная команда вроде

docker-compose up -d

будет запускать только долго работающую службу (как бы фактические _services_) и не запускать другие эффекты, такие как phpunit, без необходимости. (Также важно, чтобы он не запускал что-то не по порядку, например, запуск тестов Selenium до запуска веб-службы.)

Все, что мы действительно пытаемся сделать, это избавить разработчиков от проблем управления средой, а не запускать производственные службы. Я не знаю, представляет ли комментарий @dnephin направление, в котором движется Compose, или нет, но мне кажется неоднозначным, планирует ли Compose по-прежнему обслуживать ту нишу, в которой начал Fig. (Потому что, чтобы было ясно, я Думаю, что вариант 1 не поддерживает простоту использования, которую разработчики должны использовать, как, по-видимому, предполагал Fig.) Я полностью понимаю, если Compose не хочет иметь несколько обязанностей, но я надеюсь, что кто-то может четко сообщить нам Если те из нас, кто использует этот продукт для быстрой изолированной среды разработки, должны двигаться в другом направлении.

@kojiromike , что именно (1) не подходит для вашего docker-compose run --rm phplint vs. docker-compose --file phplint.yml up )?

Это то, что docker-compose up -d пытается «запустить» phplint, а docker-compose ps сообщает, что «служба» phplint не работает. На самом деле это не сервисный контейнер, а инструментальный контейнер, он не должен иметь понятия «вверх / вниз». Насколько я понимаю, контейнеры инструментов охватываются докером (так можно запускать что-то вроде redis-cli, явно не «службу»), и хотя я больше использую их в разработке, я думаю, что им тоже есть место для производства; например, почему говорят, что awk установлен на производственных машинах или в контейнерах, почему бы не пропустить его через контейнер со связью, чтобы получить предсказуемое поведение.

: +1: Мне постоянно хочется создать контейнер tests вместе с другими моими службами для инкапсуляции выполняемых модульных тестов. Мой «обходной путь» - установить для команды значение «/ bin / true» и запустить контейнер с командой модульного тестирования, указанной в CLI. Было бы здорово указать, какие контейнеры должны начинаться с up time!

(Кстати, хорошая работа, ребята)

cc @jameydeorio

@ryneeverett Семантика - одна из его частей. Это проблема самодокументирования и поиска. В настоящее время мы сообщаем разработчикам docker-compose run --rm foo bar . Мы предлагаем им создать функцию оболочки или псевдоним, но мы не поддерживаем стандартный псевдоним / rcfile для проектов. (Мы не хотим стандартизировать вещи за пределами контейнеров; мы хотим использовать Docker _to_ standardize.) Добавление нового файла для некоторых команд создает иерархию важности: файл docker-compose.yml становится файлом по умолчанию для важных вещи, и «другой» файл становится менее важным.

Другое дело, что просто поддержание отношений между сервисами становится более обременительным. То, что мы хотим, чтобы что-то не запускалось по умолчанию, не означает, что он не использует link или volume из долго работающей службы. extends самом деле не предоставляет всех возможностей, которые нам понадобятся для связывания служб с «командами» (одноразовые службы). Даже если бы это было так, если нам придется использовать несколько файлов yaml, мы будем вынуждены использовать extends там, где в противном случае нам бы не пришлось.

extends на самом деле не предоставляет все возможности, которые нам понадобятся для связывания служб с «командами» (одноразовые службы). Даже если это так, если нам придется использовать несколько файлов yaml, мы будем вынуждены использовать расширения там, где в противном случае нам бы не пришлось.

@kojiromike Вот что я подозревал. Интересно, были бы вы удовлетворены улучшенной поддержкой extends + каким-либо способом выполнения подкоманд (которые были бы функционально идентичны extends ) в пределах одного docker-compose.yml . Но, возможно, последнее совпадает с (4).

2) Добавьте в сервисы опцию, чтобы они не запускались по умолчанию

Я голосую за вариант 2. Например, что-то вроде директивы start: false . Преимущества заключаются в том, что мы избегаем необходимости в нескольких файлах compose.yml или дополнительных файлах конфигурации, вы можете просто прочитать один compose.yml, чтобы почувствовать весь стек приложения.

Я думаю, что наше предлагаемое решение для https://github.com/docker/compose/issues/1987#issuecomment -139632238 справится с этим. Сервисы "admin" могут быть определены в отдельном конфиге и добавлены с помощью -f когда необходимо выполнить команду администратора для композиции.

@dnephin Решение в № 1987 (комментарий) _действует_ обрабатывает "административные службы", но _не__ обрабатывает "только контейнеры данных", верно? Вам все равно придется использовать обходной путь command: /bin/true .

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

@ cpuguy83 В следующем примере контейнер данных на самом деле не нужен, но если я хочу изменить объем, мне нужно только посмотреть на одно обозначенное место.

nginx:
  image: nginx:1.9
  volumes_from:
  - data

php:
  image: php:5.6-fpm
  volumes_from:
  - data

data:
  image: debian:jessie
  volumes:
  - ./:/app

Однако я согласен, что это угловой случай, и добавление дополнительного синтаксиса, вероятно, того не стоит. Я просто говорю, что предлагаемое решение не подходит для этого случая.

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

Я не совсем в курсе нового API томов, который выходит, но я надеюсь, что мы сможем добавить раздел volumes: для составления, который будет лучше обрабатывать объем данных (вместо того, чтобы требовать для них контейнер).

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

Мне кажется, что (2) легче всего понять. На самом деле у меня нет способа подтвердить это, но моя интуиция говорит, что большинство людей, которые не очень хорошо знакомы со всеми вариантами docker-compose , которые сталкиваются с проблемой, которую мы пытаемся решить здесь, говорят: «Хотел бы я каким-то образом заставить этот контейнер _не запускаться_, когда я запускаю docker-compose up », и они видят start: false и бац, мы закончили и счастливы.

Они не говорят: «Если бы я только мог создать второй файл с неудобной историей ссылок, чтобы решить эту проблему ...» (хотя я понимаю, что https://github.com/docker/compose/issues/ 1987 # issuecomment-139632238 помогает с "неудобной связью историй", да?).

Пункт (4) был довольно расплывчатым, но выделенный путь для сценариев и разовых вещей, подобных этому, соответствует этому «разумному» законопроекту.

Сегодня я искал именно (2) но в итоге нашел мое наименее любимое решение - второй файл YML. Мой вариант использования:

У меня есть несколько контейнеров, и все они связаны с одним и тем же контейнером mongo . Я хотел бы предложить себе и своей команде возможность загружать фикстуры в базу данных mongo, и я решил, что самый простой способ сделать это - загрузить контейнер mongo под другим именем fixtures которое Сама ссылка на монго и затем запускаем mongorestore --host mongo --port 27017 --drop /dump . Поскольку мы не хотим загружать фикстуры все время, казалось естественным иметь его с start: false но в итоге получился отдельный файл YML для обоих контейнеров fixtures и mongo .

Работает хорошо, но start: false намного чище IMO. Если бы у меня было 10 или более перестановок этого так называемого контейнера фикстур, тогда да, start: false было бы плохой идеей, и я бы выбрал (1) .

Просто нужно было создать файл компоновки, в котором некоторые службы не должны запускаться с помощью команды docker-compose up -d . Для меня вариант (2) был бы лучшим решением моей проблемы.

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

Привет! Та же проблема здесь, рад, что есть хорошая проблема с группировкой, отличная работа!

В моем случае у меня есть стек Python, работающий с парой контейнеров со службами. Все работает нормально, но вот случай из стека нашел. Я управляю статическими зависимостями с помощью bower и хочу запустить команду bower внутри контейнера, это просто сценарий, который мы запускаем время от времени.

Было бы здорово запустить этот скрипт в имеющейся у нас структуре compose. Я представляю себе что-то вроде:
docker-compose run node bower install

Так что мне нравится вариант 2 из 4. Просто сервис должен не запускаться, он не нужен: P

Если есть какой-то консенсус, я могу попытаться отправить запрос на что-то вроде "перезагрузки".
начало: всегда
возможно ... не знаю.

Еще одно голосование за вариант 2.

Я бы тоже предпочел вариант 2. Новые контейнеры данных Docker можно указать в файле docker-compose, но для использования их не нужно запускать.

Вариант 2 для меня тоже

Вариант 2 был бы отличным.

+1 за вариант 2

+1 за вариант 2. Сохранение нескольких файлов и ввод их имен - пустая трата времени. Один единственный логический флаг будет управлять ими всеми. : пиво:

+1 за вариант 4,
Если мне нужно выбрать второго фаворита, это вариант 2.

Верно, что лучший вариант - 2,4, если я могу +1, то это то, что я делаю, если нет, я иду с большинством и голосую за 2.

Голосование за 2

и 2, и 4 приятно иметь.
+1 для 2

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

// 'task' being a service that manages all my tasks, probably with some custom entrypoint script
docker-compose run task tests

// 'tests' being a service specifically for testing with the default command set to run my tests
docker-compose run tests

Текущее «решение» с отдельным файлом для компоновки, на мой взгляд, не совсем решение. Как сказал @xaka , никто не хочет все это печатать:

docker-compose -f default-file.yml -f additional-tasks-file.yml  run task myTask

В итоге вы получите сценарий ./run-task который добавляет для вас все шаблоны перед myTask . Но теперь вы добавили еще одну точку входа и интерфейс в свое многоконтейнерное приложение. Разработчики видят docker-compose.yml и думают: _ "Отлично, приложение для создания текста. Я знаю, как с этим справиться!" _ И теперь вы должны им сказать: _ "Хорошо, вы можете справиться с этим с помощью docker-compose как и любое другое приложение compose ... о, но подождите ... есть еще этот дополнительный скрипт, который вам нужно знать ... "_

start: false / up: false / some-additional-flag-to-a-service: false , вероятно, самая простая вещь для реализации, но, скорее всего, самая ясная и легкая для понимания. И это значительно улучшило бы удобство использования.

что сказал @sherter . : arrow_up:

: +1: за это. отдельный файл докеров - огромная боль, особенно когда задействованы сети

Подход start: true|false слишком ограничен. Что делать, если одни сервисы используются для тестирования, другие - для администратора, а остальные - для нормальной работы?

Я бы предпочел добавить к услугам понятие группировки.

    myservice:
       group: `admin`

Если атрибут group не определен, предполагается, что default .
Таким образом, мы могли запустить службы по умолчанию и службы администрирования, используя docker-compose up -g admin -d .

А еще лучше сделать groups массивом.

Создание групповых классов сервисов кажется мощной функцией, но также не имеет отношения к этой проблеме.

В docker-compose версии 2 каждый контейнер объявляется внутри элемента services: верхнего уровня.
Объявление службы с start: never для запуска скрипта звучит неправильно.
Итак, учитывая новый формат, не следует ли нам объявить дополнительный элемент верхнего уровня помимо _services_, _volumes_ и _networks_?

Мое предложение:

• добавить новый элемент верхнего уровня scripts: , transients: (или придумайте лучшее имя) в v2.
• внутри переходных процессов вы можете определить контейнер, как и любой другой сервис
• единственное отличие состоит в том, что они не будут запускаться по умолчанию, поскольку предназначены только для временного использования.

Пример:

version: "2"

services:
  web:
    image: myapp
    networks:
      - front
      - back
    volumes:
      - /usr/src/app/
  redis:
    image: redis
    volumes:
      - redis-data:/var/lib/redis
    networks:
      - back

scripts:
  bower:
    image: my_image_with_bower
    volumes_from: web
    working_dir: /usr/src/app/static
    command: "bower"
// maybe would be great to place something like "bower $@"
// to define where you want the cli arguments to be placed, by default at the end.

volumes:
  redis-data:
    driver: flocker

networks:
  front:
    driver: overlay
  back:
    driver: overlay

А потом можно было запустить:

docker-compose script bower <EXTRA_CMD_ARGUMENTS |  default nothing>

docker-compose script bower install

Проблемы:

• Это звучит как OverPowered для создания еще одного элемента верхнего уровня только для этой цели управления запуском, но это происходит из-за того, что новый формат объявляет поведение на верхнем уровне.
• Я пытаюсь представить дополнительную гибкость (и проблемы), которые это может добавить.

Наконец, о _groups feature_ звучит неплохо, но если у вас много группировок, я не вижу проблемы с созданием файлов docker-compose для каждого из них. Вероятно, функция, которая вам нужна, - это наследование файлов в докере , это было бы здорово!

PD: @bfirsh, может быть, если вам нравится идея, вы можете добавить ее в "Возможные предложения"

Во-вторых, это переработка 4- го предложения из-за неизбежного появления нового формата декларирования услуг.

Голосование за вариант 2: самый ясный, легкий для чтения и не требует изучения новых концепций
Просто хочу, чтобы служба не запускалась по умолчанию

А что насчет чего-то вроде disabled: true

@ cpuguy83 Это может означать, что вся служба отключена, даже для run . Меня это сбивает с толку.

@qcho хмм, теперь, когда я заново познакомился с Docker, начиная с версии 1.6, я понимаю, о чем вы говорите с @gittycat . В этом смысле мне очень нравится подход @gittycat . Я представляю (голубое небо) интерфейс вроде:

groups: # if no groups, all services are in the "default" group by…default
    - foo
    - bar
services:
  foo:
    image: imagine
    groups: foo
  bar:
    image: energy
    groups: bar
  baz:
    image: money
    # no groups, so "default"
   quux:
    image: word
    groups:
      - bar
      - default

Между тем в оболочке…

docker-compose up -d # Up all services in default group, so 'baz' and quux
docker-compose up -d --groups foo # Up all services in the foo group
docker-compose up -d --groups foo,default # You get the idea
docker-compose run --rm bar somecommand # We never started 'bar', so it can be a one-off command

Такой подход был бы прекрасен и избавил бы от необходимости в этом билете, но выходит за его рамки.

@kojiromike Я так не думаю. Так системы инициализации относятся к службам, которые не должны запускаться автоматически.

Это тоже просто, и любую «путаницу» можно решить с помощью документации.
Я также нахожу это гораздо менее запутанным, чем эта группировка, которая совершенно не связана с концепцией запуска службы.

@ cpuguy83 Я думаю, что именно семантика "сервисов" сбивает с толку в первую очередь. Я согласен с тем, что группировка - это смещение масштабов. В этом смысле я предпочитаю вариант 4 / подхода @qcho , в котором они четко разграничивают «услуги» от «вещей, которые не являются услугами».

В том-то и дело, почему я должен помещать контейнер, который никогда не будет запускать службу, в категорию «служба ... отключена». Звучит как некрасивая заплатка, которую кто-то сделал, и это не интуитивно понятно.

Возможно, «версия 2» формата должна была учитывать этот вопрос. Например, другая спецификация может быть

version: 3?
containers:
  webserver:
    ...
  database:
    ...
  cache:
    ...
  some_script_container:

services: (they are groups):
  production:
    webserver:
      ...
    database:
      ...
    cache:
      ...
  development:
    webserver:
      ... DEFINE SOME CUSTOM DEV STUFF ABOVE basic container definition
    database:
      ...
    cache:
      ...     

Хорошо, теперь у нас есть подходящие сервисы с определением групп. Я могу начать производство или группу услуг по разработке. Или просто запустите сценарий в some_script_container. поскольку он не определен ни в каких сервисах, никто не будет запускаться

@qcho Зависит от определения службы, но в любом случае - я бы поставил под сомнение то, что должно запускаться только при случае, и только человек может определить, следует ли его запускать или нет.

Допустим, compose принимает что-то вроде объекта job .

1. работа запускается только один раз
2. рабочие места начинаются после обслуживания
3. ожидается выход рабочих мест
4. ???

Теперь compose также необходимо сохранить некоторое локальное состояние работы, чего в настоящее время она не выполняет.

Вот почему добавление простых auto-up: false или autorun: false - самый простой и наименее жуткий (с точки зрения масштабов) способ справиться с этим.

@ cpuguy83 Я думаю, вы расширяете то, что я говорю, чем-то более сложным. Я не собираюсь делать docker-compose, зная о какой-либо работе или рабочем процессе. Для этого могут быть созданы внешние скрипты. Я хочу, чтобы docker-compose определял весь стек для запуска приложения.

Я могу представить, что создаю сценарий и сохраняю то состояние, о котором вы говорите. Даже вызов сценария перед запуском службы, а не сразу после. Чего я не представляю, так это того, что я разбираю файл композитора, потому что мне нужно проверить, какие тома мне нужно импортировать, или какую конфигурацию мне нужно извлечь из него в неизвестном контейнере, чтобы запустить какой-то скрипт, который к нему применим. Я думаю, что docker-compose должен предоставить мне этот контейнер; моя проблема - запуск сценария и сохранение состояния.

Я не понимаю, почему люди продолжают это говорить

services:
  my-script-container:
    auto-up:false

Проще, чем:

scripts/containers/transients/you_name_it:
  my-script-container:

Такой же уровень сложности. Но семантически менее хакерский.

Чтобы получить идеи в одном потоке, ссылка №2803

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

Предложение: мы добавляем возможность поместить int docker-cmpose.overrider.yml, чтобы исключить изображение, определенное в docker.compose.

т.е.

какое-то изображение:
исключить: да

Поведение будет заключаться в игнорировании этой записи в docker-compose.yml

Не могли бы вы сообщить мне, что думает команда, мне было бы интересно внести изменения.

Голосование тоже за №2 ... как раз сегодня столкнулся с этой необходимостью.

Предложение @jimzucker также будет работать, хотя мне нравится мысль о том, чтобы увидеть "start: false" в основном файле .yaml, чтобы сразу понять, что эта «служба» не будет работать, если вы не вызовете ее явно. В противном случае вам (или в моем случае конечному пользователю / разработчику, которому вы передали файлы docker-compose) нужно не забыть искать файл переопределения.

+1 за 2. У меня есть ситуация, когда мне нужно создать образ докера как часть compose, но он не работает как служба. Другие службы (в которых установлен docker sock) время от времени запускают контейнеры из образа.

+1 за 2. И +1 за "автозапуск" или "автозапуск" как формулировка.

И нельзя ли обрабатывать обращения для групп служб (как объяснил @gittycat) с помощью переменных среды, таких как "auto-up: $ {ADMIN}"?

Я также вижу реальные варианты использования, чтобы пометить службы в docker-compose.yml чтобы они не запускались автоматически с помощью простого docker-compose up а вместо этого запускались только явно.

Решение 1) сейчас является одним из возможных способов, но, на мой взгляд, слишком громоздко, так как нужно указать один или несколько файлов yml вместо простого вызова docker-compose up и необходимости разбивать или даже дублировать файлы.

Так как я действительно хотел бы увидеть что-то вроде решения 2) (как и многие другие), я реализовал доказательство концепции в # 3047, поэтому вы можете немного поиграть с ним, чтобы увидеть, может ли оно быть жизнеспособным. решение.

+1 за вариант 2

+1 за вариант 2

+1 за вариант 2

+1 для обоих вариантов 2 и 4

+1 за варианты 2 и 4

+1 для варианта 4. некоторая конфигурация не должна быть разрешена для скриптов (например: перезапуск: всегда)

с вариантом 2 может быть такой странный случай:

service:
  run_tests:
    build: ./tests/
    restart: always
    auto-start: "false"

что бы это значило?

@mathroc : Это означает: «Не запускать этот контейнер автоматически при выполнении compose. Когда этот контейнер останавливается (после явного запуска), перезапускается независимо от кода выхода». Что в этом странного?

@niko, да ладно, я должен подумать об этом немного дольше, прежде чем публиковать ...

изменение моего "голоса" на +1 за вариант 2

+1 за вариант 2, мне это нужно в нескольких проектах.

пингует @bfirsh @dnephin :
Не могли бы вы рассказать об этой проблеме? Поскольку большинство комментариев здесь в пользу варианта 2, есть ли в настоящее время какие-либо планы по реализации чего-то подобного (или варианта 3/4)?
Я мог бы доработать свой пулреквест (№3047) и дополнить его тестами и документацией, если вы тогда подумаете о его объединении.

Спасибо.

+1 за вариант 2

+1 за вариант 2

+1 за вариант 2

Я думаю, что вариант 1 может сработать, но нам нужен лучший способ уменьшить многословность:

docker-compose -f docker-compose.yml -f docker-compose.tests.yml up

Может, могли бы добавить упрощенный / расширенный флаг? docker-compose --augment tests up и автоматически разрешается, если это вариант docker-compose.yml - в противном случае пользователь должен быть явным.

Мне действительно нравится идея нового ключевого слова верхнего уровня, возможно, suites и commands ?

Следующая конфигурация позволит:

docker-compose run -s application
docker-compose run -c cache-clear

suites:
    application:
        services:
            - database
            - memcached
            - application
    tests:
        extends: application
        services:
            - application

commands:
    cache-clear:
        service: application
        workdir: /var/www
        command/entrypoint: php app/console ca:cl

Я вижу в коде, что уже есть понятие "одноразовых" услуг (IMHO используется только при вызове docker-compose run .
Можно ли его использовать повторно?
Если я маркирую контейнер с помощью com.docker.compose.oneoff=True , будет ли он пытаться запустить его?

В противном случае я голосую за вариант 2.

Я только что наткнулся на это, поэтому вот два моих варианта использования:

1. "глобальные" переменные среды: Предлагаемый здесь подход заключается в использовании extends , что меня устраивает ... но теперь мне нужно определить image для того, что я расширяю , и даже не может использовать scratch (так получилось https://hub.docker.com/r/tianon/true/).
2. «масштабирующие» службы: по умолчанию у меня есть один экземпляр MongoDB, но для некоторых тестов я хотел бы определить второй неактивный, который я могу использовать для этих тестов. Здесь использование extends в другом файле выглядит как жизнеспособная идея (все еще изучаю docker / docker-compose и лучшие практики).

+1 за вариант 2

+1 за вариант 2

+1 за вариант 2
Кажется, простое изменение ...

+1 вариант 2,

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

auto-start:true|false

Имея с сентября прошлого года отличное решение под названием rocker-compose , я бы порекомендовал запустить: _always_ | _once_ | _никогда_. Еще мне нравится состояние: _running_ | _ran_ | _created_ тоже.

не являясь поклонником использования отдельного проекта только для этой функции, я в конечном итоге украл команду True asm code из проекта tianon / true, пока это не будет реализовано

Я также изначально думал, что вариант 2 будет лучшим, но теперь я начинаю думать, что он будет слишком ограничительным, и вскоре после его добавления возникнет необходимость в однократных задачах. Фактически, сейчас я работаю над проектом, в котором мне нужны следующие варианты использования:

• внутри стека я хочу иметь возможность определять контейнеры, которые запускаются один раз при первоначальном развертывании, а любые будущие запуски запускаются только извне (например, расписание / событие, через вызов API и т. д.), чтобы они могли инициализировать / обновлять состояние основного контейнера службы в одном стеке (например, данные / схема БД, заполнение томов данных и т. д.)
• внутри стека я хочу иметь возможность определять контейнеры, которые запускаются только извне, чтобы их можно было использовать для инкапсуляции служебных / административных задач (например, проверки состояния / данных и т. д.) и процессов, которые запускаются по расписанию (например, резервное копирование) или по внешним событиям (например, запуск процесса при изменениях в ведре S3)

В моем случае различие между state: created (выполнено 0 раз) и state: ran (выполнено> = 1 раз) важно, поскольку некоторые из служебных / административных задач могут быть деструктивными и должны использоваться только при определенных обстоятельствах, например при переносе служб.

Учитывая, что теперь я больше склоняюсь к state: running | ran | created как в rocker-compose или варианте 4 с _task_ или _job_ object верхнего уровня + возможность выражать зависимость, чтобы служба могла запускать задачу до / после себя .

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

Было бы предпочтительно иметь возможность выполнить что-то вроде:

$ docker-compose --file="docker-compose-testing.yml" up -d --exclude=tests
$ sleep 5
$ docker-compose --file="docker-compose-testing.yml" run --rm tests

Вы можете представить себе что-то более сложное, чем sleep 5 можно написать для проверки того, что инициализация произошла, но это не обязательно для фрагмента примера.

Вариант про флаг cli не читал. Поэтому я предлагаю добавить в список опций флаг --exclude . Флаг --exclude сообщает команде up не запускать указанный контейнер. Флаг --exclude будет проанализирован таким образом, чтобы при необходимости можно было исключить несколько контейнеров из запуска.

: +1:

Взвешивание с другим вариантом использования, где вариант 2 был бы подходящим решением: итерация по новой подслужбе в существующем приложении. Большинству разработчиков в проекте эта новая услуга пока не понадобится, и вы определенно не хотите, чтобы проблемы с ней мешали их работе, но вы также можете не поддерживать ветвь вне дерева в течение длительного периода времени. время.

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

+1 к варианту 2

+1 за вариант 2

+1 за вариант 2

+1 за вариант 2

+1 за вариант 2

@acran Я хотел бы видеть, как вы отправляете свой запрос на перенос, чтобы увидеть, сможем ли мы получить некоторую поддержку в продвижении вперед, может быть, если вы переустановите, чтобы устранить конфликт на # 3047, он будет поднят, не знаю, как привлечь к этому внимание.

@jimzucker well # 3047 уже является запросом на

См. Мой комментарий выше : чтобы сделать PR-слияние, все еще требуется некоторая доработка, то есть обновление связанных документов и тестовых примеров. Но я бы предпочел не заниматься этой работой, не зная, что этот подход будет считаться интегрированным восходящим потоком. Иначе мои усилия по этому поводу могут оказаться бессмысленными ...

+1 вариант 2

@acran , я хотел бы помочь вам обновить соответствующую документацию и тестовые примеры. Это нормально ?

+1 вариант 2

или, может быть, определить вид Job, как в Kubernetes?

+1 за вариант 2

У нас есть docker-compose с несколькими службами, и одна из них (база данных) должна быть запущена в среде разработки, но не в производственной среде. Следовательно, мы должны поддерживать два файла для создания докеров. Вариант 2 - это именно то, что мы ищем!

: +1: для варианта 2

+1 вариант 2

@acran Я обращаюсь к некоторым

👍 за вариант 2

+1 за вариант 2

+1 вариант 2

+1 вариант 2

Также я голосую за вариант 2

Еще одна идея: теперь у нас есть networks верхнего уровня и volumes , мы также можем добавить опцию images . Это будет намеком на Compose, что эти изображения должны быть извлечены или созданы для работы приложения, но они не будут запускаться, когда вы сделаете docker-compose up .

Это сработает для двух вариантов использования, не в моей голове:

1) Общая проблема здесь, когда вы хотите запустить какую-то команду управления. docker-compose run может вернуться к запущенным изображениям, если служба не существует.
2) Подобные приложения, которые запускают образы Docker, но не запускаются постоянно.

/ cc @dnephin @aanand @ shin-

За исключением того, что было бы неплохо иметь возможность настроить все параметры, которые потребуются краткосрочному контейнеру (например, тома / точки монтирования, сети, ссылки, имя и т. Д.) В файле docker-compose, чтобы вы не приходится добавлять их каждый раз, когда вам нужно запустить этот контейнер ...

13 сентября 2016 г., 3:58:41 CDT, Бен Фиршман [email protected] написал:

Другая идея: теперь у нас есть networks верхнего уровня и volumes , мы могли бы
также добавьте параметр images . Это будет намек на то, что эти
изображения должны быть извлечены или созданы для работы приложения, но они
не будет запущен, когда вы сделаете docker-compose up .

Это сработает для двух вариантов использования, не в моей голове:

1) Общая проблема здесь, где нужно какое-то управление
команда для запуска. docker-compose run может вернуться к работающим изображениям
если сервис не существует.
2) Приложения вродеэто, что работает
Образы докеров, но они не работают постоянно.

/ cc @dnephin @aanand @ shin-

Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/docker/compose/issues/1896#issuecomment -246618909

Отправлено с моего устройства Android с помощью K-9 Mail. Прошу прощения за краткость.

Я согласен с @mgriego в этом. Подумайте о контейнере, генерирующем сборку - лучше всего настроить все команды и параметры и просто docker-compose up foo чтобы он выполнял сборку и выходил.

Попытка получить больше понимания здесь: является ли вариант 2) просто частным случаем более общего «нам нужно значение initial_scale в docker-compose.yml »? (см. № 1661, № 2496 и др.)

@ankon совсем нет.

добавить images [раздел]

@bfirsh, это начинает двигаться в том направлении, которое я https://github.com/dnephin/dobi. Я отказался от «секций» (и вместо этого использовал только элементы верхнего уровня для каждого ресурса). Я думаю, что было бы сложно заставить это работать с моделью Compose.

1. networks и volumes самом деле никогда не используются напрямую, они просто создаются по мере необходимости контейнером. Разделение изображений на отдельный раздел не изменит нашего поведения, оно просто усложнит конфигурацию Compose. Если вы хотите просто создать образ, запустите docker-compose build .
2. Я не думаю, что это действительно решает проблемы, указанные в этой проблеме. Людям нужны контейнеры, а не только изображение

Перечитывая ветку и обсуждение в # 2496 об объявлении ограничений масштабирования в файле компоновки, я склоняюсь к тому, чтобы предпочесть вариант 4 (то есть новый раздел верхнего уровня) варианту 2.

В частности, имя раздела, например utilities , будет подходящим: компоненты, которые обычно не нужны, но когда они вам действительно нужны, вы хотите предварительно настроить, с какими другими компонентами они связаны, вместо того, чтобы пусть люди сами построят подходящее заклинание docker run .

Тогда этот подход будет охватывать не только одноразовые команды администратора, но и вспомогательные службы отладки и самоанализа, такие как pgweb и Celery Flower (которые очень удобно запускать в разработке, но обычно вы не хотите использовать их в производственной среде из-за дополнительной безопасности. площадь поверхности угрозы, которую они создают).

Определение семантики этих новых «не сервисов» также становится намного проще: они _ точно_ такие же, как services (включая все будущие изменения этого формата), за единственным исключением, что неквалифицированные команды, такие как docker-compose build , docker-compose pull и docker-compose up их полностью игнорируют - если вы хотите, чтобы какой-либо компонент, указанный в "служебных программах", а не в "службах", обрабатывался, вам необходимо указать его специально (хотя там возможно, это вариант --all , аналогичный текущему для docker-compose rm ). Однако интерфейс командной строки для взаимодействия с этими утилитами по имени будет идентичен интерфейсу командной строки для взаимодействия с обычными сервисами (в отличие от статус-кво, где вам нужно указать дополнительный файл конфигурации утилиты), а docker-compose позаботится о предотвращении конфликтов имен. между определениями службы и полезности.

Хотя предложение по масштабированию в # 2496 потенциально может быть использовано (ab) для получения такого поведения, оно по-прежнему выглядит как обходной путь, а не как должным образом спроектированная функция.

Мне нравится этот дизайн, @ncoghlan.

Вместо utilities как насчет того, чтобы просто назвать его .services ? Это естественно означает, что services и .services используют одну и ту же семантику, с той лишь разницей, что .services не запускаются по умолчанию. Это довольно близкий аналог имен файлов, которые не отображаются по умолчанию. Я полагаю, обратная сторона заключается в том, что разница между ними немного тонка.

Мне нравится основная идея, о которой там говорит @ncoghlan , но ...

1. Не соглашайтесь с тем, что _все_ неквалифицированные команды должны игнорировать эти утилиты по умолчанию. На мой взгляд, все команды должны выполняться нормально, кроме тех, которые приводят к запуску контейнера. (В общем, up и start .)
2. Что касается комментария

@bfirsh @ncoghlan Я полностью согласен с @dnephin :

Я не думаю, что это действительно решает проблемы, указанные в этой проблеме. Людям нужны контейнеры, а не только изображение

Что мне - и я думаю, что большинство людей здесь - нужно для желаемого рабочего процесса, так это простые услуги; они определены как любая обычная служба, они запускаются / останавливаются как обычные службы и т. д.
Отличие _only_ в том, что они не запускаются автоматически простым docker-compose up по умолчанию, а только если они указаны явно (или включены как зависимость).

Поэтому я не вижу необходимости в новом разделе верхнего уровня или совершенно новой концепции для этих одноразовых контейнеров, а только в необязательном параметре конфигурации для каждой службы.
Я реализовал это в моем запросе на перенос № 3047 в качестве доказательства концепции. Это довольно небольшое изменение, но оно полностью удовлетворит мои варианты использования. Так что, если я могу что-то еще сделать, чтобы объединить это, дайте мне знать (=

Для всех, кто хочет это протестировать, вот команды для сборки и запуска docker-compose в контейнере:

# download and build
git clone [email protected]:acran/compose.git -b auto_up
cd compose
docker build -t docker-compose .

# create an example docker-compose.yml
cat > docker-compose.yml <<EOF
version: "2"
services:
  foo:
    image: busybox
    auto_up: false
    command: echo foo
  bar:
    image: busybox
    auto_up: false
    command: echo bar
    depends_on:
      - foo
  baz:
    image: busybox
    command: echo baz
EOF

# start all default services only, i.e. baz
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up

# start service foo only
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up foo

# start service bar, foo is pulled in as a dependeny
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up bar

# clean up all services, i.e. foo, bar and baz
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose down

@acran , я хотел бы помочь вам обновить соответствующую документацию и тестовые примеры. Это нормально ?

@ dattran-vn01 конечно я был бы рад: smiley:

@acran в вашем примере единственная команда, которая имеет поведение, отличное от текущего Compose, - первая, и это поведение может быть выполнено с помощью up baz .
Вы также можете сделать то же самое, используя несколько файлов Compose.

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

@acran в вашем примере единственная команда, которая имеет поведение, отличное от текущего Compose, является первой, и это поведение может быть выполнено с помощью baz.
Вы также можете сделать то же самое, используя несколько файлов Compose.

@dnephin да, точно, я знаю, и в этом примере это будет самый простой способ.
Но представьте себе это с 10 службами и только одной одноразовой службой (например, "init" или "backup" / "dump"): в этом случае вам нужно будет перечислить все службы в командной строке, кроме одной единственной - выключено, например docker-compose up service1 service2 ... service10 (см. ниже). В частности, вам нужно запомнить все службы и вручную отслеживать любые изменения в docker-compose.yml .

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

Вот еще один пример docker-compose.yml для визуализации проблемы:

version: "2"
services:
  init:
    image: busybox
    auto_up: false
    command: echo "I do one-time initializing"
  service1:
    image: busybox
    command: echo "I'm service #1"
  service2:
    image: busybox
    command: echo "I'm service #2"
  service3:
    image: busybox
    command: echo "I'm service #3"
  service4:
    image: busybox
    command: echo "I'm service #4"
  service5:
    image: busybox
    command: echo "I'm service #5"
  service6:
    image: busybox
    command: echo "I'm service #6"
  service7:
    image: busybox
    command: echo "I'm service #7"
  service8:
    image: busybox
    command: echo "I'm service #8"
  service9:
    image: busybox
    command: echo "I'm service #9"
  service10:
    image: busybox
    command: echo "I'm service #10"

Простой docker-compose up _с_ атрибутом auto_up запускает здесь все службы, кроме службы init . Чтобы добиться того же без этого, потребовалось бы ввести гораздо более длинную команду с 10 службами или разделить файл YAML и указать несколько файлов.

Таким образом, запрошенная здесь функция больше связана с удобством и меньшим набором текста на cli, а не с совершенно новой функцией.

Что касается опции «использовать несколько файлов конфигурации» (которая действительно является лучшей из доступных на данный момент), проблема удобства использования заключается в том, что на практике она выглядит так:

$ docker-compose up one-shot-command
ERROR: No such service: one-shot-command
$ docker-compose up -f docker-compose.yml -f docker-compose-utils.yml one-shot-command
# Actually goes & does the requested thing

Несоответствие затем заражает _все_ документацию и автоматизацию вашего проекта: вы должны убедиться, что _два_ файла compose доступны всем, кто хочет запускать служебные команды, вы должны убедиться, что для команд в служебном файле дается полный вызов, и если какая-либо команда или служба когда-либо понижается с «всегда работает» до «запускается только по явному запросу», вам нужно найти любой вызов, который не предоставляет имена файлов конфигурации, и добавить их.

Это все _doable_, это просто раздражает по сравнению с возможностью сказать в файле создания: «Запускайте это только тогда, когда я явно прошу вас, никогда не запускать по умолчанию».

Кто-то однажды сказал мне: _ "Если несколько умных людей не могут решить, какой из подходов лучше, обычно и то, и другое не является плохим. Худшее - это бездействие". _

Эта карта кажется ярким примером этого :)

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

В моей настройке у меня есть службы в docker-compose, которые необходимы для запуска моей инфраструктуры (nginx, база данных, веб-сервер, очереди сообщений ...). Я также определил дополнительные службы, которые мне нужны только для отладки (например, веб-интерфейс базы данных).

Я бы хотел, чтобы службы «отладки» НЕ запускались автоматически, но если я хочу добавить их, я могу сделать это с помощью простого docker-compose up -d database-gui и он просто добавится.

Также: Иногда я передумал и хочу, чтобы одна из этих служб всегда запускалась ... => С вариантом 2) я могу просто изменить этот флаг

=> Проголосуйте за второй вариант, потому что он прост и здесь, кажется, удовлетворяет всем требованиям. Любое другое решение кажется мне излишним ... Добавление сложности конфигурации на основе редких или только предполагаемых вариантов использования, а не практических нужд.

Просто здесь, чтобы добавить свой +1. Я использую приложения Django, и при их запуске в докере было бы неплохо иметь контейнер, который запускал бы оболочку или тесты или, если на то пошло, команды переноса. Но я не хочу запускать что-либо из этого каждый раз при запуске приложения. Хотя использование нескольких файлов конфигурации будет работать, для этого потребуется вводить текст, писать сценарии или использовать псевдонимы в командной строке длиной в милю. Если бы я хотел это сделать, я бы вообще не использовал compose, я бы просто написал сценарий оболочки для моих контейнеров (или сценарий python для них ... возможно, добавил бы объединяющий файл YAML для хранения конфигураций контейнеров ... подождите ...) Я не Я не хочу делать что-нибудь вроде docker-compose -f common.yml -f dev.yml -f local.yml -f commands.yml up migrate только для запуска миграции базы данных в моем контейнере. Альтернативой является использование /bin/true качестве команды и выполнение чего-то вроде docker-compose -f common.yml -f dev.yml -f local.yml up commands 'python3 manage.py migrate' что тоже не очень элегантно. Поэтому мне было бы очень полезно хранить одноразовые команды где-нибудь в конфигурации. Для меня подойдет любой из вариантов 2, 3 и 4.

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

compose предназначен для запуска длительно работающих служб, которые образуют «среду».
dobi ориентирован на последовательную сборку проекта.

То, что вы ищете (запуск оболочки, запуск модульных тестов, запуск миграции), - это все задачи проекта, поэтому они намного лучше подходят для модели dobi.

dobi и compose достаточно хорошо работают вместе, вы можете запустить compose из dobi, используя ресурс compose .

compose=dev-environment:
  files: [docker-compose.yml, local.yml]
  project: 'theprojectname'

который вы можете запустить, используя:

dobi dev-environment

Здесь есть пример интеграции compose и выполнения миграции db: https://github.com/dnephin/dobi/tree/master/examples/init-db-with-rails

Здесь есть примеры многих рабочих процессов (включая выполнение тестов, запуск интерактивной оболочки, выпуск и создание минимальных изображений): http://dnephin.github.io/dobi/examples.html

+1 за 2). С нашей точки зрения, нет необходимости думать и обсуждать необычные варианты использования, такие как одноразовые команды, но мы просто хотим иметь реальные службы, которые созданы и готовы к использованию, но могут запускаться по запросу, когда это необходимо (и по умолчанию не потребляют Ресурсы).

"необычные варианты использования"? вы выполняете миграцию базы данных? вы запускаете модульные тесты? вы запускаете lint? webpack?

Да, я бегаю, но, на мой взгляд, это можно достичь и контролировать внутри контейнеров. Но я не хочу умалять ваше мнение или требования, давайте не будем разгорать эту дискуссию. Наши требования к docker compose не обязательно противоречат друг другу.

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

Называйте их задачами, командами, как угодно, но без этого я просто СОЛНЕЧНО.

Я наткнулся на это в поисках чего-то еще, просто хотел добавить вариант использования ... Мы обнаружили, что наши разработчики наиболее способны определять, какие данные следует резервировать из своих служб. Поскольку файл docker-compose.yml находится в их руках и используются именованные тома, мы решили использовать его для определения стратегий резервного копирования ... Вот обобщенный пример нашего старого docker-compose.yml, который мы использовали.

version: '2'
services:
  gitlab:
    image: gitlab/gitlab-ce:latest
    restart: always
    ports:
      - "5555:5555"
    volumes:
      - gitlab_config:/etc/gitlab
      - gitlab_logs:/var/log/gitlab
      - gitlab_data:/var/opt/gitlab
      - certificates:/etc/gitlab/ssl
      - registry_data:/var/opt/gitlab/gitlab-rails/shared/registry
  gitlab-runner:
    image: gitlab/gitlab-runner:latest
    restart: always
    volumes:
      - certificates:/etc/gitlab-runner/certs
      - /var/run/docker.sock:/var/run/docker.sock
volumes:
    gitlab_config:
      driver: local
    gitlab_logs:
      driver: local
    gitlab_data:
      driver: local
    certificates:
      driver: local
    registry_data:
      driver: local

Чтобы иметь возможность выполнять резервное копирование данных томов, мы решили использовать контейнер busybox для хранения необходимых данных, но он должен быть гибким и выполнять резервное копирование только тех томов, которые разработчики хотят. Наконец, мы должны иметь возможность создавать резервную копию каждого тома отдельно. Для этого мы добавили 3 сервиса ко всем нашему docker-compose.yml.

  boot:
    image: busybox
    depends_on:
      - gitlab
      - gitlab-runner

  backup:
    image: busybox
    volumes:
      - gitlab_config:/data/gitlab_config
      - gitlab_data:/data/gitlab_data
      - registry_data:/data/gitlab_data
      - /backups/latest:/backup
    command: find . -type d -maxdepth 1 -mindepth 1 -exec tar cvf /backup/{}.tar {}  \;
    working_dir: /backup

  restore:
    image: busybox
    volumes:
      - gitlab_config:/data/gitlab_config
      - gitlab_data:/data/gitlab_data
      - registry_data:/data/gitlab_data
      - /backups/latest:/backup
    command: find . -type f -iname "*.tar" -maxdepth 1 -mindepth 1 -exec tar xvf {} \;
    working_dir: /backup

Службы резервного копирования и восстановления просто необходимо настроить с использованием томов, все остальное сделают команды. Мы планируем добавить немного конфигурации, чтобы иметь возможность выбирать, какие тома для резервного копирования или восстановления, но пока мы делаем их все ... Поскольку мы не хотим, чтобы эти 2 службы запускались при каждой сборке докеров up, нам нужно было указать все службы, которые мы хотели, что может быть утомительно ... Итак, мы добавили фиктивную службу под названием boot, все, что она делает, зависит от всех служб, которые необходимо запустить, и мы просто вызываем ее, когда docker-compose up.

Здесь полно небольших хаков, но позволяет нам легко запустить docker-compose up backup чтобы наша резервная копия была сохранена на хосте / backups / latest, и оттуда мы запускаем нашу логику управления версиями / сокращения.

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

В настоящее время в разработке у нас есть 4 файла для создания докеров:

• docker-compose.yml : определяет основные службы, необходимые для полноценной работы нашего приложения, например, redis, MySQL, php-fpm, процессор очереди Laravel, nginx, Solr.
• docker-compose-utils.yml : Определяет служебные службы, необходимые для выполнения задач разработки, например, gulp, npm, artisan (Laravel), composer, redis-cli, обычно запускаются с указанными выше службами.
• Еще 2 файла docker-compose для определения среды и томов для вышеперечисленных сервисов

Эта настройка работает хорошо, поскольку за пределами Docker у нас есть минимальные зависимости для нашей среды разработки. Недостаток - громоздкие командные строки, необходимые для указания всех необходимых файлов .yml для запуска простых утилит.

Мы разрабатываем под macOS, Windows и Linux. Кроме того, многие из наших задач разработки требуют какой-то параметризации (например, создание миграции БД, запуск команды composer / artisan / npm с ее собственными аргументами), поэтому я создал schmich/runx как перекрестную установку с нулевой установкой. платформенный исполнитель задач, чтобы объединить наши общие задачи разработки.

Например, это позволяет нам сказать runx migrate: make create_some_table для эффективного запуска docker-compose -f docker-compose.yml -f docker-compose-utils.yml -f docker-compose-dev.yml -f docker-compose-utils-dev.yml run --rm artisan migrate:make create_some_table или runx npm outdated, чтобы просмотреть наши устаревшие зависимости JS.

Я не использовал упомянутые выше dobi , но runx кажется похожим по духу, хотя и менее приспособленным к среде Docker. В конечном счете, я хочу избежать зависимостей везде, кроме абсолютно необходимых: для самих служб и для служебных скриптов, необходимых при разработке.

Любые новости? Думаю, было бы неплохо иметь эту функцию! Я голосую за решение конфигурации верхнего уровня, например default где мы можем указать, какая служба должна быть запущена.
Фиктивная служба boot хороша, однако я предпочитаю оставить процесс на переднем плане, поэтому, когда я закончу с этой работой, я могу просто закрыть терминал, чтобы все выключилось. Также хорошо, если выходные данные прикреплены по умолчанию, чего не происходит с фиктивной службой.

Поскольку noboby прокомментировал варианты использования с использованием файлов .env, вот мой:

У меня есть 4 файла: docker-compose.yml, docker-compose.local.yml, docker-compose.prod.yml и docker-compose.ci.yml. Для каждой среды у меня разные .env:

CI .env:
COMPOSE_PROJECT_NAME=foo
COMPOSE_FILE=docker-compose.yml:docker-compose.ci.yml
WEB_PORT=8081
...

Test/dev/etc .env:
COMPOSE_PROJECT_NAME=foo
COMPOSE_FILE=docker-compose.yml:docker-compose.local.yml
WEB_PORT=80
...

И так далее...

Пользователям и / или сценариям не нужно беспокоиться о том, какие файлы композиции использовать, поскольку среды уже настроены индивидуально.

Но у меня есть экземпляр обслуживания, который нужно запустить в конечном итоге, его нельзя настроить внутри основного docker-compose.yml, и одним из решений было бы создать docker-compose.worker.yml и выполнить командную строку с 3 параметрами "-f", которые меняются с каждой средой. Этот вариант слишком подвержен ошибкам, чтобы его можно было использовать.

Решение, которое я нашел, заключалось в том, чтобы создать каталог worker, поместить туда yml-файл, связать верхний файл .env с этим каталогом и создать пустые файлы docker-compose. [Ci | local | prod] .yml (в противном случае у меня были бы для изменения значения переменной COMPOSE_FILE).

Это нормально работает, но далеко не оптимально. Любое другое решение от OP сделало бы это без беспорядка.

Я думаю, что обсуждение здесь, множество примеров использования, а также тот факт, что часто возникают повторяющиеся проблемы с этим открытым, ясно показывают, что _is_ реальный спрос со стороны многих пользователей на возможность "Определить службы, которые не запускаются по умолчанию ".

Поэтому я действительно хотел бы перенести обсуждение здесь с _если_ это будет реализовано больше на _как_ это должно быть реализовано. Можем ли мы все с этим согласиться ?

Что касается _how_, этого можно добиться, @bfirsh перечислил некоторые параметры в открывающем комментарии:

1) Рекомендуйте пользователям использовать отдельный файл Compose

Это единственное доступное в настоящее время решение для данного варианта использования. Но, как было сказано выше, в данном случае это скорее обходной путь, поскольку он требует ручного ввода длинных командных строк и запоминания, какие файлы Compose включать для какой команды запускать.
Конечно, при настройке CI или автоматизированном развертывании в производственной среде это не проблема, поскольку командная строка должна быть определена только один раз и никогда не вводиться вручную. Так что это только об удобстве в неавтоматизированных средах, т.е. развитие, которое в соответствии с Докер-Compose вручную одним из основных случаев использования самого Compose:

Вместе эти функции предоставляют разработчикам удобный способ начать работу над проектом. Compose может сократить многостраничное «руководство для разработчиков» до одного машиночитаемого файла Compose и нескольких команд.

Необходимость набирать что-то вроде docker-compose -f docker-compose.yml -f docker-compose-utils.yml run init только для инициализации локальной установки не кажется мне _удобным_, но больше похоже на то, что можно найти в _ многостраничном «руководстве для разработчиков» _.

И рассмотреть вариант 1б) здесь:

Рекомендовать пользователям использовать сценарий / инструмент оболочки для использования отдельных файлов Compose

Если мне нужно использовать дополнительные инструменты и зависимости только для этого, зачем вообще использовать docker-compose ? Поскольку все, что делает docker-compose , теоретически может быть выполнено с помощью специального сценария оболочки и собственного клиента docker напрямую.
Я вижу главное преимущество docker-compose в его стандартизированном пользовательском интерфейсе (я клонирую проект, вижу там docker-compose.yml и знаю, что мне просто нужно запустить docker-compose up чтобы начать) . Всегда нужно знать, какой файл компоновки использовать для чего резко ослабляет это преимущество.

2) Добавьте в сервисы опцию, чтобы они не запускались по умолчанию
3) Добавьте параметр конфигурации верхнего уровня, чтобы определить службы по умолчанию

Эти два параметра делают в основном одно и то же: определяют, какие службы должны (не) запускаться по умолчанию в одном файле композиции , вариант 2) путем внесения отдельных служб в черный список, вариант 3) путем внесения в глобальный белый список набора служб.
Учитывая, что в большинстве случаев в одном файле компоновки больше служб по умолчанию, чем «одноразовых служб», вероятно, проще занести одну службу в черный список, чем занести в белый список все остальные и обновлять белый список каждый раз, когда служба по умолчанию получает добавлено или удалено. Также с вариантом 2), возможно, проще объединить несколько файлов.

4) Добавьте концепцию такой вещи, как служба, но только для разовых команд («скрипты», «задачи» и т. Д.)

Я думаю, что вариант 4) - это просто специализация варианта 2) или 3), поскольку в большинстве приведенных выше примеров желаемые одноразовые контейнеры в основном определены так же, как и любая другая служба, и не делают ничего более или менее похоже на обычные службы, за исключением того, что они по умолчанию не запускаются. (Или я пропустил какое-то существенное отличие от «услуги»).

Так что, на мой взгляд, вариант 2) является лучшим выбором, поскольку он требует наименьших изменений, но в то же время достаточно гибок, чтобы удовлетворить большинство (или все?) Сценариев использования, упомянутых здесь, и быть очень удобным в использовании одновременно.
Тем не менее, я был бы в равной степени счастлив, если бы что-нибудь вроде варианта 3) или 4) было объединено с восходящим потоком. Итак, после более чем года обсуждения здесь, есть ли какие-либо сроки, когда или если это произойдет?

Я согласен, что вариант 2, вероятно, наименее инвазивный. Единственная особенность, которую я вижу в варианте 4, - это возможность запускать команды в существующих контейнерах (с использованием механизма docker exec). Например, если все, что я хочу, - это запустить миграцию базы данных или модульные тесты, возможно, нет причин создавать для нее целый отдельный контейнер, если у меня уже есть контейнер, в котором запущено мое приложение. Тем не менее, контейнеры легкие, и я был бы полностью доволен вариантом 2.

@MadWombat У меня такое же чувство по поводу варианта 4, поэтому я предложил еще одну функцию для этого варианта использования: # 4096. есть совпадение с функцией, описанной здесь, но я считаю, что она может быть полезна сама по себе или в дополнение к этой

@mathroc Я упомянул вариант 4, используя docker exec, поскольку @acran спросил, есть ли какая-либо значительная разница между вариантами 2 и 4. Однако я не могу придумать реальный вариант использования, в котором вы бы специально хотели запустить команду на существующий контейнер, а не поднимать другой аналогичный контейнер для этой цели. Может быть какой-то сценарий с ограниченными постоянными подключениями к некоторой службе или другому ограниченному ресурсу, который уже используется существующими контейнерами, но я не могу придумать ни одного.

Единственная особенность, которую я вижу в варианте 4, - это возможность запускать команды в существующих контейнерах (с использованием механизма docker exec).

Это действительно новый вариант использования, который оправдывает (и требует) введение новой концепции верхнего уровня, отличной от услуг. Но пока команды не нужно запускать через docker exec в уже существующем сервисном контейнере, существующей концепции сервиса должно быть достаточно.

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

Ближайший случай, о котором я могу думать, - это что-то вроде изменения файла конфигурации в контейнере и запуска перезагрузки приложением; используя пример @mathroc из # 4096:

version: "2"
services:
  my_service:
    image: my/service
shortcuts:
  start-debugging:
    service: my_service
    command: echo "debug=true" > /etc/myapp/conf.d/debug.conf && mydaemon --reload-config
  stop-debugging:
    service: my_service
    command: echo "debug=false" > /etc/myapp/conf.d/debug.conf && mydaemon --reload-config

Хотя это связано с этой проблемой, # 4096 имеет свои собственные варианты использования и, возможно, вариант 4) лучше всего переместить туда?

Обсуждение длилось больше года, и мы, кажется, не собираемся принимать какое-либо решение. @bfirsh нужно просто выбрать стиль и следовать ему: smile:

+1

+1, это было бы очень полезной функцией.

И еще +1 для варианта 2 с чем-то вроде auto-start: false или enabled: false .

Мой пример использования - расширение услуг. Невозможно расширить службы, для которых установлено значение depends_on , поэтому я хотел бы определить шаблон службы, а затем расширить из него несколько служб. Очевидно, что шаблон должен быть построен, но не запускаться автоматически.

Я создал собственное решение, получайте бесплатное использование.
Он все еще в бета-версии :)

https://github.com/jonathanborges/picles-docker

Здесь много отличных вариантов. Потребность в этой функции реальна.

Вариант 2 явно более популярен:

1 -> 4
2 -> 52
3 -> 3
4 -> 10

Еще 👍 для варианта 2

Мы можем довольно легко справиться с этим в сервисе «инструменты» с начальной точкой входа или командой, которая просто возвращает. Затем мы запускаем эту службу с альтернативной командой, чтобы делать то, что мы хотим (например, проверять или заполнять данные). Например

docker-compuse up -d
docker-compose run tools tests

Да, сервис инструментов будет отображаться как «остановлен» в docker-compose ps . Если это неприемлемо, то у меня работает многофайловый вариант https://github.com/docker/compose/pull/2051 . например

docker-compose -f docker-compose.yml -f docker-compose-tools.yml up -d
docker-compose -f docker-compose-tools.yml logs -f tools

Хотя похоже, что для этой потребности пишется много помощников по оркестровке, и я виноват, что поработал и над одним :).

Лично я считаю, что существует достаточно обходных путей (таких как два выше; проявить творческий подход к вашим точкам входа / контейнерам и / или использовать многофайловый подход с псевдонимом оболочки / помощником), и составление может быть простым.

@briceburg см. обсуждение выше : проблема здесь не в отсутствующей функциональности, которую нельзя было бы сделать другим способом. Существуют обходные пути почти для всего, чего здесь хотят достичь люди. Но это обходные пути и грязные хаки вместо обычного варианта использования docker-compose.

Речь идет об удобстве, о том, что вам не нужно набирать docker-compose -f docker-compose.yml -f docker-compose-tools.yml up вручную на cli, это о том, что вам не нужно помнить, было ли это docker-compose run tools tests или docker-compose run utils tests или даже нужно полагаться на _многостраничное «руководство для разработчиков» _, но вместо этого имеет единый и простой интерфейс для разработчика.

Опять же , CCing @bfirsh, @dnephin: могли бы вы предоставить _любой_ обратную связь к этому вопросу? Есть ли какая-то надежда, что мы сможем увидеть что-то подобное в ближайшей дорожной карте для docker-compose ??

@briceburg для простой среды, возможно, обходной путь приемлем, но иногда это не так. Посмотрите на мою настройку:

rancher<strong i="7">@rancher</strong>:~/servers/sgi/docker$ ls -l 
total 64
-rwxrwxr-x 1 rancher rancher  303 Dec  8 20:05 cleanup.sh
drwxrwxr-x 3 rancher rancher 4096 Dec 16 15:26 conf
drwxrwxrwx 4 rancher rancher 4096 Dec 15 20:03 data
-rw-rw-r-- 1 rancher rancher   94 Dec 14 19:40 docker-compose.amt.yml
-rw-rw-r-- 1 rancher rancher  295 Dec  8 20:05 docker-compose.auth.yml
-rw-rw-r-- 1 rancher rancher  332 Dec  8 20:05 docker-compose.ci.yml
-rw-rw-r-- 1 rancher rancher  112 Dec  8 20:05 docker-compose.dbext.yml
-rw-rw-r-- 1 rancher rancher  347 Dec 14 19:40 docker-compose.dbint.yml
-rw-rw-r-- 1 rancher rancher  688 Dec 15 16:31 docker-compose.full.yml
-rw-rw-r-- 1 rancher rancher   81 Dec  8 20:05 docker-compose.local.yml
-rw-rw-r-- 1 rancher rancher  288 Dec 15 16:31 docker-compose.yml
-rwxrwxr-x 1 rancher rancher  721 Dec 14 19:40 redeploy.sh
-rwxrwxr-x 1 rancher rancher  861 Dec  8 20:05 setup.sh
-rwxrwxr-x 1 rancher rancher   66 Dec  8 20:05 shutdown.sh
-rwxrwxr-x 1 rancher rancher  269 Dec 14 19:40 startup.sh
drwxrwxr-x 2 rancher rancher 4096 Dec 14 19:40 worker

У меня есть 8 файлов компоновки (которые я использую в нескольких комбинациях) помимо тех, которые находятся в каталоге worker , где я настраиваю контейнеры «не запускать по умолчанию». Каталог worker (с файлом .env, связанным с родительским и некоторыми пустыми файлами compose для соответствия родительской переменной .env COMPOSE_FILE) - это мой обходной путь, но моя жизнь будет намного проще, когда у нас будет решение для Эта проблема.

@vipseixas трудно оценить

В большинстве случаев вам нужно обеспечить прохождение проверок работоспособности зависимых служб / контейнеров перед выполнением тестов - например, jenkins находится в рабочем состоянии и работает (принимает соединения на: 8080 или что-то еще) до выполнения этих тестов. Раньше для этого я использовал dockerize.

Если бы я предложил серебряную пулю, я бы разрешил установить профиль компоновки с помощью переменных среды (например, DOCKER_COMPOSE_PROFILE = "tests") и разрешил бы службам зависеть от профиля - где для всех служб по умолчанию установлено значение "по умолчанию" "профиль или что-то еще. Я также хотел бы убедиться, что службы, которые зависят от другой службы, также _зависимы_ от HEALTHCHECK этой службы. Так что-то вроде

app:
  image: myapp:v1

tests:
  image: myapp:tests
  dependencies:
    - profile: "tests"
    - service: "app"
      healthcheck: true

# run the things
docker-compose up -d

# test the things
DOCKER_COMPOSE_PROFILE="tests" docker-compose up -d
DOCKER_COMPOSE_PROFILE="tests" docker-compose logs -f

+1 за вариант 2.

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

В настоящее время мы предполагаем, что все службы в нашем docker-compose.yml будут запущены на docker-compose up . Мы все работаем с нашими собственными сценариями начальной загрузки, make-файлами, инструментами сборки и т. Д., И, к счастью, как docker-compose, так и docker предоставляют обширный API для управления отдельными контейнерами после того, как кухонная мойка «поднята».

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

Какая самая простая функция, которая «делает это» для всех нас? Это крошечное обновление спецификации docker-compose.yml (исходная идея @bfirsh № 2), в которой служба может указывать autostart: false

Я голосую за: «ПРОСТО СДЕЛАЙТЕ ЧТО-ТО ДЛЯ НАС, СПАСИБО». Голосуем, теперь нужен хотя бы один ответ. 4 БОГ!

Какая самая простая функция, которая «делает это» для всех нас? Это крошечное обновление спецификации docker-compose.yml (исходная идея @bfirsh № 2), в которой служба может указывать autostart: false.

Это лучше, чем любая другая альтернатива :)

Это так просто.
scale: 0
https://github.com/docker/compose/issues/1661

@ drew-r что?

@ jonathanborges1542 Это docker-compose scale servname=2 . В файле docker-compose.yml нет эквивалента.

@ drew-r scale: 0 настоящее время сообщает демону докера отправить SIGTERM / SIGKILL всем контейнерам для службы. Это убьет любую работу по обслуживанию, даже если она еще не завершила свою работу. Это ожидаемое поведение. Изменение этого было бы плохим случаем перегрузки того, что сейчас является очевидным поведением.

@gittycat Я понимаю, но мы хотим здесь набрать "docker-compose up", и все будет готово. Тогда в этом случае это не сработает.

Я слежу за этой темой уже больше года (большинство постов на стороне докеров).
Я считаю, что лучшим вариантом будет создание новых «рабочих мест» на высшем уровне рядом с «услугами», «объемами» и «сетями». Это вариант 4 в списке OP выше.
Это также предложение в репозитории Docker.
https://github.com/docker/docker/issues/23880

@briceburg

по списку файлов сложно оценить работоспособность этого решения

Цель заключалась в том, чтобы показать, что у меня много комбинаций файлов, а использование нескольких параметров "-f" слишком подвержено ошибкам, чтобы их можно было делать вручную.

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

Иногда от гибели никуда не деться. Но я предпочитаю свое решение: я использую другой каталог, который никогда не будет «скомпонован», чтобы не было бесполезных остановленных контейнеров, загрязняющих мою среду. Вот почему у меня есть рабочий каталог с «.env», связанным с родительским «.env».

Если бы я предложил серебряную пулю, я бы разрешил установить профиль компоновки через переменные среды (например, DOCKER_COMPOSE_PROFILE = "tests")

ЭТО было бы лучшим решением. Но не думаю, что разработчики склонны увеличивать сложность ...

Я хочу создать базовый образ, «расширить» его в том же docker-compose.yml и запустить только второй образ, что в данный момент невозможно сделать за один шаг. С вариантом 2 так и будет, но, возможно, лучше и чище будет иметь «этап сборки» и «этап выполнения», на которых выполняется создание базовых образов. На данный момент мне нужно запустить 2 команды, а не одну.

+1 @ drew-r # 1661

Будет ли эта проблема реализована в какой-то момент или это просто то, что разработчики Compose не хотят делать? Было бы неплохо узнать, чтобы сообщество могло начать поиск другого решения.

Кстати голосую за вариант 2.

Спасибо

+1 за вариант 2.
Будет ли он уважать явные зависимости ... links т.д.?

Если я указываю, какую службу вызывать с помощью docker-compose up [service] , я редко хочу запускать какие-либо службы, кроме рассматриваемой службы и ее зависимостей.

Еще одно голосование за вариант 2. Есть даже PR для этого (https://github.com/docker/compose/pull/3047), который @acran был достаточно любезен, чтобы создать, поэтому усилия со стороны разработчиков compose должны быть довольно небольшими, поскольку им нужно только просмотреть его (и это довольно коротко и просто), а не писать код.

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

@msabramo compose в основном ограничен тем, что решено на уровне движка

Запрос отслеживается в репозитории движка докеров https://github.com/docker/docker/issues/23880.
Вот откуда придет решение / работа.

Предлагаю закрыть этот вопрос.

@gittycat compose по-прежнему может иметь возможность указать движку, запускать службу или нет. Это все еще очень актуальный запрос.

Сдаю докер на продакшене, там много проблем. Потом перехожу на бродягу.

Еще один голос за 2)

Еще один голос за 2 и 4.

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

Наличие простой команды для настройки и / или тестирования сделало бы все намного чище.

Еще один голос за 2!

Я прочитал эту ветку, но решил создать новое сообщение (https://github.com/docker/compose/issues/4650), которое было закрыто, и меня направили сюда. Я хотел сказать, что, хотя большая часть обсуждения в этом потоке касается флагов для отключения запущенных контейнеров, мой вариант использования относится к третьему состоянию: создание контейнеров.

Я хотел бы не только предотвратить запуск контейнера, но и иметь возможность никогда не создавать контейнер в первую очередь (в моем случае использования у меня есть управляемый пользователем процесс, который выполняет это)

@ekkis Мне любопытно, как это произошло. Мой пример использования включает обращение к основному образу контейнера и настройку альтернативных «действий», может быть выполнено с помощью чего-то вроде bash, но имеет смысл использовать Docker.

Не могли бы вы подробнее рассказать о своей проблеме?

@frnco , не уверен, что понимаю, о чем вы хотите подробнее. есть случаи, когда вы хотите создать образ без необходимости создания контейнеров. у меня один из таких случаев. Я хочу, чтобы данное изображение было построено вместе с кучей других изображений, но это конкретное изображение будет использоваться в процессе, который я написал. Я не хочу иметь два отдельных процесса для сборки, и наличие флага для build-only могло бы решить эту проблему.

@ekkis Я предлагаю вам взглянуть на # 963, похоже, он связан с тем, что вы ищете.

+1 за вариант 2

+1 за вариант 2

+1 за вариант 2

+1 за вариант 2

+1 за вариант 2

+1 за вариант 2

: +1: для варианта №2 есть вопрос по какой-либо оценке этой функции? Какое решение лучше всего? Насколько я могу себе представить, нужно перечислить все мои услуги, например:

docker-compose up service1 service2 service3

... и опустите те, которые я не хочу запускать по умолчанию

Есть ли способ, которым мы, в сообществе открытого исходного кода, можем помочь внести эту функцию, которая, кажется, очень востребована?

+1 за вариант 2.
Было бы здорово указать «стадию». Скажем, сервис будет работать только в продакшене.

+1 за вариант 2.

Проголосуйте за вариант 2

up фильтрация команд будет идеальной - docker-compose up service1 service3

: +1: для вариантов 2 и 4

На данный момент кажется очевидным, что вариант 2 - это то, что хотят пользователи. Каковы следующие шаги для этого?

Здесь на +1 для варианта 2, столкнулся с этой проблемой, надеясь, что эта функция уже существует.

+1 к варианту 2

... и еще один +1 за вариант 2

+1 за вариант 2

+1 за Вариант 2 :-)

+1 за варианты 2 и 4

Привет всем,
+1 вариант 2

IMHO, опция будет очень полезна в локальных средах, когда у вас есть приложение на основе микросервисов или с гексагональной архитектурой; как разработчик могу запускать только необходимые элементы для ближайшей работы;

Вариант 2 - тот, который нужен большинству пользователей. Решение по этому поводу еще предстоит принять, или разработка уже началась и отслеживается где-то еще?

Я думаю, что когда я закончу университет через пару месяцев и у меня будет больше времени, мне будет намного быстрее реализовать эту функцию самостоятельно (хотя я не изучал Python, на котором, как мне кажется, написано Compose), но я видел, что огромное количество голосов и запросов в течение двух лет, без каких-либо шагов вперед, и самостоятельная реализация, похоже, станет решением на следующие 5 лет (пока эта функция не будет официально реализована).

конечно +1000 за вариант 2

+1 вариант 2

Будет ли разница, если я проголосую за вариант 2? 'кажется маловероятным.

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

Это текущая официальная позиция команды сопровождающих по этому вопросу. Хотя все еще обсуждается, хотим ли мы добавить эту функцию или что-то подобное в качестве удобного варианта, это не является приоритетом по указанным причинам, а также потому, что существуют другие инструменты, которые больше подходят для этого.

@ shin - Прежде чем мы заблокируем это, могу я, чтобы мы получили ясность, если сообщество желает развития, объединит ли основная команда его, если это соответствует стандартам команды? В потоках есть реализация, и участники сообщества, желающие ее завершить, просто искали подтверждения, что это не будет пустой тратой их инвестиций. Если мы сможем получить обратную связь, я буду отслеживать эти потоки, чтобы двигаться, чтобы увидеть, можем ли мы переместить это в закрытие.

@jimzucker Нет - потому что проблема не в реализации; базовая реализация этого займет у среднего разработчика полдня. Здесь нас беспокоит фундаментальная проблема дизайна.

1. Что такое услуга? По задумке сервис - это четко определенный, длительный процесс, который взаимодействует с другими сервисами для формирования приложения. Это основное предположение, в соответствии с которым работает Compose, и оно определяет наш дизайн для большинства, если не для всех функций, которые мы реализуем.
2. Согласно этому определению, «служба, которая не запускается по умолчанию» на самом деле не является службой [1] - это скорее заранее определенная задача, выполняемая в контейнере и действующая на приложение, а не являющаяся его частью .
3. Следовательно, неправильно (в основном по замыслу) называть это службой. На этом этапе нам нужно подумать о создании нового типа определения в вашем файле Compose (я для краткости назову это «задачей», точная терминология здесь не имеет значения).
4. Поскольку задачи по своей сути являются короткопроизводительными процессами, они используют другой набор параметров по сравнению со службами. Например, мы можем интуитивно понять, что задачам не нужно открывать порты [2]. С другой стороны, такой вариант, как CID-файл, который в основном бесполезен для служб, может быть действительно полезен для задач.
5. Теперь в большинстве проектов задачи, как правило, имеют цепочки зависимостей (вот почему в традиционном, неконтейнерном мире у нас есть файлы Makefile), поэтому нам нужно иметь хотя бы базовую реализацию цепочек зависимостей, с параллелизмом и способностью определять если та задача сборки JAR, которая всегда занимает 10 минут, действительно должна запускаться снова.
6. Кроме того, некоторые службы фактически зависят от задач, которые выполняются до того, как они могут быть запущены, что добавляет еще один уровень сложности к тому, как мы вычисляем и обрабатываем зависимости.
7. А для выполнения некоторых задач необходимо, чтобы некоторые службы были запущены (например, миграция базы данных).

На данный момент это стал совершенно новый фрагмент кода, который, вероятно, соответствует или превосходит cmake с точки зрения объема и сложности. Вот почему мы так долго сопротивлялись реализации этого - отчасти потому, что это совсем не то, для чего предназначен Compose, а также потому, что у нас [3] просто нет времени или ресурсов для реализации или поддержки того, что эта функция должен стать действительно полезным для людей.

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

[1] Некоторые люди упоминают о желании иметь «дополнительные услуги», но это не самый распространенный вариант использования, упомянутый в этой теме. Насколько я могу судить, большинству людей нужна функция «задачи».
[2] Я уверен, что кто-то опровергнет меня примером задачи, в которой действительно нужно открывать порты, что только покажет, что определение того, какие опции применимы к каждому набору, нетривиально.
[3] Здесь я имею в виду «Я», поскольку я единственный сопровождающий, активно работающий над docker-compose в настоящее время.

@ shin- я вижу суть. То, что я преследую, - это «дополнительные услуги» в ваших сносках и сценариях использования для этого, а не идея задач, можем ли мы как-то договориться о том, как мы можем продвинуться в этом вопросе, поскольку это была часть темы, которую я пытаюсь поддерживать и мои билеты явно на этом пути были закрыты в пользу этой ветки. Если мы сможем отделить это от пунктов, которые вы четко определили как «задачи», мы сможем добиться некоторого прогресса. Когда люди делают +1 для варианта 2 в моем чтении, это касается дополнительной услуги. Мы рады обсудить это в автономном режиме, а затем мы сможем вернуться на форум, я нахожусь по адресу

@ shin- ваш пункт №2 неверен. служба - это служба, независимо от того, запущена ли она. существует бесчисленное количество случаев использования, когда зависимые службы изменяют поведение, когда зависимость недоступна, поэтому уровень вашего приложения не может, не должен требовать, чтобы все "службы" были доступны в любое время.

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

Я думаю, что многие люди, которые запрашивают эту функцию, хотят запускать не задачи, а дополнительные услуги. Например, если у вас есть набор микросервисов, работающих как контейнеры Docker, и вы развертываете их все как единую службу, возможно, однажды ваши требования изменятся, и вам не нужно будет запускать все контейнеры на всех ваших серверах, потому что в этом случае вы не требуются определенные функции, включенные в необязательный контейнер.

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

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

@ekkis Я думаю, вы несколько

Всем: имейте в виду, что если некоторые службы являются необязательными для вашего приложения, это уже можно решить с помощью текущих функций. Рекомендуемый способ сделать это - создать отдельный файл Compose, который можно включить или исключить с помощью флага -f . Это не очень веские аргументы в пользу добавления этой опции.

@ shin: Я ценю, что вы нашли время поговорить с нами. Я согласен, что есть несколько способов сделать это, поскольку вы предлагаете несколько файлов yml, вы также можете передать список служб, но это неудобно и приводит к ошибке пользователя, создающей операционный риск. В частности, в случае коммерческого продукта мы хотим распространить один файл компоновки и по умолчанию получить желаемое общее поведение и дать инструкции для расширенных параметров, один файл делает все это намного проще как для разработки, так и для CI / CD и распространения. Добавление переменных ENV со значениями по умолчанию оказало нам огромную помощь и устранило необходимость иметь много файлов yml, это будет еще один шаг к управлению одним файлом, описывающим развертывание.

Есть ли какая-либо форма, в которой основная команда будет готова принять участие в этом LMK?

@shin , ни на отказоустойчивость, ни на отказоустойчивость я не сослался. Я просто указал на определение «службы», а именно, что то, запускается служба или нет, не является неотъемлемой частью определения.

@ shin - Я полностью согласен с @ekkis : запуска _по умолчанию_ не нарушает определение службы, поэтому ваш пункт 2. является предположением, которое _обязательно_ не верно, как и последующие пункты, поскольку они основаны на предположение 2.

Например: когда я разрабатываю приложение с использованием базы данных mysql, я обычно определяю дополнительный _service_ phpmyadmin . Это настоящая служба: долго работающие открытые порты, зависящие от других служб.
Но я не хочу запускать эту службу _по умолчанию_, а только _по запросу_ / в разработке.
В настоящее время я понимаю это, помещая эту службу в дополнительный docker-compose.yml и запустив ее, предоставив оба файла docker-compose - как вы предложили выше.

Итак, да, уже есть возможные способы добиться этого; будь то разделение служб на несколько файлов или просто использование инструмента, отличного от docker-compose . Но как я уже писал выше : этот вопрос касается не полностью новой функции / функциональности или новой концепции (т.е. _tasks_), а удобства , особенно в средах разработки .
Набирать docker-compose -f docker-compose.yml -f docker-compose-tools.yml up совсем не удобно, поэтому docker-compose не выполняет свои собственные обещания :

Вместе эти функции обеспечивают удобный способ для разработчиков , чтобы начать работу над проектом. Compose может сократить многостраничное «руководство для одного машиночитаемого файла Compose и нескольких команд.

Какие службы запускать или какие yml файлы использовать в какой среде - это то, что обычно можно найти в _multi-page «руководстве для разработчиков по началу работы [s]» _ - если вообще можно найти ...

Так что, по моему мнению и как написал @jimzucker, большинство +1 здесь действительно для «дополнительных услуг», а не для новой концепции задач. По крайней мере, всем им лучше использовать простое логическое значение, чтобы пометить _service_, запускаться ли по умолчанию или нет.

Как показывает мой PoC, необходимое изменение кода - для «дополнительных услуг» - вполне управляемо и обеспечивает для большинства людей огромное удобство. Вариант 2 - читаемый как «_возможность пометить услугу как необязательную_» - разумный компромисс для решения этой проблемы.

@ shin - согласны ли вы с тем, что предоставление пользователям возможности отмечать услуги как необязательные - но они все еще являются услугами - им очень поможет?
При уменьшении до «маркировки _services_ как необязательных / не запущенных по умолчанию» будет ли принята и объединена эта проблема / запрос на перенос для этого?

@shin , чтобы добавить к пункту @acran выше, я могу захотеть, чтобы docker-compose строил только определенные службы, потому что эти службы будут запускаться другими службами с использованием имен . учтите, что каждый раз, когда я "поднимаюсь", я получаю кучу "сервисов" с именами project_app_1 , project_otherapp_1 и т. д., они не имеют смысла, поскольку их нужно запускать с использованием информации из базы данных (у меня есть мастер-сервис, который их запускает) . так что мне всегда приходится убивать их. поэтому для меня флаг NO_RUN или BUILD_ONLY имеет смысл. это было бы удобно

@acran

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

Я не согласен с тем, насколько это могло бы помочь - я думаю, что «сильно» переоценено. В вашем примере просто наличие docker-compose.phpmyadmin.yml которое может быть дополнительно включено, не является более обременительным или сложным (с точки зрения инструкций «руководств разработчика»), чем установка переменной среды / изменение определения службы внутри основного файла.
Я также подумываю о том, чтобы дать разработчикам «ножки», когда это не является строго необходимым.

При сокращении до «маркировки служб как необязательных / не запущенных по умолчанию» будет ли принята и объединена эта проблема / запрос на перенос для этого?

См. Выше - как только эта функция станет доступной, люди начнут использовать ее не по прямому назначению и ожидают, что мы внедрим новый набор функций для ее поддержки. Также cc @jimzucker ; В настоящее время я не могу придумать реализацию, которая предотвратила бы развертывание этого сценария. Если бы я мог, этот вопрос давно бы закрыли.

@ekkis Если вы никогда не хотите запускать эти службы самостоятельно, почему это проблема, когда они изолированы в отдельном файле? Я действительно сбит с толку, почему это здесь такая проблема.

@shin, если docker-compose.yml можно использовать для создания службы, это наиболее полезный инструмент для централизации моего процесса сборки. на самом деле имеет смысл, что я могу (условно) создать службу перед ее запуском, и я приветствую эту функциональность

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

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

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

@ shin-

В вашем примере просто наличие docker-compose.phpmyadmin.yml, которое можно дополнительно включить, не более обременительно или сложно (с точки зрения инструкций «руководств разработчика»), чем установка переменной среды / изменение определения службы внутри основного файла.

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

• Копирую / клонирую новый проект
• Я вижу, что в нем есть (единственный) файл docker-compose.yml , поэтому я знаю, что все, что мне нужно сделать, это запустить docker-compose up и приложение будет создано и запущено
• Теперь я хочу запустить одну из дополнительных служб для целей разработки (например, дополнительную отладку, phpMyAdmin). Все, что мне нужно сделать, это docker-compose up phpmyadmin .

Для меня это намного удобнее, чем использование нескольких файлов docker-compose.yml , и, как я понимаю, для большинства других людей здесь тоже. Преимущество наличия "дополнительных услуг" здесь:

• для разработчика, который не должен дублировать что-либо между несколькими файлами или должен тщательно продумывать, какие определения помещать в какой файл, а должен только установить один логический флаг ( auto_up: false ) для службы
• для пользователя, которому не нужно знать / запоминать, какие файлы включать для каких служб: нужно ли мне запускать
  
  
  
  • docker-compose -f docker-compose.phpmyadmin.yml up
  
  
  • docker-compose -f docker-compose.yml -f docker-compose.phpmyadmin.yml up или даже
  
  
  • docker-compose -f docker-compose.phpmyadmin.yml -f docker-compose.yml up ?
  
  
• вместо этого единственное, что пользователю нужно _ знать_, это то, что существует служба с именем phpmyadmin и пользователь сразу знает, как ее запустить.

См. Выше - как только эта функция станет доступной, люди начнут использовать ее не по прямому назначению и ожидают, что мы внедрим новый набор функций для ее поддержки.

Не поймите меня неправильно, я не только понимаю вашу озабоченность, но и согласен с ней: всегда найдутся пользователи, которые изменят эту - или любую другую (!) - функцию в соответствии со своими желаемыми рабочими процессами, даже если эти функции никогда не предназначались для использовал вот так.
НО для любого запроса на «необязательные услуги», отсутствующие в «задачах», вы можете _тогда_ легко утверждать, что услуги не являются задачами, и что задачи необходимо сначала представить как новую концепцию, и поэтому они не поддерживаются (пока). Т.е. что-либо большее, чем просто отметка услуги как необязательной, является шагом к концепции задач (например, вариант 4), и между ними существует четкое разделение.

С функцией пометки _service_ как необязательной, мы все еще на правильной стороне этого сокращения. «Эта функция сама по себе не слишком сложна для реализации, но она _might_ соблазняет пользователей использовать ее неправильно», что в настоящее время является единственным реальным (хотя и действительным!) Аргументом против этой функции, является совершенно неудовлетворительным как причина не реализовывать ее - по крайней мере, для пользователей, которые могли получить от него много удобства, используя его правильно ™.

Я собираюсь перенастроить свой пулреквест № 3047 на текущий мастер и провести необходимую полировку, чтобы это было принято, просто дайте мне знать;)

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

Я был бы склонен использовать вилку docker-compose которая реализует эту функцию только для этой единственной функции.

@ shin- Хотя я думаю, что все мы понимаем вашу точку зрения и сочувствуем ей, я не думаю, что фраза «это может быть неправильно использована» - хороший аргумент в пользу чего-то - очевидно - с множеством жизнеспособных вариантов использования. Конечно, ею будут злоупотреблять. Именно так растут программное обеспечение и новые идеи; из использования техники не совсем так, как должно быть. Интернет не был бы тем, чем он является сегодня, если бы мы не злоупотребляли всеми предоставленными технологиями в течение последних 25 лет.

Так или иначе.
По вашему - упрощенно - разница между услугой и задачей - это время жизни. Это имеет смысл, и я понимаю, что вы рассматриваете их как две разные концепции и чувствуете, что это потенциальная банка червей. Но это различие нигде не разъясняется и не разъясняется в документации. Также нигде не указано, что докер не предназначен для использования для ускорения временных процессов.
Я хочу сказать, что если у команды докеров есть твердая позиция по этому поводу, это следует прояснить с самого начала.
Также. Задача или услуга явно пересекаются. И маркировка услуги как необязательной определенно не относится исключительно к задаче.
С практической точки зрения я определенно согласен с @acran - наличие одного файла для создания

Хехе, я помню дискуссии яростные мы имели , когда мы лоббировали за то, что «браузеры» для отображения изображений, с главным аргументом противников в том , что это называется протокол передачи гипер текста.
Простите за Ветхие воспоминания о старом пердеже.

@ shin - если docker-compose не следует использовать в качестве make-файла, он не должен обеспечивать функциональность make-файла. если это позволяет мне создавать мои проекты (браво!), то принимать позицию, что это не make-файл, смешно

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

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

Я понимаю, что официальная позиция заключается в том, что мы должны использовать dobi, даже если это чрезмерно для того, что нам нужно. но эта официальная позиция не объясняет причины вашего нежелания принимать полезный пиар. мы все еще можем использовать dobi, когда потребность в docker-compose слишком велика или перекрытие достаточно для миграции, но это очень небольшое изменение, которое сделает всю нашу жизнь намного лучше

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

@rysiekpl Это проблема, которую мы ищем для решения другим способом, см. https://github.com/docker/cli/pull/452 (после обсуждения синтаксиса он попадет в Compose и v2 как хорошо)

@creynders Я думаю, что это немного <img> и должен ли наш конкретный браузер поддерживать его или нет.

Также, к вашему сведению:

Но это различие нигде не разъясняется и не разъясняется в документации. Также нигде не указано, что докер не предназначен для использования для ускорения временных процессов.

На самом деле это первый абзац страницы https://docs.docker.com/compose/overview/ (выделено мной):

Compose - это инструмент для определения и запуска многоконтейнерных приложений Docker. В Compose вы используете файл Compose для настройки служб вашего приложения. Затем с помощью одной команды вы создаете и запускаете все службы из своей конфигурации.

@ekkis Я очень рад, что Compose действительно помогает вашим проектам! Надеюсь, я не выгляжу неискренним во всем этом, это абсолютно нормально, если вы хотите использовать программу именно так. Однако я говорю о том, что дальнейшее продвижение в этом направлении, вероятно, ухудшит ситуацию в долгосрочной перспективе. Все мы знаем, что происходит с приложениями, которые пытаются делать слишком много вещей (хотя я полагаю, что Emacs справился с этим: stuck_out_tongue :)

Не думаю, что я был «авторитарным», но, возможно, я не выразил себя должным образом. Мое намерение состояло в том, чтобы побудить людей оставаться вежливыми и позитивными во взаимоотношениях. Цепочка по-прежнему разблокирована и будет существовать до тех пор, пока люди будут воздерживаться от злых или невежливых действий.

вы создаете и запускаете все службы из своей конфигурации.

и я предполагаю, что мы утверждаем, что следовало читать «создать и / или запустить», хотя, чтобы быть справедливым по отношению к языку, не нужно указывать ИЛИ, потому что это неявно в И. другими словами, это правда, что вы можете как создать, так и запустить службу, но это не означает, что она должна делать и то, и другое.

Все мы знаем, что происходит с приложениями, которые пытаются делать слишком много вещей.

да, я понимаю, что вы управляете границами домена

Я не думаю, что был "авторитарным"

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

в качестве прощальной мысли я бы попросил вас пересмотреть https://github.com/docker/compose/issues/4650, который не совпадает с запросом в этом потоке (как вы указали при его закрытии), но учитывает мое использование случай, а именно, что обсуждаемый здесь флаг не двоичный, а троичный

Мне очень нравится идея определения нескольких файлов. Однако включение всех файлов с несколькими -f включая оригинал, кажется полным излишеством.

На самом деле есть более практичный способ, который работает для меня (см. PS ниже): поместите все службы, которые вы не хотите запускать, в docker-compose.override.yml . И используйте docker compose -f docker-compose.yml up для обычного запуска (обратите внимание, что это одноразовая команда). Для всех последовательных вызовов переопределение будет происходить ...

В целом это все очень неинтуитивно и немного неудовлетворительно. Добавление дополнительных:

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

• Параметр -f минимален, но не очень интуитивно понятен, другой вариант -F <name> который просто добавляет дополнительные переопределения, был бы очень приятным (например, docker-compose..yml. Альтернативой было бы использованиекак каталог, в котором находятся все файлы .yml : вместе с символическими ссылками это будет так же мощно, как /etc/apache/sites.available -> /etc/apache/sites.enabled

С другой стороны: любой может предоставить простой сценарий (функцию) оболочки для своей оболочки, чтобы имитировать это поведение ...

PS: мой вариант использования заключается в том, что я определяю отладчик как службу. Очевидно, что эта услуга не нужна постоянно, но для правильной работы требуются ссылки (в том числе по соображениям безопасности).

Еще один вариант использования, для которого отлично подходит вариант 2:

Допустим, у вас есть команда людей, работающих над одним проектом. Некоторые из них имеют доступ к управляемым сервисам AWS, но некоторым из них необходимо запускать соответствующие ресурсы как локальные контейнеры. Поэтому, в зависимости от моего рабочего процесса, мне либо _ всегда_, или _ никогда_ не понадобятся контейнеры Redis и MySQL в моем созвездии компоновки.

Я собираюсь прямо заявить, что управление несколькими композитными файлами глупо для этого варианта использования. Количество совпадений комично. Хранение нескольких файлов - это легкая задача - они _выбнут_ из синхронизации и вызовут путаницу. Я, честно говоря, немного шокирован тем, что кто-то серьезно отнеслись к этому варианту в _ любом_ сценарии использования.

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

Полностью согласен с @campadrenalin.

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

ОТ:

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

Эта функция давно не доступна? См. Https://docs.docker.com/compose/compose-file/#variable -substitution. Я использую его , чтобы настраивать нашу Compose среды разработки с помощью .env файла - например , расположение исходного кода, порт отображения и т.д. Поскольку Compose файла версия 2.1 даже переменная оболочки стиля по умолчанию ( ${VARIABLE:-default} / ${VARIABLE-default ) поддерживается.

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

Я нахожу это - может быть, немного резким по тону, но действительным по сути - очень хорошее резюме от @rysiekpl.
Итак, @ shin-, мы приблизились к решению по этому вопросу? Просто закрыть его или реализовать / принять PR для варианта 2?

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

Поскольку docker-compose в любом случае, похоже, будет отброшен в пользу docker stack, я предлагаю всем как можно скорее перейти на новый формат v3 и инструмент docker stack .

Используя стек на рое (даже на 1 узле), вы можете указать это:

        deploy:
            mode: replicated
            replicas: 0

Отсутствие реплик по существу отключает работу службы.

Вам просто понадобится какой-то другой инструмент для создания этого yml, если вы хотите применить подстановки переменных среды, например envsubst.

Затем вы можете использовать заполнитель в своем yml:

        deploy:
            mode: replicated
            replicas: ${R}

И обработайте это так:

export R=0
docker stack deploy stack1 --compose-file=<(envsubst <docker-compose.yml) 

Итак, если docker-compose будет устаревшим в долгосрочной перспективе, в чем именно проблема с объединением уже существующего запроса на перенос ? Я имею в виду, если docker-compose идет по пути дронта, почему «кто-то будет запрашивать странные функции» настоящая проблема?

Поскольку docker-compose в долгосрочной перспективе кажется отброшенным в пользу docker stack

Итак, если docker-compose будет устаревшим в долгосрочной перспективе

подожди, ват? docker-compose является центральным для многих людей в процессе разработки, которому вряд ли нужен менеджер роя. Не могли бы вы указать мне на какое-нибудь официальное заявление Докера по этому поводу?

Возможно, я ошибаюсь, но похоже, что рой докеров и стек докеров тесно связаны с облачными сервисами докеров. Можно ли настроить эти вещи в автономной автономной системе?

Можно ли настроить эти вещи в автономной автономной системе?

да, вы можете использовать их в автономном режиме.

Мне кажется, что стеки в docker-swarm в конечном итоге станут надмножеством функций docker-compose. Я думаю, что файлы дескрипторов уже очень похожи. Надеюсь, этот переход не будет слишком сложным. Самое большое раздражение, которое я вижу, - это управление роем отдельно от стека (ов). Для меня больше накладных расходов, поскольку я не заинтересован в запуске составленных приложений более чем на одном узле.

А может я все неправильно понимаю ...?

+1 к варианту 2!
И я думаю, что отказ от docker compose в пользу swarm stack будет большим недостатком для сообщества. Docker compose настолько прост и удобен в использовании !!

@tberne Я согласен с этим. docker-compose прост и прост - это хорошо. мы должны проголосовать, чтобы сохранить это

Хех, какая обширная дискуссия! Не обращай особого внимания на этот комментарий, только мои два цента.

Сначала я согласился с большинством просто добавить своего рода флаг enabled .
Затем я увидел предложение об определении ветвей по группам и посчитал это хорошей идеей.
Затем я прочитал о Dobi, попробовал его, убедился, что его нельзя использовать в моем проекте прямо сейчас, и продолжил чтение.
Затем я прочитал аргументы @ shin- и счел их достаточно хорошими, хотя я также согласился с некоторыми контраргументами.

Мое текущее решение - создать несколько yamls для docker-compose и написать несколько сценариев обертывания bash, чтобы не запускать docker-compose вручную.

Например, вот как я запускаю контейнеры, которые запускают веб-сайт ( ./docker/scripts/up script):

#!/usr/bin/env bash

def_opts="-d"

cd "$(dirname "$0")"/../

# A separate bash file with functions like: get_args, add_hosts...
. ./functions.sh

docker-compose -p ${PROJECT} up ${def_opts} $(get_args "options services" "$@") && \

# Adding host to /etc/hosts
add_hosts "$HOSTS" web && \
add_hosts "$HOSTS_MAIL" mail

Большой +1 к варианту 2 или 3.

+1 за Вариант 2 или 3.

Интересно звучит и предлагаемая «групповая» концепция!

+1 за вариант 2

_Существует так много +1 on option x , что я даже не могу найти исходное утверждение. Вместо этого используйте кнопки реакции под сообщениями. _

Чтобы добавить новую идею:

Разве мы не можем просто установить масштаб по 0 ?

web:
  image: busybox:latest
  command: echo 'scaled'
  scale: 0

Вы должны просто выполнить вариант 2 (но, возможно, вместо этого nostart или что-то в этом роде), потому что люди ждали уже много лет, а затем обертывали docker-compose своими собственными менеджерами конфигурации, потому что инструмент слишком ограничен, что побеждает точку, поскольку он делает то, что docker compose должен делать. Через два года кто-то мог бы создать и свой собственный, более мощный docker-compose. Этот выпуск открыт уже давно.

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

+1 за вариант 2 или 4

Если в настоящее время нет никаких планов по добавлению этой функции, я хочу, чтобы способ запуска таких служб (или задач) в композиции был написан в документации docker-compose.

Это старый поток, и я согласен, что docker-compose не будет заботиться о _services, которые не будут запускаться с start_.

Но я также обычно добавляю сервис test , поэтому вот что я сделал:

1. Заменить entrypoint службы.

2. В новом entrypoint проверьте, доступен ли tty ( docker-compose run --tty по умолчанию использует up - нет).

   # Check if there is a tty
   if [ ! -t 1 ] ; then
     echo "No tty available."
     exit 0
   fi
   

   Это всегда будет приводить к завершению работы службы при запуске без tty (например, с docker-compose up ), в то время как все еще выполняется, как ожидалось, с docker-compose run

@paulodiovani Это больше похоже на взлом, чем на решение.

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

Я решил эту проблему в своем проекте, предоставив простой сценарий bash, который вызывает соответствующую команду docker-compose на основе предоставленных аргументов.

Теперь, если я сделаю ./docker-compose.sh -e testing up , результат будет таким же, как если бы я сделал docker-compose -f docker-compose.yml -f docker-compose.testing.yml up .
Если я просто сделаю ./docker-compose.sh up , я получу, как и следовало ожидать, обычные docker-compose up .

Следовательно, мой вариант -e ${environment} (сокращение от --env ) в основном является псевдонимом -f docker-compose.yml -f docker.compose.${environment}.yml . Это приводит к тому, что docker-compose.yml является базовым / стандартным файлом компоновки, а такие файлы, как docker-compose.testing.yml являются его расширениями.

Это в некоторой степени решает проблему @acran, когда пользователь не знает, какие файлы включить (и в каком порядке) в команду docker-compose путем применения разумных значений по умолчанию. Это не очень надежное решение, поскольку некоторые могут использовать более сложные комбинации файлов для создания файлов, но я думаю, что docker-compose должен иметь возможность делать что-то подобное. Большинство docker-compose файлы, скорее всего , начать с docker-compose. и заканчиваются .yml в любом случае, так почему бы мне всегда нужно вводить такую длинную команду ( docker-compose -f docker-compose.yml -f docker-compose.testing.yml up ) если мне нужна всего лишь одна дополнительная услуга для моей тестовой среды?

Нет необходимости в envsubst, конфигурация docker-compose выполняет переменные среды, а затем стек докера берет ее из stdin:

docker-compose config | docker stack deploy --prune --compose-file -

Давайте также будем использовать подстановки .env в docker-compose.

@kogli Думаю, проблема в том, чтобы выбрать вариант. У всех есть свои плюсы и минусы. Как я сказал ранее:

Каждое решение будет лучше для одних случаев использования и хуже (или даже бесполезно) для других. Если что-то реализовано, то хранители сохранят это навсегда, поэтому я считаю, что они мудро не торопятся с этим.

@ shin- Думаю, ты сам спрашиваешь: есть ли смысл об этом думать? Учитывая текущее положение команды, насколько сложно ее спроектировать, и множество инструментов, не было бы проще просто сказать людям, что этого не произойдет? Большинство людей, если не все, кто здесь комментировал, нашли способ справиться с этим.

Кажется, закрыть это неплохо, к тому же вы можете сосредоточиться на самом важном, и никто не задается вопросом, следует ли делать запрос на перенос и как удовлетворить все эти потребности одновременно. Они могут просто создать что-нибудь еще и, возможно, даже опубликовать это, чтобы помочь другим.

Для протокола : мое решение не было идеальным, но намного лучше, чем те 2 дня, которые потребовались мне, чтобы установить зависимости, исправить кучу вещей и запустить проект (и он уже использовал Docker). Всего 3 команды, с единственными зависимостями Docker и Docker Compose. Да, кода было больше, чем я хотел. Да, там дерьмовый порядок выполнения команд. И да, нужно иметь в виду еще кое-что. Страница Wiki посвящена этим. Прити, хорошо, если я сам так говорю, а это значит, что Docker Compose выполнил свою работу , мне просто нужно еще кое-что .

Суть в том, что если это выходит за рамки, то продолжать обсуждать это пустая трата времени. Многие люди просто останавливаются здесь, чтобы спросить об этом и высказать свое мнение, прежде чем решить, что делать. Они все равно найдут или построят что-нибудь еще, если его закроют, только быстрее. И вы получаете на одну нить меньше.

Изменить: просто придумал хороший способ выразить это: если нет четких критериев для принятия PR, и в основной команде нет никого, кто участвует в этом или не планирует взглянуть на это в обозримом будущем, это не " выпуск ", просто идея.

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

Реализация этой функции занимает около одного дня, потому что она очень проста. Однако после 2 лет обсуждений все равно ничего. Грустный.

@rubycut Да, вот что происходит, когда так называемые "высшие принципы"

@rubycut Talk дешевый, покажите код. Если можете, пришлите свой PR, если не можете, просто сообщите об этом и ждите.

@wangwenpei Ты шутишь? Во-первых, вы не являетесь сопровождающим этого проекта. Если сопровождающие примут эту идею и поставят тег «требуется помощь», я уверен, что кто-нибудь сможет внести запрос на перенос. Но они сказали, что им это не интересно. Итак, зачем вообще потянет запрос, если он не будет принят.

К вашему сведению, "код" уже есть: # 3047

@wangwenpei ну, # 3047, вот
жду, чтобы получить хоть какой-то отзыв о нем уже более двух лет. Он был недавно закрыт

по причинам, указанным в https://github.com/docker/compose/issues/1896#issuecomment -322285976

что меня очень злит, честно говоря, потому что аргументы, приведенные в https://github.com/docker/compose/issues/1896#issuecomment -322285976, никак не связаны с запросом на перенос:

1. Что такое услуга? По задумке сервис - это четко определенный, длительный процесс, который взаимодействует с другими сервисами для формирования приложения. Это основное предположение, в соответствии с которым работает Compose, и оно определяет наш дизайн для большинства, если не для всех функций, которые мы реализуем.
2. Согласно этому определению, «служба, которая не запускается по умолчанию» на самом деле не является службой [1] - это скорее предопределенная задача, выполняемая в контейнере и действующая на приложение, а не являющаяся его частью.

Я не считаю утверждение By that definition, a "service that is not started by default" is not really a service истинным. Служба, которая не запускается по умолчанию, - это просто служба, которая не запускается по умолчанию, ни больше ни меньше на данном этапе. Запуск по умолчанию или нет ничего не говорит о том, работает ли служба долго или нет, является частью приложения или нет, он только говорит, что не запускается по умолчанию.

И это именно то, что делает изменение в запросе на вытягивание: добавляет возможность отмечать запуск службы по умолчанию или нет.
Для этого нет необходимости вводить новую концепцию, например задачи. Фактически все остальные аргументы в https://github.com/docker/compose/issues/1896#issuecomment -322285976 вытекают из ложной предпосылки 2. и, следовательно, не применимы к запросу на вытягивание, который не пытается что-либо сделать. еще.

Просто для полноты:

[1] Некоторые люди упоминают о желании иметь «дополнительные услуги», но это не самый распространенный вариант использования, упомянутый в этой теме. Насколько я могу судить, большинству людей нужна функция «задачи».

Да, были примеры разовых задач, но были также примеры _реальных_ сервисов в соответствии с вашим определением, то есть законные варианты использования этой функции.
Возможность использовать это для _также_ выполнения разовых задач я не могу принять как веский аргумент против этого. Уже можно определить _service_, который не работает долго, не предоставляет никаких портов и не является важной частью приложения в полностью допустимом docker-compose.yml .

Фактически, это также один из предлагаемых обходных путей! Просто разделите _tasks_ на отдельный docker-compose.yml .
Другие упомянутые обходные пути заключаются в использовании ваших собственных самодельных (зависящих от платформы) скриптов, что полностью противоречит самоустановленной цели docker-compose, см. Мой комментарий выше , или просто переключиться на другой инструмент, т.е. хорошо работающая инструментальная цепочка, чтобы получить эту крошечную удобную функцию, которую можно легко реализовать в вашей текущей инструментальной цепочке (docker-compose).

Единственный реальный аргумент, выдвинутый против самой простой реализации варианта 2 - то есть наличия _ некоторого_ способа_ сообщить docker-compose не запускать конкретную службу по умолчанию, и ничего более, никаких новых концепций или чего-то еще - это то, что это может be_somehow_ может использоваться _ некоторыми_ пользователями.
Но этот аргумент довольно слаб по сравнению со спросом на него и приведенными здесь законными примерами использования ...

@ shin-

но также потому, что у нас [3] просто нет времени или ресурсов для реализации или поддержки того, что эта функция должна была бы стать, чтобы быть действительно полезной для людей.
[3] Здесь я имею в виду «Я», поскольку я единственный сопровождающий, активно работающий над docker-compose в настоящее время.

С одной стороны, я не могу понять, что есть только один активный сопровождающий, а с другой стороны, просто игнорируя запросы на вытягивание и, следовательно, теряя любую возможность, возможно, привлечь других разработчиков в проект.
Изменения кода, представленные в # 3047, уже _до_ реализуют функцию, которая будет _ поистине полезна [многим] людям_ - возможно, не _ всем_ людям с _ всеми_ из _их_ вариантов использования, но большинству людей здесь.

Все дополнительные требования - необходимость вводить совершенно новые концепции, новое управление зависимостями, вплоть до cmake -подобной сложности - просто вытекают из ложной предпосылки!

Я столкнулся с этой проблемой всего пару дней назад, потому что искал такую ​​функцию.

Поскольку он, к сожалению, не реализован, и из того, что я мог понять, официально поддерживаемой альтернативой является использование нескольких файлов yaml.

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

Итак, вот мой +1.