D’après le lien ci-dessus, je vois que les images et les pièces jointes sont stockées dans un dossier partagé plus profond dans l’installation de Discourse, pas à l’intérieur du docker. Sachant que j’aimerais utiliser un dossier d’images lié symboliquement depuis mon second stockage, que je monte en NFS vers d’autres serveurs. Et, sur un serveur secondaire, j’aimerais exécuter le conteneur docker de Discourse, comme moyen d’équilibrage de charge / de basculement… et j’aimerais utiliser le même dossier d’images depuis le montage NFS. J’ai déjà la base de données d’un autre serveur réseau, au cas où.
Je viens de tester le réglage, mais le résultat n’est pas bon. J’ai copié tous les fichiers image de /var/discourse/shared/standalone/uploads vers /var/www/image/uploads
Ensuite,
Créé des liens symboliques vers le dossier d’images monté en NFS
chmod & chown avec www-data:www-data et 755 pour les dossiers /uploads
Je peux voir les images sur le serveur principal où le dossier d’images est monté nativement, mais ce n’est pas le cas sur le serveur secondaire monté en NFS. Les images sont manquantes avec la taille du conteneur.
De plus, même sur le serveur principal, je peux voir, mais je ne peux plus télécharger l’image.
Je suppose que c’est dû à la permission des fichiers. Je me demande quel est le réglage idéal.
Je ne suis pas sûr si c’est du vanilla ou si c’est dû à des dizaines de rebuilds, mais les images dans le dossier par défaut sont 755/644 (dossier/fichier) et main_id:www-data sur mon serveur. J’ai également copié la même stratégie, mais cela n’a pas fonctionné. Il pourrait s’agir d’un problème spécifique aux liens symboliques ou au NFS, mais je ne peux plus suivre.
Plutôt qu’un lien symbolique, faites pointer le montage docker vers votre montage nfs.
Mais obtenir la synchronisation des permissions à l’intérieur du conteneur, à l’extérieur du conteneur et sur le serveur nfs distant peut certainement être délicat.
C’était ma première tentative. À l’intérieur du docker, j’ai trouvé que le système de fichiers était un peu désordonné, ce que j’avais déjà constaté. Il était imbriqué /uploads/uploads/uploads avant que /default/ ne soit visible. Je ne suis pas sûr de ce qui s’est réellement passé, mais j’ai copié tous les fichiers de l’intérieur vers mon montage d’image, et j’ai ajouté le dossier de montage comme volume.
Ici, la situation n’était pas très différente de celle d’un lien symbolique. Les permissions de fichiers créent en effet le même problème. Après avoir compris que les fichiers sont en fait stockés en dehors du conteneur Docker, j’ai pensé que le lien symbolique pourrait être une solution beaucoup plus simple.
Pour les deux, je suis presque sûr que c’est un problème de permission de fichier, mais un CDN personnalisé juste par bloc serveur Nginx semble une solution beaucoup plus simple que le volume docker, tant que le lien symbolique ne fonctionne pas.
Je suis à peu près certain qu’il n’y a rien de bon à tirer de l’utilisation de liens symboliques. Un problème est qu’il est difficile d’avoir le lien symbolique identique à l’intérieur et à l’extérieur du conteneur, et je suppose que votre problème de téléchargements imbriqués y est lié. J’ai vu qu’il était recommandé de ne pas utiliser de liens symboliques et je pense que c’est la raison pour laquelle.
Est-ce que Discourse prend en charge un CDN basé sur CNAME personnalisé ? Je me souviens avoir vu la configuration S3 dans l’administration et des publications sur Meta concernant Fastly, mais je ne me souviens pas bien de la configuration CDN personnalisée.
J’ai trouvé la publication. Je suppose que je dois configurer une version auto-hébergée d’un CDN compatible S3. Un simple serveur d’images Nginx ne suffit pas.