Pregunta ¿Las herramientas de administración de la configuración (Puppet, Chef) son capaces de mantener actualizados los paquetes instalados?


Esta es probablemente una pregunta simple para aquellos de ustedes que ya están ejecutando herramientas de administración de configuración. ¿Son las herramientas de administración de la configuración, como Puppet o Chef, el enfoque correcto para mantener los paquetes instalados al día?

Supongamos que ejecuto varios servidores, principalmente basados ​​en Debian y Ubuntu. ¿Las herramientas de administración de la configuración facilitan la actualización de los paquetes instalados desde los repositorios cuando aparecen actualizaciones de seguridad o correcciones de errores?

Actualmente corro "actualizaciones desatendidas" para permitir que los sistemas instalen automáticamente actualizaciones de seguridad, pero todavía tengo que conectarme a los servidores y ejecutar aptitude update && aptitude safe-upgrade De vez en cuando. Naturalmente, esto se vuelve aburrido, tedioso y propenso a errores cuanto más servidores hay.

¿Son herramientas como Puppet o Chef el enfoque correcto para mantener actualizados los paquetes instalados? ¿Alguno de ustedes usa estas herramientas para evitar la ejecución manual? aptitude o un equivalente en 15 servidores? Estoy bastante seguro de que la respuesta a estas preguntas es "¡Sí, por supuesto!"

Pero, ¿dónde puedo encontrar más información sobre este caso de uso en particular? Todavía no he tenido tiempo de estudiar Puppet o Chef en profundidad, y los ejemplos de libros de cocina o clases solo muestran ejemplos más o menos triviales de instalar un paquete en particular, como ssh. ¿Tiene otros recursos para recomendar, aparte de la documentación oficial (por supuesto, voy a estudiar los documentos una vez que sepa cuál de las herramientas, en su caso, es la adecuada para mí).


28
2017-12-14 12:28


origen


Buena pregunta, he leído un tutorial [que no puedo encontrar] mencionando mantener a Debian al día con Puppet pero nunca lo probé yo mismo. Será interesante ver las respuestas de quienes lo usan en producción. - pQd


Respuestas:


Títere (estoy bastante seguro de que el chef también) se enlaza con tu apt-get/mmm repositorios de software. Ya que hacen el trabajo pesado de averiguar qué paquetes están disponibles, eso significa ensure => latest Simplemente funciona para Ubuntu / CentOS / Debian similares. Siempre que configure correctamente los archivos apropiados (/etc/apt/sources.list, etc).


10
2018-01-10 19:53



Las respuestas que involucran Puppet o una administración similar de cada paquete significan que debe realizar un seguimiento de cada paquete en Puppet, incluso los que forman parte de la instalación básica de distribución de Linux. Usando herramientas como unattended-upgrades o yum-cron a automatizar las actualizaciones es mucho menos trabajo, solo use Puppet / Chef / Ansible para configurar esas herramientas. - RichVel


Puedes hacerlo con títeres, o bien haces:

ensure => latest,

o

ensure=> "1.0.2",

para especificar la versión más reciente / requerida. es decir

package { apache2: ensure => "2.0.12-2" }
package { apache2: ensure => latest }

Esto significa que al menos puede especificar la misma versión en todos los sistemas, así como evitar que los servidores se actualicen automáticamente (potencialmente de forma peligrosa). He usado este método en producción en varios sitios, y funciona muy bien.

Ejecutar actualizaciones desatendidas me asusta un poco, especialmente si están actualizando paquetes de misión crítica, kernels, bibliotecas mysql, apache, etc. ¡Especialmente si el script de instalación puede querer reiniciar el servicio!


23
2017-12-14 13:38



¡Gracias por la respuesta! Así que parece que al menos es posible mantener actualizados los paquetes que se instalaron vía Puppet. Bueno saber. Pero ¿qué pasa con los servidores que ejecutan diferentes versiones de paquetes? ¿Como en Debian Lenny vs Ubuntu 8.04 y 9.10? ¿Tengo que cuidar las versiones manualmente? Tengo un poco más de investigación que hacer, parece. No estoy seguro de lo que esperaba, tal vez algo parecido a Paisaje canónico que ofrece una interfaz web y otras cosas más o menos sofisticadas para actualizar paquetes en múltiples servidores. - daff
Para servidores que ejecutan versiones diferentes, aquí es donde se complica. Debe tener diferentes bloques dentro de su manifiesto de títere, donde usa Facter para recuperar la palabra clave lsb_release o debian_version de / etc y luego toma decisiones basadas en el paquete que se instalará. No he visto a Landscape utilizado en la ira en los servidores de producción, supongo que es bastante caro. - Tom O'Connor
ensure => latestsiempre se asegurará de que todo esté actualizado con lo que proporcione su conjunto de repositorios. - womble♦


Creo que esta es probablemente la pregunta equivocada. Ciertamente, el uso de herramientas de administración de la configuración como Puppet y Chef para mantener su infraestructura es un gran paso adelante al tratar de hacerlo todo de forma manual. El problema de mantener las versiones de sus paquetes actualizadas y sincronizadas no es algo que cualquiera de estas herramientas resuelva directamente. Para automatizar esto correctamente, necesita poner los paquetes de repositorios bajo su control.

La forma en que lo hago es mantener un repositorio dedicado de Yum (para Redhat / Fedora / CentOS; un repositorio APT para Debian / Ubuntu) que contiene los paquetes que me interesan para un sitio en particular. Estas serán generalmente las dependencias de la aplicación en sí (Ruby, PHP, Apache, Nginx, bibliotecas, etc.) y los paquetes críticos para la seguridad.

