Вероятно, это простой вопрос для тех из вас, кто уже использует инструменты управления конфигурацией. Подходят ли инструменты управления конфигурацией, такие как Puppet или Chef, для поддержания установленных пакетов в актуальном состоянии?
Предположим, у меня есть несколько серверов, в основном на основе Debian и Ubuntu. Упрощают ли инструменты управления конфигурацией обновление пакетов, установленных из репозиториев, при появлении обновлений безопасности или исправлений ошибок?
Я сейчас бегу "автоматические обновления" чтобы позволить системам автоматически устанавливать обновления безопасности, но мне все равно нужно подключиться к серверам и запустить aptitude update && aptitude safe-upgrade время от времени. Естественно, чем больше серверов, тем больше это становится скучным, утомительным и подверженным ошибкам.
Являются ли такие инструменты, как Puppet или Chef, правильным подходом к обновлению установленных пакетов? Кто-нибудь из вас использует эти инструменты, чтобы избежать ручного запуска aptitude или аналог на 15 серверах? Я совершенно уверен, что ответ на эти вопросы - «Да, конечно!»
Но где я могу найти дополнительную информацию об этом конкретном варианте использования? У меня еще не было времени на углубленное изучение Puppet или Chef, а примеры кулинарных книг или классов показывают только более или менее тривиальные примеры установки одного конкретного пакета, такого как ssh. Есть ли у вас какие-либо ресурсы, которые можно порекомендовать, кроме официальной документации (я, конечно, собираюсь изучить документацию, как только узнаю, какие инструменты подходят мне, если таковые имеются).
Вы можете сделать это с марионеткой, вы либо:
ensure => latest,
или
ensure=> "1.0.2",
указать последнюю / требуемую версию. т.е.
package { apache2: ensure => "2.0.12-2" }
package { apache2: ensure => latest }
Это, по крайней мере, означает, что вы можете указать одну и ту же версию для всех систем, а также предотвратить автоматическое (потенциально опасное) обновление серверов. Я использовал этот метод в производстве на нескольких сайтах, и он очень хорошо работает.
Запуск автоматических обновлений меня немного пугает, особенно если они обновляют критически важные пакеты, ядра, библиотеки mysql, apache и т. Д. Особенно, если скрипт установки может захотеть перезапустить службу!
Думаю, это, наверное, неправильный вопрос. Безусловно, использование инструментов управления конфигурацией, таких как Puppet и Chef, для обслуживания вашей инфраструктуры - это огромный шаг вперед по сравнению с попыткой делать все это вручную. Ни один из этих инструментов напрямую не решает проблему поддержания актуальности и синхронизации версий вашего пакета. Чтобы правильно автоматизировать это, вам нужно взять под свой контроль сами репозитории пакетов.
Я делаю это так, чтобы поддерживать выделенное репозиторий Yum (для Redhat / Fedora / CentOS; репозиторий APT для Debian / Ubuntu), который содержит пакеты, которые мне нужны для определенного сайта. Как правило, это будут зависимости самого приложения (Ruby, PHP, Apache, Nginx, библиотеки и т. Д.) И пакетов, критичных для безопасности.
После того, как вы настроили эту настройку (обычно вы можете просто отразить необходимые пакеты из исходного репозитория для начала), вы можете использовать синтаксис Puppet «sure => latest», чтобы убедиться, что все ваши машины будут обновлены с репо.
Было бы разумно использовать «промежуточное» репо, чтобы вы могли тестировать обновленные версии пакетов перед их беззаботным развертыванием в производственной среде. Это легко сделать с помощью Puppet без дублирования кода с помощью шаблонов репозитория.
Автоматизация управления версиями вашего пакета настоятельно рекомендует вам синхронизировать все ваши производственные системы, так как поддержка нескольких репозиториев и пакетов для разных дистрибутивов ОС, версий и архитектур компьютеров занимает очень много времени и может привести к разного рода неясным проблемам и несовместимости.
Все эти советы в равной степени применимы к драгоценным камням Ruby, яйцам Python и другим системам пакетов, которые вы можете использовать.
Я немного написал Кукольный учебник что должно помочь вам быстро приступить к работе с Puppet. Вы можете развернуть собственное определение репозитория на своих машинах, используя Puppet в качестве первого шага к контролю над версиями пакетов.
Марионетка (я уверен, что шеф-повар тоже) связана с вашим apt-get/ням программные репозитории. Поскольку они делают тяжелую работу по выяснению того, какие пакеты доступны, это означает ensure => latest просто работает для Ubuntu / CentOS / Debian и т.п. Если вы правильно настроили соответствующие файлы (/etc/apt/sources.list, и т.д).
Это старый вопрос, но я подумал, что отвечу в актуальном виде, так как в то время существующий ответ был недоступен.
Если вы используете куклу или повар, загляните в mcollective. Это очень хороший инструмент от разработчиков puppetlabs, который позволяет отправлять команды группам серверов. http://docs.puppetlabs.com/mcollective/
В нем также есть плагин apt, который можно использовать для обновления на любом количестве серверов: http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/AgentApt
Хотя Puppet / Chef являются возможными претендентами на эту функциональность, чтобы заставить их все в системе для обновления требуются либо пользовательские типы, либо перечисление каждого пакета (включая базовые системные библиотеки, такие как libc6) как ресурсы с ensure => latest. В конкретном случае автоматических обновлений пакетов вы можете изучить cron-apt пакет, который тоже делает то, что вы хотите.
Я понимаю, что это немного поздно для вашего первоначального вопроса, но здесь он в духе «лучше поздно, чем никогда».
Я использую Cfengine 3 для этого на нескольких серверах. Я указываю явный список пакетов для автоматического обновления, чтобы избежать обновления все пакеты, не проявляя к этому особого внимания. Он отлично работает, а cfengine 3 очень легкий.
Вот фрагмент обещания из моей конфигурации cfengine:
packages: "apache2" package_method => "apt", package_policy => "update";
Надеюсь это поможет.
Я согласен с Джонатаном. Подход Cfengine 3 хорош тем, что вы можете контролировать все аспекты управления пакетами без необходимости перекодировать на низком уровне.
Мы используем puppet + apt-dater.
Вы также можете использовать инструменты управления пакетами, такие как Canonicals Landscape, который предназначен для управления и мониторинга систем Ubuntu / Debian. Он управляет несколькими системами, позволяет обновлять их одновременно и предоставляет некоторые базовые возможности мониторинга.
Обычно я считаю, что проще всего использовать Ansible или аналогичный для настройки надежного автоматические обновления пакет для Ubuntu / Debian (или yum-cron для RHEL / CentOS). Вы можете использовать Puppet, Chef или другие инструменты, но я буду обсуждать здесь Ansible.
unattended-upgrades при желании можно использовать для одновременного выполнения обновлений, не связанных с безопасностью, что намного проще, чем запускать команду через Ansible каждый день.
unattended-upgrades заботится об автоматических обновлениях каждый день и обычно ограничивается только обновлениями безопасности (для повышения стабильности). Если серверу требуется перезагрузка после обновления, этот инструмент может автоматически перезагрузиться в определенное время.
Если ваши перезагрузки более сложные, unattended upgrades может писать вам по электронной почте, а также создает /var/run/reboot-required, чтобы Ansible (или аналогичный) мог управлять перезагрузками в подходящее время (например, скользящие перезагрузки кластера веб-серверов или серверов БД, чтобы избежать простоев, ожидая, пока каждый сервер станет доступным на определенном TCP-порту, прежде чем продолжить).
Вы можете использовать роли Ansible, такие как jnv.unattended-updates для систем Ubuntu / Debian или простой, но эффективный geerlingguy.security, который также охватывает RHEL / CentOS (и укрепляет конфигурацию SSH).
Если быстрые обновления безопасности менее важны, вы можете сначала протестировать их на менее важных серверах и запустить unattended-upgrade как только тесты показывают, что проблем нет - однако, по моему опыту, исправления безопасности, ориентированные на сервер, вызывают проблемы довольно редко.
Обновления, отличные от безопасности, должны проходить обычный процесс непрерывной интеграции и тестирования, чтобы гарантировать, что что-то не сломается.
Я видел aptitude safe-upgrade вызывать серьезные проблемы на серверах в прошлом, поэтому лучше не запускать это автоматически, тогда как обновления безопасности, как правило, вполне безопасны.