La actualización de la producción de Ubuntu encajona lo que se debe y no se debe hacer

De vez en cuando inicio sesión en los cuadros de producción web / db / herramientas y veo el mensaje típico:

Se pueden actualizar 30 paquetes. 16 actualizaciones son actualizaciones de seguridad.

Mi pregunta es, ¿cómo manejan todos ustedes las actualizaciones en sus cajas de Ubuntu de producción? ¿Automatizas estas actualizaciones? ¿Estableces tiempo de inactividad para ellos? El problema es que nunca se sabe cuándo una actualización va a romper algo, como quizás un archivo de configuración existente, etc.

La otra parte de este problema es que mantenerse al día con los parches es "algo bueno", pero los parches se lanzan casi a diario. ¿Cuántas interrupciones programadas tiene que hacer uno si hay un nuevo parche de seguridad disponible todos los días?

Creo que un hilo sobre las respuestas sobre cómo administrar sus actualizaciones sería muy útil.

No hay nada especial en parchear Ubuntu vs. Windows, RHEL, CentOS, SuSE, debian, etc.

El estado mental básico en el que debe estar al diseñar su procedimiento de parche es asumir que algo se romperá.

Algunas de las pautas básicas que suelo usar al diseñar una configuración de parche son:

• Utilice siempre un sistema local para centralizar internamente a su red desde donde se instalan los parches

Esto puede incluir el uso de WSUS o espejos de <your_os_here>una máquina interna de administración de parches. Es preferible que pueda consultar centralmente y hacerle saber el estado de los parches instalados en sus máquinas individuales.

• Preinstale las instalaciones, cuando sea posible, en las máquinas.

Cuando es posible, a medida que salen los parches, el servidor central los copia en las máquinas individuales. Esto es realmente solo un ahorro de tiempo para que no tenga que esperar a que se descarguen e instalen, solo tiene que iniciar la instalación durante su ventana de parche.

• Obtenga una ventana de interrupción para instalar los parches, es posible que deba reiniciar, y algo probablemente se romperá. Asegúrese de que las partes interesadas de esos sistemas sepan que se están implementando parches. Esté preparado para el "esto" no funciona llamadas.

De acuerdo con mi teoría básica de que los parches rompen las cosas, asegúrese de tener una ventana de interrupción para aplicar parches el tiempo suficiente para solucionar problemas críticos, y posiblemente deshacer el parche. No es necesario que las personas que están sentadas allí examinen después de los parches. Personalmente, confío en gran medida en mis sistemas de monitoreo para hacerme saber que todo está funcionando en el nivel mínimo con el que podemos escapar. Pero también esté preparado para que se presenten pequeños problemas molestos a medida que las personas se ponen a trabajar. Siempre debe tener a alguien programado para estar listo para contestar el teléfono, preferiblemente no el tipo que estuvo despierto hasta las 3 a.m.

• automatizar tanto como sea posible

Como todo lo demás en TI, script, script y luego script más. Script la descarga del paquete, el inicio de la instalación, el espejo. Básicamente, desea convertir las ventanas de parche en una tarea de niñera que solo necesita un humano allí en caso de que las cosas se rompan.

• Tener múltiples ventanas cada mes

Esto le brinda la capacidad de no parchear algunos servidores si, por alguna razón, no pueden ser parcheados en "la noche designada". Si no puede hacerlos en la noche 1, solicite que sean gratuitos en la noche 2. También le permite mantener el número de servidores parcheados al mismo tiempo.

¡Lo más importante es mantenerse al día con los parches! Si no lo hace, tendrá que hacer ventanas de parche muy grandes de más de 10 horas solo para volver al punto en el que está atrapado. Introducir aún más puntos en los que las cosas podrían salir mal, y hacer que sea más difícil encontrar qué parche causó y emitió.

La otra parte de este problema es que mantenerse al día con los parches es "algo bueno", pero los parches se lanzan casi a diario. ¿Cuántas interrupciones programadas tiene que hacer uno si hay un nuevo parche de seguridad disponible todos los días?

Parchar un servidor una vez al mes o una vez cada dos meses es, en mi humilde opinión, un objetivo muy alcanzable y aceptable. Más que eso, y bueno, constantemente estarás parcheando servidores, mucho menos y comenzarás a meterte en situaciones en las que tienes cientos de parches que deben aplicarse por servidor.

¿Hasta cuántas ventanas necesitas al mes? Eso depende de tu entorno. ¿Cuántos servidores tienes? ¿Cuál es el tiempo de actividad requerido para sus servidores?

