Attini Init Deploy

Start a deployment

A deployment starts by uploading a distribution to the Attini deployment origin. Attini deployment origin is a s3 bucket that is created by the attini-setup onboarding process, it acts as an entrance to your environments and is the starting point for your deployments.

When the distribution is put in the Attini deployment origin bucket, it will trigger the Init deploy lambda.

Init deploy lambda

The Init deploy lambda will download the distribution from the deployment origin bucket and:

1. Extract the files in the distribution
2. Read the attini-config file.
3. Upload the distribution content to the attini-artifact-store
4. Update the reference parameter
5. Update the Init deploy stack

When the Init deploy stack is finished updating/creating, the Attini Framework will find the deployment plan and trigger it.

Distribution content

All the content in your distribution will be extracted and put in Attini artifact store.

The distribution zip file will also be copied as-is to the artifact store, so you can still work with the original zip file if needed.

You can integrate and work with these files however you see fit using the AWS CLI, AWS SDK, or Attini deployment plan integrations.

The namespace “…/distribution-origin/” is only there to distinguish the content from the origin distribution. A step in the deployment plan can fetch or create new files and save them under any namespace.

For example, you can have one step in the deployment plan that polls config files from an external source, and you can put it under /${environment}/${distribution-name}/${distribution-id}/external-config/ or if you use the AWS CDK you can put the synthesized templates under /${environment}/${distribution-name}/${distribution-id}/synthesized-templates/.

All filed with the prefix /${environment}/${distribution-name}/${distribution-id}/ will be subject to the life cycle policy.

Find the distribution artifacts

You often end up with a use case that requires your applications to find the latest version of your distribution files.

The Init deploy will save the latest distribution id in AWS SSM parameter store with the artifact with the path: /attini/distributions/${environment}/${distribution-name}/latest. So any system in your environment can easily find the latest version of your files.

Example

I have a distribution called “config” that contains a file called “vpc-config.yaml” deployed to my prod environment.

To download the file from the artifact store, I can run the following commands:

ENVIRONMENT=prod
DISTRIBUTION_NAME=config
DISTRIBUTION_ID=`aws ssm get-parameter --name /attini/${ENVIRONMENT}/distributions/${DISTRIBUTION_NAME}/latest --query Parameter.Value --output text`
aws s3 cp s3://attini-artifact-store-${region}-${accountId}/${ENVIRONMENT}/${DISTRIBUTION_NAME}/${DISTRIBUTION_ID}/distribution-origin/vpc-config.yaml .

Init deploy stack

When a distribution is deployed to an environment, the deployment needs a flexible way to initiate. The Attini Framework accomplishes this with the “Init deploy stack”. The Init deploy stack is a CloudFormation stack that is automatically deployed from a template in your distribution, and it can deploy any AWS resources you might need. This stack can also contain your Attini::Deploy::DeploymentPlan.

Find more information on how to configure the Init deploy stack using the attini-config.

Init deploy stack change detection

In order to optimize performance, Attini will only update the Init deploy stack if the stack has changed or if its input from attini-config has changed. This allows for faster deployments, but sometimes a forced update is needed. For example, if the Init deploy stack reads parameters from the SSM Parameter Store and the value of the parameter has changed since the last deployment. In this scenario, Attini is unable to detect the change and a forced update is required. This can be triggered by setting forceUpdate: true in the attini-config file. The same is true if the Init deploy stack has any custom transformations.

In order to reduce the number of times the Init deploy stack needs to be updated, it is best to minimize the amount of configuration for and logic done directly in the deployment plan. Instead, put you logic and config in other files and scripts that the deployment plan uses.

Example

Type: AttiniRunnerJob
Properties:
  Runner: HelloWorldRunner
  Commands:
    - bash my-script.sh

This is also good practice in general because it will make the Init deploy template less bloated and make it easier to manage.