Administre libros de cocina de chef en un entorno de equipo.

Estoy aprendiendo chef y tengo problemas para estructurar todo para trabajar con mi equipo.

Para empezar, parece que debe crear una carpeta chef-repo, donde almacenará y modificará los libros de cocina utilizados para administrar sus nodos.

Trabajo en varios proyectos, y cada uno de ellos ya está bajo el control de fuente de git. Lo ideal sería mantener una carpeta de repositorio de chef en cada uno de mis proyectos con los libros de cocina de ese proyecto, ¿verdad?

Sin embargo, en la carpeta chef-repo tengo que agregar una carpeta de configuración (.chef) con la configuración de mi cuchillo y mis validaciones clave, y estas son específicas para mí. ¿Es normal simplemente agregar la carpeta .chef al archivo gitignore?

Entiendo que los libros de cocina se cargan en el servidor del chef para luego ser implementados. ¿Cómo separan otros equipos la puesta en escena de los entornos de producción sin duplicar mucho trabajo? Tenemos una rama maestra que es nuestra rama de producción, una rama de desarrollo que es nuestra rama de preparación (recibe menos del 5% de las solicitudes del sitio web) y ramas de características. La mayoría de las veces, la rama de desarrollo cuando estable se fusiona con la rama maestra. ¿Cómo podemos cargar los libros de cocina por separado para poder tener dos entornos de forma separada?

¡Gracias por la ayuda!

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.

Debe configurar dos servidores Chef, uno para producción y otro para desarrollo. La razón es que ningún servidor Chef puede soportar el desarrollo ramificado; incluso con ambientes.

O puede abandonar el concepto de servidor Chef y usar chef-solo. Puedes mantener tus libros de cocina en Git. Puedes ramificar y fusionar. Puede ignorar los problemas con las credenciales de cuchillo porque ya no las usará.

No podrá utilizar la búsqueda de cuchillos o las bolsas de datos **. Pero algunas personas no necesitan esas características de todos modos.

** Bueno, puedes: http://wiki.opscode.com/display/chef/Data+Bags#DataBags-UsingDataBagswithChefSolo

Tengo dos directorios en mi casa, .chef y chef-repo. El chef-repo está en git. El .chef es un directorio privado que es el predeterminado para cuchillo. No tienes que poner tus secretos de .chef en git; cuchillo buscará ~ / .chef.

Su directorio ~ / .chef no debe estar en el repositorio git.

Tengo un directorio ~ / projects / en el que mantengo mi repositorio de chef. En esto van las configuraciones de mis servidores.

Mi último trabajo fue como ingeniero de sistemas en la tienda Ruby-on-Rails. Nuestras configuraciones nginx, barniz y rails (entre otras) van en el repositorio del chef, pero las aplicaciones Rails se mantuvieron en repositorios git separados y se implementaron por separado.

Nuestro entorno de ensayo era un único servidor que ejecutaba todo el entorno de ensayo. Esto no era ideal porque no se parecía a Producción donde Rails se adelgaza y el DB estaba en cajas separadas. Lo que recomendaría es usar los entornos del chef para separar la puesta en escena y la producción. (Así fue cuando llegué allí, y simplemente no tengo tiempo para arreglar eso antes de irme).