cfn-compose icon indicating copy to clipboard operation
cfn-compose copied to clipboard

Introduce more robust variable ingestion mechanism

Open rbalman opened this issue 1 year ago • 0 comments

Summary Example Compose file:

Description: Sample CloudFormation Compose file
Vars:
  ENV_NAME: cfn-compose
  ENV_TYPE: nonproduction
  SUBNET_ID: "subnet-033274e18559e7bde"
  VPC_ID: "vpc-0001e3b703212c9cb"
Flows:
  SecurityGroup:
    Order: 0
    Description: Creates Security Group
    Stacks:
    - template_file: sg.yml
      stack_name: sample-{{ .ENV_NAME }}-security-group
      parameters:
        EnvironmentName: '{{ .ENV_NAME }}'
        EnvironmentType: '{{ .ENV_TYPE }}'
        VpcId: '{{ .VPC_ID }}'
      tags:
        EnvironmentName: '{{ .ENV_NAME }}'
        EnvironmentType: '{{ .ENV_TYPE }}'

  EC2Instance:
    Order: 1
    Description: Deploying EC2 Instance
    Stacks:
    - template_file: ec2.yml
      stack_name: sample-{{ .ENV_NAME }}-ec2-instance
      parameters:
        EnvironmentName: '{{ .ENV_NAME }}'
        EnvironmentType: '{{ .ENV_TYPE }}'
        SubnetId: '{{ .SUBNET_ID }}'
      tags:
        EnvironmentName: '{{ .ENV_NAME }}'
        EnvironmentType: '{{ .ENV_TYPE }}'

Right now we use vars section in the cfn-compose.yml file to supply go template variables and replace with them dynamically in the rest of the template configuration. Since the template and variables are declared in the same template we need to parse cfn-compose.yml file twice.

  • one just to scan the vars as key value pairs and
  • other to replace the template variable in the compose configuration.

It might be better to separate vars section as a separate file to have better control, extensibility and independence for future use cases.

rbalman avatar Dec 19 '22 04:12 rbalman