Я работаю с несколькими проектами, поэтому решение 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папку для использования переменных среды или что-то?