Question Des idées sur la façon d’exécuter la maintenance sur un site toujours utilisé?


J'aide avec un grand site de jeux en Australie. Nous organisons des compétitions de 7h du matin à 1h du matin, tous les jours de la semaine. Nous n'avons pas passé une journée depuis la sortie du site. Naturellement, cela rend la maintenance extrêmement difficile à exécuter et nous constatons que notre serveur de transfert a jusqu'à 50 commits d'avance sur notre branche de production. Habituellement, le développeur principal doit se lever très tôt pour fusionner les branches et s’assurer que tout fonctionne correctement.

Nous avons essayé de rendre notre site de préparation aussi semblable que possible au site de production, mais nous ne pouvons que le rendre si similaire.

Notre site est basé sur Laravel avec un serveur Node.JS pour le temps réel. Nous utilisons Laravel Forge.

Quelqu'un a-t-il des suggestions sur la manière dont nous pourrions pousser les mises à jour plus souvent? Nous sommes ouverts à tout.


18
2017-11-28 06:39


origine


Pourquoi un déploiement prend-il si longtemps? - Michael Hampton♦
@ MichaelHampton Nos déploiements ne prennent pas longtemps, c'est simplement que nous ne pouvons pas nous permettre le temps d'immobilisation si quelque chose ne va pas. - cheese5505
La question qui se pose alors est la suivante: pourquoi un retour en arrière prend-il tant de temps? - Michael Hampton♦
@ MichaelHampton, nous n'avons pas correctement examiné les retours en arrière. Cependant, nous effectuons parfois des mises à jour volumineuses qui ralentissent le site trop longtemps. - cheese5505
Peu importe ce qui prend beaucoup de temps, c'est ce que vous devez regarder. - Michael Hampton♦


Réponses:


Vous pourriez faire beaucoup de choses pour améliorer votre processus de déploiement. Quelques-uns d'entre eux sont:

  • Assurez-vous que votre code est bien testé.

    Idéalement, vous devriez avoir une couverture de 100% des tests unitaires, ainsi que des tests d'intégration pour tous les scénarios imaginables.

    Si vous ne l'avez pas, vous devriez probablement tout laisser tomber et vous en occuper.

    Examinez le développement axé sur le comportement.

    Avoir une suite de tests complète vous permettra de ...

  • Exécutez l'intégration continue.

    Chaque fois que quelqu'un commet un changement, CI peut alors automatiquement lancez la suite de tests dessus. Si la suite de tests réussit, elle peut alors se déployer immédiatement (ou planifier un déploiement). Pour les modifications qui ne nécessitent aucune modification importante de vos bases de données, cela vous fera économiser beaucoup de temps et de maux de tête.

    En cas de problème, CI peut également vous donner une restauration en un clic.

    CI est beaucoup moins utile si votre suite de tests n'est pas complète et correcte, car tout repose sur la possibilité de valider votre code de manière automatisée.

  • Faire des mises à jour atomiques.

    Dans l'idéal, vous ne devez pas simplement copier les nouveaux fichiers sur l'ancien sur le serveur de production. Utilisez plutôt un outil tel que capistrano, qui copie chaque fichier dans un nouvel emplacement, puis utilise un lien symbolique pour pointer vers le déploiement souhaité. L'annulation en arrière est instantanée car il s'agit simplement de changer le lien symbolique pour qu'il pointe vers le déploiement précédent. (Bien que cela ne couvre pas nécessairement votre migration de base de données.)

    Vérifiez également si des conteneurs tels que Docker peuvent vous aider.

  • Faites des changements plus petits et plus fréquents.

    Que vous ayez des tests, des IC ou rien, cela seul peut vous aider de manière significative. Chaque modification doit avoir sa propre branche git et un déploiement doit comporter le moins de modifications possible. Les modifications étant plus réduites, il y a moins de risques de problèmes lors d'un déploiement.

    Sur cette note, isolez autant que possible les modifications. Si vous avez modifié le jeu Omaha et que cela n'affecte pas le Texas Hold'em, le stud à 5 cartes ou autre chose, c'est le seul jeu qui doit être suspendu pour des raisons de maintenance.

  • Analysez tout ce qui dure depuis longtemps.

    Vous avez mentionné que certaines parties de vos déploiements prennent beaucoup de temps. C'est Probablement changements de schéma de base de données. Il vaut la peine de consulter votre administrateur de base de données, ainsi que chaque changement de schéma, pour voir ce qui peut donner de meilleurs résultats.

    Demandez à un expert en la matière d'examiner toute autre partie d'un déploiement qui prend beaucoup de temps.

  • Travailler heures impaires.

    Vous le faites peut-être déjà, mais il convient de le mentionner. Les développeurs (et les administrateurs système!) Ne devraient plus travailler "9 à 5", en particulier pour une opération 24x7. Si une personne est censée passer la nuit à surveiller un déploiement, à résoudre des problèmes, puis à respecter un horaire de jour, vos attentes ne sont pas réalistes et vous la préparez pour l'épuisement professionnel.


