Des idées sur la façon d'exécuter la maintenance sur un site qui est toujours en cours d'utilisation?


18

J'aide avec un grand site de jeux en Australie. Nous organisons des compétitions de 7h heure locale à 1h du matin le lendemain, tous les jours de la semaine. Nous n'avons pas sauté un jour 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 validations d'avance sur notre branche de production. Habituellement, le développeur principal doit se réveiller très tôt pour fusionner les branches et s'assurer que tout fonctionne correctement.

Nous avons essayé de rendre notre site de mise en scène aussi similaire que possible au site de production, mais nous ne pouvons que le rendre aussi similaire.

Notre site est basé au large de Laravel avec un serveur Node.JS en temps réel. Nous utilisons Laravel Forge.

Quelqu'un a-t-il des suggestions sur la façon dont nous pourrions pousser les mises à jour plus fréquemment? Nous sommes ouverts à tout.


Pourquoi un déploiement prend-il autant de temps?
Michael Hampton

@MichaelHampton Nos déploiements ne prennent pas longtemps, c'est juste que nous ne pouvons pas nous permettre le temps d'arrêt en cas de problème.
cheese5505

1
Je suppose que la question est alors la suivante: pourquoi un retour en arrière prend-il autant de temps?
Michael Hampton

@MichaelHampton, nous n'avons pas correctement examiné les annulations, mais nous faisons parfois de grosses mises à jour qui entraîneront la fermeture du site trop longtemps.
cheese5505

5
Quel que soit le temps nécessaire, c'est ce dont vous avez besoin.
Michael Hampton

Réponses:


22

