`rails server puma` vs. `puma`

Question

一些指南 (example) 推荐这个来启动自己的网络服务器

bundle exec rails server puma

但我一直都是直接用puma 启动服务器

bundle exec puma

通过rails server 启动 puma（或任何其他服务器）时是否发生了一些特别的事情？

Answer 1

当您使用rails s <server> 时，服务器会从 Rails 命令启动，并且知道 Rails 环境。

这使得例如使用rails server command 提供的任何功能和标志成为可能。

rails s --help
Usage: rails server [mongrel, thin, etc] [options]
    -p, --port=port                  Runs Rails on the specified port.
                                     Default: 3000
    -b, --binding=ip                 Binds Rails to the specified ip.
                                     Default: 0.0.0.0
    -c, --config=file                Use custom rackup configuration file
    -d, --daemon                     Make server run as a Daemon.
    -u, --debugger                   Enable ruby-debugging for the server.
    -e, --environment=name           Specifies the environment to run this server under (test/development/production).
                                     Default: development
    -P, --pid=pid                    Specifies the PID file.
                                     Default: tmp/pids/server.pid

    -h, --help                       Show this help message.

例如，您可以将调试器附加到传递--debugger 的会话或守护服务器。

第二个优势是您可以对Puma 实例进行版本控制，因为您必须在Gemfile 中列出gem。如果您像现在这样以bundle exec 开头，这已经是正确的了。

相反，当您只是运行$ puma（或$ bundle exec puma）时，您并没有通过Rails 系统。 Puma 将尝试找到一个机架引导文件并使用它（它之所以有效，是因为 Rails 在应用程序根目录中提供了一个 config.ru 脚本。

一般来说，如果您不需要将特定选项传递给服务器，则没有真正的区别。我喜欢 puma，我倾向于在一些项目中使用它，即使在生产中我们使用 Unicorn，因此将 $ puma 作为独立命令运行很方便，因为我不需要将它添加到 Gemfile。

但是，如果我的整个堆栈都使用Puma，我可能会选择$ rails s puma。这也是command suggested in the documentation。