Блог

Я относительно новичок в Chef и провожу проверку концепции, пытаясь использовать ее для создания веб-сервера. По причинам, выходящим за рамки этого вопроса, я буду создавать несколько экземпляров Apache, которые я могу захотеть как создать, так и «удалить». Тот же вопрос может действительно применяться к созданию и удалению конфигураций виртуального хоста в одном экземпляре Apache.

В настоящее время я использую chef-client для создания всех моих экземпляров Apache на основе определенных атрибутов для этого узла. Так, например, у меня могут быть атрибуты, определяющие Instance1 , Instance2 и Instance3 . На данный момент все работает просто отлично. Каталоги экземпляров создаются таким образом:

 /opt/local/apache/Instance1/stuff
/opt/local/apache/Instance2/stuff 
/opt/local/apache/Instance3/stuff
  

Каталоги содержимого и службы создаются с одним и тем же instancename идентификатором.

Проблема возникает, если я должен был, скажем, удалить Instance3 из атрибутов для этого узла. Мой запуск chef-client гарантирует, что Instance1 amp; Instance2 настроен правильно, но Instance3 останется, поскольку chef-client теперь ничего об этом не знает.

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

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

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

Это работает хорошо, но кажется хакерским, и я беспокоюсь, что это может быть антишаблоном. Концептуально, правильно ли я поступаю или мне следует делать что-то другое? Считается ли нормальным и правильным иметь пользовательский код Ruby в ваших рецептах для выполнения подобных действий?

Различие здесь обычно формулируется (с использованием терминов из Facebook Phil D) как «управляемые объекты» и «управляемая коллекция». Один template ресурс конвергентно управляет состоянием файла, но вам нужен ресурс (либо фактический пользовательский ресурс, либо просто концептуально), который представляет собой коллекцию всех файлов. Вы можете ознакомиться с zap кулинарной книгой для полуиспользуемой реализации этого, хотя она основана на интеллектуальном анализе коллекции ресурсов, а не на использовании атрибутов. Подходы к сбору данных, основанные на атрибутах, гораздо менее хрупки, чем zap поваренная книга, но также и более ограничены. Подход Facebook (т. Е. Основанный на атрибутах), вероятно, лучше всего иллюстрируется в их поваренной книге sysctl, https://github.com/facebook/chef-cookbooks/tree/master/cookbooks/fb_sysctl .

В этом случае это звучит так, как будто вы создаете глобус каталога и сравниваете его с данными атрибута, вероятно, правильный путь, но просто поймите, что иногда это может быть «сложно». Например, если вы установите атрибуты в коде рецепта, который происходит после этого глобуса, он не узнает об этом. Обычно это приводит к эскалации особых случаев, но, возможно, вы сможете сохранить порядок, и все будет в порядке 🙂