Cloud: Cluster-Wide Configuration Using HTTP

From Resin 4.0 Wiki

(Difference between revisions)
Jump to: navigation, search
Line 7: Line 7:
 
''Note: Resin can also use cloud repository based configuration, which is stored in the Triad and shared between cluster members using Resin's internal .git implementation.  While cloud configuration is slightly harder to work with than HTTP, it has the added advantage of having no SPOF, and requiring no additional HTTP server.  An administrator can make the choice which works best for their architecture, or both can be used at the same time if desired.''
 
''Note: Resin can also use cloud repository based configuration, which is stored in the Triad and shared between cluster members using Resin's internal .git implementation.  While cloud configuration is slightly harder to work with than HTTP, it has the added advantage of having no SPOF, and requiring no additional HTTP server.  An administrator can make the choice which works best for their architecture, or both can be used at the same time if desired.''
  
=== Setup an HTTP Server ==
+
=== Setup an HTTP Server ===
  
A single HTTP server will serve as your configuration repository for the entire cluster, or even multiple clusters/tiers if desired.  You can use Resin for this also, but the configurations server instance should have it's own local configuration and be entirely separate from other clusters.
+
A single HTTP server will serve as your configuration repository for the entire cluster, or even multiple clusters/tiers if desired.  You can use Resin for this also, but this server instance should have it's own local configuration and be entirely separate from other clusters.
  
=== Setup Directory Structures ==
+
For my example I've setup Apache on port 80 at "http://molson".
  
This can be as simple or complex as you desire.  For this example, I've created a "resin" directory in my webserver root.  Under that there is a directory for each environment "dev", "qa", and "prod".  Under each of these, there is a directory for each cluster in the tier "web" and "app".
+
=== Setup Directory Structures ===
  
{{{
+
This can be as simple or complex as you desire.  For this example, I've created a "resin" directory in my webserver's document root.  Under that there is a directory for each environment: "dev", "qa", and "prod".  Under each of these, there is a directory for each tier in the env: "web" and "app".
/Library/WebServer/Documents
+
 
 +
/Library/WebServer/Documents
 
   |-resin
 
   |-resin
 
   |---dev
 
   |---dev
Line 27: Line 28:
 
   |-----app
 
   |-----app
 
   |-----web
 
   |-----web
}}}
+
 
 +
This makes the URL to the app cluster in my dev environment "http://molson/resin/dev/app".
 +
 
 +
=== Move Configuration Files ===
 +
 
 +
Move the following files from the Resin conf directory to the appropriate directory in your webserver document root, in my case "resin/dev/app"
 +
 
 +
* admin-users.xml
 +
* cluster-default.xml
 +
* health.xml
 +
* resin.properties
 +
* resin.xml
 +
 
 +
So now I can directly reference resin.xml at "http://molson/resin/dev/app/resin.xml"
 +
 
 +
''You should notice that Resin XML configuration often references "${__DIR__}" for imports.  This EL variable always refers to the current directory where the XML resides, and it this still works with HTTP paths.  Thus with resin.xml loaded from http://molson/resin/dev/app/resin.xml, ${__DIR__} will refer to "http://molson/resin/dev/app/", making loading the other files automatic.''
 +
 
 +
Some of these files, or parts of them, the triad server addresses in particular, should be shared between clusters in the same environment.  I'll discuss that below.
 +
 
 +
=== Local resin.xml ===
 +
 
 +
Now we add a simple local conf/resin.xml that simple imports resin.xml from the HTTP configuration repository:
 +
 
 +
<resin xmlns="http://caucho.com/ns/resin"
 +
      xmlns:resin="urn:java:com.caucho.resin">
 +
 
 +
  <resin:import path="http://molson/resin/dev/app/resin.xml"/>
 +
 
 +
</resin>

Revision as of 00:00, 4 September 2012

Cloud-48.pngGears-48.pngCookbook-48.png

Contents

Configuration Sharing: Cluster-Wide Configuration Using HTTP

In most cases, Resin can handle HTTP(S) URLs interchangeably with file paths. This provides the handy ability to pull configuration files from a central configuration repository over HTTP. Although it adds a possible single point of failure (the configuration server), for large clustered deployments the convenience of not having to synchronize configuration files to each machine can not be understated.

Note: Resin can also use cloud repository based configuration, which is stored in the Triad and shared between cluster members using Resin's internal .git implementation. While cloud configuration is slightly harder to work with than HTTP, it has the added advantage of having no SPOF, and requiring no additional HTTP server. An administrator can make the choice which works best for their architecture, or both can be used at the same time if desired.

Setup an HTTP Server

A single HTTP server will serve as your configuration repository for the entire cluster, or even multiple clusters/tiers if desired. You can use Resin for this also, but this server instance should have it's own local configuration and be entirely separate from other clusters.

For my example I've setup Apache on port 80 at "http://molson".

Setup Directory Structures

This can be as simple or complex as you desire. For this example, I've created a "resin" directory in my webserver's document root. Under that there is a directory for each environment: "dev", "qa", and "prod". Under each of these, there is a directory for each tier in the env: "web" and "app".

/Library/WebServer/Documents
  |-resin
  |---dev
  |-----app
  |-----web
  |---prod
  |-----app
  |-----web
  |---qa
  |-----app
  |-----web

This makes the URL to the app cluster in my dev environment "http://molson/resin/dev/app".

Move Configuration Files

Move the following files from the Resin conf directory to the appropriate directory in your webserver document root, in my case "resin/dev/app"

  • admin-users.xml
  • cluster-default.xml
  • health.xml
  • resin.properties
  • resin.xml

So now I can directly reference resin.xml at "http://molson/resin/dev/app/resin.xml"

You should notice that Resin XML configuration often references "${__DIR__}" for imports. This EL variable always refers to the current directory where the XML resides, and it this still works with HTTP paths. Thus with resin.xml loaded from http://molson/resin/dev/app/resin.xml, ${__DIR__} will refer to "http://molson/resin/dev/app/", making loading the other files automatic.

Some of these files, or parts of them, the triad server addresses in particular, should be shared between clusters in the same environment. I'll discuss that below.

Local resin.xml

Now we add a simple local conf/resin.xml that simple imports resin.xml from the HTTP configuration repository:

<resin xmlns="http://caucho.com/ns/resin"
      xmlns:resin="urn:java:com.caucho.resin">
 <resin:import path="http://molson/resin/dev/app/resin.xml"/>
 
</resin>
Personal tools
TOOLBOX
LANGUAGES