部署现代 Web 应用——具备所有必要的配置，使其快速、安全且易于更新——已经变得如此困难，以至于许多开发者不敢在没有 PaaS（平台即服务）的情况下进行部署。但这太荒谬了。没人应该为基本计算支付高出几倍的价格，仅仅是为了让部署变得友好且可用。这是开源的任务，Rails 8 已经准备好解决这个问题。因此，我们非常高兴地宣布 Rails 8.0 的最终版本现已发布，此前已成功发布了 beta 版和几个发布候选版！
以下是所有主要的新功能
Rails 8 预装了 Kamal 2，可将您的应用部署到任何地方。无论是云虚拟机还是您自己的硬件。Kamal 只需要一个崭新的 Linux 服务器，并只需一个“kamal setup”命令，就能将其变成应用或配件服务器。它只需要包含您 SSH 密钥的服务器 IP 地址列表，您就可以在两分钟内准备好上线生产环境。
Kamal 之所以能如此轻松地做到这一点，是因为 Rails 自带了一个高度高效且经过优化的 Dockerfile，可以直接将您的应用程序构建成生产就绪的容器镜像。您只需准备好自己的容器注册表账户，如 Docker Hub 或 GitHub，用于存储镜像。
在 Rails 8 中，此 Dockerfile 已升级，包含了一个名为 Thruster 的新代理，它位于 Puma Web 服务器的前面，提供 X-Sendfile 加速、资源缓存和资源压缩。这意味着无需在前面部署 Nginx 或任何其他 Web 服务器。默认的 Rails 容器即可立即接受来自互联网的流量。
Kamal 2 还包含一个代理，这次是名为 Kamal Proxy 的定制化组件，取代了其发布初期的通用 Traefik 选项。此代理提供超快速的零停机部署、通过 Let's Encrypt 自动化的 SSL 证书，以及支持在单个服务器上部署多个应用，无需任何复杂的配置。
结合改进的秘密管理策略（内置集成 1password、Bitwarden 和 LastPass）以及新的别名功能，例如“kamal console”，用于启动远程 Rails 控制台会话，它提供了一个完整的解决方案，不仅处理部署，还处理您应用在生产环境的运维。
Kamal 2 由 37signals 的 Donal McBreen 主导，Kamal Proxy + Thruster 由 37signals 的 Kevin McConnell 创建。
使 Rails 更易于部署的一部分是减少启动所需的辅助服务数量。过去，Rails 需要 MySQL 或 PostgreSQL 以及 Redis 来充分利用其所有功能，如作业、缓存和 WebSockets。现在，由于引入了 Solid Cable、Solid Cache 和 Solid Queue 这三个由数据库支持的新适配器，所有这些都可以使用 SQLite 完成。
这些适配器都基于同一个前提：磁盘的速度已经足够快，我们不需要 RAM 来处理那么多任务。这使我们能够利用 SSD 和 NVMe 驱动器比老式旋转硬盘快几个数量级的简化优势。
Solid Cable 取代了 Redis 作为 pubsub 服务器的需求，用于将 WebSocket 消息从应用程序中继到连接到不同进程的客户端。它使用快速轮询，但当在同一服务器上通过 SQLite 运行时，其速度几乎与 Redis 相当。对于大多数应用程序来说，速度已经足够快了。此外，Solid Cable 默认会保留数据库中发送的消息一天，这可以帮助调试棘手的实时更新问题。
Solid Cable 由 Working Not Working 的 Nick Pezza 创建。
Solid Cache 取代了 Redis 或 Memcached 在存储 HTML 片段缓存方面的需求。除了消除辅助服务依赖外，由于使用磁盘存储而非 RAM 存储，它还允许更大的缓存并且成本更低。这意味着您的缓存可以保存更长时间，并覆盖更多请求。此外，此缓存可以加密，并由明确的保留期限（例如 30 或 60 天）管理。这使得遵守现代隐私政策和期望更加容易。
Solid Cache 已在 Basecamp 生产环境中使用一年多，存储了 10 TB 的数据，实现了完整的 60 天保留期，并在引入后将 P95 渲染时间缩短了一半。
Solid Cache 由 37signals 的 Donal McBreen 创建。
Solid Queue 对大多数人来说，它不仅取代了 Redis，还取代了像 Resque、Delayed Job 或 Sidekiq 这样的独立作业运行框架。对于高性能安装，它建立在 PostgreSQL 9.5 中首次引入的新 FOR UPDATE SKIP LOCKED 机制之上，但现在也可在 MySQL 8.0 及更高版本中使用。对于需求更温和的情况，它也适用于 SQLite，这使其成为零依赖路径的理想选择，可以快速获得将您的工作部署到生产环境的成就感。
Solid Queue 可以作为 puma 插件运行（这是单服务器安装的默认设置），或者使用新的 bin/jobs 命令来启动一个专用的调度器。可以运行多个调度器，根据定制的性能调优处理专用队列，所有这些都具有灵活的配置方案，开箱即用无需任何调整，但一旦需要，您就可以获得所有控制选项。
它几乎具备了您对现代作业队列系统所需的所有功能。包括强大的并发控制、失败重试和警报、周期性作业调度等等。在 HEY 中，它取代了多达 6 个（！）不同的 Resque gem，成为集成解决方案。
Solid Queue 在过去 18 个月内，在真实生产环境的压力下得到了精心开发，如今仅 HEY 每天就运行 2000 万个作业。
Solid Queue 由 37signals 的 Rosa Gutiérrez 创建。
除了让 SQLite 能够驱动 Action Cable、Rails.cache 和 Active Job 的 Solid 适配器三件套之外，Rails 8 在使 SQLite 适配器和 Ruby 驱动程序适合实际生产使用方面也付出了很多努力。
在 37signals，我们正在构建一个使用 SQLite 生产环境的应用程序套件，其中包括 ONCE。现在有数千个 Campfire 和 Writebook 的安装在运行，它们都使用 SQLite。这意味着需要对确保 Rails（和 Ruby）能够尽可能好地支持这个出色的文件数据库施加大量真实世界的压力。通过正确的默认设置，如 WAL 和 IMMEDIATE 模式。特别感谢 Stephen Margheim 为一系列此类改进做出的贡献，以及 Mike Dalessio 解决了 Ruby 驱动程序中最后一个 SQLite 文件损坏问题。
但 Rails 8 不仅仅是改进了部署流程和数据库驱动的适配器。我们还将 Propshaft 作为新的默认资源管道。Propshaft 是 #NOBUILD 任务在 Rails 7 中作为默认路径（并将更复杂的 JavaScript 设置移交给 bun/esbuild/vite/etc.）的成果。作为新的资源管道，它取代了可以追溯到 2009 年的旧 Sprockets 系统。那个时代还没有我们今天所知的 JavaScript transpiler 和构建管道。也远远早于我们能想象到具有出色 JavaScript 实现、import maps，并且由于 HTTP/2 而不再受制于大量小文件的浏览器。
这是一个很好的例子，说明了偶尔需要重新审视一个熟悉的问题，从根本上重新考虑。结果是，在我们新的 #NOBUILD 世界中，资源管道只需要做两件事：为资源提供加载路径，并为它们添加摘要以实现远期过期。基本就是这样。Sprockets 做了数百万件其他事情，其中许多早已不再流行，而且由于维护困难，很少有贡献者愿意或能够帮助修复它。
因此，我们感谢 Sprockets 15 年的服务，但 Rails 资源管道的未来是 Propshaft。它现在是所有 Rails 8 应用程序的默认选项，但我们将继续支持现有应用程序的 Sprockets。
Propshaft 由 37signals 的 David Heinemeier Hansson 和 FestaLab 的 Breno Gazzola 创建。
最后，更容易上线生产也意味着我们应该让安全变得容易。Rails 长期以来一直在为出色的身份验证系统的关键组件构建高级抽象，以简化这一点。自 Rails 5 起，我们就有 has_secure_password，并且在 Rails 7.1 中还引入了 generates_token_for :password_reset 和 authenticate_by。现在，随着 Rails 8 的发布，我们将所有这些零散的组件整合到一个完整的身份验证系统生成器中，它为基于会话、可重置密码、元数据跟踪的身份验证系统提供了一个出色的起点。
只需运行 bin/rails generate authentication，您就可以获得 Session 和 User 的基本模型，以及 PasswordsMailer、SessionsController 和一个 Authentication concern。您只需要自己实现用户注册流程（因为这些通常是每个应用程序定制的）。有了这些基础，您就不必担心自己构建身份验证系统（或者，天哪，为此付费给供应商！）。
Rails 8 在 Rails 7.2 发布后仅几个月就发布了，但除了上述所有令人难以置信的新工具外，还包含了大量的修复和改进。Rails 目前的状态比以往任何时候都更加出色。现在是参与这个框架的绝佳时机，也是首次加入我们行列的绝佳时刻。无论您是喜欢 #NOBUILD 还是 #NOPAAS，或者仅仅是被压缩复杂性的使命所吸引，您都会在这个充满激情的构建者社区中找到归属感，他们和您一样重视优美的代码和生产力。