Attini Init deploy¶

InitDeploy

Start a deployment¶

A deployment starts by uploading a distribution to the Attini deployment origin. Attini deployment origin is an s3 bucket that is created by the attini-setup CloudFormation stack, it acts as an entrance to your environment 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.

Note

Anyone permitted to put objects in this s3 bucket can initiate new deployments, which is a very privileged action. Therefore, you must be careful with s3:PutObject permissions. We highly recommend you apply a bucket policy that only allows the appropriate personnel to put objects in the bucket.

Naming convention¶

All distribution that is uploaded to the Attini deployment origin bucket needs the s3 key prefix: /${AttiniEnvironmentName}/${DistributionName}/ ex /dev/network/.

All distribution that is uploaded to the Attini deployment origin bucket needs the s3 key suffix: .zip to trigger a deployment.

So a valid deployment distribution will look something like /dev/network/optional-name.zip or /dev/network/my-version/optional-name.zip.

Note

Creating an s3 bucket policy for this bucket is an essential part of your security model because it limits who can make deployments to the environment. See Securing deployment origin for more information.

Init deploy lambda¶

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

Extract the files in the distribution
Read the attini-config
Upload the distribution content to the attini-artifact-store
Update the reference parameter
Update the Init deploy stack

When the Init deploy stack is finished updating/creating, the Attini framework will find any deployment plans and trigger them.

Distribution content¶

All the content in your distribution will be extracted and put in Attini artifact store with the prefix: /${environment}/${distribution-name}/${distribution-id}/distribution-origin/.

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 plans integrations.

The namespace “…/distribution-origin/” is only there to distinguish the content from the origin distribution, the Attini framework is designed for our customers to customize. 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 AttiniCfn steps that is configured directly in the Init deploy stack. It is often better to use a configuration file when possible. Configuration files are read at runtime and will therefore not require an update of the Init deploy stack. The same is true for commands for AttiniRunnerJob steps. In order to avoid an update of the Init deploy stack every time a command is changed it is better to put all the commands in a separate file and then execute that file. For example:

Type: AttiniRunnerJob
Properties:
  Runner: HelloWorldRunner
  Commands:
    - chmod +x ${ATTINI_SOURCE_DIR}/my-script.sh
    - ${ATTINI_SOURCE_DIR}/my-script.sh

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