В нашей среде у нас есть множество скриптов, которые мы используем на 30+ серверах. В настоящее время мы копируем скрипты на каждый сервер при установке ОС. Однако проблема состоит в том, что изменения скриптов требуют повторного развертывания вручную.
Я подумываю о настройке экспорта NFS, но у этого есть некоторые недостатки:
Другие варианты, которые я рассмотрел, - это Subversion (или любой исходный элемент управления), rsync и rpms. Преимущество svn - контроль версий вне скриптов. Rsync прост и позволяет создавать локальные скрипты. Я не думаю, что rpm будет работать из-за наших серверов Solaris.
У нас есть серверы Solaris, Redhat Enterprise Linux и Suse Linux, и у нас есть только небольшое количество (~ 10) небольших скриптов для развертывания, поэтому чем проще, тем лучше.
Рассмотрим: Puppet, Bcfg2, Cfengine.
Мы используем Subversion для разработки наших локальных сценариев, а затем развертываем их с помощью RPM - простой сценарий сборки (также поддерживаемый как часть нашего пакета сценариев) извлекает экспорт SVN и запускает файл спецификации RPM, который он там находит. Затем результат развертывается в нашем локальном репозитории yum, из которого все машины могут его извлечь, либо с помощью автоматических обновлений, либо вручную, в зависимости от типа машины (разработка, постановка, производство и т. Д.).
В моей текущей компании мы используем только серверы RHEL / CentOS, поэтому нам достаточно одного репозитория yum, но в предыдущей компании я построил аналогичную установку, которая выводила RPM для RHEL (репо yum) и Mandriva (репо urpmi), самораспаковывающиеся tgzs для Solaris и даже исполняемые установщики для Windows (NSIS можно использовать для создания пакетов установщика на том же сервере Linux, на котором выполняются все ваши сборки).
Если у вас есть самораспаковывающийся tgz, его автоматическое развертывание на ваших машинах Solaris представляет собой простой вызов SSH.
Subversion звучит как отличная идея, и именно так мы справляемся с подобными развертываниями, хотя мы используем не так много машин. Если ваши машины распределены по нескольким местоположениям, вы можете рассмотреть возможность использования одной из распределенных систем VCS (git и т. 'расположение в каждом центре обработки данных, которое также обновляется через определенные промежутки времени.
Если вам нравится идея использования rpm, у Solaris есть собственная система упаковки (пакеты sysv), и вы можете просто сгенерировать пакет solaris вместе с rpm. Я предполагаю, что этот процесс будет автоматизирован, так что это не составит особого труда.
Самый большой недостаток NFS, о котором вы не упомянули, - это зависимость всей вашей архитектуры от единого файлового сервера. Если это произойдет, вы потеряете все свои скрипты. В зависимости от функции сценариев это может быть для вас приемлемым или неприемлемым.
Если у вас такая небольшая установка, то Subversion может показаться непосильной. В то же время он также обеспечивает управление изменениями, что является одной из основ хорошего системного администрирования.
У нас есть аналогичный сценарий, около 30 серверов с 15-25 скриптами для распространения среди других пакетов. У нас были очень хорошие результаты с SVN в наших лабораториях, yum для распространения и RPM для обслуживания пакетов на реальных серверах.
Сложная часть состоит в том, чтобы автоматизировать построение RPM, поскольку это потребует повременного налога. Каждый раз, когда вы обнаруживаете ошибку, вам необходимо устранить ее локально, а затем сделать новую версию RPM, чтобы установить ее, иначе вы потеряете всю магию.
Хотя Puppet или Bcfg2 кажутся хорошим выбором, мы отказались от них, поскольку они, кажется, усложняют систему. Будь проще.