![]() This means that when you perform a rolling restart, those same parameters are used for the new application. Second, you’ll notice that the actual command being run looks something like bundle exec unicorn_rails -C /path/to/config/file -E development -D when interpolated by the script. This means your hardware should be able to support running two instances of your application in both CPU and RAM at least temporarily. First, in order to perform the restart, your application needs to essentially run twice until the old master is killed off. ![]() There are a couple of caveats to this approach that you should be aware of before just slapping it into your system. With this new init script in hand, I now have a better way to restart Unicorn without negatively impacting the user experience. The script is pretty self explanitory and it supports the major term signals outlined in the Unicorn documentation. oldbin" export CONFIG=/home/mfarmer/camp2/unicorn/nf # put your own path to the unicorn config file here export RAILS_ENV=development # Change for use on production or staging CMD= "bundle exec unicorn_rails -c $CONFIG -E $RAILS_ENV -D" Sig USR1 & echo "rotated logs OK" & exit 0 echo >& 2 "Couldn't rotate logs" & exit 1Ĭd /home/mfarmer/camp2/rails # put your own path here export PID=/home/mfarmer/camp2/var/run/unicorn.pid # put your own path to the pid file here export OLD_PID= " $PID. Sig USR2 & echo Upgraded & exit 0 echo >& 2 "Couldn't upgrade, starting ' $CMD ' instead" $CMD Sig USR2 & sleep 30 & oldsig QUIT & echo "Killing old master" `cat $OLD_PID ` & exit 0 echo >& 2 "Couldn't reload, starting ' $CMD ' instead" $CMD Sig TERM & echo "Forcing a stop" & exit 0 echo >& 2 "Not running" Sig QUIT & echo "Stopping" & exit 0 echo >& 2 "Not running" Sig 0 & echo >& 2 "Already running" & exit 0 echo "Starting in environment $RAILS_ENV for config $CONFIG " $CMD Test -s " $OLD_PID " & kill - $1 `cat " $OLD_PID " ` Test -s " $PID " & kill - $1 `cat " $PID " ` ![]() With a few modifications, I assembled my new init script: I did a quick search online to see if anyone had put together an init script that used this method for restarting Unicorn and found one on a gist on github. Doing so will reload all of your application code, Unicorn config, Ruby executable, and all libraries. You may replace a running instance of Unicorn with a new one without losing any incoming connections. The key to my problem lay in this explanation: On the Signal Handling page (linked above) is a section called Procedure to replace a running unicorn executable. Reading through the different signals and what message they send to the Unicorn master and workers, I found a better approach to restarting my Unicorn processes that would result in no delay or inturruption to the website. You can send a signal to a process using the unfortunately named kill system command. Unicorn makes use of POSIX Signals for inter-process communication. My search lead me to the Unicorn Signal Handling documentation. This was unaccepatble and I started a search for how to perform a zero downtime deploy for Unicorn. This was due to the approximately 20 seconds it took for the Unicorn workers to launch. This worked well enough that I put together a simple unicorn_init shell script to handle running the commands for me.Īfter a couple of deploys using this init script, I found that there was a significant inturruption caused to the site. I would do this by finding the PID (process id) of the running process, stop it using the kill command and then run the unicorn_rails command from my application root directory. During the deploy, my common practice was to stop the Unicorn processes and then restart them. I was recently deploying a new Ruby on Rails application that used NGINX and Unicorn for production.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |