Deployment

Bespin offers the ability to deploy stacks, taking into account dependency resolution and deployment checking.

For example, let’s say we have the following configuration:

---

environment:
  dev:
    account_id: "12345789"

stacks:
  security_groups:
    stack_name: appplication_security_groups

  app:
    stack_name: application

    vars:
      app_security_groups: ["{stacks.security_groups}", "AppSecurityGroup"]

    params_yaml:
      AppSecurityGroup: XXX_APP_SECURITY_GROUP_XXX

    build_after:
      - dns

  dns:
    stack_name: application-dns

And we do bespin deploy dev app, then it will first deploy security_groups, use the output from that stack as a variable for the parameters for the app stack, which gets deployed next. After the app stack is deployed, the dns stack will then be deployed (because of the build_after option).

Plans

You can explicitly specify an order of stacks by creating a plan:

---

environments:
  dev:
    account_id: "12345678"

plan:
  all:
    - vpc
    - gateways
    - subnets
    - subnet_rules
    - nat
    - dns
    - dhcp
    - dns_names
    - peering

stacks:
  vpc:
    [..]

  gateways:
    [..]

  [..etc..]

And then you may deploy that plan with bespin deploy_plan dev all

Confirming deployment

It’s useful to be able to confirm that a deployment was actually successful even if the cloudformation successfully deployed:

---

environments:
  dev:
    account_id: "123456789"

stacks:
  app:
    stack_name: application

    env:
      - BUILD_NUMBER

    params_yaml:
      BuildNumber: XXX_BUILD_NUMBER_XXX

    confirm_deployment:
      url_checker:
        expect: "{{BUILD_NUMBER}}"
        endpoint: ["{stacks.app}", PublicEndpoint]
        check_url: /diagnostic/version
        timeout_after: 600

In this example, the deployment is checked by checking that a url returns some expected value. In this case it expects the url /diagnostic/version to return the BUILD_NUMBER we deployed with.

Confirm_deployment has multiple options

url_checker

As per the example above, this checks a url on our app returns a particular value

sns_confirmation:

This confirms that an sqs topic receives a particular message:

confirm_deployment:
  auto_scaling_group_name: AppServerAutoScalingGroup

  sns_confirmation:
    timeout: 300
    version_message: "{{BUILD_NUMBER}}"
    deployment_queue: deployment-queue

This configuration will expect that the sqs queue called deployment-queue will receive a message for each new instance in the auto scaling group saying <instance_id>:success:<version_message>

Actually sending these messages is up to the definition of the cloudformation stack.

Note

The naming of this is the result of an implementation detail where this was first implemented for a stack that populated the sqs queue via an sns notification.

deploys_s3_path:

This allows you to specify an s3 path that you expect to have a value with a modified time newer than the deployment of the stack:

confirm_deployment:
  deploys_s3_path:
    - ["s3://my-bucket/generated/thing.tar.gz", 600]

Where the number is the timeout of looking for this s3 path.

When zero instances is ok

In some environments it may be ok that a stack deploys and has no instances associated with it. In this case you may set the zero_instances_is_ok: true.

If this isn’t set and no instances are in the autoscaling group after the stack is deployed, then Bespin will complain saying the deployment failed to make any instances:

---

environments:
  dev:
    account_id: "123456789"

  prod:
    account_id: "123456789"

stacks:
  app:
    stack_name: my-application

    confirm_deployment:
      auto_scaling_group_name: AppServerAutoScalingGroup

      url_checker:
        endpoint: endpoint.my-company.com
        expects: success
        check_url: /diagnostic/status

    # Add zero_instances_is_ok just for the dev environment
    environments:
      dev:
        confirm_deployment:
          zero_instances_is_ok: true