AWS Cloudformation - Partie 1 | Agile Partner
share on

AWS Cloudformation – Partie 1

By Olivier Robert, a Senior Consultant and DevOps Engineer at Agile Partner.

AWS Cloudformation is a service that enables you to provision, update and delete AWS services.

The file or files you submit, in JSON or YAML format, via the AWS console or the command line describe the desired state of your infrastructure. Cloudformation takes that description and does the heavy lifting. You do not program the steps needed to get from zero to your target. It’s not scripting. Your declare services and properties. The automation is done by Cloudformation. Sounds familiar, doesn’t it? Infrastructure as code.

I’m sure you are familiar with infrastructure as code. Maybe you have already switched from scripts in various languages to tools like Ansible (that I like). There are a few of these very known tools, no need to create an SEO buzz list here for nothing. Cloudformation is AWS’ tool and it is very handy.

What format you pick is entirely up to you, but I can’t be arsed typing curly brace and semi colons every two words, so YAML it is for me.

OK, let’s not be too long winded with the presentation and dive in.

AWSTemplateFormatVersion: 2010-09-09
Description: ---
Metadata: 

Parameters: 

Mappings: 

Conditions: 

Resources: 
 
Outputs:

Here’s the skeleton of a Cloudformation YAML file and what’s what:

Confusing? Normal! There’s detailed explanations here. But it’ll all make sense soon.

So, what resource are we going to create? A VPC is a good start. Let’s do that.

Fire up your preferred text/code editor and follow along.

The resource we want is a VPC. The only section a template really needs is a resource section. But we’ll throw in the template version and description as well.

AWSTemplateFormatVersion: 2010-09-09
Description: VPC template for Project X

Resources:
  myVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: "10.0.0.0/16"
      EnableDnsSupport: true
      EnableDnsHostnames: True
      InstanceTenancy: "default"
      Tags:
        - Key: Name
          Value: "Project X"

If we upload the template to Cloudformation, our VPC will be created in a matter of minutes.

Actually it took 21 seconds for the VPC to be created.

We have a hard coded value in our template. If we do care about that, maybe it’d be a good idea to customise it.

Enters Parameters.

AWSTemplateFormatVersion: 2010-09-09
Description: VPC template for Project X

Parameters:
  VPCCIDR:
    Description: CIDR Block for the VPC
    Type: String

Resources:
  myVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: !Ref VPCCIDR
      EnableDnsSupport: true
      EnableDnsHostnames: True
      InstanceTenancy: "default"
      Tags:
        - Key: Name
          Value: "Project X"

This is a very minimalist Parameters section, but it’ll do the trick. VPCCIDR is the variable we will use and define in the web interface.

In the resource section, we reference the variable by using intrinsic functions, here with the YAML short notation syntax.

This is a step in the right direction, but we could enter an arbitrary string for the VPCCIDR in the web interface. We can re-inforce what is expected at this stage, before we submit the template.

AWSTemplateFormatVersion: 2010-09-09
Description: VPC template for Project X

Parameters:
  VPCCIDR:
    AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/([0-9]|[1-2][0-9]|3[0-2]))$
    ConstraintDescription: Must be a valid IP range in x.x.x.x/x notation
    Default: 10.0.0.0/16
    Description: CIDR Block for the VPC
    Type: String

Resources:
  myVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: !Ref VPCCIDR
      EnableDnsSupport: true
      EnableDnsHostnames: True
      InstanceTenancy: "default"
      Tags:
        - Key: Name
          Value: "Project X"

If we use this version that uses a regular expression to validate the VPCCIDR field, this is what we’ll get in the web interface if we do indicate a valid CIDR block (like « yeah yeah, blah!blah!blah! » instead of « 10.0.0.0/16 »)

As indicated previously, the Metadata section can be used to group parameters into sections in the web interface. Here’s how we’d do that.

AWSTemplateFormatVersion: 2010-09-09
Description: VPC template for Project X

Metadata:
  AWS::CloudFormation::Interface:
    ParameterGroups:
    - Label:
        default: Network Configuration
      Parameters:
      - VPCCIDR

Parameters:
  VPCCIDR:
    AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/([0-9]|[1-2][0-9]|3[0-2]))$
    ConstraintDescription: Must be a valid IP range in x.x.x.x/x notation
    Default: 10.0.0.0/16
    Description: CIDR Block for the VPC
    Type: String

Resources:
  myVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: !Ref VPCCIDR
      EnableDnsSupport: true
      EnableDnsHostnames: True
      InstanceTenancy: "default"
      Tags:
        - Key: Name
          Value: "Project X"

Now we’ll see a « Network Configuration » section in the interface that holds the VPCCIDR parameter. Of course, this makes a lot more sense for a template with more parameters and resources. We’ll get to it.

This can save us a failed run and debugging.

We could do with an internet gateway, subnets and routing tables because right now our VPC is pretty useless. That’s OK, we’re learning Cloudformation together, no pressure!

Stay tuned, we’ll extend our template next time.

Want to know more? The experts of our Agile Software Factory are here to help you!

share on