Success - New Multisite Install on Dedicated server using ServerPilot, Nginx and Apache

@elberet hmmm, something isn’t quite right when changing the ports on the production sites

Changing the ports as you suggested on the app.yml file worked great, but after changing the two additional container files with the appropriate changes I get a 502 bad gateway error.

I made the changes to the exposed port, as well as the proxy_pass, I then rebuilt the the instance using ./launcher rebuild as well as restarted the Nginx server.

Any idea what’s wrong?

… Pops

EDIT: very weird … I was issuing the restart command for Nginx, but when I stopped it, and then started instead of “restart” everything is working fine

You can also stop exporting ports entirely by using web.socketed.template.yml:

4 Likes

I saw that post, but had a difficult time understanding how to implement it in the way my server is set up since Nginx is already installed and running in front of Apache.

It had to do with the last step, the path you referenced for sites-enabled an sites-available doesn’t exist and if I just needed to create them, I didn’t know how the files as a whole were to be set. (just a lack of knowledge on my part)

@PopsRocker Hi Pops!

Like you I’m trying to set up Discourse on DigitalOcean with ServerPilot, already running another website in a ServerPilot app (app named ‘test’). I only need a single Discourse site, so my setup will be simpler than yours.

Along with app#1 (test) hosting a website, I’ve got a 2nd ServerPilot app (named ‘discourse’) set up for purposes of pointing to the Discourse install. This gives me the /etc/nginx-sp/vhosts.d/discourse.conf and /etc/nginx-sp/vhosts.d/discourse.d/main.conf files.

So my question: what modifications did you make to your .conf files to get it to forward requests to discourse? I’ve got Discourse running and can access it from discourse.example.com:8888. What is it I need to do in the nginx conf files so that I can see Discourse at discourse.example.com, without appending the port number?

Thx

Sorry, replied too soon and then found my answer above:

in app.yml:

expose:
  - "127.0.0.1:8888:80" # fwd host port 80 to container port 8888 (http)
  - "2222:22" # fwd host port 22 to container port 2222 (ssh)

in /etc/nginx-sp/vhosts.d/discourse.d/main.conf (renamed to main.custom.conf as suggested):

location / {
    proxy_pass $backend_protocol://$backend_host:8888;
}

I’m still a little confused with this Serverpilot / Discourse setup. When you created your “discourse” app in Serverpilot, what did you put in the apps/discourse/public/ directory? I have my current discourse installation in the /var/discourse directory but am not sure how Serverpilot is suppose to recognize that?

You don’t actually have to put anything in the apps/discourse/public/ directory. Instead, you want requests to that Serverpilot app forwarded to your Discourse install living in /var/.

This is accomplished via the /var/discourse/containers/app.yml and /etc/nginx-sp/vhosts.d/discourse.d/main.custom.conf modifications referenced in my previous post.

1 Like

Thanks for your help! I was able to get it up and running.

I’m using ServerPilot too. Glad I found this article. I will let you know, how it’s worked up for me.
Thank you.

Thanks for the info on this. I know it has been a while, does anyone happen to know what kind of increase in resources on the system end up being consumed when you have a second one?

Maybe it’s because this post is from 2015 … but now I can not find the nginx-sp directory in my installation (I did it with the docker automatically).

I have all the second.yml completely changed, but I don’t know where it’s the nginx file to do the proxy thing.

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

This path should contain /standalone/ in it for the first site, no?

I wonder if there isn’t a confusion between multisite and WP+discourse in dual container setup? :face_with_raised_eyebrow:

We run multiple Discourse apps easily (on the same server) with one container for the data and one container for the app, for each “domain instance” we run.

In addition, for each “domain instance” we run two applications containers. This means there is zero downtime when we rebuild a container.

Why?

Because when “container a” is running, we rebuild “container b”; and after “container b” has rebuilt, we wait about 1 minute and we reconfigure the reverse proxy to proxy to the unix socket for “container b” and run (in the apache2 case) service apache2 restart.

This means there is basically zero downtime (maybe a few millseconds) when switching containers.

I have been following this thread in awe at how difficult (or complicated) many people are making something which is basically very simple.

Production Discourse runs in a Docker container; and the good Discourse team has provided the core templates to expose Discourse either a TCP/IP socket or UNIX domain socket (per application instance). In addition, the good meta team has provided the core template to run the data (PostgreSQL) container separately from the application (Rails, JS) container.

The exact same concept applies for any node.js application which runs in a container. These configurations (reverse proxies to containers) are basic Docker tasks which apply to any web applications which runs in a container, Discourse just happens to be one of them, and one of the best as we all know :slight_smile:

Sometimes I think the excellent team at meta Discourse makes spinning up their container so easy with their well done wrapper scripts, that users fail to understand that the underlying fundamentals of running a web-based Docker application behind a reverse proxy is really quite simple.

We can run just about “as many Discourse applications” as we like, as virtual hosts, no different than a webmaster would run 20 “old fashioned LAMP web apps” in the same server. The only difference is that instead of a virtual host to a directory of PHP files, there is a virtual host to (in our case) a UNIX domain docket. Docker makes this very efficient by sharing core libs and overlays between containers!

In addition, because networking between containers is built-in to Docker, it is very easy to set up Discourse (as an application container) to work with a PostgreSQL (data) container; which is provided for all users as a example template by the good meta team, for those who want to enjoy running Discourse in more “interesting” ways (configurations).

