Tag: Puma

Multiple UNIX sockets bindings for Puma cluster

March 14, 2015 / / 0 Comments

If you want to bind Puma to a unix socket, you can do this either by providing a -b options:

$ puma -b unix:///var/run/puma.sock

or using a puma.rb config file and setting the bind options.

# puma.rb config file
# ...config...
bind 'unix://var/run/puma.sock'
# ...config

Unfortunately if you try to bind multiple Pumas to one socket, you might end up with issue similar to this one:

2015/02/16 12:12:22 [error] 2476#0:
 *16083152 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 64.251.13.85, server: app,
  request: "POST /notifier_api/v2/notices HTTP/1.1", upstream: "http://unix:///var/run/puma.sock:/notifier_api/v2/notices", host: "app"
2015/02/16 12:12:23 [error] 2476#0:
 *16083176 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 64.251.10.203, server: app,
  request: "POST /notifier_api/v2/notices HTTP/1.1", upstream: "http://unix:///var/run/puma.sock:/notifier_api/v2/notices", host: "app"
2015/02/16 12:12:23 [error] 2474#0:
 *16083180 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 64.251.13.85, server: app,
  request: "POST /notifier_api/v2/notices HTTP/1.1", upstream: "http://unix:///var/run/puma.sock:/notifier_api/v2/notices", host: "app"
2015/02/16 12:12:43 [error] 2476#0:
 *16083282 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 64.251.13.85, server: app,
  request: "POST /notifier_api/v2/notices HTTP/1.1", upstream: "http://unix:///var/run/puma.sock:/notifier_api/v2/notices", host: "app"
2015/02/16 12:12:43 [error] 2476#0:
 *16083292 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 64.251.13.85, server: app,
  request: "POST /notifier_api/v2/notices HTTP/1.1", upstream: "http://unix:///var/run/puma.sock:/notifier_api/v2/notices", host: "app"
2015/02/16 12:12:43 [error] 2476#0:
 *16083301 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 64.251.13.85, server: app,
  request: "POST /notifier_api/v2/notices HTTP/1.1", upstream: "http://unix:///var/run/puma.sock:/notifier_api/v2/notices", host: "app"
2015/02/16 12:13:33 [error] 2474#0:
 *16083390 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 64.251.13.85, server: app,
  request: "POST /notifier_api/v2/notices HTTP/1.1", upstream: "http://unix:///var/run/puma.sock:/notifier_api/v2/notices", host: "app"
2015/02/16 12:13:33 [error] 2474#0:
 *16083392 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 64.251.13.85, server: app,
  request: "POST /notifier_api/v2/notices HTTP/1.1", upstream: "http://unix:///var/run/puma.sock:/notifier_api/v2/notices", host: "app"
2015/02/16 12:13:33 [error] 2474#0:
 *16083397 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 64.251.13.85, server: app,
  request: "POST /notifier_api/v2/notices HTTP/1.1", upstream: "http://unix:///var/run/puma.sock:/notifier_api/v2/notices", host: "app"
2015/02/16 12:13:33 [error] 2474#0:
 *16083398 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 64.251.13.85, server: app,
  request: "POST /notifier_api/v2/notices HTTP/1.1", upstream: "http://unix:///var/run/puma.sock:/notifier_api/v2/notices", host: "app"
2015/02/16 12:13:43 [error] 2477#0:
 *16083428 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 64.251.13.85, server: app,
  request: "POST /notifier_api/v2/notices HTTP/1.1", upstream: "http://unix:///var/run/puma.sock:/notifier_api/v2/notices", host: "app"

So, what is the reason? Your one and only socket might just not be enough. You can call bind multiple times, to create multiple sockets that your clustered Puma will use:

# ...config...
bind 'unix://var/run/puma1.sock'
bind 'unix://var/run/puma2.sock'
bind 'unix://var/run/puma3.sock'
bind 'unix://var/run/puma4.sock'
bind 'unix://var/run/puma5.sock'
# ...config...

Btw great docs for Puma - it's nowhere mentioned and the easiest place to understand how it works, is in the source code, that looks like that:

 # Bind the server to +url+. tcp:// and unix:// are the only accepted
