Knowledge Bank

Here you will find general information about Attini, such as:

Common issues add fixes
Glossary
How to scale your Attini deployments in a bigger organization
Information on why Attini is great!

Attini Way of Working

The Attini Framework and the Attini CLI together create a way of working that helps you to manage your AWS resources using AWS CloudFormation.

Environment isolationq

A core concept in Attini is the complete isolation of IT environments. We achieve this by copying all deployment source files into the IT environment, then all the deployment logic is performed by serverless resources inside your IT environment. This means that every IT environment is self-sufficient.

With tools that run on virtual machines or in containers, it’s often too expensive and high maintenance to have a “worker node” running in every environment all the time, this means that you often run the worker nodes in a central location and share them cross environments. Even if you’re using a CI/CD SaaS service, you still have a central platform, you just don’t manage it yourself. These types of central platforms often result in scaling limitations and tight environment coupling.

Because Attini is 100% serverless, its easy and low cost to have one copy of all CI/CD resources per environment. This design also comes with performance advantages.

Advantages

An incident/downtime/problem with your central build/deploy platform will never block you from managing your IT environment.
Easy to experiment with test environments and be sure that you never affect any other environment’s CI/CD resources.
Higher deployment speed and fewer queues.
Much easier to maintain many environments (multiple test environments, global deployments, disaster recovery environments etc).

Stateful distributions

The Attini distribution is a zip archive that contains:

Name and id (version).
All source files needed for the deployment.
Instructors on how to execute the deployment.

Attini distributions are inspired by how container images bundle all its dependencies into one image. Similarly, the Attini CLI helps you to package as many dependencies as possible into one distribution. This means that you will have all your templates, code, configuration, and any other files you might need, gathered in one place.

The Attini CLI also helps you to run scripts on a copy of your files, so you get a natural place in your workflow to:

Get automatic configuration (for example, to freeze software version or AMI ids).
Fetch centrally managed files (standard temples, global configuration, software libraries etc).
Build your code.
Etc…

The goal is to make the distribution as static as possible so that your deployment will be as predictable as possible.

Note

It is of course possible to do all of these things during the deployment (using Attini runner, AWS Lambda, CodeBuild, ECS Task, or any other compute options available in your cloud environment) as well if you need to. But then you lose the guarantee that all of your deployments will look the same.

Managing multiple environments

When we run multiple environments, we often have two contradicting requirements:

We should be able to do things in one environment without affecting the others.
All our environments should look the same.

This is a contradiction because if we do things in one environment, that environment will divert from our other environments.

To work around this contradiction, we need to be able to do 3 things:

Individually managed every environment.
Find discrepancies between environments.
Put the environments back in sync.

With Attini every environment has its own set CI/CD resources so it’s easy to individually work with one environment for development or incident mitigation (hotfix or rollback).

You can find discrepancies between environments by comparing distribution versions that are currently running in your environments. We recommend that you use a git commit (or part of the git commit) as your distribution id (or part of the id). This way you will also get a changelog via your git commit messages.

If you find discrepancies between environments, it’s easy to promote the distribution with the correct version to the out-of-date environment. Normally this means that we promote new features to production or other test environments (from development to staging), but it’s also very handy if you need to rollback a development environment after failed tests.

The Attini deployment plan

The pipeline that you are using when designing a hands-off deployment is critical for your success.

Here are some of the most important requirements:

Automatically configured so that you can maintain them on a bigger scale.
They have to be fast so that your development and incident mitigation can be fast.
Full-featured process logic like parallel actions, choices, re-tries, etc.
Plenty of services integrations (features).
Mange dependencies.

The Attini deployment plan is always automatically created and updated by the Attini init deployment so it’s just as easy to maintain 1 deployment plan as 10 deployment plans.

The Attini deployment plan is an abstraction on AWS StepFunction with comes with a lot of advantages:

Familiar syntax.
It’s very fast.
It is low cost for this use case.
Full of features and flexible process logic and error handling.
Lots of native AWS Service integrations.

But the AWS StepFunction needs a few more features to manage all our requirements, so Attini added:

Our own state types like AttiniCfn and AttiniMergeOutput to better integrate with AWS CloudFormation and to simplify common use-cases.
Standard Payload that manages dependency’s and run-time configuration.

In addition to this, Attini have managed to make most of our deployment logic event-driven, which is a big performance improvement.

Attini in your workflow

To make it easy to adopt Attini, we made 3 important design decisions:

No new authentication (we use your current AWS credentials).
Make the packaging (build) portable with the Attini CLI.
Move all deployment logic into the IT environment (Attini deployment plan).

Attini only uses your AWS credentials, so there is no need for another login or SSO configuration, your current AWS IAM roles and users will work out of the box (they might need the attini-cli-user-{region} IAM policy that is created by the attini-setup).

This also means that AWS CloudTrail will log everything Attini does, find mroe information here.

If you run all your build scripts via the package section in the attini-config. It will be easy for you to run the same code from your local computer that your build server does. This enables you to bypass git and your build server during development, which improves development speed.

