Mise à jour de la production Boîtes Ubuntu les DOS et à ne pas faire
De plus, je me connecte à la production de boîtes Web/DB/Outils et de voir le message typique:
30 paquets peuvent être mis à jour. 16 mises à jour sont des mises à jour de sécurité.
Ma question est que vous traitez toutes de vos mises à jour sur vos boîtes de production Ubuntu? Automatisez-vous ces mises à jour? Avez-vous des temps d'arrêt pour eux? Le problème est que vous ne savez jamais quand une mise à jour va briser quelque chose, tel que peut-être un fichier de configuration existant, etc.
L'autre partie de ce problème est de suivre des patchs, c'est une bonne chose, mais les patchs sont libérés presque tous les jours. Combien de pannes programmées doit-elle avoir à faire s'il existe un nouveau tache de sécurité disponible chaque jour?
Je pense qu'un fil sur les réponses sur la manière dont vous gérez vos mises à jour serait très utile.
Choses à faire:
- Faire une sauvegarde
- Assurez-vous que c'est une sauvegarde réparable (bien que ces deux sont des points généraux)
- Essayez de diriger le trafic de la boîte de production pendant votre mise à niveau.
- Essayez d'avoir une méthode d'accès hors bande au cas où tout se passe mal, KVM, console série, accès local ou à distance.
- Testez sur un serveur, puis assurez-vous que tout fonctionne, avant de déployer des mises à jour sur plus de serveurs.
- 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 à niveau)
- Sur un serveur de test, diffez les versions des fichiers de configuration contre les nouvelles (mises à jour installées) et assurez-vous que rien ne va sérieusement casser les choses. Je semble vous rappeler DPKG demandant avant d'installer de nouvelles versions différentes de ceux actuellement installés.
Choses à éviter:
- Faire des mises à jour au milieu de la journée, à 09h00 le lundi matin, ou 17h00 le vendredi après-midi! (Merci à 3influence!)
- Mise à niveau MySQL sur de très grands serveurs de base de données (le redémarrage pourrait prendre beaucoup de temps)
- Faire tous vos serveurs à la fois (surtout des noyaux)
- Faire tout ce qui pourrait changer/etc/réseaux (parce que vous pourriez perdre une connectivité)
- Mises à jour automatisées pouvant faire ce qui précède sans que vous soyez là pour vérifier que tout va bien.
Un autre point qui vaut la peine de faire: si vous êtes habitué à Windows, vous serez surpris que la plupart des mises à jour Linux non nécessitent des temps d'arrêt ou un redémarrage. Certains font, tels que les mises à jour du noyau. Mais les mises à jour nécessitant le redémarrage ou les temps d'arrêt sont généralement signalées comme telles et peuvent être traitées sur un calendrier séparé.
Nos machines Ubuntu utilisent toutes les versions LTS.
Nous installons automatiquement toutes les mises à jour - bien sûr, ce n'est pas une "meilleure pratique", mais nous sommes un magasin relativement petit et ne disposez pas d'un environnement de test/développement/développement pour chaque service unique. 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 impliquée.
Nous traitons des mises à jour de la manière suivante pour les systèmes Ubuntu LTS:
- Maitain une série de tests d'acceptation qui vérifient tous les chemins critiques dans notre logiciel
- 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 tout échoue, un ingénieur est paginée et a beaucoup de temps à des choses fixes ou à l'arrière du rouleau avant 9 heures. Cela n'a jusqu'à présent arrivé que deux fois de cinq ans - LTS est bien testé et stable.
- Nous redéployer automatiquement notre infrastructure entière chaque semaine (sur Digital Ocean) avec des déploiements bleu/vert, qui conserve tous les paquets à leurs dernières versions. Si un nouveau déploiement échoue sur les tests d'acceptation, le déploiement est en attente 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, voire plusieurs fois par jour sans impact sur les clients et éliminer l'étape (2).
Cette approche est basse entretien et évite complètement les fenêtres de maintenance.
Une chose que je recommanderais, c'est la manipulation des retombées de colis. Voir Transactions et retour avec Debian Pour une suggestion de la manière de le faire, car vous avez parfois besoin d'une solution rapide pour une mise à niveau qui enfreint quelque chose.