Archive

Posts Tagged ‘rails3’

dynamic robots.txt file in Rails 3.x

April 27th, 2012 No comments

We have a need for dynamic handling of robots.txt file as we have different requirements for production, staging, dev, test, etc.

Google-fu shows various way to do this, some for Rails 2.x, some for Rails 3.x. Here is my version.

First is to edit config/routes.rb and add this line:


match '/robots.txt' => RobotsGenerator

Then add the following to app_root/lib/classes/robots_generator.rb.

NOTE: We have an old domain, foo.com, that redirects to our newfoo.com. We don’t want foo.com to get indexed, so I have special treatment for that in production

class RobotsGenerator
  # Use the config/robots.txt in production.
  # Disallow everything for all other environments.
  def self.call(env)
    req = ActionDispatch::Request.new(env)
    headers = {}
    body = if Rails.env.production?
      if req.host.downcase =~ /foo.com$/
        headers = { 'X-Robots-Tag' => "noindex,nofollow" }
        "User-agent: *\nDisallow: /"
      else
        File.read Rails.root.join('config', 'robots.txt')
      end
    else
        "User-agent: *\nDisallow: /"
    end

    [200, headers, [body]]
  rescue Errno::ENOENT
    [404, {}, "User-agent: *\nDisallow: /"]
  end
end

Finally, you want to move public/robots.txt to config/robots.txt.

I want to give credits to the people that inspired my version.

Categories: Rails, Ruby, Tech Tags: , ,

Migrating from Bamboo to Cedar (calendon stack) on Heroku

November 17th, 2011 1 comment

We just migrated from Bamboo (bamboo-ree-1.8.7) to Cedar (calendon rails 3.1 stack) on Heroku. Here are the steps I took to make it work. Note that I didn’t do the code migration, my dev handle that, I do the server and infrastructure part.

Basically this mean moving from Rails 2.x (and ruby 1.8.7) to Rails 3.1 (ruby 1.9.2). Some of the changes require upgrading gem packages. Things such as images, css and js has to be put into an asset bundle.

On the site itself, I left the old site running, e.g. oldsite.heroku.com, and created a new site at newsite.herokuapp.com.

We created a new git dev branch and pushed to newsite, e.g.

git push heroku dev:master

Since we use SSL, I have to make sure custom_domains addon is there. But…

heroku addons:add custom_domains:basic custom_domains:wildcard

I can’t add the ssl addon until I am ready, because Heroku requires that I defined the domains for the app first! Chicken and egg, as it mean I have to take down the currently running production site.

So, make sure everything is running on new site first. Because the next steps mean production site will be down during the changes.

0. Make sure your SSL cert is up-to-date and you have both part, domain.cert and private.key. And most importantly, your key is passphrase-less!

1. Make sure your DNS records are updated and have shortest possible TTL. You are changing them.

2. Wait till DNS changes (TTL) have settle, could be a few hours. Then update your production site CNAME from *.yourdomain.com to newsite.herokuapp.com.

3. Clear out the domains in your old Heroku site:

heroku domains:clear --app oldsite

4. Add domains to new site:

heroku domains:add '*.yourdomain.com' --app newsite
heroku domains:add 'www.yourdomain.com' --app newsite

5. Upload SSL cert to your new app:

heroku ssl:add yourdomain.crt private.key

6. Now you can add the ssl addon.

heroku addons:add ssl:hostname

7. You should get an email from Heroku that has the hostname for your SSL DNS record to point your DNS to. The name should be something like this:

appid1234567herokucom-1234567890.us-east-1.elb.amazonaws.com

Update your DNS CNAME for www.yourdomain.com to point to this name.

8. Test, test, and test again your spanking new site. Add the New Relic addon if you haven’t (life saver!) and monitor traffic to your new site.

9. Monitor the log of your new site:

heroku logs -t --app newsite

10. Check the processes:

heroku ps --app newsite

11. Wait a week, if everything look good, you can take down the oldsite.