Spring Boot StackPath Terraform
Published: 2022-10-25 22:52:00

---
title: Spring Boot StackPath Terraform
published: true
date: 2022-10-25 16:19:03 UTC
tags: 
canonical_url: https://dashaun.com/posts/spring-boot-stackpath-terraform/
cover_image: https://dashaun.com/posts/spring-boot-stackpath-terraform/validate.png
---

This is another article based on recent [Spring Office Hours](https://bit.ly/spring-office-hours) sessions. Spring Boot provides several effective ways to deliver applications, to production, efficiently. There are many situations where one of the `hyperscale` cloud providers is not an option, or the best choice.

[Previously, I looked at Kamatera.](https://dashaun.com/posts/spring-boot-kamatera-terraform/)This time, I’m going to use [StackPath](https://stackpath.com).

[I did the work during a live stream, so you can see exactly how easy and exciting this was.](https://youtu.be/kWVv0U1Bvq0)

## Initial Thoughts 

I figured that going down this path would get easier with each provider. So far that has been true. I’m learning more about Terraform and getting more comfortable. I’m able to map the different concepts and building blocks a little easier with each rep.

## Getting an account 

As you would expect, nothing out of the ordinary when trying to setup an account. I couldn’t find a free tier or discount code, but I didn’t look very hard.[Reach out to me](https://dashaun.com) if you know of something that I can share. Billing info is required.

## Stackpath Terraform Provider 

Having a Terraform Provider is what I have set as the bare minimum for this exercise. The [StackPath Provider](https://registry.terraform.io/providers/stackpath/stackpath/latest/docs) was surprising. I consider myself a slightly above average Terraform user. I have never experienced this as the `default` behavior for a `Provider` and I am impressed.

The provider only required three arguments for configuration. I decided to use the environment variable approach rather than passing in variables.

```
STACKPATH_STACK_ID
STACKPATH_CLIENT_ID
STACKPATH_CLIENT_SECRET

```

For the `STACKPATH_STACK_ID` I used the `stack slug` from the `DASHBOARD`. I created the `STACKPATH_CLIENT_ID` and `STACKPATH_CLIENT_SECRET` from the `API ACCESS` option of the dashboard.

When I ran the `terraform plan` and `terraform apply` they were so fast I thought it was broken. I had guessed at the value to use for `STACKPATH_STACK_ID` and figured that I must be doing something wrong. Nope. Their platform API defaults to an `async` behavior that doesn’t wait for object creation to be completed. Instead, your actions complete, and you can run `terraform refresh` to get the status of its creation.

I’ve used other `Providers` that provide this as an option. In this case, while I was learning and iterating frequently, it felt amazing.

{% embed https://asciinema.org/a/JqexvsUYphyGVpSuEOADpfbnM?autoplay=1&startAt=03 %}

To check on the status I used `terraform refresh` and in this mode, it felt like the right way to do things.

{% embed https://asciinema.org/a/jUlDDHoeox4SXBpfFHzPPPD37?autoplay=1 %}

Accessing the service felt snappy.

{% embed https://asciinema.org/a/LHmJDSfJXSG9WTRDOXoYtDBc9?autoplay=1&startAt=2 %}

Cleaning up, was just as fast, so iterating through the struggles was relatively painless.

{% embed https://asciinema.org/a/dK1ARCkLHZNp2UQaPozfFgNo0 %}

## Struggle 

I spent a bunch of time not realizing that I needed the `stackpath_compute_network_policy` to allow public traffic. On this platform, ports are not exposed to the public by default. Even though I struggled, this made me feel a little more secure. Simply because I am forced to be specific about what I’m allowing. Additionally, the container doesn’t have remote access enabled by default.

## Differences 

Deploying a VM that can run Docker is one thing. Deploying a `container` to a `platform` is a different pattern. While I was wondering through the documentation, I was very interested. There are some very advanced and mature capabilities available. This is clearly a platform that is designed to support short-lived and very dynamic workloads.

## Summary 

I only scratched the service here, but it worked, and it worked quickly. There are some very interesting architectures that can be accomplished with `StackPath` and I’m excited to go further. I didn’t know what to expect on this journey. I can say that `StackPath` his raised the bar for my expectations going forward.

## Your Turn 

Take the [repository](https://github.com/dashaun/spring-boot-stackpath-terraform) for a spin and try it out for yourself. Let me know what you think.

## Links 

- [https://github.com/dashaun/spring-boot-stackpath-terraform](https://github.com/dashaun/spring-boot-stackpath-terraform)
- [YouTube Video](https://youtu.be/kWVv0U1Bvq0)
- [Javagrunt on Twitch](https://twitch.tv/javagrunt)