¿Qué NO debe ser gestionado por la marioneta?

Estoy aprendiendo mi camino a través de la gestión de la configuración en general y usando Puppet para implementarlo en particular, y me pregunto qué aspectos de un sistema, si los hay, no deberían gestionarse con Puppet.

Como ejemplo, generalmente damos por sentado que los nombres de host ya están configurados antes de prestar el sistema a la administración de Puppet. La conectividad IP básica, al menos en la red utilizada para llegar al puppetmaster, tiene que estar funcionando. Usar la marioneta para crear automáticamente archivos de zona dns es tentador, pero los punteros inversos de DNS ya deberían estar en su lugar antes de comenzar la cosa o los certificados serán divertidos.

Entonces, ¿debo dejar de lado la configuración de IP de Puppet? ¿O debería configurarlo antes de iniciar Puppet por primera vez pero administrar direcciones IP con Puppet de todos modos? ¿Qué pasa con los sistemas con múltiples IP (por ejemplo, para WAN, LAN y SAN)?

¿Qué hay de IPMI ? Puede configurar la mayoría, si no todos, con ipmitool , evitando que obtenga acceso a la consola (física, serial-over-lan, KVM remoto, lo que sea) para que pueda automatizarse con puppet. Pero volver a verificar su estado en cada ejecución de agente de marionetas no me parece genial, y el acceso básico al sistema de luces apagadas es algo que me gustaría tener antes de hacer cualquier otra cosa.

Otra historia completa es sobre la instalación de actualizaciones. No voy a entrar en este punto específico, ya hay muchas preguntas sobre SF y muchas filosofías diferentes entre diferentes administradores de sistemas. Yo mismo, decidí no permitir que Puppet actualizara las cosas (por ejemplo, solo ensure => installed) y las actualizara manualmente como ya estamos acostumbrados, dejando la automatización de esta tarea para un día posterior cuando tengamos más confianza con Puppet (por ejemplo, agregando MCollective a la mezcla).

Esos fueron solo un par de ejemplos que ahora tengo en mi mente. ¿Hay algún aspecto del sistema que deba dejarse fuera del alcance de la marioneta? O, dicho de otra manera, ¿dónde está la línea entre lo que debe configurarse en el momento del aprovisionamiento y la configuración "estática" en el sistema, y ​​lo que se maneja a través de la administración de configuración centralizada?

Regla general: si está utilizando la administración de la configuración, administre todos los aspectos de la configuración que pueda. Cuanto más centralice, más fácil será escalar su entorno.

Ejemplos específicos (incluidos en la pregunta, todas las narraciones de "Esta es la razón por la que desea gestionarlo"):

Configuración de red IP

OK, claro, configuró una dirección / puerta de enlace / NS en la máquina antes de colocarla en el bastidor. Quiero decir, si no lo hicieras, ¿cómo ejecutarías Puppet para hacer el resto de la configuración?

Pero supongamos que ahora agrega otro servidor de nombres a su entorno y necesita actualizar todas sus máquinas. ¿No desea que su sistema de administración de configuración lo haga por usted?

O supongamos que su empresa es adquirida y su nueva empresa matriz exige que cambie de su dirección 192.168.0.0/24 a 10.11.12.0/24 para que se ajuste a su sistema de numeración.

O de repente obtienes un contrato masivo con el gobierno: la única pega es que tienes que activar IPv6 AHORA MISMO o el acuerdo se cierra ...

Parece que la configuración de red es algo que nos gustaría administrar ...

Configuración de IPMI

Al igual que con las direcciones IP, estoy seguro de que configura esto antes de colocar la máquina en el rack: es un buen sentido común habilitar IPMI, consola remota, etc. en cualquier máquina que tenga la capacidad, y esas configuraciones no No cambies mucho ...

... Hasta esa adquisición hipotética que mencioné anteriormente en Configuración de IP: la razón por la que se vio obligado a desocupar esas direcciones de 192.168-net es porque eso es IPMI-land de acuerdo con sus nuevos señores corporativos, y debe actualizar todas sus tarjetas IPMI AHORA porque van a pisotear el espacio IP reservado de alguien.

