First Pass With Pulumi
|Apr 12, 2022||The Pulumi Verdict So Far|
|Mar 24, 2022||Using Randomization for Pulumi Kubernetes Resources|
|Mar 24, 2022||Remove Pending Operations From Pulumi State|
|Mar 11, 2022||Pulumi Secrets|
|Jan 28, 2022||Pulumi Round 2|
|Aug 10, 2021||First Pass With Pulumi|
Instead of learning a new domain specific language that wraps up cloud provider API’s, this let’s the developer use their preferred programming language, while solving several problems that using the API’s directly don’t solve.
- Ensure the deployment captures a state file of the changes made.
- Workflow around the previews and deployments.
- Easily automated policy checks and tests.
This can be a really useful tool to bring infrastructure code maintainability directly into the the lifecycle of the application.
It’s subjective to those in DevOps whether this would also apply for “Day 0-2” type operations, which are typically less frequently changed resources such as account settings, VPC, and other more static resources.
However, with a team experienced with Go or other tooling, I could see that this would provide a way to have much more programmatic control, loops, and other external libraries used, without resorting to the HCL DSL way of doing resource looping and inputs.
First impression was very positive!
brew install pulumi
pulumi new aws-go
- Entered name of test stack such as
- Copied the VPC snippet from their docs and then plugged in my own tag for naming, which by default wasn’t included.
- Reproduced the example for
pulumi destroyleft the stack in the console for full plan history and auditing. To remove the stack from the web you’d run:
pulumi stack rm dev. This is similar to how terraform cloud workspaces work and gives confidence of easier auditing by default.
- The console experience and browser integration was beautifully done.
pulumi preview --emojiprovided a very clean and succint summary of changes.
pulumi upalso was very clean, and allowed a selection to expand the details as well.
- Browser for stack provides full metadata detail, resource breakdown, audit history, and more.
The Pulumi docs for Azure DevOps were pretty solid! Full detail and walk through. As an experienced PowerShell developer, I was pleasantly suprised by quality PowerShell code that overall was structured well.2
Set some values via yaml easily by:
'pulumi config set --path 'stage' 'dev'which results in:
This is then read via:
Things To Improve
- Missing the benefit of Terraform module registry.
- Pulumi Crosswalk sounds pretty awesome to help with this. However, I wasn’t able to find the equivalent of a “crosswalk module library” to browse so that part might be a future improvement.
This document link: AWS Virtual Private Cloud (VPC) | Pulumi seemed great as a tutorial, but wasn’t clear immediately on how I could use with Go.
I looked at the aws · pkg.go.dev
but didn’t see any equivalent to the documented
awsx package shown from nodejs library.
Finally, found my answer.
I wish this was put as a big disclaimer right up at the top of the crosswalk section to ensure it was very clear.
This feels very similar in style to the AWS SDK which doesn’t allow just string values, but requires pointers to strings and thus wraps up the strings with expressions such as
Subjective, but I noticed boolean values instead of switches, which would slightly simplify the build scripts, but is more of a “nit” than a critical issue. Using if blocks instead of switch might also clean things up, but overall the script was pretty well written, which seems rare in vendor provided PowerShell examples. 👏 ↩︎