Best practices to cap deploy:start on boot

[Bráulio Bhavamitra]

Hello all,

I would like to know the best practices and references to

servers start on boot.

Even with high uptime servers, we need to certify that server(s)

are running after a reboot, so this is necessary...

I saw some just copying scripts to /etc/init.d and activating them.

But I would like to know more...

Thankfully,

bráulio

[Lee Hambley]

There is no provision or best practice for Capistrano to manage your daemons.

--
* You received this message because you are subscribed to the Google Groups "Capistrano" group.
* To post to this group, send email to capis...@googlegroups.com
* To unsubscribe from this group, send email to capistrano+...@googlegroups.com For more options, visit this group at http://groups.google.com/group/capistrano?hl=en

[Bráulio Bhavamitra]

But considering you just want to run cap deploy:start on boot.

What would you do?

Where are you going to put recipes?

How to load gem environment so capistrano is available on system?

I surely can do this, but I wanted an example.

[Lee Hambley]

Capistrano should be run from your workstation, not from the server. It is designed to deploy the software to the server, and the server's own configuration (monit, upstart, init.d scripts, launchd, dbus, etc) are responsible for running the daemons. 

Capistrano includes a legacy "start" command from the days before Rails had Passenger  mod_rails and one had to explicitly start a mongrel pool on every deployment, this hasn't been true for a number of years. The 'restart' command exists for anyone not in a position to use monit (or similar) to restart their daemons in a sane way, this applies to users of Unicorn (and thus Rainbows & related) where monit can't/won't signal URS2 for a seamless restart, and users of mod_rails, who can achieve better performance from touching ./tmp/restart.txt, rather than restarting the whole apache daemon.

The "stop" command also exists, in the rare case that someone really wants to stop their production daemons, again - this made more sense in the days of script/spin (obsolete since 5 years?) - "stop" is more commonly replaced by "web:disable" - replacing the index site with a static HTML file for deployment safety reasons.

I hope this clarifies the purpose of the tool for you.

[Donovan Bray]

I push only one init.d script that's to start god. (you could use monit or bluepill too). 

Then all of my apps dependencies involved in delivering our application get their own god configs pushed; then god is started. 

If a machine reboots; god gets started; then god takes over and starts everything else, keeps it running, and alerts when there are failures. 

Look at the god, nginx_unicorn, and unicorn recipes here as examples

https://github.com/donnoman/cap-recipes/tree/master/lib/cap_recipes/tasks

You'll also notice that by default each recipe can push its own init script, by changing the watcher you can enable god control; in the same way I left it open to create other watcher types; 

--

[Bráulio Bhavamitra]

Thanks Donovan, I'll try that soon.

Best regards,

bráulio