OK, es un poco difícil aquí, pero como dijiste, todo se puede manejar ipmitool, así que ¿por qué no hacer que Puppet ejecute la herramienta y confirme la configuración mientras hace todas sus otras cosas? Quiero decir que no va a doler nada, así que también podríamos incluir IPMI también ...

Actualizaciones

Las actualizaciones de software son más que un área gris: en mi organización evaluamos títeres para esto y lo encontramos "muy ausente", por lo que lo utilizamos radmindpara este propósito. Sin embargo, no hay ninguna razón por la que Puppet no pueda llamar a radmind: de hecho, si / cuando migramos a Puppet para la gestión de la configuración, ¡eso es exactamente lo que sucederá!

Lo importante aquí es tener todas sus actualizaciones instaladas de manera estándar (ya sea estándar en toda la organización o estándar dentro de las plataformas): no hay ninguna razón por la que Puppet no deba iniciar su proceso de actualización, siempre que haya probado exhaustivamente todo para garantizar que Puppet no arruine nada.
Tampoco hay ninguna razón por la que Puppet no pueda recurrir a una herramienta que sea más adecuada para esta tarea si ha determinado que Puppet no puede hacer un buen trabajo por sí solo ...

No reinventes la rueda.

Sí, puede tener 50 recursos de usuario virtual de títeres y realizarlos según sea necesario en sus módulos ... pero si puede, use LDAP.

Hablo por amarga experiencia. Aunque ldap no es una opción aquí, todavía.

Otro ejemplo es sacar archivos de host, en lugar de solo usar DNS.

• Puppet no es un sistema de orquestación. En particular:
  • Puppet no se adapta bien a la orquestación de VM, ya que las VM tienen un ciclo de vida propio que debe respetarse.
  • Puppet no es muy adecuado para la gestión de lanzamiento de aplicaciones / actualizaciones complejas. Las ejecuciones de títeres independientes podrían explotarse para esto, pero al menos no es el control de Puppet, sino sus scripts de envoltura o un robot humano, lo cual está bien.
• Puppet no es un buen sistema de administración de usuarios (tiene que administrar cada entrada de usuario, incluso usuarios eliminados, para que sea eficaz. Así que encuentre otra solución)
• Puppet no es una buena base de datos de configuración (observe el uso de una base de datos externa de algún tipo y un ENC, Hiera o algún pegamento similar)

Por supuesto, puedes hacer todas estas cosas con Puppet ... pero no es la mejor solución para ellos. A veces debes dejar el martillo y buscar una llave inglesa.

Sin embargo, Puppet es extremadamente bueno para mantener la configuración básica de una máquina e instalar las herramientas que le permiten hacer VM y liberar la orquestación, la administración de usuarios, etc.

Principalmente estoy de acuerdo con voretaq7, pero con un par de advertencias.

• Raramente configuro el direccionamiento IP en títeres, a menos que el sistema use DHCP (supongo que la mayoría de los proveedores de "nube" lo hacen). He tenido situaciones en las que rompí las configuraciones de red con Puppet, pero no pude corregirlas con Puppet porque el nodo no tenía forma de contactar al Puppetmaster.

• Creo firmemente que la administración de actualizaciones pertenece a las herramientas del sistema, y ​​no veo que usar Puppet como un cron glorificado sea una mejora.

En mi caso, tengo un script de arranque que carga la configuración mínima del sistema (Ubuntu): Ruby, Rubygems, build-essential, git, etc. Mis manifiestos de Puppet se mantienen bajo control de versión, y simplemente clono el repositorio. A partir de ahí, mi script de arranque hace una suposición que hostname --shortes válida e intenta hacerlo puppet apply /root/infrastructure/puppet/hosts/$( hostname --short ).pp.

Para responder tu pregunta:

• Mis scripts asumen la conectividad de red básica (DNS, IP) y no la administran ni la cambian;
• Mis scripts asumen que la identidad de la máquina es correcta y no la cambian;
• Mis scripts asumen que Ruby / Rubygems / Git está presente, pero lo gestiono después.

Cree que no necesita usar Puppet para la configuración de la red. Una vez que se configura la cosa por lo general. También puede obtener un poco de basura si tendrá un error (s) con IP o MAC o algo similar que traerá una marioneta.