Question Les outils de gestion de la configuration (Puppet, Chef) sont-ils capables de maintenir à jour les packages installés?


C'est probablement une question simple pour ceux d'entre vous qui exécutent déjà des outils de gestion de la configuration. Les outils de gestion de la configuration tels que Puppet ou Chef sont-ils la bonne approche pour maintenir à jour les packages installés?

Supposons que je gère plusieurs serveurs, principalement basés sur Debian et Ubuntu. Les outils de gestion de la configuration facilitent-ils la mise à jour des packages installés à partir des référentiels lorsque des mises à jour de sécurité ou des corrections de bugs surviennent?

Je cours actuellement "Mises à jour sans surveillance" laisser les systèmes installer automatiquement les mises à jour de sécurité, mais je dois toujours me connecter aux serveurs et exécuter aptitude update && aptitude safe-upgrade de temps en temps. Naturellement, cela devient ennuyeux, fastidieux et sujet aux erreurs, plus il y a de serveurs.

Des outils tels que Puppet ou Chef sont-ils la bonne approche pour maintenir à jour les packages installés? Est-ce que l'un de vous utilise ces outils pour éviter de lancer manuellement aptitude ou un équivalent sur 15 serveurs? Je suis presque certain que la réponse à ces questions est "Oui, bien sûr!"

Mais où puis-je trouver plus d'informations sur ce cas d'utilisation particulier? Je n'ai pas encore eu le temps d'étudier en profondeur Puppet ou Chef, et les exemples de livres de cuisine ou de classes ne montrent que des exemples plus ou moins triviaux d'installation d'un paquet particulier, tel que ssh. Avez-vous des ressources à recommander, autres que la documentation officielle (je vais bien sûr étudier les documents une fois que je saurai quels outils, le cas échéant, me conviennent).


28
2017-12-14 12:28


origine


Bonne question, j'ai lu un tutoriel [que je ne trouve pas] mentionnant comment tenir Debian à jour avec puppet mais que je n'ai jamais essayé moi-même. ça va être intéressant de voir les réponses de ceux qui l'utilisent en production - pQd


Réponses:


La marionnette (je suis sûre que le chef le fait aussi) est liée à votre apt-get/Miam dépôts de logiciels. Étant donné qu’ils ont la lourde tâche de déterminer quels forfaits sont disponibles, cela signifie ensure => latest ne fonctionne que pour Ubuntu / CentOS / Debian, etc. Tant que vous configurez les fichiers appropriés correctement (/etc/apt/sources.list, etc).


10
2018-01-10 19:53



Les réponses impliquant Puppet ou un logiciel similaire dans la gestion de chaque package signifient que vous devez suivre chaque package dans Puppet, même ceux faisant partie de l'installation de la distribution Linux de base. Utiliser des outils tels que unattended-upgrades ou yum-cron à automatiser les mises à jour C’est beaucoup moins de travail - il suffit d’utiliser Puppet / Chef / Ansible pour configurer ces outils. - RichVel


Vous pouvez le faire avec une marionnette, vous pouvez soit:

ensure => latest,

ou

ensure=> "1.0.2",

pour spécifier la dernière version / requise. c'est à dire.

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

Cela signifie au moins que vous pouvez spécifier la même version sur tous les systèmes et empêcher les serveurs (potentiellement dangereux) de se mettre à jour automatiquement. J'ai utilisé cette méthode en production sur plusieurs sites et cela fonctionne très bien.

Exécuter des mises à jour sans surveillance me fait un peu peur, surtout si elles mettent à jour des paquetages critiques, des noyaux, des bibliothèques mysql, apache, etc. Surtout si le script d'installation peut vouloir redémarrer le service!


23
2017-12-14 13:38



