Nous avons apporté quelques modifications dans le conteneur de l’application, dans l’un des fichiers du répertoire /var/www/discourse/app/views/layouts.
Ensuite, nous avons pensé (comme des imbéciles) que nous pouvions simplement reconstruire le conteneur avec la commande /var/discourse/launcher rebuild app (ce qui n’est pas le cas), mais à chaque fois que nous le faisons, nos modifications sont écrasées.
Nous ne voulons pas faire un fork de Discourse, mais nous aimerions reconstruire l’application en utilisant launcher sans que cela écrase nos modifications locales.
Il semble que nous ayons trouvé la raison pour laquelle nos fichiers étaient écrasés dans l’application lors du processus de reconstruction :
La raison semble être que launcher télécharge l’image de base de Discourse, et cette image contient un répertoire .git dont la configuration pointe naturellement vers le dépôt principal de Discourse, ce qui entraîne l’écrasement de nos modifications :
launcher
pull_image() {
# Ajouter une nouvelle tentative pour contourner les erreurs TLS de Docker Hub
$docker_path pull $image || $docker_path pull $image
}
Auparavant, nous pensions à tort que launcher construisait l’image (comment avons-nous pu manquer cela ? !), et il est maintenant clair qu’il télécharge une image de base depuis Docker Hub.
Retour à la case départ !
Existe-t-il un paramètre que nous pouvons définir pour empêcher launcher de télécharger l’image de base et l’inciter à la construire à la place ?
Je suis tout à fait d’accord avec vous : les plugins et les composants de thème sont la meilleure approche ! Cette méthode est entièrement prise en charge et permet de rester en phase avec l’équipe de développement de Meta.
Il est également bon d’être curieux, d’explorer les possibilités et de comprendre Discourse à un niveau plus profond. Après avoir lu ce sujet hier, j’ai créé un registre Docker local, étiqueté l’image de base de Discourse localement, poussé cette image vers mon nouveau registre Docker (localhost), puis reconstruit une application Discourse en tirant l’image de base depuis ce registre.
C’est amusant, je pense, d’expérimenter et d’en apprendre davantage sur Discourse, et j’ai beaucoup appris grâce à cette exploration/expérience d’administrateur système. Bien sûr, ce n’est pas ainsi que nous exécuterions une application en production, mais j’ai beaucoup appris en suivant les étapes nécessaires pour extraire l’image de base de Discourse depuis localhost plutôt que depuis un serveur distant. C’était étonnamment simple, alors j’ai rédigé ce compte rendu d’expérience pour le partager avec d’autres administrateurs système curieux :
J’espère que d’autres explorateurs administrateurs système en tireront profit, même modestement.
Il existe une méthode très simple pour mettre cela en œuvre sans vous soucier des images ou de la création d’un plugin. À condition que vous ne modifiez que des fichiers plats existants, vous pouvez les modifier depuis le fichier app.yml.
Recherchez hooks et pups. Plusieurs autres guides utilisent déjà cette approche.
J’aime aussi apprendre et essayer de nouvelles choses.
Un jour, quand j’aurai le temps, j’essaierai d’en apprendre davantage sur Docker et les registres locaux.
Pour l’instant, je vais me concentrer sur le développement de plugins, car cela est pris en charge par Discourse et s’intègre bien dans le modèle de développement de Discourse.
Comme tu l’as dit, apprendre ces choses est amusant, mais il est aussi bon de rester dans le courant dominant !
Même après avoir expérimenté le registre Docker local et l’image de base Discourse locale, je n’ai pas pu obtenir des résultats cohérents (je ne sais pas pourquoi, il doit me manquer un détail clé dans la configuration).
En revanche, j’en ai appris davantage sur les registres Docker locaux et sur la façon de les construire et de les gérer.
Juste une petite expérience Docker en passant… j’ai beaucoup appris, c’est certain !
