Buena práctica para administrar actualizaciones de paquetes para muchos servidores CentOS

Como parte de mi trabajo, administro algunas decenas de servidores CentOS 5, usando puppet para la configuración principal. Alrededor de la mitad de nuestros servidores tienen una configuración estandarizada para alojar varios sitios de django, mientras que el resto son una mezcla de aplicaciones.

Estoy clasificando gradualmente nuestras prácticas de alojamiento, y ahora he llegado al punto de averiguar cómo administrar las actualizaciones de seguridad a nivel del sistema operativo. Soy cauteloso con solo hacer un trabajo cron, yum -y updatepero tampoco quiero tener que revisar cada servidor a tiempo y revisar cada paquete con actualizaciones disponibles, ya que eso tomaría un tiempo.

Así que me pregunto si hay buenos atajos o prácticas de trabajo que minimicen los riesgos involucrados y la cantidad de tiempo que necesito dedicar. O, para decirlo de otra manera, ¿existen herramientas o prácticas que puedan automatizar gran parte del trabajo sin dejar de dar el control?

Pasos que he decidido hasta ahora:

• deshabilite todos los repositorios de terceros y configure nuestro propio repositorio para que pueda controlar qué actualizaciones pasan por allí.
• tenemos servidores provisionales para (la mayoría de) nuestros servidores de producción donde podría hacer pruebas (pero ¿cuántas pruebas son suficientes?)

También tenga en cuenta que he examinado el complemento de seguridad de yum, pero no funciona en CentOS .

Entonces, ¿cómo gestiona las actualizaciones para un número significativo de servidores CentOS que ejecutan una matriz heterogénea de aplicaciones?

En la mayoría de mis entornos, generalmente es un script kickstart y post-instalación para que el sistema principal esté actualizado y actualizado con las actualizaciones en ese momento. Por lo general, tengo un repositorio local que se sincroniza con un espejo CentOS diariamente o semanalmente. Tiendo a congelar el paquete del kernel en el momento actual de la instalación y actualizar los paquetes individualmente o según sea necesario. Muchas veces, mis servidores tienen periféricos que tienen controladores estrechamente vinculados a las versiones del kernel, por lo que es una consideración.

CentOS 5 ha madurado hasta el punto en que no son necesarias actualizaciones constantes. Pero también tenga en cuenta que CentOS 5 se está acabando. La tasa de actualizaciones se ha ralentizado un poco, y la naturaleza de las actualizaciones está más en línea con las correcciones de errores y menos con respecto a los principales cambios de funcionalidad.

Entonces, en este caso específico, lo primero que puede hacer es construir un espejo / repositorio local. Use su gestión de configuración existente para controlar el acceso a repositorios de terceros. Tal vez programar una política para actualizar los servicios críticos o públicos (ssh, http, ftp, dovecot, etc.) Todo lo demás requerirá pruebas, pero tengo la sensación de que la mayoría de los entornos no se ejecutan con sistemas completamente actualizados / parcheados.

¡Hay muchas herramientas que pueden ayudar con esto! En general, el sistema de paquetes y qué paquetes van donde se maneja la gestión de configuración. Sin embargo, estas herramientas generalmente cubren más que solo ñam y las rpm, y le ahorrarán tiempo y evitarán muchos dolores de cabeza.

La herramienta con la que estoy más familiarizado es la marioneta que uso para administrar prácticamente todas las configuraciones en mi entorno. Aquí hay algunos ejemplos de títeres para administrar específicamente yum:

http://people.redhat.com/dlutter/puppet-app.html

Actualmente hay varias herramientas de administración de configuración disponibles, que tienen grupos de usuarios bastante grandes:

• Cfengine http://cfengine.com/cfengine3
• Puppet http://puppetlabs.com/puppet/puppet-difference/
• Chef http://wiki.opscode.com/display/chef/Home (Algunas de las personas que conozco han implementado esto recientemente y me encanta)

Implementarlos en un entorno agregará años a su vida. Reduce la cantidad de dolores de cabeza de los sistemas mal configurados y permite una fácil actualización / actualización. La mayoría de estas herramientas también pueden proporcionar algunas funciones de nivel de auditoría, lo que puede reducir en gran medida el tiempo de reparación por errores de configuración.

Con respecto a su pregunta sobre las pruebas, he estado utilizando un entorno de preparación al que dirigimos la carga de algunos clientes (generalmente clientes beta o un pequeño subconjunto del tráfico de producción). Por lo general, dejamos que este clúster ejecute un nuevo código durante al menos un par de días, hasta una semana (dependiendo de la gravedad del cambio) antes de implementarlo en producción. Por lo general, he descubierto que esta configuración funciona mejor si intenta averiguar cuánto tiempo tardan en descubrir la mayoría de los errores. En sistemas muy utilizados, esto puede ser cuestión de horas, en la mayoría de los entornos que he visto una semana es suficiente para descubrir incluso errores poco comunes en la puesta en escena / QA.

Una parte realmente importante sobre las pruebas es la replicación de datos / uso. Usted mencionó que tiene versiones preparatorias de la mayoría de su hardware de producción. ¿También tienen copias idénticas de los datos de producción? ¿Se puede reproducir alguna carga de producción en su contra? ¿Puede incluso hacerlo parte del clúster de producción utilizando la duplicación de tráfico? Esto generalmente se convierte en una compensación directa entre la cantidad de recursos que la empresa está dispuesta a gastar en pruebas / control de calidad. Cuantas más pruebas, mejor, trate de no autolimitarse (dentro de lo razonable) y ver qué respaldará el negocio (luego encuentre una manera de hacer un 10% más).