Запустите службу докеров в рое, имеющем несколько системных архитектур.

Я хочу протестировать свой распределенный алгоритм как на моем ноутбуке (x86_64), так и на моем кластере Raspberry Pis (armhf), используя новый режим роя докеров.

После множества настроек я могу успешно создать кластер swarm, состоящий из одного управляющего узла (ноутбука) и N+1 рабочих узлов (N рашпилей плюс мой ноутбук). Это выглядит так:

laptop$ docker swarm init --advertise-addr 192.168.10.1
raspi1$ docker swarm join --token <TOKEN> 192.168.10.1:2377
# [...]
raspiN$ docker swarm join --token <TOKEN> 192.168.10.1:2377

Теперь я создал два образа для своего проекта: x86_64 (my_project:x86_64) и armhf (my_project:armhf). Мне очень нравится архитектура узлов/служб из этого нового режима роя, так как создание M (квази-)независимых узлов — это именно то, что я хочу, но как я могу передать правильный образ нужному узлу с помощью команды docker service create ...?< /сильный>

Из того, что я вижу, docker service create принимает только одно изображение в качестве параметра! Я видел здесь, что я мог бы дать метку каждому узлу и попросить службу использовать только узлы, имеющие эту определенную метку, но это не то, что я хочу. В конечном итоге мне пришлось бы управлять двумя кластерами задач, разделенными по архитектуре, что подавило бы мое желание использовать планировщик и диспетчер режима роя.

Я унылый выродок в своем стремлении к портативности, вот кто я!

PS: обратите внимание, у этого есть тег «docker-swarm-mode», а не «docker-swarm», потому что docker swarm и docker swarm — это две разные вещи.


person Adrien Luxey    schedule 07.12.2016    source источник


Ответы (2)


Адриан, это капитан докеров.

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

Тем не менее, есть хак, который вы могли бы сделать, чтобы связать статический двоичный файл в вашем образе докера для обеих архитектур и решить в вашем entrypoint.sh, какой двоичный файл вызывать в зависимости от базовой архитектуры.

С другой стороны, то, что вы можете создать два сервиса на архитектуру, не так уж и плохо. Версия приложения для Arm и x86_64 может потребовать различного масштабирования в зависимости от характеристик оборудования, а дополнительным бонусом является то, что вы также можете применять различные ограничения памяти / процессора в зависимости от базового оборудования.

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

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

person marcosnils    schedule 16.12.2016
comment
Спасибо за ваш ответ @marcosnils, я ждал его! :) Ваш взлом кажется законным, если мне удастся статически связать двоичный файл моего проекта. Это руководство, кажется, достигает такого уровня взлома, если я правильно понял. Кроме того, знаете ли вы об мультиархивных изображениях? Я не совсем понял, чего они достигают, и мне трудно найти примеры, но, может быть, это поможет мне создавать контейнеры для каждой архитектуры внутри моих контейнеров? В любом случае, еще раз спасибо, вы заслужили свою награду! - person Adrien Luxey; 17.12.2016
comment
Привет, @AdrienLuxey!. Похоже, что учебник, которым вы поделились, предназначен для другой цели. Это в основном позволяет создавать несколько арок локально, полагаясь на qemu, и они также помечают их по-разному, чтобы они были доступны в вашем реестре. Я знаю о многоархивном репо. По сути, они предоставляют простой способ создания образов с несколькими архитектурами, но каждый образ будет иметь отдельный тег в реестре. Конечно, вы можете использовать некоторые из этих инструментов для создания образов с многоархивными двоичными файлами внутри, но это может потребовать некоторой работы. - person marcosnils; 19.12.2016
comment
У @AdrienLuxey есть для вас хорошие новости: теперь вы можете создавать многоархивные образы с помощью сторонних внешних инструментов до тех пор, пока интерфейс командной строки docker официально не поддержит их создание. Проверьте integratedcode.us/2016/04/ 22/. Движок докера и реестр в настоящее время поддерживают этот формат, поэтому, если вы загрузите образ с несколькими архитектурами в реестр и запустите его в swarm, он должен работать. - person marcosnils; 20.12.2016

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

Посмотрите на изображение hypriot/qemu-register — его источник находится по адресу https://github.com/hypriot/qemu-register — и прочтите его до конца, чтобы понять, что он делает. По сути, он позволяет вам эмулировать двоичные файлы armhf и aarch64 на машинах x86. Затем вы можете запустить одно изображение во всем кластере.

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

person vielmetti    schedule 26.12.2016