¿Hay alguna razón para usar Puppet junto con Docker?

Probé Ops parte de DevOps hace algún tiempo y fue bastante divertido, pero no tengo tiempo ni razón para probarlo en ningún proyecto. Pero la semana pasada comencé un nuevo trabajo, donde el jefe me preguntó si podía configurar el servidor para hacer algo así como un entorno provisional para proyectos de la empresa. Junto con eso, he comenzado a pensar en migrar proyectos para ser más DevOps en lugar de solo dev.

Salí con Docker, que es genial y muy fácil para mí. Pero hace un tiempo estaba probando Puppet, así que me vino a la mente la pregunta: "¿Hay alguna razón para usar Puppet with Docker?". Docker parece estar haciendo todo lo que Puppet haría, pero de una manera más fácil.

PD: Hace algún tiempo, en Hacker News había Consul, que es una buena configuración y descubrimiento de servicios, por lo que incluso la configuración se puede resolver (y estoy pensando en implementar esto también).

Puppet y docker pueden hacer muchas de las mismas cosas, sin embargo, se acercan a ellos de una manera diferente.

Puppet gestiona archivos + paquetes + servicios. (Llamado la trifecta). Docker encapsula binarios y archivos de configuración dentro de un contenedor.

Al momento de escribir esto, Docker todavía es inestable y no debe usarse en producción. Es probable que muchas de las API cambien hasta que se lance la versión 1.0.

Incluso cuando Docker se estabilice, será una gran tarea convertir cada proceso y archivo de configuración en contenedores Docker.

Puppet, por otro lado, es un producto estable y viene con todo un ecosistema de herramientas (heira, mcollective, facter, razor). Estas herramientas se pueden implementar rápidamente y sin preocuparse de que las cosas se rompan.

Sugeriría altamente los siguientes recursos.

Un video sobre cómo administrar las pilas de aplicaciones con títeres
https://www.youtube.com/watch?v=KSo_mcJxFIA

Un podcast sobre cómo Docker y el títere pueden trabajar juntos
http://devopscafe.org/show/2014/1/23/devops-cafe-episode-46.html

Un artículo de blog sobre títeres sobre cómo integrarse con Docker
http://puppetlabs.com/blog/building-puppet-based-applications-inside-docker

Otro artículo de blog sobre títeres y acopladores coexiste
http://puppetlabs.com/blog/can-containers-and-configuration-management-co-exist

Un módulo de marionetas para interactuar con docker
http://docs.docker.io/use/puppet/

Una corrección menor en la terminología de devops. Devops es más una metodología de desarrollo de software donde los desarrolladores y las operaciones cooperan, que cualquier herramienta específica.

Actualizar

Actualmente mi empresa utiliza marionetas y acopladores. Aquí hay una gran presentación dada en puppet conf 2014 sobre por qué usarías puppet vs docker. A cargo de James Turnbull, un ex empleador de puppetlabs y autor del libro docker.

https://puppetlabs.com/presentations/using-docker-puppet-james-turnbull-kickstarter

También un buen video tutorial breve sobre Docker dado por sysadmincasts.com

https://sysadmincasts.com/episodes/31-introduction-to-docker

Docker Pros:

• Puede girar la instancia rápidamente
• Más fácil de aprender que la marioneta
• Fácil de hacer 0 tiempo de inactividad

Contras de Docker:

• Los contenedores tienen un límite de 10 GB cuando se usa el backend de devicemapper
• Los pequeños cambios de configuración tardan mucho tiempo en reconstruir el contenedor
• Cuesta dinero usar un registro de docker como hub.docker.com, quay.io (el registro de docker autohospedado es extremadamente defectuoso y no tiene interfaz gráfica de usuario)
• No hay un sistema de inicio adecuado. Algunas aplicaciones no juegan bien.
• Sin control de grano fino sobre la red
• Las aplicaciones que requieren subcapas (mirándote RVM + ruby) son muy complicadas para que funcionen correctamente
• No se pueden administrar hosts de Windows, SLES u otros sistemas operativos menos populares
• Actualmente la orquestación de Docker es muy joven.
• Actualmente no puedo configurar su /etc/resolv.conf en el momento de la compilación
• Varios errores que tenemos que montar / etc / localtime y / dev / urandom para asignar a los directorios localtime y urandom de los hosts.
• El rendimiento no es tan rápido (a pesar de todas las afirmaciones de que el acoplador debe ser del 99% de la velocidad del metal desnudo, a veces es un 30% más lento que otras máquinas).
• Los contenedores pequeños aún tienen cientos de megabytes de carga. Nuestros contenedores son todos de varios gigabytes.

Profesionales de marionetas:

• Fácil de escalar
• Funciona con servidores existentes (windows, linux, sles)
• Rápido para hacer pequeños cambios
• Fuerte comunidad de otros usuarios y módulos de títeres
• API estandarizada para instalar paquetes en todas las plataformas

Contras de marionetas:

• Las grandes infraestructuras se vuelven muy complejas
• Las dependencias del módulo condicional crean código spagetti
• Más peso pesado

Actualmente utilizamos títeres para aprovisionar nuestros contenedores acoplables. Los contenedores acoplables se utilizan para compilaciones de jenkins y se destruyen después de cada compilación. Funciona bien y nos brinda un entorno constante. Eso significa que solo tenemos que escribir el código una vez, y luego reconstruir las máquinas ubuntu, sles y centos. La reconstrucción de los contenedores lleva entre 15 y 30 minutos y sigue siendo un proceso manual. Docker es ideal para girar vm de prueba rápida,

En resumen, Puppet es excelente para administrar su infraestructura existente. Docker es bueno si tiene un greenfield que es 100% Linux con una pila de tecnología que puede encerrarse en pequeñas instancias efímeras. Si bien algunas de las funcionalidades se superponen, no son mutuamente excluyentes.

Docker le ayuda a aprovisionar y configurar inicialmente los contenedores, pero ejecuta comandos únicos en la inicialización del contenedor.

Puppet es más fuerte cuando lo ejecuta como un demonio, asegura que su configuración se mantenga como la especifica, por lo que, por ejemplo, si el servicio deja de ejecutarse, lo iniciará nuevamente.

Una de las mejores cosas sobre la configuración de títeres (correctamente diseñada) es que son idempotentes ; se supone que describe el estado en el que desea estar y no necesariamente los pasos para llegar allí.

También le permite abstraer y parametrizar configuraciones y puede exportar parámetros creados en un servidor o contenedor y usarlos en otro (por ejemplo, recopilar una lista de nombres de host de nodos para una aplicación de monitoreo).

Diría que definitivamente tienen propósitos diferentes pero relacionados. Actualmente estoy mirando el uso de manifiestos de marionetas existentes para comenzar a configurar contenedores para que los entornos de desarrollo se parezcan más a los entornos de producción.