geek pro tem

Spacelift - Bootstrap Example

Mar 14, 2023 - 5 minute read

In this article I’m going to show how to setup your new Spacelift account. I’ll be approaching this from the perspective of someone that:

  • will use it for personal use
  • will use github to store the code
  • uses AWS as the cloud provider

Spacelift is flexible, though, and while those are the boundaries I use the tool within, this will hopefully be useful to others.

A note on the personal use caveat - when you start your Spacelift account, you’ll have access to all the enterprise level features. This includes cloud integrations where you’ll be able to use a role assignment instead of credentials to manage your infrastructure. As I discovered, though, once your trial is up and you shift down to the free tier, all those integrations will break and it can be difficult to backpedal. With that in mind, this article will assume you’ll want to use credentials at some point.

Create your Spacelift Account from Github

When you signup for Spacelift, you can choose the SSO provider to use. I chose Github as that’s the integration I’d want anyway. When you do this, you’ll be able to setup the application within Github to have access to the repositories you plan to use.

Create your Management Stack Repository

Spacelift has a pretty nice Terraform provider that can be used to automate most of what you’ll be doing. I use that provider to build a management stack where I can control all the modules, spaces, stacks, contexts, integrations, etc I need.

Here is a repository of code that will allow you to define things in Terraform variables files and manage Spacelift without clicking around.

This approach assumes that you’ll have projects in other repositories that will, in turn, define their own stacks. Here is an example.

Prepare your AWS Account

As mentioned above, you’ll likely want to setup some credentials and/or a role for Spacelift to use. I’m going to assume that the reader knows enough about AWS to be able to create an IAM role or user and assign the permissions needed. I used the AWS provided AdministratorAccess policy given the breadth of what I will want Spacelift to actually do.

If you use a role, make note of the ARN for that role. If you use a user, make sure to generate some API access keys and copy those down somewhere safe for now.

Configure Spacelift

So now you’re almost ready to do stuff! Only a couple of things to do in the Spacelift UI.

Create the AWS Credential Context (if not using a role - needed for free accounts!)

You’ll need to do this if you plan on using the free tier.

Create a new context in the Spacelift UI in the root space. Name it whatever you like, but if using the code provided above it needs to have the aws_credentials label.

Create The Root Management Stack

Now create a new stack. This stack should reference the repository where you have your management module such as my example one, and it will need to have the context you created attached. It will need to be administrative, as well. You can make it autodeploy as well so that it will pick up changes automatically in the future.

Once that stack is created, you should be able to trigger it.

Using your Spacelift

So while the above management module will create things for you, you’ll still use the Spacelift UI to do things like trigger builds, run tasks, etc.

Modules

When you build a new module, you’ll need to add it to the management stack’s variables.modules.auto.tfvars file. Once you do that, you’ll need to confirm the management stack (if it isn’t set to autodeploy). Then you’ll see the module show up in the UI, but you’ll need to trigger it if hasn’t built, yet. After that first run, it should update automatically in the future.

Stacks

If you don’t have autodeploy turns on for your stacks, then you’ll need to go into the UI upon each change and confirm the changes. I usually have that enabled for my non-production stacks so I can quickly test, but the common and production resources require a manual confirmation step.

Destruction

If you decide you want to remove any projects, there are some additional manual steps.

First, you’ll need to identify all the AWS stacks you want to remove, and run a task for terraform apply -destroy -auto-approve in each one. Do this in the opposite order they were created in. As usualy, if you have things like S3 buckets where you don’t have force_destroy set, you’ll need to clean those up by hand, too.

Once all the AWS managed resources are destroyed, you can simply remove the project from your management stack configuration and it should clean up for you.

Summary

The above will leave you with a Spacelift account that is mostly automated and should allow you to easily build and maintain your infrastructure.

While my process is still in flux, there is one item that bothers me - that credential context. I’d much prefer Spacelift allow cloud integrations on their free plans so that I don’t have to place my credentials in their system at all. It isn’t that I don’t trust the credentials, but it seems like encouraging a poor practice like this would be something they’d want to avoid. Their role-based integration is really slick, and I’ve left the nuggets in the example code provided above that should allow one to easily use a role ARN instead of the credential context if/when that makes sense.