Управляйте поварскими книгами в коллективной среде

Я работаю с несколькими проектами, поэтому решение 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

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

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

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

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

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

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

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

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

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

Ваш каталог ~ / .chef не должен находиться в репозитории git.

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

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

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