Apache/ColdFusion 9 per-directory application isolation

Report · Oct 30, 2009

With CF9 enterprise, I'd like to connect to multiple CF instances in a single Apache virtual host.

For example,

mydomain.com/app1 -> handled by instance1
mydomain.com/app2 -> handled by instance2

It seems most people accomplish this by using separate vhosts, but I was wondering if this could be done at a directory level. I've tried using <Directory> and <Location> stanzas with their own JRunConfig directives, but they end up overwriting the JRun config for the entire virtual host.

If anyone knows of a built-in way to accomplish this, I would be interested. Alternatively, I'd like input on using an Apache reverse proxy configuration so that I can map /app1 to the WebService port of the JRUN instance:

mydomain.com/app1 -> localhost:8301/app1
mydomain.com/app2 -> localhost:8302/app2

Has anyone had luck with this? Does anyone see issues with this or have a better idea?

Thanks!
Seth S.

Report · Nov 30, 2009

hi, i have the same problem, link here:

http://forums.adobe.com/thread/469905?tstart=0

the only "solution" i find at the moment is using mod_proxy to manage all the incoming request and proxy them to the right VirtualHost (always one for each instance), but i don't like very much this workaround

Report · Nov 30, 2009

@clagio - I went down the same road you did with the Location directive. Apparently mod_jrun does not respect the Location or Directory container contexts. I experienced the same behavior that you described - the last defined set of JRunConfig statements took precedence for the entire vhost regardless of URL path.

After talking with some community experts I came up with several possible solutions:

1) Use Tomcat as your JEE server and deploy ColdFusion as an ear file. Tomcat/Apache connectivity is setup with a sub-module of mod_proxy called mod_proxy_ajp. This module works with rewrite rules to create virtual paths that can be mapped (proxied) to different Tomcat/CF instances. (There is no "mod_proxy_jrun" so we can't do the same thing with JRun)

2) The solution I first recommended: Use mod_proxy (specifically mod_proxy_http) and the internal Java web server built in to JRun. In this case you are just doing a reverse proxy from Apache port 80 to JRUN port 8301 (or whatever). URL requests to http://mydomain.dom/path1 get mapped to http://localhost:8301/path1. The end result is transparent to the user. This approach isn't ideal, because it requires Apache to proxy the full HTTP request rather than communicate using a binary protocol like with mod_jrun or AJP. Also, the Java web server may not be robust enough for all production environments.

3) And the solution that I liked the best for my situation was to create separate Apache vhost configs for each CF instance. These vhosts would be "internal" and not accessible to front-end users. In my main public-facing vhost I then would use normal mod_proxy rewriting rule to rewrite my URL paths to the other Apache vhost - that vhost would then use mod_jrun to communicate with JRun using the more efficient binary protocol. Here's more detail on that setup:

This is a simplified config that is currently working using an internal Apache vhost to connect to the JRun ProxyService. The default handler for CF is defined in the main configuration:

<IfModule mod_jrun22.c>
    JRunConfig Verbose false
    JRunConfig Apialloc false
    JRunConfig Ignoresuffixmap false
    JRunConfig Serverstore /opt/jrun4/lib/wsconfig/myinstance1/jrunserver.store
    JRunConfig Bootstrap 127.0.0.1:51002
    AddHandler jrun-handler .jsp .jws .cfm .cfml .cfc .cfr .cfswf
</IfModule>

