ruby/Rack应用快速入门

以下指导将带你安装和运行一个基于Ruby的uWSGI发行版 ，旨在运行Rack应用。

安装带Ruby支持的uWSGI

要构建uWSGI，你需要一个C编译器 (支持gcc和clang) 和Python二进制文件 (用来运行uwsgiconfig.py脚本，它将执行各种编译步骤)。

因为我们正在构建一个带Ruby支持的uWSGI二进制文件，因此我们也需要Ruby开发头文件 (基于Debian发行版上的 ruby-dev 包)。

你可以手工构建uWSGI —— 这些都是等价的：

  1. make rack
  2. UWSGI_PROFILE=rack make
  3. make PROFILE=rack
  4. python uwsgiconfig.py --build rack

但是如果你懒癌犯了，那么你可以一次性下载、构建和安装一个uWSGI + Ruby二进制文件：

  1. curl http://uwsgi.it/install | bash -s rack /tmp/uwsgi

或者以一种更“Ruby友好型”方式：

  1. gem install uwsgi

这些方法都构建一个“单片”uWSGI二进制文件。uWSGI项目是由许多插件注册的。你可以选择构建服务器核心，并为每个特性使用一个插件（需要时加载），或者你可以构建一个带有所有你需要的特性的单个二进制文件。后者这种构建称之为“单片”。

这个快速入门假设使用一个单片二进制文件 (因此你无需加载插件)。如果你更喜欢使用你的包发行版 (而不是从官方来源构建uWSGI)，那么见下。

关于发布包的注意事项

你的发行版非常有可能包含一个uWSGI包集合。那些uWSGI包趋向于高模块化的 (并且偶尔高度过时)，因此，除了核心部分之外，你需要安装所需插件。必须在你的uWSGI配置中加载插件。在学习阶段，我们强烈建议不要使用发行版包，从而轻松跟着文档和教程。

一旦你适应了“uWSGI方式”，你就可以为你的部署选择最佳方式。

例如，本教程利用”http”和”rack”插件。如果你正使用模块化构建，那么确保通过 —plugins http,rack 选项加载它们。

你的第一个Rack应用

Rack是编写Ruby web应用的标准方式。

这是一个标准的Rack Hello world脚本 (称之为app.ru)：

  1. class App
  2.  
  3.   def call(environ)
  4.     [200, {'Content-Type' => 'text/html'}, ['Hello']]
  5.   end
  6.  
  7. end
  8.  
  9. run App.new

扩展名 .ru 表示”rackup”，这是Rack发行版中包含的部署工具。Rackup使用了一点DSL，因此，要将其用到uWSGI中，你需要安装rack gem：

  1. gem install rack

现在，我们准备好部署uWSGI了：

  1. uwsgi --http :8080 --http-modifier1 7 --rack app.ru

(如果‘uwsgi’并不在你当前的$PATH中，记得替换它)

或者如果你正使用的是一个模块化构建 (就像你的发行版的那个)

  1. uwsgi --plugins http,rack --http :8080 --http-modifier1 7 --rack app.ru

使用这个命令行，我们生成了一个HTTP代理，路由每个请求到一个进程 (名为’worker’)，进程管理它并把响应发送回HTTP路由器 (接着路由器发送回客户端)。

如果你对为什么生成两个进程有疑问，那么（我告诉你）是因为这是你将会在生产上使用的正常架构 (一个带有一个后端应用服务器的前线web服务器)。

如果你不想要生成HTTP代理，而是直接强制worker应答HTTP请求，那么仅需将命令行修改为

  1. uwsgi --http-socket :8080 --http-socket-modifier1 7 --rack app.ru

现在，你有了单个管理请求的进程了 (但记住，直接将应用服务器公开一般是危险的，并且并不通用)。

那个’–http-modifier1 7’东东是啥？

uWSGI支持多种语言和平台。当服务器接收到一个请求的时候，它必须知道将其“路由” 到哪里。

每个uWSGI插件都有一个分配的数字 (即modifier)，ruby/rack这个使用的是7。因此， —http-modifier1 7 意思是“路由到rack插件”。

虽然uWSGI也有一个更加“人类友好型”的 internal routing system ，但是，使用modifier是最快的方式，所以，尽可能使用它们。

使用一个完整的web服务器：nginx

提供的HTTP路由器，是 (是哒，真的已经够了) 只是一个路由器。你可以将它当成一个负载均衡器或者代理使用，但是如果你需要一个完整的web服务器 (用于有效提供静态文件，或者一个web服务器所擅长的所有那些任务)，那么你可以摆脱uwsgi HTTP路由器 (如果你正使用模块化构建，那么记得修改–plugins http,rack为–plugins rack)，然后将你的应用放在Nginx之后。

