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


28

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

Supposons que j'exécute un certain nombre de 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 bogues se produisent?

J'exécute actuellement des «mises à niveau sans assistance» pour permettre aux systèmes d'installer automatiquement les mises à jour de sécurité, mais je dois toujours me connecter aux serveurs et les exécuter de aptitude update && aptitude safe-upgradetemps 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? L'un de vous utilise-t-il ces outils pour éviter de s'exécuter manuellement aptitudeou un équivalent sur 15 serveurs? Je suis 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 package 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).


belle question, j'ai lu un tutoriel [que je ne trouve pas] mentionnant la mise à jour de Debian avec des marionnettes mais je ne l'ai jamais essayé moi-même. il sera intéressant de voir les réponses de ceux qui l'utilisent en production
pQd

Réponses:


9

Puppet (je suis presque sûr que le chef le fait aussi) se connecte à vos dépôts de logiciels apt-get / yum . Puisqu'ils font le gros du travail pour déterminer quels paquets sont disponibles, cela signifie ensure => latestque cela fonctionne uniquement pour Ubuntu / CentOS / Debian. Tant que vous configurez correctement les fichiers appropriés ( /etc/apt/sources.list, etc.).


1
Les réponses qui impliquent Puppet ou similaire pour gérer chaque package signifient que vous devez suivre chaque package dans Puppet, même ceux qui font partie de l'installation de distribution Linux de base. L'utilisation d'outils tels que unattended-upgradesou yum-cronpour automatiser les mises à jour représente beaucoup moins de travail - utilisez simplement Puppet / Chef / Ansible pour configurer ces outils.
RichVel

22

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

ensure => latest,

ou

ensure=> "1.0.2",

pour spécifier la version la plus récente / 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, ainsi que d'empêcher les serveurs de se mettre à niveau automatiquement (potentiellement dangereusement). J'ai utilisé cette méthode en production sur plusieurs sites, et cela fonctionne très bien.

L'exécution de mises à niveau sans surveillance me fait un peu peur, surtout si elles mettent à niveau des packages critiques, des noyaux, des bibliothèques mysql, apache, etc. Surtout si le script d'installation peut vouloir redémarrer le service!


Merci pour la réponse! Il semble donc que la mise à jour des packages installés via Puppet soit au moins possible. 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 sens de Paysage de Canonical qui offre une interface Web et d'autres trucs plus ou moins sophistiqués pour mettre à jour des packages sur plusieurs serveurs.
daff

Pour les serveurs exécutant différentes versions, c'est là que cela se complique. Vous devez avoir différents blocs dans votre manifeste de marionnettes, où 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 de celui sur le paquet à installer. Je n'ai pas vu Landscape utilisé en colère sur les serveurs de production, je suppose que c'est assez cher.
Tom O'Connor

2
ensure => latests'assurera toujours que tout est à jour avec tout ce que votre ensemble de référentiels fournit.
womble

18

Je pense que c'est probablement la mauvaise question. Il est certain que l'utilisation d'outils de gestion de configuration tels que Puppet et Chef pour maintenir votre infrastructure est un énorme pas en avant par rapport à une tentative manuelle. Le problème de la mise à jour et de la synchronisation des versions de vos packages n'est pas un problème que ces outils résolvent directement. Pour automatiser cela correctement, vous devez mettre les référentiels de packages eux-mêmes sous votre contrôle.

La façon dont je le fais est de maintenir un référentiel Yum dédié (pour Redhat / Fedora / CentOS; un référentiel APT pour Debian / Ubuntu) qui contient les paquets qui me tiennent à cœur pour un site particulier. Il s'agit généralement des dépendances de l'application elle-même (Ruby, PHP, Apache, Nginx, bibliothèques, etc.) et des packages critiques pour la sécurité.

Une fois que vous avez 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 "assure => 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 lancer allègrement en production. Cela se fait facilement avec Puppet sans aucune duplication de code en utilisant des modèles de référentiel.

L'automatisation de la gestion des versions de vos packages vous encourage fortement à synchroniser tous vos systèmes de production, car la maintenance de plusieurs référentiels et packages pour différentes distributions de systèmes d'exploitation, versions et architectures de machine prend beaucoup de temps et risque de conduire à toutes sortes de problèmes obscurs et d'incompatibilités.

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

J'ai écrit un petit tutoriel Puppet qui devrait vous aider à démarrer rapidement avec Puppet. Vous pouvez déployer une définition de référentiel personnalisé sur vos machines en utilisant Puppet comme première étape pour contrôler les versions de package.


5

Alors que Puppet / chef sont des candidats possibles pour cette fonctionnalité, pour les faire garder tout le système à jour nécessite soit des types personnalisés ou une liste tous les paquets (y compris les bibliothèques du système sous - jacentes comme libc6) avec les ressources ensure => latest. Pour le cas spécifique des mises à jour automatisées de packages, vous souhaiterez peut-être examiner le cron-aptpackage, qui fait également ce que vous voulez.


ou simplement pousser un travail d'exécution de "mise à jour miam" avec un temps d'affichage élevé. Fonctionne pour moi de toute façon.
Sirex

5

Cette question est ancienne, mais je pensais que je répondrais de manière à jour 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 dispose également d'un plugin apt, qui peut être utilisé pour effectuer une mise à jour apt sur n'importe quel nombre de serveurs: http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/AgentApt


4

Je me rends compte que c'est un peu tard pour votre question initiale, mais ici, c'est 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 packages pour la mise à jour automatique, évitant ainsi de mettre à jour tous les packages sans y être un peu prudent. Il 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.


2

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



1

Vous pouvez également utiliser des outils de gestion de packages tels que Canonicals Landscape qui est 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 capacités de surveillance de base.


0

Mises à jour de sécurité

En général, je pense qu'il est plus simple d'utiliser Ansible ou similaire pour configurer le robuste package de mises à niveau sans assistance pour Ubuntu / Debian (ou yum-cronpour RHEL / CentOS). Vous pouvez utiliser Puppet, Chef ou d'autres outils, mais je vais discuter d'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-upgradesprend en charge les mises à jour automatiques tous les jours et est normalement limité aux mises à jour de sécurité uniquement (pour augmenter la stabilité). Si le serveur a besoin d'un redémarrage après la mise à jour, cet outil peut redémarrer automatiquement à un certain moment.

Si vos redémarrages sont plus complexes, vous unattended upgradespouvez vous envoyer un e-mail, et cela crée également /var/run/reboot-required, afin qu'Ansible (ou similaire) puisse gérer les redémarrages à un moment approprié (par exemple, les redémarrages roulants d'un cluster de serveurs Web ou DB pour éviter les temps d'arrêt, en attendant chaque serveur devient 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 renforce 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 et exécuter la unattended-upgradecommande une fois que les tests montrent qu'il n'y a pas de problèmes - cependant, il est assez rare que les correctifs de sécurité orientés serveur provoquent des problèmes, dans mon expérience.

Mises à jour générales

Les mises à jour autres que la sécurité doivent passer par un processus d'intégration et de test continu normal, pour garantir que les choses ne se cassent pas.

J'ai vu de aptitude safe-upgradegraves problèmes sur les serveurs dans le passé, il est donc 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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.