Il y a beaucoup de choses que vous pourriez faire pour améliorer votre processus de déploiement. Certains d'entre eux sont:

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

    Idéalement, vous devriez avoir une couverture de test unitaire à 100%, ainsi que des tests d'intégration pour chaque scénario envisageable.

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

    Regardez dans le développement axé sur le comportement.

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

  • Exécutez une intégration continue.

    Chaque fois que quelqu'un valide une modification, CI peut alors exécuter automatiquement 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 changements 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 fournir un retour en un clic.

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

  • Faites des mises à jour atomiques.

    Idéalement, vous ne devriez pas simplement copier de nouveaux fichiers sur les anciens sur le serveur de production. Utilisez plutôt un outil tel que capistrano, qui copie chaque fichier vers un nouvel emplacement, puis utilise un lien symbolique pour pointer vers le déploiement souhaité. La restauration est instantanée car elle implique simplement de modifier le lien symbolique pour pointer vers le déploiement précédent. (Bien que cela ne couvre pas nécessairement la migration de votre 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, un IC ou rien, cela seul peut vous aider de manière significative. Chaque changement doit avoir sa propre branche git, et un déploiement doit avoir le moins de changements possible. Étant donné que les modifications sont plus petites, il y a moins de problèmes potentiels lors d'un déploiement.

    Sur cette note, apportez des modifications plus isolées chaque fois que possible. Si vous avez modifié le jeu Omaha et que cela n'affecte pas le Texas Hold'em, le stud à 5 cartes ou autre chose, alors c'est le seul jeu qui doit être suspendu pour une maintenance.

  • Analysez tout ce qui dure longtemps.

    Vous avez mentionné que certaines parties de vos déploiements prenaient beaucoup de temps. Il s'agit probablement de modifications du schéma de la base de données. Il vaut la peine d'avoir un regard DBA sur votre base de données, avec chaque changement de schéma, pour voir ce qui peut être plus performant.

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

  • Travailler des heures impaires.

    Vous le faites peut-être déjà, mais cela mérite d'être mentionné. Les développeurs (et les administrateurs système!) Ne devraient plus travailler "9 à 5", en particulier pour une opération 24h / 24 et 7j / 7. Si quelqu'un doit passer la nuit à surveiller un déploiement, à résoudre des problèmes, puis à respecter un horaire de jour, vos attentes sont irréalistes et vous configurez cette personne pour l'épuisement professionnel.


La solution la plus simple ici consiste à utiliser des scripts de déploiement dans un outil tel que Capistrano et peut-être même à effectuer l'équilibrage de charge également.
JakeGould

Merci pour le conseil. Nous allons examiner cela. Pour le moment, nous n'avons pas de suite de tests du tout, et j'aimerais vraiment y jeter un œil, mais le site est en développement depuis plus de 8 mois et est si grand qu'il faudrait plus d'une semaine pour en créer un. Nous exécutons Laravel Forge qui relie simplement la nouvelle version au dossier pour lequel nginx est configuré. Je ne peux pas travailler des heures impaires à cause de l'école, et il en va de même pour l'autre dev.
cheese5505

1
@ cheese5505 Je sais que c'est frustrant et que cela ne résout pas votre problème mais quand vous dites ceci, "… est si grand qu'il faudrait plus d'une semaine pour en faire un." cela semble manifestement ridicule. Tout processus de développement et de déploiement sensé permettrait de constituer un serveur en moins d'une journée ou peut-être de quelques heures à une heure. Vous devriez vraiment revoir ce que vous avez fait pour constituer ce tas 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

1
"Pour le moment, nous n'avons pas du tout de suite de tests" - corrigez cela maintenant , avant de développer de nouvelles fonctionnalités. C'est votre plus gros problème et ce sera un risque de disponibilité. Les tests automatisés contribueront grandement à prévenir les pannes et réduiront considérablement la douleur des opérations.
Josh

6

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 le temps mais la commodité. C'est normal et beaucoup de gens le traitent dans le cadre de leur activité.

Vous pouvez avoir un système 2 (ou plus) avec un frontal qui dirige le trafic vers celui qui est actuellement en ligne. Une fois que vous êtes satisfait qu'une version va fonctionner, vous dites à la partie frontale de passer au nouveau système. cela devrait être facile à écrire et à prendre un peu de temps.

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


Lorsque vous différenciez le backend du frontend, voulez-vous dire une architecture logicielle complètement modulaire? Ou une architecture de serveur telle qu'un équilibreur de charge?
JakeGould

2
juste quelque chose qui accepte les connexions et les transmet au backend principal actuel.
user9517 pris en chargeGoFundMonica

5

Modification des autres réponses: vous devez suivre le modèle de déploiement bleu-vert . Lorsque vous souhaitez publier une nouvelle version, vous la déployez sur un site Web de transfert interne. Ensuite, vous pouvez exécuter des tests automatisés sur le site de production de la prochaine version. Lorsque les tests passent, vous pointez l'équilibreur de charge pour utiliser le nouveau site Web.

Cela aide de la manière suivante:

  1. Les problèmes graves sont toujours trouvés avec zéro temps d'arrêt.
  2. Le passage à une nouvelle version n'a aucun 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 elle fonctionne toujours physiquement.

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


Nous avons déjà un serveur de transfert que nous utilisons pour tester, mais pour le moment, la production et le transfert sont sur différents fournisseurs de serveurs à différents endroits. Nous essayons de déplacer la production là où se trouve la mise en scène car elle nous offre de meilleures performances.
cheese5505

1
La clé est de devoir simplement basculer l'équilibreur de charge vers une version de travail éprouvée. Avec ce modèle actuel, vous n'avez pas cela.
usr

1
La qualité d'un modèle dépend beaucoup de ce que fait le site. Si le site est sans état, c'est parfait, mais s'il ne l'est pas, vous devez déterminer comment vous allez transférer cet état lors du basculement.
Peter Green

@PeterGreen, il est très difficile pour les sites Web d'être dynamiques car cela ne permet pas le clustering et l'état peut être perdu à tout moment lors du redéploiement / redémarrage / crash / écran bleu, etc. Par conséquent, cela 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 sont susceptibles d'avoir un impact sur cet état, ce qui signifie que la mise à niveau et la restauration ne sont pas aussi simples que de simplement basculer sur le code.
Peter Green

3

Que ferez-vous si votre centre de données principal subit une panne, ce qui se produit de temps en temps dans tous les centres de données? Vous pouvez accepter le temps d'arrêt, vous pouvez basculer vers un autre centre de données, vous pouvez exécuter en mode actif-actif dans plusieurs centres de données tout le temps, ou vous pouvez avoir un autre plan. Quel que soit celui-ci, faites-le lorsque vous effectuez des versions, puis vous pouvez supprimer votre centre de données principal pendant une version. Si vous êtes prêt à avoir des temps d'arrêt lorsque votre centre de données est en panne, alors vous êtes prêt à avoir des temps d'arrêt, donc cela ne devrait pas être un problème pendant une version.


2

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

  • Utilisez une stratégie de déploiement qui permet des restaurations et des commutations instantanées, Capistrano ou à peu près tout autre système de déploiement vous y aidera. Vous pouvez utiliser des éléments tels que des instantanés de base de données et des liens symboliques de code pour pouvoir revenir rapidement à un état précédent.

  • 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 que vous pouvez transférer les demandes lors de la mise à niveau d'un nœud. Si la mise à niveau échoue, descendez simplement le nœud et, lorsqu'elle est annulée, relancez-la et votre solution HA remarquera et enverra à nouveau les demandes audit nœud. HAProxy en est un exemple, mais nginx fonctionne aussi très bien.

  • Assurez-vous que l'application peut gérer des instances simultanées, a utilisé des référentiels de données versionnés centralisés pour les données non codées qui doivent être stockées sur le disque, telles que le cache. De cette façon, vous n'aurez jamais exécuté d'application mise à niveau pour mettre en cache des fichiers d'une version différente. Cela se ferait en plus de purger les caches et de faire des échauffements du cache bien sûr. (La mise en cache n'est qu'un exemple)

J'ai généralement mis en place des workflows où les chefs d'équipe peuvent approuver les demandes de fusion vers une branche spéciale qui effectue toutes les tâches normales de CI, mais comme dernière étape supplémentaire commence également à pousser vers les 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 à vos données, vous mettez à niveau en masse tous les nœuds à l'aide de la solution CI de votre choix. De cette façon, si un déploiement fonctionne, vous savez que tous les déploiements fonctionneront pour un tag / commit 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 peut à lui seul casser le site Web. Garantir qu'une telle chose ne peut pas se produire est la base de tous les processus CI, HA et de basculement. Ne pas exécuter un seul nœud, ne pas exécuter un seul processus HA, ne pas exécuter sur une seule adresse IP, ne pas exécuter un seul CDN, etc. Cela peut sembler coûteux, mais mettre un double de ce que vous avez déjà dans un rack sur un serveur avec sa propre connexion coûte généralement moins d'une heure de temps d'arrêt sur un site professionnel.


0

Je suis globalement d'accord avec Michael sur chacun de ses points ( /server//a/739449/309477 ).

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

Il vous permettra de déployer en toute tranquillité, puis de passer instantanément à la nouvelle version. En cas de problème, vous pouvez revenir instantanément à la version de travail, simplement en changeant le lien symbolique actuel vers une version de travail.

Et Capistrano est assez rapide à manipuler (par rapport à commencer à utiliser des tests et des CI qui seront un investissement en temps plus important).

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

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.