applications with different context roots on the same host

[Brian Martin]

When deploying an application to CloudFoundry, usually an application maps to a hostname.  For example,

service.attheextreme.com -> service.war

help.attheextreme.com -> help.war

I'm interested in the following URI structure with separately deployed applications:

attheextreme.com/service

attheextreme.com/help

What is the motivation for the above structure:

1.  Need to maintain separate deployments per application (potentially on different runtimes (jee, node.js, ruby, etc)

2.  Want to avoid CORS complexity with Same Origin Policy for JavaScript.

Is it possible to deployment independent applications to the same host with different context roots?  If not, is there any consideration for this feature in the future?

Brian Martin

IBM

http://www.attheextreme.com

[Daniel Mikusa]

On Jul 25, 2013, at 1:53 PM, Brian Martin <bkma...@gmail.com> wrote:

> When deploying an application to CloudFoundry, usually an application maps to a hostname. For example,
>
> service.attheextreme.com -> service.war
> help.attheextreme.com -> help.war
>
> I'm interested in the following URI structure with separately deployed applications:
>
> attheextreme.com/service
> attheextreme.com/help
>
> What is the motivation for the above structure:
> 1. Need to maintain separate deployments per application (potentially on different runtimes (jee, node.js, ruby, etc)
> 2. Want to avoid CORS complexity with Same Origin Policy for JavaScript.
>
> Is it possible to deployment independent applications to the same host with different context roots?

As far as I understand, when you push you have to map your application to a specific host on a specific domain and that has to be unique. When you push an application, all of the build packs that I've worked with assume that the pushed application is being deployed to the root of the assigned URL. For example, when you push a Java application it's deployed as the ROOT context in Tomcat, which means a request to http://attheextreme.com/service is going to go to the root application and look for a servlet mapped to "/service".

If you can't combine your application into one application, one possibility / hack that comes to mind would be to push service to service.attheextreme.com and help to help.attheextreme.com and then push a third app that acts as a reverse proxy and maps www.attheextreme.com/service to service.attheextreme.com and www.attheextreme.com/help to help.attheextreme.com.

> If not, is there any consideration for this feature in the future?

Sounds interesting to me. Hoping someone else can comment.

Dan

[Scott Frederick]

The concept of a route, which consists of a domain (like "attheextreme.com") that is assigned to a space, and a sub-domain or host (like "service" or "help") that is assigned to an app, is pretty engrained in CF. Short of modifying CF code in a private deployment of CF, I don't see a way to do what you are asking. Daniel's idea to create a third app for reverse proxying seems like it could work. 

Some good detail on routes, domains, and sub-domains can be found here. http://docs.cloudfoundry.com/docs/using/managing-apps/custom-domains/index.html.

Scott

[Guillaume Berche]

Brian,

For specific cases where you're two context_roots would be both using java_web framework (wars), you could consider bundling them into a single EAR, and use a JEE buildpack to them as a single app, sharing the same "uri" (virtual host).

I started a prototype buildpack for the Jonas container at https://github.com/Orange-OpenSource/java-buildpack/blob/jonas/docs/container-jonas.md that supports EARs if this can help. Still some work to be done but with a few more tweaks it should be able to serve multi war EARs and honors application.xml context-root for each.

Guillaume.

[Scott Frederick]

That's a good point Guillaume. The default Java buildpack expects one war file to be pushed and makes this the ROOT application in Tomcat. You could use the JEE and ear approach, or you could fork the Java buildpack and change it to accept multiple wars (i.e. in a zip) and deploy each to the single Tomcat container with different contexts. I'm not suggesting that's a good idea, but it is possible.

The big downside to this approach is that all applications would have to be updated together. That's not ideal if you have several apps being developed by different teams or with different update cycles, but it could work. 

Scott

[Brian Martin]

Thanks for all of the discussion and sugggestions.   It looks like what I want to do is not possible at this time.  I thought this was the case, but wanted to validate with the community.

[James Bayer]

brian,

finally got unburied on this one sorry. let me try and summarize.

currently cloud foundry has the related concepts of:

• domain - standard xyz.TLD definition and also supports sub-domains foo.xyz.TLD
• host - optional 0 to many “.” separated valid strings to add before the domain
• route - host + domain (routes currently doesn't support a scheme or the context path)

the requirement is adding the ability for a route to have an optional context path.

eg. 

2 separate apps

domain: example.com

host: foo

context 1: alpha

context 2: beta

app1 can register a route for foo.example.com/alpha

app2 can register a route for foo.example.com/beta

did i express the requirement correctly?

[Brian Martin]

James,

That is exactly the use case I'm looking to support.   The problem I see is that is ripples pretty widely through the CloudFoundry system (including buildpack implementation).

Brian

[Mike Youngstrom]

We solved this problem by using the enterprise load balancer in front of our Cloud Foundry deployment to take requests to certain contexts and changing the host header to the host of the desired CF deployed application.

To take James example above we would deploy 2 apps to CF.

alpha.example.com

beta.example.com

Then in our VIP for example.com we would inspect the context and modify the host header.  If the URL is:

example.com/alpha

we change it to:

alpha.example.com/alpha

before sending it on to CF.

We don't touch the context in doing this and require the CF hosted app to put all its resources in the context being requested.

This works but an official CF solution would be nice.

Mike

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

[James Bayer]

Interesting solution Mike, thanks for sharing. That solution also requires only using relative links in the application correct? I assume you are not using URL rewriting?

In thinking about this more I realized that even if the router were to make this change so that route could be dynamically assigned and modified, you would still require the buildpack / container to be aware of the context too as you described. Additionally, you could perhaps only support a single context per app at a time unless the container in the buildpack also supported the equivalent of context symlinks.

This is certainly a complicated requirement to implement without some restrictions.

--

Thank you,

James Bayer

[Mike Youngstrom]

On Mon, Aug 26, 2013 at 11:01 PM, James Bayer <jba...@gopivotal.com> wrote:

Interesting solution Mike, thanks for sharing. That solution also requires only using relative links in the application correct? I assume you are not using URL rewriting?

No we are not url rewriting.  You can use absolute paths (most common) but not full absolute urls.  Projects that need an absolute url configure in the host.  Eventually once we move this functionality into a custom service we may provide the absolute url in the service "credentials".

Mike

[andreas....@googlemail.com]

Hi Mike & others,

any new developments in this area? We have a similar usecase as we develop different independent services (in a micro services architecture) which are deployed in CF (and most of the time each service is deployed independently as one application in CF) and we want to have all services being available under one URL like 

api.myservices.com/products

api.myservices.com/categories

api.myservices.com/wishlists

We can use a solution as described by Mike, but I would be interested if in the meantime there is support by CF directly to achieve the same URL pattern. I looked at the CF documentation but I couldn't find any hint here. 

Cheers,

Andreas

[Mike Youngstrom]

I haven't seen any progress in this space.  Our solution is working though it is not optimal.  For example, you need to be sure that your application always does relative redirects.  Which can be tricky since in java many frameworks assume absolute redirect by default deriving the url from the host header which is incorrect in our scenario.

That said, I see the complexities James has pointed out and don't want to champion a more official solution. :)

Mike

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.