Какие решения по управлению конфигурацией существуют в не сетевой среде?
Мои серверы существуют в среде без подключения к внешней сети (это является обязательным требованием), поэтому при развертывании обновлений все пакеты, двоичные файлы, файлы конфигурации и т. Д. Должны быть включены в поставляемый носитель. И, конечно, я хочу какое-то управление конфигурацией, чтобы я мог сказать, что было и не было установлено.
Поэтому мне было интересно, есть ли у людей опыт работы с шеф-поваром, марионеткой или другим инструментом управления конфигурацией для работы с этим типом среды. В худшем случае я развертываю свои обновления как RPM.
РЕДАКТИРОВАТЬ:
В моей настройке есть как серверы Linux, так и серверы Windows.
4 ответа
Я лично использовал Puppet и cfEngine, которые, как оказалось, являются хорошими инструментами для такого рода задач, и я считаю, что они в настоящее время являются основными игроками в этой области. Puppet требует немного большей осторожности, когда вы начинаете пытаться масштабировать его, но имеет более приятный синтаксис, cfEngine хорошо масштабируется, но для изучения вуду может потребоваться немного больше времени. Если подключение к внешней сети не включает какие-либо другие серверы, которыми вы можете управлять, они оба могут кэшировать свой каталог / конфигурацию в случае, если они не могут получить доступ к главному серверу, являются их собственным главным сервером или работают только по требованию, поэтому они оба должны обрабатывать требование отсутствия сети. Если для них нормально добраться до сервера с внутренним управлением, это определенно не проблема.
Парень, с которым я работаю, ругается на bcfg2, но я с ним не работал. В настоящее время мы используем Puppet на моем рабочем месте, во что бы то ни стало.
У каждого есть свои сильные и слабые стороны, и ваш выбор должен во многом зависеть от любых других ваших требований. Здесь вы можете ознакомиться с базовыми сведениями о наиболее распространенных и более неясных вариантах, которые у вас есть.
Я предполагаю, что у вас есть большой кусок серверов, работающих в автономном режиме по соображениям безопасности (эти причины становятся все более и более распространенными). Столкнувшись с очень похожей ситуацией сам. Реальный ответ на вопрос зависит от того, как выглядит ваша архитектура.
Все обычные игроки (Chef, Puppet, CF-Engine, Salt, Annsible) будут работать в автономном режиме, однако некоторые вещи, которые обычно работают, не будут работать на вашем пути (например, требования к модулю автоматической загрузки кукол из выигранной кузницы) не работает). Однако в зависимости от того, какие версии программного обеспечения вы используете, есть обходные пути. Для Puppet (если вы используете v3) я бы предложил использовать r10k, чтобы помочь смягчить проблему (я полагаю, что в v4 она включена).
То, что @David сказал для марионетки, также очень хороший совет. Теперь, что бы вы ни использовали, я бы посоветовал следующее, что, как я обнаружил, сделает вашу жизнь намного проще:-
- Старайтесь избегать жесткого кодирования данных в конфигурацию (например, если вы используете марионетку - hiera).
- Делайте как можно больше dev в сетевой среде (таким образом, вам не нужно беспокоиться о проблемах с зависимостями при разработке
- Если вы можете использовать режим клиент-сервер для большинства систем, сделайте это, так как локальные режимы работы создают некоторую дополнительную сложность, и вам будет больно, если вы не сможете этого избежать.
- (Chef / Puppet) Если у вас есть локальный сервер репозитория, посмотрите, можете ли вы настроить его так, чтобы он служил кулинарным книгам / модулям вместо интернет-соединения (как вы это делали в Maven)
С точки зрения Windows (при условии, что вы используете последнюю версию) посмотрите на использование Windows DSC + Powershell, так как по крайней мере Chef и Puppet имеют кулинарные книги / модули, которые могут взаимодействовать с ним для настройки компонентов Windows (и всего, что вы можете делать с Powershell).).
Если это поможет, взгляните на мой ответ на мой вопрос здесь, так как это был один из "других" решающих факторов.
В целом вы будете оценивать каждый инструмент в соответствии с вашими потребностями, но в большинстве случаев я обнаружил, что, как представляется, существуют решения сообщества для решения любых проблем, которые могут смягчить любые возникающие у вас проблемы.
Я недавно играл с отключенным Puppet для удаленных сред, где у меня не может быть главного сервера. В частности, эта статья была полезна для меня, и, вероятно, ее стоит посмотреть, если вы решите пойти по пути Puppet.
Вы можете настроить нормальную структуру Puppet в / etc / puppet, а затем запустить Puppet вручную. До сих пор я не понял, насколько хорошими были бы ведение журнала и отчетность без мастера.
Это был мой лучший друг во время разработки / тестирования:
puppet -d -v --modulepath=/etc/puppet/modules /etc/puppet/manifests/site.pp
Соль позволяет вам предоставлять альтернативные места для ваших пакетов.
mypkgs:
pkg.installed:
- sources:
- foo: salt://rpms/foo.rpm
- bar: http://somesite.org/bar.rpm
- baz: ftp://someothersite.org/baz.rpm
- qux: /minion/path/to/qux.rpm
В этом примере эти пакеты будут установлены из указанного местоположения:
- foo будет установлен из rpm на файловом сервере Salt
- панель будет установлена из http местоположения
- Баз будет установлен из FTP-местоположения
- qux будет установлен из локальной файловой системы