Skip to content

Instantly share code, notes, and snippets.

@toolmantim
Last active August 2, 2017 12:35
Show Gist options
  • Save toolmantim/5259853 to your computer and use it in GitHub Desktop.
Save toolmantim/5259853 to your computer and use it in GitHub Desktop.
After messing with OpsWorks for a few days I thought I'd document my own introduction to it's most important bits.

OpsWorks

AWS OpsWorks, formerly Scalarium, is a chef-based system that deeply integrates with EC2 (security policies, key pairs, etc). OpsWorks acts as web console to configure your entire system, and as a command hub for running chef-solo on all the instances.

Stacks

A stack represents a collection of inter-connected and inter-configured services.

A stack has lifecycle events which are triggered by any change to the stack configuration (such as, adding a new instance to a layer, or changing the hosts of an application). In this way, the stack acts as an event hub, notifying every instance of any changes.

When an instance is notified of a lifecycle event it is passed the entire stack serialised as JSON, allowing it to reconfigure itself accordingly. For example, adding an instance to an application layer triggers the configure event on the load balancer instances, allowing them to rewrite their HAProxy configurations and reload HAProxy.

You can provide custom JSON to be included with lifecycle events by editing the stack configuration. This custom JSON is merged with the stack JSON and passed to every instance when a chef command is run.

Cookbooks

Every OpsWorks stack includes the standard opsworks cookbooks, as well as any custom cookbooks you include via your own cookbooks repository.

Every machine contains the cookbooks, which are cloned upon instance creation. If you make changes to custom cookbooks you need to run the "Update custom cookbooks" command to update them before executing your updated recipes.

Custom cookbooks are provided in a single git repository, but can use git submodules to reference external cookbooks. If you want to reference a third party cookbook it's best to do so through your own copy or fork, in case the third-party cookbook is deleted or unavailable.

You can override templates in your custom cookbooks by adding a template file with the same path as the original. You can not override recipes.

If you need to customise a recipe you'll need to define your own namespaced recipe, and call it from your pre-built or custom layer.

Layers

Layers are instance templates, containg some AWS configuration, and the following chef recipes:

  • Setup
    • opsworks_initial_setup
    • ssh_host_keys
    • ssh_users
    • mysql::client
    • dependencies
    • ebs
    • opsworks_ganglia::client
  • Configure
    • opsworks_ganglia::configure-client
    • ssh_users
    • agent_version
  • Deploy
    • deploy::default
  • Undeploy
  • Shutdown
    • opsworks_shutdown::default

If you create a custom layer, this is all that will be configured.

OpsWorks provides preconfigured layer types (such as Passenger Rails, or HAProxy) which add additional recipes to these lifecycle events.

For example, Rails Passenger adds the following:

  • Setup
    • apache2
    • apache2::mod_deflate
    • passenger_apache2
    • passenger_apache2::mod_rails
    • passenger_apache2::rails
  • Configure
    • rails::configure
  • Deploy
    • deploy::rails
  • Undeploy
    • deploy::rails-undeploy
  • Shutdown
    • apache2::stop

Rails Unicorn adds the following:

  • Setup
    • unicorn::rails
  • Configure
    • rails::configure
  • Deploy
    • deploy::rails
  • Undeploy
    • deploy::rails-undeploy
  • Shutdown
    • nginx::stop

HAProxy adds the following:

  • Setup
    • haproxy
  • Configure
    • haproxy::configure
  • Deploy
    • haproxy::configure
  • Shutdown
    • haproxy::stop
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment