AWS OpsWorks (Instance)

Instance

• Belongs to a layer
  
  • Must be member of at least one layer
  • Can be a member of multiple layers
    • Reduce expenses (e.g. database co-hosted with web server)
    • If any layer has auto-healing disabled the instance WILL NOT be replaced
• Has OpsWork agent installed
• Configuration (Instance Type, AZ)
• Installs package updates
  • Disable with InstallUpdatesOnBoot
• Has root device type (EBS or Instance-store)
• Instance can be on-premise
  • Additional charges apply
• Existing EC2 instance can be registered
• Many stack settings can be overridden on per-instance manner
• Hosts file
  • Maintained by OpsWorks agent

Machines Created Outside of OpsWorks

• Linux only
• Registration
  • Installs an OpsWorks agent on the machine
• Assigning to layer
  
  • Runs Layer's recipes
• Unassigning
• Deregistration
  • Shuts down the agent and uninstalls

Registered Instance States

• Registering
  • Called: register 
  • Setup command sent
• Running Setup
  • Setup Acknowledged
  • Running core Setup recipes (initial setup)
  • /etc/hosts is overwritten
• Registered
  • Initial Setup successful
  • Not assigned to any layer
• Assigning
  • Called: assign
  • All setup recipes run again (including initial but they are idempotent)
• Unassigning
  • Shutdown coommand sent
  • After completion returns to Registered state
• Online
  • Setup successful
  • Assigned to layer
  • Configure command sent all instances in the stack
• Setup failed
  • Setup unsuccessful
• Deregistering
  • From any other state
• Deleted
  • Instance is deregisterd (not part of Stack anymore)
  • re-register if needed again

Supported Platforms

• x64 only
• Cannot mix Linux and Windows in the same stack
• Linux
  • Can run different distributions in the same layer
  • A-Linux
    • New major version every 6 months
      
      • Lock the version to control the update process
  • Ubuntu
  • RHEL7
• Windows
  • Only Custom Layers can be used
• Custom AMIs
  • Must be based on OpsWorks-Supported AMIs
  • Two methods of creating AMI
    • Linux/Windows: use EC2 
    • Base on existing OpsWorks instance
  • Cannot specify specific AMI as default OS
    • Must specify generic "Custom AMI"
  • Can specify custom AMI only when you "Add new instance"

Root Device Storage

• Windows - must be EBS
• Linux
  • Instance Store
    • On restart must repeat complete setup
    • Logs are lost
  • EBS
    • Costly
    • Depends on EBS service

Scaling Type

• Does not use EC2 auto scaling
• OpsWorks does NOT launch new instances
  • It can only start/stop existing
•  24/7
  • Stop-start manually
• Time-Based
  • Similar to AS scheduled policy
• Load-Based
  • Similar to AS dynamic policy
    • Unlike AS instances are stopped but not terminated
  • Linux only