For the past year I’ve been using opsworks on AWS. I’m not sure who this product is aimed at but clearly people who are experts in Chef automation and or have deep knowledge of AWS from querying support, information not available on their technical docs. When I initially set up Opsworks it had recently been moved onto using a newer version of Chef (12), there’s very little documentation around there example github repo and cookbooks are pretty old https://github.com/aws/opsworks-cookbooks
And I could be wrong but I think these didn’t work either, the major caveat is that their online interface doesn’t seem to pick up on any changes you make outside of Opsworks. Which might be acceptable however even changing things inside the Opsworks GUI does not work sometimes. Try changing the name of the machine (this is used as the hostname) it picks this up from the machine itself. You then change the machine’s hostname, but it still reverts back to what’s set in Opsworks. Other anomalies include it showing the wrong IP address when an elastic IP is assigned.
Here’s a snippet from a support query:
When we use managed services, updates, deletes, and other modifications to the infrastructure need to be done within the management console for that service. When we make changes to resources created by something like OpsWorks outside of the OpsWorks console or AWS cli, weird behavior can occur. This is because agents controlling those resources cannot track the changes made to those resources if they are made outside of their jurisdiction. These changes are called “out of band changes.” The above scenario would be considered an out of band change, and OpsWorks is reacting to changes to its resources in an expected manner for this situation. Right now, because of the series of events surrounding the use of that EIP, OpsWorks views that EIP as unassigned to any instance in the stack, hence the conflicting information about the public IP for that instance.
Another feature of Opsworks is the auto-healing aspect. Server failure where there is a hardware fault can be automatically handled by Opsworks bringing the instance back up. After a colleague had a long chat with AWS support this isn’t supported unless you configure you instances in a specific way. Even when it does work it can get in a stop_failed status. Which effectively means it didn’t work.
The only useable aspect of Opsworks which is the only reason we are using it is for the integrated user management with AWS iam policies, which is great for SSH key management. Past that we haven’t found it reliable enough or easy to use any of the other claimed features.