Merci pour la réponse! Il semble donc qu'il est au moins possible de garder à jour les paquets qui ont été installés via Puppet. Bon à savoir. Mais qu'en est-il des serveurs exécutant différentes versions de packages? Comme dans Debian Lenny vs Ubuntu 8.04 et 9.10? Dois-je m'occuper des versions manuellement? Il me semble que j'ai encore des recherches à faire. Je ne suis pas sûr de ce à quoi je m'attendais, peut-être quelque chose dans le genre de Paysage de Canonical qui offre une interface Web et d’autres outils plus ou moins sophistiqués pour la mise à jour de paquets sur plusieurs serveurs. - daff
Pour les serveurs exécutant différentes versions, c’est là que cela se complique. Votre manifeste de marionnette doit comporter différents blocs, dans lesquels il utilise Facter pour récupérer le mot clé lsb_release ou debian_version à partir de / etc, puis prend des décisions en fonction du paquet à installer. Je n'ai pas vu Landscape utilisé dans la colère sur des serveurs de production, je suppose que c'est assez cher. - Tom O'Connor
ensure => latestveillera toujours à ce que tout soit à jour avec tout ce que votre ensemble de référentiels fournit. - womble♦


Je pense que c'est probablement la mauvaise question. Utiliser des outils de gestion de la configuration, tels que Puppet et Chef, pour maintenir votre infrastructure représente un énorme pas en avant par rapport à l’essai manuel. Le problème de la mise à jour et de la synchronisation des versions de vos packages n’est résolu en aucune manière par l’un de ces outils. Pour automatiser cela correctement, vous devez placer les référentiels de paquets sous votre contrôle.

Pour ce faire, je gère un référentiel Yum dédié (pour Redhat / Fedora / CentOS; un référentiel APT pour Debian / Ubuntu) qui contient les paquets qui s’importent pour un site particulier. Il s’agit généralement des dépendances de l’application elle-même (Ruby, PHP, Apache, Nginx, des bibliothèques, etc.) et des packages critiques pour la sécurité.

Une fois que vous avez configuré cette configuration (en général, vous pouvez simplement mettre en miroir les packages requis à partir du référentiel en amont), vous pouvez utiliser la syntaxe "assurer => dernière" de Puppet pour vous assurer que toutes vos machines seront à jour avec le référentiel.

Il serait judicieux d’utiliser un référentiel «intermédiaire» pour vous permettre de tester les versions mises à jour des packages avant de les transférer allègrement à la production. Cela se fait facilement avec Puppet sans aucune duplication de code en utilisant des modèles de référentiel.

L'automatisation de vos packages La gestion des versions vous encourage fortement à synchroniser tous vos systèmes de production, car la maintenance de plusieurs référentiels et packages pour différents systèmes de distribution, versions et architectures de système d'exploitation prend beaucoup de temps et est susceptible d'entraîner toutes sortes de problèmes et d'incompatibilités obscurs.

Tous ces conseils s’appliquent également aux rubis, aux œufs de Python et aux autres systèmes d’emballage que vous pouvez utiliser.

J'ai écrit un peu Tutoriel sur les marionnettes ce qui devrait vous aider à utiliser rapidement Puppet. Vous pouvez déployer une définition de référentiel personnalisée sur vos machines en utilisant Puppet comme première étape pour mettre sous contrôle les versions de package.


17
2018-02-25 15:02





Cette question est ancienne, mais je pensais que je répondrais de manière actualisée car une réponse existante n'était pas disponible à l'époque.

Si vous utilisez une marionnette ou un chef, examinez mcollective. C'est un très bel outil des gars de puppetlabs qui vous permet d'envoyer des commandes à des groupes de serveurs. http://docs.puppetlabs.com/mcollective/

Il possède également un plugin apt, qui peut être utilisé pour effectuer une mise à jour apt sur un nombre quelconque de serveurs: http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/AgentApt


5
2017-07-26 17:58





