Je tente de comprendre la configuration “zéro temps d’arrêt”. Ma configuration actuelle comprend plusieurs instances Discourse pour différentes communautés. Les deux disposent d’une configuration de conteneur data/web 2. J’ai un Nginx au niveau de l’hôte qui gère la terminaison SSL et utilise une connexion socketée transmise au Nginx du conteneur.
J’ai trouvé ces deux sujets intéressants :
Je tente donc de comprendre ce processus. Il semble y avoir un certain niveau de connaissances supposées pour y parvenir. Toute aide que quelqu’un pourrait apporter ici serait excellente.
La première chose que je souhaite comprendre est de savoir comment déterminer quand un conteneur data doit être mis à niveau. Il semble qu’il existe des cas où vous ne pouvez pas simplement reconstruire le conteneur web. Comment puis-je savoir avec certitude quand c’est le cas ? S’agit-il de tous les cas où l’option de mise à niveau est grisée dans le panneau d’administration pour les mises à niveau, ainsi que potentiellement des travaux personnalisés sur les thèmes et les plugins ? Pourrais-je le savoir avec certitude en examinant les migrations du schéma de base de données ? Devrais-je avoir un environnement de test (staging) et simplement essayer pour le savoir avec certitude ?
La prochaine chose que je souhaite savoir est comment effectuer une mise à niveau sans temps d’arrêt. D’après la lecture des deux liens, vous reconstruiriez de toute façon le conteneur data et le conteneur web ? Je n’arrive pas à déchiffrer cela. Aurais-je besoin de conteneurs data/web séparés pour parvenir à un zéro temps d’arrêt à la fin ?
Toute orientation serait formidable ! Je pourrais probablement passer de nombreuses heures à découvrir quelque chose qui semblait fonctionner, mais je préfère m’appuyer sur les épaules des géants et éviter de découvrir les cas limites à la dure (en production) si cela est possible.
Si vous avez besoin de plus d’informations sur ma configuration particulière, n’hésitez pas à demander des clarifications. Je répondrai directement et mettrai à jour ce message.
Je ne connais pas grand-chose à la « migration post-déploiement », mais d’après ce que j’ai lu (ici sur Meta), une façon de procéder consiste à utiliser 3 conteneurs : 1 pour les données et 2 pour le web. Vous mettez à jour le conteneur web qui n’est pas en cours d’exécution, puis vous le basculez pour l’utiliser une fois la mise à jour terminée.
Je pense que cela a du sens. Donc le conteneur de données ne lance pas de reconstruction via le lanceur ? Je gérerais simplement l’équilibrage de charge au niveau de l’hôte avec Nginx. Laissez-moi voir si je peux organiser cela :
conteneur de données :
./launcher enter data_container
SKIP_POST_DEPLOYMENT_MIGRATIONS=1 rake db:migrate
Tout dépend des mises à jour nécessaires pour le conteneur de données.
La mise à jour de Postgres 12 est un bon exemple d’indisponibilité inévitable. Même si vous aviez un conteneur de données dupliqué, vous devriez mettre votre site dupliqué en lecture seule pendant la mise à niveau de la base de données.
La seule façon de ne jamais connaître d’indisponibilité est de ne jamais mettre à niveau. Les mises à jour via /admin/upgrade sur une installation à conteneur unique sont déjà sans interruption de service. Les mises à jour effectuées via ssh, comme lorsqu’il faut mettre à jour l’image de base, entraîneront des degrés d’indisponibilité variables selon votre budget et votre tolérance à la complexité.
La meilleure façon d’éviter les interruptions de service est de créer une copie de staging, sinon vous prenez un petit risque d’indisponibilité après chaque mise à jour lorsque des plugins ou des personnalisations rencontrent des problèmes de compatibilité.
D’accord. Donc, pour éviter tout problème majeur, effectuez un test en staging et observez les résultats… Je tenterais donc la procédure ci-dessus pour voir si le conteneur de données échoue.
Si c’est le cas, mon environnement de staging pourrait comporter 1 serveur de données et 1 serveur web, tandis que la production en aurait 2 de chaque. Dans le pire des cas, si l’opération est tentée d’abord en staging, voici la procédure à suivre en production :
Cela dépend de votre définition des temps d’arrêt.
Si les utilisateurs ne peuvent pas accéder au site, c’est un temps d’arrêt, c’est évident.
Si ils ne peuvent pas s’inscrire, publier, répondre ou aimer, considéreriez-vous cela comme un temps d’arrêt ?
Si c’est une grande communauté, les coûts liés à l’exécution de plusieurs conteneurs de données sur SSD seront considérables. Avez-vous envisagé un serveur PostgreSQL externe, tel qu’Amazon RDS ?
Les détails que @Stephen soulève sont vraiment importants. Parce que nous devons comprendre ce qu’est le zéro temps d’arrêt : par exemple, je pourrais contourner une exigence de zéro temps d’arrêt en faisant ce qui suit :
Je définis le zéro temps d’arrêt comme ne jamais répondre à l’utilisateur avec un code autre que HTTP 200 lorsque la requête est valide (en gardant les codes 300 et 400 ouverts si nécessaire). Ensuite, je déploie Discourse sur un droplet à 10 $ dans une solution mono-conteneur et j’ajoute Add an offline page to display when Discourse is rebuilding or starting up pour éviter les erreurs 500. De cette façon, je ne montre pas un site qui est en panne.
Est-ce que, dans un état d’esprit rationnel, je penserais que cela constitue un zéro temps d’arrêt ? Jamais. Est-ce que cela fonctionne comme proposé ? Bien sûr. Et je pourrais même ajouter un serveur de secours dans une autre région pour être encore plus à l’épreuve du zéro temps d’arrêt.
C’est pourquoi la qualification et la sémantique sont importantes. Ce n’est pas la même chose de toujours afficher quelque chose que d’avoir toujours une fonctionnalité sur le site.
Aidez-nous simplement à comprendre. De quoi avez-vous besoin pour atteindre votre définition de zéro temps d’arrêt ? Les utilisateurs peuvent-ils subir 10 à 30 minutes en mode lecture seule ? Avez-vous les compétences nécessaires pour bricoler une solution ? Cherchez-vous à offrir à nos utilisateurs une page élégante indiquant En maintenance, on revient tout de suite. Nous avons besoin de plus de détails pour vous proposer une solution précise qui fonctionne vraiment pour vous. Ou, à tout le moins, pour vous orienter dans la bonne direction.
Cette discussion commençait à devenir un peu tendue et hors sujet. Veuillez rappeler à chacun d’être respectueux lors des échanges sur un sujet. Les questions de clarification sont posées pour fournir une réponse plus précise, car les configurations et les objectifs de chacun sont différents.
jomaxro
(Joshua Rosenfeld)
A ouvert ce sujet ()
15
Ce sujet a été automatiquement ouvert après 13 heures.
et éviter de découvrir les cas limites à la dure (en production) si cela est possible.