AWS DevOps Pro Certification Blog Post Series: OpsWorks
This is part of the blog post series: AWS DevOps Pro Certification
Using AWS costs money, some of these services may not be part of the AWS Free Tier. You can keep costs down by tearing down anything you've created whilst learning, but it's still possible to run up a hefty bill so pay attention to the instances you setup!
I'm very lucky to be able to use my employer's AWS account. You should ask your place of work if a similar arrangement can be made as part of your study.
Velocius quam asparagi conquantur
The format of the blog posts is liable to change as I try to refine my mental model of each domain, so be sure to revisit the blog posts on a regular basis.
- provides three managed services
- AWS OpsWorks for Chef Automate
- AWS OpsWorks for Puppet Enterprise
- AWS OpsWorks Stacks which uses Chef Solo
In this post, we'll primarily be focussing on AWS OpsWorks Stacks, but know that the others are managed services that can be utilised instead of running yourself (think of the comparison to self-hosting a database server versus using RDS).
- is a declarative state engine (as is Chef Automate and Solo). By this mean you define what you want to happen i.e. have a web server running, OpsWorks/Chef will then determine how to do it on the operating system that the Chef agent is installed on. Recall that package managers and configuration files live in different places in Operating Systems, even in distributions of Operating Systems (CentOS, Debian et al).
- is also unique compared to other Chef managed services in that it uses the concept of "Layers"
- autoscaling and scheduled scaling enabled
- provides you with a choice of Chef 11 or 12 stacks. The difference between the two versions is that Chef 11 has built-in cookbooks, whereas Chef 12 allows you to use your own or community cookbooks.
- has a concept of Layers (think of these as different layers of functionality i.e. web server, database server)
- these layers can be OpsWorks, ECS or RDS based
- OpsWorks Stacks User Guide
If CloudFormation is most configurable (and ultimate the most complex) orchestration tool (requiring a fair bit of Operations/Infrastructure experience) and Elastic Beanstalk is developer friendly and quick to get up and running. Then OpsWorks Stacks is probably the middle ground.
CloudFormation is a tool that is very specific to AWS, whereas your Chef recipes could be used on other Chef installations.
- You have familiarity with Chef
- Want a certain degree of control, but not the complexity of CloudFormation.
I've not had the time to hunt down the CLI equivalent for this section, please drop me a comment if you have resources I can use!
I've loosely based this around the Getting Started guide for Linux with the following exceptions:
Using a Chef 11 Stack
The application is a static site
The application deployment is via https (the GitHub download as zip link)
Go to AWS Console and find the OpsWorks service (if you don't have a Stack defined you'll be at the introductory page which provides info about Stacks and the other managed services offerings).
Create a stack (Chef 11)
- Provide a stack name
- Everything else is based on the region you choose i.e. VPC and subnet or sensible defaults provided by AWS (Operating System)
Add a layer (OpsWorks / ECS / RDS) - well drill into OpsWorks
- Set Layer Type as
Static Web Server
- The layer type is based on blueprints and can be load balancing, app server (Static, Node, PHP and Rails) and a few other types (MySQL, Memcache, Ganglia and custom).
- You can only have one type as a Layer.
- You can assign to an Elastic Load Balancer if you have one available (it will become a new layer). This makes sense if you've got multiple instances.
- Set Layer Type as
Add an instance(s)
- Hostname - will be predefined based on the layer type
- Size - AROOGA! AROOGA! aws wants to set this as
c4.largemaybe pick something cheaper like
- Subnet - you will want to distribute your instances across different subnets.
- Advanced is where you can configure scaling type (24/7, time or load based) or override default settings for OS and SSH key
- Start the instance(s)
Add an Application
- Provide a name
- Set Repository Type as
HTTP Archive(note: other options as Git, Subversion, S3 and Other)
- Set Repository URL as
- Click •Add App* button
Deploy the app
- Click the Deploy link next to your newly created "App"
- By default, the instances associated with your
Static Web Serverwill be selected
- Click the Deploy button
Wait until the app has been deployed to your instance, then go to the Instances link in the sidebar and click on the Public IP of your instance. This should launch the static site.
To tear down:
- Delete the app
- Stop the instances
- Delete the instances
- Delete the
Static Web Serverlayer
- Delete the app
API and CLI features and verbs
- User Profile
**Verbs (CRUD) **
- Account attributes
**Verbs (CRUD) **
- create (backup/server)
- describe (backups/servers/account-attribute/events)
- update (server/server-engine-attributes)
- delete (backup/server)
AWS DevOps Pro Certification Blog Post Series
- Domain 1: SLDC automation
- Domain 2: Configuration Management and Infrastructure as Code
- Domain 3: Monitoring and Logging
- Domain 4: Policies and Standards Automation
- Domain 5: Incident and Event Response
- Domain 6: High Availability, Fault Tolerance, and Disaster Recovery