Support for relative URLs and discourse-only docker containers (PR #3155)

discourse
#1

This set of changes does two things. They are mostly unrelated but they were essential for us in building our Discourse instance and, I believe, they are generally useful.

  • Better support for RAILS_RELATIVE_URL: we have fixed numerous places where it wasn’t respected.

Running under a a relative URL (domain.com/forum/…) vs subdomain (forum.domain.com) is very useful from the SEO point of view, see, for instance, here.

  • Better support for deployments with external Postgres, Redis and nginx.

The repo contains a Dockerfile which builds an image that includes only Discourse itself. This makes it easier to deploy, e.g., in AWS, using RDS (hosted Postgres) and ElastiCache (hosted Redis). The repo also contains a fig.yml, which helps you use fig to do local development using an equivalent setup (the Vagrant-based setup still works just fine). The fig setup is documented in docs/fig.md.

GitHub

#2

You’ve signed the CLA, vgeshel. Thank you! This pull request is ready for review.

#3
#4

Closed while I fix test failures

#5
#6

You’ve signed the CLA, vgeshel. Thank you! This pull request is ready for review.

#7

The Dockerfiles belong in https://github.com/discourse/discourse_docker

#8

This doesn’t make sense, just switch it over to the application layout, don’t recreate the includes in another layout.

#9

This is already done for Rails.env.production, just reuse that code

(see bottom of file)

#10

This Dockerfile builds an image that contains just Discourse itself. It’s common for projects that support building as docker images of this kind of simple way to include a Dockerfile. The image built from this Dockerfile can be uploaded to a public registry - it contains nothing specific to the particular installation.

As far as I understand, the purpose of discourse_docker is quite different: it’s to let a user build and run their own, custom discourse docker image (which contains postgres, redis, nginx, and their configuration).

#11

I just needed access to the Discourse object which is not available in the no_ember layout. These changes are the minimum I could find to make that work. There are a lot more differences between the no_ember and application layouts than this, the page would look different if I changed the layout.

#12

Sorry, not sure what you’re referring to. Bottom of which file?

#13

Or you could just do an erb <script> and get the base_url that way?

#14

https://github.com/discourse/discourse/blob/d64d3aa2e289d99be79d8a1fa3d0294c90770c49/config/database.yml#L36

It builds the db config out of environment variables.

#15

The current arrangement is: when running with Rails.env.production, use environment variables. Otherwise, use database.yml. Are you suggesting I change that?

#16

Hmm… I think it could be changed so that in any mode, it uses what it finds in the env.

#17

Wouldn’t this break people who modify database.yml for development? I’m assuming the current setup exists for a reason…

#18

Well, the idea there is that in development, they wouldn’t be in the env, and it would just use what’s in the file. While in production, everything is specified in the env.

#19

Sure. I was trying to make this similar to all the other places where .ajax is called (which either use Discourse.ajax or $.ajax(Discourse.getURL('/path')... What you are suggesting would make for simpler/smaller code, but different from any other ajax call. Not sure which is better.

#20

Sorry, I’m not following. In production, database.yml is ignored and only environment is used. I thought you were suggesting to do the same for development/test. Did I misunderstand?