13 votos

Buenas prácticas para la gestión de las actualizaciones de los paquetes de un montón de servidores CentOS

Como parte de mi trabajo me administrar un par de decenas de CentOS 5 servidores, el uso de títeres para el conjunto principal. Alrededor de la mitad de nuestros servidores cuentan con un conjunto normalizado para un hosting diversos django sitios, mientras que el resto son un mish mash de aplicaciones.

Estoy poco a poco la organización de nuestro hosting prácticas, y ahora he llegado al punto de trabajar en cómo administrar las actualizaciones de seguridad a nivel de sistema operativo. Yo soy cuidadoso de sólo tener un trabajo cron para hacer una yum -y update , pero también no quieren tener que dar la vuelta a cada servidor en el tiempo y en la revisión de cada paquete con actualizaciones disponibles, como que iba a tomar un tiempo.

Me pregunto si hay alguna buena accesos directos o prácticas de trabajo que podrían minimizar los riesgos y minimizar la cantidad de tiempo que necesita para pasar. O para decirlo de otra manera hay de herramientas o prácticas que pueden automatizar una gran parte del trabajo, mientras que todavía da el control.

Pasos que he decidido hasta ahora:

  • deshabilitar todos los repositorios de terceros y configurar nuestro propio repositorio, de modo que yo puedo controlar lo que las actualizaciones de pasar por allí.
  • tenemos servidores de ensayo para el (la mayoría de) nuestros servidores de producción donde yo pudiera hacer la prueba (pero, ¿cuánto de pruebas es suficiente prueba?)

También tenga en cuenta que he mirado en el yum seguridad plugin pero no funciona en CentOS.

Entonces, ¿cómo gestionar las actualizaciones para un número significativo de CentOS servidores que ejecutan un conjunto heterogéneo de aplicaciones?

2voto

Tina Puntos 21

En la mayoría de mis entornos, generalmente es un comienzo y post-script de instalación para obtener el principal sistema de seguridad y actualizaciones en ese momento. Yo, por lo general, tienen un local repo que se sincroniza con un CentOS espejo a diario o semanalmente. Tiendo a congelar el paquete del kernel en lo que es la vigente en el momento de la instalación y actualización de paquetes de forma individual o como sea necesario. Muchas veces, mis servidores periféricos que tienen los conductores estrechamente vinculada a las versiones del kernel, por lo que es una consideración.

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

Así que en este caso específico, la primera cosa que usted podría hacer es construir una réplica local/repo. Su uso existente de gestión de la configuración para controlar el acceso de terceros a los repos. Quizás programación de la política de yum update crítica o público de servicios (ssh, http, ftp, dovecot, etc.) Todo lo demás se requieren pruebas, pero me da la sensación de que la mayoría de los entornos no ejecutar completamente actualizado/patched sistemas.

1voto

polynomial Puntos 3284

Hay muchas herramientas que pueden ayudar con esto! Es general el sistema de paquetes y los paquetes que ir a donde está manejado por la administración de la configuración. Estas herramientas suelen cubrir más que yum y rpm sin embargo, y ahorrar tiempo y evitar muchos dolores de cabeza!

La herramienta que estoy más familiarizado con es marioneta que yo uso para gestionar prácticamente todos los config en mi entorno. Aquí están algunos ejemplos de títeres para la gestión de yum específicamente:

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

Hay un número de herramientas de administración de configuración disponibles en la actualidad, estos tienen bastante grandes grupos de usuarios:

La aplicación de estos en un entorno va a añadir años a su vida. Se reduce el número de dolores de cabeza de mal configurado los sistemas y permite una fácil actualización/actualización. La mayoría de estas herramientas también pueden proporcionar algunos de auditoría a nivel de funcionalidad, así que puede reducir considerablemente el tiempo de reparación de errores de configuración.

En cuanto a tu pregunta acerca de las pruebas que he estado utilizando un entorno de ensayo que nos directa de algunos de los clientes de la carga (normalmente los clientes beta o un pequeño subconjunto de tráfico de producción). Normalmente nos vamos a este grupo de ejecutar el nuevo código de al menos un par de días, hasta una semana (dependiendo de la gravedad del cambio) antes de pasarlo a producción. Por lo general me he encontrado con esta configuración funciona mejor si tratas de calcular cuánto tiempo la mayoría de los errores llevará a descubrir. En muy utilizados en sistemas de esto puede ser una cuestión de horas, en la mayoría de los entornos he visto en una semana es tiempo suficiente para descubrir, incluso infrecuente errores en la puesta en escena/QA.

Una parte muy importante acerca de las pruebas es la replicación de datos/uso. Usted mencionó que tiene de ensayo versiones de la mayoría de su producción de hardware. Ellos también tienen copias idénticas de los datos de producción? Puede reproducir cualquiera de la carga de producción en contra de ella? Se puede incluso hacer parte de la producción de clúster mediante el tráfico de creación de reflejo? Generalmente, esto se convierte en un intercambio directo entre el monto de los recursos que la empresa está dispuesta a gastar en testing/QA. Más pruebas de la mejor, no se auto límite (dentro de lo razonable) y ver lo que el negocio va a apoyar (luego encontrar una manera de hacer un 10% más).

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: