Thanks @riking. Can you elaborate a little more? Let us say I have a brand new virtual instance, which does not have any Discourse packages. And say I downloaded my latest version of my Discourse app image from my Docker hub which is tuned for personal use. Now I have latest Discourse Docker image on the new virtual instance. Can you describe how I should launch that image and start the service? Can I simply run docker run <image id>; or do I need to download launcher utility and execute launcher start app? My point is that I prefer docker run approach over relying on launcher for deployment.
All launcher start app does is turns conf file to a docker run command. In fact it outputs the docker run command it runs, you can cut-and-paste that 
No need to have launcher or anything installed on the box to run a Discourse instance. Launcher is simply a convenience.
2 Likes
Oh… I thought there are some magic happens inside the launcher but was not… Thanks for the clarifications! Okay, then I get more clear picture! Probably I can make a script to parse the docker command and generate Docker Compose yaml, so that I can use it for easy deployment.
Then… hmm… Discourse already has the good support… wonder why this lengthy thread began at the beginning… 
Just because it does not provide the Docker Compose yaml by default…? Anyway thanks for helping to understand.
6 Likes
Not that I have any serious complaints about the current monolithic image approach. In fact I am fairly convinced with the rationale given in this thread. I know that not taking the isolated container orchestration route is a compromise, but the consequences are well thought.
However, based on @jongnam’s last comment, I think it would be really cool to add a couple features in the launcher start app command:
- a
--dryrunflag to only output the generateddocker runcommand and not executing it automatically - a
--composeflag to output a minimal docker-compose file on STDOUT which is nothing but a reformatting of the generated run command
The latter would allow people to manually add more services (such as a local SMTP server), defining private network, or adjust certain parameters.
9 Likes
absolutely great suggestions, I would add that you also want a --stack so you can output the docker stack format as well which is around the corner.
PR totally welcome.
3 Likes
In case you missed this:
Thanks for the pointer. That was a fantastic read as I am still exploring stuff around Discourse. I wish, there was a built-in SMTP server solution as well. Currently, one has to use external providers or set it up manually.
I can give you an outgoing SMTP server image in no time at all, but it won’t help you much, because 99.9% of the work in getting outgoing e-mail setup correctly is in DNS (rDNS, SPF/DKIM), and in managing all the other crap surrounding mail delivery (like periodically checking blacklist aggregators and requesting delisting). That’s why we recommend an external mail relay for outgoing e-mail, because that is a lot of fiddly, specialist work that very few people want to deal with, and it isn’t something we can automate away. Contrariwise, if you’re dead set on running your own outgoing mail, setting up the MTA is the easy bit, so there’s not a lot of motivation to make the easy bit easier when the many hard bits are going to stay hard.
11 Likes
When I started running email servers under Linux, I had to port Sendmail myself, as no one else (who made the code available) had done so. I’m pretty good at it. When I finish moving off the server that I set up five years ago, I won’t be managing any mail servers that send mail. It’s just too freaking hard for all the reasons that @mpalmer outlined. The likelihood that whatever IP you get assigned is on some blacklist is insanely high. Even the email services like Mailgun and SparkPost have difficulty staying off the blacklists.
I’m not entirely convinced just how easy receiving mail is anymore, but I haven’t yet given up on that, and having Mailgun receive mail and then forward it to Gmail is annoying. I think I will soon add a $200 Discourse + Let’s Encrypt + direct incoming email install offering along side of my standard $99 Discourse Install.
4 Likes
Thanks @mpalmer and @pfaffman for insights. I think I am aware of these issues as I am also managing a hosted mail server (Exim4) for our current sites that are not on Discourse yet. I am certainly not denying the issues you people have described and actually I read such things here before as well, because built-in SMTP server seems like a well-requested feature (for me it was not a request, but a wish instead).
However, as far as my understanding goes, getting the IP address delisted from various blacklists is the real pain. Otherwise DNS records are not an issue and we end up doing that anyway even if we use third-party SMTP services.
Third party e-mail services will usually help you get your DNS settings correct, with checking tools and feedback. They also (especially for paid services) provide tech support. All of that would come back to here if we provided some sort of outgoing e-mail container.
At any rate, if you’ve got a mail server you’re happy with already, you don’t need to use a third-party mail service, you can just route the e-mail through your existing MTA.
2 Likes
Totally understandable!
Our email server is configured to listen from the localhost only. We are experimenting with Discourse on a very different system and do not want it to have any connection with the production environment. For now we are using one of the recommended SMTP providers for Discourse, if we decided to finally migrate our production forum to Discourse, and the email traffic grows then we might configure an Exim4 container and run it under the same private network, otherwise will configure a separate instance, open it to accept connections from elsewhere and put the firewall in place.
1 Like
Thanks for your quick reply @Falco in this other thread that was closed before I could respond. I hope this one isn’t too long of a response but I found a bunch of things that could probably either use clarification or an update to 2017 since the status of most of the problems that were outlined in that other post have solutions now.
A good number of things outlined in the initial part of that post really outlines the dated nature of the official response to why there is no docker-compose methodology being developed here.
For example:
You’re supposed to configure a docker-compose file in such a way that it does all of the ensuring itself. If the file fails to run it gives very comprehensive responses as to what is wrong. Also if you want to make things super easy for people you could even go the route of creating a tool where you could just cherry-pick a series of settings and things similar to the now defunct https://lorry.io which now only exists as a git repo https://github.com/CenturyLinkLabs/lorry-ui if it is what I think it is. You could just cherrypick what you need and it would format the YAML file correctly so no worrying about spacing etc like so many have trouble with Y.
I understand the desire to want to provide this help and if there needs to be that level of assistance to the average installer of Discourse then so be it but the base framework of assume some level of competence rather than the assumption of the complete lack thereof and using industry standard stuff is ideal.
This is officially supported in docker now.
docker images prune
docker container prune
docker system prune
Doesn’t the philosophy of using a custom script/wrapper technically just impose your own philosophy?
At least an attempt at some degree of documentation of this would be phenomenal even if only in the container on https://hub.docker.com with an example docker-compose.yml for the sake of getting people started.
Both of these reasons can be handled in docker-compose using a container that can be set to bootstrap only and then is shut down using docker-compose up -d bootstrap or something along those lines then followed by docker-compose stop && docker-compose rm -f bootstrap along with shared volumes or even direct host filesystem mounted volumes.
This all should mostly be done using either your own homebrew container that can handle upgrades. Along with environment variables passed into the CMD directives of the Postgres container or even just pull a specific tag from the discourse official repos.
configured correctly should be handled by Env vars and launched before see docker-compose version 3 depends_on Compose file | Docker Documentation
This can all be handled using a custom fork of the official repositories for Nginx under the discourse organization account on hub.docker.com with a custom launch script with Env vars and case switches.
I hope that I don’t come off poorly with making these criticisms I just see a lot of fringe cases that would be handled easier with a docker-compose file as the documentation can tend to make a lot of assumptions.
You can do whatever you want, just don’t ask us to support it.
1 Like
What I am struggling with here is understanding what problem our installers are facing today you are proposing to solve, and how
4 Likes
… not to mention how to handle all the things that still can’t be done with docker-compose. “there’s now only 17 reasons why you can’t use docker-compose, not the 27 you said there were!” isn’t particularly useful or interesting. The best way to demonstrate that docker-compose is capable of supporting Discourse is to do it.
5 Likes
When you try ./discourse-setup and have port 80 and 443 the installer script links you to a tutorial on this forum that doesn’t apply to servers that are already running something on port 80/443. This is what the discourse-setup script links you to but it doesn’t actually fix the problem because I don’t want to tear down my web services on 443/80 just to run the installer.
It assumes that the Discourse files are already setup somehow. So if this documentation is either incomplete or ineffective for scenarios like mine, which by the sounds of it have been consistent problems. It seems that rather than waiting on or relying on proper or complete or more clear documentation it would be ideal to use standards where your suggested philosophical agnosticism doesn’t have to apply.
The underlying issue that I keep seeing reoccur is the fact that many of these setup hurdles would be bypassed with switching to something where you wouldn’t have to document it.
You’ve even made suggestions that it might be in the cards to make a switch I was just trying to make compelling responses to all of the reasons that were proposed as to why docker-compose was unsuitable.
I’m not expecting you to do anything all that I was trying to do was discuss something that, according to the original post was open for some degree of discussion.
The suggestion was clearly not to have a short and unprofessional response like this. Ultimately if I were to be able to get this software running on my own server maybe one day I might make suggestions to other people to buy support from you guys but if this is a sample of the kind of reaction that would be received by your support staff if I were a paying customer I have to say I’d definitely avoid making the referral as much as I believe in this technology.
The suggestions that I made, I believed would have made a clear case as to why switching to docker-compose would not only be ideal for you but ideal for everyone. If it’s officially supported and documented by your contributors it would benefit everyone and not just me. This was part of the case that I made when I was trying to thoughtfully re-ignite discussion on the topic.
You’re not wrong, but ideally, the reason that I’m here talking about it is that its obviously not something that is working in my use case in its current state. If I personally had the ability to do all of the things that are being done using your software I would be doing that instead of whining about it to you people.
I assumed that if I came up with a reasonably well thought through response explaining how the other technology could potentially alleviate many of these issues could be beneficial to this project.
Truthfully I would love to do this myself and then submit a solution but the reason I’m even looking at Discourse isn’t so that I can start working for Discourse. I’m looking at Discourse because I want a discussion board that will suit my communities needs better than XenForo.
We don’t sell support, we sell hosting. So there’s that.
Switching to docker-compose has real costs (in engineering time), for very little benefit. Every time someone comes along and says “you should use docker-compose!”, we reply “show us how!” and then things go… eerily quiet. It’s almost like launcher does things that can’t be done with docker-compose… the best “well thought through response” would be a working demonstration of a launcher-less alternative.
If you have problems with any of the documentation here, please tell us about it in the relevant topic(s) so it can be improved. Tearing down everything and starting again just because a howto needs a tweak seems like an incredibly poor use of everyone’s time.
9 Likes