Adoptable Cookbooks List

Supermarket Belongs to the Community

Supermarket belongs to the community. While Chef has the responsibility to keep it running and be stewards of its functionality, what it does and how it works is driven by the community. The chef/supermarket repository will continue to be where development of the Supermarket application takes place. Come be part of shaping the direction of Supermarket by opening issues and pull requests or by joining us on the Chef Mailing List.

Use either a system-wide installed unicorn, or one that gets deployed with your application

Requirements

An installed unicorn. Alterantively you can use the install recipe to install it using rubygems.

Furthermore you need to add the following line to your metadata.rb

depends 'unicorn-ng'

Attributes

Packages

To install unicorn, rubygems is required. The cookbook tries to figure out automatically which packages are required depending on your current OS.
It is possible to override the automatic settings and specify them manually, though

node['unicorn-ng']['packages'] = %w(rubygems)

Configuration

Everything in your unicorn.rb can be maintained using attributes.
Consider using the provides LWRPs (see below)

Most importantly, you need to specify the path to your unicorn.rb.
If this is not specified, the default recipe will do nothing.
You can also specify a working directory, if needed

This section describes the supported attributes, as well as their default settings.

node['unicorn-ng']['config']['worker_processes'] = 1
node['unicorn-ng']['config']['listen'] = 8080
node['unicorn-ng']['config']['backlog'] = nil
node['unicorn-ng']['config']['pid'] = 'tmp/pids/unicorn.pid'
node['unicorn-ng']['config']['timeout'] = 60
node['unicorn-ng']['config']['stderr_path'] = 'log/unicorn.stderr.log'
node['unicorn-ng']['config']['stdout_path'] = 'log/unicorn.stdout.log'
node['unicorn-ng']['config']['preload_app'] = true
# When sent a USR2, Unicorn will suffix its pidfile with .oldbin and
# immediately start loading up a new version of itself (loaded with a new
# version of our app). When this new Unicorn is completely loaded
# it will begin spawning workers. The first worker spawned will check to
# see if an .oldbin pidfile exists. If so, this means we've just booted up
# a new Unicorn and need to tell the old one that it can now die. To do so
# we send it a QUIT.
#
# Using this method we get 0 downtime deploys.
#
# Stolen from: https://github.com/blog/517-unicorn
node['unicorn-ng']['config']['before_fork'] = <<-EOS
old_pid = '#{node['unicorn-ng']['config']['pid']}.oldbin'
if File.exists?(old_pid) and server.pid != old_pid
begin
Process.kill('QUIT', File.read(old_pid).to_i)
rescue Errno::ENOENT, Errno::ESRCH
# someone else did our job for us
end
end
if defined?(ActiveRecord::Base)
ActiveRecord::Base.connection_handler.clear_all_connections!
end
EOS
node['unicorn-ng']['config']['after_fork'] = <<-EOS
if defined?(ActiveRecord::Base)
ActiveRecord::Base.connection_handler.verify_active_connections!
end
EOS

It's also possible to add arbitrary commands to the top of unicorn.rb in case you need something
like a special require statement.

Use systemd (defaults to true on Ubuntu >= 15.04)
NOTE: This is recommended on machines with systemd, as it's a way cleaner solution. However, the 'status', 'add-worker' and 'remove-worker' actions are not supported on systemd. Furthermore, systemd restart equals former full-restart, reload is behaving like former restart and the former reload was dropped.

node['unicorn-ng']['service']['systemd'] = false

Since 0.3.0, you can specify the service name. The initscript will be deployed to /etc/init.d/$SERVICENAME, or, when systemd is used, to /etc/systemd/system/$SERVICENAME.service
Defaults to 'unicorn'

node['unicorn-ng']['service']['name'] = 'unicorn'

Additional options for the initscript (if required, ignored when using systemd)