Skip to content

Instantly share code, notes, and snippets.

@manhdaovan

manhdaovan/0-downtime-deploy-Unicorn-Systemd.md

Forked from c4nc/0-downtime-deploy-Unicorn-Systemd.md
Created July 9, 2021 07:12
Show Gist options
  • Save manhdaovan/39b6ec7ab360b87c917ca61899fd67e5 to your computer and use it in GitHub Desktop.
Save manhdaovan/39b6ec7ab360b87c917ca61899fd67e5 to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. @c4nc c4nc renamed this gist Jul 24, 2016. 1 changed file with 0 additions and 0 deletions.
    0 0-downtime-deploy-Unicorn-Systemd → 0-downtime-deploy-Unicorn-Systemd.md
    View file
    File renamed without changes.
  2. @c4nc c4nc revised this gist Jul 24, 2016. 1 changed file with 7 additions and 4 deletions.
    11 changes: 7 additions & 4 deletions 0-downtime-deploy-Unicorn-Systemd
    View file
    Original file line number Diff line number Diff line change
    @@ -1,6 +1,9 @@
    #Working configuration to accomplish 0-downtime deploy with unicorn 5.x and systemd on centos 7
    ##Working configuration to accomplish 0-downtime deploy with unicorn 5.x and systemd on centos 7

    The examples and assumptions on the unicorn bogomips repo (https://unicorn.bogomips.org) doesn't work for centos 7.
    Below my working configuration (v1).
    The scope is to accomplish a 0-downtime reload of a [unicorn](https://unicorn.bogomips.org) service managed by Systemd on a Centos 7 distro.

    Any advice/remark will be appreciated
    The examples and assumptions that i found on the [bogomips's unicorn repo](http://unicorn.bogomips.org/examples/) seems not working for centos 7.

    Below a working configuration tested on Centos 7 and unicorn 5.1

    **Any advice/remark will be appreciated**
  3. @c4nc c4nc renamed this gist Jul 24, 2016. 1 changed file with 0 additions and 0 deletions.
    0 0-downtime-deploy_Unicorn_Systemd → 0-downtime-deploy-Unicorn-Systemd
    View file
    File renamed without changes.
  4. @c4nc c4nc renamed this gist Jul 24, 2016. 1 changed file with 0 additions and 0 deletions.
    0 0-downtime-deploy Unicorn Systemd → 0-downtime-deploy_Unicorn_Systemd
    View file
    File renamed without changes.
  5. @c4nc c4nc renamed this gist Jul 24, 2016. 1 changed file with 0 additions and 0 deletions.
    0 0-downtime-deploy on Unicorn Systemd → 0-downtime-deploy Unicorn Systemd
    View file
    File renamed without changes.
  6. @c4nc c4nc created this gist Jul 24, 2016.
    6 changes: 6 additions & 0 deletions 0-downtime-deploy on Unicorn Systemd
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,6 @@
    #Working configuration to accomplish 0-downtime deploy with unicorn 5.x and systemd on centos 7

    The examples and assumptions on the unicorn bogomips repo (https://unicorn.bogomips.org) doesn't work for centos 7.
    Below my working configuration (v1).

    Any advice/remark will be appreciated
    104 changes: 104 additions & 0 deletions unicorn.rb
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,104 @@
    # 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.
    RAILS_ENV = 'production'
    application_name = 'appname'
    deploy_to = "/DOCROOT/#{application_name}"

    # Use at least one worker per core if you're on a dedicated server,
    # more will usually help for _short_ waits on databases/caches.
    worker_processes 4

    # 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 "appuser", "appgroup" #usually group has the same name of the user

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

    # listen on both a Unix domain socket and a TCP port,
    # we use a shorter backlog for quicker failover when busy
    listen "#{deploy_to}/shared/tmp/sockets/unicorn.sock", :backlog => 64
    # listen 8080, :tcp_nopush => true

    # nuke workers after 30 seconds instead of 60 seconds (the default)
    timeout 30

    # feel free to point this anywhere accessible on the filesystem
    pid "#{deploy_to}/shared/tmp/pids/unicorn.pid"

    # By default, the Unicorn logger will write to stderr.
    # Additionally, ome applications/frameworks log to stderr or stdout,
    # so prevent them from going to /dev/null when daemonized here:
    stderr_path "#{deploy_to}/shared/log/unicorn.stderr.log"
    stdout_path "#{deploy_to}/shared/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 false #true
    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

    # local variable to guard against running a hook multiple times
    run_once = true

    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
    ActiveRecord::Base.connection.disconnect!

    # Occasionally, it may be necessary to run non-idempotent code in the
    # master before forking. Keep in mind the above disconnect! example
    # is idempotent and does not need a guard.
    if run_once
    # do_something_once_here ...
    run_once = false # prevent from firing again
    end

    old_pid = "#{server.config[:pid]}.oldbin"
    if File.exists?(old_pid) && 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
    end

    after_fork do |server, worker|
    # per-process listener ports for debugging/admin/migrations
    # addr = "127.0.0.1:#{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
    ActiveRecord::Base.establish_connection

    # 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)
    end
    24 changes: 24 additions & 0 deletions unicorn_app.service
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,24 @@
    #systemd unit file service for unicorn 5.x / Centos 7.x
    [Unit]
    Description=unicorn - app xxx
    #After=nginx.service

    [Service]
    Type=forking
    PIDFile=/DOCROOT/shared/tmp/pids/unicorn.pid
    User=appuser
    Group=appgroupname
    WorkingDirectory=/DOCROOT/current
    #Below, the rack env is set-up to none for production. It could be rewrited by rails init (you should export RAILS_ENV to the system)
    ExecStart=/usr/local/rvm/wrappers/ruby-2.3.0/unicorn -c /DOCROOT/current/config/unicorn.rb -E none -D
    ExecStop=/usr/bin/kill -QUIT $MAINPID
    #USR2 signal will spawn the new master process, the kill signal to the old master should be send from rails
    ExecReload=/bin/kill -s SIGUSR2 $MAINPID
    CPUAccounting=true
    MemoryAccounting=true
    BlockIOAccounting=true
    PrivateTmp=true
    NoNewPrivileges=true

    [Install]
    WantedBy=multi-user.target