Когда марионетка, шеф-повар или ansible являются простыми решениями, чем диспетчер пакетов?
] [] []... я установил OpenSSL 1.0.1h ...[
] [
]Да, но только заголовочную версию. Ваша библиотека по-прежнему []0.9.8e-fips-rhel5[], а не []1.0.1h[], как ваш заголовок. Вам нужно установить подходящую библиотеку для вашего заголовка.[
].
Похоже, что вы установили []OpenSSL 1.0.1h[] вручную, в то время как []0.9.8e-fips-rhel5[] кажется, что это rhel-версия. Вероятно, рил-версия была установлена через управление пакетами. Возможно, вам просто нужно удалить []0.9.8e[] через []yum remove openssl-libs[]. После этого проверьте, не обнаружены ли ваши библиотеки []OpenSSL 1.0.1h[] (я предполагаю, что вы установили заголовок + lib). Если нет, установите []OpenSSL 1.0.1h[]-libs (снова).[
Менеджер пакетов ни в коем случае не является заменой управления конфигурацией. Система управления конфигурациями может взаимодействовать с родным пакетным менеджером. Что касается подделки конфигураций в пакеты, этого будет достаточно только в том случае, если a) все ваши серверы будут иметь одинаковые конфигурации и b) для их конфигураций не требуется никаких внешних данных.
Рассмотрим базовую инфраструктуру. У вас есть внутреннее веб-приложение, но вы также используете веб-сервер для запуска программы отслеживания билетов (скажем, Redmine). Ваше внутреннее веб-приложение написано на PHP, но Redmine - это рубиновое приложение. Эти два различных веб-приложения будут иметь различные конфигурации apache. Если вы выпекаете конфигурации в пакеты, то это потребует от вас сборки двух пакетов apache, которые конфликтуют друг с другом, например, apache-internal и apache-redmine. Легко понять, как это может стать неуправляемым очень быстро.
Давайте посмотрим, как это будет выглядеть в марионеточном манифесте:
# internal PHP application
class { apache: }
# uses your OS package manager to install PHP
class {'::apache::mod::php':
package_name => "php54-php",
path => "${::apache::params::lib_path}/libphp54-php5.so",
}
# redmine
class { apache: }
# uses your OS package manager to install mod_passenger
class { apache::mod::passenger: }
apache::vhost { $::fqdn:
docroot => '/path/to/directory',
directories => [
{ path => '/path/to/directory',
passenger_enabled => 'on',
},
],
}
Другой основной пример - это наличие различных окружений в вашей инфраструктуре. То, что вы не можете сделать со статическими конфигурациями в менеджере пакетов, это шаблонные конфигурационные файлы. Если у вас есть среда разработки и производства, шаблоны позволяют вам писать конфигурации, которые говорят вашим приложениям подключиться к правильному источнику данных (например, к базе данных) или к конкретному окружению.
Наконец, кто будет добавлять свои собственные репозитории и устанавливать правильные пакеты на каждый хост? Это более ненужная поддержка, которая решается с помощью управления конфигурацией.
Я согласен с Джорданом, практическим примером того, как я использую puppet в моей компании, является то, что у нас есть локальные репозитории yum, поскольку вся наша инфраструктура основана на Centos. При создании новых серверов с нуля я могу выбрать манифест, который я предварительно настроил для создания сервера, например. Это может быть стек ламп, поэтому марионетка установит все необходимые RPM, чтобы обеспечить наличие всех правильных приложений. Но он также удалит любые системные службы, которые мне не нужны, изменит конфигурации, развернет правила iptable, установит учетные записи администраторов, настроит правила прокси и так далее. Любые системные изменения, которые я вношу, я делаю через марионетку, поэтому я никогда не забываю сделать их снова.
Как видите, марионетка используется не только для управления пакетами, она может построить целый сервер без взаимодействия с пользователем. Подумайте, если ваше оборудование выйдет из строя, сколько времени и сколько усилий потребуется для создания новой реплики.