Rails_00011

$ cap deploy:check
和前面一样，我们可能需要将 deploy.rb 文件中 default_environment 一行前的注释符去掉 并且调整该项。我们重复执行该命令，直到完全没有问题。 现在可以做部署了。由于我们已经做好了必要的前期准备工作并且检查了结果，部署应该很顺利：
$ cap deploy:migrations
# On your server $ cd /home/rubys/work/depot/ $ tail -f l来自g/production.log
有时候我们还需要一些更底层的信息——应用程序中的数据到底是什么样子？此时就该祭出最有 用、最强大的现场调试工具了……
console 脚本现场查看应用程序 Using Console to Look at a Live Application
$ cap deploy:setup
运行该命令时， Capistrano 会提示输入服务器密码。 如果执行失败就不能登陆， 将 deploy.rb 文 件 default_run_options 一行前的注释符去掉后再试一次。一旦成功连接，它就会建立所需的目录。 命名完成后，我们可以检查一下，看看是否还有其他问题：
depot> ruby script/plugin install git:///rails/exception_notification.git
Web 开发敏捷之道——应用 Ralls 进行敏捷 Web 开发，第 3 版
1.1 然后在应用程序的控制器中加上下列代码：
class ApplicationController < ActionController::Base include ExceptionNotifiable # ...
更多选项请看 /rails/pages/DeploymentTips.
清理 session Clearing Out Sessions
如果你不是使用基于 cookie 的 session 管理机制， 要注意 Rails 不会自动帮我们清理 session： 它只管创建 session 数据，却不会删除已经过期的 session。不用太长时间这就会成问题——如果使 用默认的、基于文件的 session 存储策略(而不是将 session 存入数据库)，问题会来得更快；不过不 管采用哪种存储策略，我们所面对的都是理论上无限的数据。 既然 Rails 不会帮我们清理 session，我们就得自己动手做。最简单的清理办法就是定时执行一 段脚本：如果 session 放在文件中，这段脚本就应该找出己经过期的 session 数据，并将它们删掉。 譬如说，可以在脚本中执行下列命令，以删除超过 12 小时不被使用的 session 文件。
28.7
上线，并不断前进 Moving On to Launch and Beyond
将部署环境配置好之后，我们就可以在开发工作告一段落时将应用程序上线投入生产运行。今后我
们还可能增加更多的部署服务器， 第一次部署中学到的经验将帮助我们决定未来部署环境的结构。 譬如说 ， 我们可能会发现 Rails 是整个系统中比较慢的一部分， 大部分时间都被耗费在 Rails 上， 而不是数据库 或者文件系统。此时我们就应该添加更多的应用服务器，以便分散 Rails 的负载压力，提升整个系统的 性能。 但我们也可能发现大量时间被耗费在数据库上。如果情况果真如此，就应该想办法对其进行优化： 可能需要改变访问数据的方式，也可能用一些精心优化的 SQL 来替代 ActiveRecord 的默认查询。 总之有一件事是明白无疑的：每个应用程序都需要专门的精心呵护。最重要的就是要经常倾听应用 程序的声音，发现它的需要。作为软件开发者，上线并不是我们工作的终结——那才是真正的开始。 当你想要研究其他的部署选项，可以在“部署 Rails 应用：分步指南”[ZT08]中找到大量好的建 议。
28.5
检查已部署的应用程序 Checking Up on a Deployed Application
Web 开发敏捷之道——应用 Ralls 进行敏捷 Web 开发，第 3 版
1.1
Rails 是敏捷的
497
在应用程序部署之后，无疑我们还需要经常检查它是否运行良好。有两种主要的检查方式，其一是 查 看 各 种 日 志 文 件 — — 包 括 前 端 web 服 务 器 和 后 端 Mongrel 实 例 产 出 的 日 志 ： 其 二 是 用 script/console 连接到应用程序内部。
$ $ $ $ git git git cap add . commit -m "add cap files" push deploy
前三条命令会更新 SCM 服务器。一旦你更加熟悉 Git,您可能想要更精细的控制什么时候和什么文 件要添加进来，您可能想在部署之前逐步实施多个改动，等等。只有最好一条命令才会更新我们的应用、 web 和数据库服务器。 如果出于某种原因我们需要将应用程序回退到从前的某个版本，可以使用下列命令：
查看日志文件 Looking at Log Files
要想快速了解应用程序中发生了什么，可以用 tail 命令来查看日志文件，看看在收到请求之后应 用程序都输出了哪些日志。最有趣的数据往往就在日志文件中。即使运行 Apache 了多个应用，每个应 用的日志都会被放进到该应用的 production.log 文件中。 假设应用程序部署的位置与此前的例子相同，下面就是查看日志文件所需的命令：
config.logger = Logger.new(config.log_path, 10, 10.megabytes) config.logger = Logger.new(config.log_path, 'daily')
我们也可以直接将日志设为系统日志：
config.logger = SyslogLogger.new
生产环境中失败的处理不同于开发环境。在开发环境中，我们能得到非常多的调试信息，但在生产 环境中，默认的方式是渲染一个包含有抛出错误的 action 名的静态 HTML 文件。可以通过覆盖 rescue_action_in_public 和 rescue_action_locally 方法来定制恢复错误的方式。我们可以 在控制器中覆盖被认为是本地请求的 local_request？()方法。 相比于编写一个定制的恢复方法，我们可能更希望在应用程序抛出异常时能够将相应信息通过邮件 发送给技术支持人员，exception notification 插件就可以提供这样的功能。首先安装该插件：
496
end
第 30 章
部署与生产
我 们 需 要 编 辑 几 个 属 性 来 适 应 我 们 的 应 用 。 毫 无 疑 问 ， 我 们 要 改 变:user、:domain 和:application。:repository 要对应于前面 Git 存放的地方。:deploy_to 要匹配到我们告诉 Apache 能找到 config/public 目录的地方。 default_run_options 和 default_environment 只有在遇到特定问题时才有用。 这里的 “miscellaneous options” 是基于 Git 的 这里定义了两个任务。一个是告诉 Capistrano 如何重启 Passenger。另一个是通过拷贝我们前 面放到服务器端的 database.yml 文件来更新该文件。在需要时你可以随时调整这些任务。 第一次部署应用时，我们需要一个额外步骤来设置部署到服务器的基本目录结构。
应用程序的模型类包含了大量的功能，一般而言，这些功能都是提供给控制器去使用的，但我们也 可以和模型类直接交互。进入这个世界的大门就是 script/console 脚本，用下列命令就可以开启这扇 大门：
# On your server $ cd /home/rubys/work/depot/ $ ruby ./script/console production Loading production environment. irb(main):001:0> p = Product.find_by_title("Pragmatic Version Control") => #<Product:0x24797b4 @attributes={. . .} irb(main):002:0> p.price = 32.95 => 32.95 irb(main):003:0> p.save => true
Web 开发敏捷之道——应用 Ralls 进行敏捷 Web 开发，第 3 版
开启一个 console 会话之后，就可以调用模型对象的所有方法。我们可以创建、查看或是删除记 录，这就是操作整个应用程序的入口。
28.6
投入生产运行之后的琐事 Production Application Chores
应用程序投入生产运行之后，还有一些日常琐事需要关注，这样应用程序才能运行良好。这些杂事
不会自动被处理，幸运的是，我们可以让他们这样。
Web 开发敏捷之道——应用 Ralls 进行敏捷 Web 开发，第 3 版
498
第 30 章
部署与生产
处理日志文件 Dealing with Log Files
应用程序在运行过程中会不断往日志文件中输出数据，最后日志文件会变得臃肿不堪。要解决这个 问题，大部分日志工具都提供了日志分卷(roll over)的功能：按照时间将日志分为多个文件。这样庞 大的日志就可以分为可管理的小块，可以将较早的日志存档保管，甚至将过时的日志直接删除。 Logger 类也支持分卷。我们只需决定需要保留几个(或多长时间的)日志文件以及每个文件的大小 就可以了。要让其生效，也只需将其中一行加入到 config/environments/production.rb 文件中 即可：