22
2017-11-28 07:55



La solution la plus simple consiste ici à utiliser les scripts de déploiement dans un outil tel que Capistrano et peut-être même à équilibrer la charge. - JakeGould
Merci pour le conseil. Nous allons examiner cela. À l'heure actuelle, nous n'avons pas du tout de suite de tests, et j'aimerais vraiment en savoir plus, mais le site est en développement depuis plus de 8 mois et est si vaste qu'il faudrait plus d'une semaine pour en créer une. Nous utilisons Laravel Forge, qui relie simplement la nouvelle version au dossier pour lequel nginx est configuré. Je suis incapable de travailler à des heures irrégulières à cause de l'école, et c'est pareil pour l'autre dev. - cheese5505
@ cheese5505 Je sais que c'est frustrant et que cela ne résout pas votre problème, mais quand vous dites cela, “… Est si gros qu'il en faudrait plus d'une semaine pour en faire un.” cela semble manifestement ridicule. Tout processus de développement et de déploiement sain permettrait à un serveur d’être construit en moins d’une journée, voire de quelques heures à une heure. Vous devriez vraiment revoir ce que vous avez fait pour construire cette pile de choses ingérables pour éviter cela. Le problème n'est pas la complexité mais la prévoyance de base dans la planification. - JakeGould
"Pour le moment, nous n'avons pas du tout de suite de tests" - corrigez ceci à présent, avant de développer de nouvelles fonctionnalités. Ceci est votre plus grand point de douleur et sera un risque de disponibilité. Les tests automatisés contribueront grandement à prévenir les pannes et réduiront considérablement la douleur des ops. - Josh


D'après ce que vous dites, il semble que vous ayez une fenêtre de maintenance de 1 h à 7 h tous les jours. Le problème n'est pas l'heure mais la commodité. C’est normal et beaucoup de gens le traitent comme une activité professionnelle.

Vous pouvez avoir 2 systèmes (ou plus) avec un système frontal qui dirige le trafic vers celui qui est actuellement actif. Une fois que vous êtes satisfait de la disponibilité d'une version, vous demandez au système frontal de passer au nouveau système. cela devrait être facile de créer un scénario rapide.

Vous avez maintenant le choix de laisser l'ancien système en l'état afin de pouvoir revenir en arrière ou de le mettre à jour afin qu'il puisse être utilisé comme pièce de rechange pour le système actif jusqu'à ce qu'il soit temps de créer / tester les prochaines mises à jour.


6
2017-11-28 07:24



Voulez-vous dire une architecture logicielle totalement modulaire? Ou une architecture de serveur telle qu'un équilibreur de charge? - JakeGould
juste quelque chose qui accepte les connexions et les livrer au backend principal actuel. - Iain


Modification des autres réponses: Vous devriez suivre les modèle de déploiement bleu-vert. Lorsque vous souhaitez publier une nouvelle version, vous la déployez sur un site Web de transfert intermédiaire interne. Ensuite, vous pouvez exécuter des tests automatisés sur le site de production de la prochaine version. Une fois les tests terminés, vous indiquez à l’équilibreur de charge d’utiliser le nouveau site Web.

Cela aide de la manière suivante:

  1. Les problèmes graves sont toujours présents avec zéro temps d'arrêt.
  2. Le passage à une nouvelle version a exactement zéro temps d'arrêt, car la nouvelle version est déjà démarrée et réchauffée.
  3. Vous pouvez revenir à l'ancienne version à tout moment, car celle-ci est toujours en cours d'exécution.

Tous les autres problèmes mentionnés par vous-même et d'autres personnes deviennent moins graves lorsque vous pouvez vous déployer à tout moment sans stress. Le modèle de déploiement bleu-vert est une solution relativement complète pour les problèmes de déploiement.


5
2017-11-28 13:06



Nous avons déjà un serveur de transfert que nous utilisons pour tester, mais pour le moment, la production et le transfert sont effectués sur différents fournisseurs de serveurs situés à des endroits différents. Nous essayons de déplacer la production là où se trouve la mise en scène, car cela nous donne de meilleures performances. - cheese5505
La clé est simplement de passer de l’équilibreur de charge à une version de travail éprouvée. Avec ce modèle actuel, vous ne l'avez pas. - usr
La qualité d'un modèle dépend beaucoup de ce que fait le site. Si le site est apatride, tant mieux, mais s'il ne l'est pas, vous devez déterminer comment vous allez transférer cet état lors du basculement. - Peter Green
@ Peter Green est très difficile pour les sites Web car cela ne permet pas la mise en cluster et l'état peut être perdu à tout moment lors du redéploiement / redémarrage / crash / écran bleu, etc. Par conséquent, c'est très rare. - usr
@usr la plupart des sites Web ont un état. Cet état peut être stocké dans des fichiers ou dans une base de données. Dans ce dernier cas, la base de données peut être locale ou distante. Certaines mises à niveau ont probablement un impact sur cet état, ce qui signifie que la mise à niveau et la restauration ne sont pas aussi simples que le simple basculement du code. - Peter Green


