Posts Tagged ‘passenger’

7th December
2010
written by simplelight

Is there any way to specify the RAILS_ENV when using Passenger? I tried setting it in my environment.rb, but it doesn’t seem to take anything other than “production” … setting the RAILS_ENV constant instead of the ENV[‘RAILS_ENV’] eventually did the trick.

For a way to set Rails_env differently depending on the capistrano stage being deployed to, see this post

1st August
2008
written by simplelight

Unfortunately, the New Relic performance monitor for Ruby on Rails doesn’t work with mod_rails (Passenger). According to a support email from them it currently “only supports mongrel and thin (without sockets)”. They plan to support Passenger in the future. That’s great news because they provide an excellent performance monitoring tool which is very easy to install and use.

Update: New Relic has added support for mod_rails. I received this email from their excellent customer support:

I was just digging through my support emails and found a few people who had inquired about RPM supporting Phusion Passenger, aka mod_rails.

 

I wanted to let you know that we released a version of the agent with ‘beta’ support for Passenger.

 

If you’re interested, check it out and let us know how it works for you!

 

To try it out, just do:

 

script/install –force http://svn.newrelic.com/rpm/agent/newrelic_rpm

 

Bill Kayser

New Relic RPM Developer

 

1st July
2008
written by simplelight

If you’re running your low-volume Ruby on Rails app on mod_rails (Passenger) and have wondered why the first page takes 5 seconds or more to load, there is an excellent explanation here.

25th June
2008
written by simplelight

I was once a respected coder. But for 5 years I’d designed ASIC’s using Verilog (where everything happens at once) and then for 5 years I’d turned to business. And it all changes in a decade. I’d let my skills lapse and in the interim C++ had morphed to Java and then suddenly CPU’s got really fast and scripting was back in vogue. 

I realized that my CS undergrad was quickly becoming worthless. Web programming was a complete mystery to me. (Whether that was really a problem is a philosophical question beyond the scope of a humble blog entry). Here is my road to recovery. In bullet point form amenable to PowerPoint and as buzzword compliant as possible.

Jan 1st, 2008: Resolve to brush up on programming skills.

Which language should I learn? Web development seems cool….what’s involved in that? Narrowed it down to a) the LAMP stack or b) Ruby on Rails. Do I want to be a) paid as a programmer or b) hip ?

I went with Hip. Rails it is.

Here are the steps (and mistakes) I took on the road to recovery:

  1. Linux – I remember that: “ls -al” and all that. It’s the sine qua non for a real programmer.
  2. F@(k. That’s a lot of variants of Linux. Go with Ubuntu because I’m semi-African.
  3. Hmm… Windows XP is standard issue at work.
  4. Get an old PC from my IT guy. Spend an entire day installing Ubuntu. Realize I’m now a web programmer so start again and install the server version. What the hell? What’s involved with web programming anyway. Will I be writing the client or the server?
  5. Call college roommate who is on “tiger team” at Yahoo. He says: “Buy Pickaxe“. Sold. In a flash of environmental sympathy I buy the PDF version. It also saves $10. Print it out on corporate printer. Double sided to save the environment.
  6. Need the Rails part: Buy “Agile Web Development with Rails“. We invested in an Agile software company so “agility” must be good.
  7. Start reading. In the interest of time and an anxiety to see the global greeting I dispense with Linux and deploy InstantRails on Windows –> Instant gratification. (Nice to see those programmer types have dropped their antipathy towards Microsoft. I’m a web programmer. Even if it’s only on localhost. (Wow: It’s only February and I could compete with Amazon if I wanted to and if I knew where to buy all the books for my bookstore)
  8. I have a bookstore up and running. No one can see it. That’s ok….how hard can deployment be.
  9. March. Deploytment is hard. People don’t recommend Windows. Could I be the only person writing Ruby code in a Rails environment on Windows XP. Seems to be from my google searches.
  10. Let’s reinstall Ubuntu Linux.
  11. Install ruby gems. Rinse. Repeat. Rinse. Repeat. Check dependencies. Rinse Repeat. Rinse. Repeat.
  12. Install MySQL. (It’s nice that I don’t need to think too much about the database. Seems like something business people should concern themselves with).
  13. Stuff is working. Slow as all hell on this ancient PC but what the hell. People will wait for the page to load.
  14. Becoming a problem that I can only work on my hobby at work. Can’t afford another PC at home.
  15. VMware to the rescue. Downloading an Ubuntu VM on my home PC is a cinch. And hip. Which is important.
  16. Realize I need a real hosting service. (Weeks of agonizing research). Settle on Dreamhost. (I love those guys!)
  17. Deploy app. Hmmm…this is a f@(k1ng nightmare!
  18. Passenger (mod_rails) is released a few days later. I realize I’m back on the cutting edge. Deployment is now piss easy.
  19. www.assetcorrelation.com (Live as of June 1st, 2008 — 5 months start to finish)
  20. Start to harass Google to show me some organic search love.

It’s been a wild ride. And not as hard as I thought. In the end, we return to the beginning. I still hate writing test benches. Hacking is still fun. And not having deadlines is the way to go. 🙂

27th May
2008
written by simplelight

Over Memorial Day weekend I migrated my Rails Application to Dreamhost using mod_rails (Passenger). It was not an entirely smooth process but I was also upgrading from Rails 1.8.x at the same time. That was compounded by making the foolish mistake of trying to rebuild my database using Rake migrations. (That’s a bad idea. I could have saved many hours by just uploading the schema)

Here is the procedure I followed (hat tip to Nock):

  1. cd ~/
  2. rails your_app_name -d mysql
  3. Copy app/, database.yml, routes.rb, db/
  4. Change public/.htaccess from .cgi to .fcgi
  5. put your app into production mode (uncomment line 5 in environment.rb)
  6. run rake db:migrate RAILS_ENV=production
  7. chmod -R 755 ~/your_app_name/app
  8. rm your_app_name/public/index.html
  9. killall -USR1 dispatch.fcgi
  10. killall -USR1 ruby

One comment on step 4. For some reason none of my stylesheets would load. Much of the advice gleaned from endless Google searches seemed to suggest that the problem would be fixed by setting the RewriteBase in /public/.htaccess. That turned out to not be the case.

My stylesheet problem was caused by having this line twice in my .htaccess file

RewriteRule ^(.*)$ dispatch.fcgi[QSA,L]

DO NOT uncomment the one before RewriteEngine On , as all the tutorials seem to imply, just change the .cgi to .fcgi in the block below it.

Thanks to Dreamhost for their stellar support over a frustrating (for me!) Memorial Day weekend. In the end, (as is so often the case), very little of the frustration was caused by Dreamhost or mod_rails but, rather, by some of the vagaries of Rails. I’m guessing that future deployments would be much smoother as this was my first time deploying to a shared hosting environment.

26th May
2008
written by simplelight

I use Dreamhost to host my websites and they have now added support for Passenger (a.k.a mod_rails). Ruby on Rails deployment hassles should be a distant memory soon!

If you’re looking for a cheap and cheerful hosting company for your Rails app, I highly recommend Dreamhost. It’s great for the solo developer (or small team) because for a small amount per year you can launch your site on a shared hosting service and then later easily migrate it to a virtual private server as your needs change. 

Dream in Rails