Attini runner (Beta)

The Attini runner is a fast, flexible, and cost-efficient way to execute code from a container as a part of your deployment plan

Find detailed implementation details and API information here.

Quick info

  • The Attini runner is executed as an Amazon ECS task.

  • The same task can be reused between different steps and executions without restarting the container.


When a AttiniRunnerJob step in a deployment plan is started (see AttiniRunnerJob deployment plan type) the following will occur:

  1. The Attini framework will check if there is a warm runner with the correct configuration. If not, the Attini framework will start one.

  2. The Attini deployment plan will then add a message to the runner’s SQS queue with the AttiniRunnerJob commands, the deployment plan payload, and some other required information.

  3. If the Attini runner starts for the first time, it will download your attini distribution from the Attini artifact store. It will use the distribution located at S3 attini-artifact-store-${region}-${accountId}/${environment}/${distribution-name}/${distribution-id}/${distribution-name}.zip.

  4. The Attini runner will then:

    • Receive the message from the SQS queue.

    • Create a working directory for the job.

    • Extract the distribution into the working directory.

    • Remove the message from the SQS queue.

    • Run the commands.

    • Report the result to the deployment plan. See runner output for more information.


Warm and cold starts

Starting the ECS Task can take some time and is associated with some risks (hitting service limits, failure to allocate ENIs etc).

To increase development speed, decrease rollback time, and enable parallel jobs, the Attini runner is kept “warm”, much like a Lambda function but with some differences. A Lambda will start a new instance if a new request is received while another is being processed. An Attini runner will instead handle multiple parallel requests by executing them simultaneously on the same instance. How many jobs the runner will execute at the same time can be configured via the runner configuration. If the number of parallel jobs exceed the configured maximum the requests will remain on the SQS queue until a job has finished executing.

A runner can be reused between executions. How long a runner will stay alive without a job request can be configured in the runner configuration. So if the same distribution is deployed in rapid succession then there is no need to start a new container for each execution as long the runner configuration is unchanged. If the configuration for the runner (or the ECS task) changes however then Attini will restart the task with the new configuration.

The same runner can not be used for different distributions. However, the same ECS task definition can be used for different runners.