Я хочу масштабировать приложение докера, используемое для выполнения p эриодические тесты производительности оборудования в нескольких удаленных местах.Это приложение требует запуска одних и тех же тестов производительности - с использованием одних и тех же базовых образов - на каждом из удаленных рабочих узлов с конфигурацией, специфичной для каждого рабочего узла.
Рассмотрим этот пример, где у меня есть три сервера ...
worker .denver.example.com
worker.chicago.example.com
worker.newyork.example.com
... и я хочу запустить свои контейнеры fizbuz-tester
и foobar-performance
на всех трех рабочих узлах. Как мне сделать следующее:
fizbuz-tester
каждый час на worker.denver
и worker.chicago
, но каждые шесть часов на ] worker.newyork
. foobar-performance
как MY_JAM = ABBA
на worker.chicago
, MY_JAM = IRONMAIDEN [1111861314] на
] worker.denver и MY_JAM = BEATLES
на worker.newyork
. Базовый образ Docker, запускающий контейнер, такой же, но настройки среды выполнения другие (и будут периодически корректироваться). В настоящее время мой процесс состоит в том, чтобы проконсультироваться с моей документацией и запустить соответствующую команду docker run
для каждого рабочего. Если я хочу изменить один из параметров конфигурации контейнера, это снова связано с подключением к работнику. Проблемы масштабируемости должны быть очевидны.
Как я могу управлять этим приложением, когда оно масштабируется с 3 до 5, до 10, до 20 рабочих узлов?
Инструменты оркестрации Docker, которые я обнаружил, похоже, основаны на ] «делать то же самое во многих местах» , тогда как для моего приложения мне нужно «делать то же самое разными способами во многих местах»
Переход к удаленной оркестровке контейнеров - Docker Swarm- не подходит для моего варианта использования. Все, что я читал о Swarm, указывает на то, что он абстрагирует управление фактическими рабочими хостами Docker, а это совсем не то, что мне нужно.
Есть ли инструмент, который позволяет мне удаленно управлять несколькими рабочими узлами докеров с центрального сервера, при этом давая мне контроль над каждым рабочим индивидуально, а не только как часть пула ресурсов?
Я надеюсь, что два лет спустя после этого вопроса ответ может быть доступен
Когда вы запускаете команду 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-contextxts /
OpenSVC можно использовать для удовлетворения ваших потребностей.
fizbuz-tester
и ] foobar-performance
(это может быть одна служба, если предполагается, что оба контейнера выполняются вместе, что означает, что они функционально привязаны к одной цели / стеку приложения) * fizbuz-tester *
[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 -выступать ance run --rid task # foobar
При масштабировании узлов вам просто нужно присоединить новые узлы к кластеру (2 команды для присоединения узла), и службы будут автоматически масштабированы.
Удаленное управление - это также доступно с OpenSVC 2.0, используя сокет TLS кластера https://docs.opensvc.com/latest/agent.configure.client.html