Una vez que tenga esta configuración (por lo general, para comenzar, puede simplemente reflejar los paquetes requeridos desde el repositorio ascendente), puede usar la sintaxis "asegurar => más reciente" de Puppet para asegurarse de que todas sus máquinas estarán al día con el repositorio.

Sería prudente utilizar un repositorio de "preparación" para permitirle probar versiones actualizadas de paquetes antes de distribuirlos alegremente en producción. Esto se hace fácilmente con Puppet sin duplicación de código mediante el uso de plantillas de repositorio.

La automatización de la versión del paquete le recomienda enfáticamente que sincronice todos sus sistemas de producción, ya que el mantenimiento de múltiples repositorios y paquetes para diferentes distribuciones de SO, versiones y arquitecturas de máquinas requiere mucho tiempo y puede llevar a todo tipo de problemas e incompatibilidades desconocidos.

Todos estos consejos se aplican igualmente a las gemas de Ruby, los huevos de Python y otros sistemas de paquetes que puede utilizar.

He escrito un poco Tutorial de marionetas Lo que debería ayudarte a ponerte en marcha con Puppet rápidamente. Puede implementar una definición de repositorio personalizada en sus máquinas utilizando Puppet como primer paso para poner bajo control las versiones de los paquetes.


17
2018-02-25 15:02





Esta pregunta es antigua, pero pensé que respondería de una manera actualizada ya que una respuesta actualmente existente no estaba disponible en ese entonces.

Si está utilizando marionetas o chef, busque en mcollective. Es una muy buena herramienta de los chicos de Puppetlabs que te permite enviar comandos a grupos de servidores. http://docs.puppetlabs.com/mcollective/

También tiene un complemento de apt, que se puede utilizar para realizar una actualización de apt en cualquier número de servidores: http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/AgentApt


5
2017-07-26 17:58





Si bien Puppet / Chef son posibles contendientes para esta funcionalidad, para que se mantengan todo en el sistema, la actualización requiere tipos personalizados o una lista de todos los paquetes (incluidas las bibliotecas del sistema subyacentes como libc6) como recursos con ensure => latest. Para el caso específico de las actualizaciones de paquetes automatizadas, es posible que desee examinar el cron-apt paquete, que hace lo que quieres también.


4
2017-12-16 07:43



o simplemente elimine un trabajo de ejecución de "yum update" con un tiempo de visualización alto. Funciona para mí de todos modos. - Sirex


Me doy cuenta de que es un poco tarde para su pregunta original, pero aquí está con el espíritu de "mejor tarde que nunca".

Yo uso Cfengine 3 para hacer esto en varios servidores. Especifico una lista explícita de paquetes para actualización automática, evitando así la actualización todos Paquetes sin ser un poco cuidadosos. Funciona muy bien, y cfengine 3 es muy ligero.

Aquí hay un fragmento de promesa de mi configuración de cfengine:

    packages:
            "apache2"
                    package_method => "apt",
                    package_policy => "update";

Espero que esto ayude.


4
2018-01-25 11:56





Estoy de acuerdo con Jonathan. El enfoque de Cfengine 3 es agradable porque puede controlar todos los aspectos de la administración de paquetes sin tener que recodificar en un nivel bajo.


2
2018-02-17 04:44





Utilizamos puppet + apt-dater.


2
2018-02-17 09:16





También puede usar herramientas de administración de paquetes como Canonicals Landscape, que está diseñada para administrar y monitorear sistemas Ubuntu / Debian. Administra múltiples sistemas, le permite actualizarlos simultáneamente y proporciona algunas capacidades básicas de monitoreo.


1
2018-01-26 18:17





Actualizaciones de seguridad

En general, creo que es más simple usar Ansible o similar para configurar el robusto actualizaciones desatendidas paquete para Ubuntu / Debian (o yum-cron para RHEL / CentOS). Puedes usar Puppet, Chef u otras herramientas, pero discutiré Ansible aquí.

  • unattended-upgrades puede usarse para realizar actualizaciones no relacionadas con la seguridad al mismo tiempo, si lo prefiere, lo cual es mucho más fácil que ejecutar un comando a través de Ansible todos los días.

  • unattended-upgrades se encarga de las actualizaciones automáticas todos los días y, normalmente, se limita a las actualizaciones de seguridad únicamente (para aumentar la estabilidad). Si el servidor necesita reiniciarse después de la actualización, esta herramienta puede reiniciarse automáticamente en un momento determinado.

Si tus reinicios son más complejos, unattended upgrades puede enviarte un correo electrónico, y también crea /var/run/reboot-required, para que Ansible (o similar) pueda administrar los reinicios en un momento adecuado (por ejemplo, reinicios continuos de un grupo de servidores web o DB para evitar el tiempo de inactividad, esperando que cada servidor esté disponible en un determinado puerto TCP antes de continuar).

Puedes usar roles Ansible como jnv.unattended-actualizaciones para los sistemas Ubuntu / Debian, o el simple pero efectivo geerlingguy.security, que también cubre RHEL / CentOS (y refuerza la configuración de SSH).

Si las actualizaciones de seguridad rápidas son menos importantes, puede ponerlas en un proceso de prueba en servidores menos importantes primero y ejecutar el unattended-upgrade comando una vez que las pruebas muestran que no hay problemas, sin embargo, en mi experiencia, es bastante raro que las correcciones de seguridad orientadas al servidor causen problemas.

Actualizaciones generales

Las actualizaciones que no sean de seguridad deben pasar por un proceso de prueba y integración continuo normal, para garantizar que las cosas no se rompan.

he visto aptitude safe-upgrade causa problemas graves en los servidores en el pasado, por lo que es mejor no ejecutar esto automáticamente, mientras que las actualizaciones de seguridad son generalmente bastante seguras.


0
2017-07-11 09:30