Tuesday, 16 September 2014

Configure Nginx with Unicorn on Ubuntu(Linux)


So finally you choose to go with NginxUnicorn for your rails application.  Thats great!
We will go through with all the aspect for deploying your app on cloud. For sake of hand we will use AWS's EC2 server for deployment as it is mostly used.

Prepare your instance & Install dependent libraries

When you purchase the instance it is almost blank except OS installed. So we need to prepare it for our deployment. Lets install them first.

$ sudo apt-get update
$ sudo apt-get install build-essential git-core
$ sudo apt-get install zlib1g-dev libssl-dev

Also install vim as you will need it when updating config files on server.

$ sudo apt-get install vim

Install Nginx

Lets install Nginx.

$ sudo apt-get install nginx

It should installed nginx at /etc/nginx . Inside that directory you will find nginx.conf which main config file for Nginx. We will talk more about it later.

Install Ruby

Now its time to install ruby.

Follow the instruction to install RVM at https://rvm.io/rvm/install . There are 2 ways to install rvm
1) Single User installation
2) Multi User installation

I would suggest to go with Multi user installation. You just need to add any user to role "rvm" whom you wanted to give access to use rvm.


Copy below code to unicorn.rb under /config directory of your project. 

# Sample verbose configuration file for Unicorn (not Rack)
# This configuration file documents many features of Unicorn
# that may not be needed for some applications. See
# http://unicorn.bogomips.org/examples/unicorn.conf.minimal.rb
# for a much simpler configuration file.
# See http://unicorn.bogomips.org/Unicorn/Configurator.html for complete
# documentation.

# WARNING: See config/application.rb under "Relative url support" for the list of
# other files that need to be changed for relative url support

# Read about unicorn workers here:
# http://doc.gitlab.com/ee/install/requirements.html#unicorn-workers
worker_processes 3

# Since Unicorn is never exposed to outside clients, it does not need to
# run on the standard HTTP port (80), there is no reason to start Unicorn
# as root unless it's from system init scripts.
# If running the master process as root and the workers as an unprivileged
# user, do this to switch euid/egid in the workers (also chowns logs):
# user "unprivileged_user", "unprivileged_group"

# Help ensure your application will always spawn in the symlinked
# "current" directory that Capistrano sets up.
working_directory "/path/to/your/project" # available in 0.94.0+

# Listen on both a Unix domain socket and a TCP port.
# If you are load-balancing multiple Unicorn masters, lower the backlog
# setting to e.g. 64 for faster failover.
listen "/path/to/your/project/tmp/sockets/unicorb.socket", :backlog => 1024

# nuke workers after 30 seconds instead of 60 seconds (the default)
# NOTICE: git push over http depends on this value.
# If you want be able to push huge amount of data to git repository over http
# you will have to increase this value too.
# Example of output if you try to push 1GB repo to GitLab over http.
#   -> git push http://gitlab.... master
#   error: RPC failed; result=18, HTTP code = 200
#   fatal: The remote end hung up unexpectedly
#   fatal: The remote end hung up unexpectedly
# For more information see http://stackoverflow.com/a/21682112/752049
timeout 60

# feel free to point this anywhere accessible on the filesystem
pid "/path/to/your/project/tmp/pids/unicorn.pid"

# By default, the Unicorn logger will write to stderr.
# Additionally, some applications/frameworks log to stderr or stdout,
# so prevent them from going to /dev/null when daemonized here:
stderr_path "/path/to/your/project/log/unicorn.stderr.log"
stdout_path "/path/to/your/project/log/unicorn.stdout.log"
# combine Ruby 2.0.0dev or REE with "preload_app true" for memory savings
# http://rubyenterpriseedition.com/faq.html#adapt_apps_for_cow
preload_app true
GC.respond_to?(:copy_on_write_friendly=) and
  GC.copy_on_write_friendly = true

# Enable this flag to have unicorn test client connections by writing the
# beginning of the HTTP headers before calling the application.  This
# prevents calling the application for connections that have disconnected
# while queued.  This is only guaranteed to detect clients on the same
# host unicorn runs on, and unlikely to detect disconnects even on a
# fast LAN.
check_client_connection false

before_fork do |server, worker|
  # the following is highly recomended for Rails + "preload_app true"
  # as there's no need for the master process to hold a connection
  defined?(ActiveRecord::Base) and

  # The following is only recommended for memory/DB-constrained
  # installations.  It is not needed if your system can house
  # twice as many worker_processes as you have configured.
  # This allows a new master process to incrementally
  # phase out the old master process with SIGTTOU to avoid a
  # thundering herd (especially in the "preload_app false" case)
  # when doing a transparent upgrade.  The last worker spawned
  # will then kill off the old master process with a SIGQUIT.
  old_pid = "#{server.config[:pid]}.oldbin"
  if old_pid != server.pid
      sig = (worker.nr + 1) >= server.worker_processes ? :QUIT : :TTOU
      Process.kill(sig, File.read(old_pid).to_i)
    rescue Errno::ENOENT, Errno::ESRCH
  # Throttle the master from forking too quickly by sleeping.  Due
  # to the implementation of standard Unix signal handlers, this
  # helps (but does not completely) prevent identical, repeated signals
  # from being lost when the receiving process is busy.
  # sleep 1

after_fork do |server, worker|
  # per-process listener ports for debugging/admin/migrations
  # addr = "{9293 + worker.nr}"
  # server.listen(addr, :tries => -1, :delay => 5, :tcp_nopush => true)

  # the following is *required* for Rails + "preload_app true",
  defined?(ActiveRecord::Base) and

  # if preload_app is true, then you may also want to check and
  # restart any other shared sockets/descriptors such as Memcached,
  # and Redis.  TokyoCabinet file handles are safe to reuse
  # between any number of forked children (assuming your kernel
  # correctly implements pread()/pwrite() system calls)

You can change "worker_processes" and "timeout" according to your app and sever config.

Configure Nginx to use Unicorn

Now time to configure Nginx. Create a file yoursite.com in "/site-available" directory under nginx's home directory(/etc/nginx) .

upstream your_app {
    # Path to Unicorn SOCK file, as defined previously
    server unix:/path/to/your/project/tmp/unicorn.sock fail_timeout=0;

server {

    listen 80;
    server_name yoursite.com;

    # Application root, as defined previously
    root /path/to/your/project/public;

    try_files $uri/index.html $uri @app;

    location @app {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        proxy_pass http://your_app;

    error_page 500 502 503 504 /500.html;
    client_max_body_size 4G;
    keepalive_timeout 10;

Please make sure to match socket path of unicorn. It should match with what you have defined in unicorn.rb .

Time to start Unicorn

Every thing is setup. Now time to start Unicorn. From root of your application directory run below command. Don't forget to adjust environment if you are running in staging or anyother environment.

bundle exec unicorn_rails -c config/unicorn.rb -E production -D

At this point your site is setup and running now. Go to yoursite.com .

No comments:

Post a Comment