Driving GorillaStack configuration through Terraform
We have spent some time building a Terraform provider for GorillaStack. We’ll explore the “what” and “why” in some FAQs below, and will follow up with some technical blog posts around the “how” a little later.
What is a Terraform Provider?
A Terraform Provider is an implementation of mappings between Terraform templates and API calls for resource creation, updates, reads and deletes.
Essentially, just like a talented DevOps engineer could create AWS resources from Terraform templates, she can now create GorillaStack resources from Terraform templates too.
Why did you do this?
Since making our API generally available, our customers have been asking us to simplify the process of working with it. In all the requests to provide Postman collections or sample code, we observed that customers don‘t want to write boilerplate code to generate API requests for all parts of the management of the lifecycle of GorillaStack resources.
This is a lot easier with our Terraform provider. Define the Tag Groups and Rules in a template and manage all resource lifecycle management through Terraform. Goodbye boilerplate.
Best of all, all your changes can be version controlled in a repository!
Do I need to use this, or change how I work with GorillaStack?
No, this is completely optional. If you have been bothered by repetition in managing resources through our user interface or API, this could be a good option for you. If not, keep doing your thing.
How do I get started?
Just like other community Terraform providers, you will need to install GorillaStack by installing our provider as a go module.
go get -d github.com/gorillastack/terraform-provider-gorillastack cd $GOPATH/src/github.com/gorillastack/terraform-provider-gorillastack make
Head to our Github repository and follow the instructions on how to get started.
We love feedback. That is the exact reason why we did this piece of work. If you have feedback on the Terraform provider, our products, our blog posts or just want to share your thoughts on the nuanced art-form (sounds better than un-exact science) that is DevOps, we want to hear from you.
Please join our budding Slack community and join in the conversation.