为了与Nginx通信，uWSGI可以使用多个协议：HTTP, uwsgi, FastCGI, SCGI, 等等。

最有效的是uwsgi。Nginx默认支持uwsgi协议。

在一个uwsgi socket上运行你的rack应用：

  1. uwsgi --socket 127.0.0.1:3031 --rack app.ru

然后在你的nginx配置中添加一个location节

  1. location / {
  2.     include uwsgi_params;
  3.     uwsgi_pass 127.0.0.1:3031;
  4.     uwsgi_modifier1 7;
  5. }

重载你的nginx服务器，然后它应该开始代理请求到你的uWSGI实例。

注意，你不需要配置uWSGI来设置一个指定的modifier，nginx将会使用 uwsgi_modifier1 5; 指令来实现它。

添加并发性

通过前面的例子，你部署了一个能够服务单个请求的栈。

要增加并发性，你需要添加更多的进程。如果你希望有一个魔法数学公式可以找到要生成的正确进程数，嗯……很抱歉，我们没有。你需要进行实验，并且监控你的应用，以找到正确的值。考虑到每个进程是你的应用的一个完全拷贝，因此，必须考虑内存使用。

要添加更多的进程，只需使用 –processes <n> 选项：

  1. uwsgi --socket 127.0.0.1:3031 --rack app.ru --processes 8

将生成8个进程。

Ruby 1.9/2.0引入了一个改进的线程支持，uWSGI通过’rbthreads’插件支持它。当你编译uWSGI+ruby (>=1.9)单片二进制文件的时候，会自动内建这个插件。

要添加更多线程：

  1. uwsgi --socket 127.0.0.1:3031 --rack app.ru --rbthreads 4

或者线程+进程

  1. uwsgi --socket 127.0.0.1:3031 --rack app.ru --processes --rbthreads 4

有其他（一般更高级/复杂）的方式来提高并发性 (例如，’fiber’)，但是，大多时候，你最终会得到一个普通的旧式多进程或者多线程模型。如果你感兴趣，那么请查看 Rack 之上的完整文档。

添加健壮性：Master进程

It is highly recommended to have the uWSGI master process always running on productions apps.

It will constantly monitor your processes/threads and will add fun features like the uWSGI Stats服务器.

To enable the master simply add —master

  1. uwsgi --socket 127.0.0.1:3031 --rack app.ru --processes 4 --master

使用配置文件

uWSGI有数百个选项 (但一般来说，你不会使用超过数十个)。通过命令行处理它们有点蠢，因此，试着总是使用配置文件。

uWSGI支持各种标准 (XML, INI, JSON, YAML, 等等)。从一个移到另一个相当简单。你可以通过命令行使用的相同的选项也可以在配置文件中使用，只需将前缀 — 移除：

  1. [uwsgi]
  2. socket = 127.0.0.1:3031
  3. rack = app.ru
  4. processes = 4
  5. master = true

或者xml:

  1. <uwsgi>
  2.   <socket>127.0.0.1:3031</socket>
  3.   <rack>app.ru</rack>
  4.   <processes>4</processes>
  5.   <master/>
  6. </uwsgi>

要通过配置文件运行uWSGI，只需将其当做一个参数指定：

  1. uwsgi yourconfig.ini

如果出于某些原因，你的配置不以期望的扩展名 (.ini, .xml, .yml, .js) 结尾，那么你可以通过这种方式，强制二进制文件使用一个指定的解析器：

  1. uwsgi --ini yourconfig.foo
  1. uwsgi --xml yourconfig.foo
  1. uwsgi --yaml yourconfig.foo

等等等等。

你甚至可以通过管道使用配置 (使用破折号强制从标准输入中读取)：

  1. ruby myjsonconfig_generator.rb | uwsgi --json -

当你生成多个进程时的fork()问题

uWSGI某种程度上是“Perl化的”，我们没法隐藏它。它的大多数抉择 (从“不止一种实现的方式”开始) 来自于Perl世界 (更一般来说，是来自于传统的UNIX系统管理员方法)。

当应用到其他语言/平台上的时候，这个方法有时会导致意外行为。

当你开始学习uWSGI的时候，你会面对的其中一个“问题”是它的 fork() 使用。

默认情况下，uWSGI在第一个生成的进程中加载你的应用，然后多次 fork() 自身。

这意味着，你的应用被单次加载，然后被拷贝。

虽然这个方法加速了服务器的启动，但是有些应用在这项技术下会出问题 (特别是那些在启动时初始化db连接的应用，因为将会在子进程中继承连接的文件描述符)。

