Мы используем версии 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 будет уничтожено?
Puppet на самом деле не предназначен для распространения больших файлов, поэтому вам лучше делать это вне группы. Наилучший подход - упаковать пользовательское / стороннее программное обеспечение в виде пакетов RPM и разместить свой собственный репозиторий RPM. Пакет RPM (то есть specfile и патчи) в идеале должен контролироваться по версиям, а репозиторий RPM должен иметь резервную копию или размещаться на нескольких машинах.
Я настоятельно рекомендую использовать репозиторий Yum для развертывания всего вашего программного обеспечения, включая то, которое вы компилируете. После правильной настройки вы исправите все проблемы с зависимостями, контроль версий и т. Д.
Я предпочитаю иметь систему с тремя ветвями (dev, qa, prod) для моих репозиториев. Это позволяет добавлять данные системы в разные репозитории и соответственно проходить через них.
Я делаю это (и планирую обновления yum) через 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, запуск и обновление, поскольку эта команда возвращает положительный код выхода, который заставляет марионетку думать, что это не удалось, но поскольку она работает Я не приложил много усилий, чтобы исправить ложное сообщение об ошибке.
Я не пытался добавить конфигурацию репо в марионетку или автоматизировать сборку и добавить в процесс репо для новых пакетов, но как только вы достигнете определенного размера, эти задачи станут целесообразными. Резервное копирование всегда полезно.
Процесс для RPM и yum должно быть очень похоже.