linux – ¿Qué NO debería ser manejado por títeres?

Pregunta:

Estoy aprendiendo a través de la gestión de la configuración en general y usando títeres para implementarlo en particular, y me pregunto qué aspectos de un sistema, si es que hay alguno, no deberían manejarse con títeres.

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 los títeres. La conectividad IP básica, al menos en la red utilizada para comunicarse con el titiritero, debe estar funcionando. Usar puppet 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 iniciar la cosa o los certificados serán divertidos.

Entonces, ¿debería omitir la configuración de IP de la marioneta? ¿O debería configurarlo antes de iniciar el títere por primera vez pero administrar las direcciones IP con títere de todos modos? ¿Qué pasa con los sistemas con varias direcciones IP (por ejemplo, para WAN, LAN y SAN)?

¿Y IPMI ? Puede configurar la mayoría, si no todo, con ipmitool , lo que le evita tener acceso a la consola (físico, 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 un agente títere no me suena bien, y el acceso básico al sistema es algo que me gustaría tener antes de hacer cualquier otra cosa.

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

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

Respuesta:

Regla general: si está utilizando la administración de 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 (extraídos de la pregunta, todas las narrativas de "Por eso quiere administrarlo"):


Configuración de red IP

De acuerdo, 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 digamos que ahora agrega otro servidor de nombres a su entorno y necesita actualizar todas sus máquinas. ¿No quiere que su sistema de administración de configuración lo haga por usted?

O digamos que su empresa es adquirida y su nueva empresa matriz exige que cambie de su direccionamiento 192.168.0.0/24 a 10.11.12.0/24 para encajar en su sistema de numeración.

O de repente obtiene un contrato gubernamental masivo: el único problema es que tiene que mostrar IPv6 AHORA MISMO o el trato se arruina …

Parece que la configuración de la 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 bastidor. Es de sentido común habilitar IPMI, consola remota, etc. en cualquier máquina que tenga la capacidad, y esas configuraciones no no cambia mucho …

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

De acuerdo, aquí es un poco ipmitool , pero como dijiste, todo se puede administrar con 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 dañar nada, por lo que también podemos incluir IPMI …


Actualizaciones

Las actualizaciones de software son más bien un área gris – En mi organización evaluamos a puppet para esto y lo encontramos "muy deficiente", por lo que usamos radmind para 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 lo haya probado a fondo. todo para garantizar que Puppet no estropee nada.
Tampoco hay ninguna razón por la que Puppet no pueda llamar 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 …

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım