Si vous exécutez des mises à jour automatiques

J'exécute des serveurs Web de production Centos. Je veux savoir quelle est la meilleure pratique pour exécuter des mises à jour. Dois-je automatiser cela avec yum-cron ou yum-updatesd? Ou existe-t-il un risque de mise à jour des sites, il serait donc préférable de mettre à jour sur un serveur de test, puis d'exécuter les mises à jour manuellement chaque semaine?

La majorité des serveurs utilisent uniquement les référentiels officiels mais certains ont le référentiel atomique pour les modules PHP qui ne sont pas disponibles autrement. Quoi de mieux dans ce cas? puis-je définir yum pour utiliser uniquement Atomic pour les modules PHP? Je ne veux pas que tout soit mis à jour vers le truc de pointe dans Atomic, je ferais plutôt confiance à Centos (ou vraiment à Red Hat) pour garder mes serveurs stables et sécurisés.

Il y a des avantages et des inconvénients dans les deux sens, et vous devez vraiment étudier l'architecture de votre système pour savoir quelle méthode vous convient le mieux. Quelle que soit la route que vous prenez, vous devez comprendre pourquoi vous avez choisi cette méthode et quels sont les inconvénients afin de pouvoir les compenser.

Voici quelques trucs à prendre en compte:

• Les mises à jour de sécurité doivent toujours être appliquées d'une manière ou d'une autre, et le plus tôt possible. Si votre serveur ne reçoit pas les mises à jour de sécurité appliquées en temps opportun pour une raison quelconque, corrigez vos habitudes d'administrateur système.

• Les mises à jour de Distro sont généralement bonnes, surtout si elles proviennent de sources officielles. Si vous vous sentez mal à l'aise de les appliquer, vous n'utilisez peut-être pas la meilleure distribution pour vos besoins. Vous devez utiliser une distribution qui correspond à votre méthodologie. En d'autres termes, vous pouvez faire confiance aux mises à jour pour qu'elles soient dans votre meilleur intérêt. S'ils se déplacent trop rapidement ou apportent des modifications logicielles qui cassent vos affaires, vous devriez probablement utiliser une distribution différente.

• Les mises à jour peuvent casser vos affaires. Un passage à un logiciel plus récent pourrait casser votre code si vous utilisiez des fonctionnalités obsolètes ou si vous écriviez simplement de mauvaises choses. Vous devez envisager une architecture système qui vous permet de tester votre produit sur des mises à jour avant de les exécuter sur des systèmes de production.

• Si vous utilisez des fonctionnalités de mise à jour automatique, vous devez toujours avoir un moyen de revenir aux configurations de travail connues. Les instantanés complets du système peuvent vous sauver la vie si une mise à jour casse votre produit sur un système de production.

Ce n'est pas une liste exhaustive, juste quelques éléments pour vous faire réfléchir. En fin de compte, ce n'est pas une décision que quelqu'un d'autre peut prendre pour vous. Vous êtes l'administrateur. Connaissez vos systèmes. Connaissez votre distribution.

Je suis d'accord à 100% avec ce que Caleb a déjà dit. Quelques encoches plus spécifiques à CentOS de ma part:

La distribution est basée sur RedHat et ses correctifs. Ces correctifs sont testés très bien et au cours des 4 dernières années où nous avons utilisé CentOS 5 avec plus de 50 serveurs, il n'y a jamais eu de mauvais correctif.

MAIS: Bien que nous appliquions automatiquement tous les correctifs quotidiennement aux serveurs qui exécutent uniquement des éléments de distribution, nous démarrons les serveurs de production (après la mise à jour de la glibc ou du noyau) uniquement après que nos systèmes de test ont fonctionné dans cette configuration quelques jours.

Pour les autres référentiels, nous les mettons en miroir dans un répertoire intermédiaire. Ces correctifs sont d'abord appliqués aux serveurs de test. S'il est prouvé que rien ne casse, nous activons le répertoire intermédiaire et le copions dans un référentiel de production.

La correction automatique a pour effet secondaire que les composants corrigés sont souvent redémarrés - donc si vous les avez mal configurés après le démarrage, le redémarrage échouera.