La mise à jour de la production Ubuntu contient les choses à faire et à ne pas faire

De temps en temps, je me connecte aux boîtes de production web / db / tools et vois le message typique:

30 packages peuvent être mis à jour. 16 mises à jour sont des mises à jour de sécurité.

Ma question est, comment gérez-vous tous les mises à jour sur vos boîtiers de production Ubuntu? Automatisez-vous ces mises à jour? Fixez-vous des temps d'arrêt pour eux? Le problème est que vous ne savez jamais quand une mise à jour va casser quelque chose, comme peut-être un fichier de configuration existant, etc.

L'autre partie de ce problème est que suivre les correctifs est «une bonne chose», mais les correctifs sont publiés presque quotidiennement. Combien d'interruptions programmées doit-on effectuer si un nouveau correctif de sécurité est disponible chaque jour?

Je pense qu'un fil sur les réponses sur la façon dont vous gérez vos mises à jour serait très utile.

Il n'y a rien de spécial dans le patch d'Ubuntu contre Windows, RHEL, CentOS, SuSE, debian, etc.

L'état d'esprit de base dans lequel vous devez être lors de la conception de votre procédure de patch est de supposer que quelque chose va se casser.

Certaines des directives de base que j'ai tendance à utiliser lors de la conception d'une configuration de correctif sont les suivantes:

• Utilisez toujours un système local pour centraliser en interne sur votre réseau où les correctifs sont installés à partir de

Cela peut inclure l'utilisation de WSUS ou des miroirs d' <your_os_here>une machine de gestion des correctifs interne. De préférence, qui peut interroger de manière centralisée et vous faire connaître l'état des correctifs installés sur vos machines individuelles.

• Pré-étalez les installations - si possible - sur les machines.

Lorsque cela est possible, au fur et à mesure que les correctifs sortent, le serveur central les copie sur les machines individuelles. C'est vraiment juste un gain de temps pour que vous n'ayez pas à attendre qu'ils soient téléchargés ET installés, il vous suffit de lancer l'installation pendant votre fenêtre de patch.

• Obtenez une fenêtre d'interruption pour installer les correctifs, vous devrez peut-être redémarrer et quelque chose se cassera probablement. Assurez-vous que les intervenants de ces systèmes sont conscients du déploiement de correctifs. Soyez prêt pour les appels "cela" ne fonctionne pas.

Conformément à ma théorie de base selon laquelle les correctifs cassent les choses, assurez-vous que vous disposez d'une fenêtre d'interruption pour appliquer les correctifs assez longtemps pour résoudre les problèmes critiques et éventuellement restaurer le correctif. Vous n'avez pas forcément besoin que des personnes soient là pour tester après les patchs. Personnellement, je compte beaucoup sur mes systèmes de surveillance pour me faire savoir que tout fonctionne au niveau très minimal avec lequel nous pouvons nous en sortir. Mais préparez-vous également à ce que de petits problèmes lancinants soient appelés lorsque les gens se mettent au travail. Vous devriez toujours avoir quelqu'un prévu pour être là prêt à répondre au téléphone - de préférence pas le gars qui était jusqu'à 3 heures du matin pour réparer les boîtes.

• automatiser autant que possible

Comme tout le reste en informatique, script, script puis script encore plus. Script le téléchargement du package, le démarrage de l'installation, le miroir. Fondamentalement, vous voulez transformer les fenêtres de patch en une tâche de baby-sitting qui a juste besoin d'un humain au cas où les choses se briseraient.

• Avoir plusieurs fenêtres chaque mois

Cela vous donne la possibilité de ne pas patcher certains serveurs si, pour une raison quelconque, ils ne peuvent pas être patchés "la nuit désignée". Si vous ne pouvez pas les faire la nuit 1, exigez qu'ils soient gratuits la nuit 2. Vous permet également de garder le nombre de serveurs corrigés en même temps.

Surtout, suivez les correctifs! Si vous ne le faites pas, vous devrez vous-même faire de très grandes fenêtres de patch de plus de 10 heures juste pour revenir au point où vous êtes rattrapé. Présentant encore plus de points où les choses pourraient mal tourner, et rendant plus difficile la recherche du correctif causé et du problème.

L'autre partie de ce problème est que suivre les correctifs est «une bonne chose», mais les correctifs sont publiés presque quotidiennement. Combien d'interruptions programmées doit-on effectuer si un nouveau correctif de sécurité est disponible chaque jour?

Patcher un serveur une fois par mois ou tous les deux mois est - à mon humble avis - un objectif très réalisable et acceptable. Plus que cela, et bien vous corrigerez constamment les serveurs, beaucoup moins et vous commencerez à vous retrouver dans des situations où vous avez des centaines de correctifs qui doivent être appliqués par serveur.

