Skip to content

Commit ac9abd3

Browse files
mikechaumikechau
committed
Initial commit
0 parents  commit ac9abd3

File tree

1 file changed

+270
-0
lines changed

1 file changed

+270
-0
lines changed

‎README.md

Lines changed: 270 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,270 @@
1+
# Intro to CloudFormation 101
2+
3+
This document outlines a workshop for introducing CloudFormation.
4+
5+
Are participants expected to be a CloudFormation expert at the end of the
6+
workshop?
7+
8+
Absolutely not.
9+
10+
The goal of this workshop is to expose what CloudFormation is and does.
11+
12+
It is totally OK if any or all of these things are beyond you.
13+
14+
After the workshop, perhaps through reflection it will start to make sense.
15+
Alternatively, down the road you might become more exposed to the terms and concepts described in this workshop and it might start to make more sense at
16+
that point.
17+
18+
Just keep an open mind and everything will be 200 OK.
19+
20+
## Overview
21+
22+
The following topics will be covered:
23+
24+
- Brief History
25+
+ The Manual Way
26+
+ Configuration Management
27+
+ Infrastructure as Code
28+
- CloudFormation Templating Languages
29+
+ JSON
30+
+ YAML
31+
+ Alternatives
32+
- CloudFormation Resources
33+
+ Security Groups
34+
+ Launch Configuration
35+
+ Auto Scaling Group
36+
+ EC2 Instance
37+
- CloudFormation Features
38+
+ Parameters
39+
+ Resource Types
40+
- Lab
41+
42+
## Brief History
43+
44+
Before we jump into writing a CloudFormation template, let's review a brief
45+
history of managing AWS infrastructure before CloudFormation.
46+
47+
### The Manual Way
48+
49+
[!Automation - xkcd](https://imgs.xkcd.com/comics/automation.png)
50+
51+
The fallback for automation is just doing whatever it is manually.
52+
53+
Without the right tooling, automating a process can be time consuming because a
54+
lot of time can be spent on building tools to assist with the automation (ie. writing a script).
55+
56+
Examples:
57+
- Logging into the AWS console and manually provisioning servers.
58+
- SSH into each server to apply system upgrades.
59+
60+
We could save some time by writing some scripts and it'll get the job done and this will generally work fine at a small scale.
61+
62+
The manual way becomes tedious and error prone when we start to introduce the
63+
need to manage more systems in many different environments and need to create
64+
copies of an environment that are all similarly configured (ie. dev/staging/
65+
prod).
66+
67+
Tracking changes to a system can also be challenging as there might not be any
68+
sort of audit trail to refer back to.
69+
70+
Pros:
71+
- Fast
72+
73+
Cons:
74+
- Tedious when repeating
75+
- Error prone when repeating
76+
- Hard to determine the state of the world
77+
78+
### Configuration Management
79+
80+
As we move away from the manual way, we might start to look at configuration
81+
management tools.
82+
83+
Popular choices include:
84+
85+
- Chef
86+
- Puppet
87+
- Salt
88+
- Ansible
89+
90+
Configuration management is all about maintaining consistency and tracking
91+
changes. Configuration management also makes it easier to audit and maintain
92+
compliance.
93+
94+
Essentially, configuration management allows you to declare the state of the world and it will update the targeted systems to match it.
95+
96+
Pros:
97+
- Consistency
98+
- Auditing
99+
- Compliance
100+
101+
Cons:
102+
- Not necessarily needed for containerized application deployments
103+
- Rolling back is not free
104+
105+
### Infrastructure as Code
106+
107+
Infrastructure as code is all about having a single source of truth that serves
108+
as a blueprint for what we want the infrastructure to look like.
109+
110+
Templates are written using a DSL that describes the desired resources and their relationships.
111+
112+
Examples:
113+
- CloudFormation
114+
- Terraform
115+
116+
Pros:
117+
- Consistency
118+
- Auditing
119+
- Compliance
120+
- Rollbacks*
121+
122+
Cons:
123+
- Potentially can destroy a resource unintentionally
124+
125+
## CloudFormation Templating Languages
126+
127+
CloudFormation supports two flavors of templating JSON and YAML.
128+
129+
### JSON
130+
131+
```json
132+
{
133+
"AWSTemplateFormatVersion" : "2010-09-09",
134+
"Description" : "Single EC2 Instance",
135+
"Resources" : {
136+
"MyEC2Instance" : {
137+
"Type" : "AWS::EC2::Instance",
138+
"Properties" : {
139+
"ImageId" : "ami-79fd7eee",
140+
"KeyName" : "testkey",
141+
"InstanceType": "t2.micro"
142+
}
143+
}
144+
}
145+
}
146+
```
147+
148+
At the bare minimal, the JSON template contains top level keys for
149+
`AWSTemplateFormatVersion`, `Description`, and `Resources`.
150+
151+
Inside `Resources` are uniquely named keys that are mapped to specific AWS
152+
resources.
153+
154+
### YAML
155+
156+
```yaml
157+
---
158+
AWSTemplateFormatVersion: '2010-09-09'
159+
Description: Single EC2 Instance
160+
Resources:
161+
MyEC2Instance:
162+
Type: AWS::EC2::Instance
163+
Properties:
164+
ImageId: ami-79fd7eee
165+
KeyName: testkey
166+
InstanceType: t2.micro
167+
```
168+
169+
CloudFormation has recently offered support for YAML offering a more human
170+
option for writing templates. Whitespace has significance with YAML, rather
171+
than use curly braces we can nest keys by indenting two spaces at each level.
172+
173+
### Alternatives
174+
175+
Generally, most CloudFormation users will probably not be writing their
176+
templates in JSON by hand, but utilize some sort of scripting language to
177+
generate the templates to JSON.
178+
179+
Such options include:
180+
181+
- [cfndsl](https://github.com/cfndsl/cfndsl) - Ruby
182+
- [troposphere](https://github.com/cloudtools/troposphere) - Python
183+
184+
But ultimately, we can use whatever we want as long it generates valid JSON or
185+
YAML.
186+
187+
## CloudFormation Resources
188+
189+
A CloudFormation template represents a *stack*, and the components within the
190+
*stack* are known as *resources*.
191+
192+
In this workshop, as a class we will compose a static template. It will cover
193+
everything from the VPC to an Auto Scaling Group.
194+
195+
If you are lost, it is OK. This part of the workshop is more about doing.
196+
197+
### Security Groups
198+
199+
> A security group acts as a virtual firewall that controls the traffic for one or more instances. When you launch an instance, you associate one or more security groups with the instance. You add rules to each security group that allow traffic to or from its associated instances. You can modify the rules for a security group at any time; the new rules are automatically applied to all instances that are associated with the security group. When we decide whether to allow traffic to reach an instance, we evaluate all the rules from all the security groups that are associated with the instance.
200+
201+
**KEY FACT:**
202+
203+
> Security groups are stateful — if you send a request from your instance, the response traffic for that request is allowed to flow in regardless of inbound security group rules. Responses to allowed inbound traffic are allowed to flow out, regardless of outbound rules.
204+
205+
For example, if you have a EC2 instance that needs to talk to MySQL, the
206+
instance only needs to have a egress (outbound) rule to 3306. The MySQL server
207+
would need a ingress (inbound) rule for 3306.
208+
209+
#### References
210+
211+
- [Security Groups for Your VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html)
212+
- [AWS::EC2::SecurityGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-security-group.html)
213+
214+
### Launch Configuration
215+
216+
> A launch configuration is a template that an Auto Scaling group uses to launch EC2 instances. When you create a launch configuration, you specify information for the instances such as the ID of the Amazon Machine Image (AMI), the instance type, a key pair, one or more security groups, and a block device mapping. If you've launched an EC2 instance before, you specified the same information in order to launch the instance.
217+
218+
**KEY FACT**:
219+
220+
> You can specify your launch configuration with multiple Auto Scaling groups.
221+
222+
> However, you can only specify one launch configuration for an Auto Scaling group at a time, and you can't modify a launch configuration after you've created it.
223+
224+
A launch configuration is immutable and can be assigned to multiple auto scaling groups, but a auto scaling group can only use one launch configuration.
225+
226+
#### References
227+
228+
- [Launch Configurations](https://docs.aws.amazon.com/autoscaling/ec2/userguide/LaunchConfiguration.html)
229+
230+
### Auto Scaling Group
231+
232+
> An Auto Scaling group contains a collection of EC2 instances that share similar characteristics and are treated as a logical grouping for the purposes of instance scaling and management. For example, if a single application operates across multiple instances, you might want to increase the number of instances in that group to improve the performance of the application, or decrease the number of instances to reduce costs when demand is low. You can use the Auto Scaling group to scale the number of instances automatically based on criteria that you specify, or maintain a fixed number of instances even if a instance becomes unhealthy. This automatic scaling and maintaining the number of instances in an Auto Scaling group is the core functionality of the Amazon EC2 Auto Scaling service.
233+
234+
#### References
235+
236+
- [Auto Scaling Groups](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html)
237+
238+
### EC2 Instance
239+
240+
> Amazon Elastic Compute Cloud (Amazon EC2) provides scalable computing capacity in the Amazon Web Services (AWS) cloud. Using Amazon EC2 eliminates your need to invest in hardware up front, so you can develop and deploy applications faster. You can use Amazon EC2 to launch as many or as few virtual servers as you need, configure security and networking, and manage storage. Amazon EC2 enables you to scale up or down to handle changes in requirements or spikes in popularity, reducing your need to forecast traffic.
241+
242+
#### References
243+
244+
- [What is Amazon EC2?](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html)
245+
246+
## CloudFormation Features
247+
248+
To keep things simple, we will only cover a few features CloudFormation
249+
templates supports.
250+
251+
#### References
252+
253+
- [What is AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
254+
- [Template Reference](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-reference.html)
255+
256+
### Parameters
257+
258+
> Parameters enable you to input custom values to your template each time you create or update a stack.
259+
260+
- [Parameters](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html)
261+
262+
### Resource Types
263+
264+
265+
266+
### Reference Function
267+
268+
## Lab
269+
270+
Using our existing CloudFormation template, configure it to accept a parameter to change the instance type, AMI (typed), and add another security group rule that allows incoming traffic on port 443.

0 commit comments

Comments
 (0)