Add the gem to your Gemfile
gem 'capistrano3-monit', github: 'naps62/capistrano3-monit'
Run bundle
to update your Gemfile.lock
Add the following to your Capfile
:
require 'capistrano/monit'
The following tasks will be available to you:
monit:status # shows the output of running `monit status` on the server
monit:start # sends a start signal to all monitored processes
monit:stop # sends a stop signal to all monitored processes
monit:restart # sends a restart signal to all monitored processes
Until version 0.3.0, monit:restart
would automatically be hooked into your deploy:restart
task. Starting in 0.4.0, that is no longer the case.
If you want to achieve the same result, you can something like the following to your config/deploy.rb
:
namespace :deploy do
task :restart => 'monit:restart'
end
after 'deploy:publishing', 'deploy:restart'
Currently, the start|stop|restart
tasks assume you only want to handle
monitored processes related to the app being deployed. For this, the name of
each process should contain the name of the application. For example, if you
have the following configuration for your production stage:
# config/deploy/production.rb
set :application, 'production'
And if monit:status
returns the following output:
Process 'production-puma'
status Does not exist
monitoring status Monitored
data collected Wed, 04 Dec 2013 23:24:51
Process 'production-redis'
status Does not exist
monitoring status Monitored
data collected Wed, 04 Dec 2013 23:24:51
Process 'staging-puma'
status Does not exist
monitoring status Monitored
data collected Wed, 04 Dec 2013 23:24:51
Process 'staging-redis'
status Does not exist
monitoring status Monitored
data collected Wed, 04 Dec 2013 23:24:51
Then launching the monit:start
task will only handle the production-puma
and production-redis
processes.
If you don't want monit to be executed with sudo, add this to your config/deploy.rb
:
set :execute_monit_without_sudo, true
- Add tasks to manage the monit service itself
- Allow a customizable list of processes to manage, instead of making assumptions based on their names
This is a very early work, extracted from a specific project i'm working on. If you require a new feature, please open an issue, or preferably, a pull request with a proposed implementation