J’ai d’abord essayé de faire fonctionner Discourse avec des paramètres semi-par défaut et cela a très bien fonctionné, j’ai pu télécharger des fichiers ainsi que faire d’autres choses.
Ensuite, j’ai réalisé que le chemin dans app.yml était /var/discourse et je l’ai mis à jour à /var/www/discourse, j’ai arrêté et détruit le conteneur, j’ai complètement supprimé le dossier précédent. Je l’ai remis en marche… mais j’ai remarqué que je ne pouvais plus télécharger de fichiers.
Quel type de permissions le dossier uploads nécessite-t-il ? Je peux faire quelques modifications manuellement, mais j’aimerais savoir exactement quoi et si c’est acceptable en général (le lanceur ne devrait-il pas s’occuper de définir les bonnes permissions, surtout lorsqu’il est lancé à partir de zéro ?)
Le chemin /var/www/discourse est le chemin vers discourse à l’intérieur du conteneur. /var/discourse est le chemin normal pour Discourse_docker à l’extérieur du conteneur.
Puisque vous venez de commencer, je vous recommanderais de recommencer et de ne rien renommer cette fois-ci.
Je suppose que vous n’avez pas mis à jour le chemin dans votre app.yml et qu’il essaie donc d’accéder à quelque chose qui n’existe pas.
J’ai beaucoup d’autres projets sur ce serveur et ils sont tous bien situés dans mon dossier /var/www, donc je préfère garder cela ainsi Et peu m’importe comment c’est à l’intérieur du conteneur.
Mais je l’ai mis à jour ? Dans les montages, ou où d’autre cela devrait-il aller ?
Exactement mon propos. Parce que votre proxy inverse nginx ne se trouve pas dans ce chemin, pourquoi le conteneur Docker le devrait-il ?
Mais un conteneur vit sa propre vie et le chemin vers le conteneur ne devrait pas affecter ce que fait son Nginx. Avez-vous également modifié autre chose ?
Ok, rien n’a fonctionné, j’ai donc fini par changer les permissions du dossier uploads à 755 et tout va bien maintenant. Après la reconstruction, il semble que les téléchargements eux-mêmes allaient bien (du côté du moteur), cependant nginx n’a pas pu les lire.
Je ne comprends pas tout à fait pourquoi vous faites tout cela. C’est votre choix de placer un conteneur dans un chemin qui sera visible mondialement si vous faites une petite erreur, mais c’est votre choix. Mais tout le reste… pourquoi ?
Avoir un proxy inverse devant Discourse est vraiment trivial et sinon votre configuration serait une installation standard sans tous ces tracas. Bien sûr, si vous voulez jouer et que c’est votre passe-temps, mais très bientôt quelqu’un se manifestera et dira que vous ne pouvez obtenir de support que pour une installation standard et le plus gros problème est que personne ne sait vraiment ce que vous avez fait. Ou pourquoi.
Vous corrigez un problème que vous avez rencontré en essayant de faire autre chose, ce dont une personne standard a besoin. Même avec un proxy inverse.
C’est pourquoi vous êtes assez loin du standard Parce qu’il y a deux options :
vous avez un bug entre les mains que personne d’autre n’a
vous avez fait quelque chose de drôle
Peut-être que c’est un bug. Et vous l’avez confirmé en faisant une installation standard en utilisant un chemin sûr (à bien des égards) et en connectant en même temps votre proxy inverse de la bonne manière. Parce que si c’est toujours cassé, je peux parier que le problème se situe dans l’hôte virtuel et/ou les ports. Mais si ça marche… alors nous revenons à l’option “drôle” — où personne ne sait ce que vous avez fait.
Voyez-vous le problème ici ?
Dans tous les cas, l’utilisation d’un proxy inverse entraîne aucun support… c’est la politique ici. Mais d’autres utilisateurs peuvent et aideront assez souvent.
Et peu m’importe comment c’est à l’intérieur du conteneur.
La situation est la même avec le conteneur Docker.