如果你对uWSGI使用的粗暴的preforking不确定，那么只需使用 —lazy-apps 选项来禁用它。它将会强制uWSGI在每个worker中完全加载你的应用一次。

部署Sinatra

让我们忘掉fork()，回到有趣的事情上来。这次，我们部署一个Sinatra应用：

  1. require 'sinatra'
  2.  
  3. get '/hi' do
  4.   "Hello World"
  5. end
  6.  
  7. run Sinatra::Application

将其另存为 config.ru ，然后如前所见那样运行：

  1. [uwsgi]
  2. socket = 127.0.0.1:3031
  3. rack = config.ru
  4. master = true
  5. processes = 4
  6. lazy-apps = true
  1. uwsgi yourconf.ini

好吧，或许你已经注意到，基本与前面的app.ru例子没啥区别。

这是因为，基本上，每个现代的Rack应用都将其自身作为一个.ru文件（一般称为config.ru）公开，因此，无需使用多个选项来加载应用 (例如，像Python/WSGI世界中的那样)。

部署RubyOnRails >= 3

从3.0起，Rails就是完全兼容Rack的，并且它公开了一个你可以直接加载的config.ru文件 (就像我们用Sinatra那样)。

与Sinatra的唯一不同是，你的项目有一个特定的布局/约定，期望你当前的工作目录是包含项目的那个目录，因此，让我们添加一个chdir选项：

  1. [uwsgi]
  2. socket = 127.0.0.1:3031
  3. rack = config.ru
  4. master = true
  5. processes = 4
  6. lazy-apps = true
  7. chdir = <path_to_your_rails_app>
  8. env = RAILS_ENV=production
  1. uwsgi yourconf.ini

除了chdir之外，我们添加了’env’选项，它设置 RAILS_ENV 环境变量。

从4.0起，Rails支持多线程 (只适用于ruby 2.0)：

  1. [uwsgi]
  2. socket = 127.0.0.1:3031
  3. rack = config.ru
  4. master = true
  5. processes = 4
  6. rbthreads = 2
  7. lazy-apps = true
  8. chdir = <path_to_your_rails_app>
  9. env = RAILS_ENV=production

部署更老的RubyOnRails

较老的Rails版本并非完全Rack兼容的。出于这样的原因，uWSGI中有一个特定的选项，用来加载较老的Rails应用 (你也会需要’thin’这个gem)。

  1. [uwsgi]
  2. socket = 127.0.0.1:3031
  3. master = true
  4. processes = 4
  5. lazy-apps = true
  6. rails = <path_to_your_rails_app>
  7. env = RAILS_ENV=production

所以，长话短说，指定 rails 选项，将rails应用的目录（而不是Rackup文件）作为参数传递。

Bundler和RVM

Bundler是用来管理依赖的标准的事实上的Ruby工具。基本上，你在Gemfile文本文件中指定你的应用所需的gem，然后启动bundler来安装它们。

要让uWSGI遵守bundler安装，你只需要添加：

  1. rbrequire = rubygems
  2. rbrequire = bundler/setup
  3. env = BUNDLE_GEMFILE=<path_to_your_Gemfile>

(第一个并非ruby 1.9/2.x要求的必须节。)

基本上，这些行强制uWSGI加载bundler引擎，并且使用在 BUNDLE_GEMFILE 环境变量中指定的Gemfile。

当使用Bundler的时候 (就像现代框架所做的那样)，你的常见部署配置将会是：

  1. [uwsgi]
  2. socket = 127.0.0.1:3031
  3. rack = config.ru
  4. master = true
  5. processes = 4
  6. lazy-apps = true
  7. rbrequire = rubygems
  8. rbrequire = bundler/setup
  9. env = BUNDLE_GEMFILE=<path_to_your_Gemfile>

除了Bundler之外，RVM是另一个常见的工具。

它允许你在单个系统中安装多个 (独立的) Ruby版本 (带自己的gemset)。

要指示uWSGI使用一个指定RVM版本的gemset，只需使用 –gemset 选项：

  1. [uwsgi]
  2. socket = 127.0.0.1:3031
  3. rack = config.ru
  4. master = true
  5. processes = 4
  6. lazy-apps = true
  7. rbrequire = rubygems
  8. rbrequire = bundler/setup
  9. env = BUNDLE_GEMFILE=<path_to_your_Gemfile>
  10. gemset = ruby-2.0@foobar

只是注意，对于每个Ruby版本（是Ruby版本，不是gemset！），你都需要一个uWSGI二进制文件（或者如果你使用模块化构建，则是一个插件）。

