Déplacer un site Discourse vers un autre VPS avec rsync

Wiki de la communauté Adminsys
,
21

Salut !

J’essaie de suivre les étapes de @scottfsmith. J’arrive à faire fonctionner rsync. Il n’est pas important pour moi d’obtenir les changements les plus récents via rsync car je teste juste une nouvelle version de Linux avec mon site existant pour voir si tous mes plugins fonctionnent. Donc, je ne fais pas la deuxième exécution de rsync. Ensuite, essayer de faire ./launcher rebuild app produit des erreurs.

2022-12-13 14:43:01.974 UTC [59] LOG:  le système de base de données a été interrompu ; dernière fois connu à 2022-12-13 10:23:29 UTC
2022-12-13 14:43:02.075 UTC [59] LOG:  enregistrement de contrôle principal invalide
2022-12-13 14:43:02.075 UTC [59] PANIC:  impossible de localiser un enregistrement de contrôle valide
2022-12-13 14:43:03.137 UTC [56] LOG:  le processus de démarrage (PID 59) a été terminé par le signal 6 : Aborted
2022-12-13 14:43:03.137 UTC [56] LOG:  démarrage avorté en raison de l'échec du processus de démarrage
2022-12-13 14:43:03.231 UTC [56] LOG:  le système de base de données est arrêté
I, [2022-12-13T14:43:06.699692 #1]  INFO -- : 
I, [2022-12-13T14:43:06.711862 #1]  INFO -- : > su postgres -c 'createdb discourse' || true
createdb: error: impossible de se connecter à la base de données template1 : impossible de se connecter au serveur : Aucun fichier ou dossier de ce type
	Le serveur est-il en cours d'exécution localement et accepte-t-il
	les connexions sur le socket de domaine Unix « /var/run/postgresql/.s.PGSQL.5432 » ?
I, [2022-12-13T14:43:06.917008 #1]  INFO -- : 
I, [2022-12-13T14:43:06.917421 #1]  INFO -- : > su postgres -c 'psql discourse -c "create user discourse;"' || true
psql: error: impossible de se connecter au serveur : Aucun fichier ou dossier de ce type
	Le serveur est-il en cours d'exécution localement et accepte-t-il
	les connexions sur le socket de domaine Unix « /var/run/postgresql/.s.PGSQL.5432 » ?
I, [2022-12-13T14:43:07.007654 #1]  INFO -- : 
I, [2022-12-13T14:43:07.008155 #1]  INFO -- : > su postgres -c 'psql discourse -c "grant all privileges on database discourse to discourse;"' || true
psql: error: impossible de se connecter au serveur : Aucun fichier ou dossier de ce type
	Le serveur est-il en cours d'exécution localement et accepte-t-il
	les connexions sur le socket de domaine Unix « /var/run/postgresql/.s.PGSQL.5432 » ?
I, [2022-12-13T14:43:07.087098 #1]  INFO -- : 
I, [2022-12-13T14:43:07.087319 #1]  INFO -- : > su postgres -c 'psql discourse -c "alter schema public owner to discourse;"'
psql: error: impossible de se connecter au serveur : Aucun fichier ou dossier de ce type
	Le serveur est-il en cours d'exécution localement et accepte-t-il
	les connexions sur le socket de domaine Unix « /var/run/postgresql/.s.PGSQL.5432 » ?
I, [2022-12-13T14:43:07.167221 #1]  INFO -- : 
I, [2022-12-13T14:43:07.168041 #1]  INFO -- : Terminating async processes

Je n’arrive pas à en tirer assez pour trouver une solution. Certaines recherches suggèrent que le conteneur doit être arrêté mais il n’est pas démarré. Des idées ?

Merci
David

22

Je vous suggère de configurer un serveur de staging pour résoudre votre problème particulier.

D’après ces erreurs, il semble que la base de données soit corrompue. Vous devez arrêter la base de données pour obtenir un ensemble de données valide afin qu’elle puisse fonctionner. Le second rsync n’est pas facultatif.

1 « J'aime »
23

Impressionnant !

Un fil de discussion vieux de quatre ans et une réponse en 3 minutes ! :slight_smile:

Quoi qu’il en soit, il s’agit essentiellement d’un serveur de staging que je vise et j’utilise cette méthode rsync. Mais recommandez-vous de ne pas le faire de cette façon avec rsync mais d’utiliser une sauvegarde ? Je me souviens ne pas avoir obtenu tous les paramètres de personnalisation d’un serveur de staging précédent que j’avais configuré, mais peut-être que je me trompe.

Merci

1 « J'aime »
24

C’est ce que ce lien décrit.

Tout, sauf les plugins (qui sont dans votre app.yml), est dans la sauvegarde ; la base de données et les téléchargements sont tout ce qu’il y a.

1 « J'aime »
25

D’après mes tests de cette méthode, il semble suffisant d’exécuter ./launcher stop app avant le rsync initial. Bien sûr, l’une des raisons d’utiliser cette méthode semble être de maintenir le forum en cours d’exécution sur l’ancien serveur le plus longtemps possible, auquel cas il est évidemment nécessaire d’exécuter le deuxième rsync pour maintenir la cohérence. Mais pour le processus relativement courant de déplacement d’un forum vers un autre serveur et/ou hôte où une brève interruption est acceptable, j’aime vraiment la simplicité et la portabilité de cette méthode.

1 « J'aime »
26

C’est exact.

C’est exact.

Ma méthode préférée est de faire le rsync des certificats Let’s Encrypt et SSL, de mettre l’ancien serveur en mode lecture seule, de faire une sauvegarde, de restaurer sur le nouveau serveur, puis de changer le DNS (ou mieux, une adresse IP statique lorsque le nouveau serveur est prêt.

Mais si un peu d’interruption ne vous dérange pas, votre méthode est excellente.

2 « J'aime »
27

Je prévois de migrer vers un nouveau VPS en janvier après quelques problèmes récents lors de la mise à niveau de Discourse sur mon ancien Ubuntu.

Mes questions sur la migration d’une ancienne goutte Digital Ocean vers une nouvelle goutte Digital Ocean sont :

  • Je prévois de réduire le TTL de l’enregistrement DNS A la veille de ma migration à quelque chose de petit, comme 5 minutes. Cela vous semble-t-il raisonnable ?

  • Le premier message de ce fil a été modifié pour la dernière fois en juin 2016. Est-il toujours valide et correct ?

  • Cette méthode rsync copiera-t-elle également la base de données entière de l’ancien VPS vers le nouveau VPS ?
    – Nous sommes sur une installation standard

  • Le certificat SSL Let’s Encrypt existant sera-t-il également copié ? Le certificat SSL est-il lié ou associé à une adresse IP ? Continuera-t-il à se renouveler automatiquement ? Des pièges ici ?

  • À quel moment dois-je modifier l’enregistrement DNS A public pour qu’il pointe vers le nouveau VPS ?
    – Et aussi modifier le TTL pour revenir à quelque chose de plus élevé

28

C’est tout à fait correct.

Si vous utilisez quelque chose qui permet d’avoir une IP permanente qui peut être assignée à plusieurs VM, alors vous pouvez le faire de manière à ne pas dépendre du DNS pour effectuer le changement.

La seule précaution que j’ajouterais serait d’arrêter l’ancien site pour le rsync final, puis de le redémarrer en mode lecture seule pendant que le nouveau se reconstruit.

29

Le premier message affiche toujours le chemin incorrect /var/discourse/ :

Pourriez-vous modifier/mettre à jour s’il vous plaît ?

30

@Richie, @JammyDodger en a maintenant fait un wiki :+1:

2 « J'aime »
31

J’ai migré vers un nouveau VPS aujourd’hui et j’ai pensé partager mon expérience car il semble que pas mal de gens rencontrent le blocage du système d’exploitation de l’ancienne version sur leurs mises à jour ces derniers temps :blush:

Je suis sur Digital Ocean, j’ai donc créé un nouveau droplet.

Ancien VPS = Ubuntu Server 18.04.6 LTS

Nouveau VPS = Ubuntu Server 23.10

J’ai effectué le nettoyage habituel sur le nouveau VPS - veuillez modifier selon vos besoins :

Apt-get update

Apt-get upgrade

Apt-get install fail2ban

ufw default deny incoming

ufw default allow outgoing

ufw allow ssh

ufw allow http

ufw allow https

ufw enable

J’ai ensuite créé un nouveau répertoire vide pour Discourse :

sudo mkdir -p /var/discourse

Puis j’ai installé Docker :

wget -qO- https://get.docker.com/ | sh

Ensuite, j’ai changé le TTL de mon DNS de 30 minutes à 10 minutes (le minimum autorisé par GoDaddy).

Sur mon ancien serveur, j’ai téléchargé une copie locale de la sauvegarde de la base de données Discourse de la nuit dernière (on n’a jamais trop de sauvegardes locales). J’ai également téléchargé une copie de app.yml sur mon PC local.

Comme suggéré par plusieurs personnes ci-dessus, j’ai effectué un rsync de “root à root”. J’ai utilisé l’adresse IP plutôt que le nom d’hôte, afin d’éviter toute confusion DNS. Comme suggéré ci-dessus, j’ai utilisé les commutateurs -avz :

rsync -avz root@old.ip.address.here:/var/discourse /var

Pour référence, mon dossier discourse fait 25 Go.

Il a fallu environ 25 minutes pour le rsync de l’ancien serveur vers le nouveau. C’était simplement entre deux droplets Digital Ocean dans la même région LON1. Vos expériences peuvent varier.

Après le rsync et une tentative de reconstruction, j’ai rencontré la même erreur que celle rencontrée par @piratdavid concernant le système de base de données postgres database system is shut down.

J’ai donc arrêté l’application sur l’ancien VPS :

./launcher stop app

Et j’ai effectué un autre rsync, uniquement pour les modifications cette fois :

rsync -avz --delete root@old.ip.address.here:/var/discourse /var

Ensuite, j’ai redémarré l’application Discourse de l’ancien serveur et l’ai mise très rapidement en mode Maintenance - ceci afin que les gens puissent toujours y accéder et voir le message d’avertissement habituel de maintenance.

Cela me donne également le temps de travailler sur le nouveau VPS :blush:

J’ai mis à jour mon fichier HOSTS sur mon PC local afin de pouvoir accéder à Discourse sur le nouveau VPS sans avertissements / problèmes de navigateur.

Sur le nouveau VPS, j’ai ensuite exécuté :

./discourse-setup

Ceci afin qu’il puisse mettre à jour automatiquement les paramètres de RAM et de CPU dans le fichier app.yml.

J’ai ensuite effectué une reconstruction de l’application sur le nouveau VPS :

./launcher rebuild app

J’ai effectué quelques tests de base, tout va bien.

DNS mis à jour - travail terminé.

Merci pour ce sujet détaillé, tout le monde :smiley:

3 « J'aime »
32

Merci les gars, premier post mis à jour concernant les chemins /var/discourse.

1 « J'aime »
33

Si quelqu’un a des difficultés à effectuer un rsync de root à root parce qu’il a peut-être désactivé la connexion root sur l’ancien serveur, ou si vous voulez simplement le faire en tant qu’utilisateur non root, j’ai trouvé ce post utile pour comprendre comment utiliser sudo sur le serveur distant : https://askubuntu.com/questions/719439/using-rsync-with-sudo-on-the-destination-machine

Supposons que vous ayez un utilisateur, discourse, des deux côtés qui a des privilèges sudo. Sur la machine distante, vous allez modifier le fichier /etc/sudoers avec sudo visudo. Vous allez ajouter la ligne :

discourse ALL=NOPASSWD:/usr/bin/rsync

Ensuite, sur la nouvelle machine, vous allez exécuter (en tant qu’utilisateur non root) :

sudo rsync -avz --delete --rsync-path="sudo rsync" discourse@old.ip.address.here:/var/discourse /var

Cela vous permettra d’exécuter tout ce qui est décrit ici en tant qu’utilisateur non root. Si vous conservez l’ancien serveur, je retournerais dans le fichier /etc/sudoers et supprimerais la ligne que vous venez d’ajouter.

1 « J'aime »
34

Si je comprends bien, cela permet au plus gros du transfert de se faire pendant que Discourse est en cours d’exécution. La stratégie de restauration à partir d’une sauvegarde nécessite au moins un accès en lecture seule pour la sauvegarde et le déplacement de la sauvegarde vers le nouveau serveur (ou le transfert via un bucket S3). Pour les gros sites, cela peut entraîner un temps de lecture seule considérable que la stratégie rsync évite soigneusement.

Il serait peut-être possible de gagner un peu plus de temps de disponibilité en évitant d’arrêter PostgreSQL sur l’ancien système et en “corrigeant” le problème sur le nouveau système avec pg_resetwal. NB : Je n’ai pas essayé cela et laisser la base de données s’arrêter gracieusement est presque certainement une meilleure idée.

Je me demande s’il existe un moyen de démarrer Discourse en lecture seule ? Je soupçonne que le moyen le plus rapide est via la ligne de commande une fois le conteneur démarré.

Quoi qu’il en soit, merci d’avoir partagé votre expérience ! Cela semble être un processus utile à avoir sous la main. :slight_smile:

35

Très.

Tellement utile en fait, que je suis tenté de tout refaire pour créer un environnement de staging (sur un VPS moins performant), juste pour tester et anticiper tout problème avant de mettre en œuvre des changements sur la production.

1 « J'aime »
37

Bonjour,

Je suis en train d’essayer ce processus sur une ancienne instance Discourse dont je suis maintenant responsable de la maintenance – migration d’un Ubuntu EOL vers quelque chose de plus récent car toute mise à niveau échoue si j’essaie de la faire sur place – et bien que le rsync ait réussi, postgres n’arrive pas à démarrer en invoquant des problèmes de propriété de fichiers. L’exécution du rsync en tant que root avec les options de préservation de la propriété n’a pas corrigé cela (la propriété et les permissions des fichiers correspondent maintenant à la source, j’ai vérifié), et parce que le bootstrap a échoué et que je n’ai pas de conteneur en cours d’exécution, je ne peux pas tenter de corriger cela comme le décrit Update failed (postgresql) - #7 by noezDE.

Quelle est la meilleure façon de normaliser ce que postgres attend ?

38

Pouvez-vous chown les fichiers en dehors du conteneur ? Cela devrait être possible si vous avez les autorisations root/sudo.

39

Bien sûr, mais par rapport à quoi ? En dehors du conteneur, les permissions sont correctes et aussi complètement absurdes.

Source (fonctionnelle) :

root@ip-[...]:/var/discourse/shared/standalone# ls
total 54492
drwxr-xr-x 15 root       root         4096 Oct 22  2021 .
drwxr-xr-x  3 root       root         4096 Feb 28  2017 ..
drwxr-xr-x  3 ubuntu     www-data     4096 Feb 28  2017 backups
-rw-r--r--  1 root       root     55730645 Mar 15  2017 discussion.json
drwx------  7 root       root         4096 Mar  6  2017 letsencrypt
drwxr-xr-x  4 root       root         4096 Feb 28  2017 log
drwxr-xr-x  2 _apt       netdev       4096 Feb 28  2017 postgres_backup
drwx------ 19 _apt       netdev       4096 Sep 15 04:39 postgres_data
drwx------ 20 _apt       netdev       4096 Oct 22  2021 postgres_data_old
drwx------ 20 messagebus uuidd        4096 Apr  5  2018 postgres_data_older
drwxrwsr-x  5 _apt       netdev       4096 Sep 15 04:39 postgres_run
drwxr-xr-x  2 lxd        lxd          4096 Sep 16 01:03 redis_data
drwxr-xr-x  2 root       root         4096 Mar  6  2017 ssl
drwxr-xr-x  4 root       root         4096 Feb 28  2017 state
drwxr-xr-x  4 ubuntu     www-data     4096 Sep 15 04:39 tmp
drwxr-xr-x  5 ubuntu     www-data     4096 Apr 13  2017 uploads

Destination (endommagée) :

root@ip-[...]:/var/discourse/shared/standalone# ls -al
total 54488
drwxr-xr-x 15 root       root         4096 Sep 15 04:31 .
drwxr-xr-x  3 root       root         4096 Sep 15 04:27 ..
drwxr-xr-x  3 ubuntu     www-data     4096 Sep 15 04:27 backups
-rw-r--r--  1 root       root     55730645 Sep 15 04:27 discussion.json
drwx------  7 root       root         4096 Sep 15 04:27 letsencrypt
drwxr-xr-x  4 root       root         4096 Sep 15 04:27 log
drwxr-xr-x  2 _apt       netdev       4096 Sep 15 04:27 postgres_backup
drwx------ 19 _apt       netdev       4096 Sep 15 04:27 postgres_data
drwx------ 20 _apt       netdev       4096 Sep 15 04:30 postgres_data_old
drwx------ 20 messagebus uuidd        4096 Sep 15 04:31 postgres_data_older
drwxrwsr-x  5 messagebus tss          4096 Sep 15 04:31 postgres_run
drwxr-xr-x  2 uuidd      _ssh         4096 Sep 15 04:38 redis_data
drwxr-xr-x  2 root       root         4096 Sep 15 04:32 ssl
drwxr-xr-x  4 root       root         4096 Sep 15 04:31 state
drwxr-xr-x  4 ubuntu     www-data     4096 Sep 15 04:31 tmp
drwxr-xr-x  5 ubuntu     www-data     4096 Sep 15 04:31 uploads

Je suppose que ces identifiants pourraient avoir plus de sens à l’intérieur du conteneur, peut-être ?

40

Ouais, j’ai essayé le bruteforce des identifiants numériques de ls -aln et j’obtiens toujours le même échec.

2024-09-16 01:21:27.237 UTC [36] FATAL:  data directory "/shared/postgres_data" has wrong ownership

Je ne sais pas ce qu’il veut.

41

Je pense avoir eu une erreur similaire récemment.

Une supposition est que l’ancien conteneur et le nouveau ont des entrées /etc/passwd différentes. Vous pourriez comparer ces fichiers, je suppose.

Je pense que votre meilleure option est de restaurer à partir d’une sauvegarde. Je ne me souviens pas si j’ai fait cela ou si j’ai rendu quelque chose 777.