Лучший способ управлять сторонним / специализированным программным обеспечением с помощью Puppet?

Мы используем версии Ruby, Collectd, Ant, Java (и более), которые недоступны в репозиториях CentOS или EPEL. До сих пор наша стратегия их установки была своего рода хаком:

  • написать сценарий (с управлением версиями) для каждого пакета, который загружает исходный код или двоичные файлы с хост-сайта с помощью curl на мастер Puppet и при необходимости компилирует исходный код; при необходимости перепаковывает в сжатый архив

  • используйте файловый сервер Puppet, чтобы распространять двоичные файлы на наши серверы, а Puppet манифестирует для распаковки тарбол в / usr / local (или где угодно)

Написание скриптов может быть проблематичным, и их нужно обновлять, если один из сайтов, от которых мы загружаем файлы, меняет свой API. Кроме того, программное обеспечение компилируется отдельно в каждой среде, что кажется расточительным и может привести к проблемам с отсутствующими зависимостями времени компиляции (например, Ruby: require 'readline' или require 'yaml' может работать в некоторых средах, но не в других)

Итак, я могу придумать два других варианта:

  • Просто включите сторонние бинарные файлы в subversion и распространите их вместе с остальным кодом Puppet. Я обеспокоен тем, что это сильно повлияет на производительность проверок и нажатий на код Puppet; мы смотрим почти на 800 МБ (и растет) стороннего кода. Кроме того, кажется неправильным проверять несколько версий и архитектур Java параллельно в управлении версиями.

  • Не управляйте версиями бинарных файлов и не пишите сценарии загрузки - когда мы решим обновить Ruby, скомпилируйте его в блок разработки и загрузите новый пакет вручную всем нашим мастерам Puppet всякий раз, когда мы решаем обновить. Кроме того, что если пакеты будут уничтожены? Или стать не синхронизированным на разных мастерах? Прямо сейчас мы можем легко сгенерировать все наши пользовательские пакеты с нуля.

Какой из трех вариантов лучше? Как люди обычно управляют скомпилированным / переупакованным сторонним программным обеспечением с помощью Puppet? Если вы создаете локальное хранилище Yum, вы управляете версией процесса, который вы используете для создания RPM? Что произойдет, если ваш репозиторий Yum будет уничтожен?

Источник

3 ответа

Решение

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

Источник

Я настоятельно рекомендую использовать репозиторий Yum для развертывания всего вашего программного обеспечения, включая то, которое вы компилируете. После правильной настройки вы устраните все проблемы с зависимостями, контроль версий и т. Д.

Я склонен иметь систему из трех ветвей (dev, qa, prod) для моих репозиториев. Это позволяет добавлять определенные системы в разные репозитории и соответственно проходить через них.

Я делаю это (и планирую обновления ням) через Puppet.

Источник

Повторяя два других ответа: используйте существующую систему управления пакетами вашего дистрибутива.

Мы делаем это с Ubuntu и apt установить RabbitMQ и OAuth следующим образом:

class apt::example {

  file  {  "/etc/apt/sources.list.d/repo.example.list":
    source => "puppet:///modules/apt/repo.example.list",
    ensure => present,
  }

  exec {"install-gpg-key":
    command => "/usr/bin/curl -s http://repo.example.com/ladadadada@example.com.gpg.key | /usr/bin/apt-key add -; /usr/bin/apt-get update",
    refreshonly => true,
    subscribe => File["/etc/apt/sources.list.d/repo.example.list"],
    require => File["/etc/apt/sources.list.d/repo.example.list"],
  }

}

и использовать репо:

class apache2::platform {

  package { ["librabbitmq0", "php5-amqp", "php5-oauth"]:
    ensure => installed,
    notify => Service["apache2"],
    require => File["/etc/apt/sources.list.d/repo.example.list"]
  }

  [...]

}

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

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

Я не пытался добавить конфигурацию репо в Puppet или автоматизировать сборку и добавить в процесс репо новые пакеты, но как только вы достигнете определенного размера, эти задачи станут стоящими. Резервные копии всегда стоят того.

Процесс для RPM а также yum должно быть очень похоже.

Источник
Другие вопросы по тегам