Alors que Puppet / Chef sont des prétendants potentiels à cette fonctionnalité, il est important de les garder tout à jour sur le système nécessite soit des types personnalisés, soit la liste de chaque paquet (y compris les bibliothèques système sous-jacentes telles que libc6) en tant que ressources avec ensure => latest. Pour le cas particulier des mises à jour automatisées des packages, vous pouvez vous pencher sur la cron-apt forfait, qui fait ce que vous voulez aussi.


4
2017-12-16 07:43



ou tout simplement pousser un travail exécutif de "yum update" avec un temps d'affichage élevé. Travaille pour moi quand même. - Sirex


Je me rends compte que votre question initiale est un peu tardive, mais dans l’esprit "mieux vaut tard que jamais".

J'utilise Cfengine 3 pour le faire sur plusieurs serveurs. Je spécifie une liste explicite de paquets pour la mise à jour automatique, évitant ainsi la mise à jour tout paquets sans être un peu prudent à ce sujet. Cela fonctionne très bien et cfengine 3 est très léger.

Voici un extrait de promesse de ma configuration cfengine:

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

J'espère que cela t'aides.


4
2018-01-25 11:56





Je suis d'accord avec Jonathan. L’approche Cfengine 3 est intéressante car vous pouvez contrôler tous les aspects de la gestion des paquets sans avoir à recoder à un niveau bas.


2
2018-02-17 04:44





Nous utilisons marionnette + apt-dater.


2
2018-02-17 09:16





Vous pouvez également utiliser des outils de gestion de paquets tels que Canonicals Landscape, conçu pour gérer et surveiller les systèmes Ubuntu / Debian. Il gère plusieurs systèmes, vous permet de les mettre à jour simultanément et fournit des fonctionnalités de surveillance de base.


1
2018-01-26 18:17





Mises à jour de sécurité

En général, je pense que c'est plus simple d'utiliser Ansible ou similaire pour configurer le robuste mises à jour sans surveillance paquet pour Ubuntu / Debian (ou yum-cron pour RHEL / CentOS). Vous pouvez utiliser Puppet, Chef ou d'autres outils, mais je vais discuter de Ansible ici.

  • unattended-upgrades peut être utilisé pour effectuer des mises à jour non liées à la sécurité en même temps si vous préférez, ce qui est beaucoup plus facile que d'exécuter une commande via Ansible tous les jours.

  • unattended-upgrades prend en charge les mises à jour automatiques tous les jours et est normalement limité aux mises à jour de sécurité (pour accroître la stabilité). Si le serveur a besoin d'un redémarrage après la mise à jour, cet outil peut redémarrer automatiquement à un moment donné.

Si vos redémarrages sont plus complexes, unattended upgrades peut vous envoyer un courriel, et il crée également /var/run/reboot-required, de sorte que Ansible (ou similaire) puisse gérer les redémarrages à un moment approprié (par exemple, redémarrage progressif d’un cluster de serveurs Web ou de serveurs de base de données pour éviter les temps morts, en attendant que chaque serveur soit disponible sur un certain port TCP avant de continuer).

Vous pouvez utiliser des rôles Ansible tels que jnv.unattended-upgrades pour les systèmes Ubuntu / Debian, ou le simple mais efficace geerlingguy.security, qui couvre également RHEL / CentOS (et durcit la configuration SSH).

Si les mises à jour de sécurité rapides sont moins importantes, vous pouvez d’abord les soumettre à un processus de test sur des serveurs moins importants, puis exécuter le unattended-upgrade Une fois, les tests de commande montrent qu'il n'y a pas de problèmes - cependant, il est assez rare que les correctifs de sécurité orientés serveur causent des problèmes, selon mon expérience.

Mises à jour générales

Les mises à jour autres que la sécurité doivent passer par un processus normal d'intégration et de test continu, afin de s'assurer que tout ne se casse pas.

J'ai vu aptitude safe-upgrade Dans le passé, il était préférable de ne pas l'exécuter automatiquement, alors que les mises à jour de sécurité sont généralement assez sûres.


0
2017-07-11 09:30