В настоящее время мы используем Puppet (с манифестами и связанными файлами в SVN) для управления конфигурацией наших хостов * nix. Однако я столкнулся с проблемой, вызывающей недоумение.
Многие из наших хостов имеют скрипты, специфичные для хоста - задания cron, скрипты интеллектуального анализа данных, скрипты, которые динамически генерируют файлы конфигурации и т. Д. Я ищу способ управлять этими скриптами, в частности создавать их версии и позволять относительно простое решение для восстановления, если хост перестраивается без изменения существующей компоновки.
Кажется, я не могу найти решение, которое «работает» в нашей среде.
Думаю, самый простой способ объяснить, что я ищу, - это то, что я хотел, но не существует:
Какие-либо предложения?
Настоящая проблема здесь не в системе SCM, а в том, что у вас нет контроля над вашими пользователями, вносящими неконтролируемые изменения в вашу производственную среду. Если вы не можете заставить пользователей регистрировать изменения, управление конфигурацией - не совсем правильный подход. Похоже, вам действительно нужно хорошее решение для резервного копирования, которое можно использовать для быстрого восстановления рабочего образа.
Если вы хотите иметь возможность восстанавливать "конфигурацию" с помощью марионетки, вместо обычного решения для резервного копирования (которое у вас должно быть в любом случае), вы можете использовать fpm Джордана Сисселя http://www.semicomplete.com/blog/geekery/fpm.html . fpm действительно предназначен для создания пакетов (rpm, deb и т. д.), но он может выводить марионеточный модуль с учетом списка файлов. Вы можете запустить cronjob на каждом хосте, который генерирует марионеточный модуль с этими хост-скриптами и проверяет его в svn / git / etc.
ФСВС - это клиент Subversion для Unix, который позволяет использовать любую часть файловой системы в качестве рабочей копии. Он хранит данные SVN в / var, поэтому он не забивает ваши каталоги вложенными папками .svn. Важно отметить, что он прозрачно сохраняет метаданные файлов Unix в атрибутах SVN.
Вы используете его так же, как svn в командной строке:
cd /home/mydir
fsvs urls svn+ssh://yoursvnrepohost/var/svn/yourrepo/home/mydir
fsvs exclude ./tmp
fsvs commit -m 'initial commit'
(...)
fsvs log
fsvs diff thatconfigfile
Вы можете использовать любой инструмент SVN для просмотра полученного репозитория SVN.
Я также предлагаю добавить ежедневное задание cron для автоматической фиксации в /.
Вы также должны исключить множество файлов, кеш, временные каталоги и т. Д., Иначе вы собираетесь заполнить свой репозиторий мусором.
Я бы рекомендовал обновить репозиторий системы контроля версий непосредственно на самом сервере. Я храню большую часть своей производственной конфигурации в репозитории инфраструктуры.
Похоже, вы пытаетесь перестроить решение. Не используйте символические ссылки, пусть они используют SVN в произвольных местах.
Хотя существуют SCM, которые могут хранить ссылки, я не знаю, чтобы какая-либо из систем SCM обрабатывала ссылки таким образом. И они не должны ИМХО! Что, если вы хотите работать с двумя разными ветвями одновременно и получить две копии, по одной для каждой ветки? (Это довольно обычное дело в моем опыте программирования проектов.) Они навредили бы друг другу, если бы каждый указывал на одни и те же файлы в другом месте на диске.
SCM обычно выделяют каталог, который принадлежит им. Это позволяет нескольким извлеченным репозиториям работать бок о бок без помех и очищает границу между файлами, управляемыми и не управляемыми SCM.
Вместо ссылок я бы построил решение на основе операций копирования и явного развертывания. Чтобы справиться с вашим случаем, я бы написал сценарии синхронизации между развернутыми местоположениями ваших сценариев и исходным каталогом, управляемым SCM (который я назову «репо»), чтобы вы могли обратно вносить изменения в свои сценарии на месте. в репо. Я бы также работал над простым в запуске сценарием развертывания (на основе Puppet?), Который копировал из репозитория в целевые местоположения для тестирования.
Хотя я согласен, что, вероятно, было бы лучше повторно обучить ваших разработчиков вносить правки в Subversion, но вы могли бы разумно взломать это без особых усилий.
Я бы начал с создания каталога или репозитория (в зависимости от того, что наиболее целесообразно в вашей среде), в котором есть подкаталог для каждого хоста, которым вы хотите управлять таким образом. Под этими каталогами поместите файлы, которыми вы хотите управлять в структурированном виде. Лично я бы сделал так:
per_host_confs/
host1/
etc/
cron.d/
foo
logrotate.d/
bar
var/
...
Затем добавьте задание cron (или добавьте правило марионетки), которое запускает скрипт, который проверяет текущий ствол соответствующего каталога хоста (переменная $ hostname будет полезна здесь, в вашем рецепте марионетки) в некоторый временный каталог, находит ли это каталог и копирует соответствующие файлы на место в рабочей копии, а затем фиксирует его.
Правило марионетки для повторного развертывания может делать что-то подобное и использовать время создания или проверки модификации, чтобы определить, когда отправлять файлы из рабочей копии / репозитория на локальный диск.
Можете ли вы сделать символические ссылки наоборот. Управляйте каталогом с помощью svn (скажем, /usr/local/scripts/), а затем скопируйте все свои скрипты в этот каталог (или подкаталоги) и поместите символическую ссылку в старое место. Затем, когда кто-то редактирует файл, они фактически редактируют файл в каталоге svn.
Если символьные ссылки не работают, вы можете использовать жесткие ссылки.
Как только вы это сделаете, вы можете попытаться поощрить своих сотрудников редактировать файлы в новом месте и постепенно стандартизировать новую структуру каталогов. В качестве поддержки у вас может быть задание cron, которое проверяет каждую ночь и отправляет вам электронное письмо, чтобы вы знали, кто не использует новую систему, чтобы вы могли дружески напомнить соответствующему человеку.