使用Puma部署Rails项目 - 简书
使用Puma部署Rails项目
Puma是一个基于Ruby的Web Server服务器，与其他Ruby Web服务器不同的是，Puma是为速度与并发而生的。它和Unicorn的很大不同是，Puma主要基于多线程，而Unicorn是基于多进程，所以Puma的内存占用要比Unicorn小很多。（当然基于多线程最大的问题就是线程安全的问题，这个在Ruby1.9之后已经逐步得到比较完美的解决了，Ruby1.8就别指望跑Puma了。）
下面是Puma的官方给出的数据，内存占用占据明显优势，而速度方面也是独占鳌头，所以Puma在部署中越来越流行了。
Paste_Image.png
和unicorn一样，使用Puma之前先在Gemfile中添加：
gem 'puma'
之后添加配置文件config/puma.rb
#!/usr/bin/env puma
environment 'production'
threads 2, 32 # minimum 2 threads, maximum 64 threads
app_name = 'rails_test'
application_path = "/var/www/#{app_name}"
directory "#{application_path}/current"
pidfile "#{application_path}/shared/tmp/pids/puma.pid"
state_path "#{application_path}/shared/tmp/sockets/puma.state"
stdout_redirect "#{application_path}/shared/log/puma.stdout.log", "#{application_path}/shared/log/puma.stderr.log"
# bind "unix://#{application_path}/shared/tmp/sockets/puma.sock"
bind 'tcp://127.0.0.1:801'
#绑定端口801
worker_timeout 60
daemonize true
preload_app!
关于所有的配置参数，可以在 里面了解。
bundle exec puma -C config/puma.rb
bundle exec pumactl --state tmp/sockets/puma.state stop
bundle exec pumactl --state tmp/sockets/puma.state restartunicorn 使用简介 · Ruby China
Unicorn 是什么？
为 Rack 应用程序设计的 HTTP server
是一个利用Unix的高级特性开发的
为具备低延迟，高带宽的连接的客户服务
为 Rack， Unix， 快速的客户端和易调试而设计。
完全兼容 Ruby 1.8 和 1.9。
进程管理：Unicorn 会获取和重启因应用程序出错导致死亡的任务，不需要自己管理多个进程和端口。Unicorn 可以产生和管理任何数量的任务进程。
负载均衡完全由操作系统(Unix)核心完成。在繁忙的任务进程时，请求也不会堆积。
不需要关心应用程序是否是线程安全的，workers 运行在特们自己独立的地址空间，且一次只为一个客户端服务。
支持所有的 Rack 应用程序。
使用 USR1 信号来固定重复打开应用程序的所有日志文件。Unicorn 也可以逐步的确定一个请求的多行日志放在同一个文件中。
nginx 式的二进制升级，不丢失连接。你可以升级 Unicorn、你的整个应用程序、库、甚至 Ruby 编辑器而不丢失客户端连接。
在 fork 进程时如果由特殊需求可以使用 before_fork 和 after_fork 。如果“preload_app“ 为 false 时，则不能使用。
可以使用 copy-on-wirte-friendly 内存管理来节约内容（通过设置 “preload_app" 为 true ）。
可以监听多接口，包括：UNIX sockets，每个 worker process 也可以在简单调试时通过 after_fork 钩子绑定到私有的端口。
配置使用简单易用的 Ruby DSL。
$ gem install unicorn
# 设定 GEM_HOME
GEM_HOME = "/Users/P.Luo/.rvm/gems/ruby-1.8.7-p340@project_name"
# 获取当前项目路径
require 'pathname'
path = Pathname.new(__FILE__).realpath # 当前文件完整路径
path = path.sub('/config/unicorn.rb', '')
APP_PATH = path.to_s
# 或直接填写
# APP_PATH = "/path_to_project/workspace/project_name"
# worker 数
worker_processes 20
# 项目目录，部署后的项目指向 current，如：/srv/project_name/current
working_directory APP_PATH
# we use a shorter backlog for quicker failover when busy
# 可同时监听 Unix 本地 socket 或 TCP 端口
listen "/tmp/project_name.sock", :backlog =& 64
# 开启tcp 端口，可不使用 apache 或 nginx 做代理，直接本地：http://localhost:port
#listen 8080, :tcp_nopush =& true
# 如果为 REE，则添加 copy_on_wirte_friendly
# /faq.html#adapt_apps_for_cow
if GC.respond_to?(:copy_on_write_friendly=)
GC.copy_on_write_friendly = true
# request 超时时间，超过此时间则自动将此请求杀掉，单位为秒
timeout 180
# unicorn master pid
# unicorn pid 存放路径
pid APP_PATH + "/tmp/pids/unicorn.pid"
# unicorn 日志
stderr_path APP_PATH + "/log/unicorn.stderr.log"
stdout_path APP_PATH + "/log/unicorn.stdout.log"
preload_app true
before_fork do |server, worker|
defined?(ActiveRecord::Base) and
ActiveRecord::Base.connection.disconnect!
after_fork do |server, worker|
defined?(ActiveRecord::Base) and
ActiveRecord::Base.establish_connection
非 Rails Rack 应用程序：
Rails 应用程序（支持Rails 1.2 及之后的版本）
unicorn_rails
参数说明：
unicorn 会默认绑定到8080端口，可以使用 --listen/-l 来选择到不同的 address:port 或者使用 UNIX socket.
-D 以Deamon 形式启动
-c 设定配置文件，如我们的 /workspace/project_name/config/unicorn.rb
-E 设定生产环境或开发环境，如 -E production
$ unicorn_rails -E production -D -c /srv/project_name/current/config/unicorn.rb
$ ps auwx | grep unicorn
获取：master 的pid
$ kill -9 17357
$ unicorn_rails -E production -D -c /srv/project_name/current/config/unicorn.rb
在/etc/init.d/ 目录下添加 init 脚本：
$ sudo /etc/init.d/unicorn.project_name
Usage: /etc/init.d/unicorn.project_name &start|stop|restart|upgrade|force-stop|reopen-logs&
可以运行：sudo /etc/init.d/unicorn.project_name 来进行项目重启、停止、启动...
init 脚本示例（请更改 APP_ROOT － 项目目录 和 APP_USER － 项目所属用户 的值）：
# Feel free to change any of the following variables for your app:
TIMEOUT=${TIMEOUT-60}
APP_ROOT=/srv/project_name/current
APP_USER=username
PID=$APP_ROOT/tmp/pids/unicorn.pid
ENV=production
CMD="bundle exec unicorn_rails -E $ENV -D -c $APP_ROOT/config/unicorn.rb"
action="$1"
old_pid="$PID.oldbin"
cd $APP_ROOT || exit 1
test -s "$PID" && kill -$1 `cat $PID`
oldsig (){
test -s $old_pid && kill -$1 `cat $old_pid`
case $action in
sig 0 && echo &&2 "Already running" && exit 0
su $APP_USER -c "$CMD"
sig QUIT && exit 0
echo &&2 "Not running"
force-stop)
sig TERM && exit 0
echo &&2 "Not running"
restart|reload)
sig HUP && echo reloaded OK && exit 0
echo &&2 "Couldn't reload, starting '$CMD' instead"
su $APP_USER -c "$CMD"
if sig USR2 && sleep2 && sig 0 && oldsig QUIT
n=$TIMEOUT
while test -s $old_pid && test $n -ge 0
printf '.' && sleep 1 && n=$(($n - 1))
if test $n -lt 0 && test -s $old_pid
echo &&2 "$old_pid still exists after $TIMEOUT seconds"
echo &&2 "Couldn't upgrade, starting '$CMD' instead"
su $APP_USER -c "$CMD"
reopen-logs)
echo &&2 "Usage: $0 &start|stop|restart|upgrade|force-stop|reopen-logs&"
请把 project_name 改成自己项目的名称
简单的先放着，因为有其他任务，后续再调格式
因为是自己研究的，有不对的地方，请大家指教，后续也会继续更新的。
支持...为什么rails一直没有一个最好服务器方案呢？老在变
不是再变，而是不断有更好的出来
没有最好，只有更好！
流水不腐，户枢不蠹
好文章，适合科普。
k，这篇文章太打动我了，之前对unicorn完全没有关注过，现在看来很威武
unicorn现在是主流了，github在09年就开始在用：
比passenger好？
Rails项目用unicorn,
Python项目用gunicorn, 然后用supervisor去管理它们。
实践证明sig 0会一直返回False，导致upgrade功能失败。有懂行的人解释下为什么么？
后方可回复, 如果你还没有账号请点击这里 。
共收到 11 条回复Ruby 服务器对比 · Ruby China
本帖已被设为精华帖！
之前一直对 Ruby 的服务器不是很了解，在stackoverflow看到一篇文章感觉不错，顺便翻译了一下，英语不好，如果哪里错了请大家指出，避免误导他人。
原文地址：
The word "deployment" can have two meanings depending on the context. You are also confusing the roles of Apache/Nginx with the roles of other components.
Historic note: This article was originally written on November 6, 2010, when the Ruby app server ecosystem was limited. I've updated this article on March 15 2013 with all the latest updates in the ecosystem.
Disclaimer: I am one of the authors of Phusion Passenger, one of the app servers.
一，Apache vs Nginx
他们都是web服务器，都能伺服静态文件，利用恰当的模块也能伺服动态的web应用。Apache更加流行，拥有更多的功能；Nginx则相对小巧、快速、功能少。
让Apache 和 Nginx 来伺服 Ruby 服务器都不是开箱即用（out-of-the-box）的，为此你需要使用另外的插件来组合他们。
Apache 和 Nginx都能作为反向代理，就是说他们能够把进来的 HTTP 请求发给其他服务器，接着把该服务器的 HTTP 响应转给客户端，后面会看到为什么和这个有关系。
二，Mongrel以及其他production环境的服务器 vs WEBrick
Mongrel是Ruby实现的应用服务器，具体来说：
1，在自己的进程空间中加载 Ruby 应用。
2， 创建一个 TCP socket，允许它可以和外部世界通信(例如Internet)。Mongrel 在这个socket上监听 HTTP 请求，并把请求数据转发给 Ruby 应用。
3，Ruby 应用返回一个描述 HTTP 响应的对象，Mongrel 将其转换为真正的 HTTP 响应字节，并发回到 socket 中。
然而 Mongrel 已经不再维护了，其他替代的服务器是：
Phusion Passenger
Trinidad (JRuby only)
TorqueBox (JRuby only)
接下来我会讲一讲他们和 Mongrel 的区别
WEBrick 和 Mongrel 很像，区别如下：
WEBrick 不适合用于 production。WEBrick 完全是用 Ruby 写的；Mongrel（ 以及其他 Ruby 应用服务器）是部分 Ruby 部分C，主要是 Ruby，但它的 HTTP 解析器为了性能是用 C 写的。
WEBrick 速度比较慢而且不够强壮，有普遍知道的内存泄漏问题，以及 HTTP 解析问题。
因为 WEBrick 是 Ruby 默认自带的，所以 WEBrick 经常用于 development 环境下作为默认服务器，而其他的服务器则需要另外安装。不建议在production 环境下使用 WEBrick 服务器，虽然因为某些原因，Heroku 选择了WEBrick 作为默认服务器，他们以前使用的是 Thin，但我不知道他们为什么换到了 WEBrick。
三，应用服务器世界
当前所有的Ruby 应用服务器都是 HTTP 类型的，一些服务器直接将80端口暴露到 Internet 中，另一些则没有。
暴露80端口的：Phusion Passenger， Rainbows。
没有直接暴露的：Mongrel, Unicorn, Thin, Puma。这些服务器必须必须置于反向代理服务器之后，比如Apache 和 Nginx。
我不了解 Trinidad 和 TorqueBox，所以就忽略了。
为什么有些服务器需要置于反向代理之后？
某些服务器的每个进程在同一时间只能处理一个请求，如果想同时处理两个请求，你就需要启动多个服务器实例，都伺服同一个 Ruby 应用。这种应用服务器进程的集合称为应用服务器集群（比如Mongrel Cluster, Thin Cluster）。然后你必须启动 Apache 或者 Nginx，给集群做反向代理，Apache/Nginx 会处理好集群中不同应用实例间的请求分发。(更多内容参见章节 "I/O并发模型”)
Web 服务器可以缓存请求和响应。有些客户端发送数据、接收数据的速度缓慢，你当然不希望应用服务器在等待客户端收发数据时什么也不干，Web 服务器可以隔离应用服务器和慢客户端。Apache 和 Nginx 擅长同时很多事情，因为他们是多线程或者基于事件的。
大多数的应用服务器可以伺服静态文件，但不擅长，而Apache 和 Nginx可以更快速度处理这件事情。
人们经常直接使用Apache 或者 Nginx伺服静态文件，而不会处理需要转发的请求（forward requests），这是比较安全的策略。Apache 和Nginx足够聪明，可以保护应用服务器远离恶意请求。
为什么有些服务器可以直接暴露在Internet中？
Phusion Passenger 和其他应用服务器不一样，其中一个特点是可以融入其他服务器。
Rainbows 的作者公开指出，Rainbows 可以直接暴露在 Internet 中。他非常确认在解析 HTTP 过程中不会轻易遭受攻击。当然，作者也并不做任何担保，并表示不同应用环境下有其相应的风险。
四，应用服务器对比
在这一章中，我会比较我提过的大多数服务器，但不包括 Phusion Passenger。Phusion Passenger 和其他的不一样，我会单独开出一章。我还会忽略 Trinidad 和 TorqueBox，因为我对他们不是很了解，只有你用到 JRuby 的时候才会涉及到他们。
只有最基础的功能。像之前提到的，Mongrel 仅仅是单线程、多进程，所以它只用于集群（cluster）中。没有进程监控，意味着如果集群中一个进程崩溃了，则需要手动重启。人们需要使用额外的进程来照看 Mongrel，比如 Monit 和 God。
是从 Mongrel 中fork出来的。支持监控一定数量的的进程：如果一个进程崩溃了，则会被主进程自动重启。它能让所有进程都监听同一个共享的socket，而不是每个进程使用单独的socket，这会简化反向代理的配置。像Mongrel一样，Unicorn 是单线程、多进程。
利用 EventMachine 库，实现基于事件的 I/O 模型。它并不是使用 Mongrel 的 HTTP 解析器，没有基于 Mongrel。它的集群节点没有进程监控，所以你需要去监控进程是否崩溃。每个进程监听各自的socket，不像 Unicorn 一样共享socket。理论上来说，Thin 的I/O 模型允许高并发，这也是 Thin 被应用的大部分场合。一个 Thin 的进程只能处理一个并发请求，所以你还需要集群。关于这个古怪的性质，更多内容参见“I/O并发模型”。
也是从 Mongrel 中fork出来的，但和 Unicorn 不一样的是，Puma 是基于多线程，使用 Thread Pool 实现。因为 GIL 的存在，所以 MRI 不能利用多核实现CPU并行，所以你需要特别确认的是你能利用多核。更多内容参见“I/O并发模型”。
通过给不同的库实现多种并发模型 。
五，Phusion Passenger
Phusion Passenger 和其他的不一样。他直接融入 Apache 或者 Nginx，类似于 Apache 的 mod_php。就像 mod_php 使 Apache伺服 PHP 应用一样， Phusion Passenger 也可以使 Apache 或者 Nginx 伺服 Ruby 应用。Phusion Passenger 的目标是所有的事情做起来尽可能地减少麻烦。
如果使用 Phusion Passenger的话，你不需要为你的应用启动一个进程或者集群，为 Apache/Nginx 配置静态目录，或者设置反向代理。
你只需要：
编辑web服务器的配置文件，写入 Ruby 应用下public文件夹的路径
没有第二步。
所有的配置工作都在Web 服务器配置文件的指导下做完了，Phusion Passenger几乎自动化了所有事情，不需要启动集群以及管理进程。启动或者停止进程，他们崩溃时重启，这些都被自动化了。和其他应用服务器相比，Phusion Passenger 所需要做的改动工作非常少，这是人们使用 Phusion Passenger 的主要原因。
和其他应用服务器不同的是，Phusion Passenger 主要是用 C++ 写的，速度很快。
Phusion Passenger 的企业版有更多的特性，比如自动回滚重启，支持多线程，容错部署。（such as automated rolling restarts, multithreading support, deployment error resistance, etc.）
基于以上原因，Phusion Passenger是当前最流行的 Ruby 应用服务器，服务于超过50,000 站点，包括大型站点：New York Times, Pixar, Airbnb。
六，Phusion Passenger vs 其他服务器
相对其他的服务器 ，Phusion Passenger 提供了更多的特性功能：
根据访问量自动调整进程的数量。在资源有限的服务器上，我们运行多个 Ruby 应用，而我们的应用不对外公开，而且组织内的访客每天的访问量也很低，例如 Gitlab, Redmine等。Phusion Passenger 能够在进程不使用的时候挂起他们，需要的时候恢复进程，为更重要的应用腾出资源。相比之下，其他的服务器的所有进程会一直运行着。
有些服务器不适合某些特定的负荷。例如 Unicorn 为轻量快速的请求而设计，See
section "Just Worse in Some Cases".
Unicorn 不擅长的负荷：
& 流（e.g. Rails 4 live streaming or Rails 4 template streaming）
& 调用 HTTP API
及后续版本中多种I/O模型，使它非常适合这种负荷。
其他的应用服务器需要用户为每个应用至少启动一个实例，相比之下，Phusion Passenger 支持一个实例多个应用。这大大减少管理员的开支。
Phusion Passenger 支持多个 MRI Ruby, JRuby 和 Rubinius。Mongrel, Unicorn 和 Thin 只支持 MRI，Puma也支持三个。
Phusion Passenger 不仅支持 Ruby，它还支持 Python WSGI，所以同样能运行 Django 和 Flask 应用。实际上，Phusion Passenger正在向多语言服务器发展的道路上前进，Node.js的支持已经列在计划中。
Out-of-band garbage collection。Phusion Passenger 可以在请求的循坏外执行 Ruby 的垃圾回收，可以潜在地减少几百毫秒的请求时间（reducing request times by hundreds of milliseconds）。Unicorn也有类似的功能，但是Phusion Passenger 的版本更加灵活，因为 1，it's not limited to GC and can be used for arbitrary work。2，Phusion Passenger的版本适应多进程应用，而 Unicorn 则不行。
自动回滚重启（Automated rolling restarts）。Unicorn 以及其他应用服务器的回滚重启需要脚本来执行，Phusion Passenger 企业版自动帮你完成了。
还有更多的特性和优势，暂不一一列举。你可以参考全面的 Phusion Passenger 手册( ,
)，或者到官网得到更多信息。
七，I/O并发模型
单线程，多进程。 Ruby 应用服务器中比较常见、流行的 I/O 模型，主要是因为 Ruby 生态系统中的多线程支持比较差。一个进程同时仅且只能处理一个请求，web 服务器通过多进程来进行均衡负载。这种模型比较稳定，开发者不会轻易造成并发bug。这种模型适合执行快速的短请求，不适合速度慢、长请求阻塞I/O的运算，例如 调用HTTP API。
纯多线程 。现在Ruby生态系统已经很支持多线程了，所以这种I/O模型变得切实可行。多线程支持高I/O并发，既适合短请求也适合长请求。开发者也很容易引入并发bug，幸运的是大多数框架按照这种方式设计，所以也不太可能发生。有一个需要注意的事情是，因为使用了全局解释器锁（GIL），MRI Ruby 解释器不能均衡使用多个CPU内核，即使有多个线程。为此，你可以使用多个进程，每个进程使用一个CPU内核。JRuby 和 Rubinius没有GIL，所以他们的一个进程可以均衡负载多个CPU内核 。
结合多线程、多进程 。Phusion Passenger Enterprise 4以后版本实现了。你可以轻易在以下模型切换：单进程多线程，纯多线程，多进程多线程。这种模型给出了最好的选择方式。
事件。这种模型和之前提到的模型不一样。它允许极高的I/O并发，以及非常适合长请求。为实现此功能，需要从应用到框架的详细支持。然而主要的框架（Rails 和 Sinatra）并不支持事件模型。这也是实际上一个Thin进程同时不能处理多个请求的原因，就像单线程多进程模型一样。只有专门的框架才充分利用事件I/O模型，例如Cramp。
八，Capistrano
Capistrano和其他的不一样。在之前的所有章节中，“部署”指的是在服务器上启动 Ruby 应用，然后对访客开放，但是在这之前需要一些准备工作，例如：
将 Ruby 应用的代码和文件上传到服务器机器上。
安装应用所依赖的库。
创建或者迁移数据库。
启动或者停止应用依赖的守护进程，例如 Sidekiq/Resque
或者 whatever。
启动应用时需要做的所有其他事情。
在 Capistrano 的语义中，“部署”意味着去做所有的准备工作。Capistrano 不是一个服务器，反而是一个自动做那些准备工作的工具。你告诉 Capistrano 你的服务器在哪里，以及每当你部署新版本应用的时候需要执行的命令，Capistrano 就能帮你上传 Ruby 应用到服务器上并且运行你指定的命令。
Capistrano 总是与应用服务器组合使用，并不会替代应用服务器。反之亦然，应用服务器也不会替代 Capistrano。
当然 Capistrano 也不是必须使用的。如果你可以使用 FTP 或者 手动上传 Ruby 应用，每一次都执行相同的动作。其他人厌倦这种重复，所以他们在 Capistrano 中自动执行这些步骤。
out-of-the-box：开箱即用，意思是只需很少量的准备工作就可以干活了，也可引申为“很好的，很适用的……”
这篇文章是Phusion Passenger 的人写的，我当初看完后也选择了 Passenger .
也是从 Mongrel 中fork出来的，但和 Unicorn 不一样的是，Puma 被设计成多进程的。目前不支持集群。你需要特别确认的是你能实现多核 这段翻译地有点大意
Puma 是基于多线程，使用 Thread Pool 实现。因为 GIL 的存在，所以 MRI 不能利用多核实现CPU并行，所以你需要特别确认的是你能利用多核。
感谢指正，已修改
「Neither Apache nor Nginx can serve Ruby web apps out-of-the-box」
「让Apache 和 Nginx 来伺服 Ruby 服务器都是开箱即用（out-of-the-box）的」
貌似意思反了，应该是「都不是开箱即用的」
反正一直是passenger，方便……
最早用的passenger,中间用了thin/puma/rainbows,意在提高并发,但Ruby多线程并发并不可靠,整体性能和可靠性还不如passenger开线程安全模式.
改用passenger了，感觉很省事
现在流行的基本上是heroku那套了吧。
这个要收藏咯
有的小脚本程序我就用WEBrick来跑sinatra...接收来自主服务器的操作。。挺稳定的。。
如果有 phusion passenger 5 (raptor) vs unicorn 的性能测试我就点赞
这个帖子 收藏了 谢谢楼的分享！
Heroku 现在推荐使用 Puma
嗯，rails支持多线程安全之后，Puma
和rainbows这种多线程的服务器必然越来越得势。
Passenger 以前常用，后来就不太用了。主要是nginx会经常需要升级，如果同时需要每次再编译甚至升级passenger总感觉比较麻烦。
Nginx+Puma/Rainbows/Unicorn长期运维省事一些。
Heroku 选择了WEBrick 作为默认服务器
据我所知 Heroku 换成了 Unicorn
passenger牛逼的功能都是企业版提供的呀..
"still, the author provides no warranty and says that usage is at own risk." 这一句应该可以翻译为：“当然，作者也并不做任何担保，并表示不同应用环境下有其相应的风险。”
"Bare bone" 翻译成暴露的石头？裸露的骨头还可以原谅，可以翻译成“只有最基础的功能”。
感谢指正，已修改
22楼 已删除
據我所知，Heroku 換成了 Puma（見 ）
后方可回复, 如果你还没有账号请点击这里 。
共收到 22 条回复