Управление конфигурацией: межмашинные зависимости

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

Например, на сервере MySQL я настраиваю puppet для следующих действий:

• Настройте проверку подлинности на компьютере, чтобы он попадал на мой сервер LDAP
• Настройте apt для использования моего локального зеркала репозитория
• Установить пакеты MySQL
• Напишите my.cnf
• Запустите MySQL
• Создать пользователей в базе данных

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

Этот сервер MySQL является одним блоком в настройке master-> master replication. В идеальном мире puppet (или другой подобный инструмент) позволил бы мне представить тот факт, что серверу B нужно подождать, пока сервер A станет доступным, а затем попытаться установить с ним отношения репликации.

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

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

В качестве альтернативы, и хотя я сам не являюсь подписчиком, некоторые люди считают свои манифесты / прогоны недетерминированными. Это означает, что один запуск не обязательно объявляет полный результат узла. Может пройти два или более прогонов, прежде чем узел достигнет желаемого состояния.

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

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

Кукольный может сделать это просто отлично. Попросите каждый сервер экспортировать ресурс, чтобы настроить другие соответствующие серверы для выполнения того, что необходимо сделать после их запуска и работы. У меня нет примера для MySQL, но мы настраиваем таким образом много (например, около 80 при текущем количестве) ресурсов DRBD, а также все наши конфиги Nagios.

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