Code is Life

Remember when you were a kid and tried to build the ultimate LEGO castle? You had all these cool pieces, but figuring out how they fit together was the real challenge. Well, welcome to the grown-up version: building your serverless cloud playground! Let’s take a bird’s-eye view of our LEGO set… err, I mean, our solution components.

The Grand Blueprint: Components Overview

Imagine you’re an architect (the cool kind that builds things, not the one arguing about font sizes in UI design). Here’s your blueprint for the ultimate cloud playground:

1. The Git Repository: Your Building Plans
   • This is where your Infrastructure as Code (IaC) lives.
2. GitLab Pipeline: Your Automated Assembly Line
   • This defines how to take your code from your repository and turn it into the desired infrastructure with a series of jobs, scripts and contains the definition of the steps you need to take to create your infrastructure.
3. GitLab Runner: Your Tireless Robot Worker
   • This is the engine that powers your pipeline. It is the compute that actually executes the jobs and scripts defined in the pipeline.
4. GitLab Managed HTTP Backend: Your Secret Vault
   • This is where Terraform stores its state files. 
5. OIDC Integration: Your Magical Keymaster
   • This is how we securely assume AWS roles. It’s like having a magical key that changes every hour, so even if the bad guys get it, it’ll turn into a pumpkin before they can use it.
6. Multiple State Files: Your Parallel Universes
   • Each environment gets its own state file. It’s like having multiple parallel universes, each with its own copy of your infrastructure.

How These LEGO Pieces Fit Together

Now, let’s see how this Rube Goldberg machine… err, sophisticated system works:

1. You, the brilliant developer, push your IaC changes to the Git repo.
2. This triggers the GitLab Pipeline, our automated assembly line. It’s ready to build your cloud infrastructure!!
3. The GitLab Runner, our tireless robot, springs into action.
4. The Runner uses OIDC to assume an AWS role and gains the power to deploy your infrastructure. 
5. With its new AWS superpowers, the Runner can now deploy your infrastructure using Terraform.
6. Terraform uses the GitLab Managed HTTP Backend to store and retrieve state files.
7. Because we have multiple state files, we can deploy multiple copies of the infrastructure. 

This whole process allows you to have your own sandbox to play in, without stepping on anyone else’s toes. 

The Magic of OIDC: Your Secure Passport to AWS

Let’s take a closer look at our magical keymaster, OIDC. In our solution, we’re using it to securely assume AWS roles. Here’s how it works:

1. When our GitLab Runner needs to access AWS, it doesn’t use long-lived credentials. Instead, it gets a short-lived OIDC token from GitLab.
2. This token is like a VIP pass that AWS trusts. When presented with this token, AWS says, “Ah, you’re with GitLab? Come right in!”
3. AWS then provides temporary credentials to the Runner. These credentials are like a backstage pass that expires after a short time.
4. The Runner can now use these temporary credentials to deploy our infrastructure, all without any long-lived secrets being stored or transmitted.

Multiple State Files: Your Infrastructure Multiverse

Now, let’s talk about those parallel universes we mentioned earlier. In our solution, we’re using multiple Terraform state files, one for each environment. 

1. Isolation: Each environment (sandbox, pre-prod, production) has its own state file. It’s like each universe has its own history book.
2. Concurrent Development: Multiple developers can work on different environments without stepping on each other’s toes. 
3. Easier Promotions: When it’s time to move changes from one environment to another, we simply deploy the delta between the environments and terraform is really good at that.
4. Reduced Blast Radius: If something goes wrong in one environment (oops, did someone just delete the internet?), it doesn’t affect the others.

Wrapping Up Our Blueprint

So there you have it, folks! Your blueprint for building the ultimate cloud playground. With these components working together, you’ll be able to develop, test, and deploy your serverless applications faster than you can say “Infrastructure as Code.”

In our next post, we’ll dive deeper into how we set up and manage these parallel universe state files with Terraform. It’s like juggling, but instead of balls, you’re juggling entire cloud environments. Stay tuned!

Remember, in the world of serverless development, the cloud is your playground. So go forth and build some awesome sandcastles… just don’t forget your OIDC sunscreen!