I’ve recently been working to create and Azure dat platform and chose to build systems with Pulumi. Expect to see more posts about this over the next 6 months and possibly more. It’s a fascinating space as you stumble upon some of Microsoft’s engineering choices. I’m in two minds about several and am surprised how some make it out of the workshop of pain designing how to build services.
This one isn’t to bang on a negative, and how a decision of several years ago by MS makes it easier to do some things.
Set Up
I have a decent laptop, but not some souped-up monster, more an average solid workhorse. That means this isn’t something you need special tools for. I chose python to create all my Pulumi artifacts with as I use it regularly in the data world. While there might have been other benefits to some languages, I’m happy with how it’s gone so far. I’ll discuss some of the issues I’ve encountered in another post.
I created an empty repo with a gitignore and not much else and pulled that to my machine. Then I created a folder in the repo for Azure, we do have a few AWS artifacts, but they’re of a lower priority. I then created various folders ResourceGroups, Networks, Databases, AppServices and so on. Each of those folders is a separate Pulumi project and I’m creating stacks in each
I use Pycharm for developing Python. I then opened the Azure folder as my top level and am now able to move through each folder and edit the various files. Mostly __main__.py as need be. Future work may include additional files to support Automation.
I have WSL2 installed and I am set up with the Azure CLI there, my Linux/Unix history makes that so much better for me than my PowerShell experience. Mind you many times something relatively straightforward in PowerShell has left a sour taste. That means my experiences may have jaded me. I added the Pulumi CLI to WSL
Tips
My hot tip is to use your IDE, PyCharm, etc to write the code and then use WSL to run your Pulumi commands. As a result, your connection will stay active to Azure for days on end and it’s a simple command-line and venv is so smooth in WSL. It’s easy to change folders, and then run commands to use all your available well-known Linux tools. That can make it easier to diagnose issues.
I’ve created simple scripts to run each time I start a project. They are to load the relevant config values for creating variables that change between development and production. A simple set of the config commands used to load them
Enjoy working with o build systems with Pulumi , it does have a few rough edges and places for improvement, but the overall experience can be wildly good.
Good Luck
See ya ’round
Peter
