Attini Runner

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.
• It can run within a private network so that it can integrate with private services and databases.

Architecture

When an AttiniRunnerJob step 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 add a message to the Runner’s SQS queue with the AttiniRunnerJob commands, the deployment plan payload, and some other required information.
3. If it is the first job in the deployment plan execution, the Attini Runner will download your attini distribution from the Attini artifact store.
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

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 in the same instance. How many jobs the Attini Runner will execute simultaneously is configured in the Runner configuration. If the number of parallel jobs exceeds the configured maximum, the requests (jobs) will remain in the SQS queue until a job has finished executing.

An Attini Runner can be reused between executions. How long a Runner will stay alive without a job request can be configured in the Runner configuration. If the configuration for the Runner changes, Attini will restart the task with the new configuration.

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

Default Runner

Attini Setup will create resources for a default Runner.

The default will be used for some “out-of-box” automation like the AttiniSam type.

Default runner configuration

The default runner uses the default values from Attini::Deploy::Runner resource.

The following AWS Resources are created by Attini Setup, and they are used for the default runner.

1. Default ECS cluster called attini-default.

2. Default IAM Role for the Runner.

3. CloudWatch log group called /attini/runner/default.

4. An ECS task-definition called attini-default-runner, and it uses the following configuration:

   • The Image comes from attini public ECR repository attini/default-runner.
   • 3 GB RAM
   • 0.5 CPU

EC2 Runner

If Ec2Configuration is configured for the runner, the ECS EC2 Launch type will de used.

Main advantages to using en EC2:

1. It allows for docker builds.
2. EC2 has a lower cost per CPU Core and GB Memory and more infrastructure options, which can be relevant for jobs with special requirements.

Drawbacks of using EC2 runners are:

1. Longer cold stars.
2. Increased complexity.

EC2 Runner configuration

Default docker build configuration

By default, the Attini runner on EC2 will be using a Docker-out-of-Docker (DooD) configuration, find more information on this subject in this Docker-in-Docker in docker blog.

This means that the Attini runner container will mount the host’s Docker’s socket. The Attini runner container can and then use the docker CLI to interact with the docker daemon on the EC2 Host.

The drawbacks of DooD configuration are usually not relevant to the Attini runner because:

1. The EC2 host is not shared with other containers.
2. The Attini runner or the EC2 host usually does not need a port mapping because it should have no incoming traffic.
3. Mount points are only relevant when you run a container, and the Attini runner should be used to build containers.

If this method doesn’t work for your use-case, you can provide your own ECS TaskDefinitionArn with privileged mode enabled to run Docker-in-Docker (DinD) or have a look at the nestybox project.

EC2 host management and troubleshooting

The EC2 host will be stared and terminated automatically by Attini and the AWS IAM permissions to do this are included in the runners least privilege policy arn:aws:iam::{AWS::AccountId}:policy/attini-runner-basic-execution-policy-{AWS::Region}. If the IAM role for the runners does not have this policy, there is a risk for zombie EC2s.

The EC2 host should have the AWS SSM agent enabled so you can connect to the instance using AWS Systems Manager Session Manager. If its not working, make sure the IAM role used by the InstanceProfile has the manged policy AmazonSSMManagedInstanceCore attached. If you have any issues, you can connect to the host and investigate it.

The ECS agent logs will be sent to a CloudWatch log group with a 90-days retention period. You can find the CloudWatch log group your Init deploy stack with the logical name {RunnerName}EcsClientLogGroup.