Four Top ServerTemplate Best Practices

You’ve reached an archived Flexera blog post that may be out of date. Please visit the blog homepage for the most current posts.

RightScale engineers Tim Miller and Cary Penniman took the podium at the RightScale Compute conference recently to talk about best practices that organizations can employ as they work with RightScale ServerTemplates™ to build consistent, production-quality cloud configurations. 

ServerTemplates are RightScale-specific, reusable components that define the characteristics of a cloud server. They use MultiCloud Images™ to define the operating system and supporting applications for the server and a collection of RightScripts™ or Chef recipes that install select applications and define configuration settings and other attributes.

Miller and Penniman covered four best practices that help RightScale users to:

  • Streamline configuration development using rsync
  • Ensure consistency of production configurations
  • Customize configurations with minimal maintenance
  • Automate data backups and availability

Streamline Configuration Development

The first tip involved creating an efficient development workflow. You can develop ServerTemplates using a variety of configuration tools. In their demo, the presenters chose to optimize a Chef configuration. The typical workflow involves pushing any changes you make to your repository, refreshing them in RightScale, then running and testing on the server. That process can take a couple of minutes per change, which can add up.

To speed things up, you can use a tag called download_cookbooks_once along with rsync at the command line, make your changes locally, and check that everything runs before you make a code commit and push your changes through the typical workflow. You can read about this process in detail at Chef Developer Workflows and watch the process demonstrated in the video of the talk.

RightScale Compute session: ServerTemplate Best Practices

Ensure Consistency of Production Configurations

When you’re going into production, don’t run your servers on HEAD, which is a living, editable version, as opposed to an un-editable committed revision. But just committing is not enough, Penniman said. To ensure that the servers run the same way they did when you tested them, ensure that your servers install from one of the daily snapshots of the Linux package repositories.

If you have any Chef recipes in your ServerTemplates, you also need to freeze your cookbook repositories — lock them down to a specific commit SHA. You can freeze both package and cookbook repositories under the Repos tab of a ServerTemplate. You have to also be aware of external dependencies that are installed by your custom scripts or recipes. These are typically packages and tarballs hosted on third-party websites and not in the RightScale package mirrors. A best practice is to download any dependencies you need for your template and store them in an object store like S3 or CloudFiles. If you don’t, you just have to hope that the third-party websites are up and running when your servers need to boot.

Sometimes during the development process you can be making feature changes to a ServerTemplate incrementally when you need to switch gears and quickly deploy a change to that ServerTemplate, perhaps to fix a bug. The way to keep from posting untested changes to production is to have two ServerTemplates — one for staging, one for production. The production ServerTemplate stays lock-step with what’s deployed, so you can make that quick change when necessary. Do all your testing in staging, and only when you’re sure it’s ready to go do you merge it into the production template and deploy it.

But in fact that’s not enough when you have multiple developers making changes at the same time. In that situation, you can clone the staging template so that each developer can work on a particular feature and then merge them back into the staging ServerTemplate once everything is working.

Customize Configurations with Minimal Maintenance

RightScale provides a MultiCloud Marketplace™ of tried, tested, and supported ServerTemplates. If you need to customize one, isolate your changes – put your new scripts at the top or bottom of the boot scripts, so that when RightScale releases new versions of ServerTemplates you use, you can easily reapply your changes. If you want to build your own ServerTemplates, start with one of our Base ServerTemplates, which come with monitoring, logging, and security already baked in.

Automate Data Backups and Availability

Finally, some advice on data storage:

  • Keep data in multiple locations.
  • Use volumes to maintain backups of local data.
  • Save volumes in remote object stores.

You can do this through the RightScale Storage Toolbox, a ServerTemplate that encapsulates all of the best practices we’ve learned about storage, including scripts for backup to volumes and snapshots as well as remote object storage, which lets you quickly restore a server to a new cloud in the event of an outage.

“I would just import the Storage Toolbox ServerTemplate into my account, clone it, and start building my server right on top of it,” Miller said, so you can concentrate on building your app, not the underlying infrastructure.

Request a demo and we’ll show you how enterprises are using RightScale ServerTemplates for dynamic provisioning to support high-availability deployments.