3 ms·

Pardon and excuse the self promotion, but just yesterday night I did a small blog post on deploying Rails Apps with Puma. The deployment part is really quite na

Pardon and excuse the self promotion, but just yesterday night I did a small blog post on deploying Rails Apps with Puma. The deployment part is really quite naive and I'm working on part 2 of the post. http://jasdeep.ca/2013/07/deploying-rails-apps-with-puma-and-nginx/ http://jasdeep.ca/2013/07/deploying-rails-apps-with-puma-and...

FooBarWidget 13y ago
What was naive about [your deployment section], and what needs updating?
- johnbellone 13y ago
  I think that he meant the deployment section in his post was naive, not yours :). I appreciate the compare and contrast.
  - FooBarWidget 13y ago
    I know, that's I meant too. :) I meant to ask, what was naive about his deployment section? Perhaps he meant putting Puma directly on port 80. Although I usually wouldn't do that, I am not entirely sure whether one shouldn't do that. For example Unicorn is multi-proces single-threaded so it should never be used without a buffering web server, but Puma is different. We'll need the Puma author to make a statement about this. I'm glad the comparison was useful to you. :)
- jasdeepsingh 13y ago
  Well, I did outlined how simple my approach was in the article I wrote. The approach really works brilliantly for simple projects with one or two servers where you can log on to each machine and just git pull your code and run the migrations etc and be done with the deployment. For more scalable architectures I prefer putting multiple of these app instances behind a Load Balancer such as Nginx reverse proxy. That is part 2 of my post :) I'm running Puma in production for a simple project which we have behind a Nginx load balancer.
mtarnovan 13y ago
For Rails 4, you don't need to modify script/rails. Might be good to mention in your article.
- jasdeepsingh 13y ago
  I haven't had a chance to set this up with a Rails 4 app yet, But you might be right. Thanks for pointing this out. I'll update the article.

FooBarWidget 13y ago

What was naive about [your deployment section], and what needs updating?

johnbellone 13y ago
I think that he meant the deployment section in his post was naive, not yours :). I appreciate the compare and contrast.
- FooBarWidget 13y ago
  I know, that's I meant too. :) I meant to ask, what was naive about his deployment section? Perhaps he meant putting Puma directly on port 80. Although I usually wouldn't do that, I am not entirely sure whether one shouldn't do that. For example Unicorn is multi-proces single-threaded so it should never be used without a buffering web server, but Puma is different. We'll need the Puma author to make a statement about this. I'm glad the comparison was useful to you. :)
jasdeepsingh 13y ago
Well, I did outlined how simple my approach was in the article I wrote. The approach really works brilliantly for simple projects with one or two servers where you can log on to each machine and just git pull your code and run the migrations etc and be done with the deployment. For more scalable architectures I prefer putting multiple of these app instances behind a Load Balancer such as Nginx reverse proxy. That is part 2 of my post :) I'm running Puma in production for a simple project which we have behind a Nginx load balancer.

mtarnovan 13y ago

For Rails 4, you don't need to modify script/rails. Might be good to mention in your article.

jasdeepsingh 13y ago
I haven't had a chance to set this up with a Rails 4 app yet, But you might be right. Thanks for pointing this out. I'll update the article.