Below is the checklist of these practices:

1. Ensure that NS records and MX records are changed if they need to be changed

Changing nameservers will point the domain to the hosting server,  and changing MX records will redirect incoming mails to the mail server. As a very first step, we should make sure that name servers of the domain are set to be the correct one.  Changing MX record is a must if our application is parsing incoming mails or we wants to use other mail services for e-mail exchange, for example Gmail.

2. Ensure some backup mechanism in place for both data as well as user uploaded content like images/documents etc.

Since production data is very critical, we must setup backup  mechanism. It could be some type of scheduled task that takes periodic backup of all critical data, Or it could be some type of backup service provided by hosting company. When we talk about critical production data, it includes production DB, content generated by application users like images, documents, etc.

3. Ensure database indexes

We might have done development without having proper database indexes, but we should avoid going to production without them. Adding indexes might slow down insert queries a bit but it increases the  performance of read queries. It applies when application in production has percentage of read operations much more than write operations.

4. Enable your slow query log

This is specific to MySQL. Enabling slow query log allows MySQL to log slow running queries to a file. And this log can be used to find queries that take a long time to execute and are therefore candidates for optimization.

5. Ensure exception capturing is in place

We might want to be notified when something bad happens to our application. There are several hosted services available who receive and track exceptions, for example Hoptoadapp.com, GetExceptional.com etc…  Either we can choose one from these hosted services or we can use “exception notifier” plugin.

6. Ensure adding entries for cron/scheduled jobs

Most of the applications have some functionality/jobs that need to be run periodically, for example generating invoices, sending newsletters etc.  In most cases these jobs are done by a rake task. We should make sure that we have added such jobs to cron or similar program.

7.  Monitoring important processes

To ensure that our site is up 24×7 we need to ensure that all processes that our application needs are up. There can be many processes like MySQL, Mongrel, Apache etc.. These processes are very important as our application directly depends on them. For example if MySQL process get killed accidentally, our application would not be able to connect to MySQL and will start throwing exceptions.

We can choose any of the available monitoring tools like God, Monit, 24×7 etc…

8. Ensure confidential data filtering

We would never like to leak/share confidential information of our application users. We should make sure that none of the user’s confidential data like SSN, Credit card info, password are being written to log files. We might not have paid much attention on this while developing the application.

9. Rotate log files

Once our site is up and running, every single request write some text in log file. And hence size of the  log file keeps on increasing. Larger log files can put us in trouble if we get it beyond certain size. Its difficult to manage these log files, as larger files need more memory to open and need more time to download. In one of the rescue project we did , the log file size was 3GB.

We would recommend having logrotate setup for the application.

10. Setup Asset Host

Setting up asset hosts can reduce loading time by 50% or more. We must setup asset hosts for our application. Once asset hosts are all set, our static files will be delivered via asset hosts for example asset1.hostname.com, asset2.hostname.com

11. Clearing up stale sessions

We should make sure we should not left any stale session on the server. If our application is using DB or file system  as session store, we must add a schedule task to delete stale sessions.

These are some of the points we have identified from our past experience and we might be missing some. Feel free to  always add them as comments, and I’ll keep this post updated.

We also provide affordable rails deployment services.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

But, for SEO sake I had to change configuration so that wordpress can be access by http://domain.com/blog instead of http://blog.domain.com/

The problem was if I configure wordpress for http://domain.com/blog and go to this url, the request was handled by rails app because of domain.com virtualhost.

So what I did? I changed apache virtualhost configuration for http://blog.domain.com and http://domain.com as:

Also I created a symbolic link to wordpress installation directory under rails public folder(ln -s /var/www/html/wordpress /var/www/html/railsapp/blog).

I restarted apache and it worked fine. Wordpress was running at http://domain.com/blog and rails app was as http://domain.com/.

I personally didn’t like some sessions that are based on marketing. There were people from some hosting company and after every 2 mins they were saying “we are the best”. I think this should not happen in barcamp. As far as I know about barcamp, it is for sharing your experiences, Talking about new technology, but not for promoting your company.

I think that, at BarCamp there should be sessions on new things, not on the things that are popular and have similar other services.

There was a very good session by Jinesh Varia on Amazon Cloud Computing. He included Amazon’s simple storage system, and Amazon’s cloud computing(Ec2) in his presentation. He also helped me to answering people while the demo. He gave me a hint that very soon there will a news from Amazon that will surprise us.

I have uploaded my presentation slides on Slideshare.net:

| View | Upload your own

Thanks to Impetus Noida for Hosting Barcamp for second time and Opera for Beer.

Lets run rails application on https with pound. For that your machine should have:

* Pound installed with ssl support
* Pound and mongrels running

