Назад | Перейти на главную страницу

Инструмент удаленного администрирования Docker для некластеризованных работников

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

Рассмотрим этот пример, где у меня три сервера ...

... и я хочу запустить свои контейнеры fizbuz-tester и foobar-performance на всех трех рабочих узлах. Как бы я сделал следующее:

Базовый образ Docker, запускающий контейнер, такой же, но настройки среды выполнения другие (и будут периодически корректироваться). В настоящее время мой процесс заключается в том, чтобы просмотреть мою документацию и запустить соответствующий docker run команда на каждого рабочего. Если я хочу изменить один из параметров конфигурации контейнера, он снова включает подключение к работнику. Проблемы масштабируемости должны быть очевидны.

Как я могу управлять этим приложением, если оно масштабируется с 3 до 5, до 10 или 20 рабочих узлов?

Инструменты оркестрации Docker, которые я обнаружил, похоже, основаны на "делайте то же самое во многих местах", тогда как для моего приложения мне нужно "сделай то же самое в разные пути во многих местах "

Идеальное решение для удаленной оркестрации контейнеров - Докер Рой- не подходит для моего варианта использования. Все, что я читал о Swarm, указывает на то, что он абстрагирует управление фактическими рабочими хостами Docker, а это совсем не то, что мне нужно.

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

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

OpenSVC можно использовать для удовлетворения ваших потребностей.

* физбуз-тестер *

[DEFAULT]
nodes = *
topology = flex
flex_target = 2

[task#fizbuz]
type = docker
image = fizbuz-tester:latest
netns = host
rm = true
schedule@worker.newyork.example.com = @360
schedule = @60

см. документ с определениями расписания для расширенного синтаксиса https://docs.opensvc.com/latest/agent.scheduler.html#schedule-definition

* foobar-performance *

[DEFAULT]
nodes = *
topology = flex
flex_target = 3

[task#foobar]
type = docker
image = foobar-performance:latest
netns = host
environment@worker.chicago.example.com = MY_JAM=ABBA
environment@worker.denver.example.com = MY_JAM=IRONMAIDEN
environment@worker.newyork.example.com = MY_JAM=BEATLES
rm = true

Если у задачи нет расписания, вы можете запустить ее вручную с помощью om foobar-performance run --rid task#foobar

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

Удаленное управление также доступно в OpenSVC 2.0 с использованием сокета TLS кластера. https://docs.opensvc.com/latest/agent.configure.client.html

Когда вы запускаете команду docker, двоичный файл docker - это только клиент (= docker cli), который отправляет HTTP-запрос движку докера, по умолчанию в локальный сокет unix.
Когда вы активируете удаленный доступ на своих серверах, вы можете запускать команды докеров с удаленного компьютера.

Seaech для 'docker remote api' или см. https://gist.github.com/kekru/4e6d49b4290a4eebc7b597c07eaf61f2

Если вы устанавливаете новейшую версию docker cli 19.03, вы можете использовать новую команду docker context для переключения между удаленными серверами.
https://docs.docker.com/engine/context/working-with-contexts/