AWS OpsWorks Stacks

Overview

• Supports hybrid environments
• Based on Chef
• Does not require Chef server

Stack

• Logical containter for layers, instances, apps
  • Compare (CloudFormation::Stack and ElasticBeanstalk::Environment)
• Typically Stack per environment (e.g. "Production", "Staging")
• Contains 1+ layers
• Updating
  • Does not generally affect running instances
• Cloning
  • Copy the settings but does not create instances

Stack Commands

• Commands
  
  • Update Custom Cookbooks
    • Fetches latest from repository
  • Execute recipes
    • Recipes to execute
  • Setup
    • Runs the instances' Setup recipes
  • Configure 
    • Runs the instances' Configure recipes
  • Upgrade Operating System
    • A-Linux or RHEL
    • Allow Reboot (Y/N)
• Instances
  • Select applicable instances
    • All, layer only, stack

Custom JSON

• Arbitrary data (parameters) that can be referenced by Chef
  • Uses Chef "node" syntax
• Can be used to override built-in layer attributes
• Specified on Create/Update/Clone stack

OpsWorks Agent

• Runs on instance
• Installed by OpsWorks (agent version specified on CreateStack)
  • LATEST - latest available version. Installes new version on instance as soon as available
  • Fixed version
• Runs in response to lifecycle events
  • AWS Backend sends JSON command to Agent
• Performs configuration management (via Chef)
• Push model (normal Chef client performs "pull")
  

Resource Management

• Allows to reuse
  • EIPs
  • EBS Volumes
  • RDS DB Instance
• Operations
  • Register 
    • Registers AWS resource to the particular stack
    • Must be done before attaching
  • Attach
    • EBS
      • cannot be attached to Windows instance
      • must be xfs formatted
      • cannot be attached/detached from running instance
    • EIP
      • can be attached online/offline
    • RDS
      • attached to (possibly many) apps
  • Move
  • Detach
  • Deregister
    • Does not delete the resource
    • When Instance is deleted its attached resources can be deleted with it

Security

• Users are imported from IAM
• Separate user management
  • Permissions
    • Deny
    • Show
    • Deploy
    • Manage
      • Not all permissions (e.g. lack clone/update stack)
      • Supplement with IAM policy if necessary
• Independent SSH keys per user to log-in to the instance