I get that discourse is a Ruby on Rails application. I set it up on a Digital Ocean droplet following these instructions. The instructions are awesome and it just works which is really great, but there’s definitely an element of magic to it, as a relative novice like me.
I have the feeling that the meat of the installation is in the “Clone the Official Discourse Docker Image into this /var/docker” step and that’s where I suspect the whole Ruby on Rails setup happens behind the scenes. I don’t have a good grasp of Docker, but I at least went here and watched the video.
So anyway, now I have an interest in using this Digital Ocean droplet to develop and host an additional custom Ruby on Rails application on a different subdomain than my Discourse site (in principle this could even be another instance of Discourse right?). I just don’t know where to begin though. If I ssh to my server rvm isn’t a recognized command, rails isn’t a recognized command. Can anyone offer advice/pointers on how to deploy my own rails app on the same server?
You can install ruby “outside” of the container and host another application, or another service on a different port and use nginx to direct requests between the two applications. You are correct that in theory this could be another discourse install… but you may want to look into the multisite configs.
Hm, this is a difficult topic to write about, because it touches many different aspects of Linux server administration and maintenance. I tried to type up a “quick overview” but realized it’d either turn into a freaking book or be full of holes and pitfalls and "you’ll figure it out"s.
So… on an even more abstract level, this is what you’d probably want to do:
Set up Redis, PostgreSQL and Nginx on your host.
Use the web_only.yml sample instead of standalone.yml.
Hack the web.template.yml or use a hook in your app.yml so that nginx isn’t started inside the container.
Wire it all together so that Discourse connects to Postgres and Redis on your host and the host forwards requests to the Unicorn running inside the container.
The most important thing to keep in mind is that “inside the container” and “outside the container” might, for these purposes, as well be two different computers. Most importantly, THE CONTAINER’S LOCALHOST AND THE HOST’S LOCALHOST (127.0.0.1) ARE SEPARATE NETWORK DEVICES! If Unicorn-inside-the-container is set to bind to 127.0.0.1:3000, then nginx-in-the-host will not be able to connect to it. Instead, refer to the Docker Advanced networking documentation; your goal is make Docker assign a predictable IP address to the Discourse container and have Nginx forward requests there.