Я працюю з декількома проектами, тому рішення 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, щоб полегшити додавання нових співробітників або змінити секрети.
Щодо кількох середовищ: Шеф-кухар має функцію, яка називається середовищем . Я його ще не використовував, але він повинен робити все, що вам потрібно. Ви також можете суворо розділити виробниче середовище (щоб уникнути того, щоб розробники мали будь-які ключі, які так чи інакше стосуються виробництва env), маючи дві окремі організації з розміщеними шеф-кухарями або сервери шеф-кухарів. Цей фрагмент kni.rb показує, як налаштувати ніж по-іншому на основі перевіреної в даний час гілки - ви можете використовувати це для встановлення середовища, а також URL-адреси сервера шеф-кухаря. Існує також плагін для ножа, який називається "нож-потік" , що забезпечує більш повний робочий процес на дві організації.
.chefпапку для використання змінних середовища чи чогось іншого?