Que ferez-vous si votre centre de données principal subit une panne, ce qui se produit de temps à autre dans tous les centres de données? Vous pouvez accepter le temps d'immobilisation, basculer vers un autre centre de données, exécuter en mode actif-actif dans plusieurs centres de données à tout moment ou disposer d'un autre plan. Quel que soit le choix, faites-le lorsque vous effectuez des mises à jour, puis vous pourrez mettre votre centre de données principal hors service pendant une mise à jour. Si vous êtes prêt à avoir un temps d'arrêt en cas de panne de votre centre de données, vous êtes prêt à le faire, de sorte que cela ne devrait pas être un problème lors d'une publication.


3
2017-11-28 08:24





Pour ajouter aux réponses précédentes:

  • Utilisez une stratégie de déploiement qui permette les retours en arrière et la commutation instantanée. Capistrano ou quasiment tout autre système de déploiement y contribuera. Vous pouvez utiliser des éléments tels que des instantanés de base de données et des liens symboliques pour pouvoir revenir rapidement à un état antérieur.

  • Utilisez une gestion de configuration complète, ne laissez rien géré manuellement. Des systèmes comme SaltStack, Ansible et Puppet en sont des exemples. Ils peuvent également être appliqués aux configurations de conteneurs Docker et aux boîtes vagabondes.

  • Utilisez HA pour vous assurer de pouvoir traiter les demandes lors de la mise à niveau d'un nœud. Si la mise à niveau échoue, descendez simplement le nœud et, une fois la restauration effectuée, remettez-la en place et votre solution haute disponibilité remarquera et transmettra à nouveau les demandes à ce nœud. HAProxy est un exemple, mais nginx fonctionne également très bien.

  • Assurez-vous que l'application est capable de gérer les instances simultanées, les référentiels de données centralisés utilisés pour les données non codées devant être stockées sur le disque, telles que le cache. De cette façon, vous ne pourrez jamais exécuter une application mise à niveau pour mettre en cache des fichiers d'une version différente. Cela serait fait en plus de purger les caches et de faire des échauffements de cache bien sûr. (La mise en cache est juste un exemple)

En général, je configure des flux de travail où les chefs d’équipe peuvent approuver les demandes de fusion à une branche spéciale qui effectue tout le travail de CI normal, mais qui, en dernier lieu, commence également à s’adresser aux nœuds de production. En gros, vous exécutez un déploiement manuel de CI sur une instance de production. Si cette instance ne génère pas de réponses non valides, interrompt ou fait des choses étranges pour vos données, vous mettez à niveau tous les nœuds à l'aide de la solution de CI de votre choix. Ainsi, si un déploiement fonctionne, vous savez que tous les déploiements fonctionneront pour une balise / validation spécifique.

À l'heure actuelle, il semble que vous exécutiez une application de production sur un seul nœud, avec un processus de déploiement, une source et une cible. Cela signifie pratiquement que chaque étape de ce flux de travail est un point d'échec qui, en soi, peut casser le site Web. S'assurer qu'une telle chose ne peut pas se produire est la base de tous les processus de CI, de haute disponibilité et de basculement. Ne pas exécuter un seul nœud, ne pas exécuter un seul processus de haute disponibilité, ne pas utiliser une seule adresse IP, ne pas exécuter un seul CDN, etc. Cela peut sembler coûteux, mais créer une copie de ce que vous avez déjà dans un rack sur un serveur doté de sa propre connexion coûte généralement moins d'une heure d'indisponibilité sur un site d'entreprise.


2
2017-11-29 04:12





Je suis globalement d’accord avec Michael sur chacun de ses points (https://serverfault.com/a/739449/309477).

À mon avis, la première amélioration que vous devriez apporter consiste à utiliser un outil de déploiement (Capistrano).

Cela vous permettra de vous déployer pacifiquement, puis de passer instantanément à la nouvelle version. Si quelque chose ne va pas, vous pouvez revenir instantanément à la version de travail, simplement en changeant le lien symbolique actuel en une version de travail.

Et Capistrano est assez rapide à gérer en premier (comparé à l’utilisation de tests et de CI, ce qui représente un investissement en temps plus important).

Deuxièmement, si l'argent n'est pas votre principale problème, vous devriez avoir un serveur de développement iso-prod pour tester votre application avant de la déployer en production. Utiliser un industriel solution (Ansible, Chef, Puppet) pour gérer les instances VPS.


0
2017-12-04 10:31