AWS CloudFormation Stack Discovery

The update-children step makes it straightforward to keep an Cloudsoft AMP model in synch with external resources, from a cloud, GitHub or Jira tickets, or any data source you choose. The AMP blueprint can then be used to attach management logic, including for example automatically deploying branched resources into ephemeral test environments.

This example shows how CloudFormation stacks in AWS can be synchronized.

Firstly, we define our type to represent discovered stack and be able to refresh on_update:

brooklyn.catalog:
  bundle: aws-cfn-discovery-sample
  version: 1.0.0-SNAPSHOT
  items:
    - id: aws-cfn-discovered-stack-sample
      item:
        type: org.apache.brooklyn.entity.stock.BasicEntity
        brooklyn.initializers:
          - type: workflow-effector
            name: on_update
            steps:
              - set-entity-name ${item.StackName}
              - set-sensor data = ${item}
              - set-sensor stack_status = ${item.StackStatus}
              # above is just a start, you can check drift, explore resources, etc

This should be added to the catalog.

We can then deploy our AMP application to discover and monitor stacks:

name: AWS CloudFormation Discoverer

services:
  - type: workflow-software-process
    location: localhost
    name: Stacks

    brooklyn.policies:
      - type: workflow-policy
        brooklyn.config:
          name: periodically update children
          period: 1m
          steps:
            - ssh aws cloudformation describe-stacks
            - transform stdout | json | set describe_stacks_output_json
            - update-children type aws-cfn-discovered-stack-sample id ${item.StackId} from ${describe_stacks_output_json.Stacks}

Create and delete stacks, and see them update in AMP. Then consider:

Modify the ssh aws step in the “discoverer” to filter based on your preferred tags.
Use the transform ... | merge operator to combine lists from different regions.
Add other policies to check for drift on stacks and show failures in AMP if there is drift.
Create a similar workflow to monitor pull requests using the gh CLI; then create, update, delete, and track ephemeral test deployments based on those