Production Setup

This page covers the topics needed to set up a production-grade installation of etch. If you're just getting started see our getting started page.

Application Code

• Store your copy of etch in a revision control system (Subversion, CVS, git, etc.) At a minimum you'll have to modify a few config files in the stock distribution. You'll want to keep track of those modifications. And if you have a central revision control system you've probably already got backups configured for it, so you don't have to worry about backing up your copy of etch separately.

Configuration Data

• Store your configuration data in an revision control system as well
• Set up controlled deployment
• Develop a peer review process for changes in your configuration data. A second set of eyes looking over changes is always a good idea. We recommend that you set up an internal mailing list for etch users and require that admins email a diff of any proposed change to the mailing list for review before committing it to your revision control system.

Environments

• Set up a staging environment. Always launch to staging before launching to production. This allows you to catch database migration errors and other deployment issues before production, and gives you a last chance to do some smoke testing and user acceptance testing. This can be done with a virtual machine so that it doesn't use up a whole box.
• If you have more than one colo/datacenter/server room build a BCP environment in one of the secondary locations, configure database replication to this environment. This allows you to continue to provide etch service in the event that you lose the primary datacenter.

Web/App Server

The way Rails apps are usually run in production is with a standard HTTP server (Apache or nginx) listening on the user-visible ports (80 and 443, or whatever), proxying to a Ruby web server (we recommend unicorn) running on some set of high ports. If you followed our getting started instructions you already have unicorn, so you just have to configure it to run in production mode (--env production), and configure your choice of standard HTTP server to proxy to it.

• Have at least two web/app servers and load balance them, either with a hardware load balancer or one of the software load balancers (haproxy) and some clustering software.
• Configure your web server to force all traffic over SSL. I.e. either just have the server listen on SSL only, or if you want it for convenience have it listen on a non-SSL port too but redirect any connections on that port to the SSL port.

Database Server

• Set up a user with a password in your database server specifically for etch. Grant it permissions on the etch database only. In config/database.yml configure etch to use this account. Use different passwords in your different environments.
• Configure some form of database replication so that your database server is not a single point of failure. The options here vary greatly depending on your choice of database server, but you should at least have a warm standby to which you can manually switch your application servers.
• Configure database backups. With etch it would not be terribly catastrophic to lose the data in the database, clients would repopulate it as they checked in, but backups are still probably a good idea.
• Configure application and database servers so that SQL traffic goes over SSL. Some database servers support this natively, but we recommend using stunnel.

Security

• Etch communications often involve sensitive data (private keys, etc.) and thus should always be encrypted. As mentioned above in the web server section you should configure your web server in such a way that communication from clients must be done over SSL/HTTPS.
• Consider enabling client authentication
• Protect the revision control repository containing your configuration data from unauthorized access or modifications.