Jan 23, 2023

ARM private worker pools are here!

Starting today, Enterprise customers can enjoy the benefits of using ARM64-based self-hosted worker pools. You can expect improved performance and cost savings for your workloads as ARM instances are ~20% cheaper on average.

Updates to the worker pool infrastructure

Spacelift AMI

Spacelift AMIs starting from January 2023 got a new "-x86_64" and "-arm64" postfix in their names, respectively.

Launcher download URL

The download URL of the launcher used to be https://downloads.spacelift.io/spacelift-launcher. Now it has two variants:

- https://downloads.spacelift.io/spacelift-launcher-x86_64

- https://downloads.spacelift.io/spacelift-launcher-aarch64

The legacy URL will still get updates but it is recommended to update all worker pools to pull the binary from the proper URL regardless of the CPU architecture. The easiest way to do it is to bump your respective Terraform module to the latest version:

- terraform-aws-spacelift-workerpool-on-ec2@v1.3.0

- terraform-google-spacelift-workerpool@v1.2.0

- terraform-azure-spacelift-workerpool@v0.0.6

Note: In general, we recommend that you periodically recycle your worker pools. This ensures that your workers have the latest OS updates, and the latest copy of the Spacelift launcher binary, which is downloaded during instance startup.

AWS Terraform worker pool module

We've released terraform-aws-spacelift-workerpool-on-ec2@v1.3.0 Terraform module with two major updates:

- it now downloads the launcher binary from the architecture-specific URL

- we've switched from using Launch Configurations to Launch Templates

We've made the switch from Launch Configurations to Launch Templates because Launch Configurations are being deprecated by AWS.

Switching from amd64 to arm64

If you're using the terraform-aws-spacelift-workerpool-on-ec2 module to deploy the worker pool it is just a matter of updating the module version to v1.3.0 and updating ec2_instance_type and ami_id parameter.

data "aws_ami" "this" {
  most_recent = true
  name_regex  = "^spacelift-\\d{10}-arm64$"
  owners      = ["643313122712"]
  filter {
    name   = "root-device-type"
    values = ["ebs"]
  }
  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
  filter {
    name   = "architecture"
    values = ["arm64"]
  }
}

module "workerpool" {
  source = "github.com/spacelift-io/terraform-aws-spacelift-workerpool-on-ec2?ref=v1.3.0"

  ami_id            = data.aws_ami.this.id
  ec2_instance_type = "t4g.micro"
  # Further configuration is redacted for clarity
}

After the change is applied, the instance type will be swapped in the Auto Scaling Group. At this point, you need to drain all of the instances (click the Worker pools tab on the Spacelift UI, choose the appropriate worker pool and click on Drain button on all instances), then terminate them manually in AWS. The Auto Scaling Group will automatically start the arm64 instances.

A full example can be found here.

Runner image compatibility

All Spacelift runner images are ARM compatible. If you use custom runner images, you need to make sure they have an arm64 variant available. Easiest way to check it is using docker manifest inspect command. E.g:

docker manifest inspect public.ecr.aws/spacelift/runner-terraform:latest

Limitations

As of today we only provide ARM AMIs on AWS. ARM is still in Beta on Azure. Similarly Google Cloud Platform doesn't have ARM machines in all supported regions.

New