/ devops

Manage sidekiq workers using deployment setup and Capistrano

In real world, most of the Rails applications would be having a Sidekiq instance as its companion in production systems. And it's a necessary thing to have some sort of mechanism to manage your Sidekiq instance with your deployment setup.

In this post, I am going to throw light on some of the options that you have with managing Sidekiq workers with the deployment setup capistrano.

  1. using capistrano-sidekiq gem.
  2. using custom tasks
Option1: capistrano-sidekiq

The first one is using capistrano-sidekiq gem which takes care of the hassle for you

First add capistrano-sidekiq to your Gemfile:

gem 'capistrano-sidekiq'

After you do a:

bundle install

Require capistrano-sidekiq in your Capfile:

require 'capistrano/sidekiq'

The gem comes with a lot of options to customize your Sidekiq instance, you can see the various available options from the github page

sidekiq default hooks

capistrano-sidekiq adds some default hooks when capistrano-rails is installed.

task :add_default_hooks do
  after 'deploy:starting', 'sidekiq:quiet'
  after 'deploy:updated', 'sidekiq:stop'
  after 'deploy:reverted', 'sidekiq:stop'
  after 'deploy:published', 'sidekiq:start'

== Sidekiq will start or stop automatically during Rails deployments.== Just set sidekiq_default_hooks to false if you don't want this to happen.

You also can start/stop Sidekiq instances manually anytime using:

cap production sidekiq:start

Note: This option is prefered if you need advanced control of your sidekiq workers.

Option:2: Your own capistrano task

If you dont want to manage your sidekiq instances using capistrano-sidekiq gem you can simply add a custom task in your code like:

task :restart_sidekiq do
  on roles(:worker) do
    execute :service, "sidekiq restart"
after "deploy:published", "restart_sidekiq"

This will restart your sidekiq instance whenever capistrano publishes the artifacts to your server after a deployment.

Manu S Ajith

Manu S Ajith

Tech Entrepreneur, dating Elixir, in long-term ❤️ w/ Ruby, had multiple one night stands w/ Go. Into functional paradigms DDD/CQRS/EventSourcing architecture these days. @manusajith on the interwebs

Read More