Using PowerShell in Containers
The vision for PowerShell Core is to be able to run PowerShell anywhere. In this article, I’m going to discuss how you can use Docker Containers to enable just that. We’ll look at running PowerShell in a container, running cmdlets, running different versions of PowerShell at the same time, and also how to build our own “serverless” computing platform.
Let’s address a few reasons why you would want to run PowerShell in a container.
- Speed and agility – this for me is probably the number one reason to run PowerShell in a container. The PowerShell container images are coming in at around 375MB, this means with a modern Internet connection you’ll be able to pull a PowerShell container image and be up in running in a very small amount of time.
- Version – there are container images available for every release of PowerShell Core, including preview/release candidate code. With containers, you can run multiple versions of PowerShell Core in a way where they will not conflict with each other.
- Platform independence – there are container images for Ubuntu, Fedora, Windows Server Core, Nano Server and more. This allows you to be able to consume PowerShell Core regardless of your underlying platform. You can select whichever image you want, pull the container and go.
- Testing – if you need to test your scripts across various versions of PowerShell Core you can pull the container, run the script on the exact version you need. You can have multiple containers on your system running multiple versions of PowerShell and be able to run them all at the same time.
- Isolation – containers will allow you to have self-contained environments for execution, security, environment, and configuration settings. You can also use this idea to isolate conflicting modules from each other. This is particularly valuable when developing modules and/or cmdlets.
Getting Up and Running
Let’s get started with using PowerShell Core in a container. First up, we will want to pull the Docker Container Image to our local machine. This will pull the image with the latest tag. Which at the time of this post is 6.2.0-ubuntu-18.04.
docker pull mcr.microsoft.com/powershell:latest
With the container image local, let’s go ahead and start up the container. In this first go, I’m going to start up the container with the docker run command and with the –interactive and –tty flags. What these flags do is, when the container starts, attach to the terminal of the container so I can use PowerShell Core interactively at the command line.
docker run \
--name "pwsh-latest" \
--interactive --tty \
mcr.microsoft.com/powershell:latest
This will get you a PowerShell prompt. I told you this was going to be fast.
PowerShell 6.2.0 Copyright (c) Microsoft Corporation. All rights reserved. https://aka.ms/pscore6-docs Type 'help' to get help. PS />
From that prompt, we can do the normal PowerShell things we need to do. Let’s start our journey like all good PowerShell demos do and run Get-Process. You’ll notice that there is only one process running in the container, and that’s your pwsh session. This is due to the isolation concepts of Containers. With this isolation, problems like conflicting modules and settings go away. The container gives you script an isolated execution environment. If you need to have two conflicting versions of a module, DLL or library to run your workload or script…you can use a container to isolate their execution giving them the ability to co-exist on the same system.
PS /> Get-Process
NPM(K) PM(M) WS(M) CPU(s) Id SI ProcessName
------ ----- ----- ------ -- -- -----------
0 0.00 110.03 2.01 1 1 pwsh
We can use exit to get out of PowerShell. When you exit PowerShell the container will stop. You can see that status of your container with docker ps.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 8c9160fea43f mcr.microsoft.com/powershell:latest "pwsh" 6 minutes ago Exited (0) 8 seconds ago pwsh-latest
If you’d like to get back into your container you can use docker start pwsh-latest -i where pwsh-latest is the container name we just created and -i is for interactive (we used –interactive earlier). Run that and you’ll land right back at a PowerShell prompt again.
Running a cmdlet When Starting a Container
Now, let’s say we wanted to start our container up and non-interactively run a cmdlet right away, we can do that. With the docker run command, we can tell the container that we want it to start pwsh and pass in a cmdlet as a parameter into pwsh, with the -c parameter and that cmdlet will be executed. Let’s check out how.
docker run mcr.microsoft.com/powershell:latest pwsh -c "&{Get-Process}"
NPM(K) PM(M) WS(M) CPU(s) Id SI ProcessName
0 0.00 81.35 0.54 1 1 pwsh
From a performance standpoint, I want to point out the time it takes to do this work, we can use the time command to help us with that. Less than two seconds to start the container, start pwsh and execute our cmdlet and shut down the container.
time docker run mcr.microsoft.com/powershell:latest pwsh -c "&{Get-Process}"
NPM(K) PM(M) WS(M) CPU(s) Id SI ProcessName
0 0.00 81.61 0.54 1 1 pwsh
real 0m1.901s
user 0m0.038s
sys. 0m0.086s
Now let’s say I wanted to test a cmdlet execution against a specific version of PowerShell Core, perhaps even a Release Candidate. Let’s change the tag from latest to preview and docker will pull that container, start it up and we immediately have an environment for testing. This could be leveraged for script testing, cmdlet testing, module testing and so on. In the output below, you can see the preview tag points to the 6.2.0-rc1 version of PowerShell Core.
docker run mcr.microsoft.com/powershell:preview pwsh -c "&{Get-Host}"
Name : ConsoleHost
Version : 6.2.0-rc.1
…output omitted…
Now, each time we started a container so far in this post and then exited pwsh, the container shut down and was still on our system. We can see the containers with a docker ps -a. We can restart any of these containers and get them back by using the command mentioned previously.
docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d8d8d27ec7be mcr.microsoft.com/powershell:preview "pwsh -c &{Get-Host}" 4 seconds ago Exited (0) 2 seconds ago pensive_poincare
5eace290b47c mcr.microsoft.com/powershell:latest "pwsh -c &{Get-Proce…" 4 minutes ago Exited (0) 4 minutes ago dreamy_haibt
c8361b9e0a76 mcr.microsoft.com/powershell:latest "pwsh -c &{Get-Proce…" 6 minutes ago Exited (0) 6 minutes ago boring_shirley
8c9160fea43f mcr.microsoft.com/powershell:latest "pwsh" 15 minutes ago Exited (0) 8 minutes ago pwsh-latest
We can delete each container by name, using docker rm then specifying the name as a parameter. For example, docker rm pwsh-latest would delete that container.
Running a Script When Starting a Container
When a container is deleted, the data “inside” the container is deleted too. So if we created a script inside a container and then delete the container that means the script would go away too. In Docker, we can use a volume to help us with this. A volume allows us to store our data externally to the container, we can mount the volume inside the container and it looks like it’s part of the container’s file system.
With volumes, when we delete the container, the data stays inside the volume. We can then create a new container and attach the volume to that new container and the data will be there for us to work with.
Let’s start a container and attach a volume at the /scripts location of the container’s file system. Let’s also add the –detach parameter. This is going to start the container, start pwsh and then stop the container. Then I’m going to copy a script from my local file system into the container. The container does not need to be running for the copy operation to succeed.
docker run \
--name "pwsh-script" \
--interactive --tty \
--volume PSScripts:/scripts \
mcr.microsoft.com/powershell:latest
Here’s the code to copy the script from my local file system into the container where pwsh-script is the container name and /scripts is the location we want to copy the script to inside the container. This is the volume we attached to the container. The script is a simple hello-world script.
docker cp Get-Containers.ps1 pwsh-script:/scripts
With that, let’s go ahead and remove the container. We used it just to copy the script into the volume. I kind of feel bad, but we’ll keep moving on.
docker rm pwsh-script
With that, let’s create a new container in interactive mode, with the volume attached. This will put us at a pwsh prompt.
docker run \
--name "pwsh-script" \
--interactive --tty \
--volume PSScripts:/scripts \
mcr.microsoft.com/powershell:latest
Now, since our script is in the volume and we attached that volume when we created this new container, it’s available for us inside the container. Let’s go ahead and run that script inside the container and then delete the container with docker rm when it’s finished.
PS /> ls -la /scripts/ total 12 drwxr-xr-x 2 root root 4096 May 2 18:30 . drwxr-xr-x 1 root root 4096 May 2 18:33 .. -rw-r--r-- 1 502 dialout 73 Apr 28 21:43 Get-Containers.ps1 PS /> /scripts/Get-Containers.ps1 Hello, world! PS /> exit docker rm pwsh-script
Sounds Like…Serverless?
Now let’s take that technique we just stepped through, where we started the container, ran a script and deleted the container and combine all of that into one step. To do so, we’ll use the following command options for docker run. We specify the –rm option which will delete the container when it exits, add the /scripts volume and tell pwsh to run the script that’s in our volume by specifying its location with the parameter -F /scripts/Get-Containers.ps1.
docker run \
--rm \
--volume PSScripts:/scripts \
mcr.microsoft.com/powershell:latest pwsh -F /scripts/Get-Containers.ps1
Hello, world!
Now, with that last technique, we’ve encapsulated the entire lifecycle of the execution of that script into one line of code. It’s like this script execution never happened…or did it ;) All kidding aside, we effectively have a serverless computing platform now. Using this technique in our data centers, we can spin up a container, on any version of PowerShell on any platform, run some workload/script and when the workload finishes, the container just goes away. For this to work well, we will need something to drive that process. In an upcoming blog post, we’ll talk more about how we can automate the running of PowerShell containers in Kubernetes.
In this post, we covered a lot, we looked at how you can interactively run PowerShell Core in a container, how you can pass cmdlets into a container at runtime, running different versions of PowerShell Core and also how you can persistently store scripts outside of containers in volumes and run those scripts in your containers. We also looked at how you can encapsulate the whole execution of a script and the containers life cycle into one line of code. Really giving you the ability to run PowerShell Core anywhere on any platform.
I hope you enjoyed this and are as excited as I am about how we can leverage this technology to solve new and unique problems in your data center and IT operations.