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!
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).
Related
I have been playing around and evaluating other options to rails' default WEBrick server and Thin was the most painless and clean thing which worked very well!!
which one of these Mongrel, Thin, WEBrick and Passenger would you recommend and why..?
are there any scalability perks(cluster friendly or configs which can handle some sort of scale) which come with any of these servers.. or should scalability even be a parameter while evaluating them?
Dipak already answered half of your question but let me clarify on things a little bit. (I am one of the Phusion Passenger authors.)
WEBrick is a toy web server. Nobody uses it in anything but development because it performs poorly and is said to leak memory.
You said Thin worked well. Have you already set it up in a reverse proxy configuration? Because that's what people do in production scenarios. It is not safe to expose Thin (or Mongrel, or Unicorn) directly to the Internet.
You may be interested in reading Ruby on Rails server options and the Phusion Passenger architectural overview for more etailed explanations.
When it comes to scalability, there's not much difference. They all perform very similar in production, they all scale in about the same way, and any problems you encounter will most likely to be caused by your app or by Rails. Well, except for WEBrick, which you really shouldn't use in production. You may see difference in hello world benchmarks, but that will be all. In production use most of the time will be spent in the app so any minor speed differences visible in hello world benchmarks will become completely invisible.
There are some subtleties to be aware of though.
Phusion Passenger provides a feature called global queuing. It solves a specific problem, explained in detail in the manual. By default Nginx and Apache proxies requests in a round-robin manner so they suffer from this problem, while Phusion Passenger does not. There are ways to get around this when not using Phusion Passenger but they require specific configuration or the installation of additional web server modules.
The I/O model may or may not be important depending on the nature of your application. Mongrel, Thin, Unicorn, they are all multi-process single-threaded. This works great for traditional web apps which looks up stuff in the local database and renders something, but sucks majorly for apps which perform a lot of HTTP API calls or otherwise have to wait a lot on I/O. Why Rails 4 Live Streaming is a Big Deal explains this in detail.
Phusion Passenger is also multi-process single-threaded, but Phusion Passenger Enterprise supports multithreading. Phusion Passenger Enterprise is a commercial variant of the open source Phusion Passenger, with a variety of features useful for large-scale production environments.
In large production environments, some features become important, e.g. rolling restarts, not showing anything wrong when a deployment failed, etc. Mongrel, Thin, Unicorn, Phusion Passenger, they all expose these features to some degree, but some require more admin effort than others. For example to implement rolling restarts in Mongrel and Thin, you need quite a lot of steps in your deployment scripts. Unicorn doesn't require as many steps, but still significantly. This is where Phusion Passenger Enterprise shines: it takes all these features and turn them into a single config option. Turn the option on and the software takes care of the rest.
So, pick whatever option you think is best for your scenario.
The easiest to set up for production will probably be Apache and mod_rails (passenger). If you want to be using the new hotness, you could give nginx and passenger a whirl.
For development mongrel is usually the easiest to work with. Most Windows IDE's (RadRails, Netbeans) give you the choice to use Webrick or Mongrel for development work and let you control the servers from the IDE itself.
Update
Four Choices
There are really four choices, well, plus WEBrick, but that would be an unusual choice for a production server. Approximately in order of increasing complexity...
nginx + Mongrel
nginx + Passenger
Apache + Mongrel
Apache + Passenger
(There is Phusion Passenger Standalone, but that's really an nginx + passenger compiled together, so I'm not counting it, although it may be a good option for some people.)
A larger site may then add specialized layer 7 hardware (NetScaler, F5, ...) in front of the servers.
Thin is as easy as gem 'thin' for development and production
What is the best deployment environment for a RoR app? Someone has suggested Unicorn but am not sure. Any suggestions?
Update:
well, i have a small app with just 3-4 pages and will be accessed by not more than 25-50 concurrent users. "best" here means, ease of deployment of the app and ease of maintenance of the environment itself. Obviously stability of the solution matters as well
You should try passenger standalone, it uses nginx under the hoods and is lightning fast with little configuration. Especially when you use many apps on one server, with different gemsets and ruby versions.
Even using nginx under the hoods, you can still choose apache or nginx to maintain your webservers domains using sockets.
read this article:
http://blog.phusion.nl/2010/09/21/phusion-passenger-running-multiple-ruby-versions/
In terms of ease of deployment and maintenance.
Then its hard to beat Phusion Passenger.
It appears as an apache or nginx mod.
I always go for the apache mod
as I prefer to have apache installed from apt,
and I find it easier to do version upgrade.
It can be installed as simply as;
gem install passenger
passenger-install-apache2-module
And from then on the install process will tell you exactly what to do.
I'm a newly converted LAMP stack developer and wondering how to deploy a rails version of our large scale app.
Our servers currently have:
CentOS
Apache 2.x
MySQL
I've read about products that aid in setting up with this stack (Passenger, etc) but I'm concerned with speed and server load (as our app is already a high trafficked one).
How are people deploying rails applications for production use on a similar setup?
How could I setup rails to use this existing stack without adding anything else (or only adding production scale components to it)? -- Sort of a LAMR of sorts (Linux Apache MySQL Rails)
NOTE: The setup will still serve existing projects that are built with PHP -- so the setup can't really break any existing stack functionality
Passenger is a good option and is already used by lots of high-traffic sites in production.
ad. 1. As you already said, Passenger + REE is popular choice.
ad. 2. You could try to run it with lightweight app server like thin or unicorn. http://articles.slicehost.com/2009/4/17/centos-apache-rails-and-thin
Is it possible to not use Passenger and deploy with just Apache and MySQL?
I don't believe you can run rails with only apache and mysql in such a way. Much like the way mod_php takes care of processing the PHP for Apache, a module like passenger (www.modrails.com) takes care of processing the Rails application for you.
You can use the PassengerEnabled off (more info) setting in the vhost to disable passenger for the PHP apps. (although your php app will work fine as long as it is not placed in your rails app without this setting.)
About production scale settings. I believe that Twitter used to use apache as a load balancer to a number of mongrel http-servers. (see this article for some extra information). As you can see, caching (e.g. memcached) can provide a huge boost to your app if implemented well.
Are there any easy-to-configure webserver with ruby for Windows ?
I am hoping to find a webserver that can easily be configured to work with Ruby on Rails or Sinatra.
Anyone know of any ?
I use Sinatra+Thin on Windows, sometimes behind either Apache or Nginx as a reverse proxy (to speed up serving static files and to create a pool of 2-4 server instances). The speed is not as good as it is on Ubuntu with similar (or lesser) hardware, but at work I have to use certain servers allocated to me.
To use Thin with Sinatra, simply install Thin, and Sinatra will use it. If you need further help configuring Apache or Nginx, post more questions (after searching the web, of course).
If you want easy, stay with WEBrick.
If you want a production server, go with Apache + Passenger. But that won't be as simple as just using WEBrick.
Probably it is not answer you want but: http://rubyinstaller.org/. Installation is easy - follow instructions to install rails.
Second step is enable/configure port/application in firewall. Because ruby server works on port 3000 but http is common on port 80.
BUT this RoR environment is for development, so don't expect high performance.
I have a simple Ruby on Rails application that works through a localhost test (both using sqlite, or ruby mysql2 gem).
I have a web server ready to upload my app online.
I understand that I need to create a new mysql database, which is no problem, and obviously add the connect info in the database.yml, but how do I propertly upload the whole thing (app root) to a public dir of my site?
Rails itself contains a few links to get you started with deployment. I was in your boat a while ago, and I got started with Passenger and Apache within half an hour (although I did have some light Apache experience going in).
Get started just to prove to yourself you can do it
Not that it's a good idea, but the balls to the wall easiest way to "deploy" is the following (assuming you've already pulled your application into your deployment environment, created your database, and run rake db:migrate and any application-specific steps like bundle install on Rails 3):
rails server -p 80 on Rails 3 (./script/server -p 80 on Rails 2).
There is no step 2.
This has to be run on a machine for which you have administrative rights and for which port 80 is not already being listened to by another application. This is suboptimal in many ways, most apparent of which is that it won't allow for virtual hosting (i.e., it won't cooperate with other "websites" being run from that server), but it's a good baby step to dip your feet into.
Go to the machine's FQDN or in fact any hostname that resolves to the machine's IP address (via a hosts file or an A record), and you'll see your application.
Now do it properly
You're going to want to do the following to bring your application "up to speed":
Deploy it behind a virtual host behind a webserver application like Apache
Use a production-oriented deployment setup (WEBrick's single-threadedness, among other factors, make it unsuitable for production)
Actually use the "production" rails environment
I'll be recommending a very, very typical Apache/Passenger deployment environment. The reason is that (at least it seems to me) this particular stack is the most thoroughly supported across the Internet, so if you need to get help, you'll have the easiest time with this.
1. Set up Apache
I don't want to sound like a tool, but setting up Apache (if it's not already set up on your deployment environment) is left as an exercise for the reader. It also varies enough across platforms that I couldn't possible write a catchall guide. Coarsely, use your distribution's package manager (for Ubuntu, this is apt-get) to get it hooked up.
2. Set up Passenger
Passenger installation is even easier. You just run one command, and their guide runs you through all the steps. At this point, in your Rails application root, you'll be able to run passenger start instead of rails s to have Passenger fill the role that WEBrick once did.
3. Hook up Passenger with Apache
The Passenger guide fairly thoroughly documents, step by step, how to set it all up. The ServerName attribute in Apache's VirtualHost entry should be set to your hostname. Passenger will "find" the Rails application from the public directory you give Apache, and when you restart Apache, the first time the server gets a request for a page, Passenger will hook up your Rails application and start serving up files.
I'm not performing these steps as I'm writing this guide, so I'm not sure to what extent this is done automatically, but make sure that the site is enabled via a2ensite (in the case that you're putting this VirtualHost node in the sites-available directory) and that Passenger is enabled via a2enmod.
Make sure your production environment is ready
This is likely to be the first time you're using the production environment. Most rake tasks don't automatically act on the production environment, but you can conveniently force them to by including RAILS_ENV=production inline with any rake tasks. The one you'll very likely be running is rake db:migrate RAILS_ENV=production. The bundler in Rails 3 works independently of environment.
5. Go
Restart Apache. The specifics on how to do this will vary by distribution, so you'll have to look it up. For Ubuntu, apache2ctl restart does it for me.
Visit your hostname as you defined in ServerName, and you should be seeing your application up and running.
I've heard gems like capistrano can assist with this.
https://github.com/capistrano/capistrano
Heroku is an excellent (free) option: http://docs.heroku.com/quickstart
Also, deploying to Heroku is as easy as it gets!