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

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.

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.

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.

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.

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.

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.

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.