Luis Fernando Urrea
2012-May-09 19:29 UTC
Unicorn doesn''t play nice with Capistrano deployment?
I am having issues when using unicorn with a Capistrano deployment.>From what I have been able to understand Capistrano uses a scheme inwich every release is deployed inside the releases directory under a unique name and if the transaction was successful, creates a symlink named current that will point to that release. So I end up with a deployment directory such as: /home/deployer/apps/sample_app/current Then when I try to start unicorn from the binstubs directory all the unicorn methods look for things in the following path, particularly in the configurator.rb module: /home/deployer/apps/sample_app I haven''t been able to fully understand how unicorn sets the working_directory from here: https://github.com/defunkt/unicorn/raw/master/lib/unicorn/configurator.rb But I wanted to check with the community if I am missing something evident due to the noob nature in me. TIA -- O: 2248-2483 C: 8723-2518
Konstantin Gredeskoul
2012-May-09 19:33 UTC
Unicorn doesn''t play nice with Capistrano deployment?
I highly recommend using the gem for this:
https://github.com/sosedoff/capistrano-unicorn
instead of rolling your own. I typically start unicorn (and any other
task) by first doing a CD into the application directory (either
release_path or current_path depending on when during your deployment
the command runs).
When you set this up, please check your
config/unicorn/"#{Rails.env}".rb, perhaps that is what''s
pointing to
the wrong path?
Hope this helps
K
On Wed, May 9, 2012 at 12:29 PM, Luis Fernando Urrea
<lfurrea at simplecs.net> wrote:> I am having issues when using unicorn with a Capistrano deployment.
> >From what I have been able to understand Capistrano uses a scheme in
> wich every release is deployed inside the releases directory under a
> unique name and if the transaction was successful, creates a symlink
> named current that will point to that release.
>
> So I end up with a deployment directory such as:
>
> /home/deployer/apps/sample_app/current
>
> Then when I try to start unicorn from the binstubs directory all the
> unicorn methods look for things in the following path, particularly in
> the configurator.rb module:
>
> /home/deployer/apps/sample_app
>
> I haven''t been able to fully understand how unicorn sets the
> working_directory from here:
>
> https://github.com/defunkt/unicorn/raw/master/lib/unicorn/configurator.rb
>
> But I wanted to check with the community if I am missing something
> evident due to the noob nature in me.
>
> TIA
>
>
> --
> O: 2248-2483
> C: 8723-2518
> _______________________________________________
> Unicorn mailing list - mongrel-unicorn at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> Do not quote signatures (like this one) or top post when replying
--
Konstantin Gredeskoul
CTO?:: Wanelo Inc
cell:?(415) 265 1054
Rob Sutherland
2012-May-09 19:47 UTC
Unicorn doesn''t play nice with Capistrano deployment?
I''m going to a bit off your topic but for good reason. I was finally annoyed by capistrano for other reasons and went with a simple git based deployment. I setup my remote repo to post to a url in the app when a commit happens. The action of that URL is summed up in this gist: https://gist.github.com/2648267 I also use this because I can make changes on github directly or on the server and commit the changes to cause the same code refresh and worker restart. It''s also nice that the app on the server is an actual git repo. I don''t have experience with the capistrano-unicorn gem; that gem may be more of what you''re looking for. On Wed, May 9, 2012 at 2:29 PM, Luis Fernando Urrea <lfurrea at simplecs.net> wrote:> I am having issues when using unicorn with a Capistrano deployment. > >From what I have been able to understand Capistrano uses a scheme in > wich every release is deployed inside the releases directory under a > unique name and if the transaction was successful, creates a symlink > named current that will point to that release. > > So I end up with a deployment directory such as: > > /home/deployer/apps/sample_app/current > > Then when I try to start unicorn from the binstubs directory all the > unicorn methods look for things in the following path, particularly in > the configurator.rb module: > > /home/deployer/apps/sample_app > > I haven''t been able to fully understand how unicorn sets the > working_directory from here: > > https://github.com/defunkt/unicorn/raw/master/lib/unicorn/configurator.rb > > But I wanted to check with the community if I am missing something > evident due to the noob nature in me. > > TIA > > > -- > O: 2248-2483 > C: 8723-2518 > _______________________________________________ > Unicorn mailing list - mongrel-unicorn at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-unicorn > Do not quote signatures (like this one) or top post when replying-- Rob Sutherland 256.473.3148
Konstantin Gredeskoul
2012-May-09 19:57 UTC
Unicorn doesn''t play nice with Capistrano deployment?
I like the simplicity of your git hook deployment solution, but the simplicity is also it''s limitation. If you are running say 2 clusters of 10 app servers, need to do rolling deploys without downtime, stop/start things like resque, solr, memcached all in the right order to allow for the site to continue functioning while it''s happening, then you''d probably be very happy that capistrano exists :) Also, what about production-only configuration, such as production db connection params, credentials to various other services, maybe even a payment gateway? I would highly discourage from checking these into your source code repo for obvious reasons. For a single host environment i don''t think it really matters, but for anything bigger than that, capistrano is pretty awesome. I''ve used it for many years, and most recently capified a green field rails project. It took about an hour. Anyway, I am not married to capistrano, but I do think it''s a great tool that solves a very large pain in a consistent and programmable way, and is certainly worth a try. K On Wed, May 9, 2012 at 12:47 PM, Rob Sutherland <rob at roberocity.com> wrote:> I''m going to a bit off your topic but for good reason. I was finally > annoyed by capistrano for other reasons and went with a simple git > based deployment. > > I setup my remote repo to post to a url in the app when a commit > happens. The action of that URL is summed up in this gist: > https://gist.github.com/2648267 > > I also use this because I can make changes on github directly or on > the server and commit the changes to cause the same code refresh and > worker restart. It''s also nice that the app on the server is an actual > git repo. > > I don''t have experience with the capistrano-unicorn gem; that gem may > be more of what you''re looking for. > > > > > On Wed, May 9, 2012 at 2:29 PM, Luis Fernando Urrea > <lfurrea at simplecs.net> wrote: >> I am having issues when using unicorn with a Capistrano deployment. >> >From what I have been able to understand Capistrano uses a scheme in >> wich every release is deployed inside the releases directory under a >> unique name and if the transaction was successful, creates a symlink >> named current that will point to that release. >> >> So I end up with a deployment directory such as: >> >> /home/deployer/apps/sample_app/current >> >> Then when I try to start unicorn from the binstubs directory all the >> unicorn methods look for things in the following path, particularly in >> the configurator.rb module: >> >> /home/deployer/apps/sample_app >> >> I haven''t been able to fully understand how unicorn sets the >> working_directory from here: >> >> https://github.com/defunkt/unicorn/raw/master/lib/unicorn/configurator.rb >> >> But I wanted to check with the community if I am missing something >> evident due to the noob nature in me. >> >> TIA >> >> >> -- >> O: 2248-2483 >> C: 8723-2518 >> _______________________________________________ >> Unicorn mailing list - mongrel-unicorn at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-unicorn >> Do not quote signatures (like this one) or top post when replying > > > > -- > > Rob Sutherland > 256.473.3148 > _______________________________________________ > Unicorn mailing list - mongrel-unicorn at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-unicorn > Do not quote signatures (like this one) or top post when replying-- Konstantin Gredeskoul CTO?:: Wanelo Inc cell:?(415) 265 1054
Rob Sutherland
2012-May-09 20:05 UTC
Unicorn doesn''t play nice with Capistrano deployment?
Great points. Most of what I do are simple deployments. I haven''t experimented with memcached, etc. that would benefit from a capistrano style deployment. This also works better in Sinatra than in Rails for limiting downtime because the restart is typically quicker. For most of what I do Capistrano is too much. So I like the simplicity here. For production only configuration I don''t have that checked into source control. It exists on the server only and ignored in the .gitignore file (as does most of my custom development config). There are some things in source control that gets pushed to the server - such as tests, etc. And just to be clear, I''m not anti Capistrano. I just like to keep things as simple as possible. For a large system the git hook won''t work. But for a small system Capistrano is (typically) too much. On Wed, May 9, 2012 at 2:57 PM, Konstantin Gredeskoul <kig at wanelo.com> wrote:> I like the simplicity of your git hook deployment solution, but the > simplicity is also it''s limitation. > > If you are running say 2 clusters of 10 app servers, need to do > rolling deploys without downtime, stop/start things like resque, solr, > memcached all in the right order to allow for the site to continue > functioning while it''s happening, then you''d probably be very happy > that capistrano exists :) > > Also, what about production-only configuration, such as production db > connection params, credentials to various other services, maybe even a > payment gateway? ?I would highly discourage from checking these into > your source code repo for obvious reasons. > > For a single host environment i don''t think it really matters, but for > anything bigger than that, capistrano is pretty awesome. ?I''ve used it > for many years, and most recently capified a green field rails > project. It took about an hour. > > Anyway, I am not married to capistrano, but I do think it''s a great > tool that solves a very large pain in a consistent and programmable > way, and is certainly worth a try. > > K > > > > On Wed, May 9, 2012 at 12:47 PM, Rob Sutherland <rob at roberocity.com> wrote: >> I''m going to a bit off your topic but for good reason. I was finally >> annoyed by capistrano for other reasons and went with a simple git >> based deployment. >> >> I setup my remote repo to post to a url in the app when a commit >> happens. The action of that URL is summed up in this gist: >> https://gist.github.com/2648267 >> >> I also use this because I can make changes on github directly or on >> the server and commit the changes to cause the same code refresh and >> worker restart. It''s also nice that the app on the server is an actual >> git repo. >> >> I don''t have experience with the capistrano-unicorn gem; that gem may >> be more of what you''re looking for. >> >> >> >> >> On Wed, May 9, 2012 at 2:29 PM, Luis Fernando Urrea >> <lfurrea at simplecs.net> wrote: >>> I am having issues when using unicorn with a Capistrano deployment. >>> >From what I have been able to understand Capistrano uses a scheme in >>> wich every release is deployed inside the releases directory under a >>> unique name and if the transaction was successful, creates a symlink >>> named current that will point to that release. >>> >>> So I end up with a deployment directory such as: >>> >>> /home/deployer/apps/sample_app/current >>> >>> Then when I try to start unicorn from the binstubs directory all the >>> unicorn methods look for things in the following path, particularly in >>> the configurator.rb module: >>> >>> /home/deployer/apps/sample_app >>> >>> I haven''t been able to fully understand how unicorn sets the >>> working_directory from here: >>> >>> https://github.com/defunkt/unicorn/raw/master/lib/unicorn/configurator.rb >>> >>> But I wanted to check with the community if I am missing something >>> evident due to the noob nature in me. >>> >>> TIA >>> >>> >>> -- >>> O: 2248-2483 >>> C: 8723-2518 >>> _______________________________________________ >>> Unicorn mailing list - mongrel-unicorn at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/mongrel-unicorn >>> Do not quote signatures (like this one) or top post when replying >> >> >> >> -- >> >> Rob Sutherland >> 256.473.3148 >> _______________________________________________ >> Unicorn mailing list - mongrel-unicorn at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-unicorn >> Do not quote signatures (like this one) or top post when replying > > > > -- > > Konstantin Gredeskoul > CTO?:: Wanelo Inc > cell:?(415) 265 1054 > _______________________________________________ > Unicorn mailing list - mongrel-unicorn at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-unicorn > Do not quote signatures (like this one) or top post when replying-- Rob Sutherland 256.473.3148
Luis Fernando Urrea <lfurrea at simplecs.net> wrote:> I am having issues when using unicorn with a Capistrano deployment. > >From what I have been able to understand Capistrano uses a scheme in > wich every release is deployed inside the releases directory under a > unique name and if the transaction was successful, creates a symlink > named current that will point to that release.Correct.> So I end up with a deployment directory such as: > > /home/deployer/apps/sample_app/current > > Then when I try to start unicorn from the binstubs directory all the > unicorn methods look for things in the following path, particularly in > the configurator.rb module: > > /home/deployer/apps/sample_app > > I haven''t been able to fully understand how unicorn sets the > working_directory from here: > > https://github.com/defunkt/unicorn/raw/master/lib/unicorn/configurator.rbJust put the following line at the top of your config file: working_directory "/home/deployer/apps/sample_app/current" When I used Capistrano, I would start unicorn inside the "current" directory to avoid that config line: cd /home/deployer/apps/sample_app/current unicorn -c $PWD/config/unicorn.conf.rb That said, I don''t deploy with Capistrano anymore. I package apps into gem/rpm/deb/any-other-packaging-system for multi-machine deployments, and use a git checkout for single-instance deployments.