Cloud: Cluster-Wide Configuration Using HTTP
From Resin 4.0 Wiki
| Line 5: | Line 5: | ||
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. | 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. | + | ''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 the configurations server instance should have it's own local configuration and be entirely separate from other clusters. | ||
| + | |||
| + | === 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 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". | ||
| + | |||
| + | {{{ | ||
| + | /Library/WebServer/Documents | ||
| + | |-resin | ||
| + | |---dev | ||
| + | |-----app | ||
| + | |-----web | ||
| + | |---prod | ||
| + | |-----app | ||
| + | |-----web | ||
| + | |---qa | ||
| + | |-----app | ||
| + | |-----web | ||
| + | }}} | ||
Revision as of 00:00, 4 September 2012
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 the configurations server instance should have it's own local configuration and be entirely separate from other clusters.
= 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 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".
-resin
