Don’t Treat Them Like Regular Virtual Machines

I’ve seen OpsWorks used as a round about way to provision EC2 instances. This is not the purpose of OpsWorks. OpsWorks provides an orchestration mechanism that triggers configuration management events at key events in the life of a virtual machine allowing us to respond to change in our environments faster.

If all you want to do is provision an EC2 instance, RDP into the box and configure it manually, you don’t need OpsWorks. You should head on over to the EC2 dashboard and have at it!

However, if you want to automate the setup / tear down of your machines so that in the case of disaster, high load, scheduled outages, you’ll be able to spin up new instances that will configure themselves and start handling load, then OpsWorks is for you.

Don’t Only Manually Run Chef Recipes to Configure Your Environment

OpsWorks has what are called Lifecycle events. Use them.

  • Setup: when the instance starts
  • Configure: after any instance starts or network changes are made
  • Deploy: when you run the deploy command
  • Undeploy: when you delete an app or run the undeploy command
  • Shutdown: when the instance stops

If you always run your scripts using the manual script runner then you will be building in a ‘run once’ bias into your code. You might find yourself getting attached to instances and not wanting to delete them. The whole point of configuration management tools like Chef is to make every environment, every instance completely and utterly replaceable. There should be no worry or concern about deleting an instance because everything that made that instance the way it was is captured in two places:

  1. The AMI you started from
  2. The Setup and Configure recipes that get invoked when a new instance is launched for the first time.

Don’t Be Afraid to Delete Your Instances

As I mentioned previously, if you notice an unnatural attachment or resistance to shutting down or, god forbid, deleting an instance chances are you have some technical debt. Because the instances that compose your application’s tiers should be setting themselves up and re-configuring themselves upon every change there shouldn’t be any reason to delete an instance.

You need to explore edge cases where there might be hidden pitfalls. Ask yourself these questions:

  • What happens when I add the first instance to a layer?
  • What happens if I add a single new instance to a layer?
    • How will the existing instances respond to this new addition?
    • How will the new instance start taking on load?
  • What happens if I delete a single instance to a layer?
  • What happens if I delete all instances from a layer?
  • What happens if I stop a single instance in a layer?
  • What happens if I stop all instances in a layer?

Make sure your scripts take into consideration the various states that the layer can be in as instances go through planned outages, fail or scale by schedule or load.