Pulumi & AWS minimum viable build

20 May 2022 🔖 devops minimum viable build
💬 EN

Thanks to their website & my old notes on provisioning AWS resources with Terraform, I figured out a minimum viable build with Pulumi for creating a resource inside an AWS playground from A Cloud Guru.

CLI tools

First I installed the Pulumi and AWS CLI tools onto my computer and setting up C:\users\my_username\.aws\config to have my A Cloud Guru playground’s credentials stored in a local AWS “profile” nicknamed “acloudguru.”

Files

Then I created the following file structure at C:\example\hellopulumi:

.
├── Pulumi.my-first-stack.yaml
├── Pulumi.yaml
└── Main.yaml

Pulumi.my-first-stack.yaml

config:
  aws:profile: acloudguru
  aws:region: us-east-1
  aws:allowedAccountIds:
    - 123456789 # Actually set to the account ID of my A Cloud Guru AWS playground

There used to be a “pulumi:template: aws-yaml” setting in this file when Pulumi’s CLI tool helped me generate a sample, but taking it out didn’t seem to hurt anything, so it’s not in my “minimum viable build” code.

Pulumi.yaml

name: my-first-pulumi-project
runtime: yaml
description: The description of my first Pulumi project

Main.yaml

resources:
  # Create an AWS resource (S3 Bucket)
  my-bucket:
    type: aws

outputs:
  # Export the name of the bucket
  bucketName: ${my-bucket.id}

_(Not that I actually knew what to write here. I stole it from Pulumi’s built-in samples, which created it in Pulumi.yaml, and then I refactored it into Main.yaml and examples)

Commands

Add an S3 bucket

Then, from within C:\example\hellopulumi, I ran:

pulumi up

And when prompted “Please choose a stack, or create a new one:,” I hit Enter to choose “<create a new stack>” and named it “my-first-stack” to match the filename “Pulumi.my-first-stack.yaml.”

When asked, “Do you want to peform this update?” I arrowed down to yes and hit Enter.

In about 5 seconds, Pulumi told me it was done.

Verify it’s there

Heading over to my ACG playground’s S3 dashboard at https://s3.console.aws.amazon.com/s3/buckets?region=us-east-1, I could see that indeed, suddenly an S3 bucket existed. Neat.

Delete the S3 bucket

I’m sure there are ways to clean up that aren’t quite so “nuclear,” but here’s how I did so: I deleted every last resource in “my-first-stack:”

pulumi destroy -s my-pulumi-username/my-first-pulumi-project/my-first-stack

Verify it’s gone

Back to the ACG playground’s S3 web dashboard. Yup, I’m back to no buckets. Yay. at https://s3.console.aws.amazon.com/s3/buckets?region=us-east-1, I could see that indeed, suddenly an S3 bucket existed. Neat.

Verify AWS account ID allow-listing

Then I changed the only entry in the allowedAccountIds config property to literally be “123456789” rather than an actual AWS account ID from A Cloud Guru and ran pulumi up again, choosing to deploy it into the “my-first-stack” when prompted with arrow keys.

This time, I received the following error, with “987654321” below being a stand-in for what my actual ACG playground AWS account ID was that the configuration parameter of aws:profile: acloudguru intelligently figured out it ought to be trying to add an S3 bucket to:

     Type                 Name                                    Plan       Info
 +   pulumi:pulumi:Stack  my-first-pulumi-project-my-first-stack  create
     └─ aws:s3:Bucket     my-bucket                                          1 error

Diagnostics:
  aws:s3:Bucket (my-bucket):
    error: 1 error occurred:
        * AWS Account ID not allowed: 987654321

Hooray! Not having an AWS account ID in allowedAccountIds does indeed protect me from messing with it!

This will be very helpful for making sure I’m always only mucking about w/ my ACG AWS playgrounds, and never with anything I’m helping someone else on at a professional level.

Finish cleaning up

All done … final command:

pulumi stack rm my-first-stack

Visited https://app.pulumi.com/my-pulumi-username/projects and confirmed there are no projects or stacks.

Lovely.

Next steps

Now that I’ve confirmed A Cloud Guru AWS playgrounds work just fine with both Terraform and Pulumi before my 7-day free trial ran out, I suppose I have to figure out what’s next.

I know I didn’t really use Pulumi the way it’s meant to be used – with a proper programming language so that you can do things really modularly – but I’m not sure I’m even going to need it. I just wanted to know I had it, in case it ever turned out to be useful.

I suppose maybe my next project is seeing what all AWS tools the ACG playground will actually let me play with. It’s too locked down, for example, to play with multi-account tools like AWS Control Tower, but I think that’s to be expected. (Heck, the accounts are probably set up w/ Control Tower or something behind the scenes.)

I think the big thing I want to do is set myself up some sort of ecosystem of Security Groups, EC2 instances, EFS systems, RDS databases, etc. that imitate a big web-and-database application I’m familiar with from work.

Allegedly, there are a lot of “cloud-native” infrastructure management practices it doesn’t lend itself to.

Although the real system is such a big beast that apparently it literally costs thousands of dollars a day to run, I’m hoping I can manage to build a mockup of it that stays well within ACG playground limits while being architecturally equivalent to it.

I’m actually really happy that ACG AWS playgrounds only last a matter of hours – it’ll force me to use Infrastructure As Code tools like Hashicorp Terraform, Ansible, Pulumi, etc. It reminds me of the way Salesforce scratch orgs’ short lifespan keeps me on my toes and forces me to have excellent “new org” configuration code stored into the codebases I write. Learning to write this code against short-lived AWS accounts is going to make sure I don’t get stuck in any “pets” / “fine china” habits and and learn everything I try with a “cattle” / “paper plates” approach.

Of course, some of the scale-related issues from our actual application … like “it takes hours to compile these terabytes of source code after every patch” … or whatever … will be things I’ll have to remember to keep in mind every time I think I’ve figured out something clever. I can’t go showing things off too excitedly just because they work in a system that doesn’t do anything interesting.

But ideally, using my scale model in an ACG playground, I’ll figure out enough about the quirks of the application, and also enough about cloud infrastructure management in general, to be able to come up with a few ideas and scripts that might be able to be used in the actual system so as to:

• make upgrades faster (e.g. via “blue-green deployment”), and
• make disaster-recovery fire drills so fast that they’re easy to slip in during upgrade outage windows.

Wish me luck!

Squeee

Okay, seriously, the more I think about it, I can’t believe how lucky I am that A Cloud Guru playgrounds expire in a matter of hours.

I literally asked work to pay for this saying:

“Maybe if I learn more about infrastructure-as-code tools, I can help figure out how we can further paper-plate-ize some of our fine-china servers.”

Swipe the credit card, and ACG just strolls up, sticks its hand out, and says:

“Nice to meet you. My name is Cloud Playground, but you can call me Chaos Monkey, and I’ll be destroying your monstrously complex ship-in-a-bottle 3 times a day. Look forward to seeing your blueprints.”

GAME ON, I love this.