Управление поваренными книгами шеф-повара в командной среде

Я учусь на шеф-повара и испытываю проблемы со структурированием всего, чтобы работать с моей командой.

Начнем с того, что вам следует создать папку chef-repo, в которой вы будете хранить и изменять поваренные книги, используемые для управления вашими узлами.

Я работаю над различными проектами, и каждый из них уже находится под контролем git source. В идеале я бы держал одну папку chef-repo в каждом из моих проектов с этими кулинарными книгами, верно?

Тем не менее, в папку chef-repo я должен добавить папку конфигурации (.chef) с конфигурацией моего ножа и проверкой ключей, и они специфичны для меня. Нормально ли просто добавить папку .chef в файл gitignore?

Я понимаю, что поваренные книги загружаются на сервер chef для последующего развертывания. Как другие команды отделяют промежуточную работу от производственной среды, не дублируя большую работу? У нас есть главная ветка, которая является нашей производственной веткой, ветка разработчика, которая является нашей промежуточной ветвью (получает менее 5% запросов веб-сайта) и функциональные ветки. Большую часть времени ветка dev, когда она стабильна, объединяется с веткой master. Как мы можем загружать кулинарные книги отдельно, чтобы иметь возможность разделить две среды?

Спасибо за помощь!

Я работаю с несколькими проектами, поэтому решение CJC не будет работать для меня. Существует также проблема общей конфигурации по сравнению с пользовательской конфигурацией (адреса и т. Д. Являются общими для компании, в конфигах также есть немного волшебства). Схема, на которой я наконец-то остановился, немного взломана, но удобна в использовании.

Вместо глобального ~/.chefя использую подкаталог '.chef' в chef-repo, который не хранится в git (он добавлен в .gitignore). У меня также есть config/knife.rbфайл, который зарегистрирован в Git и содержит общую конфигурацию. Это начинается с этого фрагмента:

root_dir = File.join(File.dirname(__FILE__), '..')
%w(knife-secrets.rb knife-local.rb).each do |conf_name|
  conf = File.join(root_dir, ".chef", conf_name)
  Kernel::load(conf) if File.exists? conf
end

Это загружает файлы, .chef/knife-local.rbсодержащие пользовательскую конфигурацию (в базовой версии это просто OPSCODE_USER='username'константа, которая используется позже, но может содержать любую конфигурацию ножа), и.chef/knife-secrets.rb которая содержит общие секреты (ключи AWS и т. Д.).

Ниже есть обычная конфигурация ножа, которая использует константы, определенные в этих файлах, например:

client_key               "#{root_dir}/.chef/#{OPSCODE_USER}.pem"

Таким образом, я добиваюсь стандартизации конфигурации ножей по всей компании, что, в свою очередь, означает, что любой фрагмент кода или вызов ножа, совместно используемый в вики, будет работать для всех. В самом ноже достаточно путаницы и магии - разные конфигурации только усугубят ситуацию. Кроме того, каждый получает выгоду от небольших магических фрагментов, таких как этот, чтобы knife sshиспользовать логин, настроенный в пользовательском~/.ssh/config

Также существует проблема с общими секретами: ключ проверки сервера chef, ключи AWS, хранящиеся в нем knife-secrets.rb, закрытый ключ ECH SSH, зашифрованные ключи пакета данных и т. Д. Мы определенно не хотим, чтобы они были сохранены в хранилище - или, фактически, в любом месте, где они не зашифрованы. Таким образом, мы распространяем эти файлы как.tar.gz файла, который GPG-зашифрован для всех в компании и передается через Dropbox.

Конфигурирование всего этого становится сложным, и я хочу, чтобы люди в команде на самом деле использовали это, так что есть последний элемент: rake initзадача, которая создает .chefкаталог, символические config/knife.rbссылки, chef-secrets.tgzфайл дешифрования и untars , удостоверяется, что личный ключ Opscode Platform пользователя находится и .chef/knife-local.rbработает правильно настроен, символические плагины ножа и устанавливает надлежащие права на каталог и файлы внутри. Эта задача настроена так, что ее можно многократно запускать в уже инициализированном репозитории (например, для обновления секретов или плагинов ножей).

Есть также вспомогательная задача, которая перепаковывает все секреты, шифрует tar-архив всем и копирует его в Dropbox, чтобы упростить добавление новых сотрудников или изменение секретов.

Относительно нескольких сред: у Chef есть функция, которая называется средой . Я еще не использовал его, но он должен делать то, что вам нужно. Вы также можете строго отделить производственную среду (чтобы у разработчиков не было ключей, которые каким-либо образом связаны с рабочей средой), имея две отдельные организации Hosted Chef или серверы Chef. В этом фрагменте knife.rb показано, как настроить нож по-разному в зависимости от извлеченной в данный момент ветки - вы можете использовать его для настройки среды, а также URL-адреса сервера шеф-повара. Существует также плагин ножа, называемый «ножевой поток» , обеспечивающий более полный рабочий процесс с двумя организациями.

Вам необходимо настроить два сервера Chef, один для производства и один для разработки. Причина в том, что ни один сервер Chef не может поддерживать разветвленную разработку; даже с окружающей средой.

Или вы можете отказаться от концепции сервера Chef и использовать chef-solo. Вы можете хранить свои кулинарные книги в Git. Вы можете ветвиться и сливаться. Вы можете игнорировать проблемы с учетными данными ножа, потому что вы больше не будете их использовать.

Вы не сможете использовать поиск ножей или пакеты данных **. Но некоторым людям эти функции все равно не нужны.

** Ну, вы вроде как можете: http://wiki.opscode.com/display/chef/Data+Bags#DataBags-UsingDataBagswithChefSolo

У меня дома есть два каталога: .chef и chef-repo. Шеф-репо в Git. .Chef - это какой-то личный каталог, используемый по умолчанию для ножа. Вам не нужно вкладывать свои секреты из .chef в git; нож будет искать ~ / .chef.

Ваша директория ~ / .chef не должна быть в git repo.

У меня есть каталог ~ / projects /, в котором я храню репозиторий Chef. В этом идет конфиги моих серверов.

Моя последняя работа была системным инженером в магазине Ruby-on-Rails. Наши конфиги nginx, varnish и rails (среди прочих) находятся в репозитории chef, но сами приложения Rails хранились в отдельных репозиториях git и разворачивались отдельно.

Нашей промежуточной средой был один сервер, на котором выполнялась вся промежуточная среда. Это не было идеальным, потому что это не было похоже на Production, где Rails тоньше, а DB были в отдельных коробках. То, что я бы порекомендовал, - это использовать среду Chef для разделения Staging и Production. (Вот так было, когда я туда попал, и у меня просто нет времени, чтобы это исправить, прежде чем я ушел.)