The Attini CLI also has features that are designed to help you to mock your build server configuration so that your build scripts can run unchanged.

Because we moved all deployment logic from a central CI/CD platform (Build server, Deployment SaaS solution, etc), and because you can install the Attini CLI anywhere, you can always extend any tool you currently use with Attini.

Getting started

To get started with Attini, see our Quick start.

Central Repository for Attini Distributions

Description

You often want to have a central repository for your build artifacts. This example shows how to configure an S3 bucket to act as a central repository for Attini distributions.

Prerequisites

AWS account that is a member of an AWS organization.
Install the AWS CLI and Configure CLI credentials.
Install the Attini CLI.
A GitHub repository.

We will go through:

How to configure the S3 bucket.
How to configure GitHub actions to build the Attini distribution. using the Attini CLI.
How to push the Attini distributions to S3 using the AWS CLI.
How to fetch the Attini distribution from the S3 bucket and deploy. it to a different AWS Account using the Attini CLI.

Note

This example is for GitHub actions, but the general architecture will work with any build server that integrates with git and AWS. You will just have to reconfigure a few things.

Create the S3 Bucket

First, we need an S3 bucket with the following configuration.

Note

Ensure you have AWS CloudTrail data events enabled for this bucket if you plan to use it in Production. If the distributions are tampered with, you want to know who did it.

We need a life cycle policy for the objects. There will always be a copy of the distributions inside every individual environment using it, so you don’t need to worry about removing distributions that might be needed for a rollback.

In the example below, we will delete the distributions after 365 days.
We need a bucket policy allowing application accounts to get the distributions.

The example below opens the bucket for the entire AWS Organization.
We need to give GitHub actions permission to upload an object to the bucket.

In the example below, I create a Managed Policy that I will use for an IAM User or an IAM Role.

Example bucket CloudFormation template

AWSTemplateFormatVersion: 2010-09-09
Description: Example of and S3 bucket that can act as a central repository for attini distributions.

Parameters:
  BucketName:
    Type: String
    Description: The repository (s3 bucket) name.

  OrganizationId:
    Type: String
    Description: The id of your AWS Organization (o-xxxxxxxxxx). This will allow all AWS Accounts in your AWS Organization to get objects from the bucket.