Los entornos más pequeños que son 9x5 probablemente pueden salirse con una ventana de parche al mes. Las grandes tiendas 24x7 pueden necesitar dos. Es posible que 24x7x365 muy grandes necesiten una ventana móvil cada semana para tener un conjunto diferente de servidores parcheados cada semana.

Encuentre una frecuencia que funcione para usted y su entorno.

Una cosa a tener en cuenta es que 100% actualizado es un objetivo imposible de alcanzar: no deje que su departamento de seguridad le diga lo contrario. Haz tu mejor esfuerzo, no te quedes muy atrás.

Cosas para hacer:

1. Tomar una copia de seguridad
2. Asegúrese de que sea una copia de seguridad restaurable (aunque estos dos son puntos generales)
3. Intente dirigir el tráfico fuera de la caja de producción mientras realiza la actualización.
4. Intente tener un método de acceso fuera de banda en caso de que todo salga mal, KVM, consola serie, acceso local o manos remotas.
5. Pruebe en un servidor, luego asegúrese de que todo funcione, antes de implementar actualizaciones en más servidores
6. Utilice puppet si puede para asegurarse de que los números de versión sean los mismos en varios servidores. (También puedes usarlo para forzar actualizaciones)
7. En un servidor de prueba, diferencie las versiones de los archivos de configuración con los nuevos (actualización instalada) y asegúrese de que nada va a romper las cosas seriamente. Me parece recordar que dpkg preguntó antes de instalar nuevas versiones que difieren de las instaladas actualmente.

Cosas a evitar:

1. ¡Haciendo actualizaciones a la mitad del día, o las 09:00 los lunes por la mañana, o las 5pm los viernes por la tarde! (¡Gracias @ 3influence!)
2. Actualización de MySQL en servidores de bases de datos realmente grandes (reiniciar podría llevar mucho tiempo)
3. Hacer todos sus servidores a la vez (especialmente los núcleos)
4. Hacer cualquier cosa que pueda cambiar / etc / networks (porque podría perder conectividad)
5. Actualizaciones automatizadas que podrían hacer lo anterior sin que usted esté allí para verificar que todo esté bien.

Otro punto que vale la pena destacar: si está acostumbrado a Windows, se sorprenderá de que la mayoría de las actualizaciones de Linux no requieren tiempo de inactividad o reinicio. Algunos lo hacen, como las actualizaciones del kernel. Pero las actualizaciones que requieren reinicio o tiempo de inactividad generalmente se marcan como tales y se pueden manejar en un horario separado.

Nuestras máquinas Ubuntu están ejecutando versiones LTS.

Simplemente instalamos automáticamente todas las actualizaciones, seguro que no es la "mejor práctica", pero somos una tienda relativamente pequeña y no tenemos un entorno de prueba / desarrollo / producción para cada servicio. Las actualizaciones LTS generalmente están bastante bien probadas y son mínimamente invasivas de todos modos.

La actualización a una nueva versión obviamente es un poco más complicada.

Nos ocupamos de las actualizaciones de la siguiente manera para los sistemas ubuntu LTS:

1. Maitain un conjunto de pruebas de aceptación que verifican todas las rutas críticas en nuestro software
2. Instale actualizaciones de seguridad sin supervisión a las 4 am todas las mañanas e inmediatamente ejecute las pruebas de aceptación. Si algo falla, un ingeniero es localizado y tiene mucho tiempo para arreglar las cosas o retroceder antes de las 9 a.m. Hasta ahora, esto solo ha sucedido dos veces en cinco años: LTS está bien probado y es estable.
3. Redistribuimos automáticamente toda nuestra infraestructura cada semana (en digitalocean) con implementaciones azules / verdes, lo que mantiene todos los paquetes en sus últimas versiones. Si un nuevo despliegue falla las pruebas de aceptación, el despliegue está en espera hasta que un ingeniero pueda depurar el problema.

El siguiente paso lógico para nosotros es eliminar la información de la sesión en memoria para que simplemente podamos volver a implementar la infraestructura todos los días o incluso varias veces al día sin afectar a los clientes y eliminar el paso (2).

Este enfoque requiere poco mantenimiento y evita completamente las ventanas de mantenimiento.

Una cosa que recomendaría es manejar las reversiones de paquetes. Consulte Transacciones y reversión con Debian para obtener una sugerencia de cómo hacerlo, ya que a veces necesita una solución rápida para una actualización que rompe algo.