- #PESTER CONTINUALLY HOW TO#
- #PESTER CONTINUALLY INSTALL#
- #PESTER CONTINUALLY UPDATE#
- #PESTER CONTINUALLY DOWNLOAD#
POST the results to Azure DevOps (via pipeline tasks). Clear all Azure credentials from the running machine. #PESTER CONTINUALLY DOWNLOAD#
Invoke Pester - Download your Terraform state files (eg from an Azure blob container) - Convert each state file from JSON to a PowerShell object - For each state file object: - + For each resource type found: - + + Run the relevant preloaded function to test the resource - Output the results into NUnit XML. Load into memory… - Custom functions that test each type of resource - Any naming standard function used in your Azure environment. Use service principal credentials to log into each subscription. #PESTER CONTINUALLY INSTALL#
Install and import Pester on the running agent. You can look at a bunch of screenshots I have made for this project which might help you along the way: #PESTER CONTINUALLY HOW TO#
Create Azure DevOps pipelines for the following YAML files: If you are unsure how to do this, use the screenshots in this folder as a guide, here.pipelines\00_pipes\deploy_base.yml. The script works on the Name, not the ID, of the subscription (perhaps I should update/change this). #PESTER CONTINUALLY UPDATE#
Also update the Name of the subscription to the same GUI name that shows in your own subscription.
Update the configuration YAML file that points to these values. ARMCLIENTID = a service principal ID with contributor rights on the subscription ARMCLIENTSECERT = the SPs secret ARMSUBSCRIPTIONID = the subscription ID being deployed to ARMTENANTID = the tenant ID associated with the subscription TERRAFORMBACKENDACCESSKEY = the storage account access key where the tfstate file is kept AZDOPAT = the personal access token as mentioned above AZDOPATAPI = a personal access token with API rights for when POSTing to Event Hub (discussed further below) 
Create a backend storage account and key vault to store the state files and subscription credential secrets. As shown link - Create a Personal Access Token that has the following rights Agent Pools (Read & manage) Create a service connection linking to your subscription, using the naming convention sub. To demonstrate Pester functioning, I have built a mini-landing zone which you can clone from this repo: Basically, if you’re on a Linux box, in PowerShell, and can type a command of any sort and get a result, then Pester can assert against it. In previous roles I have even used commands from Docker, JQ, and even SSH’d onto another box to run a command, grab the resulting output of that command, and use Pester to assert the result. For all of my Pester testing I have run this on either an Ubuntu or RedHat machine with PowerShell 7.x installed, using Azure DevOps tasks to initiate it. Pester is a PowerShell module, but that doesn’t mean you can only run PowerShell commands, or that the script has to run on a Windows box. I am basing the examples below of Pester using Azure DevOps for the pipeline runs, and that the state files for Terraform are kept in Azure storage account in a container called tfstate however these practices could be altered and applied anywhere.īefore we get started, there is one important thing to note. On some projects I have worked with, we have run Pester on a morning schedule and POST’ed the results to both Event Hub (for which Elastic Cloud consumes) and to Microsoft Teams, so that we keep track of any resources that might have been altered outside of how we normally deploy resources. Not only can it test what you have just deployed is correct, but it can also run on a schedule to ensure that nothing has drifted away from what the Terraform state file determines as correct. For those that don’t know, Pester is an extremely simple and useful PowerShell testing tool that can easily be adapted to test if Terraform has actually deployed your resources correctly by using basic assertions which is a whole lot easier than eyeballing each one yourself.
0 kommentar(er)
