AWS CloudFormation Concepts: Difference between revisions
| Line 237: | Line 237: | ||
{{External|[https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/outputs-section-structure.html Outputs]}} | {{External|[https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/outputs-section-structure.html Outputs]}} | ||
The Outputs object in the template contains declarations for the values to be made available externally after the stack is created. The section declares output values of this stack that can be imported into other stack, to create cross-stack references. A dependent stack may import the output with the [[AWS_CloudFormation_Concepts_Intrinsic_Functions#ImportValue|Fn:ImportValue]] intrinsic function. | The Outputs object in the template contains declarations for the values to be made available externally after the stack is created. The section declares output values of this stack that can be imported into other stack, to create [[#Cross-Stack_References|cross-stack references]]. A dependent stack may import the output with the [[AWS_CloudFormation_Concepts_Intrinsic_Functions#ImportValue|Fn:ImportValue]] intrinsic function. | ||
The best logical representation of an Output is a key/value pair in a virtual map shared between stacks. The output is identified by its key, and it has a value. The entry also has a description and an export name. <font color=darkgray>What is the relationship between the key and the export name. When should one be used or another?</font> | The best logical representation of an Output is a key/value pair in a virtual map shared between stacks. The output is identified by its key, and it has a value. The entry also has a description and an export name. <font color=darkgray>What is the relationship between the key and the export name. When should one be used or another?</font> | ||
| Line 253: | Line 253: | ||
awd cloudformation [[AWS_CloudFormation_Command_Line_Operations#Describe_a_Stack|describe-stacks]] | awd cloudformation [[AWS_CloudFormation_Command_Line_Operations#Describe_a_Stack|describe-stacks]] | ||
===Cross-Stack References=== | |||
When AWS resources are grouped based on lifecycle and ownership, you might want to build a stack that uses resources managed by another stack. These dependencies resources can be hard-coded in the dependent stack, or input parameters can be used to specify those. However, these methods can make templates difficult to reuse. The alternative is to export dependency resources with [[#Output|Output]] and use the exported resources by calling them using [[AWS_CloudFormation_Concepts_Intrinsic_Functions#ImportValue|Fn::InportValue]] function. | |||
=Change Set= | =Change Set= | ||
Revision as of 17:04, 21 March 2019
External
Internal
Overview
CloudFormation creates and configures resources, grouped in stacks. The resource declarations are provided as templates. One of the greatest benefits of templates and AWS CloudFormation is the ability to create a set of resources that work together to create an application or solution.
CloudFormation as AWS Service
CloudFormation is an AWS service, named "cloudformation.amazonaws.com".
Bootstrapping Application via WS CloudFormation
Stack
A stack is a collection of AWS resources that can be managed (create, update or delete) as a single unit. Every stack is based on a template: all resources in a stack are defined by the stack's AWS CloudFormation template. Because AWS CloudFormation treats the stack resources as a single unit, they must all be created or deleted successfully for the stack to be created or deleted. If a resource cannot be created, AWS CloudFormation rolls the stack back and automatically deletes any resources that were created. If a resource cannot be deleted, any remaining resources are retained until the stack can be successfully deleted.
Nested Stack
A nested stack is a stack created as part of other stacks.
Root Stack
Dependencies between Stacks
If stack B uses stack A (relies on outputs produced by stack A), then stack A cannot be deleted:
Export us-west-2-CodeBuildServiceRole cannot be deleted as it is in use by B.
Stack Operations
Template
A template is a declaration of AWS resources that make up a stack. The template describes what resources are needed, and AWS CloudFormation provisions those resources in an orderly and. predictable fashion. The resources are created in parallel where possible. AWS CloudFormation deals with failure and transient issues. The templates are stored as JSON or YAML text files.
Template Structure
---
AWSTemplateFormatVersion: "version date"
Description:
<String>
Metadata:
<template metadata>
Parameters:
<set of parameters>
Mappings:
<set of mappings>
Conditions:
<set of conditions>
Transform:
<set of transforms>
Resources:
<set of resources - the only required top-level object>
Outputs:
<set of outputs>
AWSTemplateFormatVersion
AWSTemplateFormatVersion represents the version of the template format. If not specified, loudFormation will use the latest version.
Description
Input Parameters
The input parameters are declared in a template's Parameters object. A parameter contains a list of attributes that define its value and constraints against its value. The only required attribute is Type, which can be a String, Number or an AWS-specific type.
Parameters:
WebServerPort:
Default: 8888
Description: TCP/IP port for the WordPress web server
Type: Number
MinValue: 1
MaxValue: 65535
For AWS-specific parameter types, AWS CloudFormation validates input values against existing values in the user's AWS account and in the region where he or she is creating the stack before creating any stack resources.
Type
String
The following attributes can be declared constraints: MinLength, MaxLength, Default, AllowedValues and AllowedPattern.
Number
The following attributes can be declared constraints: MinValue, MaxValue, Default and AllowedValue.
Validation Constraints
- MinLength
- MaxLength
- Default
- AllowedValues
- AllowedPattern
Parameter Description
The parameter description is important, as it will show up in the dynamically-generated CloudFormation console (wizard) while creating the stack. Specifying examples and details is a good idea.
NoEcho
For sensitive information, the "NoEcho" attribute can be used to prevent a parameter value from being displayed in the console, command line tools, or API.
GitHubPersonalAccessCode: Type: String NoEcho: true
Pseudo-Parameters
Pseudo-parameters are names CloudFormation resolves implicitly, based on the context the template is processed within, when the stack is created.
AWS::StackName
AWS::Region
AWS::AccountId
Metadata
Metadata section is optional, and provides information about the template itself. These details may include implementation details for specific resources.
Keys:
- AWS::CloudFormation::Init
- AWS::CloudFormation::Interface: Defines the grouping and ordering of input parameters when they are displayed in the AWS CloudFormation console. By default, the AWS CloudFormation console alphabetically sorts parameters by their logical ID.
- AWS::CloudFormation::Designer: describes how resources are laid out in the AWS CloudFormation Designer.
Conditions
The optional Conditions section contains statements that define the circumstances under which entities are created or configured.
Mappings
More here. Mappings are logically similar to "switch" statements. Also see Fn::FindInMap
Resources
"Resources" is the only required top-level template element. It must contain at least one resource.
Resources:
ResourceName: # ... also known as Logical ID
Type: AWS::ProductIdentifier::ResourceType
Properties: ...
A resource must have a Type attribute, which defines the kind of AWS resource should be created.
AWS::ProductIdentifier::ResourceType
Full list of resource types:
Resource declarations use a Properties attribute to specify the information used to create a resource. Resources are declared in template using logical names. When the resource is crated, a physical name is generated for it.
Resource Name, Logical ID
The name used to declare a resource definition within the template represents the logical name of that resource. It is also referred to as "resource name" or "logical ID". When AWS CloudFormation creates the resource, it generates a physical name that is based on the combination of the logical name, (sometimes) the stack name, and a unique ID. Examples of logical names to generated physical names mapping:
| Resource Logical ID | Resource Physical ID | |
| BuildBucket | → | stack-name-buildbucket-2a3et4c9f3bas |
| CodeBuildProject | → | CodeBuildProject-apCEy5I1KyH8 |
| Pipeline | → | stack-name-Pipeline-24RCYXM52UE6A |
Resource Physical ID
Upon successful creation, a resource will get a physical ID, which can be obtained from the "Resources" tab of the stack.
Resource Types
DependsOn
The DependsOn attribute specifies that one resource must be created after another.
DeletionPolicy
{{DeletionPolicy}}
Specifies how CloudFormation should handle the resource deletion.
Metadata
The Metadata attribute specifies structured data with a resource.
Embedding Stacks
Outputs
The Outputs object in the template contains declarations for the values to be made available externally after the stack is created. The section declares output values of this stack that can be imported into other stack, to create cross-stack references. A dependent stack may import the output with the Fn:ImportValue intrinsic function.
The best logical representation of an Output is a key/value pair in a virtual map shared between stacks. The output is identified by its key, and it has a value. The entry also has a description and an export name. What is the relationship between the key and the export name. When should one be used or another?
Outputs:
Output-Logical-ID:
Description: Information about the value exported as "Export.Name"
Value: value-to-return
Export:
Name: export-name
The value of an output can include literals, parameter references, pseudo-parameters, a mapping value, or intrinsic functions.
The output values can be inspected with CloudFormation -> Stacks -> stack-name -> Outputs or with
awd cloudformation describe-stacks
Cross-Stack References
When AWS resources are grouped based on lifecycle and ownership, you might want to build a stack that uses resources managed by another stack. These dependencies resources can be hard-coded in the dependent stack, or input parameters can be used to specify those. However, these methods can make templates difficult to reuse. The alternative is to export dependency resources with Output and use the exported resources by calling them using Fn::InportValue function.
Change Set
Function
AWS CloudFormation has a number of intrinsic functions that can be used to refer to other resources and their properties.
Intrinsic Functions
Ref, Join, Split, etc:
Condition Functions
Drift
CloudFormation Designer
CloudFormation Service Role
If (and when) creating a service role, CloudFormation is identified as "cloudformation.amazonaws.com".
Variable Substitution
"Variables", in lack of a better name:
The following can be substituted in Strings with the Sub function.
Template Parameters
Resource Logical ID
Resources:
MyECRepository:
...
!Sub 'this will be replaced with the name of the ${MyECRepository}'
Also see, above: Resource Name, Logical ID.