Easier yet, we call a page for system health, which any loadbalancer can do.
That page checks for a couple mountpoints, and that it can connect to the
database. When we want to remove something from the LB we just rename that
file, makes it very easy to script putting things in an out of the LB.
On Thu, Nov 12, 2009 at 12:14 AM, Rob Lockstone <lockst...@mac.com> wrote:
> I wrote our deployment system. Our load balancer monitors our servers by
> sending certain commands to check if the server is responding. If it doesn't
> respond for 10 seconds, the server is removed from the pool. So our
> deployment system works by sending a privileged command to each server in
> each pool telling it to give the "I'm sleeping" response to the load
> balancer. After the load balancer removes the server, the deployment server
> (which has already retrieved the files to deploy from our repository) copies
> the files out and then tells resin to restart (if the particular type of
> deployment requires a restart, not all do). It then monitors the server to
> see when it's come back online before moving onto the next sever in the
> The above is a somewhat simplified explanation, but that's the basics. For
> example, the deployment system is multi-threaded so it can operate on
> multiple pools at the same time, and even multiple servers in a particular
> pool depending on the time of day.
> When all is said and done, we can do an entire production deployment to
> scores of servers in about 10-15 minutes without our users ever knowing that
> servers have been popping in and out and restarting.
> On Nov 11, 2009, at 19:41, Rachel McConnell wrote:
> I use a tool called Capistrano (http://www.capify.org/) to do very similar
> set of tasks. Capistrano was written for Rails apps so I had to do a fair
> amount of scripting, including splitting out all my servers into separate
> tasks, but once I got this done it works extremely well. It requires Ruby
> on the machine you're managing the process from, but of itself it only calls
> shell tasks on the remote machines so Ruby need not be installed on those.
> I too would be interested in what others use for this.
> On Wed, Nov 11, 2009 at 7:28 PM, Adam Allgaier <allgai...@yahoo.com>wrote:
>> We currently have a cluster of Resin web servers sitting behind a load
>> balancer. What do you recommend for automating/scripting deployment?
>> Our "script" would look something like this:
>> for each web server:
>> - disable web server on the load balancer
>> - upload application files (jsps + jars)
>> - restart resin
>> - enable on the balancer
>> - wait a minute
>> - go to next web server
>> I'm not sure where to start on something like this, so you wisdom is much
>> Adam :-)
> resin-interest mailing list
resin-interest mailing list