# protocols.
#
def bind(url)
@options[:binds] << url
end

Running GitLab 7.1 using Puma instead of a Unicorn

August 13, 2014 / / 0 Comments

Warning

Warning! Before you do this, please read why you should'nt: why did gitlab 6 switch back to unicorn?

So now, when

you-have-been-warned

let's get started...

Gemfile updates

Nothing special here. Just add:

gem 'puma'

and then:

# From /home/gitlab/gitlab
sudo bundle install --no-deployment
sudo -u gitlab -H bundle install --deployment --without development test postgres

Puma config

Create a puma.rb file in your gitlab config dir and copy/paste this:

app_path = File.expand_path(File.dirname(File.dirname(__FILE__)))

rails_env = ENV['RAILS_ENV'] ||  'production'
environment rails_env

threads 4, 32
workers 2

daemonize true
bind                 "unix://#{app_path}/tmp/puma/sock"
state_path           "#{app_path}/tmp/puma/state"
pidfile              "#{app_path}/tmp/puma/pid"
activate_control_app "unix://#{app_path}/tmp/puma/ctlsock"
stdout_redirect      "#{app_path}/log/puma_access.log", "#{app_path}/log/puma_error.log"

preload_app!

and

mkdir /home/git/gitlab/tmp/puma

At this point, you should be able to execute puma worker:

# You should execute this from a git user
cd /home/git/gitlab && exec bundle exec puma -C /home/git/gitlab/config/puma.rb

[4419] Puma starting in cluster mode...
[4419] * Version 2.9.0 (ruby 2.1.2-p95), codename: Team High Five
[4419] * Min threads: 4, max threads: 32
[4419] * Environment: production
[4419] * Process workers: 2
[4419] * Preloading application
[4419] * Listening on unix:///home/git/gitlab/tmp/puma/sock

Init Script

To manage my Pumas I use Jungle. You can read more about it here. From this point, I assume that you have figured out a way to autostart GitLab Puma process (if not, you'll have to start it each time manually - good luck!).

Unfortunately it is not all. Default GitLab init script (provided with GitLab sources) will try to run Unicorn, so we need to silent it (but we need to keep the Sidekiq part).

To do so, we have to change the /etc/init.d/gitlab script.

start_gitlab() method (line 165) - we have to comment the else case:

  # Then check if the service is running. If it is: don't start again.
  if [ "$web_status" = "0" ]; then
    echo "The Unicorn web server already running with pid $wpid, not restarting."
  # else
    # Remove old socket if it exists
    # rm -f "$socket_path"/gitlab.socket 2>/dev/null
    # Start the web server
    # RAILS_ENV=$RAILS_ENV bin/web start
  fi

wait_for_pids() method (line 78) - we have to remote the first condition from while loop. We no longer check for web_server_pid_path:

wait_for_pids(){
  # We are sleeping a bit here mostly because sidekiq is slow at writing it's pid
  i=0;
  while [ ! -f $sidekiq_pid_path ]; do
    sleep 0.1;
    i=$((i+1))
    if [ $((i%10)) = 0 ]; then
      echo -n "."
    elif [ $((i)) = 301 ]; then
      echo "Waited 30s for the processes to write their pids, something probably went wrong."
      exit 1;
    fi
  done
  echo
}

There are some other places that you could modify - so you would not get any warnings, but hey! Those are just warnings. What I did above is an absolute minimum for starting/stopping Sidekiq without any Unicorn errors.

Nginx server block

And an example Nginx server block (virtual host) config:

upstream git.server.name {
  server unix:///home/git/gitlab/tmp/puma/sock;
}

server {
  server_name git.server.name;
  client_max_body_size 32M;

  keepalive_timeout 5;

  root /home/git/gitlab/public;
  access_log /var/log/nginx/git.server.name.access.log;
  error_log  /var/log/nginx/git.server.name.error.log;

  location / {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;

    if (-f $request_filename) {
      break;
    }

    if (!-f $request_filename) {
      proxy_pass http://git.server.name;
      break;
    }
  }
}

After that - you are ready to go! Good luck!

Copyright © 2024 Closer to Code

Theme by Anders Noren — Up ↑