Après de nombreuses recherches et expérimentations, j’ai découvert que Docker Desktop sur Linux est à l’origine des problèmes de permissions.
En effet, l’application Discourse dans le conteneur Docker s’exécute en tant qu’utilisateur non root, à savoir l’utilisateur discourse. Mais comme écrit par exemple ici et ici :
Docker Desktop sur Linux exécute une machine virtuelle et les conteneurs s’exécuteront à l’intérieur de cette machine virtuelle. Dans ce cas, vous ne pouvez pas simplement monter le dossier hôte de la même manière dans les conteneurs, car vous devez d’abord le monter dans la machine virtuelle.
Ainsi, en tant que personne qui n’est en aucun cas une experte en Docker, je vois deux façons de résoudre ce problème :
(1) Abandonner Docker Desktop sur Linux et exécuter Docker nativement à la place
Cela semble être la solution la plus durable car je vois que le conteneur discourse semble être conçu pour être utilisé de cette manière. Je suis seulement hésitant car je devrai alors me souvenir de toutes les commandes pour gérer mes images, conteneurs et ressources. Et, étant un développeur frontend, je préférerais une interface utilisateur pour gérer les choses. Mais je suppose que je dois aborder cela comme un investissement pour en apprendre davantage sur Docker.
OU
(2) Changer la propriété des dossiers montés dans le conteneur
J’ai réussi à faire fonctionner cette approche et à exécuter Discourse avec succès localement depuis Docker Desktop, cependant je vois un tas d’avertissements dans le Terminal et je ne suis donc pas sûr de la durabilité de cette solution à long terme.
Cela implique plusieurs étapes :
Étape 1 : Cloner le dépôt
$ git clone https://github.com/discourse/discourse.git
$ cd discourse
Étape 2 : Initialiser le conteneur
Depuis le dossier discourse cloné sur la machine hôte, exécutez :
$ d/boot_dev
Que fait-il ? Voir ici.
Important : Omettez le drapeau --init afin que rien ne soit fait après la création du conteneur.
Étape 3 : Changer la propriété des dossiers
L’utilisateur discourse dans le conteneur docker a l’id 1000. Ce guide suppose que l’utilisateur de votre machine hôte a également le même id. Cela pourrait ne pas poser de problème si l’utilisateur de votre machine hôte a un id différent, mais je ne peux pas tester cela et donc je ne peux pas me prononcer sur cette situation. Vous pouvez trouver votre id en exécutant id ou echo $UID dans un terminal Linux.
Depuis votre machine hôte, exécutez :
# ouvrez un shell dans le conteneur docker
$ d/shell
# vous devriez déjà être dans /src, mais juste pour être sûr :
$ cd /src
# changez la propriété de /src à l'utilisateur et au groupe discourse
$ chown 1000:1000 .
# changez la propriété de tous les fichiers et dossiers dans /src à l'utilisateur et au groupe discourse (non récursivement)
$ chown 1000:1000 *
# changez récursivement la propriété de presque tous les sous-dossiers à l'utilisateur et au groupe discourse
# essentiellement tous les dossiers sauf 'database', car celui-ci appartient à l'utilisateur et au groupe 'postgres'
$ chown -R 1000:1000 app bin config d db docs documentation images lib log plugins public script spec test vendor
# vérifiez que cela a fonctionné, devrait maintenant afficher l'utilisateur et le groupe discourse
$ ls -l
# quittez le conteneur
$ exit
Étape 4 : Continuez comme d’habitude
Continuez à configurer le conteneur et à démarrer Discourse en exécutant ce qui suit depuis votre machine hôte :
# installez les gems
$ d/bundle install
# migrez la base de données
$ d/rake db:migrate
$ RAILS_ENV=test d/rake db:migrate
# créez un utilisateur administrateur
$ d/rake admin:create
# Dans un terminal :
d/rails s
# Et dans un terminal séparé
d/ember-cli
Remarque :
J’ai rencontré certains avertissements comme celui-ci :
fatal: detected dubious ownership in repository at '/src'
Qui provient de la virtualisation de Docker Desktop sur Linux.
Ignorez ces avertissements, depuis votre machine hôte, exécutez :
d/exec git config --global --add safe.directory /src
Pourquoi Docker Desktop pour Linux exécute-t-il une VM ?
