¿Cómo actualizar yum / actualizar de forma segura muchos hosts?

Puppet es, en realidad, solo una utilidad de administración de configuración, no una herramienta de automatización. Si desea una automatización adecuada, querrá buscar mcollective, que comenzó como una herramienta de terceros y ahora se encuentra bajo el paraguas de puppetlabs. Al no haber trabajado con mcollective, tampoco puedo hablar de qué tan bien manejaría esto, pero entiendo que funciona mejor como un mecanismo de ejecución de tareas arbitrarias, que no funcionará tan bien cuando intente realizar tareas repetidas regularmente. .

Creo que la mejor manera de hacer esto sería desarrollar las secuencias de comandos y el proceso mediante el cual desea actualizar, y luego usar una marioneta para enviar las configuraciones. Así que hágase las siguientes preguntas.

1. ¿Con qué frecuencia quiero que se actualicen las máquinas?
2. ¿Quiero que se reinicien automáticamente cuando se instala un nuevo kernel o solo quiero una notificación?
3. ¿Deberíamos ejecutar algún comando especial durante las actualizaciones?
4. ¿Tengo suficientes sistemas para que las actualizaciones se escalonen?

A medida que comience a construir la configuración y responda esas preguntas, es probable que encuentre más que surjan de su entorno específico. Para un ejemplo específico lo que hago es esto:

• Para la mayoría de mis sistemas, las actualizaciones son una vez por semana, a través de un trabajo cron. Según el propósito y el entorno, algunos sistemas son mucho más frecuentes.
• La mayoría de los sistemas se reinician automáticamente, ciertos sistemas (según el propósito) envían un correo electrónico de recordatorio para reiniciar. Esto se maneja a través de un trabajo cron que verifica el archivo vmlinuz con el número de versión más alto en /boot contra la salida de uname -r
• Después de quemarme con la actualización de glibc de RHEL 5.3->5.4, me aseguro de actualizar yum, luego glibc y luego todo lo demás.
• Dado que todo esto es ejecutado por trabajos cron, tengo horas de sueño aleatorias entre cada ejecución yum. Cada host puede tardar entre 5 y 45 minutos en completarse, lo que hace un trabajo razonable al distribuir la carga.

Todo esto está contenido en dos archivos, las dos entradas cron (actualizaciones y verificación del kernel) almacenadas en /etc/cron.d y el script de actualización. Estoy haciendo esto con un script de shell cada vez más desordenado que toma argumentos de la línea de comandos para realizar la actualización o la verificación del kernel y si reiniciar o no. Luego, Puppet administra estos dos archivos. Dado que se trata de sistemas basados ​​en rpm y dpkg, probablemente crearía dos scripts o crearía do_update separados funciones para los dos sabores y hacer que cada uno se llame con un modificador de línea de comando diferente. Luego, puede enviar el script correcto marcando operatingsystem fact en su declaración de archivo, o cree una plantilla de la entrada cron y use el mismo hecho para decidir qué interruptor usar.

Usando un script bien probado, este método ha funcionado muy bien. De hecho, lo suficientemente bien como para que esta configuración se haya utilizado con éxito durante algunos años para manejar cientos de sistemas. Ocasionalmente veremos contratiempos cuando los empaquetadores del kernel comiencen a agregar más y más niveles de versiones secundarias a los archivos y la rutina de comparación se ahogue.

Puppet en sí no es la herramienta para este trabajo. Puppetlabs tiene una herramienta separada llamada MCollective, que es similar a Capistrano, Fabric y Func.

Hay un agente de MCollecive llamado Packages Agent que puede realizar actualizaciones de yum, entre otros tipos de administración de paquetes.

Mencionaste que parte de tu infraestructura ejecuta Ubuntu. Tal vez debería buscar en el paquete de actualizaciones desatendidas.

Si sus anfitriones son anfitriones RHEL, es posible que desee consultar RHN Satellite. De lo contrario, puede valer la pena echar un vistazo a Spacewalk ** (ver nota a continuación). Están diseñados para administrar copias locales de repositorios de paquetes ascendentes y para facilitar la administración de sistemas registrados en el servidor RHN Satellite. Puede programar que los paquetes se actualicen en un momento específico, o si ha habilitado OSAD, las actualizaciones se pueden programar en tiempo cercano en la GUI web de RHN Satellite/Spacewalk.

Algunas personas han publicado usando títeres a continuación, hay algunos blogs y páginas web escritos sobre cómo integrar Puppet con RHN Satellite.

ALTERNATIVAMENTE....

Si está más interesado en ver un proyecto emergente que eventualmente reemplazará a RHN Satellite, puede echar un vistazo al Proyecto Katello. Katello contiene una gran cantidad de proyectos que son parte del producto CloudForms de Red Hat y se dice que es el upstream para el eventual reemplazo de RHN Satellite. De hecho, Katello integra Puppet mediante el uso de Foreman. Definitivamente vale la pena considerar Katello a largo plazo en lugar de Spacewalk (pero no RHN Satellite todavía debido a la suscripción/soporte).

** Me he referido tanto a RHN Satellite como a Spacewalk como RHN Satellite en mi publicación para facilitar las cosas. La distinción real es si tiene o no sistemas RHEL, si ese es el caso, necesitará RHN Satellite, ya que puede descargarse de RHN de manera compatible, Spacewalk sería para usuarios que usan una reconstrucción de RHEL o Fedora (entiendo que Spacewalk puede ser compatible con Debian también, pero personalmente no sé mucho sobre esto). Por lo tanto, al buscar información, puede ser necesario buscar Spacewalk o RHN Satellite