There are a couple of things that should be taken care of prior to going live with your Ruby on Rails web application. This section summarizes the most relevant points.
There are a couple of things that should be taken care of prior to going live with your Ruby on Rails web application. This section summarizes the most relevant points.
Do not wait with the first deployment until your go-live is due. Instead, practice deployments to the live servers as soon as some functionality and maybe also content exists. This helps you to get used to the deployment workflow. Deploying regularly lets you find out whether everything works as expected, how long requests take, and how problems can be tracked down and solved. Also, check whether sending e-mails works as desired.
Integrate tools that let you monitor what happens inside your application. You should be the first to recognize exceptions, not the visitors of your website. Fix the error that causes an exception in time to uncover all the other bugs hiding somewhere. Infopark recommends using third-party tools such as Airbrake, Errbit, Honeybadger, Sentry, Raygun or related ones to have exception notifications sent to you along with stack traces and the request parameters used.
Next, assess how well the website performs. Does it cope with traffic peaks? How many requests per minute are served by which controller? Where are the bottlenecks? Infopark recommends NewRelic, a service that provides you with charts and analysis tools. The pages that are requested most often and take most time to render should be optimized first.
Today, SSL-secured pages are an absolute requirement, particularly when dealing with personal data. Getting ready for SSL involves acquiring a certificate for your domain and installing it on the load balancer. All SSL requests are handled by the load balancer, which decrypts them and passes them unencrypted to your web application. The load balancer then encrypts the responses sent by your application and delivers them to the client.
Even though the SSL certificate is not valid for domains other than the one for which it was issued, Infopark recommends to install the certificate prior to going live. The certificate only takes effect after your domain name has been associated with your new website. However, the task of installing it has been completed. One less worry.
Also, activating SSL early encourages you to develop your application with HTTPS already in mind. Redirect to HTTPS if appropriate, for instance when delivering forms to the visitors. The browser will complain about the certificate not matching the host name. However, after going live, it finally works.
If everything is up and running, go surfing. Click through the deployed website, and invite your colleagues to do the same. Is your site responsive enough, are all the compiled assets available? Look into every corner, watch out for lorem ipsum remains and bugs with magic hats. You might temporarily register another domain, or add a subdomain, and let the DNS point it to the load balancer. Are redirects still intact, does HTTPS still work? What about the third-party services you are using on your website, or user-generated content?
Next to functional tests like these, you might want to load-test your site. Imagine thousands of people waiting for your pages to be finally displayed. Do not disappoint them. Use a tool like loadimpact.com to force up the number of requests to the unexpected maximum. The traffic simulation results might suggest using more or faster servers, or tweaking the performance of your code.
Also, take care of your cache to keep your site up even if Scrivito is not reachable.
Have we mentioned that going live is only a matter of changing the DNS record of the domain if the above-said has been taken seriously?
Providing DNS entries for delivering a website via a load balancer
For high availabilty, a live system hosted in Amazon's Elastic Compute Cloud (EC2) should consist of several identical live servers delivering the same content. They are located behind a load balancer that acts as the entry point for HTTP requests, distributing them equally to the live servers. If a live server fails, the load balancer is notified in order to stop forwarding requests to the failed server. A new EC2 instance is automatically created as a replacement for the one that stopped working.
Mostly, not one but several domains or subdomains are hosted in the Cloud (e.g. customer.com and www.customer.com). All HTTP requests directed to the customer’s domains and subdomains are intended to be handled by the load balancer.
According to the rules of the DENIC, a German 2nd-level domain needs to be bound to an IP address (this is done using an A record). However, load balancers, as well as EC2 instances, do not have fixed IP addresses. Therefore, it is required to point the domain name to a CNAME record. Note that a domain name can be assigned to one CNAME record only.
Infopark recommends to use Amazon Route 53. Alternatively, your domain registrar might also offer such a service. You may also consider using a free service like wwwizer.com. These services act as a bridge between your DNS provider’s A record for your domain and the potentially changing IP address of Amazon’s load balancer.
Additional subdomains such as www can usually be bound to the load balancer by means of a CNAME record.