Spring Boot StackPath Terraform
An exciting Terraform experience for your Spring Boot apps
This is another article based on recent 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. This time, I'm going to use StackPath.
I did the work during a live stream, so you can see exactly how easy and exciting this was.
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 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 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.
To check on the status I used terraform refresh
and in this mode, it felt like the right way to do things.
Accessing the service felt snappy.
Cleaning up, was just as fast, so iterating through the struggles was relatively painless.
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 for a spin and try it out for yourself. Let me know what you think.