Verwendung eines Launchers, der ein Docker-Image in Docker-Compose erstellt

Entwickler
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.

I’ve read through Beginners Guide to Install Discourse for Development using Docker and I got a local instance of docker running on my Mac.

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

2

Yes.

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.

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.

I’m following the lead from Can Discourse ship frequent Docker images that do not need to be bootstrapped? - #26 by sam which basically said using the output from .launcher is the way to go if you want to use docker-composer.

4

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?

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.

6

… bootstrap is called by rebuild so there would be no difference in the resultant image …

7

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.

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.

9

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.

10

It’s only for testing instances

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.

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

13

I am still not following at all, maybe ask your dev manager to post here explaining why our officially supported docker dev setup is a problem.

14

I asked if Beginners Guide to Install Discourse for Development using Docker would suffice.

The answer was yes.

15

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:

  1. Shell scripts tend to not work on Windows.
  2. The shell script requires git, my docker hosts only have a bare OS and docker installed. They are, by design, incredibly lean and bare.
  3. 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.
  4. 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.

16

Ich möchte, dass alle Docker-Builds auf einem separaten Build-Server stattfinden, getrennt von der Produktionsumgebung. Warum Docker nutzen, wenn es doch nur eine Reihe von Skripten ist, die auf dem Host erforderlich sind?

Auf meinem Produktions-Host soll Docker im Swarm-Modus installiert sein, und ich muss mich am Registry-Login anmelden können, um die benötigten Images zu pullen. Außerdem möchte ich in der Lage sein, beispielsweise drei Instanzen eines beliebigen Containers auf drei Knoten zu betreiben (sodass Volumes oder Bind-Mounts zum Host einfach verwaltet werden können).

Ich bin völlig damit einverstanden, auf einem Staging-Server genau die offiziell unterstützte Discourse-Methode anzuwenden und Builds durchzuführen.

Der von mir angesprochene Produktions-Docker-Swarm wird viele weitere Produkte im selben Cluster beinhalten.

Ich plane, alle Container auf meinem offiziell unterstützten Discourse-Staging-Server mit docker inspect zu analysieren, alle vorgefertigten Docker-Images in eine Registry zu pushen und zu versuchen, sie auf den Produktions-Swarm-Cluster zu deployen.

Sollte ich das erreichen, werde ich es hier teilen.

Ich möchte die Anwendung in mehrere Container aufteilen. Soweit ich gesehen habe, behandelt die offiziell unterstützte Discourse-Version Docker wie eine VM und führt alles in einem einzigen Container aus (wie kann man dann bei Bedarf nur eine einzelne Komponente skalieren?).

Vielleicht ist die open-source-unterstützte Version absichtlich nicht orchestrierungsmanager-freundlich gestaltet, damit sie Verträge für das Management von Deployments erhalten kann, die massive Skalierung erfordern. Dieses Modell passt für mich. Sie haben natürlich das Recht, Geld damit zu verdienen, Discourse auf großen, bereits etablierten, produktionsreifen Swarm- oder Kubernetes-Systemen zu installieren.

Ich sage nicht, dass dies eine ihrer Einnahmequellen ist, ich spekuliere nur. Es ist nicht wichtig, ob das zutrifft oder nicht; ich möchte lediglich darauf hinweisen, dass sie keineswegs verpflichtet sind, etwas anderes als ihre derzeit unterstützten Mechanismen zu unterstützen. Es muss einfach anerkannt werden, dass die unterstützte Methode nicht für produktionsreife Container-Orchestrierungscluster geeignet ist.

17

Mein Verständnis ist, dass dies der Vereinfachung der Unterstützung dient – CDKC nutzt die quelloffene Version; sie verdienen ihr Geld mit dem Hosting, was die kostenlose Unterstützung für die offiziell unterstützte Version finanziert.

Hier gibt es eine Anleitung zum Aufteilen der Container: Multisite configuration with Docker

Wir haben es geschafft, eine Instanz unter docker-compose zum Laufen zu bringen, also ist das, was Sie anstreben, definitiv machbar.

18

Haben Sie den Quellcode veröffentlicht? Es wäre toll, einige Beispiele zu sehen.

19

Wir haben eine ältere Version von libre.sh / compose / Discourse · GitLab als Vorlage verwendet. Damit sollten Sie gut starten können.

20

Hallo.
Es ist Mai 2020, und dies ist nach wie vor ein höchst umstrittenes Thema.

Ich habe jeden Thread gelesen, den ich über die aktuelle Discourse-Unterstützung für Docker finden konnte, und habe die fünf Stadien der Trauer durchlaufen – ich bin jetzt bei der Resignation angelangt.

Kontext –

Ich habe einen Docker-Swarm, der alles für unsere Websites und Unternehmen betreibt. Ich möchte keine zusätzlichen VPS kaufen oder warten, nur um ein Forum zu hosten.

Ich möchte einfach das Discourse-Image mit einzelnen Containern darauf bereitstellen, um die Dinge bei Bedarf unterschiedlich skalieren zu können. Bisher bin ich gescheitert. Das sollte nicht so schwierig sein.

Ich habe das mit weitaus komplexeren, aber vergleichbaren Codebasen wie GitLab und Sentry in ein bis zwei Stunden erledigt. Dies ist meine dritte Woche, in der ich versuche, eine funktionierende Lösung mit Discourse zu finden, und immer noch keine zuverlässige Installation.

Es scheint mir …

  • Discourse ist funktionsreich, existiert schon seit geraumer Zeit und hat leidenschaftliche und kompetente Mitwirkende.
  • Discourse war ein früher Adopter der Containerisierung und hat das damals mit den verfügbaren Tools und dem damaligen Wissen umgesetzt.
  • Kritik an der Art und Weise, wie es funktioniert, wird oft mit Defensivität beantwortet.
  • Es fehlt eine klare Anleitung genau zu diesem Problem, das viele Menschen in den letzten Jahren gestellt haben und das noch viele in der Zukunft im Zusammenhang mit Cluster-Orchestrierung stellen werden.
  • Launcher usw. ist in Ordnung für eine einzelne Docker-Maschine; es ist ein wunderbares Skript, das einem häufigen Anwendungsfall entspricht. Aber meine Erfahrung bei der Erstellung eines portierbaren Images damit war ein Misserfolg.

Dinge, die albern sind …

  • die passiv-aggressiven Reaktionen auf berechtigte Bedenken von Menschen, die nur versuchen, einen kleinen Teil ihrer Arbeit zu erledigen.
  • die Behauptung, dass Launcher der EINZIGE Weg sein sollte, wie es funktionieren sollte.
  • der Verweis auf „Dokumentation