¿Por qué no usar la herramienta de administración de configuración en lugar de Dockerfile?

Soy bastante nuevo en Docker y en las herramientas de administración de configuración.

Al principio comencé a escribir scripts de bash para aprovisionar mis cajas Vagrant para mis máquinas de desarrollo, pero ahora he cambiado a usar Chef para eso, de modo que pueda usar la misma fuente para aprovisionar entornos de desarrollo y producción para tratar de obtenerlos como similares como sea posible.

Desde que comencé a usar Chef, he llegado a disfrutar el aspecto SECO de no tener que copiar y pegar líneas de script de shell de proyecto a proyecto, la capacidad de aprovisionar máquinas que ejecutan una variedad de distribuciones de Linux utilizando una fuente consolidada, y la conveniencia de usar libros de cocina proporcionados por la comunidad.

Ahora que he estado usando Chef para aprovisionar mis VM, parece que retrocedo un paso cuando agrego comandos RUN seguidos de comandos de shell a un Dockerfile para lograr lo que se puede lograr simplemente ejecutando una receta de Chef.

Busqué en Google y no encontré nada (pero tal vez me lo perdí), pero no parece que haya una manera fácil de usar recetas de Chef para construir contenedores Docker. ¿Porqué es eso?

Entiendo que los contenedores están destinados a ser inmutables y que las herramientas de administración de configuración se usan comúnmente para reconfigurar máquinas durante toda su vida útil, pero ¿no ofrecerían aún muchos beneficios si se usan durante la construcción inicial del contenedor?

La herramienta que necesita es Packer usando Docker como "constructor" y Chef como "aprovisionador". Luego puede agregar la imagen resultante a su repositorio y reutilizarla sin tener que empacar nuevamente, hasta que cambien sus recetas.

Estas estrategias no tienen nada que ver entre sí.

Los contenedores (como Docker) son una metodología para implementar y aislar aplicaciones. Los contenedores son muy apreciados porque son transportables. Se pueden desarrollar y previsualizar localmente en la mayoría de los casos, por lo que tiene sentido colocar aplicaciones en ellos.

En cuanto a por qué Docker usa scripts de shell : una imagen de Docker es literalmente una imagen de contenedor de Linux. Es un sistema operativo Linux y el objetivo de ese contenedor es ser lo más ligero y eficiente posible. Si comenzaste a agregar Chef, Ruby, Erlang y todas las demás bibliotecas necesarias para tener Chef como aprovisionador en un Dockerfile, estarías eliminando el punto de usar contenedores.

Configuration Management es para aprovisionar un nodo de proceso. El estado final de su configuración generalmente se refleja en el código y tiene un servidor central para mantener el estado. Herramientas como vagrant le permiten usar chef para configurar máquinas Vagrant, en gran medida por conveniencia para los desarrolladores. Si bien puede usar la mayoría de estas herramientas en un modo solo local , el mantenimiento de las mismas se vuelve bastante pesado. Esos servidores centrales son para cosas como clasificar automáticamente el control de versiones y la gestión de dependencias.

Bash no es inherentemente un paso atrás. Por ejemplo, muchas organizaciones que construyen canales de imágenes totalmente inmutables construyen sus imágenes usando Bash. Esto garantiza la estabilidad y la previsibilidad, así como un lenguaje común entre los ingenieros (muchos ingenieros pueden provenir de diferentes entornos de gestión de configuración).

Gestión inmutable frente a configuración . La infraestructura inmutable no cambia y debe reemplazarse por completo para poder actualizarse. Config Management implica que el estado de una máquina es mantenido por un agente o una conexión externa (como con Ansible).

Los contenedores Docker son inherentemente inmutables. No se conservan datos sobre ellos y se deben enrollar para poder actualizarlos.