First configuration and execution

In this episode we will prepare our Spacelift account and we will look around the console.

Before we start

Before we start playing with Spacelift, we should create new repository (I called mine spacelift-demo) and put there two files.

• providers.txt which is exactly the same like in first episode of this series
• main.tf with this content:

provider "aws" {
  assume_role_with_web_identity {
    role_arn                = "arn:aws:iam::1234567890:role/spacelift-role"
    web_identity_token_file = "/mnt/workspace/spacelift.oidc"
  }

  default_tags {
    tags = {
      Environment = "Sandbox"
      Terraform   = "True"
      Repo        = "spacelift-prep"
      Project     = "Spacelift tutorial"
    }
  }
}

resource "aws_s3_bucket" "mybucket" {
  bucket = thisismytestbucketforspacelift
}

Simple stuff, we create one AWS S3 Bucket only.

Please remember, S3 Bucket name must be globally unique!

We configured the IAM Role which we want to use. Of course, again, it is hardcoded, what is not a good practice, but enough for the demo purposes.

And we need to commit this to main branch.

Finally we can go forward

After the login we can see the menu on the left side:

This menu should give us a glimpse of idea what Spacelift really is. As it is stated on the webpage

Spacelift is a sophisticated CI/CD platform for Terraform, CloudFormation, Pulumi, Kubernetes, and Ansible

Spacelift is a CI/CD tool. But is it only it? What we will explore is if Spacelift is more like an orchestrator for IaC.

So, let's get started!

First position in the menu is Stacks. Stacks are main entity of the projects. Stack uses repository of the code and manages the resources and states.

Let's create our first stack. Click Add stack button on top right side of the screen. It seems hidden a little bit, I think that can be improved :)

On the first screen we define basic information. Name of the stack, space (we will learn it more later), description, etc.

Ok, done, let's click continue.

And here we can be hit by some unexpected thing. Or should I say - expected? :) We need to provide the repository. And we can't just refresh the page if we create one now. That is exactly why we created the repo earlier. It wil be good to have the possibility to refresh the state, or even... create repo from here.

I provided the information like on screen below.

After we click Continue we go to very important, I would say the most important, part of the configuration. We deal with Terraform here, and this part allows us to configure the behavior of Terraform. It is not the place to explain what statefile is, so let me navigate through these fields shortly.

• Backend in our case is Terraform. There are more of them. You may ask why there is no backend for Ansible, as Spacelift claims they can manage it too? Well, Ansible is serverless (oh wow, I just realized that synonym for this case :D), therefore there is no state to manage.
• Smart sanitization - very nice function. Spacelift will try to determine if value is sensitive and should be hidden (useful for variables)
• Version - quite obvious, isn't it?
• Manage state - crucial thing. We can allow Spacelift to care about the statefile.
• Import existing statefile - very cool feature. It means that we can migrate existing resources, or should I say, management of existing resources to Spacelift.

And now we go to the final step of configuration.

Nice thing - we can manage administrative stack. It means we can use Terraform to manage Spacelift! How cool is that? And what was first - chicken or egg? ;)

I set some advanced options too. First, Autodeploy. For this simple repo we don't need any additional actions, let's deploy it directly. Second, I enabled Local preview. This looks like very cool option, we can check the stack with spacectl command locally! We will test it soon.

Finally, we can decide about runners and their images and we can even customize the workflows.

Let's save the stack now.

Nicely done!

Burn the AWS!!

Or maybe not :) We have simple template prepared, so let's trigger it!

Let's click this small button:

And see what happened!

The process is clean and clear.

In case of the screen above you see the report after trigger through commit, however, it doesn't really matter, the info is very similar.

First, I need to say what I do not like. The order. Well, yes, this works, but somehow I prefer to see it in oposite direction. The oldest on top, newest on the bottom. A matter of habbit, I suppose.

We see couple of stages.

• Queued - this is the time between trigger and actual start of the execution. Spacelift prepares some resources where our demo is executed.
• Preparing - Actual preparation of the resources mentioned in step above
• Initializing - in case of our demo - initialization of Terraform - terraform init.
• Planning - well, terraform plan :)
• Applying - ... you know, right? :) Do you remember, that we set immediate execution when we setup the stack? That is why apply was executed immediately after plan.
• Finished - just info that run is ended.

What was done by our Terraform? We can check it from the level of Spacelift!

Do you see the ADD tab? We can see additionally the +1 note. This means... Yes, we added 1 resource!. When we go to this tab, we will be able too see all actions done by the execution. Sweet.