Euh… 
Le script n’a même pas besoin d’accéder à /var/discourse (pourquoi le fait-il ?).
L’ensemble du problème découle de quelques éléments :
- une énorme incompréhension de ce qu’est docker, de son fonctionnement et de ce qu’il permet
- le collage de la notion que docker = docker-compose (ce n’est pas le cas !)
Vous pouvez avoir une configuration complètement contenue qui ne touche pratiquement pas l’environnement hôte…
Après avoir pas mal fouillé, il semble que tout le script de “configuration” ait été créé pour rendre l’installation aussi simple que possible pour la personne très peu technique. Il vérifie, guide l’utilisateur et configure tout. Cela peut être une bonne chose, mais cela échoue complètement dans tout ce qui tente de s’écarter, même d’un tout petit pouce, du chemin envisagé.
Dans la configuration la plus basique, vous n’avez peut-être même pas besoin d’accéder à des répertoires hôtes - tout sera contenu dans un environnement limité (l’image sera utilisée pour créer le conteneur et tout le stockage requis sera géré via des volumes docker [cela pose des problèmes lorsque vous souhaitez migrer ailleurs ou accéder aux fichiers, mais nous parlons des bases]).
Il essaie également de s’assurer que le DNS est correct, essaie de configurer les certificats, le proxy inverse, le SMTP et autres - encore une fois, c’est tout à fait normal de fournir cette configuration facile.
MAIS !
Le problème n’est PAS de jeter cela mais de fournir EN PLUS une image docker simple (elle existe déjà, elle est utilisée par les scripts et les modèles utilisés par le script ! discourse_docker/templates/postgres.template.yml at main · discourse/discourse_docker · GitHub & discourse_docker/launcher at main · discourse/discourse_docker · GitHub) avec
- un versionnement approprié : vous étiquetez l’image avec la version de discourse publiée (3.4.5 ou autre)
- une documentation saine et simple des variables d’environnement attendues (pilotant la connectivité de la base de données/redis/etc.) et des chemins/volumes possibles qui peuvent être montés sur l’hôte.
Juste ça…
Jetez un œil au guide miniflux mentionné précédemment : Miniflux Installation with Docker - il vous donne des détails sur l’image (et quels dépôts les servent) et les variables d’environnement possibles pour la configurer.
Ou l’image docker MySQL : https://hub.docker.com/_/mysql - la même chose - un guide qui explique ce qui est possible de configurer (voir surtout la section : “Variables d’environnement”).
Personne ne dit : “vous devez utiliser le lanceur mysql pour construire l’image mysql afin de pouvoir l’utiliser”, ni redis d’ailleurs - dans ce cas, vous utilisez simplement les images existantes et c’est l’indice et l’essence de l’utilisation de docker. Pourtant, dans le cas de discourse, soudainement, c’est une mauvaise solution et tout le monde crie : “vous devez construire votre propre image !” – pourquoi !?