I'm an experienced LAMP developer moving into Rails. I have a very stupid question to ask: what the hell does Phusion Passenger do?
I've read a lot of documentation, I've Googled, I've read Wikipedia, I've read Stack Overflow. I've even installed it and gotten it running on a development machine (with Apache). I still don't know what it's actually doing though.
Here's one guess: I think it's weird that the Apache document root points to /mywebapp/public/
instead of /mywebapp/
, so I assume it has to do with making everything inside of /mywebapp/
accessible. (That's a wild guess though, based on the fact that I don't know how else that stuff is getting accessed.)
I've gathered that Passenger is revolutionary, groundbreaking, etc, etc, but what does it do!?
Sorry for the n00b question, everyone. Thanks!
Phusion Passenger® is an open source web application server. It handles HTTP requests, manages processes and resources, and enables administration, monitoring and problem diagnosis. Passenger is very easy to use, makes deploying in production much easier and is scalable.
Passenger® is an app server that runs and automanages your web apps with ease. Also improves security, reliability and scalability.
The Passenger Apache module registers Passenger-specific configuration options inside Apache. You, the administrator, configure Passenger by adding Passenger-specific configuration options to the Apache configuration file. Restart or reload Apache to apply any configuration changes.
Welcome to the Passenger Library, a comprehensive online resource about Ruby, Python and Node. js deployment, administration, scaling, high availability and more — through the use of the Phusion Passenger application server. The entire library is open source.
Passenger is a system for preparing and launching instances of Ruby for use with Rack-based applications such as Ruby on Rails. Apache and nginx, the two supported web server platforms, cannot run Ruby like they can PHP, Perl, or Python because there's no built-in Ruby module that works as well as those do. This means Ruby tends to run as an independent group of processes that the web server will have to direct traffic through.
Rails tends to run as a persistent process because the start-up time for the whole stack is significant. Passenger launches new instances as they are required, and will kill off those that are no longer required. You can see this in the process list as they are clearly identified with "Passenger" and "Rails" prefixes.
One feature of Passenger is it will re-use a portion of the Rails stack so that creating additional processes is faster, cloning one instance instead of spinning up a new one from scratch. The loader is written in C++ and handles properly configuring and kicking off each Ruby process as efficiently as possible and also helps save memory by sharing it amongst different processes.
The reason you host things out of the public/
directory is to avoid exposing your application code-base. PHP needs to be configured properly to prevent people from simply browsing directories and downloading the source because there's no specific distinction between static content and executable scripts. A mis-configured server will gladly serve up raw .php files instead of running them, for instance.
Passenger isn't exactly revolutionary, but it does incorporate a number of essential features in a very convenient package. What makes it such a great thing is that it works very well and doesn't demand a lot of attention. Out of the box it's pretty much ready to go.
It serves ruby on rails applications (actually any rack application). I was used with version 2.x of passenger to integrate it directly in apache, but with the new version, which supports standalone execution, I prefer to run it in standalone mode (in conjunction with rvm)
It can be very useful both in development mode and in production mode and it speeds up execution of RoR application.
In order to deploy a RoR application I install it with its own gemset and then I install passenger in that gemset with gem install passenger
(you can also safely skip gemsets, but they will isolate the application environment, so it's nice to have them). After that you can start the application with passenger start -a 127.0.0.1 -p 3081 -e production
in the project root.
Then I configure an apache vhost to work in reverse proxy mode with a file like this one
<VirtualHost *:80> ServerName your.server.org ProxyPass / http://localhost:3081/ ProxyPassReverse / http://localhost:3081/ ProxyRequests Off # Local reverse proxy authorization override # Most unix distribution deny proxy by default (ie /etc/apache2/mods-enabled/proxy.conf in Ubuntu) <Proxy http://localhost:3081/*> Order deny,allow Allow from all </Proxy> </VirtualHost>
and you're ok, you have your application deployed with its local config, it doesn't even need root privileges (for the passenger part).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With