I’m looking into Discourse as a candidate for a forum in my project.
I am a bit surprised by how convoluted it is to actually run the stack.
On GitHub there is this instruction - it requires an SMTP server and a domain.
I also saw another guide which goes through the installation of the stack on the host directly. I’d prefer to rely on Docker to have all these dependencies set up
What also confused me is that the first guide put great emphasis on the fact that I need SMTP server, and DNS. This one does not mention that at all.
It seemed to me that since it is all dockerized, I should be able to just run some Docker Compose to have Discourse and the database (as I see it’s Postgresql) containers running (+ possibly some other containers, like caching if Discourse needs it). Then, in production, I’d probably host in on Kubernetes (seems to not be so easy as I’ve read in some thread).
Do you want a development install or a production install? If it’s the latter, then seeDiscourse official Standard Installation. Running under k8s is possible, but it’s not straightforward, as you need to use ./launcher to build the container. And doing a full no-downtime upgrade requires a few steps that are not immediately obvious. If you want it to be easy, just spin up a VM (a bit easier if it runs Ubuntu or Debian).
Yes, you need to be able to send email for production. For development, you obviously don’t need that.
@merefield Thanks for the Docker link. That works, and that’s close to what I imagined the process would look like. Although, it’s a bit weird that everything is packaged into one container. And yeah, it is slow.
What surprised me is that when I git clone discourse, and cd discourse, my shell becomes really slow - first time I see that . This repo must contain lots of files, or something, although I’m not sure why that would impact my shell.
@pfaffman I’d also like to try the installation that is closer to production one, to have an idea what the process looks like. I’m fine with installation on a VM. However, what about the SMTP server and the domain? The guide is very strict about these and says that I MUST have those.
And that would also be fine, but it’s just that I don’t fully understand some things:
why is the domain actually needed? Why localhost is not enough?
does the mail server need to point at the same domain as the domain I use for Discourse?
the guide also talks about subdomains - why subdomain? I.e., I’m setting up a VM on Azure, and the VM has some DNS assigned to it (like myvm.westeurope.cloudapp.azure.com) - isn’t that domain enough?
It’s for production and it requires https so you need a domain name. The azure one will work.
You don’t have to use the same domain name for the mail server as the hostname. A while back I changed discourse-setup to prompt for the notification email address.
Subdomain means just don’t use x.com but use y.x.com. That’s fairly established practice.
I have the same concern with you about the domain names for discourse. WHY LOCALHOST IS NOT ENOUGH?
I just only install discourse for my team to play but cannot without DNS. We tried to add DNS resource with localhost to the hosts file on my server to resolve but unsuccessful.
Does anyone try to run discourse without public domain?
No. If you want to run a development install you don’t need a hostname, but it works only for localhost. If you want your team to use it, you need a host name. If you have a team, surely you have a domain name? Just create some subdomain of whatever your company uses, pay $12 for a host name, or do the free trial.
Well for us – we don’t want discourse to be public. We want an internal discussion board. I’m with the others, localhost fails, install fails when you are just trying to give it a test run. Really off putting and the crazy scripts instead of the well known and standard ‘docker-compose up -d --build’ is alarming to say the least… I don’t know if I want to use this product because it takes itself too seriously… or at least somebody who wrote the launcher is.
Or maybe it was written before docker-compose was a viable utility and it still works on thousands of sites and a change would risk breaking them all for an edge case.
If the server has access to the outside world its not that hard to disable the https stuff, though I’ve not done it in a while.
You need a domain name, but it does not need to be on a public ip. If your server can access the internet (to download discourse and it’s pieces) then you can turn off the let’s encrypt stuff and it should work. I think you just need to delete the ssl and let’s encrypt templates in the yml file, but you won’t be able to use discourse-setup. Copy the standalone sample and edit it by hand.
It’s needed for several reasons. Although you can get a domain for free at FreeNom, however there has been a lot of controversy on how FreeNom handles data and user information so be careful if you choose to take that route.
