Назад | Перейти на главную страницу

Какие решения для управления конфигурацией существуют в несетевой среде?

Мои серверы существуют в среде без внешнего сетевого подключения (это требование), поэтому при развертывании обновлений все пакеты, двоичные файлы, файлы конфигурации и т. Д. Должны быть включены в доставленный носитель. И, конечно, мне нужно какое-то управление конфигурацией, чтобы я мог сказать, что было установлено, а что нет.

Поэтому мне было интересно, есть ли у людей опыт работы с Chef, Puppet или другим инструментом управления конфигурацией для работы с этим типом среды. В худшем случае я развертываю свои обновления как RPM.

РЕДАКТИРОВАТЬ:

В моей установке есть как серверы Linux, так и серверы Windows.

Я лично использовал Puppet, и cfEngine оказались хорошими инструментами для такого рода задач, и я считаю, что в настоящее время они являются основными игроками в этой области. Puppet требует немного больше внимания, когда вы начинаете пытаться масштабировать его, но имеет более приятный синтаксис, cfEngine хорошо масштабируется, но может потребоваться немного больше времени, чтобы изучить вуду. Если отсутствие подключения к внешней сети включает в себя любые другие серверы, которыми вы можете управлять, оба могут кэшировать свой каталог / конфигурацию в случае, если они не могут связаться с главным сервером, будучи их собственным главным сервером, или работать только по запросу, поэтому они оба должны обрабатывать требование отсутствия сети. Если для них нормально подключиться к серверу с внутренним управлением, это определенно не проблема.

Парень, с которым я работаю, клянется bcfg2, но я не работал с ним. В настоящее время мы используем Puppet на моем рабочем месте, чего бы это ни стоило.

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

Я предполагаю, что у вас есть большая часть серверов, работающих в автономной среде из соображений безопасности (эти причины становятся все более и более распространенными). Сам столкнулся с очень похожей ситуацией. Настоящий ответ на вопрос зависит от того, как выглядит ваша архитектура.

Все обычные игроки (Chef, Puppet, CF-Engine, Salt, Annsible) будут работать в автономной среде, однако некоторые вещи, которые обычно работают, не будут и будут мешать вам (например, требования к модулю автоматической загрузки марионеток из кузницы выиграли не работает). Однако в зависимости от того, какие версии программного обеспечения вы используете, есть обходные пути. Для Puppet (если вы используете v3) я бы предложил использовать r10k, чтобы помочь смягчить проблему (я считаю, что v4 уже включен).

То, что @David сказал о марионетке, тоже очень хороший совет. Независимо от того, что вы используете, я бы предложил следующее, которое, как я обнаружил, значительно облегчит вашу жизнь:

  • Старайтесь избегать жесткого кодирования данных в конфигурации (например, если вы используете марионетку, используйте hiera).
  • Делайте как можно больше разработчиков в сетевой среде (тогда вам не нужно беспокоиться о проблемах с зависимостями при разработке
  • Если вы можете использовать режим клиент-сервер для большинства систем, сделайте это, поскольку локальные рабочие режимы создают дополнительную сложность, которая вызывает боль, если вы не можете этого избежать.
  • (Chef / Puppet) Если у вас есть локальный сервер репозитория, посмотрите, сможете ли вы настроить его для обслуживания кулинарных книг / модулей вместо подключения к Интернету (как в случае с Maven)

С точки зрения Windows (при условии, что вы используете последнюю версию) взгляните на использование Windows DSC + Powershell, поскольку по крайней мере Chef и Puppet имеют кулинарные книги / модули, которые могут взаимодействовать с ними для настройки компонентов Windows (и всего остального, что вы можете делать с Powershell ).

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

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

Salt позволяет вам указать альтернативные места для ваших пакетов.

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-адреса
  • baz будет установлен из ftp-сервера
  • qux будет установлен из локальной файловой системы

Недавно я играл с отключенным Puppet для удаленных сред, где у меня нет главного сервера. В частности, Эта статья был мне полезен, и, вероятно, стоит поискать вас, если вы решите пойти по пути Марионеток.

Вы можете настроить обычную структуру Puppet в / etc / puppet, а затем запустить puppet вручную. Пока я не понял, насколько хороши были бы ведение журнала и отчетность без мастера.

Это был мой лучший друг во время разработки / тестирования:

puppet -d -v --modulepath=/etc/puppet/modules /etc/puppet/manifests/site.pp