Mes excuses si cela a déjà été demandé, j’ai cherché mais je n’ai pas vu le scénario exact que je prévois (ou je l’ai manqué, mais je veux m’assurer de bien faire car je ne l’ai jamais fait auparavant).
Je suis toujours sur la version 18 (qui est celle avec laquelle j’ai commencé ; je n’ai jamais mis à niveau mon système d’exploitation Linux, seulement les mises à jour de sécurité), donc bientôt je passerai à la version 22. Tout ce que j’ai lu ici suggère qu’il est beaucoup plus judicieux de migrer vers une nouvelle installation que de mettre à niveau celle existante, car il existe potentiellement une multitude de problèmes aléatoires qui peuvent ou non survenir, mais cela n’en vaut pas la peine car s’ils surviennent, ce n’est qu’un tracas inutile.
J’ai lu ce guide Move your Discourse Instance to a Different Server mais il fait référence au déplacement d’un serveur vers DigitalOcean (ou vice versa), ce qui rend le Snapshot inapplicable, alors que je prévois de passer d’un Droplet DigitalOcean existant à un nouveau (ce qui, selon plusieurs références, fonctionne bien et est idéal par rapport à une mise à niveau).
Donc, ma question pour un transfert DO > DO est : puis-je simplement arrêter mon Droplet, prendre un snapshot, démarrer un nouveau Droplet sur Ubuntu mis à jour que je souhaite, charger le snapshot, et voilà (ajuster l’enregistrement DNS pour le domaine, etc.) ? En contournant essentiellement la « réinstallation complète de Discourse » que le guide détaille. Je comprends que les snapshots sont censés être une copie identique 1:1 de l’installation sur le Droplet, par opposition à la sauvegarde qui concerne spécifiquement votre configuration Discourse et qui nécessite une installation complète pour être réellement utilisée. Est-ce que je comprends bien cela ? Y a-t-il des inconvénients à cela, autre qu’une interruption de service plus longue ?
tl;dr : puis-je simplement prendre un snapshot, créer un nouveau Droplet mis à niveau, charger le snapshot et avoir terminé ?
J’espère ne pas me tromper complètement, mais restaurer un snapshot de la version 18 sur la version 22 vous ramènera à la version 18, car un snapshot est une copie 1:1 de l’ensemble du droplet.
Pour moi, créer un tout nouveau droplet est toujours la dernière option, car j’ai besoin d’installer tout ce dont Ubuntu (ou quel que soit le système d’exploitation) a besoin, y compris le système de messagerie, etc.
Je suis tout à fait sûr que c’est une autre tâche triviale pour ceux qui savent le faire, mais après 10 ans, je n’ai jamais appris à démarrer facilement un nouveau droplet fonctionnel.
L’installation de Discourse prend environ 30 minutes ?
Faites simplement une sauvegarde de votre site et de votre fichier app.yml, créez une nouvelle instance sur la nouvelle version du système d’exploitation, réaffectez l’adresse IP à votre nouvelle instance (pour que le domaine pointe vers le bon endroit, le nouveau), installez Discourse (vous pouvez quitter l’assistant, mettre à jour app.yml, puis reconstruire) et importez votre sauvegarde.
L’ensemble de ce processus devrait prendre moins d’une heure.
Ce processus n’affecte jamais votre instance existante, donc si tout le reste échoue, il est très facile de revenir en arrière ?
Si je passe d’une version LTS du système d’exploitation à la version suivante, je m’attendrais à un processus assez fluide. Donc, je pourrais faire une sauvegarde - bien sûr - et la télécharger par sécurité - bien sûr - puis essayer la mise à jour du système d’exploitation. Si cela ne fonctionnait pas, je pourrais alors essayer un nouveau système d’exploitation.
Mais en faisant cela, j’aurais plus de temps d’indisponibilité du forum.
Je suis un peu réticent à migrer vers une nouvelle instance principalement parce que je devrais mettre à jour le DNS et attendre sa propagation. Bien que je voie que le message ci-dessus indique que je peux emporter mon adresse IP avec moi, ce qui est bien, et qui dissipe cette réticence.
En fait, en changeant entièrement ma réponse, si je peux emporter mon adresse IP vers une nouvelle instance, ce serait préférable. Il est possible que tous les fournisseurs ne le permettent pas. Il est possible que pour certains fournisseurs, on perde une adresse IP gratuite et que l’on commence à payer pour l’adresse IP, parce qu’elle a été déplacée même si elle n’a pas changé.
Une atténuation très simple pour cela est de simplement définir un TTL très bas (ou de remplacer les serveurs de noms par un qui prend en charge cela). De cette façon, les enregistrements expirent en moins de temps qu’il ne faut pour reconstruire.
Vous pouvez utiliser une IP statique (je ne me souviens plus comment DigitalOcean les appelle maintenant). En réseau, vous pouvez obtenir une nouvelle IP, puis la mapper à l’ancien droplet. Ensuite, vous modifiez le DNS et laissez-le se propager. Lorsque vous êtes prêt à passer au nouveau serveur, il vous suffit de changer l’IP pour qu’elle pointe vers le nouveau serveur. Cela se fait immédiatement et si quelque chose tourne mal, vous pouvez simplement revenir en arrière.
Cela a du sens, je n’avais même pas pensé au transfert du système d’exploitation.
Lancer un nouveau droplet serait aussi mon dernier choix, car je n’ai jamais déplacé de droplets auparavant (c’est le premier que j’ai) ni mis à niveau le système d’exploitation auparavant, mais tous les guides que je vois ici semblent recommander de le faire de cette façon plutôt que de simplement mettre à niveau le droplet sur lequel je suis, donc j’ai pensé autant suivre la majorité si les deux méthodes comportent des risques et que je n’ai fait ni l’une ni l’autre.
Ma pensée est aussi que si la mise à niveau échoue totalement d’une manière ou d’une autre maintenant, vous avez le temps d’arrêt de la tentative, vous avez le temps d’arrêt pendant que vous êtes obligé d’essayer de le réparer (ou d’abandonner et d’en créer un nouveau), par rapport au nouveau qui pourrait ne pas fonctionner pendant que votre original reste en marche et intact. Je ne sais pas pourquoi cela échouerait, mais en cherchant sur meta ici, il y a BEAUCOUP de gens qui disent que cela a échoué, ou des liens indiquant qu’ils ne recommanderaient jamais cette méthode (en plus des guides officiels ici et de DigitalOcean le suggèrent).
Je vais essayer ce week-end.
Adresses IP réservées (anciennement Adresses IP flottantes, apparemment).
Correct : si vous créez un fichier app.yml vide (par exemple avec touch app.yml dans le répertoire des conteneurs) et que vous y collez (soigneusement !) le contenu de votre autre serveur, vous n’avez pas du tout besoin d’exécuter ./discourse-setup.
Un problème qui m’a affecté cette semaine était ma configuration d’e-mail : assurez-vous que votre service d’e-mail n’exige pas l’adresse IP exacte à partir de laquelle vous appelez. S’ils le font, assurez-vous de mettre à jour cette configuration (chez votre fournisseur de services).
C’est pourtant la chose la plus sûre à faire. Si vous la cassez, votre ancien site continue de fonctionner. Il n’y a aucun risque.
Il y a un sujet à ce sujet. Vous pouvez copier votre fichier yml et les éléments de let’s encrypt et même voir que cela fonctionne en modifiant votre DNS local pour qu’il pointe vers le nouveau serveur.
Et si vous avez vos sauvegardes sur S3, vous pouvez dormir sur vos deux oreilles en sachant que si quelque chose tourne mal, vous pouvez démarrer un nouveau serveur et restaurer une sauvegarde en une trentaine de minutes.
Ma seule vraie préoccupation n’était pas tant de le déplacer, mais de passer par toute la configuration et de gâcher d’une manière ou d’une autre un paramètre, que ce soit le service de messagerie ou letsencryp ou quoi que ce soit, et de ne le réaliser que plus tard, une fois que tout s’effondre. Ce qui n’est évidemment pas un problème s’il peut simplement lire mon ancien app.yml, donc c’est bon.
Je ne suis pas entièrement sûr de ce que cela signifie, mais je ne pense pas que ce soit le cas… J’ai Mailgun et en vérifiant tous les enregistrements là-bas/DNS dans GoDaddy, rien ne semble être lié à une adresse IP spécifique.
D’accord, ça a l’air assez simple, je vais essayer cette semaine. Peut-être passer à un meilleur Droplet en même temps.
Je ne trouve pas le sujet dont je suis sûr qu’il existe. En bref, configurez les sauvegardes sur s3 dans vos paramètres d’environnement, rsync sur /var/discourse ou peut-être juste les répertoires ssl et letsencrypt et containers, puis reconstruisez.