Docker-based Workers»
Spacelift Docker-based workers consist of two main components: the launcher binary, and the worker binary. The launcher is responsible for downloading the correct version of the worker binary to be able to execute Spacelift runs, and for starting new Docker containers in response to those runs being scheduled.
The launcher is distributed as a statically-linked Go binary, which can be downloaded using the following links:
In order to work, the launcher expects to be able to write to the local Docker socket. Unless you're using a Docker-based container scheduler like Kubernetes or ECS, please make sure that Docker is installed and running.
Finally, you can run the launcher binary by setting two environment variables:
SPACELIFT_TOKEN- the token you’ve received from Spacelift on worker pool creation.SPACELIFT_POOL_PRIVATE_KEY- the contents of the private key file you generated, in base64.
Info
You need to encode the entire private key using base-64, making it a single line of text. The simplest approach is to just run cat spacelift.key | base64 -w 0 in your command line. For Mac users, the command is cat spacelift.key | base64 -b 0.
Congrats! Your launcher should now connect to the Spacelift backend and start handling runs.
Tip
In general, arm64-based virtual machines are cheaper than amd64-based ones, so if your cloud provider supports them, we recommend using them. If you choose to do so, and you're using custom runner images, make sure they're compatible with ARM64. All Spacelift provided runner images are compatible with both CPU architectures.
Periodic updates»
Our worker infrastructure consists of two binaries: launcher and worker. The latest version of the launcher binary is downloaded during the instance startup. The launcher then establishes a connection with the Spacelift backend and waits for messages. When it gets a message, it downloads the latest version of the worker binary and executes it. The worker binary is responsible for running the actual Spacelift runs.
This setup ensures that the worker binary is always up to date, but the launcher may not be. Typically, the worker binaries receive more updates but it's still recommended to recycle the worker pool every once in a while to ensure that the launcher is up to date. The simplest way to do this is via the Cycle option on the worker pool page:
Additionally, if you use Spacelift AMIs, they receive routine system updates every few weeks so it's worth bumping the AMI to the latest version from time to time. That automatically takes care of downloading fresh launcher binaries as well.
Terraform Modules and Helm Chart»
For AWS, Azure and GCP users we've prepared an easy way to run Spacelift worker pools. This repository contains the code for Spacelift's base images, and the following repositories contain Terraform modules to customize and deploy worker pools to AWS, Azure or GCP:
- AWS: terraform-aws-spacelift-workerpool-on-ec2.
- Azure: terraform-azure-spacelift-workerpool.
- GCP: terraform-google-spacelift-workerpool.
Info
AWS ECS is supported when using the EC2 launch type but Spacelift does not currently provide a Terraform module for this setup.