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

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).

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.).

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!

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.

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.

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

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.

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.

Nous utilisons marionnette + apt-dateur.

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.

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.