Je crée une nouvelle instance de Discourse à partir de zéro à des fins de développement et je rencontre à nouveau cette erreur de bootstrap :
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate' a échoué avec le retour #<Process::Status: pid 1002 exit 1>
Emplacement de l'échec : /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec a échoué avec les paramètres {"cd"=>"$home", "tag"=>"migrate", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap a échoué avec le code de sortie 1
La configuration du conteneur se fait avec deux conteneurs pour webonly et dataonly (redis) et avec une base de données postgresql externe. Commenter les paramètres maxmind ne change rien.
La meilleure supposition serait que vous n’avez pas assez de mémoire - dans ce cas, ajoutez du swap ou passez à une instance avec plus de RAM. Essayez free -h.
Hmmm, non, nous avons 4 Go de RAM et beaucoup d’espace disque (2 x 32 Go), l’environnement global est le même que celui de l’autre machine Docker où les builds s’exécutent sans problème.
x86_64 arch détecté.
Mise à jour du lanceur en cours
Le lanceur est à jour
2.0.20250226-0128 : Extraction de discourse/base
Digest : sha256:6f18aa2cd22bba0deb91d69194e577d4f96130ad555ae8ec646a8792cbfe37db
Statut : L'image est à jour pour discourse/base:2.0.20250226-0128
docker.io/discourse/base:2.0.20250226-0128
/usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups.rb
/usr/local/bin/pups --stdin
18:C 19 Apr 2025 16:38:41.670 # oO0OoO0OoO0Oo Redis démarre oO0OoO0OoO0Oo
18:C 19 Apr 2025 16:38:41.670 # Version Redis=7.0.15, bits=64, commit=00000000, modifié=0, pid=18, vient de démarrer
18:C 19 Apr 2025 16:38:41.670 # Configuration chargée
18:M 19 Apr 2025 16:38:41.670 * Horloge monotone : POSIX clock_gettime
18:M 19 Apr 2025 16:38:41.670 * Mode d'exécution=standalone, port=6379.
18:M 19 Apr 2025 16:38:41.670 # Serveur initialisé
18:M 19 Apr 2025 16:38:41.671 * Chargement du RDB produit par la version 7.0.15
18:M 19 Apr 2025 16:38:41.671 * Âge du RDB 72606 secondes
18:M 19 Apr 2025 16:38:41.671 * Utilisation de la mémoire RDB lors de la création 0.82 Mo
18:M 19 Apr 2025 16:38:41.671 * Chargement du RDB terminé, clés chargées : 0, clés expirées : 0.
18:M 19 Apr 2025 16:38:41.671 * DB chargée depuis le disque : 0.000 secondes
18:M 19 Apr 2025 16:38:41.671 * Prêt à accepter les connexions
999:C 19 Apr 2025 16:39:59.006 # oO0OoO0OoO0Oo Redis démarre oO0OoO0OoO0Oo
999:C 19 Apr 2025 16:39:59.006 # Version Redis=7.0.15, bits=64, commit=00000000, modifié=0, pid=999, vient de démarrer
999:C 19 Apr 2025 16:39:59.006 # Configuration chargée
999:M 19 Apr 2025 16:39:59.006 * Horloge monotone : POSIX clock_gettime
999:M 19 Apr 2025 16:39:59.006 # Avertissement : Impossible de créer le socket d'écoute TCP du serveur *:6379 : bind : Adresse déjà utilisée
999:M 19 Apr 2025 16:39:59.006 # Échec de l'écoute sur le port 6379 (TCP), abandon.
18:gestionnaire-de-signaux (1745080813) SIGTERM reçu, planification de l'arrêt...
18:M 19 Apr 2025 16:40:13.541 # Arrêt demandé par l'utilisateur...
18:M 19 Apr 2025 16:40:13.541 * Sauvegarde du dernier instantané RDB avant de quitter.
18:M 19 Apr 2025 16:40:13.549 * DB sauvegardée sur disque
18:M 19 Apr 2025 16:40:13.549 # Redis est maintenant prêt à quitter, au revoir...
ÉCHEC
--------------------
Pups::ExecError : cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' a échoué avec le retour #<Process::Status: pid 1002 exit 1>
Emplacement de l'échec : /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec a échoué avec les paramètres {"cd"=>"$home", "tag"=>"migrate", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap a échoué avec le code de sortie 1
** ÉCHEC DU BOOTSTRAP ** veuillez faire défiler vers le haut et rechercher les messages d'erreur précédents, il peut y en avoir plus d'un.
./discourse-doctor peut aider à diagnostiquer le problème.
48b8aa6c912bbabc42d6b9373808088f5aa9079de1e1f7360fc858891a48556b
OK, j’ai corrigé la séparation de web_only et redis. Le message d’erreur est maintenant :
FAILED -------------------- Pups::ExecError: cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate' a échoué avec le retour #<Process::Status: pid 981 exit 1> Emplacement de l'échec : /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn' exec a échoué avec les paramètres {\"cd\"=>\"$home\", \"tag\"=>\"migrate\", \"hook\"=>\"db_migrate\", \"cmd\"=>[\"su discourse -c 'bundle exec rake db:migra te'\"]} bootstrap a échoué avec le code de sortie 1 ** ÉCHEC DU BOOTSTRAP ** veuillez faire défiler vers le haut et rechercher les messages d'erreur précédents, il peut y en avoir plus d'un. ./discourse-doctor peut aider à diagnostiquer le problème. 801049b69a89d38b1ae5c299d356fc5f8dc6a8f518b1260c2dde05e0b6081556
Mais peut-être est-ce un malentendu / manque de connaissances de ma part :
La base de données doit être externe sur un autre conteneur lxc qui a une base de données postgresql. L’utilisateur de la base de données et la base de données existent, mais la base de données est vide avant le premier bootstrap de web_only. Le script crée-t-il lui-même la base de données sur le système distant lors de la première construction ? Ou dois-je d’abord créer le conteneur de base de données, puis exporter manuellement son schéma par défaut et les données vers le démon postgresql externe ?
Merci pour le diagramme. C’est une configuration assez sophistiquée - vous le feriez si vous aviez une bonne raison et connaissiez le territoire.
Si vous voyez toujours ce qui suit, je pense que c’est l’indication de ce qui ne va pas. Redis ne peut pas ouvrir le port sur lequel il doit écouter.
Les questions portent donc sur le fait que redis devrait faire cela, dans ce conteneur, et si oui, où d’autre sur la machine une autre instance de redis est en cours d’exécution. lsof pourrait être un outil utile ici.
Salut @Ed_S
merci pour l’indice concernant le port manquant. Je veux d’abord attendre la réponse de Falco concernant mes questions sur la configuration générale de Discourse avec une base de données PostgreSQL externe.
Oui, la configuration est un peu sophistiquée par rapport à la norme avec un seul conteneur d’application. J’exécute tout sur une machine root dédiée avec Proxmox (https://p\u003eroxmox.com) comme environnement de virtualisation chez hetzner.de
Vous devez toujours partager les journaux complets, y compris la partie où la migration a échoué. Ma supposition (et c’est une supposition puisque vous n’avez pas partagé l’erreur) est que vous utilisez le plugin IA et que votre base de données n’a pas le module complémentaire requis.
# Use 'links' key to link containers together, aka use Docker --link flag. links: - link: name: data alias: data
Dans mon cas, le conteneur de données est un conteneur redis
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a27999b28a90 local_discourse/redis \"/sbin/boot\" 2 days ago Up 20 hours
donc name: redis and alias: data
Selon la documentation Docker, il s’agit d’une fonctionnalité obsolète, mais elle est toujours utilisable, voir Legacy container links | Docker Docs
Je pense maintenant que la meilleure approche serait de créer d’abord une configuration standard « tout-en-un » (app.yml). Et ensuite, faire un dump SQL du schéma et des données initiaux du conteneur vers une machine postgres externe. @Falco qu’en penses-tu ?
L’installateur créera automatiquement tout ce qui est nécessaire tant qu’il dispose d’informations d’identification valides et qu’il peut atteindre la base de données. Ceci est documenté dans Configurer Discourse pour utiliser un serveur PostgreSQL séparé
