The other day I needed to launch some one-off Fargate / ECS container tasks with PowerShell. The documentation covered most of what I needed but I could not find any examples on how to override environment variables sent to the container task.
I only needed to change one environment variable so creating a whole new task definition seemed overkill for this purpose. After some trial and error the below code helped me get the job done.
If this helped you out please let me know in the comments. Feedback will motivate me to share solutions on this site more often.
I wanted to look at connecting two disparate systems for a recent project. The goal was to be able to enter information into one system and have information processed by another system. The systems have no direct authentication trusts between them but they are both running on Amazon Web Services EC2 platform. This was a perfect use for the decoupling nature of the Amazon Simple Queue Service and I wanted to come up with a proof of concept, which is outlined below.
Before getting into any details, I want to make clear that this is not a best practice use case of SQS. For most uses of SQS there is a need to keep track of the messages being processed in some kind of permanent state such as a database. With a persistent data store containing the processed messages, the queue workers can more effectively process messages if messages are delivered one or more times. That being said lets go over this proof of concept.
Assuming AWS keys with correct permissions are configured and the AWSPowerShell module is loaded, the below command will create a new SQS queue with PowerShell. The command returns the created queue url which will be stored in a variable $NewSQSQueueUrl for future use.
A quick peek at the SQS console to ensure the queue was created.
This next bit creates an array of strings which will serve as some example information to share between the systems. For this proof of concept I am sending example PowerShell parameters into the SQS queue.
PowerShell
1
$exampleparams=@("All The Things","Another Example Parameter")
I have written the POC functions which are also uploaded to my GitHub PowerShell repo that get dot sourced. These functions put the information (example parameters) into the new SQS queue as message attributes of the newly created SQS message.
After running these functions the message ids are returned to the PowerShell host indicating the messages have been inserted into the SQS queue successfully.
Below is the function that was dot sourced that did the uploading. You could customize this to fit your use case with some help from the AWS Send-SQSMessage cmdlet documentation.
Send-SQSMessage-QueueUrl$SQSQueueUrl-MessageAttributes$messageAttributes-MessageBody"Request generated by $($env:Username) at $(Get-Date -Format u)"
}
}
catch{
Write-Error$_
}
}
}
With messages being put into the queue, I need a function to pull down the messages and process them on the queue worker system (aka the SQS message receiver). My goal is to take different actions on the queue worker system based on the message attributes of the SQS messages pulled out of the queue. That function looks something like this.
Start-SQSQueueProccessing
PowerShell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
functionStart-SQSQueueProccessing
{
[CmdletBinding()]
[Alias()]
[OutputType([int])]
Param
(
[Parameter(Mandatory=$true,
ValueFromPipelineByPropertyName=$true,
Position=0)]
[String]$SQSQueueUrl
)
Process
{
try
{
Write-Verbose"$(Get-Date -Format u) Polling for $SQSQueueUrl messages"
}else{Write-Verbose"$(Get-Date -Format u) ... No messages were pulled from the queue...nothing to do right now"}
}
catch{
Write-Error$_
}
}
}
This function isn’t actually doing anything interesting with the messages other than generating some output to the PowerShell streams but this is a proof of concept after all :).
Considerations when using SQS
As SQS is designed to decouple distributed systems, SQS does not assume every message pulled from the queue has been processed successfully. Messages that are pulled from the queue are hidden from the queue until the message visibility timeout period has passed. It is up to the queue workers to delete the messages from the queue after the message has been processed. This is why at the end of the function above, messages are deleted from the queue with the Remove-SQSMessage cmdlet.
After working with SQS a bit, I noticed that the behavior surrounding the delivery of messages sitting in the queue is a little unintuitive. For example, say there are 8 messages in a queue and I request for up to 10 messages to be received with Receive-SQSMessage. A logical assumption would be that all 8 messages are returned but that is rarely the case. After working with some messages in queues it becomes quite apparent that SQS will return a random number of messages. Additionally without using FIFO (First-In First-Out) queues, the messages will often be delivered out of order.
Another bit of a gotcha I ran into at first was that by default, Recieve-SQSMessage will not return any message attributes from SQS. The resulting Amazon.SQS.Model.Message object that was returned had blank MessageAttributeValues until I specified “-MessageAttributeName All” parameter.
Hopefully the above considerations will shed some light on the way the function is written. I wrote it so that it could be run repeatedly from a parent polling script and that it could handle one more more message objects being returned from each poll of SQS.
Back to the functions
Finally, we get to the polling function portions of the script which could run on scheduled intervals via task scheduler. This function first checks a queue for the existence of messages using the Get-SQSQueueAttribute cmdlet. If messages are found in the queue, it will invoke the Start-SQSQueueProcessing function referenced above to handle the messages. I make use PowerShell transcription to keep a log for now. If this ever moves out of proof of concept, logging could be improved quite a bit to make it cleaner.
What does it look like when ran you may be wondering?
The PowerShell transcript output captures the same information. As you may have noticed, the body of the generated SQS messages contains information on who created the SQS message and when it was created which could help for audit trails.
Here is some example code which may help you automate security group creation with PowerShell. I wanted to take a look at automating some security group creation tasks today and there wasn’t too much help available via search engines. Maybe this post will help that out a bit.
The minimum amount of IAM permissions needed to accomplish this task will be:
IAM Policy for this script
Vim
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"Stmt1392679134000",
"Effect":"Allow",
"Action":[
"ec2:Describe*",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateSecurityGroup",
"ec2:CreateTags"
],
"Resource":[
"*"
]
}
]
}
This snippet of powershell will:
Lookup the only VPC in your account, provided your regional defaults are set via Initialize-AWSDefaults or the ec2 instance you are running this on. This is helpful as some of the powershell cmdlets only play nice with the default vpc, which many people tend to delete.
Create a new security group for a load balancer
Allow HTTP and HTTPS traffic ingress into the load balancer security group
Create a new security group for a web server
Allow HTTP from the load balancer to the web server security group
Allow SSH from a security group that is looked up by the name “My Bastion Host Security Group” to the web server
Today I am going to attempt to take some PowerShell functions I wrote on Windows and run them on Linux. This should all be possible now that Microsoft Loves Linux! With the new .Net (core) going open-source and cross platform combined with AWS’s Tools for PowerShell core, I should be able to run the exact same functions across Windows and Linux.
For this exercise I will be using a Ubuntu virtual machine on Hyper-V but this could easily be done on CentOS or other various linux distros. Microsoft recently added support for installing PowerShell through popular distro’s default package managers so we will take that approach to get up and running.
Enough intro lets get to it! I am going to use Microsoft’s provided steps in a bash terminal window to register the Microsoft repo and get the latest PowerShell 6 alpha installed and running.
After running those commands, PowerShell is installed and the system leaves us at the PowerShell command prompt.
To verify everything is working I can use $psversiontable to output our PowerShell info to the host.
Okay, everything is looking good so far.
Loading AWS Tools for PowerShell Core
Next up is to get AWS Tools for PowerShell core loaded. This can be done with the new PowerShell package management cmdlets specifically Install-Module.
PowerShell
1
Install-Module-NameAWSPowerShell.NetCore
Oh No, a red error appeared! Quick, email this error to our System Administrator to figure out what went wrong! Haha, just kidding. Lets read it.
The error says administrator rights are required to install modules. The suggestions are to try to change the scope via parameter or to use elevated rights. Well, run as administrator sure won’t work on Linux, so I will do the equivalent and exit out of PowerShell then sudo powershell back into the PowerShell host.
After a retry of the Install-Module command from the now elevated PowerShell host, the Install-Module command completes without error.
I want to check to see the available modules with the get-module command and verify the AWSPowerShell.NetCore module is listed now that its installed.
PowerShell
1
Get-Module-listavilable
Everything checks out and the AWS module is listed right at the top.
Loading my AWS functions from GitHub
I don’t plan on doing any editing of my functions or commits from this system, so I can skip configuring Git and just install it right from the package manager. The neat thing about using Git is that all the nuances that come from working on files between *nix and Windows, like different carriage returns, should be handled behind the scenes by Git.
Shell
1
sudo apt-getinstall git
Once git is installed I can clone the PowerShellScripts repository from my github.
A quick ls and cd is used to make sure the AWSFunctions folder came down with the repository.
Creating AWS Read Only Access Keys
Since this is just a proof of concept exercise, I am going to run a function I built to check the status of a running EC2 Instance by looking up its Name tag. The only access I need for this in AWS IAM is the ability to describe my instances so we can create a new IAM User with an attached EC2 Read only policy.
The IAM console has really become simple to use with recent updates but lets cover everything step by step.
First I’ll log into my AWS account and navigate to the IAM console. From there I want to choose Users and then use the Add User button.
I will call the user blogpostec2readonly and check the box for programmatic access, which will generate our access keys.
On the next screen I will choose Attach existing policies directly. The filter box directly below can be used to search for “ec2readonly” and an AWS managed policy for EC2 Read Only will appear. This managed policy is prewritten json IAM policy maintained by Amazon that helps administrators quickly provide permissions without needing to deep dive into IAM permissions. Perfect for our use case at hand. I’ll check the box for this policy and click next.
The next screen is a review screen and a final Create User button.
After the new IAM user is created the access key and secret key are provided for download. Be careful with these, as AWS access keys are all that is needed to access an AWS account. I will copy the provided access keys into the gedit text editor so I can use them in the next step.
Configuring AWS PowerShell Module Credentials
All the prep work is nearly completed and the next steps are to configure the default region, access key, and secret keys to be used with the AWS PowerShell module cmdlets. To do this we will import the AWSPowerShell.NetCore module and run the Set-AWSCredentials and Initialize-AWSDefaults cmdlets.
I need to load my functions into memory so lets use Get-ChildItem to list the functions files and dot source each one. (% in PowerShell is a shorthand alias for ForEach-Object)
PowerShell
1
Get-ChildItemAWSFunctions|%{.$_.FullName}
To verify my custom functions are loaded and ready to execute we can try to tab complete them. The function I am running in this exercise is Test-RunningEC2InstanceByServerName so I will type Test-Run and press tab.
Success! Tab completion filled out the name of function for me. Lets see if it works…
The Instance hosting this here blog is called PACKETLOST02 so I will send that server name in as a parameter into the function and I am expecting it to return that the instance is running.
The function ran and returned that the instance is running.
Summary
How neat was this? I took some PowerShell functions I wrote on the Windows platform and commited them into my GitHub repo then got them to run on Linux. When I initially wrote these functions it was to help automate my day to day administration of Amazon Web Services. I wrote these functions on the Windows platform with only the Windows platform in mind. Thanks to the great work of the developers at Microsoft and Amazon Web Services these functions are now cross platform.
I hope this post provides a quick glance into how useful and flexible PowerShell can be as well as how promising the future of the .NET core and the .NET standard libraries are to cloud computing. Cheers!
I often have to turn on instances or register them with load balancers. I had some trouble finding documentation on the AWS PowerShell modules but in the end I was able to get everything done via scripts.
Here are some examples that might help you out.
If you are not using IAM roles then you will need to pass credentials to the AWS powershell module to use. This is how you accomplish that (using least privileged IAM credentials I hope).
I was configuring a MySQL RDS instance inside a VPC a few months back with a bit of a unique setup. This RDS needed to be publicly accessible from some systems outside the corporate network and also accessible via systems in the same VPC.
I configured the RDS instance in a new public subnet and gave it an elastic IP by choosing the option for Publicly Accessible during RDS creation. I changed the security groups to allow it to accept MySQL traffic from the public IP of the system outside the corporate network. I also changed the security group to allow MySQL traffic from members of another security group containing the servers I wanted to interface with the RDS instance.
To my surprise I had no connectivity between the internal VPC systems and the RDS instance. Telnet tests to port 3306 confirmed the traffic was being blocked. After some name resolution troubleshooting, I discovered if I allowed MySQL traffic through the NAT security group and allowed MySQL traffic from the public IP of my AWS Nat instance into the RDS instance I had connectivity.
The systems in the VPC were resolving the public IPs of the RDS instance and not the internal IPs provided via the VPC. After some digging into the documentation I discovered this was a result of us bringing our own DNS into the VPC with Active Directory.
The solution was to create a conditional forwarder zone on the domain controllers located in the VPC to forward name resolution requests for amazonaws.com to the DNS server provided by the VPC. The DNS server provided with the VPC is located on the bottom most subnet of the VPC. So if your VPC CIDR block was 10.10.0.0/16 and your subnets were 10.10.0.0/24 your Amazon provided DNS server would be at 10.10.0.2.
This DNS server is used by your default DHCP option set and it cannot be accessed via systems outside your VPC. So if you have the same Active Directory domain on premises and in AWS, you will not want this conditional forwarder zone on your on premises domain controllers.
With the conditional forwarder in place, requests from VPC domain joined systems now resolved internal IPs of the RDS instance and traffic no longer needed to route out to the internet via the NAT instance.
