aws-toolkit-azure-devops
aws-toolkit-azure-devops copied to clipboard
Azure DevOps Task 'AWS Tools for Windows PowerShell Script' - Ignore PS Module Check
Current situation: Using Azure DevOps on a private Azure DevOps server to connect to AWS resources.
In Azure DevOps pipelines, the AWS Task 'AWS Tools for Windows PowerShell Script' is used to run PowerShell scripts against AWS resources. The scripts are executed on a Self-Hosted Agent (Private VM).
As per documentation 'The module will be automatically installed if needed', however every time this task is executed, it checks if the module is present on the Self-Hosted Agent.
Problematic Scenario: If we have have more than 10 similar tasks on the same pipeline, and the check is made every time, which consumes nearly 1 minute per task only for the checks. In total, this increases the pipeline execution time by 10 minutes.
Question: Is it possible to ignore this check?
Expected Solution: Add an option to ignore the Powershell Module checks in the AWS task.
Thank you
The check is here: https://github.com/aws/aws-toolkit-azure-devops/blob/2e99eec9c7f200f7477ca370380bfdb585a1a763/src/tasks/AWSPowerShellModuleScript/RunAWSPowerShellModuleScript.ps1#L39
If that takes 1 minute, that implies that the Get-Module -Name AWSPowerShell -ListAvailable call is slow.
Possible improvements:
- change the code to always try
Import-Module -Name AWSPowerShellin a try-catch and only then doing the "check" step above. - find a faster way to check for a module instead of
Get-Module -ListAvailable- related: https://github.com/PowerShell/PowerShell/issues/11387
Hello @justinmk3,
Thanks for your reply.
However in this case, we are using the AWS Task 'AWS Tools for Windows PowerShell Script' in an Azure DevOps pipeline.
This Azure DevOps task from AWS "uses cmdlets from the AWS Tools for Windows PowerShell module (AWSPowerShell) module. The module will be automatically installed if needed."
Task reference: https://docs.aws.amazon.com/vsts/latest/userguide/awspowershell-module-script.html
So, the import of AWSPowerShell modules is handled by this Task which simply references our PowerShell scripts. As such, we cannot control which AWSPowerShell modules are being installed or skipped, as it checks for everything by default.
Thank you
Are you able to run Get-Module -Name AWSPowerShell -ListAvailable manually and see how long it takes? Checking how long Import-Module -Name AWSPowerShell would also be useful.
Hello @justinmk3,
Kindly note we tried above commands on our VM, and we found the below results:
-
"Get-Module -Name AWSPowerShell -ListAvailable" took 0.5 seconds, and
-
"Import-Module -Name AWSPowerShell" took 15.3 seconds.
Thank you
Great info, thanks!
"Get-Module -Name AWSPowerShell -ListAvailable" took 0.5 seconds, and
"Import-Module -Name AWSPowerShell" took 15.3 seconds.
So Import-Module is the slow part. Reading the AWS Tools for PowerShell,
AWS.Tools - The modularized version of AWS Tools for PowerShell. ...
AWSPowerShell.NetCore - The single, large-module version of AWS Tools for PowerShell. All AWS services are supported by this single, large module.
AWSPowerShell - The legacy Windows-specific, single, large-module version of AWS Tools for PowerShell. All AWS services are supported by this single, large module.
Proposal
Based on the above, perhaps we could improve performance of Import-Module by migrating to AWS.Tools instead of the legacy AWSPowerShell
Hello @justinmk3,
You're right, migrating from the legacy AWSPowerShell to the new AWS.Tools could help gain around 15 seconds.
Thank you :) Feel free to proceed.
However, I think if we could add a checkbox to ignore/skip the PowerShell Module verification (i.e. make the Import-Module part optional), that would instantly help us gain 1 minute per task. This is because we do not need to verify/import the module every time a script is executed when we use this extension.
Appreciate your thoughts on this.
Thank you
we do not need to verify/import the module every time a script is executed when we use this extension.
If there's a faster way to check that the module is already imported, we could use that and skip Import-Module.
Adding a "skip" option is (1) a very special-case solution and (2) doesn't save much in terms of implementation cost, so it's unlikely we would take that approach. Instead the code should skip unnecessary things by default.
@justinmk3 Well noted, thank you👍
Please feel free to proceed with your initial proposal, i.e. to migrate towards the use of AWS.Tools.
Thank you
Same issue here. In my case, it takes 5 MINUTES to import modules. Idk why, but at this moment its been the slowest step in my pipeline.
Same here, 1 min mininum waiting time, AWSPowershell: 4.1.562 is pre-installed on all agents.
Same here - 5 minutes to load on Azure hosted agent. Seems the problem isn't the Azure Devops task - it is AWS PowerShell.
The first message in the task log file lists "Checking install status for AWS Tools for Windows PowerShell module" as the 5 minute offender .
According to Microsoft, both the AWS CLI and AWS PowerShell are already installed on their hosted agents.
Using a pipeline PowerShell task ( not an AWS PowerShell ) to run the get-awspowershellversion returns in 5 minutes.
Doing some more testing using the PowerShell, other commands were tested
- Initialize-AWSDefaultConfiguration -Region us-east-1 -AccessKey XXX -SecretKey XXX -SessionToken XXX
- Get-EC2Instance
Still 5 minutes on Initialize-AWSDefaultConfiguration
Similar AWS CLI commands run from the same PowerShell task don't exhibit the same problem. The below consistently returned in under 50 seconds
40 seconds for the below
- aws configure set region us-east-1
- aws configure set aws_access_key_id $Env:AWS_ACCESS_KEY_ID
- aws configure set aws_secret_access_key $Env:AWS_SECRET_ACCESS_KEY
- aws configure set aws_session_token $Env:AWS_SESSION_TOKEN
10 seconds for the below
- aws ec2 describe-instances
This time delay gets out of control when you have 6 or 7 stages in a release pipeline, each using the AWS PowerShell task - this tacks on 30 minutes to the pipeline....
This delay can also be seen on AWS EC2 instances where the first call to Initialize-AWSDefaults takes 5 minutes....
Some additional testing indicates the speed problem may be related to AWSPowerShell running in Windows vs Linux.
Removing AWS Tools for Windows PowerShell Script from the equation and soley using PowerShell and the AWSPowerShell module...
Running the exact same script with an Ubuntu host executes the initialization in under 40 seconds, in Windows 4+ minutes.
This was tested in an Azure Devops classic release by creating a Task with two hosted Agent jobs, one using Ubuntu-Latest the other Windows-Latest
Under each Agent, add a PowerShell task and run the inline code below, uses your own AWS credentials
Write-Host "Install"
Install-Module -Name AWSPowerShell -Force
Write-Host "Import"
Import-Module -Name AWSPowerShell
Write-Host "GetInstalled"
Get-InstalledModule -Name AWSPowerShell
Write-Host "Initialize"
# Initialize-AWSDefaultConfiguration -Region 'us-east-1' -AccessKey XXX -SecretKey XXX -SessionToken XXX
$Env:AWS_ACCESS_KEY_ID="ABC"
$Env:AWS_SECRET_ACCESS_KEY="DEF"
$Env:AWS_SESSION_TOKEN="GHI"
Initialize-AWSDefaultConfiguration -Region 'us-east-1'
Write-Host "GetEC2"
Get-EC2Instance
Write-Host "Done"
Since it is already installed on Azure Windows Hosts, for the Windows task, you can comment out "Install-Module -Name AWSPowerShell -Force"
You can slice and dice this a few ways, such as commenting out the Import-Module, which will result in Initalize-* taking 4 minutes vs 1 seconds.
Pipeline logs are attached.
Install AWS Powershell LINUX.log Install AWS Powershell WINDOWS.log