My advice, for what little it is worth, is to understand that Discourse is simply a web app running in a container behind a reverse proxy, like any web app. We also run our private Docker registry (more than one actually) in the same manner as well; a Docker application behind the same reverse proxy to port 5000 (the default Docker registry port).

Discourse, in their wisdom to make life easy for users (and Discourse accessible to non-sys admin gurus), provides the capability to expose the web applications directly (without a reverse proxy) in their OOTB configuration. In addition, setting up a reverse proxy outside the Docker container is the same for all of these Dockerized web applications. The meta team provides those templates as well (such great support if you think about it!).

In closing, it is very easy to run one, twenty, or more dockerized applications behind a reverse proxy. They are just containers (and all of them could be a different Discourse forum) and the choice of how to expose the containers are up the user (the sys admin) and so are the choices of how to set up persistant storage volumes including databases.

I think that this is so simple and the meta team has made it so simple for everyone; but one of the side-effects by making it so simple, is that people forgot (or do not learn) the fundamentals of how easy and elegant the dockerized configuration (behind a reverse proxy) actually is (independent of Discourse).

Hope this helps in some small way.

All the best!

5 Likes

It’s really simple…

Each application has its own shared volume and that volume is where the unix domain socket runs (and where all the other persistent data is like the uploads, etc.)

You do not need to work with docker-compose directly, special pup directives, or change anything at all (only set up the basic yml files correctly for the containers, and run launcher).

If one of your Discourse sites / apps is called “farmer_forums”, then your unix socket is located (by default), for example:

/var/discourse/shared/farmer_forums/nginx.http.socket

If your next Discourse site / app is “race_car_forums”, then your unix socket is (for example) here:

/var/discourse/shared/race_car_forums/nginx.http.socket

You can do this for 100s of forums, if you wish; and each one is just an entry in a reverse proxy to that socket. Just name your container yml files appropriately.

Each one of those forums will have their own data container as well. You can use any naming convention you like for those containers for example

  • farmer_forums_data
  • race_car_forums_data

Of course, each one of those will have their own shared volume for their database(s).

All you need to do is to create one working “two container solution” and replicate it behind a reverse proxy. Creating one site, or 100 sites, it is all the same if you follow this simple method.

PS: I have heard (read) some people try to have one database container for many different forums. I would never recommend that, personally. That configuration creates a single point of failure for all forums and is not how I like to do things “keep it simple and stupid” (KISS). But, I like KISS in sys admin, because I have fat fingered things over the decades more than once :slight_smile: and so I don’t like breaking more than I have too when I make a mistake (which we all do, from time to time).

So, if you are struggling with this; just get one site up and running with two containers, the app and the data container, behind a reverse proxy.

Then just replicate that, as many times as you want, with an app and a data container for each site. All your container names must be unique and should follow some easy to remember naming convention like in the farmers and race car samples above.

I’m not trying to sound repetitive nor preachy., but it is almost trivial to set up many Discourse sites behind a reverse proxy in this manner.

Hope this further explanation helps, in some small way.

In a nutshell, for me “multisite” simply means doing the “two container” solution behind a reverse proxy, multiple times, as many times as you wish! :slight_smile: One or ten, it’s all the same configuration, basically, only the names of the containers are different, and there is some “easy to understand” container naming configuration (like in the two examples above). Docker will share the libs and overlays appropriately between images, so there is “nothing to do here” because “that is what docker does” (sets up all the shared libs, builds the docker network, etc) all by itself, which makes this “efficient” due to how docker shares libs, between images, etc.

5 Likes

Maybe we should call this setup something else than multisite (which in my mind shares the data container cf the howto topic closed by sam earlier last year)
Parallel site? :crazy_face: i don’t know…
If i’m not mistaken, since you have an .yml file per data/web couple containers, you can specify different plugins set and smtp per domain?

Yes, of course. You can have all the same plugins or all different ones, obviously.

You can configure your SMTP host with the same SMTP information (if your provider has the capability) or separately. I use the same SMTP host when I set up in this manner, but we don’t have much traffic because I disable digests; but this is a totally different (unrelated issue), how to set up SMTP mail.

Regarding “what you call it” … well when we set up 20 LAMP apps on a server, we do not call that “parallel hosting”, so I do not think the name is important. You can call it what ever you like!

The point is that, it is easy to set up and works flawlessly.

Others are welcome to make things as complicated as they like. As mentioned, I am a KISS sys admin, and I like thing simple, easy to setup, and replicate fun and reliable. If you love complexity, do not follow this method, as it is too simple :slight_smile: and does not require a lot of discussion :slight_smile: but it works flawlessly and with other web apps on the same proxy, no problemo!

As a site note, I think many people want to run multiple discourse sites on the same server, in a manner similar to this. Running many discourse sites as virtual hosts behind a reverse proxy is the same as running any web app behind a reverse proxy. Personally, I prefer to keep thinks simple (KISS) as mentioned.

All the best and stay creative!

3 Likes

I also believe your setup is not concern by the fact that some plugin are not compatible with multisite?

It sure seems the way to go for beginners like me

2 Likes

Exactly. This KISS configuration has no constraints like that issue above at all

All plugs work normally and need no special hooks or modifications. It’s KISS :slight_smile:

It’s Zen and the art of sys admin :wink:

2 Likes