¿Las herramientas de gestión de 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 configuración como Puppet o Chef el enfoque correcto para mantener actualizados los paquetes instalados?

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

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

¿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 aptitudeo 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 la instalación de un paquete en particular, como ssh. ¿Tiene algún recurso para recomendar, aparte de la documentación oficial (por supuesto, voy a estudiar los documentos una vez que sepa cuál, si es que hay alguna, de las herramientas son las adecuadas para mí)?

Puppet (estoy bastante seguro de que el chef también lo hace) se vincula con sus repositorios de software apt-get / yum . Dado que hacen el trabajo pesado de averiguar qué paquetes están disponibles, eso significa que ensure => latestsolo funciona para Ubuntu / CentOS / Debian. Siempre que configure los archivos apropiados correctamente ( /etc/apt/sources.list, etc.).

Puedes hacerlo con títeres, o bien haces:

ensure => latest,

o

ensure=> "1.0.2",

para especificar la última versión / requerida. es decir

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

Esto al menos significa que puede especificar la misma versión en todos los sistemas, así como evitar que los servidores (potencialmente peligrosos) se actualicen automáticamente. 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, núcleos, bibliotecas mysql, apache, etc. ¡Especialmente si el script de instalación puede querer reiniciar el servicio!

Creo que esta es probablemente la pregunta equivocada. Ciertamente, usar herramientas de administración de configuración como Puppet y Chef para mantener su infraestructura es un gran paso adelante al tratar de hacerlo todo manualmente. 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, debe poner los repositorios de paquetes bajo su control.

La forma en que hago esto 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. En general, serán 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, puede simplemente reflejar los paquetes requeridos desde el repositorio ascendente para comenzar) puede usar la sintaxis "sure => latest" de Puppet para asegurarse de que todas sus máquinas estén actualizadas con el repositorio.

Sería aconsejable utilizar un repositorio de "puesta en escena" para permitirle probar versiones actualizadas de paquetes antes de lanzarlos alegremente a 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 las versiones de su paquete le recomienda encarecidamente que sincronice todos sus sistemas de producción, ya que mantener múltiples repositorios y paquetes para diferentes distribuciones de sistemas operativos, versiones y arquitecturas de máquinas requiere mucho tiempo y es probable que ocasione todo tipo de problemas oscuros e incompatibilidades.

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

He escrito un pequeño tutorial de Puppet que debería ayudarlo a comenzar a usar Puppet rápidamente. Puede implementar una definición de repositorio personalizada en sus máquinas usando Puppet como el primer paso para controlar las versiones de los paquetes.

Si bien Puppet / Chef son posibles contendientes para esta funcionalidad, hacer que mantengan todo actualizado en el sistema requiere tipos personalizados o enumerar cada paquete (incluidas las bibliotecas del sistema subyacentes como libc6) como recursos ensure => latest. Para el caso específico de las actualizaciones automáticas de paquetes, es posible que desee consultar el cron-aptpaquete, que también hace lo que quiere.

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

Si está usando una marioneta o un chef, busque en mcollective. Es una herramienta muy agradable de puppetlabs que le permite enviar comandos a grupos de servidores. http://docs.puppetlabs.com/mcollective/

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

Me doy cuenta de que esto es un poco tarde para su pregunta original, pero aquí está en el espíritu de "más vale tarde que nunca".

Utilizo Cfengine 3 para hacer esto en varios servidores. Especifico una lista explícita de paquetes para la actualización automática, evitando así actualizar todos los paquetes sin tener un poco de cuidado al respecto. 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.

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

Utilizamos puppet + apt-dater.

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

Actualizaciones de seguridad

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

• unattended-upgrades se puede usar para realizar actualizaciones que no sean de 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-upgradesse 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 sus reinicios son más complejos, unattended upgradespuede enviarle un correo electrónico, y también crea /var/run/reboot-required, de modo que Ansible (o similar) pueda administrar los reinicios en un momento adecuado (por ejemplo, reinicios continuos de un clúster de servidores web o DB para evitar el tiempo de inactividad, esperando cada uno servidor para estar disponible en un determinado puerto TCP antes de continuar).

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

Si las actualizaciones rápidas de seguridad son menos importantes, primero puede pasarlas por un proceso de prueba en servidores menos importantes y ejecutar el unattended-upgradecomando una vez que las pruebas muestren que no hay problemas; sin embargo, es bastante raro que las soluciones de seguridad orientadas al servidor causen problemas, en mi experiencia.

Actualizaciones generales

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

He visto aptitude safe-upgradecausar graves problemas 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.