Je suis en train de migrer d’une configuration classique à deux conteneurs (conteneurs web_only et data séparés) vers une configuration où la base de données est hébergée sur un serveur de base de données central (pas à l’intérieur d’un conteneur Docker).
La base de données centrale a été créée à partir du dump.sql qui fait partie du fichier de sauvegarde. Le fichier web_only.yaml de Docker Compose utilise :
connexion à la base de données PostgreSQL centrale
Pendant la construction de web_only, j’obtiens l’erreur suivante :
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 741 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
L’hôte de la base de données est accessible avec ces données. Des idées sur ce qui se passe ici ? La même construction avec le conteneur de base de données standard se termine avec succès.
Êtes-vous sûr que la base de données distante est disponible depuis le serveur ? Il semble que non. Pouvez-vous utiliser telnet sur le port de la base de données depuis la machine du serveur web ?
> ÉCHEC
> --------------------
> Pups::ExecError: cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate' a échoué avec le retour #<Process::Status: pid 816 exit 1>
> Emplacement de l'échec : /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
> exec a échoué avec les paramètres {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
> bootstrap a échoué avec le code de sortie 1
Sur le nouveau système, les données doivent provenir de la base de données centrale au lieu de la base de données Docker si possible.
Concernant le DISCOURSE_DB_SOCKET : « » : comme nous utilisons une connexion à distance, je suppose que la valeur du socket n’est pas pertinente dans les deux cas (données dockérisées ou données distantes)
L’erreur se trouvait plus loin dans le journal de build :
…
docker_manager est déjà à la dernière version compatible
wp-discourse est déjà à la dernière version compatible
I, [2023-11-10T21:08:17.388213 #1] INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate'
Le nom du plugin est 'discourse-topic-voting', mais le répertoire du plugin est nommé 'discourse-voting'
rake aborted!
ActiveRecord::StatementInvalid: PG::InsufficientPrivilege: ERROR: permission denied for table users (ActiveRecord::StatementInvalid)
Alors bonnes nouvelles ! La connexion fonctionne, ce sont les permissions de la base de données qui doivent être ajustées.
… ok ok, il semble que j’aie encore des problèmes de permissions ici, voir /var/log/postgresql/postgresql-13-main.log :
2023-11-10 22:07:58.371 UTC [196127] postgres@postgres STATEMENT: ALTER DEFAULT PRIVILEGES IN SCHEMA 'public' GRANT ALL ON TABLES TO 'discourse';
2023-11-10 22:10:18.270 UTC [196160] discourse@discourse ERROR: permission denied for table site_settings
2023-11-10 22:10:18.270 UTC [196160] discourse@discourse STATEMENT: SELECT name, data_type, value FROM site_settings
2023-11-10 22:10:18.313 UTC [196160] discourse@discourse ERROR: permission denied for table users
2023-11-10 22:10:18.313 UTC [196160] discourse@discourse STATEMENT: SELECT COUNT(*) FROM (SELECT 1 AS one FROM \"users\" LIMIT 20) subquery_for_count
OK, comme toujours, c’était un « problème de couche 8 »
J’avais déjà une base de données discourse dans postgres, mais l’utilisateur/rôle discourse n’avait pas tous les privilèges requis sur celle-ci. Et j’ai manqué certaines différences « comportementales » majeures entre mariadb et postgres…
Maintenant, j’ai tout recréé : utilisateur, base de données, permissions pour l’utilisateur/rôle (y compris ALTER DEFAULT PRIVILEGES FOR ROLE discourse IN SCHEMA public GRANT ALL ON TABLES TO “discourse”; pour correspondre aux tables créées par cet utilisateur à l’avenir)
La construction est terminée et l’instance fonctionne bien avec le serveur postgres distant, elle est donc prête à importer la sauvegarde de l’ancienne instance.
