A test copy of the application in a sub-uri

[Jeffrey Jones]

Hello all.

I have been struggling with this setup for a while and was wondering
if (A) it is possible and (B) if anyone has any pointers.

I have a rails app that runs on Apache+Passenger. This site is running
in production environment and uses SSL

I would like to have another rails app running (Actually uat version
of the production app) in the sub-uri /test and running in the uat
environment. It should still be covered my the main site's SSL.

I have never quite managed to get it working but before I go into long-
winded details about what I have tried so far I just wanted to check
that I haven't been barking up the wrong tree.

Is the above setup possible? Any feedback would be much appreciated.

Cheers

Jeff

[dancinglightning]

Hi

> I have a rails app that runs on Apache+Passenger.

at / ?

> I would like to have another rails app running (Actually uat version
> of the production app) in the sub-uri /test and running in the uat
> environment. It should still be covered my the main site's SSL.

Why ? for the ssl ? in test ?

Still, I have tried and it didn't work out. I use subdomains
sucessfully.

Torsten

[Jeffrey Jones]

Hola torsten

On 31/08/11 02:41, dancinglightning wrote:
> Hi
>> I have a rails app that runs on Apache+Passenger.
> at / ?
>

Yes, at the root /

>> I would like to have another rails app running (Actually uat version
>> of the production app) in the sub-uri /test and running in the uat
>> environment. It should still be covered my the main site's SSL.
> Why ? for the ssl ? in test ?

Client is adamant that the test site must be covered by SSL as well due
to security policies etc etc.

> Still, I have tried and it didn't work out. I use subdomains
> sucessfully.
>

I am trying to find a solution that doesn't require us using up another
IP and certificate (Or getting an expensive wildcard certificate)
specifically for the test site so sub-domains are out.
> Torsten
>
I have tried various methods and never managed to quite get it working
in the manner I described, i am not sure if it is even possible to be
honest which is why I posted here. Thanks for the feedback

Cheers

Jeff

[wbr]

I've done a lot of experimenting with apache/passenger/rails
deployment options to cover a number of quirky and temperamental
customer requirements. I'm currently using subdomains to deploy our
"development" versions, but there's a lot of extra dns/ip-address/
apache-config work to set that up and keep it going. Once it's up,
however, it's the easiest to manage from a Rails standpoint, as each
application lives in a completely separate VirtualHost.

But your request got me thinking how nice it would be to get rid of
half my subdomains and half my VirtualHosts.

https://my.domain.com/some/rails/route
https://my.domain.com/dev/some/rails/route

So I tried it, and it appears to work well - as long as you use rails
url helpers to generate urls. If you have any hard-coded urls in your
views, you'll pop back up to the main domain and your "production"
app.

The trick is to use AliasMatch, PassengerAppRoot, and SetEnv
RAILS_RELATIVE_URL_ROOT in your VirtualHost.

Here's the basics of what it looks like:


DocumentRoot /www/myrails/public

<Directory /www/myrails/public/>
PassengerEnabled On
PassengerAppRoot /www/myrails/
RailsEnv production
</Directory>

AliasMatch ^/dev/(.*)$ /www/myrails-dev/public/$1
RedirectMatch ^/dev$ /dev/
<Directory /www/myrails-dev/public/>
PassengerEnabled On
PassengerAppRoot /www/myrails-dev/
RailsEnv development
SetEnv RAILS_RELATIVE_URL_ROOT /dev
</Directory>


Note that this technique is not rails-specific. Similar setup should
be possible with any Rack-based app served with Passenger.

[Jeffrey Jones]

Ahoi there wbr.

I don't think I ever managed to use AliasMatch and RedirectMatch in my
attempts; that might have been the part that was eluding me.
I shall give your setup a try and report back on how things go.

Thanks for the examples and explanation!

Cheers

Jeff

[Jeffrey Jones]

Hello wbr.

I merged your suggestions into my present vhost.conf file and it hasn't
exploded on me but there is one problem. The Gist and error message is
below:

The two environments are production (/) and uat (/uat)

https://gist.github.com/1182826

Basically, accessing the test URL DOES spin up the uat application
instances but I get a white empty screen in the browser. The logfile in
the gist above comes from the uat application log so it looks to me that
the uat application is not picking up on the RAILS_RELATIVE_URL_ROOT
environment variable.

Would this be an accurate view do you think? I am currently looking
through the rails documentation to see if I can set that inside the
program as a test.

Cheers

Jeff

[Jeffrey Jones]

Ah, I forgot to mention, these are rails 3 apps which may have something
to do with it. I am looking for ways to set the relative root for a
rails 3 app since the rails 2 way is deprecated, doesn't seem to be much
documentation on it or I am looking in the wrong places / using the
wrong search keywords.

