@jmmills Разве вы не можете запустить свои контейнеры, такие как: "docker-compose scale worker = 5", и эта служба будет начинаться с 5?

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

@ @aanm Ожидаете ли вы, что docker-compose up должен учитывать параметр scale ? Единственная проблема, которую я вижу, заключается в том, что мы вводим в декларативную конфигурацию параметры, которые НЕ совместимы с базовыми концепциями Docker / Docker API, но очень специфичны для Docker Compose.

Если бы мы сделали это в будущем; Я бы предложил что-то вроде:

#!yaml worker: build: rqworker $scale: 5 links: - redis command: rqworker -u tcp://redis

Где $<parameter> обозначает конкретную вещь Docker Compose.

Мы много раз обсуждали, принадлежит ли scale YAML; был PR, чтобы добавить это раньше (# 630). Я по-прежнему придерживаюсь мнения, что большинству людей не следует указывать масштабные числа в своей конфигурации, потому что это делает ее менее переносимой, но я понимаю варианты использования для этого.

Теперь, когда у нас есть элементарный способ дополнить файлы Compose с помощью extends (и, надеюсь, скоро станут лучше - # 1380, # 758), проблемы, которые я поднял в https://github.com/docker/compose / pull / 630 # issuecomment -69210279, возможно, менее важны.

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

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

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

myproject:
    build: .
    command: nosetests
    scale: 0
    links:
       - redis
redis:
    image: redis
apiserver:
    image: myproject
    command: plackup
    links:
       - redis
workerserver:
    image: myproject
    command: rqworker
    links:
        - redis

@jamshid @jmmills А как насчет параметра / ключа enabled в файле YAML для каждой службы? Такой, что можно отключить / включить службу?

@prologic Зачем это нужно, если параметр "масштаб" решает обе задачи?
Если вы хотите представить запущенный процесс / контейнер как экземпляр класса, его можно даже назвать instances

@jmmills Я просто пытаюсь найти _ решение_ для вашего варианта использования, которое не связано с нарушением текущего docker-compose как такового. Я действительно склонен думать, что scale=0 не кажется подходящим, и я совершенно не понимаю, должен ли scale=X быть частью самого Compose.

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

Что ж, я думаю, у нас есть либо scale=0 либо disabled ключ.

: +1: при наличии возможности установить размер по умолчанию scale для экземпляра. И я согласен, как только масштаб установлен, нет необходимости в клавише disabled , так как вы просто установите масштаб на 0.

+1

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

$ docker-compose up && docker scale thing=4

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

$ docker-compose up

Становится DWIM.

Я не уверен, что мне это действительно нравится; внезапно up обретает две возможности:

• Поднимите все контейнеры, у которых нет параметра scale .
• Принесите все контейнеры, в которых есть scale=0 .

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

• масштабировать контейнеры вверх / вниз
• Отключить контейнеры / службы с помощью ` scale=0

Зачем поднимать контейнеры с scale=0 ?
Сборка будет создавать образы с scale=0 , тем самым облегчая потребность в базовом образе.

Я _ могу ошибаться_, но, читая ваш последний комментарий, это как бы подразумевало :)

Позвольте мне уточнить:

base_thing:
    build: .
    scale: 0

thing:
    image: base_thing
    # scale: 1 implied by default

workers_for_thing:
    image: some_other_image
    scale: 4
    links:
      - thing

test_harness:
    image: base_thing
    command: nosetests --where=my_test_code_dir --all-modules
    scale: 0

Теперь ожидаемое поведение: docker-compose build строит любые контейнеры с помощью "build" (создает ли извлечение внешних изображений при сборке? Не помню), docker-compose up запускает что-либо с положительным масштабом (по умолчанию 1), docker-compose run test_harness необходимости построит "base_thing" и выполнит мою единственную команду. Сообразительный? :)

Изменить: docker-compose up будет запускать 1 "thing" и 4 "worker_for_thing"

Хорошо спасибо; ваш пример имеет больше смысла и немного яснее в отношении намерения scale=0

Я думаю, что docker-compose "тянет" изображения на up / run .

Мне нужно создать рецепт с указанием количества de intances (масштаб), для тестирования, производства, qa и т. Д.

+1 за scale=X . Это было бы очень полезно.
И +1 за комментарий @jmmills с описанием конфигурации и ожидаемыми результатами.

Ура! для scale=x . Инициализация набора контейнеров определенно поможет определить потенциальные условия гонки при настройке конфигураций кластера.

+1 за scale=x (включая scale=0 чтобы отключить службы для начальных docker-compose up )

+1 за scale=x .

x - это NaN, я бы предложил вместо него -1 .

+1 для scale = x.

+1

+1

Как насчет того, чтобы прекратить ставить +1, пожалуйста?

+1 полезно, чтобы увидеть уровень интереса к функции.

@shofetim Я знаю лучший способ сделать это: реализовать рассматриваемую функцию и отправить запрос на перенос ...

Добавление +1 - также хороший способ увидеть, как люди согласны с предлагаемым решением. Это довольно распространенное поведение на гитхабе. Если щелкнуть кнопку отказа от подписки в уведомлениях, они отключатся.

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

Вот как можно обойти вариант использования "scale = 0":

app:
  build: .
  environment:
    - DATABASE_URL=postgres://user:password<strong i="6">@host</strong>:5432/dbname
  command: sleep 999999999999

app_web:
  extends:
    service: app
  ports:
    - "3000:3000"
  command:
    # intentionally blank to use Dockerfile's default RUN command

app_worker:
  extends:
    service: app
  command:
    rake jobs:work

@wkonkel да, я делал подобные вещи в прошлом.

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

Для этого есть действительно старый PR: # 630.

Проблема в том, что масштаб - это операционная проблема, а не часть определения приложения, поэтому на самом деле не подходит для файла набора.

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

Случай scale: 0 уже должен быть рассмотрен с помощью # 1754. Контейнер "без операции" может просто иметь команду, которая сразу завершается (echo, true и т. Д.). Случаи, когда требуется scale: 0 , обычно могут быть одним из двух: контейнеры тома данных или "специальные / административные задачи".

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

Административные задачи лучше решать с # 2051. Вы можете определить admin.yml который расширяет ядро docker-compose.yml и позволяет вам связывать ваши административные задачи с "основной композицией", не запутывая определение каждой из них.

Оба эти изменения сейчас в основной версии и будут доступны в версии 1.5.0 (которая уже не за горами).

Таким образом, остается только случай, если вы захотите масштабировать службу до> 1 по умолчанию. Уже довольно легко написать что-то подобное, но возможность поместить это в файл конфигурации все равно было бы неплохо. Думаю, мы собираемся изучить идею отдельной конфигурации в # 745. Я считаю, что эта новая конфигурация будет хорошим местом для вещей, которые не являются частью определения приложения (имя проекта, сетевое имя по умолчанию, масштаб по умолчанию и т. Д.).

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

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

Не могли бы вы привести пример этого дела?

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

Есть ли причина, по которой базовый образ должен быть частью той же сборки? Как я отмечаю в # 1455, compose - это в первую очередь не инструмент для сборки докеров. Его цель - обеспечить состав контейнеров во время выполнения. Попытка поддержать все возможные сценарии сборки значительно увеличивает объем компоновки и отвлекает от компоновки контейнеров. Даже инструмент, созданный для создания образов, будет трудно поддерживать каждый из этих запросов. Я думаю, что лучший вариант - оставить как можно большую сложность сборки в компоновке и позволить пользователям менять соответствующий инструмент сборки вместо docker-compose build .

Вариант использования, который меня волнует, - это scale = 0 (возможно, abstract = true будет лучшим дескриптором). Я хочу обмениваться изображениями и переменными среды между разными командами. В частности, мне нужен один запущенный веб-сервер и один сервер фоновых заданий, оба с одним и тем же кодом и оба с одинаковыми переменными среды.

@wkonkel, используя ваш пример, я думаю, это тоже сработает?

app_web:
  build: .
  ports:
    - "3000:3000"
  environment:
    - DATABASE_URL=postgres://user:password<strong i="7">@host</strong>:5432/dbname

app_worker:
  extends:
    service: app_web
  command: rake jobs:work
  ports: []

Вы торгуете, имея абстрактную услугу с переопределением без операции command на отсутствие абстрактной услуги с переопределением без операции на ports . Звучит правильно?

1988 год связан с абстрактными услугами.

@dnephin Да, в моем случае это работает.

На самом деле, я беру это обратно ... Я просто попробовал это с docker-compose-1.4.2, и кажется, что "ports: []" не отменяет родительский, поэтому app_worker не может начать с "порт уже выделен ".

@dnephin В этой ветке есть объяснение получше, но я

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

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

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

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

Или, может быть, я просто слишком самоуверен и должен обернуть свои команды docker compose в сценарии оболочки, чтобы запускать мои службы с масштабированием и определять все мои сборки изображений как цели make с зависимостями.

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

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

@dnephin Круто, не могли бы вы затем предоставить link этому базовому / промежуточному контейнеру, чтобы убедиться, что он будет собран первым?

@dnephin : у меня есть бегун CI, который выполняет эквивалент docker compose up . Я хочу, чтобы моя тестовая среда работала с несколькими версиями службы (т. Е. Масштабировалась). Я мог бы скопировать весь блок конфигурации, но это потребовало бы повторения самого себя. В данном случае это не «просто операционная проблема», это то, что мне нужно в моей среде разработки, пока я разрабатываю кластерное приложение, которое в настоящее время полностью описывается как файл компоновки. На данный момент мне нужно было бы иметь некоторую конфигурацию внеполосного масштабирования, а затем как-то вызывать docker-compose scale , я полагаю, но это не кажется идеальным и представляет дополнительные возможности для неудач и гонок.

В производственных случаях вы можете захотеть запустить свои услуги в минимальном масштабе. Скажем, например, вы мигрируете из одного кластера в другой, и для простоты примера давайте сохраним некоторые сложные части миграции в виде копируемых данных; и вам действительно нужно начать иметь дело с некоторым трафиком с самого начала, поэтому вам нужно развернуть с помощью docker-compose up по крайней мере (n) экземпляров некоторой службы, скажем, web.

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

С моей точки зрения масштаб, по сути, является определяющим параметром топологии и композиции.

@dnephin

Не могли бы вы привести пример этого дела?

Consul, MariaDB Master-Master или любое другое распределенное приложение на Swarm действительно должно иметь как минимум 3 узла в кластере, чтобы быть надежными. Определенно есть варианты использования количества служб, доступных в файле конфигурации, я не понимаю, почему вы так против. Большой: +1: от меня здесь.

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

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

1. Я установил начальную шкалу 3 для услуги
2. Я запускаю docker-compose up -d , мой сервис масштабируется до 3
3. Я бегу docker-compose scale service=4
4. Я вношу некоторые изменения и выполняю повторное развертывание с помощью docker-compose up -d .. Что происходит? Масштаб снова уменьшается до 3? Теперь он полностью игнорирует масштаб?

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

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

Приведенный вами пример является примером эксплуатационного требования. Для запуска приложения не нужно несколько мастеров, это необходимо для надежности (работы) сервиса. И вы все еще можете сделать это с помощью scale db=x .

Используя пример, приведенный выше @dnephin :

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

Ответ на вопрос, поднятый @dnephin, заключается в том, что я ожидаю, что будет запущено столько же сервисов / контейнеров, сколько до модификации.

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

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

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

Я создал # 2496 для моего предложения об удалении команды масштабирования и замене ее опцией масштабирования (из сообщения выше). Было бы здорово получить обратную связь по этому предложению.

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

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

Сценарий, который вы упомянули в новом предложении, будет легко решен с помощью полнофункциональной службы / инструмента new-compose.

+1

+1

+1

@dnephin Разве поведение не будет таким же, если вы это сделаете:

$ docker-compose up -d && docker-compose scale node=4 && docker-compose up -d

Разве это не проблема того, как композиция сохраняет внутреннее масштабирование.

В том-то и дело, что "Составить приложение" без состояния. Единственное состояние - это 1) файл компоновки и 2) метки контейнера докеров, управляемые движком.

Файл Compose редактирует только человек, а не Compose. Было бы беспорядком пытаться написать yaml с такими же комментариями, порядком и структурой. Он не поддерживается pyyaml, и мы все равно не хотели бы этого делать.

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

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

up && scale && up делает правильные вещи. up воссоздаст все контейнеры, и, поскольку в конфигурации нет значения масштаба, нет никаких сомнений в том, какой должен быть желаемый масштаб. Он уже был установлен командой масштабирования и отслеживался метками контейнеров.

@dnephin Я думаю, что согласен с тем, что вы говорите, [я могу ошибаться в этом предположении], что вы действительно спрашиваете, _если_ количество экземпляров компонента действительно связано с составом службы (группировка контейнеров запуск различных контейнеров компонентов). Я бы сказал, что в настоящее время он решает эту проблему, только с оговоркой об отсутствии паритета между cli и определением композиции (yaml).

Если объем ответственности определен, что масштаб не является проблемой композиции, тогда масштаб должен быть удален как параметр cli (вероятно, вызывающий недовольство многих пользователей), или если определено, что масштаб является проблемой композиции службы. что между cli и yaml должен быть паритет с дополнительной поддержкой минимального количества экземпляров для учета кластеризованных экземпляров, требующих N + 1.

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

+1

+1

+1

В настоящее время мне нужно объявить такие вещи:

селен-хром1:
...
селен-хром2:
...

Это было бы хорошо:
селен-хром:
масштаб: 2

+1

именно то, что сказал @caioquirino . +1

docker-compose up должен вызвать рабочую среду, не требуя другой работы. Единственный способ вызвать службы, требующие нескольких узлов, - это использовать шаблон, упомянутый @caioquirino . Игнорируя здесь нарушения DRY, шаблон выглядит неправильно, когда вы затем пытаетесь использовать команду масштабирования для добавления еще одного узла, поскольку неясно, какую «службу» следует масштабировать.

Масштабирование в файле yml исправляет это.

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

По линиям ...

consul_bootstrap:
  build: ./consul
consul_master:
  build: ./consul_master
  scale: 0

Идея состоит в том, что вы можете использовать тот же файл docker-compose.yml и беспрепятственно переходить от среды разработки к рабочей. Экземпляры consul_master автоматически присоединятся к плоту и установят кворум, выполнив docker-compose scale consul_master=3 . Это было бы круто.

Чтобы ответить на @dnephin ...

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

1. Я установил начальную шкалу 3 для услуги
2. Я запускаю docker-compose up -d, мой сервис масштабируется до 3
3. Я запускаю docker-compose scale service = 4
4. Я вношу некоторые изменения и выполняю повторное развертывание с помощью docker-compose up -d .. Что происходит? Масштаб снова уменьшается до 3? Теперь он полностью игнорирует масштаб?
5. Любить это
6. Хорошо
7. Я все еще с тобой
8. Я думаю, что должно быть некоторое различие между существующим развертыванием и новым развертыванием, чтобы можно было поддерживать непрерывность масштабирования для существующих развертываний, которые получают текущие обновления. Отдельное развертывание будет включать окружение DOCKER_HOST и т. Д., А также масштаб каждого компонента, идентификаторы образов и историю повторных развертываний. Это может быть хорошее место для подключения к механизмам апстека, таким как непрерывное развертывание или сине-зеленые развертывания? Я представляю себе рабочий процесс, немного более готовый к производству, поэтому вы можете просто подключиться к другому DOCKER_HOST и выполнить docker-compose up -d а затем предоставить хуки, чтобы инструменты upstack могли управлять такими вещами, как CI и сине-зеленые развертывания. Может быть, добавить что-нибудь вроде DOCKER_COMPOSE_ENV = {"testing" || "производство" || "dev"}?

ИМХО, имея "жестко запрограммированные" scale , скажем до 3, он должен начинаться с 3 контейнеров

Я думаю, что путаницу между параметром «scale» и командой «scale» можно было бы облегчить, назвав параметр YAML «initial_scale» или «default_scale». Это довольно ясно дает понять, что это просто значение, которое будет использоваться, если не будет какого-либо переопределения. Также (по крайней мере, IMHO) кажется разумным, что этот параметр "initial_scale" будет использоваться только тогда, когда docker-compose запускает службу в первый раз, а не при повторном запуске docker-compose up с некоторыми экземплярами службы, уже запущенными.

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

Происходит интересная вещь, в сообщении блога https://blog.docker.com/2016/02/video-containers-as-a-service-caas/ на видео "48.56 показано, что в новом выпущенном центре обработки данных docker вы может в точке создания стека фактически установить, сколько экземпляров контейнера вы хотите запустить.Так что эта идея не нова для команды докеров, надеюсь, она будет включена в следующие выпуски compose

+1

+1

Миллионы вопросов и запросов scale / initial_count и так далее .. и все еще не запланированы.

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

+1

+1

+1

+1

ПОЖАЛУЙСТА ОСТАНОВИСЬ!
НЕ ДОБАВЛЯЙТЕ +1!
ПРОСТО ПОДПИСАТЬСЯ НА ВЫПУСК!

+1 ( @pierrre извините)

+1 это очень важно ( @pierrre , извините)

Я согласен, но не хочу получать 100000 уведомлений о вашем «+1»!

/ me разветвляет docker compose и начинает изучать кодовую базу.

Многие действительные пункты выше, похоже, что наличие параметра default/inital scale в файле конфигурации + команда scale cli будет обращаться к обоим. Чтобы добавить варианты использования для поддержки варианта начального масштабирования, рассмотрите кластерные службы, в которых кворум состоит из X узлов и которые не должны работать в противном случае (например, не менее 3). Смысл docker-compose том, чтобы иметь полноценный дескриптор такой системы.

Мой вариант использования:

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

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

Иногда они уже:

• docker-compose up service
• docker-compose scale service=1 .

И, если scale предоставил все параметры cli (например, --force-recreate ), которые делает up , или если up знал о подсчете, то они в основном так и были бы.

Если, как предлагается в этой проблеме, к docker-compose.yml будет добавлена ​​директива «начального масштаба», тогда up придется научиться считать. В этот момент не следует ли up просто поддерживать синтаксис подсчета docker-compose up service=10 (который может перезаписать любой масштаб, определенный в yaml)?

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

@mattgiles Я согласен, вот где я собирался с # 2496, однако я не service=count можно добавить к up . Я думаю, что это могло бы исправить ситуацию. Единственная проблема, которую я вижу, заключается в том, что в настоящее время up web означает только запуск веб-службы и ее зависимостей. Попытка сделать up web=3 должна и дальше означать то же самое. Это означает, что нет способа up всего и сразу переопределить счетчик масштаба, но это, вероятно, нормально.

Я обновлю предложение в №2496

@dnephin Я пропустил последнее предложение. Потрясающие!

fwiw, я думаю, что для docker-compose up web=3 совершенно интуитивно понятно вызвать три контейнера для "веб-службы", а также любые зависимости ... в соотношениях, определенных в yaml (для чего-то вроде scale директива

Последующие вызовы up могут продолжаться, как сейчас, оставляя существующие контейнеры в покое. Только если текущий масштаб меньше, чем тот, который определен в yaml, он изменит счетчики, чтобы они соответствовали запрещенному масштабу. Никакая определенная шкала не будет по-прежнему подразумевать шкалу 1.

Такие вещи, как --force-recreate также должны, вероятно, оставить счетчики в покое, если они выше, чем определено в yaml, но все же воссоздать все контейнеры, чтобы они соответствовали другим атрибутам.

Для меня также имеет смысл иметь возможность уничтожать контейнеры, как в настоящее время можно с scale , вызывая что-то вроде docker-compose up web=2 т. Д. И т. Д.

+1

+1 (просто чтобы разозлить @pierrre ;))

+1

+1 для scale = x.

В связи с этим мне хотелось бы описать синглтоны. scale=1

Любой успех здесь с вариантом масштабирования

+1

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

Спасибо,
Джейсон Миллс

• отправлено с мобильного телефона.

8 августа 2016 г. в 17:19 lavvy [email protected] написал:

Любой успех здесь с вариантом масштабирования

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

+1

+1

+1

+1

+1 (чтобы снова разозлить @pierrre )

+1

Я хотел бы повторить случай

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

масштаб = 1
Потому что мне нужен один-единственный из них - _ever_. В кластере MariaDB есть случай, когда мне может понадобиться только один узел, настроенный с определенным механизмом хранения (например, Spider, ColumnStore и т. Д.).

scale = n
Потому что бывают случаи, когда я знаю, что мне нужно запустить n сервисов, например, кластер MariaDB, где у меня всегда будет один первичный (с его конфигурацией) и два вторичных (с их отличной от первичной конфигурацией).

Для меня имеет смысл @alvinr. По умолчанию, вероятно, должно быть 1.

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Я не являюсь представителем Марафона или Мезосферы.

Это еще один пример довольно простого запроса функции, который был оставлен / отклонен службой поддержки докеров более года. https://github.com/docker/docker/pull/12749 - еще один пример. Kubernetes и Marathon уже довольно давно используют эти опции («экземпляры»: 3 в файле marathon.json) и даже реализуют автоматическое масштабирование. Нежелание группы поддержки докеров уже некоторое время отталкивает меня от центра обработки данных и роя докеров.

В Kontena это также как instances: 3 (https://www.kontena.io/docs/references/kontena-yml)

Другой способ сделать это - добавить секцию scale в файл компоновки версии 2.

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

Примером может быть:

version: "2"

services:
  worker:
    image: something
    command: work

scale:
  worker: 2    

Это с возможностью указать scale: 0 потенциально может убить двух зайцев одним выстрелом, а другой - https://github.com/docker/compose/issues/1896

Кажется, это и ежу понятно.

Я хочу развернуть nginx + nodejs + mongodb с 3 или 4 экземплярами nodejs. Каждый раз, когда я запускаю приложение.

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

docker-compose up масштабировать nodejs = 4

Сделал бы.

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

16 октября 2016 г., 21:36, «Майкл Шварц» [email protected]
написал:

Кажется, это и ежу понятно.

Я хочу развернуть nginx + nodejs + mongodb с 3 или 4 экземплярами nodejs. Каждый
когда я запускаю приложение.

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

docker-compose up масштабировать nodejs = 4

Сделал бы.

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

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

@westlakem Будем надеяться, что Docker для MacOS не постигнет та же участь, будем надеяться, что ребята из Unikernel останутся.

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

Это просто ужасно:

docker-compose up -d
docker-compose scale workers=16
docker-compose down
docker-compose up --abort-on-container-exit

которые явно можно заменить чем-то вроде:

docker-compose up --abort-on-container-exit --scale workers=16

Изменить: я вижу, что «Rancher» имеет синтаксис, похожий на docker-compose, и поддерживает параметр начального масштаба: https://paypertrail.com/blog/tech/docker-rancher-and-laravel-easy-and-safe-scalability

Обходной путь - использовать возможности привязки и слияния YAML и дублировать службу в файле docker-compose.

services:
  toscale: &my_service
     ... # all paramteres
  # second instance
  toscale2: 
     << : *my_service
     ports:
       - 81:80 # override port if needed

так далее ...

Это было бы очень полезно!

Это очень странно, этого не существует ...

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

Это уже работа над файлом композитора v3 https://github.com/aanand/compose-file/blob/master/schema/data/config_schema_v3.0.json, который будет и уже поддерживается в docker-compose v1. 10.0-rc1

В их предложениях "Услуги" есть встроенный параметр. Очень печально, что в качестве
подписавшись на этот выпуск, никто из команды разработчиков не сообщил нам, что
он входил в состав продукта Services, и кому-то пришлось прочитать заметки RC
за 1.10 для любого понимания. Где представители докеров?

Пт, 6 января 2017 г., 6:30, Yasmany Cubela Medina <
[email protected]> написал:

Это уже идет работа над файлом композитора v3 https://github.com/aanand/
составить файл / blob / master / schema / data / config_schema_v3.0.json, который будет
и он уже поддерживается в docker-compose v1.10.0-rc1

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/docker/compose/issues/1661#issuecomment-270886347 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AES98nOAW-h0BVaR8D9uQfLpMCQRfdyfks5rPiXEgaJpZM4FS8ZQ
.

+1

+1

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

Например, я запускаю docker-compose scale nodejs_web=4 затем docker-compose down ,
затем я снова начинаю docker-compose up , он запускает 4 nodejs_web.

Я хочу знать, где команда scale сохраняет число 4?

Docker-compose.yml может быть:

version: '2'
services:
  nodejs_web:
    image: node
    command: node

Поддерживаю предложение
Пожалуйста, дайте нам эту основную функцию.

Сервисы в новой версии Docker предлагают функцию «реплик».

В понедельник, 20 марта 2017 г., в 15:28, alwaysastudent [email protected]
написал:

Я поддерживаю предложение @dnephin https://github.com/dnephin на # 2496
https://github.com/docker/compose/issues/2496
Пожалуйста, дайте нам эту основную функцию.

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

@westlakem - эта функция предназначена для роя. Это не для масштабирования обычных услуг.

Так много плюсов, мало минусов. Что с этим вопросом?

В https://github.com/docker/compose/issues/2496 есть более недавнее предложение о полном удалении команды масштабирования.

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

Реализовано еще в 1.13.0. Спасибо всем за отзывы и терпение.

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

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

@greenscar Извините, я не совсем уверен, в чем проблема - вы недовольны тем, как реализована эта функция? Если да, то как мы можем сделать это лучше?

Почему этого нет в версии 3? Чрезвычайно запутанный, поскольку «deploy.replicas» и «up» не эквивалентны, можно сказать, что эта функция отсутствует в v3.

@cgarciae deploy.replicas служит той же цели, что и scale . Почему, на ваш взгляд, они не равнозначны?

@ shin - Если я не хочу создавать рой и использую только docker-compose up -d , docker compose сообщает мне, что он проигнорирует настройки «развертывания».

@cgarciae Почему вы используете файл v3, если не хотите создавать Swarm?

Я думаю, что все, кто использует докер, ожидают, что параметр масштаба будет работать как для файлов докеров 2, так и для 3 файлов. Нет причин не делать этого, и он может даже установить значение по умолчанию для deploy.replicas. Если установлен deploy.replicas, он переопределяет масштаб в рое. Что не так с этой картинкой, кроме того, что все ожидают ее появления (и, конечно, если она вам не нравится, нет необходимости использовать ее в вашем docker-compose.yml)?

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

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

Ой, подождите, так что если я изменю конфигурацию сборки докеров на version: "2.2" тогда я могу использовать scale: 2 но если кто-то захочет перейти на более позднюю версию, больше нет возможности сделать это?

Хорошо, я вижу, что проблема с "версией" на самом деле не означает, что версии уже были подняты, https://github.com/docker/compose/issues/4693

Я использую v3.6, потому что мне нужны некоторые конфигурации, которых нет в 2.2. Для локальной разработки я не использую рой, но я хочу установить scale = 0 для некоторых контейнеров в моем docker-compose.overrides.yml. Потому что некоторые из них предназначены только для процессов сборки, например, контейнера frontendbuild. Этот контейнер разделяет некоторые тома с другими запущенными контейнерами, но не должен запускаться вместе с этими другими контейнерами при docker-compose up. Таким образом, buildcontainer просто запускается с командой run. Да, я могу установить параметр --scale при вызове docker-compose up, но я думаю, что лучше записать его прямо в конфигурацию. :)

Спасибо за масштабный параметр. Я смог использовать его в непроизводственной docker-compose.yml чтобы любой мог использовать конфигурацию высокой доступности Consul и Vault. Параметр масштабирования упростил подготовку локальной конфигурации высокой доступности. https://github.com/samrocketman/docker-compose-ha-consul-vault-ui

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

На какой версии docker compose вы работаете? Начиная с версии 3 эта функция была удалена (я имею в виду, что она никогда не реализовывалась), поэтому ее игнорировали. См. Https://docs.docker.com/compose/reference/scale/

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

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

Хорошо, я догадался, что вы говорите о компоновке докеров со стеком роя, вот почему. Я никогда не пробовал, но странно говорить о HA с docker compose без оркестратора и узла mutli. Это для "poc" или для тестирования? Во всяком случае, я никогда не пробовал в этом контексте

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