Voy a orientar esta respuesta como si la pregunta fuera "cuáles son las ventajas del chef solo" porque esa es la mejor manera que conozco para cubrir las diferencias entre los enfoques.
Mi resumen de recomendación está en línea con otros: use un chef-servidor si necesita administrar un entorno dinámico y virtualizado donde agregará y eliminará nodos con frecuencia. Un servidor de chef también es un buen CMDB , si lo necesita. Use chef-solo si tiene un entorno menos dinámico donde los nodos no cambiarán con demasiada frecuencia, pero los roles y las recetas lo harán. El tamaño y la complejidad de su entorno es más o menos irrelevante. Ambos enfoques escalan muy bien.
Si implementa chef-solo, use un cronjob con rsync, 'git pull' o algún otro mecanismo idempotente de transferencia de archivos para mantener una copia completa del repositorio de chef en cada nodo. El cronjob debería ser fácilmente configurable para (a) no ejecutarse en absoluto y (b) ejecutarse, pero sin sincronizar el repositorio local. Agregue un directorio / nodos en su repositorio de chef con un archivo json para cada nodo. Su cronjob puede ser tan sofisticado como desee en términos de identificación del archivo de nodo correcto (aunque recomendaría simplemente $ (hostname -s) .json. También puede crear una cuenta de código de operación y configurar un cliente con el chef alojado, si es por No hay otro motivo que no sea poder usar Knife para descargar libros de cocina comunitarios y crear esqueletos.
Este enfoque tiene varias ventajas, además de la obvia "no tener que administrar un servidor". Su control de origen será el árbitro final de todos los cambios de configuración, el repositorio incluirá todos los nodos y listas de ejecución, y cada servidor que sea completamente independiente facilita algunos escenarios de prueba convenientes.
Chef-server presenta un agujero en el que usa la "carga de cuchillo" para actualizar un libro de cocina, y debe parchear este agujero usted mismo (como con un gancho posterior a la confirmación) o arriesgarse a que los cambios en el sitio sean sobrescritos en silencio por alguien que "carga el cuchillo" s una receta obsoleta del repositorio local obsoleto en su computadora portátil. Es menos probable que esto suceda con chef-solo, ya que todos los cambios se sincronizarán con los servidores directamente desde el repositorio principal. El problema aquí es la disciplina y el número de colaboradores. Si eres un desarrollador en solitario o un equipo muy pequeño, subir libros de cocina a través de la API no es muy arriesgado. En un equipo más grande puede ser si no pones buenos controles en su lugar.
Además, con chef-solo puede almacenar todos los roles, atributos personalizados y listas de ejecución de sus nodos como archivos node.json en su repositorio principal de chef. Con chef-server, los roles y las listas de ejecución se modifican sobre la marcha utilizando la API. Con chef-solo, puede rastrear esta información en el control de revisión. Aquí es donde se puede ver claramente el conflicto entre entornos estáticos y dinámicos. Si su lista de nodos (no importa cuánto tiempo sea) no cambia a menudo, tener estos datos en el control de revisión es muy útil. Por otro lado, si frecuentemente genera nuevos nodos y destruye los antiguos (nunca volverá a ver su nombre de host o fqdn) mantener todo bajo control de revisión es simplemente una molestia innecesaria, y tener una API para hacer cambios es muy conveniente. Chef-server tiene todas las características orientadas a la gestión de entornos dinámicos en la nube, como la opción de nombre en "bootstrap de cuchillo" que le permite reemplazar fqdn como la forma predeterminada de identificar un nodo. Pero en un entorno estático, esas características tienen un valor limitado, especialmente en comparación con tener los roles y las listas de ejecución en el control de revisión con todo lo demás.
Finalmente, los entornos de prueba de recetas se pueden configurar sobre la marcha para casi ningún trabajo adicional. Puede deshabilitar los cronjobs que se ejecutan en un servidor y realizar cambios directamente en su repositorio local. Puede probar los cambios ejecutando chef-solo y verá exactamente cómo se configurará el servidor en producción. Una vez que todo se haya probado, puede registrar los cambios y volver a habilitar los cronjobs locales. Sin embargo, al escribir recetas, no podrá utilizar la API "Buscar", lo que significa que si desea escribir recetas dinámicas (por ejemplo, equilibradores de carga) tendrá que hackear esta limitación, reuniendo los datos de los archivos json en su directorio / nodos, que probablemente sea menos conveniente y carecerá de algunos de los datos disponibles en la CMDB completa. Una vez más, los entornos más dinámicos favorecerán el enfoque basado en bases de datos, entornos menos dinámicos estarán bien con archivos json en el disco local. En un entorno de servidor donde un chef debe ejecutar llamadas API a una base de datos central, dependerá de administrar todos los entornos de prueba dentro de esa base de datos.
El último también se puede usar en emergencias. Si está solucionando un problema crítico en los servidores de producción y lo resuelve con un cambio de configuración, puede realizar el cambio inmediatamente en el repositorio del servidor y luego enviarlo al servidor principal.
Esas son las principales ventajas de chef-solo. Hay algunos otros, como no tener que administrar un servidor o pagar por un chef alojado, pero esas son preocupaciones relativamente menores.
En resumen: si usted es dinámico y altamente virtualizado, chef-server ofrece una serie de excelentes características (cubiertas en otro lugar) y la mayoría de las ventajas de chef-solo serán menos notables. Sin embargo, hay algunas ventajas definidas, a menudo no mencionadas, para chef solo, especialmente en entornos más tradicionales. Tenga en cuenta que implementarse en la nube no significa necesariamente que tenga un entorno dinámico. Si no puede, por ejemplo, agregar más nodos a su sistema sin lanzar una nueva versión de su software, probablemente no sea dinámico. Finalmente, desde una perspectiva de alto nivel, un CMDB puede ser útil para cualquier cantidad de cosas solo relacionadas tangencialmente con la administración y configuración del sistema, como la contabilidad y el intercambio de información entre equipos. Usar chef-server podría valer la pena solo por esa característica.