[Jeffrey Jones]

Ok, some more experimenting.

Using the vhost setup provided by wbr.

A) Relying on the environment variable doesn't seem to work.
B) If I use config.action_controller.relative_url_root as in the
guides.rubyonrails.org then the app crashes on startup.
[ pid=25873 thr=158687540 file=utils.rb:176 time=2011-08-31 14:16:03.581
]: *** Exception ArgumentError in
PhusionPassenger::Rack::ApplicationSpawner (wrong number of arguments (1
for 0)) (process 25873, thread #<Thread:0x12eac268>):
C) If I manually wrap all my routes in a scope '/test' block then the
application works.

So for the moment I will do C) and set it so that it will wrap only in
uat environment.

If anyone has any other ideas I am interested in getting this working
the best way since my option of C) is a bit of a kludge at the moment.

cheers

Jeff

[wbr]

Ah yes, I'm still in Rails 2.3.something. One of my requirements is
that my apps live independently of how they're being served or where
from. I have no code in my Rails apps that knows anything about
domains or sub-uri's. I tried that in the beginning, and it was a
mess. Every time the customer changed something about where our apps
sit in their URL namespace, we would have a nightmare of cleanup.

I'm sure there's a way in Rails 3 - googling it shows that Rails 3
routes "scope" might be the answer.

[wbr]

Ok, after a night of experimenting, it looks like
RAILS_RELATIVE_URL_ROOT has been fixed in Rails 3.1. Here's what I'm
doing with it:

Same config as I mention above, plus one of the following...

1. Wrap all routing calls that you want behind the sub-uri in a scope.

In routes.rb

scope ENV['RAILS_RELATIVE_URL_ROOT'] || "/" do
map ...
resource...
...
end


2. wrap your config.ru "run" in a map.

In config.ru

map ActionController::Base.config.relative_url_root || "/" do
run Foo::Application
end


Don't do both.


I prefer the 2nd scheme, because it encapsulates all rack-based
routing, including the asset pipeline stuff and any other middleware
(which doesn't seem to work with the scoped Rails routes).

You can even "fake" your sub-uri behavior while serving with "rails
server".

RAILS_RELATIVE_URL_ROOT=/dev/myapp rails server

And just in case anyone's wondering, I prefer AliasMatch,
PassengerAppRoot, and SetEnv RAILS_RELATIVE_URL_ROOT over RailsBaseURI
and symlinks. If your document root is the public folder of one app,
and you want a sub-uri to point to your development version, it gets
ugly real fast using symlinks. Also, AliasMatch allows for great
flexibility - I've used it to create a single VirtualHost where I can
drop any number of Rails/Rack/Sinatra/etc apps into my /development/
directory and they're instantly deployed to mydomain.com/dev/appname

[Jeffrey Jones]

Hello wbr.

Excellent ideas.

I will try the 2nd option, I agree that that looks like the better one
and see if there is anywhere I can break routing inside the app.

Cheers

Jeff

[wbr]

Great... curious to hear how it works (or doesn't) for you.

Reading more about Rails routing in railsguides.com, it sounds like
routing scopes in 3.1 -should- be able to handle this sort of thing,
including calls to middleware rack apps. I've also noticed that even
with the config.ru trick, some of my url helpers ignore the relative
root. I haven't figured out the pattern yet, but I've seen other posts
on the net that talk about similar issues with asset management and
sub-uri's. So there may still be some lingering bugs.

[wbr]

Well, this is definitely going beyond the realm of Passenger, but
hopefully it will help others who stumble on this.

Looks like there IS still a bug in sass-rails in the final release of
Rails 3.1. sass-rails completely ignores RAILS_RELATIVE_URL_ROOT in
its asset helpers.

There is an issue tracked here
https://github.com/rails/sass-rails/issues/17

which references a patch here
https://github.com/bpaquet/sass-rails/commit/f83a59fe2052dc7ba8c2d0bc9c8a653fad47fb08

I installed the patch, and all is well now with sass asset helpers in
my 3.1 apps.

[Jeffrey Jones]

Welp, after running through the automated tests and using the site live
for a few days I have yet to run into a major problem.

There was one issue where I was using controller.controller_path as it
was returning different results but that was it (Fixed by matching
against the controller.fullpath instead).

I am not doing anything too funky with url_helpers so if there are
edge-cases I guess I am not coming across them.

As far as I can tell all is groovy.

Thank you very much for your help on this one.

[Jeffrey Jones]

Sorry, important point, the app tested below was a 3.0 one.