如果你有兴趣，那么这里是构建uWSGI核心+每个rvm中安装的Ruby版本1个插件的命令列表。

  1. # build the core
  2. make nolang
  3. # build plugin for 1.8.7
  4. rvm use 1.8.7
  5. ./uwsgi --build-plugin "plugins/rack rack187"
  6. # build for 1.9.2
  7. rvm use 1.9.2
  8. ./uwsgi --build-plugin "plugins/rack rack192"
  9. # and so on...

然后，如果你想要使用ruby 1.9.2和@oops gemset：

  1. [uwsgi]
  2. plugins = ruby192
  3. socket = 127.0.0.1:3031
  4. rack = config.ru
  5. master = true
  6. processes = 4
  7. lazy-apps = true
  8. rbrequire = rubygems
  9. rbrequire = bundler/setup
  10. env = BUNDLE_GEMFILE=<path_to_your_Gemfile>
  11. gemset = ruby-1.9.2@oops

开机时自动启动uWSGI

如果你正想着打开vi，然后编写一个init.d脚本来生成uWSGI，那么坐下（并且淡定），首先确保你的系统并没有提供一个更好（更现代）的方法。

每个发行版都选择了一个启动系统 (Upstart, Systemd…)，并且有大量可用的进程管理器 (supervisord, god, monit, circus…)。

uWSGI将与它们完美集成（我们希望），但是如果你计划部署大量的应用，那么看看uWSGI Emperor - 它或多或少是每个devops工程师的梦想。

安全性和可用性

总是避免以root运行你的uWSGI实例。你可以使用uid和gid选项来移除特权。

  1. [uwsgi]
  2. socket = 127.0.0.1:3031
  3. uid = foo
  4. gid = bar
  5. chdir = path_toyour_app
  6. rack = app.ru
  7. master = true
  8. processes = 8

web应用部署的一个常见问题是“卡住的请求”。你所有的线程/worker都卡住了 (请求阻塞) ，而你的应用无法接收更多的请求。

要避免这个问题，你可以设置一个 harakiri 定时器。它是一个监控器 (由master进程管理)，会摧毁那些卡住超过指定秒数的进程。

  1. [uwsgi]
  2. socket = 127.0.0.1:3031
  3. uid = foo
  4. gid = bar
  5. chdir = path_toyour_app
  6. rack = app.ru
  7. master = true
  8. processes = 8
  9. harakiri = 30

这将会摧毁那些阻塞超过30秒的worker。小心选择 harakiri 值！

除此之外，自uWSGI 1.9起，stats服务器导出了全部请求变量，因此，你可以（实时）看到你的实例正在做什么 (对于每个worker, thread 或者异步核)。

启用统计信息服务器是很简单的：

  1. [uwsgi]
  2. socket = 127.0.0.1:3031
  3. uid = foo
  4. gid = bar
  5. chdir = path_to_your_app
  6. rack = app.ru
  7. master = true
  8. processes = 8
  9. harakiri = 30
  10. stats = 127.0.0.1:5000

只需将其绑定到一个地址 (UNIX或者TCP) 上，并且只需连接 (你也可以使用telnet) 到它上面，来接收你的实例的一个JSON内容。

uwsgitop 应用 (你可以在官方的github仓库中找到它) 是一个使用统计信息服务器来实现类top实时监控的工具的例子 (有颜色！！！)

内存使用

低内存使用是整个uWSGI项目的卖点之一。

不幸的是，默认对内存的积极态度也许（看好：是也许）会导致某些性能问题。

默认情况下，uWSGI Rack插件在每次请求之后调用Ruby GC (垃圾回收器)。如果你想要减少这个频率，只需添加–rb-gc-freq &lt;n&gt; 选项，其中，n是调用GC之后的请求数。

如果你计划进行uWSGI的基准 (或者把它与其他方法对比)，那么考虑它对GC的使用。

Ruby可以是一个真正的内存吞噬者，因此，我们更喜欢默认积极对待内存，而不是取悦hello-world基准点。

卸载

uWSGI 卸载(offloading)子系统 允许你在某些特定的模式匹配的时候尽快释放你的worker，并且能够委托给一个纯c线程。例如，发送来自文件系统的静态文件，从网络传输数据到客户端，等等。

卸载是非常复杂的，但是它的使用对终端用户是透明的。如果你想要试一试，那么只需添加–offload-threads <n>，其中，<n>是要生成的线程数 (一个cpu一个线程是个不错的值)。

当启用了卸载线程时，所有可以被优化的部分将会被自动检测到。

以及现在

有了这些许概念，你应该已经可以上生产了，但是uWSGI是个巨大的项目，它有数百个特性和配置。如果你想要成为一个更好的系统管理员，那么请求继续阅读完整的文档。

欢迎进入uWSGI的世界！