¿Alguien ha manejado alguna vez varios sistemas distribuidos geográficamente con Puppet?
Tengo varias implementaciones casi exactamente similares (excepto las IP del servidor), administración que estoy buscando convertir a Puppet.
Tengo 2 opciones:
Haga que cada implementación aloje su propio PuppetMaster para proporcionar configuraciones locales, luego sincronice de alguna manera los PuppetMasters (tal vez con Puppet nuevamente)
Hospede PuppetMaster en AWS EC2 para alta disponibilidad y proporcione configuraciones para todas las implementaciones desde un solo punto
¿Alguien ha probado la segunda opción y cómo funcionó? Estoy especialmente interesado en el rendimiento de alta disponibilidad en dicho entorno.
No hay nada malo con ninguno de los enfoques que propone. Tenemos tres titiriteros, todos ubicados en un solo sitio y que sirven nodos en todo el mundo; los separamos en función de si el nodo de la marioneta de conexión está en dev / test / prod. Otras personas prefieren ejecutar un titiritero por región geográfica. ¡Otras personas tienen muchos titiriteros, algunos solo manejan un nodo!
La clave es que es vital que almacene y administre su árbol de manifiesto de puppetmaster en un sistema de control de versiones; trátelo como cualquier otro código que mantenga su empresa. Recomiendo Git, pero Subversion también hará el truco si estás más acostumbrado a eso. Puppetmaster es simplemente un servicio que ofrece su visión particular de su VCS, en lugar de ser una base de datos central en sí misma.
Con su contenido en un VCS, puede implementar los manifiestos / módulos necesarios en los respectivos titiriteros y mantenerlos sincronizados fácilmente. La convención parece ser que la gente tiene un git / svn repo / module por puppet module, aunque no hay nada que le impida poner todo el árbol debajo de un repo / module.
Mis preguntas para usted serían:
¿Cuántos nodos hay en cada implementación? Si está hablando de más de 50, entonces valdría la pena tener un titiritero local seguro.
¿Las implementaciones tienen terceros que las usen además de su empresa? El puppetmaster debe tener una seguridad muy alta: considérelo como la llave de la puerta de todos sus sistemas y contendrá información muy confidencial.
Del mismo modo, para los PM basados en la implementación, ¿los alojaría en su propio servidor / VM o necesitaría una máquina existente para la tarea? Recomiendo encarecidamente que el servidor puppetmaster tenga ese rol solo, por seguridad.
¿Cómo espera que EC2 le brinde una mayor disponibilidad? Según tengo entendido, las instancias de EC2 no son HA, aunque debería ser posible ejecutar 2+ puppetmasters detrás del servicio de equilibrador de carga de AWS.
¿Son los despliegues muy diferentes? ¿Quieres cambiarlos en diferentes momentos del día? Múltiples titiriteros te dan un mejor nivel de control.
Hola. Hablando de 10-20 nodos como máximo en cada implementación, las implementaciones son en todo el mundo. No se permiten terceros dentro de las implementaciones. En realidad, estoy interesado en concentrar todos los datos relacionados con Puppet en una máquina dedicada, por lo que el PM se alojaría en la instancia EC2. Probablemente usaré Heartbeat + DRBD para la HA. Las implementaciones son básicamente los mismos dispositivos, ya que solo las IP del servidor son diferentes. Gracias de nuevo.
SyRenity
Parece mucho que un clúster de puppetmaster en EC2 probablemente haga el truco para ti. Solo asegúrate de usar Git o Subversion para almacenar tus manifiestos de manera segura :)
Mike Pountney
2
También podría usar un sistema sin Puppetmaster usando un VCS distribuido como Git, usando el esquema descrito aquí:
Si no tiene un puppetmaster, pierde el soporte de configuraciones almacenadas, que es una de las características más poderosas de Puppet. Piense en la recopilación de información entre máquinas integrada en las actualizaciones; por ejemplo, puede recopilar automáticamente información sobre la ejecución de servicios en todos los hosts (administrados por títeres) para generar reglas de firewall, reglas de enrutamiento, configuraciones de monitoreo, copias de seguridad basadas en extracción, etc.
David Gardner
Sí, ese es un punto justo. Ciertamente, hay ventajas de ejecutar un sistema completo basado en Puppetmaster, y generalmente lo hago. Sin embargo, puedo ver situaciones en las que un sistema muy ligero basado en VCS como este sería útil.
John Arundel
Si está optando por una configuración sin master, puede hacerlo y configurar el servidor puppetmaster para recibir solo el inventario de los facters; no tiene que estar muy disponible en ese momento.
timurb
0
También tenemos varios maestros de marionetas, diferentes entornos que sincronizamos. Para hacer esto, gestionamos todos nuestros módulos y manifiestos de títeres en subversión y luego implementamos los módulos de títeres en los titulares de títeres utilizando manifiestos de títeres regulares y un módulo llamado vcsdeploy que realiza la comprobación:
También podría usar un sistema sin Puppetmaster usando un VCS distribuido como Git, usando el esquema descrito aquí:
http://bitfieldconsulting.com/scaling-puppet-with-distributed-version-control
fuente
También tenemos varios maestros de marionetas, diferentes entornos que sincronizamos. Para hacer esto, gestionamos todos nuestros módulos y manifiestos de títeres en subversión y luego implementamos los módulos de títeres en los titulares de títeres utilizando manifiestos de títeres regulares y un módulo llamado vcsdeploy que realiza la comprobación:
http://www.practicalclouds.com/content/guide/pclouds-vcsdeploy-deploy-stuff
Cuando queremos sincronizar, etiquetamos una versión y luego actualizamos los node.pp para el titiritero.
Saludos
Dave
fuente