Golang SDK for terraspace

Terraspace
#1

Hi Team,

I wanted to check if we have any Golang SDK for terraspace ? Just like how we have for terraform and terragrunt, I’d like to know if we have any SDK for terraspace ? especially in GoLang

Or any other alternative to interact with terraspace programatically ? instead of CLI.

#2

There is no terraspace golang sdk. Current options:

  • Shelling out to the CLI from within golang. It’s not ideal, but at least possible.
  • Ruby SDK - Of course can interface with terraspace with Ruby since terraspace is written in Ruby. The rspec-terraspace library actual does this.

Wanted to at least answer the question.

#3

Hi @tung Thanks for your response. I guess I now need to learn ruby to interact with terraspace programatically, but thats something i have to do eventually anyways.

I also had one more query.

As far as i read the docs, we have env specific tfvars for each stack and we run TS_ENV=dev terraspace up demo for dev and TS_ENV=prod terraspace up demo for prod. so my question is how can do both these at the same time ? like i wanna deploy some stack in dev and prod in parallel. is there a way to achieve this ? something like TS_ENV=dev,prod,stage terraspace up demo which deploys the demo stack in all three envs (dev/prod/stage) , in parallel and not sequential.

Highly appreciate any sort of pointers on this. Thanks.

#4

RE: TS_ENV=dev,prod,stage terraspace up

It is not possible to deploy dev and prod in parallel on the same machine without issues. They need to be run in separate discrete commands in serial.

Some notes for context:

  • The TS_ENV gets set in terraspace super early in the boot process. Experimented with switching it later afterward, and it was pretty complex. The TS_ENV value gets memoized by different libraries: terraspace core itself and terraspace_plugins_* It’s a racket.
  • Terraspace also builds and writes files to the filesystem. As a part of normal terraspace build or terraspace up, the .terraspace-cache folder gets cleaned up, so previous artifacts don’t “reappear” and mess up the terraform apply. When running multiple commands in parallel, the clean-up step interferes with the parallelization. The terraspace all command selectively disables clean-up for each batch to avoid issues. It was tricky to implement.
  • Been thinking in the future, will update Terraspace Cloud, so it runs Terraspace remotely. A remote runner would remove the filesystem collision issues with parallelization since terraspace is running on fresh remote machines. This is more similar to how TFC, Spacelift, env0, Scalr work. The 2nd phase of Terraspace Cloud will likely have remote runners. There is no timeline for this.
  • To deploy dev and prod in parallel now, you could run terraspace in your own CI/CD pipeline. CI: Continuous Integration - Terraspace It might not be what you’re looking for. Everyone tends to want different things.
  • Hope that helps, though.