Mise à jour de la production Ubuntu enferme les choses à faire et à ne pas faire

Solution 1 :

Il n'y a rien de spécial à propos des correctifs entre Ubuntu et 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 correctif est de supposer que quelque chose va pause.

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

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

Cela peut inclure l'utilisation de WSUS ou de miroirs de <your_os_here> à une machine interne de gestion des correctifs. Préférable qui peut interroger de manière centralisée et vous informer de l'état des correctifs installés sur vos machines individuelles.

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

Lorsque cela est possible, au fur et à mesure que les correctifs sortent, demandez au serveur central de les copier sur les machines individuelles. C'est vraiment juste un gain de temps pour que vous n'ayez pas à attendre qu'ils se téléchargent ET s'installent, 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 parties prenantes de ces systèmes sont conscientes que des correctifs sont déployés. Soyez prêt pour les appels "ceci" ne fonctionne pas.

Conformément à ma théorie de base selon laquelle les correctifs cassent les choses, assurez-vous d'avoir une fenêtre d'indisponibilité pour appliquer les correctifs suffisamment longtemps pour résoudre les problèmes critiques, et éventuellement annuler le correctif. Vous n'avez pas nécessairement besoin d'avoir des gens assis là pour tester après les correctifs. Personnellement, je compte beaucoup sur mes systèmes de surveillance pour me faire savoir que tout fonctionne au niveau minimum auquel nous pouvons nous en tenir. 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'à 3h du matin à patcher les boîtes.

• automatiser autant que possible

Comme tout le reste en informatique, script, script puis script un peu plus. Scriptez 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 là-bas 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 "le soir désigné". Si vous ne pouvez pas les faire la nuit 1, exigez qu'ils soient gratuits la nuit 2. Vous permet également de conserver le nombre de serveurs patchés en même temps.

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

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

Patcher un serveur une fois par mois ou une fois tous les deux mois est - à mon humble avis - un objectif très réalisable et acceptable. Plus que cela, et bien vous corrigerez constamment des 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.

Combien de fenêtres avez-vous 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 environnements plus petits qui sont 9x5 peuvent probablement s'en tirer avec une fenêtre de patch par mois. Les grands magasins ouverts 24h/24 et 7j/7 peuvent en avoir besoin de deux. Les très grands 24x7x365 peuvent avoir besoin d'une fenêtre glissante chaque semaine pour avoir un ensemble différent de serveurs corrigés chaque semaine.

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

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

Solution 2 :

Choses à faire :

1. Effectuer 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 détourner le trafic de la zone de production pendant la mise à niveau.
4. Essayez d'avoir une méthode d'accès hors bande en cas de problème, KVM, console série, accès local ou mains à distance.
5. Testez sur un serveur, puis assurez-vous que tout fonctionne, avant de déployer les mises à jour sur d'autres serveurs
6. Utilisez la marionnette si vous le pouvez pour vous assurer que les numéros de version sont les mêmes sur plusieurs serveurs. (Vous pouvez également l'utiliser pour forcer les mises à jour)
7. Sur un serveur de test, comparez les versions des fichiers de configuration avec les nouvelles (mises à jour installées) et assurez-vous que rien ne va sérieusement casser les choses. Je crois me rappeler 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 le lundi matin, ou à 17h00 le vendredi après-midi ! (merci @3influence !)
2. Mettre à niveau MySQL sur de très gros serveurs de base de données (le redémarrage peut prendre beaucoup de temps)
3. Faire tous vos serveurs à la fois (en particulier les noyaux)
4. Faire tout ce qui pourrait changer /etc/networks (car vous pourriez perdre la connectivité)
5. Des mises à jour automatisées qui pourraient faire ce qui précède sans que vous soyez là pour vérifier que tout va bien.

Solution 3 :

Autre point à souligner :si vous êtes habitué à Windows, vous serez surpris que la plupart des mises à jour Linux ne le fassent pas nécessitent un temps d'arrêt ou un 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.

Solution 4 :

Nos machines Ubuntu exécutent toutes des versions LTS.

Nous installons automatiquement toutes les mises à jour - bien sûr, ce n'est pas la "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.

Solution 5 :

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

1. Maintenir une suite de tests d'acceptation qui vérifient tous les chemins critiques de nos logiciels
2. Installez les mises à niveau de sécurité sans surveillance à 4h du matin tous les matins et exécutez immédiatement les tests d'acceptation. Si quelque chose échoue, un ingénieur est appelé et a tout le temps de réparer les choses ou de revenir en arrière avant 9 heures du matin. 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'intégralité de notre infrastructure chaque semaine (sur digitalocean) avec des déploiements bleu/vert, qui maintiennent 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 tous les jours ou même plusieurs fois par jour sans impact sur les clients et éliminer l'étape (2).

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