¿Qué NO debe ser gestionado por la marioneta?

67

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?

Lucas404
fuente
1
Buena pregunta. Tengo curiosidad por saber si hay algo más que configuraciones específicas de la máquina para las que no deberías usar puppet. Bueno, eso y las máquinas con Windows.
HopelessN00b
66
<vague> No debe administrar las cosas en títeres cuando es mejor / más fácil administrarlas de otra manera. </vague>: p
Zoredache
1
Con el predominio de las compañías que usan Puppet en estos días, puedo ver esta pregunta atrayendo mucha atención en los próximos años
Daniel Li

Respuestas:

24

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 ...

voretaq7
fuente
Re: Actualizaciones. Una cosa que puede meterte en problemas con Puppet ejecutando tus actualizaciones es cuando se repara el servicio crítico, por ejemplo: mysql, apache: no quieres que se reinicien por capricho. Puppet proporciona formas de bloquear la versión de esos paquetes, así es como lo he evitado mientras disfruto de actualizaciones generales para otros detalles.
thinice
@thinice Ese es un buen punto, pero mi contrapunto habitual es golpear a la gente en la parte posterior de la cabeza y gritar REDUNDANCIA muy, muy fuerte :-) (Es una situación peor con Radmind porque eso destruye el sistema de archivos. Nuestra política es haga que el equilibrador de carga descargue la mitad de los servidores para que podamos parchearlos / probarlos, luego trasladaremos a todos a las máquinas parcheadas para que podamos hacer la otra mitad. Funciona bien, pero necesita la redundancia integrada en su entorno.)
voretaq7
10

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.

Sirex
fuente
3
Reconozco todas esas palabras, pero todavía no estoy seguro de lo que estás tratando de decir.
Chris S
2
Estoy tratando de decir; la marioneta es un lugar central para la "información". También lo son DNS y LDAP. No intente hacer su trabajo con Puppet, es una basura ... Digo esto después de haber visto archivos gigantes / etc / hosts que se expulsan con Puppet cada vez que un nuevo host se une a la red.
Sirex
3
¿La gente realmente usa Puppet en lugar de LDAP para administrar cuentas de usuario?
Joel E Salas
2
Cada herramienta tiene su lugar, pero el uso de títeres para la gestión de cuentas de usuario o LDAP para el almacenamiento de archivos es un abuso .
Hubert Kario
1
Sin duda es un uso ab ...
jldugger 01 de
9
  • 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.

Robert M Thomson
fuente
Más de una objeción: Puppet se puede configurar para agregar y eliminar usuarios con o sin administrar a cada usuario. Dicho esto ... es inútil no administrar a todos los usuarios y terrible para administrar a todos los usuarios. Uso marionetas para agregar cuentas de servicio, pero no cuentas de usuario.
Art Hill
2

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.

Paul Gear
fuente
1

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.
François Beausoleil
fuente
0

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.

Evgenii Iablokov
fuente
2
¿Nunca tuvo que cambiar a mano la puerta de enlace predeterminada en más de 100 servidores? Lucky you;)
@EricDANNIELOU Supongo que podría tomarse como un +1 para permitir que Puppet gestione la configuración de IP de las interfaces de red;)
Luke404
@EricDANNIELOU Intente hacer esto con bash, el ciclo "for" y los permisos de usuario apropiados (sudo a root o root directamente) y sed / perl / etc. :)
Evgenii Iablokov
1
No creo que el ciclo bash "for" y los scripts sucios sed / awk / vi sean más seguros que scm para la configuración de la red. Y una vez que tiene una marioneta configurada para todo lo demás, no es muy conveniente tener ssh "for" loop solo para la configuración de la red.