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

Как управлять узлами марионеток с разными версиями модулей?

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

Например, я хочу иметь возможность создать модуль марионетки, содержащий конфигурацию сервера, зависимости и т. Д. Для нашей версии 1.0 и отдельный модуль для версии 1.1. После установки одного мастера марионетки я хотел бы иметь возможность настроить некоторые узлы для запуска версии 1.0, а другие узлы для запуска 1.1.

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

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

Как лучше всего с этим справиться?

Есть несколько способов, которыми мне больше всего нравятся следующие три:

  • Для перехода с apache1 на apache2 мы создали полностью отдельные модули. Вы могли подумать, что это вызвало много дублирования, но мы одновременно переделали нашу конфигурацию.
  • Для простых обновлений отдельных пакетов мы делаем такие вещи, как

    package{"foo":
        ensure => $wants_foo_upgrade ? {
            true => latest,
            false => 1.0
        }
    }
    

    где $wants_foo_upgrade основан на нашей базе данных инфраструктуры, данных extlookup или фактах

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

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

class our_software ($version) {
  ...
}

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

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

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