Trabajo con múltiples proyectos, por lo que la solución de cjc no funcionará para mí. También hay un problema de configuración común frente a personalizada (las direcciones, etc. son comunes para la empresa, también hay un poco de magia en las configuraciones). El esquema que finalmente decidí es un poco pirateado, pero es conveniente de usar.
En lugar de global ~/.chef, uso el subdirectorio '.chef' dentro de chef-repo, que no se almacena en git (se agrega a .gitignore). También tengo un config/knife.rbarchivo que está registrado en Git y contiene configuración compartida. Comienza con este fragmento:
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
Esto carga archivos que .chef/knife-local.rbcontienen una configuración personalizada (en la versión básica es solo OPSCODE_USER='username'constante que se usa más adelante, pero puede contener cualquier configuración de cuchillo) y .chef/knife-secrets.rbque contiene secretos compartidos (claves de AWS, etc.).
Debajo de eso, hay una configuración de cuchillo regular que usa constantes definidas en estos archivos, por ejemplo:
client_key "#{root_dir}/.chef/#{OPSCODE_USER}.pem"
De esta manera, logro la estandarización de la configuración de cuchillo en toda la empresa, lo que a su vez significa que cualquier fragmento de código o invocación de cuchillo compartido en un wiki funcionará para todos. Hay suficiente confusión y magia en el cuchillo mismo: las diferentes configuraciones solo lo empeorarían. Además, todos se benefician de pequeños fragmentos mágicos, como este para hacer knife sshuso del inicio de sesión configurado en el usuario~/.ssh/config
También hay un problema de secretos compartidos: clave de validación del servidor del chef, claves de AWS almacenadas knife-secrets.rb, clave privada SSH de EC2, claves de bolsa de datos cifradas, etc. Definitivamente no queremos que se almacenen en el repositorio, o, en realidad, en cualquier lugar donde no estén encriptados de manera segura. Por lo tanto, distribuimos esos archivos como un .tar.gzarchivo, que está cifrado con GPG para todos en la empresa, y se comparte a través de Dropbox.
La configuración de todo esto se está volviendo complicada, y quiero que la gente del equipo realmente use la cosa, por lo que está el elemento final: la rake inittarea que crea el .chefdirectorio, los enlaces simbólicos config/knife.rballí, descifra y elimina el chef-secrets.tgzarchivo, asegura que la clave privada de la plataforma Opscode de los usuarios esté allí y .chef/knife-local.rbesté correctamente configurado, conecta enlaces simbólicos y establece los permisos adecuados en el directorio y los archivos que contiene. Esta tarea está configurada para que sea seguro ejecutarla muchas veces en el repositorio ya inicializado (por ejemplo, para actualizar secretos o complementos de cuchillo).
También hay una tarea auxiliar que vuelve a empaquetar todos los secretos, encripta el tarball para todos y lo copia en Dropbox, para que sea más fácil agregar nuevos empleados o cambiar los secretos.
Con respecto a los entornos múltiples: Chef tiene una característica llamada entornos . Todavía no lo he usado, pero debería hacer lo que necesita. También puede separar estrictamente el entorno de producción (para evitar que los desarrolladores tengan claves relacionadas de alguna manera con el entorno de producción) al tener dos organizaciones de Hosted Chef o servidores de Chef separados. Este fragmento de cuchillo.rb muestra cómo configurar el cuchillo de una manera diferente según la rama actualmente desprotegida; puede usar esto para configurar el entorno y la URL del servidor del chef. También hay un complemento de cuchillo llamado cuchillo-flujo , que proporciona un flujo de trabajo más completo de dos organizaciones.
.chefcarpeta para usar variables de entorno o algo así?