Шеф-повар - повторное выполнение рецепта

Question

Прежде всего, может (и это хорошая практика) шеф-повар запустить рецепт с заданным интервалом на определенную роль?

У меня есть рубиновый скрипт, который управляет учетными записями пользователей и идентификаторами ssh, он в настоящее время работает на cron каждый час, и я хотел бы превратить его в рецепт шеф-повара по понятным причинам (я хочу, чтобы он был там на все машины).

Я вижу два способа сделать это:

Либо превратить скрипт в шаблон, рецепт просто вынести шаблон для заданного пути, а затем зарегистрировать cronjob

ИЛИ

Разбейте скрипт на ресурсы, провайдеры и т. Д., И пусть шеф-повар запускает его каждый час.

Идеи?

Answer 1

Вы можете запустить шеф-клиент в качестве демона (опция -d, как он используется в сценариях инициализации), или под инструмент управления услугами, как upstart, runit/daemontools или BluePill. Вы также можете запустить его из cron - просто убедитесь, что там не запущен режим демонов :).

Поставщики ресурсов шеф-повара принимают идемпотентные действия, чтобы настроить ресурсы в желаемом состоянии. Это означает, что если Chef уже работает в системе, он только изменяет ресурсы, если они не соответствуют тому, что говорит рецепт. Например, если у вас есть рецепт, который говорит:

package "haproxy" 

service "haproxy" do 
    action [:enable, :start] 
end 

template "/etc/haproxy/haproxy.cfg" do 
    source "haproxy.cfg.erb" 
end 

пакет будет установлен в первый раз бежит шеф и не будет изменен снова, если пакет не были удалены из системы, или изменить ресурс. Аналогично, служба haproxy будет включена (через инструменты управления сервисами вашей платформы, обычно символические ссылки в /etc/rc*.d), а затем запускается (например, через /etc/init.d/haproxy start). Наконец, только если содержимое шаблона изменится, шеф-повар сделает новую версию шаблона. Для шаблонов он определяет это на основе контрольной суммы SHA256.

Существует несколько исключений - ресурсы execute, script и ruby_block не являются идемпотентными, если вы не предоставили какой-либо условный критерий.

Кроме того, при использовании сервера у шеф-повара нет списков рецептов «один раз» или «один». Недавно была затронута тема thread on the Chef mailing list.

Answer 2

Оба варианта возможны.
Ваших вариантов вы упомянули, были:

1)

превратить сценарий в шаблон, рецепт просто вынести шаблон для заданного пути , а затем зарегистрировать cronjob

Это легко начать (без изменений в вашем сценарии, он просто гарантирует, что он есть)

Помните, что шеф-повар выполняет каждый рецепт каждый раз ... Как сказал jtimberman: «он только модифицирует ресурсы, если они не соответствуют рецепту». Таким образом, ваш рецепт должен просто перезаписывать новый шаблон при его изменении.

ИЛИ 2)

Разбейте сценарий на ресурсы, провайдеров и т.д., и есть повар запустить его каждый час.

Этот вариант более похож на шеф-повар, и, вероятно, более надежный и масштабируемый - особенно, поскольку вы добавляете больше инфраструктуры под управление шеф-поваром.

Это будет отлично работать, если ваш клиент-шеф-повар будет демоннизирован, или шеф-повар будет работать на cron.

В этом случае вы можете настроить рецепт, используя ресурсы, такие как «пользователь», «группа» и «файл» (для копирования ключей ssh). См. Здесь для деталей: http://wiki.opscode.com/display/chef/Resources#Resources-File

Тогда вам лучше всего использовать «сумку данных» (данные json) для хранения сведений о пользователе и установки на них пользователей. Это именно то, что Opscode сделали в этом рецепте (смотрите в ./recipe/sysadmins.rb для вдохновения): https://github.com/opscode/cookbooks/tree/master/users

Просто надо знать, что они используют шеф-сервер (или Opscode платформы). Если вы используете chef-solo, вам нужно будет заменить «search (: users,« groups: sysadmin ») своим собственным файлом мешков с данными, найденным где-то поваром-шеф-поваром можно получить (загружаемый или в вашем шеф-поваре -repo).