Recently there have been some changes in my backpack concerning the portable system that I carry with myself to perform my job. I have had an HP laptop handed to me on my first day of work at my current company (about two years ago) and I actually had no problems whatsoever at the start. Now this laptop lived for about 3/4 years before it decided to stop working. My Laptop would not turn on and I could not work for 1.5 days cause we had no spare laptops at the time. Now that was a bummer.. My company replaced my system with the same model and since I actually liked the Laptop I was handed in the first place I was excited to have another one of these. Another 3/4 years down the line the exact same thing happens. Again I'm unable to work for 1.5 days before my replacement arrives. Again it is the same model. Then I learned something interessting. My company does BYOD (Bring your own device) and they actually pay for that system. But as, almost, always with cool stuff there is a hook. The laptop my company hands out have a 2 year lease on them before you can have a new one. Very reasonable policy in my eyes and also I thought at the time that my lease would soon expire and I could order a new one. No... As I learned a little while after receiving my 3rd laptop (still same model) I found out that my lease was reset both times I received a replacement and I thought that I would be stuck in an endless HP Laptop loop, where I would get a new one every 3/4 years. Now I'm in luck that I have good people above me that allowed me to ditch that HP misery (Not at all implying that's the case for every HP Laptop!) and order myself my own System to be able to work on that. So I started thinking what I would like to use. It would have to perform well since I do developmemt on it and I also am fond of big and nice screens, since I work in a different spot nearly every day and I don't always have the possibility for external screens. Ah and I code Powershell. Could I buy myself a Macbook and have a good time working on it mostly writing Powershell code? Powershell 7 is around the edge and crossplatform is available since v6 so that is kind of covered. VSCode is available.. What do I need more? Honestly I tried to inform myself to the best I could, but soon it got clear to me that I was going to get a Macbook. At the time I write this I have worked on my Macbook for one week now and I have to say I love it! I have noticed no shortcomings up until now and I have done some cool linux stuff on my machine! I have a Linux ansible lab on my Macbook for example. But the main thing I discovered for me this past few weeks was Docker. I know I'm late to the party, but I started to look at it and play around with it. My main interesst was actually to run Powershell on linux and see how that's working out. But then it hit me. Run Pester tests on docker machines with powershell on them. You can completly destroy your container and there will be a new one up and running in a matter of seconds. I know it's a simple idea and I by no means think for a second, that I'm the first one to come up with this, but still. So I started to write a Module. In this Blogpost you'll learn how to run the Pester tests for your Powershell project on multiple operating systems locally. DockerPester makes this possible. DockerPester Ok so now you should have installed Docker on your machine, which makes you ready to use DockerPester. Installing DockerPester The Module is currently not available on the Gallery. So at the moment the only option of using it you have is to fork and clone the repo. First run of DockerPester So to start off you just need a Powershell Project of yours with some Pester Tests. Create a Hashtable that contains the following Key Value pairs: {% highlight powershell %} $ParamSet = @{ ContainerName = "DockerPester" #Name of the Container used to Test. Image = "mcr.microsoft.com/powershell:7.0.0-rc.2-alpine-3.8" #Image used for the Container InputFolder = "/Users/kevin/code/PSHarmonize"#Module or Folder you pass with your Tests in them PathOnContainer = "/var" #Path you want to copy to in your container PathToTests = "Tests" #Path in 'InputFolder' where your Tests are located PrerequisiteModule = "PSHTML" #Pass Modules that are prerequisites to your tests to download from gallery in container. Executor = "LNX" #The executor is the OS of your Machine - Docker host. If you run on Windows you set "WIN" if you run on MacOS or Linux you set "LNX" } {% endhighlight %} Each Parameter we define in the hashtable is shortly described with a comment on the same line. Make sure you're in the right context for the Image you define here and the Executor matches your OS. Also make sure to change the 'InputFolder' to an actual project with Pestertests in them. 'PathToTests' is the Path in your Powershell Project Folder where your Tests are located. To run your first DockerPester run use the following code: {% highlight powershell %} Invoke-DockerPester @ParamSet {% endhighlight %} So here we basically just splat the Parameters we defined in the Hash $ParamSet to 'Invoke-DockerPester'. So what will that do. First it will spin up a Container with the Image we defined in our Hash. The ContainerName we set will be the name of that container. Then it will copy the Powershell Module Project Folder from your local Computer that you defined under 'InputFolder' to the path you defined in 'PathOnContainer' on the Container. After that it will start downloading the Prerequisite modules that you defined to download from the gallery and it will install the newest version of Pester and yes, the output on that is not sooooooo nice I will admit that, but hey, we all need room to grow right? After the installation of the modules it will start executing the Pester Tests. And when that's done it will return the Passthru Object from Pester back to you. The Output you will see should look like this: {% highlight powershell %} PS /Users/kevin> Invoke-DockerPester @ParamSetf6b8047075adc5ee491b772b9321e85bf0e628d9add2a1ff9f79ea254894227a DockerPester Installing package 'PSHTML' Downloaded 0.00 MB out of 0.64 MB. [ ] Installing package 'Pester' Downloaded 0.00 MB out of 0.85 MB. [ ] Installing package 'Pester' Process Package Manifest [oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo ] Pester v4.10.1 Executing all tests in '/var/PSHarmonize/Tests' Executing script /var/PSHarmonize/Tests/Functions.Letters.Tests.ps1 Describing [PSHarmonize][Functions] Testing Letter Functions

I want to introduce you to one of my more recent open source projects. "PSAnsible.Playbook". What is it? It is basically nothing more than a wrapper around the "ansible-plabyook" excecutable. Instead of that excecutable you can use Powershell to start your playbooks and you will get results back in the way we all know and love it from powershell native tools/frameworks. Let me demonstrate. Setting up a small test enviornment Setting up the module If you want to follow along here you can follow the instructions on my docs page on Github: Docs on how to set up the module The TLDR Version of that docs page is: install ansible (either linux or mac, or WSL on Windows) make sure powershell core is installed install the module Configure the ansible.cfg for ansible to output json Setting up a dummy ansible environment In order to make some quick tests on ansible I usually use a small dummy environment that looks like following. Inventory I set up an inventory at ”/etc/ansible/hosts" with the following content: win: hosts: waap: ansible_host: localhost woop: ansible_host: localhost weep: ansible_host: localhost wuup: ansible_host: localhost In this inventory you will find that I define one group called "win". This group has 4 different hosts. Since I do not have a lab environment handy with 4 machines at all times I use "ansible_host: localhost" to make ansible think I have 4 host, where ansible actually will point all actions to localhost aka running it on itself. This is just a quick way to "test on multiple hosts" without having multiple hosts. Playbook Then comes the fun part. Writing your playbook. this is what ansible is all about and almost always what I test in such a dummy environment. I would write a playbook to test out the syntax of ansible conditionals for example or whatever. For this example here a small playbook with an "echo” will be enough. I continue to create my playbook as "/etc/ansible/ps.yml" and I fill it up with the following content: --- - name: PSTest hosts: win connection: local gather_facts: no tasks: - name: This is a debug message debug: msg: I am a debug message Very simple, just a debug message. Using ansible-playbook Now normally what you would do is you would call your playbook like this: ansible-playbook /etc/ansible/ps.yml -i /etc/ansible/hosts this would then result in the following output: PLAY [PSTest] **************************************************************************************************************************************************************************************************************** TASK [This is a debug message] *********************************************************************************************************************************************************************************************** ok: [waap] => { "msg": "I am a debug message" } ok: [woop] => { "msg": "I am a debug message" } ok: [weep] => { "msg": "I am a debug message" } ok: [wuup] => { "msg": "I am a debug message" } PLAY RECAP ******************************************************************************************************************************************************************************************************************* waap : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 weep : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 woop : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 wuup : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 Now this output is nice right? You see everything that happened and you also get a Play Recap at the end there. What more do you want? Well.. Imagine how this would look like at scale. We can scale in two directions here. There can first of all be a lot more tasks in a playbook. And secondly you can target an inventory with way more hosts. Also what you get here may be nice to look at, but this is where the party ends. You have no way to programmatically continue your process and for example display the data you gathered during your playbook run, or validate that you have achieved a certain result in your run. *** Now here PSAnsible.Playbook comes in to play. (pun fully intended). *** Using PSAnsible.Playbook Since you have prepared your enviornment and loaded the module in powershell you can run the following command: $result = invoke-PSAnsiblePlaybook -Playbook /etc/ansible/ps.yml -i /etc/ansible/hosts This will return an object in $result with all the information you need on the ansible playbook run. If you look at $result you will on the root level find all information on what has been excecuted: ~> $result Playbook Param ExcecutionString RunResult -------- ----- ---------------- --------- /etc/ansible/ps.yml {-i} ansible-playbook /etc/ansible/ps.yml -i /etc/ansible/hosts PSAnsiblePlaybookRunResult You see which playbook was excecuted, which parameters you have passed to the "ansible-playbook" excecutable. You can also see the exact line used to execute the playbook (ExcecutionString). This enables you to debug. If you encounter errors it is transparent what exactly ran. And the most exciting part: In the "RunResult" Property of the object you will find all details about your run in a structured format. Let's have a look: ~> $result.RunResult.RunResult hostname summary tasks -------- ------- ----- waap @{changed=0; failures=0; ignored=0; ok=1; rescued=0; skipped=0; unreachable=0} {@{TaskName=This is a debug message; TaskDetails=}} weep @{changed=0; failures=0; ignored=0; ok=1; rescued=0; skipped=0; unreachable=0} {@{TaskName=This is a debug message; TaskDetails=}} woop @{changed=0; failures=0; ignored=0; ok=1; rescued=0; skipped=0; unreachable=0} {@{TaskName=This is a debug message; TaskDetails=}} wuup @{changed=0; failures=0; ignored=0; ok=1; rescued=0; skipped=0; unreachable=0} {@{TaskName=This is a debug message; TaskDetails=}} As you can see here you get an array. One instance per host, where all tasks are listed in the tasks property. And you have your summary where you can check each property (Changed, Failures etc.) as you like. This in turn enables things like sorting on hosts where all tasks where no failures occured: ~> $result.RunResult.RunResult | ?{$_.summary.failures -eq 0} hostname summary tasks -------- ------- ----- waap @{changed=0; failures=0; ignored=0; ok=1; rescued=0; skipped=0; unreachable=0} {@{TaskName=This is a debug message; TaskDetails=}} weep @{changed=0; failures=0; ignored=0; ok=1; rescued=0; skipped=0; unreachable=0} {@{TaskName=This is a debug message; TaskDetails=}} woop @{changed=0; failures=0; ignored=0; ok=1; rescued=0; skipped=0; unreachable=0} {@{TaskName=This is a debug message; TaskDetails=}} wuup @{changed=0; failures=0; ignored=0; ok=1; rescued=0; skipped=0; unreachable=0} {@{TaskName=This is a debug message; TaskDetails=}} You see where I'm going with this. You have Ansible playbook run results in powershell which you can further on use however you like. Cool usecases that come to mind immediatly: Display Results of Ansible Playbook Runs in a nice way (PSHTML??) Test your Ansible playbooks with Pester! Possibilites are limited by the things you do with Powershell. Or any language you choose to pass your results to. Closing This is it folks. That's my most recent project. It was not to big of a deal, but I'm certainly going to use this. I like the possibilities this opens up for People who are open to use Powershell on linux. This Module of course also work if you target linux machines with ansible, so maybe if a linux engineer could step over the shadow and use Powershell on linux they could even profit from this ;) Hit me up on twitter @_bateskevin if you have any questions about it. But yeah, that's that.