Now, First of all we need a ssl certificate, that can be generate by issuing “openssl req -x509 -newkey rsa:1024 -keyout mydomain.pem -out mydomain.pem -days 365 -nodes” . Give all the information it asks. Now copy mydomain.pem to /etc/pound/ directory(I am assuming that your pound.cfg file resides in /etc/pound/). Now put the following code in pound configuration file(/etc/pound/pound.cfg):

I am assuming that your mongrels are running at ports 8000, 8001, 8002, apache running at 8080 and pound is listening ports 443 & 80.
Restart pound, and you are done. With this configuration all requests for dynamic content at port 443(https) will get redirected to mongrels and requests for static content will get redirected to apache.

You may want to check if the request is https or not before serving the content. That can be done by adding a before_filter (defined below) in application.rb :

By adding this method as before_filter in application.rb your application will check for https, if the request is not of type https it will redirect to an https request.

You can also deploy your rails application with pound(a reverse proxy, load balancer and HTTPS front-end for Web server).

First you need to setup mongrel_clusters for your rails application by issuing ” mongrel_rails cluster::configure -e production -p 8000 -a 127.0.0.1 -N 3 -c ./ ” inside the rails application root directory(on client machine). This will create mongrel_cluster.yml in config directory. You can change parameters in this command, as -p 8000 specifies that mongrel instances will start up on port number starting 8000, -a 127.0.0.1 specifies that mongrel instances will listen to the localhost, -N specifies the number of mongrel instances and -c specifies the rails root directory.

Now you need to install pound(if not installed) by issuing following commands(as root):

• cd /opt/src
• wget http://www.apsis.ch/pound/Pound-2.3.2.tgz
• tar xzpf Pound-2.1.6.tgz
• cd Pound-2.1.6
• ./configure
• make
• make install

This will install pound in /usr/local/sbin/pound. In order to proceed further we need to create pound.cfg(pound configuration file) in /etc/pound/pound.cfg . Below is the content of pound.cfg:

</p> <p>User “pound”<br /> Group “pound”</p> <p>ListenHTTP<br /> Address 0.0.0.0<br /> Port 80<br /> Service<br /> BackEnd<br /> Address 127.0.0.1<br /> Port 8000<br /> End<br /> BackEnd<br /> Address 127.0.0.1<br /> Port 8001<br /> End<br /> BackEnd<br /> Address 127.0.0.1<br /> Port 8002<br /> End<br /> End<br /> End<br />

Start mongrel cluster by issuing mongrel_rails cluster::start in you app root directory, start pound by /usr/local/sbin/pound -f /etc/pound/pound.cfg , now you are done. Pound is listening the port 80 and redirect all requests to mongrel instances running on 8000, 8001, 8002.

* Please Note that we have configured pound at port 80, if port 80 is being used by apache or any other application pound will not start. You need to stop any service using port 80, if it is apache then stop apache, change line ‘Listen 80′ to “Listen 8080″ and start apache.

In a specific case, when apache is running at some port (let say 8080), you may want to use apache to serve static content of your application, in order to reduce some load from mongrels. In that case use the following:

</p> <p>User “pound”<br /> Group “pound”</p> <p>ListenHTTP<br /> Address 0.0.0.0<br /> Port 80<br /> Service<br /> URL “/(images|stylesheets|flash|javascripts)/”<br /> BackEnd<br /> Address 127.0.0.1<br /> Port 8080<br /> End<br /> Session<br /> Type BASIC<br /> TTL 300<br /> End<br /> End<br /> Service<br /> BackEnd<br /> Address 127.0.0.1<br /> Port 8000<br /> End<br /> BackEnd<br /> Address 127.0.0.1<br /> Port 8001<br /> End<br /> BackEnd<br /> Address 127.0.0.1<br /> Port 8002<br /> End<br /> End<br /> End<br />

This will redirect all requests for image, stylesheets, javascripts, flash to apache. Now we need to configure apache to serve those static content. Just add a virtualhost for that:

<br /> <VirtualHost *:8080><br /> ServerName example.com<br /> ServerAlias www.example.com<br /> DocumentRoot /var/www/html/example.com/public<br /> <Directory "/var/www/html/example.com/public" ><br /> Options FollowSymLinks<br /> AllowOverride None<br /> Order allow,deny<br /> Allow from all<br /> </Directory></p> <p> RewriteEngine On</p> <p> # For static files it’s good to avoid hitting your mongrel process<br /> # so let apache knows it should serve it directly<br /> # for a rails application it means, files in images / stylesheets / javascripts<br /> RewriteRule “^/(images|stylesheets|flash|javascripts)/?(.*)” “$0″ [L]</p> <p></VirtualHost><br />

Its all done. All requests for dynamic content at port 80 will be redirect to mongrel running at 8000, 8001, 8001 and requests for static content will be served by apache running at port 8080.

Related posts:

1. 11 Things to Consider Before Deploying Your Ruby on Rails Application At VinSol, we have been developing and deploying Rails applications...

Related posts brought to you by Yet Another Related Posts Plugin.