So by default CF requests are sent to myinstance1, port 51002. However, using rewriting any requests sent to /webstore/*.cfc,*.cfm are
redirected to webstore.localdomain which is configured to proxy to myinstance2, port 51020.

<VirtualHost *:80>
# This VHOST functions as a container to map requests from mydomain.dom/webstore to
# a dedicated JRun instance.

        DocumentRoot "/var/www/vhosts/www.mydomain.dom/html"
        ServerName webstore.localdomain

        # Deny all non-local requests, this should by requested via proxy from the main
        # public-facing VHOST
        <Location />
                Order deny,allow
                Deny from all
                Allow from 127.0.0.0/255.0.0.0 ::1/128
        </Location>

        # JRun Settings
        <IfModule mod_jrun22.c>
                JRunConfig Verbose false
                JRunConfig Apialloc false
                JRunConfig Serverstore /opt/jrun4/lib/wsconfig/myinstance2/jrunserver.store
                JRunConfig Bootstrap 127.0.0.1:51020
        </IfModule>
</VirtualHost>
<VirtualHost *:80>
        DocumentRoot "/var/www/vhosts/www.mydomain.dom/html"
        ServerName www.mydomain.dom

RewriteEngine on

        # Proxy webstore requests to internal VHOST dedicated to specific CF/JRun instance
        RewriteRule ^\/webstore\/(.+)\.cfm(.+)? http://webstore.localdomain/webstore/$1.cfm$2 [P,L]
        RewriteRule ^\/webstore\/(.+)\.cfc(.+)? http://webstore.localdomain/webstore/$1.cfc$2 [P,L]
</VirtualHost>

Note: I added webstore.localdomain to my /etc/hosts file.

Report · Dec 01, 2009

thanks sstone for your feedback, all of your solutions, are good "workaround",and i agree with you saying that the last one is the best one..

but it's possible that there isn't any official documents from Adobe that suggest one solution over the others?

regarding the "Apparently mod_jrun does not respect the Location or Directory container contexts.", i made some test with these configuration:

test1:

    <IfModule mod_jrun22.c>
      JRunConfig Verbose false
      JRunConfig Ssl false
      JRunConfig Ignoresuffixmap false
      JRunConfig Serverstore /opt/cf/jrun4/lib/wsconfig/2/jrunserver.store
      JRunConfig Bootstrap 127.0.0.1:51002
      JRunConfig Apialloc false
    </IfModule>
    <Location /test1>
      AddHandler jrun-handler .cfm .cfml .cfc .jws .cfr .cfswf
    </Location>
    <Location /test2>

#empty just to explain - you can delete /test2 location
</Location>

Test2:

    <Location /test1>
      <IfModule mod_jrun22.c>
        JRunConfig Verbose false
        JRunConfig Ssl false
        JRunConfig Ignoresuffixmap false
        JRunConfig Serverstore /opt/cf/jrun4/lib/wsconfig/2/jrunserver.store
        JRunConfig Bootstrap 127.0.0.1:51002
        JRunConfig Apialloc false
        AddHandler jrun-handler .cfm .cfml .cfc .jws .cfr .cfswf
      </IfModule>
    </Location>
    <Location /test2>

#empty just to explain - you can delete /test2 location
</Location>

In both test the code in /test1 is parsed from cf, and the code in /test2 location it's printed but not parsed, so mod_jrun respect the Location directive, but seems that these values are "global" for all the Virtualhost, and a new "call" of the same parameter overwrite the first one..

I tried working with "SetHandler jrun-handler" (like i do with weblogic) directive without success.. but i think that the solution, if there is one, is working with handlers..

Report · Dec 01, 2009

I think we're saying the same thing. The JRunConfig commands are accepted within Location containers but are not using the Location's value as part of mod_jrun configuration. AddHandler is a built-in Apache directive and doesn't have anything to do with the JRun connector per se. However, your example brings up an interesting point. You could hypothetically compile 2 different mod_jrun22.so modules - one that exposed "jrun-handler" as the request handler name and one that exposed "jrun-handler2". You would have to load them as separate modules in Apache, but then you could use the AddHandler directive to point to separate handlers based on the enclosing Location container. (This of course would require modifying the mod_jrun source to build the second module). Seems like a lot of work, but I think it might be another non-multiple-vhost solution.

However, I did get info (second hand) from two different former Adobe employees who indicated that the multiple Apache vhost method was being used at Adobe to solve this problem.

Thanks,

PS: The more I think about it, the 2 modules idea would be even more complex than I described above. If you took that approach you'd probably be better off compiling in the values that were normally being defined in the Apache config directly into the module. The JRunConfig statements if used would still apply to both modules and defeat the purpose of 2 modules.

Report · Dec 02, 2009

i thought about compiling a second mod_jrun, but really it's not a very flexible solution.. and also require a new mod_jrun for each instance

too much work, without interesting benefits