Resources:
  AttiniRepository:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Ref BucketName
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          -
            ServerSideEncryptionByDefault:
              SSEAlgorithm: AES256
      VersioningConfiguration:
        Status: Enabled
      LifecycleConfiguration:
        Rules:
          -
            Id: ExpirationInDays
            Status: Enabled
            ExpirationInDays: 356
          -
            Id: MultipartUploadLifecycleRule
            Status: Enabled
            AbortIncompleteMultipartUpload:
              DaysAfterInitiation: 7
          -
            Id: NoncurrentVersionExpirationInDays
            Status: Enabled
            NoncurrentVersionExpirationInDays: 30
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true


  BucketPolicy:
    Type: AWS::S3::BucketPolicy
    Properties:
      Bucket: !Ref AttiniRepository
      PolicyDocument:
        Statement:
          -
            Action:
              - s3:GetObject
              - s3:ListBucket
            Effect: Allow
            Resource:
              - !GetAtt AttiniRepository.Arn
              - !Sub ${AttiniRepository.Arn}/*
            Principal: "*"
            Condition:
              StringEquals:
                aws:PrincipalOrgID: !Ref OrganizationId

  PushAttiniDistribution:
    Type: AWS::IAM::ManagedPolicy
    Properties:
      ManagedPolicyName: push-attini-distribution
      Description: This policy allows an IAM User or IAM Role to push distribution to the repository bucket
      PolicyDocument:
        Version: 2012-10-17
        Statement:
          - Action:
              - s3:PutObject
            Effect: Allow
            Resource: !Sub ${AttiniRepository.Arn}/*


Outputs:

  AttiniRepository:
    Description: The name of the S3 bucket
    Value: !Ref AttiniRepository

Configure your Git Repository

Configure access to the S3 bucket

If your build server already has access to S3, you can skip this step.

You can give GitHub actions AWS access in 2 ways using IAM Role (OIDC) or with an IAM User.

Using the IAM Role is better because you want to have to manage API keys, so this is recommended for production use.

Using the IAM User is fast and easy, so for a POC, this opinion is ok.

Follow the steps in this guide.
Attach the push-attini-distribution Managed Policy to your role.

IAM User (old way)

Create an AWS IAM User that has “s3:PutObject” access to the bucket we just created. You can use the push-attini-distribution Managed Policy in the template if you want to. Temporarily save the “Access key ID” and “Secret access key” somewhere safe.
Go to your Gihub repository > Settings > Secrets > Actions secrets.
Add 2 new secrets, one called AWS_ACCESS_KEY_ID and the other AWS_SECRET_ACCESS_KEY and populate the values that you saved from step 1.

Configure the Attini distribution

Create a file called attini-config.yaml in the root of the repository.

It should look something like this:

distributionName: hello-world

package:
  prePackage:
    commands:
      - attini configure set-dist-id --id ${GITHUB_SHA} # this command will set the Attini distribution to the git commit id

Info

If you ever need to package (attini distribution package) the distribution on your local computer when doing development, you can mock the GITHUB_SHA environment variable using the flag --environment-config-script. In this script, you can add the shell command export GITHUB_SHA=test-commit-id.

Configure the GitHub action

In the root of your repository, create a file called .github/workflows/build.yml

Now add the following code to the file:

on:
  push:
    branches:
      - main

name: Build and push Attini distribution

jobs:
  deploy:
    name: Build and push
    runs-on: ubuntu-latest

    steps:
    - name: Configure AWS Credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: eu-west-1


    - name: Install Attini CLI # Better to do this in the container image if it's possible
      shell: bash
      run: |
          curl -fsSO https://docs.attini.io/blob/attini-cli/install-cli.sh
          bash install-cli.sh -s          


    - name: Check out repository code
      uses: actions/checkout@v2

    - name: Package and upload the Attini distribution
      shell: bash
      run: |
        # GITHUB_SHA is an environment variable which is our git commit id, which is a good value to use for the distribution id.
        DISTRIBUTION_ID="${GITHUB_SHA}"
        DISTRIBUTION_NAME="hello-world"
        REPOSITORY_BUCKET_NAME="attini-repository-bucket"

        attini distribution package . --name ${DISTRIBUTION_NAME}.zip

        # If you upload the distribution to the path "/latest/" it easy to find the latest version.
        aws s3 cp ${DISTRIBUTION_NAME}.zip s3://${REPOSITORY_BUCKET_NAME}/${DISTRIBUTION_NAME}/latest/${DISTRIBUTION_NAME}.zip

        # You also want to save a copy with the DISTRIBUTION_ID in path so that you can easily get old versions.
        aws s3 cp ${DISTRIBUTION_NAME}.zip s3://${REPOSITORY_BUCKET_NAME}/${DISTRIBUTION_NAME}/${DISTRIBUTION_ID}/${DISTRIBUTION_NAME}.zip

At the very least you want to change the values for aws-region and REPOSITORY_BUCKET_NAME in the file.

Next time you push a change to the main branch, your distribution will be packaged and uploaded to the s3 bucket to the location /hello-world/${DISTRIBUTION_ID}/hello-world.zip and /hello-world/latest/hello-world.zip.

You can, of course, name your distributions whatever you want and use any prefix or path in S3 that makes sense for your way of working, but having the distribution name and id in the S3 key is a good place to start.

You can also add additional steps that automatically log in to your Development AWS account and deploy the distribution there.

Deploy the Attini distribution from the repository

Now log in to your application account (for example, Development or Production) from your terminal, build server, or AWS CloudShell and run the following command:

attini deploy run s3://${REPOSITORY_BUCKET_NAME}/hello-world/${DISTRIBUTION_ID}/hello-world.zip

This will pull the distribution from the repository and deploy it to your current environment.

Change Log

Note

This changelog is no longer maintained, please see our releases on GitHub.

Attini CLI

Version 2.5.8

Date: 28 March 2023

Attini is now Open Source and you can find our latest releases in Attini CLI repository on GitHub

Version 2.5.7

Date: 11 March 2023

Bug fix: Environment configuration scripts will now work as intended.

Version 2.5.6

Date: 2 March 2023

Bug fix: Will now exclude symlink files when coping working directory during package. This created problems for container builds.

Version 2.5.5

Date: 17 February 2023

Added support for new features in the Attini framework version 1.6.0.

Recommended framework version 1.6.0 or higher

Version 2.5.4

Date: 7 February 2023

Will now exclude node_modules, .DS_Store and .vscode when copying files to the temp working directory for packaging a distribution.
attini dist inspect command now shows the distribution version.

Version 2.5.3

Date: 26 January 2023

Added an AWS SAM project to attini init-project commands.
Bug fix. Path for sam project no longer has to start with a slash.

Version 2.5.2

Date: 20 January 2023

Added the "--abort" option to the attini deploy continue command.

Version 2.5.1

Date: 17 January 2023

Increased timeouts for S3 as it sometimes timed out for big distribution when working with a poor internet connection.
Bug fix. Fixed a bug when the AWS SDK SSO implementation would throw a "token expired" error before the token expired.

Version 2.5.0

Date: 5 January 2023

Now adds the AttiniMergeOutput step automatically after a parallel step if using the simple syntax.

Version 2.4.4

Date: 12 December 2022

Bug fix. The rollback command now works together with the production environment confirmation prompt.
Bug fix. Now you can combine --container-build and --environment-config-script in the attini deploy run command
Bug fix. CloudFormation shorthand conditions now work in the deployment plan template.

Version 2.4.2

Date: 9 December 2022

Some minor changes to the presentation.
Updated the following deployment function to link to the new StepFunction console.
Distribution name is now mandatory. It will no longer be resolved from the folder name if absent.

Version 2.4.1

Date: 7 December 2022

Added support for a simple deployment plan syntax (Beta).
Some minor changes to the presentation.

Version 2.4.0

Date: 30 November 2022

Improved visuals when following a deployment.
Added --disable-least-privilege-init-deploy-policy option to attini setup command.
Improved validation.
Will now retain files in sam project folders.
Added node_modules to default ignores.
Will now fail during package if a sam template in an AttiniSam step uses "PackageType: Image" as it is not supported.

Version 2.3.0

Date: 21 November 2022

Now creates a metadata file when packaging a distribution in order the be pass data available during the package phase to the framework.
Added support for the AttiniSam step.
Added additional validation of the init-stack during the package phase.
Added support for semantic versioning of distributions.

Version 2.2.2

Date: 26 October 2022

Bug fixes.

Version 2.2.1

Date: 19 October 2022

Added the attini deploy continue command to resume deployments paused by the AttiniManalApproval.
Bug fixes.

Version 2.1.1

Date: 13 October 2022

Bug fixes.
Command attini deploy run now have a smoother cross account deployment experience. When deploying straight from an S3 bucket, s3:GetBucketLocation permissions is now required.
Status on deployment plan in attini deploy history command

Version 2.1.0

Date: 10 October 2022

Completely rebuilt the follow deployment function used for attini deploy run and attini deploy describe. It will now print outputs from different steps as well as any output from scripts executed with the attini runner.
Added the --json option to attini deploy run, attini deploy describe and attini package commands.

Version 2.0.0

Date: 20 September 2022

attini context is now attini environment context.
Added attini distribution parent command.
attini package is now attini distribution package.
Added the attini distribution inspect command.
Added the attini distribution download command.
Added the --environment option to the attini context command.
Added the --distribution-name option to the attini context command.
Added the attini ops parent command.
attini report rogue-stacks is now attini ops rogue-stacks.
attini export-logs is now attini ops export-logs.
attini delete-stack-resource is now attini ops delete-stack-resource.
Added the --delete-stack flag to the attini delete-stack-resource command.
Commands with json or yaml output will now also output errors in the same format.
Added the me-central-1 region to the auto-completion candidates.

Version 1.2.1

Date: 1 September 2022

Fixed a bug when the specified profile region was not used for AWS calls.
Fixed bugs in the information prompt when deploying to production.

Version 1.2.0

Date: 31 August 2022

Added attini update-cli command. It will update the CLI...
Users will now be informed when they are using an older version of the CLI when deploying or packaging distributions.
Added more information to the prompt when deploying to production environment.
The attini environment list command will now print errors in yaml or json format.

Version 1.1.13

Date: 22 August 2022

Added some validation for attini-config during the package phase.
Minor bug fixes.

Version 1.1.12

Date: 05 August 2022

Fixed bug in the attini context command. The timestamp for the latest deployment will now print the correct format.

Version 1.1.11

Date: 22 June 2022

Fixed bug in the attini context command. Will now correctly show distributions even if the StepFunction logs have been cleared (after 90 days). This required the distribution to be deployed with version 1.2.54 or later of the Attini framework.
Improved performance of the attini context command.
ANSI colors can now be disabled by setting the ATTINI_DISABLE_ANSI_COLOR environment variable.
Introduced environment types. An environment can now be either a "test" or a "production" environment.
Added confirmation prompt when deploying to a production environment.
Added the --force option for deployment commands. This will make the CLI skip the confirmation prompt.

Version 1.1.10

Date: 10 June 2022

The follow deployment function now supports change detection for the Init-deployment-stack.

Version 1.1.9

Date: 31 May 2022

All commands now have a --help option
All commands returning lists will now return a list in either json or yaml format depending on if the the --json option is set.

Version 1.1.8

Date: 21 April 2022

Bug fix: The attini_dist folder will now always be deleted completely before package.

Version 1.1.7

Date: 30 Mars 2022

Bug fix: Fixed error when attini package would freeze if executed in an environment with 2 or less available threads.
Bug fix: Fixed error when attini package would crash if executed in an environment without the "SHELL" environment variable set.

Version 1.1.6

Date: 22 Mars 2022

Bug fix: Fixed bug when installing Attini in a new account.
Bug fix: attini deploy describe now behave as intended.
Bug fix: Fixed bug when redeploying an init-stack right after it failed gave a misleading error message.

Version 1.1.5

Date: 22 Mars 2022

Note

Requires Attini Framework version 1.2.8 or higher.

Improved error reporting when following a deployment. CloudFormation errors will now be printed in real time. This feature is not available for cross account or cross region deployments.

Version 1.1.4

Date: 2 Mars 2022

Bug fix: attini report rogue-stacks now behave as intended when there are multiple environments in the same account.

Version 1.1.3

Date: 14 February 2022

Can now specify options to pass to docker when doing container builds. Options are specified in the attini-config file.
Environment configuration files specified with the --environment-config-script option is now required to be located in the distribution project folder, or in a subdirectory to it.
A relative path specified via the --environment-config-script option is now relative from where the command is executed, not relative to the distribution root.
Bug fix: package using container build will now handle absolute paths for the --environment-config-script option.

Version 1.1.2

Date: 8 February 2022

Added container build option for attini deploy run and attini package commands. You can now specify an image in your attini-config that will be used for packaging your distribution
Added attini report rogue-stacks command to help manage stacks no longer managed by a distribution.
Added attini delete-stack-resources command that will remove any resources Attini created in order to manage a Cloudformation stack. Will not delete the actual stack.
attini deploy run and attini package commands will now put the finished distribution in a folder called attini_dist inside the distributions project folder.
Added support for aarch64 CPU.

Version 1.1.1

Date: 31 January 2022

Note

Requires Attini Framework version 1.2.8 or higher.

Added attini deploy describe command to follow deployment started by others or get information about previous deployments.
attini setup command no longer require --contact-email.
Minor bug fixes.

Version 1.1.0

Date: 14 January 2022

Note

Requires Attini Framework version 1.2.0 or higher.

Bug fix: Context command will no longer fail on distributions without deployment plans
attini context command will now print what version of the Attini framework is installed in your AWS account.
Added attini init-project command with various subcommands to help get started with new projects.
Added attini deploy history command now prints in yaml format by default.
Added attini deploy history command no longer require environment to be specified if there is only one environment in account.
Added attini deploy rollback command no longer require environment to be specified if there is only one environment in account.
Added attini deploy run command no longer require environment to be specified if there is only one environment in account.

Version 1.0.7

Date: 21 December 2021

Environments are no longer created automatically when deploying to them for the first time. This is to prevent creating environments in the wrong account by accident. Instead a user is required to create environments via the CLI.
Added attini environment create <env-name> command.
Added attini environment remove <env-name> command.
Added attini environment list command.
Added attini context command to get information about the current environments/account. Only works for distributions deployed with version 1.1.1 or greater of the Attini framework.

Version 1.0.6

Date: 9 December 2021

Bug fix: fixed error when package commands some times abort the executions even with correct exit code.

Version 1.0.5

Date: 16 November 2021

Added attini package --environment-config-script option.
Added attini deploy run --environment-config-script option.
Bug fix: attini setup will no longer require user to enter the --create-init-deploy-default-role or --init-deploy-role-arn when updating the framework.
Bug fix: Errors from pre or post package commands will now print the entire error message, not just the first row.
Email option is now required for attini setup when installing Attini for the first time.

Version 1.0.4

Date: 16 November 2021

Added attini setup --create-deployment-plan-default-role flag.
Added attini setup --create-init-deploy-default-role flag.

Version 1.0.3

Date: 8 November 2021

Added attini package command.
Added support for pre and post package command.
Added attini setup --accept-license-agreement flag.
Added attini setup --keep-version flag.
Added attini configure set-init-deploy-parameter command to easily set/update parameters for init-deploy.
Added attini configure set-init-deploy-tag command to easily set/update tags for init-deploy.
Added attini configure set-parameter command to easily set/update parameters for CloudFormation deployments.
Added attini configure set-tag command to easily set/update tags for CloudFormation deployments.
Added attini configure set-dist-id command easily set/update distribution id.

Attini Framework

Version 1.7.0

Date: 14 March 2023

Attini is now Open Source and you can find our latest releases in Attini framework repository on GitHub

Version 1.6.3

Date: 6 March 2023

Fixed misleading error message when starting/stopping ECS tasks.
Fixed a bug when the Attini runner would cold start twice during the first deployment of a distribution.

Version 1.6.2

Date: 2 March 2023

Updated the default runner image to include the latest Attini CLI.
The AttiniCdk step will now use the --all option for the deploy command unless stacks are specified.
SQS message retention is now set to 12 hours instead of the default 4 days.
Attini actions minimum access policy has been given the ecs:StopTask permission.

Version 1.6.1

Date: 20 February 2023

Added RoleArn to the AttiniCdk step.
The runner will print the CloudWatch log url if the startup commands fail.
Fixed a bug that would sometimes cause the runner to cold start even if the configuration has not changed.

Version 1.6.0

Date: 17 February 2023

AttiniCdk Step was added.
Changed the configuration of the default runner to:
- Use ECS cluster "attini-default".
- "IdleTimeToLive" is now 1 hour.
- It now has 3 GB memory.
- It now has 0.5 CPUs.
"GiveAdminAccess" parameter was added to the Attini setup as a replacement for the deprecated "UseAdministratorAccessForDeployingCloudformation" parameter.

Note

If you have onboarded the Attini framework with the configuration UseAdministratorAccessForDeployingCloudformation=true, you need to set GiveAdminAccess=true next time you update the framework.

This is easily done with the command attini setup --give-admin-access.

Recommended CLI version 1.5.5 or higher

Version 1.5.4

Date: 10 February 2023

Templates no longer need the / prefix
Minor fixes

Version 1.5.3

Date: 31 January 2023

Added support for Asia Pacific (Melbourne) ap-southeast-4
Resource Groups support in Middle East (UAE) me-central-1
Dependencies can now specify specific versions

Version 1.5.2

Date: 26 January 2023

Bug fix. Path in AttiniSam steps no longer need to start with a slash
The manual approval step now has an "abort" option

Version 1.5.0

Date: 17 January 2023

Added support for setting default in the deployment plan payloads output section.
Can now specify a image directly in the Runner definition, eliminating the need to write a TaskDefinition if you want to use your own image.
The init stacks parameters will now be available via the deployment plans payload.

Version 1.4.4

Date: 9 January 2023

Fixed bug in runner resulting from deleting the attini_data folder.

Version 1.4.3

Date: 5 January 2023

The runner will now handle none Json output

Version 1.4.2

Date: 7 December 2022

Added iam:UpdateAssumeRolePolicy and iam:ListRoles permission to the default init role.
Some minor improvements to error handling.

Version 1.4.1

Date: 21 November 2022

Bug fixes and improved performance.

Version 1.4.0

Date: 21 November 2022

Added support for the AttiniSam step.
Added additional validation of the init template to the macro in order to catch deployment plan errors earlier.
The Attini Framework now creates a default ecs cluster with a default Attini Runner configured. This runner is in the first release only used for performing AWS SAM package for the AttiniSam steps.
Added support for semantic versioning of distributions.

Version 1.3.33

Date: 26 October 2022

Bug fixes.

Version 1.3.30

Date: 19 October 2022

Added the AttiniManualApproval step. See the AttiniManalApproval for more information.
Parameter values for the init stack can now be imported from the output of distributions declared as dependencies. See the Attini configuration documentation for more information.

Version 1.3.25

Date: 12 October 2022

Bug fixes.

Version 1.3.19

Date: 10 October 2022

Added support for the new improved follow function in the CLI (Require CLI version 2.1.0 or greater).
Will now use attini-runner 1.1.0 if no runner is installed on the ECS task image used.

Version 1.3.10

Date: 20 September 2022

Added the AttiniImport type to the deployment plan.

Version 1.3.3

Date: 2 September 2022

Support for UAE (me-central-1) region

Version 1.3.2

Date: 1 September 2022

Attini Runner is now generally available.
Improved error handling for deployment plan configuration.
Made error messages for invalid configuration more informative.

Version 1.2.79

Date: 22 August 2022

Added support for EnableTermination support for Cloudformation stacks.
Added support for dependencies. A distribution can now be dependent on other distributions.
Improved error handling for Attini runner. The deployment plan will now no longer freeze if the ECS task definition uses a broken image or breaks during startup.
Fixed issues in the basic execution policy for the Attini runner.

Version 1.2.75

Date: 5 August 2022

VPC configuration is now optional for runners. If not specified, the default VPC will be used.
Startup section for runners, these commands will only run when the ECS task is started.
Added a basic execution policy for the Attini runner.
Will now delete all metadata regarding Attini runners if the related init stack is deleted.

Version 1.2.65

Date: 22 June 2022

Will now save additional data about distributions. This is to improve the behavior of the attini context CLI command.
Added permissions to the Attini default roles to make it easier to work with the Attini runner.
Minor fixes to Attini runner start-up logs.

Version 1.2.51

Date: 10 June 2022

The Init deploy stack will now only update if there are changes in the stack or in its input from the attini-config file.
Added the "forceUpdate" option to the attini-config file. If true then the Init deploy stack will always update.

Version 1.2.47

Date: 1 June 2022

Added support for the Attini runner (Beta).
Added support for using S3 URIs when referencing CloudFormation templates in a Attini CFN step.
Fixed bug when the merge step would fail when merging fields if the value from the first branch was null.

Version 1.2.33

Date: 21 April 2022

Variables for configuration files can now be specified in the attini-config file the same way as tags and parameters. This is useful if you want a variable to be globally accessible. It can also be used to set defaults or have predefined different values for different environments.
Improved error reporting for errors in the init stack.

Version 1.2.30

Date: 22 Mars 2022

Enabled real-time error reporting for CLI. Requires CLI version 1.1.5 or greater.
Minor bug fixes.

Version 1.2.19

Date: 1 Mars 2022

Added the "Action" config option. Can be set to "Delete" or "Deploy" depending on if the stack should be deleted or deployed. Default is “Deploy”.
Added the AttiniLambdaInvoke step. A convenient way to invoke a lambda in a deployment plan while preserving the payload for subsequent steps.

Version 1.2.12

Date: 11 February 2022

Bug fix: The attini-step-guard lambda wrongly logged errors in some scenarios.
Bug fix: Fixed a bug that happened when a deployment plan containing a stack with a transformation was triggered twice. This lead to the deployment plan freezing.

Version 1.2.8

Date: 31 January 2022

Support added for the describe deployment command in the CLI.
Email is no longer required when installing the framework (If installing via the CLI version 1.1.1 is required)
Bug fixes.

Version 1.2.0

Date: 14 January 2022

Note

Requires Attini CLI version 1.1.0 or higher.

Attini will now publish events on the attini-deployment-status SNS topic everytime it deploys a Cloudformation stack.
Events attini-deployment-status now contains message attributes to make it easier to subscribe to specific events, for example if a Cloudformation stack fails.
All events that Attini publishes to the attini-deployment-status SNS topic is now saved to the new AttiniDeploymentEventsV1 DynamoDB table.
Added version to all DynamoDB table names used by Attini.
Changed naming convention of attributes in the AttiniResourceStates table to make it more uniform.
Attini will now delete any resources in DynamoDB belonging to a Cloudformation stack if the stack is deleted, even if the stack is deleted manually.
Bug fixes.

Version 1.1.2

Date: 22 December 2021

Removed old cfnOutput payload (replaced with output). This means that users can no longer read stack outputs from the cfnOutput payload and user will have to switch to reading from the output payload.
Added support for getting parameters and tags from SSM Parameter store.
Fixed bug with recursive config inheritance (if a configuration file extended itself).
Variable substitution will now work on all configurations, including extension paths.
Added support for Asia Pacific (Jakarta) ap-southeast-3 region.

Version 1.0.37

Date: 30 November 2021

Email option is now required for attini setup when installing Attini for the first time.
Added improved monitoring capability’s.

Version 1.0.30

Date: 23 November 2021

Added new “output” section to the deployment plan payload. This will replace the cfnOutput and cfnGlobalOutput section.

Version 1.0.13

Date: 16 November 2021

Note

This change will not break any of your current deployments but next time you update attini-setup CloudFormation stack you will need to apply new configuration.

Attini core functionality.
Added support for Attini license agreement acceptance and license token.
Added support for Attini resource allocation (AWS Lambda reserved concurrency).
Bug fixes.
Changed names on some attini-setup parameters.

Version 0.0.455

Date: 8 November 2021

Attini core functionality.
Added support for Attini license agreement acceptance.
Bug fixes.

Common Issues

Attini CLI

Text ‘date’ could not be parsed at index 19

I get the error Text '2021-05-04T18:35:49UTC' could not be parsed at index 19 when using the CLI with AWS SSO credentials.

If you authenticate with an old version AWS CLI version, this error occurs. Please update the AWS CLI.

For more information about this issue, see aws-sdk-java-v2/issues/2190.

Updating the Attini CLI doesn’t work

If you update the Attini CLI and the installation looks ok, but it takes no effect, it’s probably because you have 2 Attini CLI installed and the “old” installation is located before your “new” installation on your system PATH.

Run the command: type attini

And verify that the Attini CLI path is actually the one you updated.

“bad CPU type in executable: attini” on Mac with Apple silicon processor

The Attini CLI is currently only compiled for x86_64 CPU architecture for Mac, so you need Rosetta 2 for it to work.

You can install Rosetta using the command:

/usr/sbin/softwareupdate --install-rosetta --agree-to-license

Note: The first time you run the Attini CLI after the Rosetta installation, it will take a few extra seconds.

(zsh) Attini CLI broke after I updated it

If you get the error zsh: killed on all the Attini CLI commands after an update, you have to delete the Attini CLI and reinstall it. See the rm ${PATH_TO_CLI}/attini; part of the installation Attini CLI command.

Getting error “sh: syntax error near unexpected token `('" when turning on cli autocomplete

If you are trying to enable Attini CLI autocomplete via source <(attini generate-completion) command and it fails like this:

sh: syntax error near unexpected token ('`

Run this command instead:

attini generate-completion > /tmp/attini-generate-completion; source /tmp/attini-generate-completion; rm -f /tmp/attini-generate-completion

(bash) Attini CLI autocompletion does not work

If the autocompletion for the CLI does not work, make sure you are not running an old version of bash. Attini autocompletion required bash version 4 or later. To update bash on a Mac with homebrew run brew install bash.

Deployment plan

Deployment plan froze

A frozen deployment plan is a consequence of the Attini resources or AWS Service integrations not responding to the underlying AWS StepFunction. This can be due to issues (for example, throttling) with some underlying services, like AWS Lambda or Amazon SNS.

If you have a frozen deployment plan, you should retry your deployment. The Attini framework will always cancel the old deployments before starting a new one, so there is no risk for zombie deployments.

Importing an old CloudFormation stack into a deployment plan

If you have an old CloudFormation stack that you include in an Attini deployment plan and the first update of that CloudFormation stack fails, the Attini deployment will freeze. The workaround is to not do any updates to the CloudFormation stack on the first run, that way the CloudFormation stack will not fail.

Invalid State Machine Definition: SCHEMA_VALIDATION_FAILED

Error message:

Resource handler returned message: "Invalid State Machine Definition: SCHEMA_VALIDATION_FAILED:
The field Type should have one of these values: [Task, Wait, Pass, Succeed, Fail, Choice, Parallel, Map] at

This issue can happen in 3 common scenarios:

You have configured a standard StepFunction step in your deployment plan and have not configured “Type” correctly.
You have misspelled an Attini type so that the AttiniDeploymentPlan Transform did not convert your deployment plan into a valid state language.
You are running on an old version of the Attini Framework, which might not support the type your trying to use.

Glossary

Attini Project

Attini Project is a folder (ex a git repository) that contain a attini-config file . This file includes the configuration that the Attini CLI and the Attini Framework need to package and deploy your distribution.

Attini Deployment Origin

Attini deployment origin is an S3 bucket that will be created by . It is is responsible for receiving distributions and trigger the init deploy lambda. The s3 bucket will be called attini-deployment-origin-${region}-${accountId}, and you will find it in your AWS account after you onboard the attini-setup.

There will be one Attini deployment origin bucket per AWS account and region.

The artifacts will be deleted according to your artifact life-cycle policy.

Attini Artifact Store

An S3 bucket that will be created by attini-setup that is responsible for managing all the artifacts from your distribution and making them available to your environment. The S3 bucket will be called attini-artifact-store-${region}-${accountId}, and you will find it in your AWS account after you onboard the attini-setup. If your deployment needs temporary storage, you can use the Attini artifact store with key prefix attini/tmp/. Find more info here

There will be one attini artifact store bucket per AWS account and region.

All the artifacts from a distribution will be uploaded to the bucket with the prefix /${AttiniEnvironmentName}/${DistributionName}/${DistributionNameId}/distribution-origin/

The artifacts will be deleted according to your artifact life-cycle policy.

Distribution

Is a zip file containing any files your deployment needs. The distribution should also contain certain configuration that enables the Attini Framework to start a deployment. See more information about distribution configuration here.

Deployment

When a distribution is being uploaded to an Attini Deployment Origin Bucket, it triggers a deployment which tells the Attini Framework to start. The Attini Framework will:

Extract the files in the distribution and put them in the Attini Artifact Store so that the files become available to the Environment.
Deploy the Init deploy stack, which created the deployment plan.
Attini Framework will run the deployment plan after the Init deploy is successful.

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 the distribution. Because it’s a CloudFormation stack, you can provision any resources you need for the deployment. The Init deploy stack creates the Attini deployment plan, and it is configured by the here.

Attini Deployment Plan

The deployment pipeline, created (and updated) by the the Init deploy stack The Attini deployment plan is defined as CloudFormation/CDK resources in the Init deploy. It can deploy CloudFormation stacks, trigger AWS lambdas, run containers which can run terraform, kubectl, AWS CDK, or AWS SAM and anything else you might need. The Attini deployment plan is based on AWS Step Functions and can therefore use all the services integrations that AWS Step Functions offers.

Attini Config File

The attini-config file is always located in the root folder of your distribution. The file can be called attini-config.json, attini-config.yaml or attini-config.yml and it contains the distribution name, id, package config, tags and Init deploy configuration and more.

Knowledge Bank

Subsections of Knowledge Bank

Attini Way of Working

Environment isolationq

Advantages

Stateful distributions

Managing multiple environments

The Attini deployment plan

Attini in your workflow

Getting started

Central Repository for Attini Distributions

Description

Prerequisites

Create the S3 Bucket

Example bucket CloudFormation template

Configure your Git Repository

Configure access to the S3 bucket

IAM Role (recommend)

IAM User (old way)

Configure the Attini distribution

Configure the GitHub action

Deploy the Attini distribution from the repository

Change Log

Subsections of Change Log

Attini CLI

Version 2.5.8

Version 2.5.7

Version 2.5.6

Version 2.5.5

Version 2.5.4

Version 2.5.3

Version 2.5.2

Version 2.5.1

Version 2.5.0

Version 2.4.4

Version 2.4.2

Version 2.4.1

Version 2.4.0

Version 2.3.0

Version 2.2.2

Version 2.2.1

Version 2.1.1

Version 2.1.0

Version 2.0.0

Version 1.2.1

Version 1.2.0

Version 1.1.13

Version 1.1.12

Version 1.1.11

Version 1.1.10

Version 1.1.9

Version 1.1.8

Version 1.1.7

Version 1.1.6

Version 1.1.5

Version 1.1.4

Version 1.1.3

Version 1.1.2

Version 1.1.1

Version 1.1.0

Version 1.0.7

Version 1.0.6

Version 1.0.5

Version 1.0.4

Version 1.0.3

Attini Framework

Version 1.7.0

Version 1.6.3

Version 1.6.2

Version 1.6.1

Version 1.6.0

Version 1.5.4

Version 1.5.3

Version 1.5.2

Version 1.5.0

Version 1.4.4

Version 1.4.3

Version 1.4.2

Version 1.4.1

Version 1.4.0