As more services go live on my Kubernetes clusters and more people start relying on them, I get nervous. For the most part, I try and keep my applications and configurations stateless - relying on ConfigMaps for example to store application configuration. This means with a handful of YAML files in my Git repository I can restore everything to working order. Sometimes though, there’s no choice but to use a PersistentVolume to provide some data persistance where you can’t capture it in a config file. This is where a backup of the cluster - and specifically the PersistentVolume is really important.

[<img class=“alignright size-thumbnail wp-image-8035” src="/images/2017/03/logo.jpg" alt="" width=“150” height=“150” which vROps can provide by using various extensibility solutions.

We discussed the following use cases and demonstrated them in live environments:

Use Case 1 - Full-Stack vSphere Monitoring. From application to Infrastructure.

Use Case 2 - Amazon RDS Workloads. Monitoring public cloud workloads with vROps.

Use Case 3 - vROps Extensibility. Metrics, Logs and Costing come together along with other 3rd party extensibility options.

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.

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.

I have been musing this a little while and decided to write this post/rant/opinion post, feel free to post your thoughts and opinions in the comments.

OK so here it is, one thing I have observed for a good while now is how much noise there is about how -you- should be in the cloud (Public) and if you are not you’re already dead.

I call Bull****!

Public, Hybrid and Private clouds are solutions not final destinations, regardless of whether you are a customer, partner, or any other third thing you should be purely focused on what is best for you or (if you provide IT services) your customer. It is plainly obvious to me that in -all- of the customers I have visited there has been no appetite or reason to mass adopt any single one solution/option as it simply would not fit how they do business and function day to day. There will of course be exceptions to this rule but they are indeed exceptions not the norm.

Although it’s fairly limited, you can add AWS as an endpoint for vRealize Automation 7  and consume EC2 AMIs as part of a blueprint. You can even add the deployed instances to an existing Elastic Load Balancer at deploy time. In this post I’ll run through the basics to get up and running and deploy your first highly available (multiple Availability Zone, load balanced) blueprint.

Preparing AWS for use as a vRA endpoint

There are some obvious pre-requisites for attaching an AWS endpoint - for example, you need to have a VPC configured. There are plenty of resources out there for creating a VPC, so I won’t extend this post by replicating them. This is what I’m using:

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.