`轨道服务器美洲狮`对`美洲狮` [英] `rails server puma` vs. `puma`

问题描述

一些指南（示例）推荐这个来启动一个web服务器

  bundle exec rails server puma 
  

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

  bundle exec puma 
  

通过 rails server 来启动puma（或任何其他服务器）时会发生什么特别的事情？

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

例如，这可以使用 rails server命令提供的任何特性和标志。

  rails s --help 
用法：rails server [mongrel，thin，etc] [options] 
 -p ，--port = port在指定的端口上运行Rails。 
默认值：3000 
 -b，--binding = ip将Rails绑定到指定的ip。 
默认值：0.0.0.0 
 -c，--config = file使用定制机架配置文件
 -d，--daemon使服务器作为守护进程运行。 
 -u，--debugger为服务器启用ruby调试。 
 -e，--environment = name指定在（test / development / production）下运行此服务器的环境。 
默认值：development 
 -P，--pid = pid指定PID文件。 
默认值：tmp / pids / server.pid 
 
 -h，--help显示此帮助信息。 
  

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

第二个优点是可以将 Puma 实例，因为您必须在 Gemfile 中列出gem。如果你用 bundle exec 来启动它，就像你正在做的那样，这已经是真的。相反，当你简单地运行 $ puma （或者 $ bundle exec puma ）你没有通过Rails系统。 Puma 会尝试找到一个机架引导程序文件并使用它（因为Rails提供了一个 config.ru 脚本在应用程序根目录下。

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

然而，我可能会使用 $ rails s puma 如果我的整个堆栈使用 Puma ，这也是命令在文档中建议。

Some guides (example) recommend this to start one's webserver

bundle exec rails server puma

But I've always just started the server with puma directly

bundle exec puma

Does something special happening when firing up puma (or any other server) via rails server?

解决方案

When you use rails s <server>, the server is launched from the Rails command and is aware of the Rails environment.

This makes possible, for example, to use any of the features and flags offered by the 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.

For instance, you can attach a debugger to the session passing --debugger or daemonize the server.

The second advantage is that you can version the Puma instance, since you will have to list the gem in the Gemfile. This is already true if you start it with bundle exec like you are doing.

Conversely, when you simply run $ puma (or $ bundle exec puma) you're not passing through the Rails system. Puma will try to find a rack bootstrap file and will use it (it works because Rails provides a config.ru script in the application root.

Generally speaking, there is no real difference if you don't need to pass specific options to the server. I like puma and I tend to use it in some projects even when on production we use Unicorn, thus running $ puma as a standalone command is handy because I don't need to add it to the Gemfile.

However, I would probably go with $ rails s puma if my entire stack uses Puma. This is also the command suggested in the documentation.

这篇关于`轨道服务器美洲狮`对`美洲狮`的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！