Могут ли инструменты управления конфигурацией (Puppet, Chef) поддерживать установленные пакеты в актуальном состоянии?

Это, вероятно, простой вопрос для тех из вас, кто уже использует инструменты управления конфигурацией. Являются ли инструменты управления конфигурацией, такие как Puppet или Chef, правильным подходом для обновления установленных пакетов?

Предположим, я использую несколько серверов, в основном на основе Debian и Ubuntu. Средства управления конфигурацией облегчают обновление пакетов, установленных из репозиториев, когда появляются обновления безопасности или исправления ошибок?

В настоящее время я запускаю «автоматические обновления», чтобы позволить системам автоматически устанавливать обновления безопасности, но мне все равно приходится подключаться к серверам и запускать их aptitude update && aptitude safe-upgradeтак часто. Естественно, чем больше серверов, тем скучнее, утомительнее и подвержен ошибкам.

Являются ли такие инструменты, как Puppet или Chef, правильным подходом для обновления установленных пакетов? Кто-нибудь из вас использует эти инструменты, чтобы избежать запуска вручную aptitudeили аналогичного на 15 серверах? Я совершенно уверен, что ответ на эти вопросы "Да, конечно!"

Но где я могу найти больше информации об этом конкретном случае использования? У меня еще не было времени, чтобы углубленно изучить Puppet или Chef, и в примерах поваренных книг или классов показаны только более или менее тривиальные примеры установки одного конкретного пакета, такого как ssh. Есть ли у вас какие-либо ресурсы, чтобы рекомендовать, кроме официальной документации (я, конечно, собираюсь изучать документы, как только узнаю, какой из инструментов, если таковые имеются, мне подходит).

Puppet (я уверен, что шеф-повар тоже) связывается с вашими репозиториями программного обеспечения apt-get / yum . Поскольку они занимаются выяснением того, какие пакеты доступны, это означает, что ensure => latestэто работает только для Ubuntu / CentOS / Debian и тому подобное. Если вы правильно настроили соответствующие файлы ( /etc/apt/sources.listи т. Д.).

Вы можете сделать это с куклой, вы можете сделать:

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, библиотеки и т. Д.) И пакетов, критичных для безопасности.

После того, как вы это настроите (обычно вы можете просто зеркально отразить требуемые пакеты из репозитория upstream), вы можете использовать синтаксис Puppet «sure => latest», чтобы убедиться, что все ваши машины будут обновлены по репо.

Было бы разумно использовать «промежуточное» хранилище, чтобы вы могли тестировать обновленные версии пакетов, прежде чем без промедления развернуть их в производство. Это легко сделать с помощью Puppet без дублирования кода с помощью шаблонов репозитория.

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

Все эти советы в равной степени относятся к драгоценным камням Ruby, яйцам Python и другим системам пакетов, которые вы можете использовать.

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

В то время как Puppet / Chef являются возможными претендентами на эту функцию, для того, чтобы они обновляли все в системе, требуются либо пользовательские типы, либо список каждого пакета (включая базовые системные библиотеки, такие как libc6) в качестве ресурсов ensure => latest. В конкретном случае автоматических обновлений пакетов вы можете посмотреть на cron-aptпакет, который также делает то, что вы хотите.

Этот вопрос старый, но я думал, что отвечу самым современным образом, так как существующий в то время ответ был недоступен.

Если вы используете марионетку или шеф-повара, посмотрите на mcollective. Это очень хороший инструмент от ребят из puppetlabs, который позволяет отправлять команды группам серверов. http://docs.puppetlabs.com/mcollective/

Он также имеет подключаемый модуль apt, который можно использовать для обновления apt на любом количестве серверов: http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/AgentApt

Я понимаю, что уже немного поздно для вашего первоначального вопроса, но здесь это в духе «лучше поздно, чем никогда».

Я использую 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-upgrades для систем Ubuntu / Debian, или простой, но эффективный geerlingguy.security , который также охватывает RHEL / CentOS (и укрепляет конфигурацию SSH).

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

Общие обновления

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

В прошлом я видел aptitude safe-upgradeсерьезные проблемы на серверах, поэтому лучше не запускать это автоматически, тогда как обновления безопасности, как правило, достаточно безопасны.