En ce qui concerne le nombre de fenêtres dont vous avez besoin par mois? Cela dépend de votre environnement. Combien de serveurs avez-vous? Quel est le temps de disponibilité requis pour vos serveurs?

Les petits environnements 9x5 peuvent probablement s'en tirer avec une fenêtre de correctif par mois. Les grands magasins 24h / 24 et 7j / 7 peuvent en avoir besoin de deux. Les très grandes 24x7x365 peuvent nécessiter une fenêtre mobile chaque semaine pour avoir un ensemble différent de serveurs patché chaque semaine.

Trouvez une fréquence qui fonctionne pour vous et votre environnement.

Une chose à garder à l'esprit est que 100% à jour est un objectif impossible à atteindre - ne laissez pas votre service de sécurité vous dire le contraire. Faites de votre mieux, ne vous laissez pas trop distancer.

Choses à faire:

1. Faites une sauvegarde
2. Assurez-vous qu'il s'agit d'une sauvegarde restaurable (bien que ces deux points soient généraux)
3. Essayez de diriger le trafic hors de la zone de production pendant la mise à niveau.
4. Essayez d'avoir une méthode d'accès hors bande au cas où tout irait mal, KVM, console série, accès local ou à distance.
5. Testez sur un serveur, puis assurez-vous que tout fonctionne, avant de déployer les mises à jour sur plusieurs serveurs
6. Utilisez des marionnettes si vous le pouvez pour vous assurer que les numéros de version sont identiques sur plusieurs serveurs. (Vous pouvez également l'utiliser pour forcer les mises à niveau)
7. Sur un serveur de test, comparez les versions des fichiers de configuration avec les nouveaux (mise à jour installée) et assurez-vous que rien ne va sérieusement casser les choses. Il me semble que dpkg a demandé avant d'installer de nouvelles versions qui diffèrent de celles actuellement installées.

Choses à éviter:

1. Faire des mises à jour en milieu de journée, ou 09h00 un lundi matin, ou 17h00 un vendredi après-midi! (merci @ 3influence!)
2. Mise à niveau de MySQL sur de très gros serveurs de base de données (le redémarrage peut prendre du temps)
3. Faire tous vos serveurs en même temps (en particulier les noyaux)
4. Faire tout ce qui pourrait changer / etc / networks (car vous pourriez perdre la connectivité)
5. Mises à jour automatisées qui pourraient faire ce qui précède sans que vous soyez là pour vérifier que tout est OK.

Un autre point mérite d'être souligné: si vous êtes habitué à Windows, vous serez surpris que la plupart des mises à jour Linux ne nécessitent ni temps d'arrêt ni redémarrage. Certains le font, comme les mises à jour du noyau. Mais les mises à jour qui nécessitent un redémarrage ou un temps d'arrêt sont généralement signalées comme telles et peuvent être traitées selon un calendrier distinct.

Nos machines Ubuntu exécutent toutes des versions LTS.

Nous installons simplement automatiquement toutes les mises à jour - ce n'est pas une "meilleure pratique", mais nous sommes une boutique relativement petite et nous n'avons pas d'environnement de test / développement / production pour chaque service. Les mises à jour LTS sont généralement assez bien testées et peu invasives de toute façon.

La mise à niveau vers une nouvelle version est évidemment un peu plus compliquée.

Nous traitons les mises à jour de la manière suivante pour les systèmes ubuntu LTS:

1. Maitain une suite de tests d'acceptation qui vérifient tous les chemins critiques dans notre logiciel
2. Installez les mises à niveau de sécurité sans surveillance à 4 heures du matin tous les matins et exécutez immédiatement les tests d'acceptation. Si quelque chose échoue, un ingénieur est paginé et a tout le temps de réparer les choses ou de revenir en arrière avant 9h. Jusqu'à présent, cela ne s'est produit que deux fois en cinq ans - LTS est bien testé et stable.
3. Nous redéployons automatiquement l'ensemble de notre infrastructure chaque semaine (sur digitalocean) avec des déploiements bleu / vert, ce qui maintient tous les packages à leurs dernières versions. Si un nouveau déploiement échoue aux tests d'acceptation, le déploiement est suspendu jusqu'à ce qu'un ingénieur puisse déboguer le problème.

La prochaine étape logique pour nous est d'éliminer les informations de session en mémoire afin que nous puissions simplement redéployer l'infrastructure chaque jour ou même plusieurs fois par jour sans impact sur les clients et éliminer l'étape (2).

Cette approche nécessite peu d'entretien et évite complètement les fenêtres de maintenance.

Une chose que je recommanderais est de gérer les annulations de packages. Voir Transactions et restauration avec Debian pour une suggestion sur la façon de le faire, car parfois vous avez besoin d'une solution rapide pour une mise à niveau qui casse quelque chose.