Recently I’ve been working on some ideas in my lab to leverage the AWS endpoint on vRealize Automation. One of the things I needed to get working was getting Software Components working on my AWS deployed instances.
The diagram to the right shows my end-stage network – the instance deployed by vRA into AWS should be in a private subnet in my VPC, and should use my local lab DNS server and be able to access my vRA instance. This allows me to make use of the vRA guest agent for software components on the deployed VMs. I also wanted to have the deployed VMs use their local NAT gateway for internet traffic, rather than paying for the data over my VPN connection. (more…)
When you’re working with Amazon and vRealize Automation Software Components, one of the requirements is for the Guest Agent (gugent) to talk back to the vRealize Automation APIs – the gugent polls the API for tasks it should perform, downloads them from the API and executes them, then updates the tasks with a status.
This means that Virtual Machines deployed as EC2 instances in an AWS VPC require the ability to talk back to internal corporate networks – not something you’d want to publish on the internet! That’s where AWS’s VPN connections come in – you can create several types of VPN that allow such communication over a secure (encrypted) virtual private network.
For the purposes of this post, I’m going to look at setting up the “AWS Hardware VPN”, which is described by Amazon:
You can create an IPsec, hardware VPN connection between your VPC and your remote network. On the AWS side of the VPN connection, a virtual private gateway provides two VPN endpoints for automatic failover. You configure your customer gateway, which is the physical device or software application on the remote side of the VPN connection.
As with all things AWS, you have to create two of anything in different Availability Zones to call it Highly Available, or for any kind of SLA to apply. The VPN is no different, and as you can see from the diagram above you create two tunnels to provide a Highly Available connection to AWS.
To get a bit of a background on my AWS setup for vRealize Automation, take a look at this post – Adding an AWS endpoint to vRealize Automation 7. The VPCs and configuration described in this article are my starting point.
For my hardware VPN I am running a Ubiquiti EdgeRouterX, which is a fantastic little router, highly recommended. It has a tiny form factor, runs on Vyatta OS and even provides a PoE port for my Ubiquiti Unifi AP AC Lite. (more…)
Recently I was asked to develop some vRealize Orchestrator workflows against the F5 BIG-IP iControl REST API, but I was not able to test freely against a production appliance. After a lot of attempts to get in contact with F5 for a 90-day trial of the full version, or to purchase a lab license, I came up empty handed. The free version you can download from F5’s website is version 11.3, which does not feature the iControl REST API, which was released in 11.4.
What I did notice while on the F5 site was the links to the AWS Marketplace where you can rent F5 BIG-IP Virtual Editions by the hour – $0.83/hr + AWS usage fees.
If you happen to have a license for BIG-IP there’s also a Bring Your Own License version, which would be handy. You can view all the options on F5 Network’s AWS Marketplace page.
Here’s how you set up your F5-in-AWS! (more…)