The installation guide is pretty clear that one of the downsides of using a Virtual Machine to host Discourse is the potential performance hit. Lots of ram and multiple drives are recommended to help alleviate this. I assume the upsides are mostly that you can build/install a known environment, and that if it goes kerblooey, it doesn’t take other stuff down with it.
Now, I already have an Ubuntu server with hardware RAID drives, Postgres 9.1 and Ruby. Instead of installing a VM on my server, why not just install Discourse on the ‘real’ server?
Or, I have a spare server that isn’t even running right now. It would appear that running on a non-virtual machine means instead of steps 1, 2, 3, 4, and 5, I have just step 3, and that’s it. I’m just not sure what hidden downsides of non-virtuality might be.
Keep in mind that Docker is not virtualization (although it can be used in combination with it), it’s containerization. Its benefit is that all of the requirements for Discourse are packaged up in an easily consumable fashion, making it easier to deploy, support and upgrade. It does not reduce performance in any appreciable way.
Ah. “Docker?” I said to myself. “What’s that got to do with anything?” Bear with me here, I’m a part-time programmer. (More accurately, I’m a one-man band; I manufacture and sell small objects made from atoms with no moving parts. The servers I run and the software I write mostly go to support my business, so I have to be very careful about what I take time to learn. If I haven’t already needed it, I probably don’t know much about it.)
I went looking for the installation document that I’d referred to previously. Going to GitHub led me to both “Discourse As Your First Rails App” and, just a bit further down, the “Discourse Installation Guide”.
The Installation Guide says “The only officially supported installs of Discourse are the Docker based beginner and advanced installs, above. We regret that we cannot directly support any other methods of installation.” Seems fair.
However, what I’d seen previously (and I’m not sure the Installation Guide was even there when I did) was the “…First Rails App” document, which makes no mention of Docker at all. True, the Rails App is described as what one does for setting up a development server, and the Installation Guide is supposed to be for a production server.
Still, wouldn’t I make my life simpler by just using the Docker containerized install twice, once for the dev install and once for the production install?
Particularly since it appears that the mildly complex process of installing VirtualBox detailed in the “Rails App” document isn’t an officially supported way of doing it (any more?).
So what you’re saying is that some of the benefits of virtualization (in particular, some of the isolation benefits) can be had through the Docker containerization system without paying most of the VM performance penalties?
For actual development on Discourse, prefer Vagrant installed on your local machine.
For a staging server, yeah, I think two Docker installs would work. Hmm, can you have containers/app.yml containers/app2.yml? If you can get that to work, with a non-Docker nginx in front VHosting the two, you might be able to get a good setup.
In the sense of having two independent instances of Discourse running? Although, as I think about it, I’m not sure why I’d do that. It’s not like I intend to do any development work on Discourse itself.
Never mind, I retract the question. {slightly sheepish grin}
Sam’s blog says to use Ubuntu 12.04LTS, and that 13.10 specifically didn’t work at some point, but the GitHub page says 13.10 is acceptable. My current server is 10.04LTS, and since everything currently on it works, it’s going to stay that way. It’s agony that the 14.04LTS release is a month away, but I don’t think I want to wait that long, so I guess I’ll fire up the spare box and install 12.04 LTS.