csmu
(Keith John Hutchison - Ceiteach Seán Mac Úistin)
1
I’ve been asked to make a docker-compose file for a discourse project I’m working on to make it as simple as possible for developers and sysadmins we’re working with to fire up a discourse instance to test against.
I’ve read through Can Discourse ship frequent Docker images that do not need to be bootstrapped? and came away the notions that ./launcher was really necessary in order to keep the right versions of software in play, to make installation of plugins seamless and deterministic, and to enable software upgrades via the web UI, all ./launcher was doing was working out the correct command line options to send to docker, using docker-compose to build the image did not work given the complexities involved, and interestingly, that I could just use the docker image created by ./launcher and use that with docker-compose.
I rebuilt the app, copied the final command to launch the instance, converted that to a docker-compose.yml file and started the container. I just have the init scripts to go.
I’m thinking I’d have the scripts … the initial init scripts being accessible in the shared folder and getting using docker-compose run or docker exec to get to the bootstrapping.
Has anyone done this?
Are there any guides as to what subset of scripts need to be run is the base image has already been built?
Cheers and thanks
Keith John Hutchison
Background Research.
I’ve read through install-with-docker-compose and it works well enough … main issues is it’s slightly behind the official release, and there is no command line support for discourse and rails.
I’ve since discovered that adding discourse and rails command line support will be trivial as they are bash scripts.
The main issue here was I had to bootstrap the image which is something I’ve been asked to avoid.
I restored locally after running discourse enable_restore from a staging backup and it looks good.
I’ve investigated bitnami/discourse. It worked … main issues was it was a fair bit behind the official image, quite a bit different with paths and it was slower than Install with Docker compose
No. The only supported way to run discourse is through launcher. If you do it at other way, you’re on your own. If you use bitnami you will need to get support from them, and I’m pretty sure they provide none
If you have a budget, I might be able to help. My contact info is in my profile.
csmu
(Keith John Hutchison - Ceiteach Seán Mac Úistin)
3
G’day Jay
I wasn’t asking for help with Bitnami … that was just background. It would be too different from the staging environments that uses .launcher.
But is it simple if said image ends up not being representative, lags behind official releases and said developers and sysadmins are unable to get support here?
It’s always frustrating for users when tell them their install is completely unsupported, you’re effectively asking for guidance in building another unsupportable install. Do the IndieHosters understand that you/they will be totally on their own with this?
csmu
(Keith John Hutchison - Ceiteach Seán Mac Úistin)
5
I totally agree. That’s why I suggested to our dev lead not to use the bitnami/discourse images, why he asked me to research the best way forward and why I’ve chosen to use the image(s) created by ./launcher as suggested by
So the question for me now is, how to generate the base image(s) using launcher and bring up the environment using compose?
I’ve already tried using the image created by ./launcher rebuild app.
I’m about to look at ./launcher bootstrap app.
csmu
(Keith John Hutchison - Ceiteach Seán Mac Úistin)
6
… bootstrap is called by rebuild so there would be no difference in the resultant image …
The image from bootstrap is fine, in fact it is running here on meta, PG is running on AWS RDS, Redis in a dedicated container.
csmu
(Keith John Hutchison - Ceiteach Seán Mac Úistin)
8
I know the image is fine Sam. We’re using it on a staging server. I clearly understand that what is lacking here currently is my knowledge on how to run the scripts required to setup the shared folders within docker-compose.
I am super confused at why you would even want to involve compose.
This gives your devs an ultra easy setup path on local:
In production … why would you even think about deploying with compose? In general production container orchestration happens in either scripts or kubernates or some other dedicated production tool.
csmu
(Keith John Hutchison - Ceiteach Seán Mac Úistin)
10
It’s only for testing instances
csmu
(Keith John Hutchison - Ceiteach Seán Mac Úistin)
11
Mainly because I’ve been asked to by our team lead. His argument is when testing … he doesn’t want to rely on sysadmins, or devs knowing how to set up discourse other than doing docker-compose up -d.
csmu
(Keith John Hutchison - Ceiteach Seán Mac Úistin)
12
I agree … I followed the instructions and it didn’t take a lot of time to set up. The main issue I will have is selling the idea of running the scripts
I am not associated with the OP here, but I can tell you why I want a docker compose file rather than a shell script:
Shell scripts tend to not work on Windows.
The shell script requires git, my docker hosts only have a bare OS and docker installed. They are, by design, incredibly lean and bare.
Docker compose files can, with a little work, be converted to docker swarm files which can be run on my infrastructure and managed with docker swarm management tooling.
Every other piece of my infrastructure is managed via docker-swarm tooling. Having a single piece of infrastructure that is an outlier adds a large amount of cognitive overhead that I need to store somewhere and will certainly be lost/forgotten when it comes time to upgrade (every other piece of our infrastructure gets upgrades by just updating image version in docker swarm file).
What I would like to see is a template docker swarm or docker compose file that I can use, which references an image published to Docker Hub, and I can configure by just editing the various swarm file settings.
I haven’t yet tried running the scripts locally to see if I can extract the compose file, but it sounds like that is my best bet to not have Discourse be some oddball outlier in my system. I would prefer if I didn’t need to go run a script just to generate a sample docker-compose/swarm file and if instead I could just see one in docs or a gist or something.
Je souhaite pouvoir effectuer toutes les constructions Docker sur un serveur de build distinct de celui où s’exécute la production. À quoi sert Docker si cela nécessite un ensemble de scripts sur l’hôte ?
Sur mon hôte de production, je souhaite que Docker soit installé en mode swarm et que je puisse me connecter à mon registre pour télécharger les éléments nécessaires. Je veux également pouvoir exécuter, par exemple, trois instances de n’importe quel conteneur répartis sur trois nœuds (de sorte que tous les volumes ou montages liés à l’hôte soient facilement gérables).
Je suis tout à fait disposé à construire et à suivre exactement la méthode officielle prise en charge par Discourse sur un serveur de staging.
Le swarm Docker en production dont je parle inclura de nombreux autres produits sur le même cluster.
Je prévois d’inspecter tous les conteneurs de mon serveur de staging officiellement pris en charge par Discourse, de pousser toutes les images Docker préconstruites vers un registre et de tenter de les déployer sur le cluster swarm de production.
Si j’y parviens, je partagerai les résultats ici.
Je voudrais séparer les composants en plusieurs conteneurs. D’après ce que j’ai observé, la version officiellement prise en charge de Discourse traite Docker comme une machine virtuelle et exécute tout dans un seul conteneur (comment faire évoluer un seul composant si nécessaire ?).
Peut-être que la version open source prise en charge n’est pas volontairement compatible avec les gestionnaires d’orchestration afin qu’ils puissent obtenir des contrats pour gérer des déploiements nécessitant une mise à l’échelle massive. Ce modèle me convient parfaitement. Ils ont tout à fait le droit de gagner de l’argent en installant Discourse sur de grands systèmes de production déjà établis utilisant Swarm ou Kubernetes.
Je ne dis pas que c’est ainsi qu’ils génèrent une partie de leurs revenus, c’est une simple spéculation. Qu’ils le fassent ou non n’a pas d’importance ; je souligne simplement qu’ils ne sont en aucun cas obligés de prendre en charge autre chose que leurs mécanismes actuellement supportés. Il faut simplement reconnaître que la méthode prise en charge n’est pas compatible avec un cluster d’orchestration de conteneurs de niveau production.
csmu
(Keith John Hutchison - Ceiteach Seán Mac Úistin)
17
Ma compréhension est que cela vise à faciliter le support : CDKC utilise la version open source. Ils génèrent leurs revenus grâce à l’hébergement, ce qui finance le support gratuit qu’ils offrent à la version officiellement prise en charge.
Bonjour.
Nous sommes en mai 2020 et c’est toujours un domaine extrêmement controversé en termes d’utilisation.
J’ai lu tous les fils de discussion que j’ai pu trouver concernant le support actuel de Docker pour Discourse, et j’ai traversé les cinq étapes du deuil à ce sujet : je suis maintenant à l’acceptation.
Contexte :
J’ai un swarm Docker qui exécute tout pour nos sites et nos entreprises. Je ne veux pas acheter/maintenir des VPS supplémentaires uniquement pour héberger un forum.
Je souhaite simplement déployer l’image de Discourse sur celui-ci avec des conteneurs individuels afin de pouvoir mettre à l’échelle les différents éléments selon les besoins. Jusqu’à présent, j’ai échoué. Cela ne devrait pas être aussi difficile.
J’ai réalisé cela avec des bases de code bien plus complexes mais comparables, comme Gitlab et Sentry, en 1 à 2 heures chrono. C’est ma troisième semaine à essayer d’obtenir une solution fonctionnelle avec Discourse, et toujours aucune installation fiable.
Il me semble que…
Discourse est riche en fonctionnalités, existe depuis un certain temps et compte des contributeurs passionnés et compétents.
Discourse a été l’un des pionniers de la conteneurisation et a fait ce qu’il a fait en utilisant à la fois les outils et les connaissances disponibles à l’époque.
Les critiques sur la manière dont il fonctionne sont souvent accueillies avec de la défensivité.
Il manque des directives claires sur ce problème précis que de nombreuses personnes ont soulevé au cours des dernières années, et que beaucoup d’autres poseront à l’avenir concernant l’orchestration de clusters.
Le launcher, etc., convient bien pour une seule machine Docker ; c’est un script élégant qui répond à un cas d’usage courant. Mais mon expérience de son utilisation pour créer une image portable est un échec.
Des choses absurdes…
Les réponses passivement agressives aux préoccupations légitimes soulevées par des personnes qui tentent simplement de mener à bien une petite partie de leur travail.
Insister pour que le launcher soit la SEULE façon de faire fonctionner les choses.
Faire référence à une « documentation » dans des fils de discussion obsolètes et s’attendre à ce que les personnes passent des heures à lire ce contenu simplement pour installer quelque chose.
Nous pouvons faire mieux que cela.
La demande / l’offre
Je suis prêt à passer du temps avec quelqu’un qui connaît le fonctionnement du launcher pour créer un guide étape par étape permettant de réaliser des installations de conteneurs séparées et reproductibles, accompagné d’une vidéo.