Database Specialty - CloudFormation and Automation Flashcards
Infrastructure as Code
- Currently, we have been doing a lot of manual work
- All this manual work will be very tough to reproduce:
- In another region
- in another AWS account
- Within the same region if everything was deleted
- Wouldn’t it be great, if all our infrastructure was… code?
- That code would be deployed and create / update / delete our infrastructure
What is CloudFormation
- CloudFormation is a declarative way of outlining your AWS Infrastructure, for
any resources (most of them are supported). - For example, within a CloudFormation template, you say:
- I want a security group
- I want two EC2 machines using this security group
- I want two Elastic IPs for these EC2 machines
- I want an S3 bucket
- I want a load balancer (ELB) in front of these machines
- Then CloudFormation creates those for you, in the right order, with the exact
configuration that you specify
Benefits of AWS CloudFormation (1/2)
- Infrastructure as code
- No resources are manually created, which is excellent for control
- The code can be version controlled for example using git
- Changes to the infrastructure are reviewed through code
- Cost
- Each resources within the stack is tagged with an identifier so you can easily see how
much a stack costs you - You can estimate the costs of your resources using the CloudFormation template
- Savings strategy: In Dev, you could automation deletion of templates at 5 PM and
recreated at 8 AM, safely
- Each resources within the stack is tagged with an identifier so you can easily see how
Benefits of AWS CloudFormation (2/2)
- Productivity
- Ability to destroy and re-create an infrastructure on the cloud on the fly
- Automated generation of Diagram for your templates!
- Declarative programming (no need to figure out ordering and orchestration)
- Separation of concern: create many stacks for many apps, and many layers. Ex:
- VPC stacks
- Network stacks
- App stacks
- Don’t re-invent the wheel
- Leverage existing templates on the web!
- Leverage the documentation
How CloudFormation Works
- Templates have to be uploaded in S3 and then referenced in CloudFormation
- To update a template, we can’t edit previous ones. We have to reupload a new version
of the template to AWS - Stacks are identified by a name
- Deleting a stack deletes every single artifact that was created by
CloudFormation.
Deploying CloudFormation templates
- Manual way:
- Editing templates in the CloudFormation Designer
- Using the console to input parameters, etc
- Automated way:
- Editing templates in a YAML file
- Using the AWS CLI (Command Line Interface) to deploy the templates
- Recommended way when you fully want to automate your flow
CloudFormation Building Blocks
Templates components (one course section for each):
1. Resources: your AWS resources declared in the template (MANDATORY)
2. Parameters: the dynamic inputs for your template
3. Mappings: the static variables for your template
4. Outputs: References to what has been created
5. Conditionals: List of conditions to perform resource creation
6. Metadata
Templates helpers:
1. References
2. Functions
YAML Crash Course
- YAML and JSON are the languages you can
use for CloudFormation. - JSON is horrible for CF
- YAML is great in so many ways
- Let’s learn a bit about it!
- Key value Pairs
- Nested objects
- Support Arrays
- Multi line strings
- Can include comments
What are resources?
- Resources are the core of your CloudFormation template (MANDATORY)
- They represent the different AWS Components that will be created and
configured - Resources are declared and can reference each other
- AWS figures out creation, updates and deletes of resources for us
- There are over 224 types of resources (!)
- Resource types identifiers are of the form:
AWS::aws-product-name::data-type-name
How do I find resources documentation?
- I can’t teach you all of the 224 resources, but I can teach you how to
learn how to use them. - All the resources can be found here:
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aw
s-template-resource-type-ref.html - Then, we just read the docs J
- Example here (for an EC2 instance):
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aw
s-properties-ec2-instance.html
Analysis of CloudFormation Template
- Going back to the example of the introductory section, let’s learn why it
was written this way. - Relevant documentation can be found here:
- http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/awsproperties-ec2-instance.html
- http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/awsproperties-ec2-security-group.html
- http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/awsproperties-ec2-eip.htm
What are parameters?
- Parameters are a way to provide inputs to your AWS CloudFormation
template - They’re important to know about if:
- You want to reuse your templates across the company
- Some inputs can not be determined ahead of time
- Parameters are extremely powerful, controlled, and can prevent errors
from happening in your templates thanks to types.
When should you use a parameter?
- Ask yourself this:
- Is this CloudFormation resource configuration likely to change in the future?
- If so, make it a parameter.
- You won’t have to re-upload a template to change its content
How to Reference a Parameter
- The Fn::Ref function can be leveraged to reference parameters
- Parameters can be used anywhere in a template.
- The shorthand for this in YAML is !Ref
- The function can also reference other elements within the template
Concept: Pseudo Parameters
- AWS offers us pseudo parameters in any CloudFormation template.
- These can be used at any time and are enabled by default
What are mappings?
- Mappings are fixed variables within your CloudFormation Template.
- They’re very handy to differentiate between different environments
(dev vs prod), regions (AWS regions), AMI types, etc - All the values are hardcoded within the template
When would you use mappings vs parameters ?
- Mappings are great when you know in advance all the values that can be
taken and that they can be deduced from variables such as- Region
- Availability Zone
- AWS Account
- Environment (dev vs prod)
- Etc…
- They allow safer control over the template.
- Use parameters when the values are really user specific
Fn::FindInMap
Accessing Mapping Values
- We use Fn::FindInMap to return a named value from a specific key
- !FindInMap [ MapName, TopLevelKey, SecondLevelKey ]
What are outputs?
- The Outputs section declares optional outputs values that we can import into
other stacks (if you export them first)! - You can also view the outputs in the AWS Console or in using the AWS CLI
- They’re very useful for example if you define a network CloudFormation, and
output the variables such as VPC ID and your Subnet IDs - It’s the best way to perform some collaboration cross stack, as you let expert
handle their own part of the stack - You can’t delete a CloudFormation Stack if its outputs are being referenced
by another CloudFormation stack