Continuing on from where we left off, now that we have our Rails application deployed to a production server using Cloud 66, there are a few more things we need to do to make it production-ready. These steps include enabling database backups, setting up our application to scale beyond a single server, and ensuring we have a secure, monitored application.

Automate Your Database Backups

Enabling automated backups of your Cloud 66 managed database will ensure you have regular snapshots of your data. Unlike some backup solutions, Cloud 66 will verify the backups worked properly to provide peace-of-mind that you'll be able to restore from a previously successful backup. Too often, we ignore this step as part of backup automation only to find our backup scripts have been failing for some time.

Scale Up With Multiple Servers

While the previous article focused on deploying our application to a single server, we'll most likely need to scale to multiple servers immediately, or once our application gains more traction. To make this happen using Cloud 66, we first have to install a load balancer:

Depending on the cloud vendor you selected, the method used by Cloud 66 to install a load balancer will vary. For my example, I used AWS as my cloud vendor, resulting in Cloud 66 using the Elastic LoadBalancer (ELB) service from AWS. The load balancer service help page outlines the load balancer strategy for each cloud vendor.

Once we have a load balancer installed, we can add more servers as needed to support our incoming traffic.

Configure Notification Settings

Cloud 66 can notify you when different events occur. Each event can be configured to notify you in different ways. Be sure to customize your notification settings to ensure the right people are notified as soon as possible:

Adding Custom Firewall Rules

One of the big advantages of using Cloud 66 is that each Rails and database server is configured with a firewall that restricts access to your servers. This removes the need to do this yourself, risking a bad configuration that leaves your server open or perhaps locking you out due to a bad setting (I speak from experience).

Should you need to open an additional port to allow specific servers access, you can use the 'custom firewall rules' feature to add new rules and deploy them to your servers without manually editing or maintaining them. Each new server will be assigned the same rules, preventing you from missing this important step as you add new servers to handle more incoming traffic.

Viewing Recent Deployments

If you add redeployment hook support, or if you have multiple team members who are allowed to deploy, it's important to have a history of what versions of your code have been deployed (and by whom). Use the deployments view to look at when recent deployments have occurred and the git hash used for the release:

Using LiveLogs for troubleshooting

Finally, managing logs across servers often requires installing tools such as the ELK stack. While this may be a toolset you decide to install for running log analytics, Cloud 66 does provide LiveLogs for helping you troubleshoot deployments and runaway servers.

Putting it All together

Over the course of my last three articles, we've looked at why Rails deployments are hard, how to deploy a Rails app using Cloud 66 to your cloud vendor of choice, and how to make your Rails app production-ready. Along the way, we avoided many time-consuming tasks, including server provisioning, configuration, patching, asset pipeline management, and common monitoring and logging setup tasks.