Tanzu Kubernetes Grid (TKG) Clusters As-A-Service with vRealize Automation OOTB integration with vSphere with Tanzu.

In this blog I m going to cover how vRealize Automation / vRealize Automation Cloud integrate out of the box with vSphere with Tanzu that will help empower DevOps teams to easily request, provision and operate a Tanzu Kubernets Grid (TKG) as a service.

Overview

vRealize Automation is a Multi-Cloud modern infrastructure automation platform with event-driven state management, designed to help organizations control and secure self-service for Private Cloud, Hybrid Cloud and Public Cloud automation with governance with a DevOps based infrastructure delivery approach.

( Click the Image to Enlarge )

It helps improve IT agility, productivity and efficiency so you can prepare for the future of your business, providing organizations a consistent way of automation across cloud and data centers. Read More!

As for vSphere 7 with Tanzu, its considered the biggest release of vSphere in over a decade. It enables millions of IT administrators across the globe to get started with Kubernetes workloads within an hour give or take.

Its truly a new generation of vSphere for containerized applications and the fastest path to Kubernetes. This single, streamlined solution bridges the gap between IT operations and developers with a new kind of infrastructure for modern, cloud-native application both on premises and in public clouds.

( Click the Image to Enlarge )

On one side it empower developers with secure, self-service access to a fully compliant and conformant Kubernetes API and on the other side it empower IT Operators with visibility into Kubernetes workloads and clusters and it allows them to manage policies for an entire group of VMs, Containers or both with a unified platform. Read More!

Requirements

  • A Tanzu Basic vSphere 7.0.3 Update 3e environment is what I am using here, with Workload Management enabled.
  • An instance of vRealize Automation 8.6.1 or higher on premises Or vRealize Automation Cloud (SaaS).

Step-by-Step Flowchart

To simplify the steps I have created a flowchart as a reference that we will be going through to outline and explain all the needed steps, describing each step with screenshots to help you follow along to configure the integration and allows you to provision both Supervisor Namespaces and Tanzu Kubernetes Grid Clusters using vRealize Automation.

( Click the Image to Enlarge) ( Click Again to Zoom In & Out)

But Wait, There’s More!

Make sure to watch my video for this blog post on YouTube If you want to see me going over the above step-by-step flowchart and doing a live demo provisioning a Supervisor Namespace , A Tanzu Kubernetes Cluster from vRealize Automation using VMware Cloud Templates and the Self-Service Portal.

I will also be deploying a Kubernetes Voting-App on the provisioned Kubernetes Cluster from the command line using Kubectl.

If you like the content and want to see more, please make sure to like the video, subscribe to the VMwareLab YouTube channel and hit the notification Icon, all so you don’t miss any upcoming blogs or videos, not to mention that It also helps the channel a ton, so I can continue producing and putting more content out there.

Thank you

The End, Eh!

Blueprinting CAS Cloud Automation Services Kubernetes Machine Blueprints Tanzu vRA Blueprints vRealize Automation vRealize Suite

Infoblox IPAM Plug-in 1.1 Integration with vRealize Automation 8.1 / vRealize Automation Cloud

Hello Everyone

Welcome to VMwareLabYour VMware Cloud Management Blogger

With vRealize Automation you can use an external IPAM provider to manage IP address assignments for your blueprint deployments.

In this integration use case, you use an existing IPAM provider package, in this case its an Infoblox package, and an existing running vRealize Automation environment to build a provider-specific IPAM integration point.

You configure an existing network and create a network profile to support IP address allocation from the external IPAM provider. Finally, you create a blueprint that is matched to the network and network profile and deploy networked machines using IP values obtained from the external IPAM provider.

infoblox-vRA-logos-2

The Infoblox IPAM Plug-in allows us to easily integrate vRealize Automation 8.1 and vRealize Automation Cloud with the Infoblox DDI appliance.

One of the main features of Using Infoblox DDI, is that it allows IT Teams to consolidate DNS, DHCP and IP address management into a single platform, deployed on-site and managed from a common console.

The Infoblox IPAM plugin 1.1 for vRealize Automation 8.1 integration allows us to use the IP address allocation and DNS record creation and deletion with our Cloud Assembly or Service Broker deployments.

The plugin is available on the VMware Solution Exchange and uses (ABX) Action Based Extensibility to retrieve IP data from the Infoblox grid as well as update the grid with DNS host records and other data for the deployed virtual machines (VM) and networks.

Prerequisites

  • vSphere private cloud
  • vRealize Automation 8.1
  • Infoblox NIOS or vNIOS appliance with minimum WAPI 2.7 version
  • Infoblox grid is configured for IPAM and DNS
  • A good place to work and an ice cold beer.

In this video blog we are going to go through all the steps required to install, configure, and use the Infoblox IPAM plugin 1.1 for vRA 8.1 / vRA Cloud.

Let’s get started, Eh!

Important Notes

  • The vRA 8.1 Infoblox IPAM plug-in v1.1 is currently managed by VMware. The plug-in is not officially supported by Infoblox currently but Infoblox is actively working towards certifying / providing support for this plugin.
  • Plugin functionality is currently limited to IP address allocation/de-allocation, network creation/deletion, and DNS record creation/deletion.
  • If you happen to use a signed certificate on Infoblox ( Self-Signed Cert Shouldn’t have this issue ),  You may encounter the following error Unable to validate the provided access credentials: Failed to validate credentials” knowing for sure that your credentials are correct, you might have an Infoblox certificate issue. To fix that you can check my colleague Dennis Derks blog here .
  • If you use custom DNS views in Infoblox (internal, external, etc.) then some additional configuration is required that’s not easily identified. To fix that check this blog here

If you have any comments please leave it in the comment section of either the blog here or in the you-tube video comment section, please hit the like button if you liked the video.

To stay up to date with my latest blogs and videos, make sure to follow my blog site and do subscribe to my YouTube channel VMwareLab and smash that notification bell.

The End, Eh!

Automation and Orchestration CAS Infoblox IPAM vRA Blueprints vRealize Automation

VMware Cloud Automation Services (CAS) – Cloud Assembly – Part 1

VMware’s cloud automation services are a set of cloud services that leverage the award-winning vRealize Automation on-premises offering. These services make it easy and efficient for developers to build and deploy applications. The cloud automation services consist of VMware Cloud Assembly, VMware Service Broker, and VMware Code Stream. Together, these services streamline application delivery, enable cloud flexibility and choice, and control risks. Additionally, these services facilitate collaboration between traditionally siloed groups helping further with accelerating business innovation.

  • VMware Cloud Assembly: Developers want the same experience of automating deployment and consumption of infrastructure and applications in private and hybrid clouds as they adopt public clouds. Cloud Assembly delivers unified provisioning across all clouds through declarative Infrastructure as Code, including AWS, Azure, and VMware Cloud on AWS. With Cloud Assembly, IT and cloud operations teams can orchestrate and expedite infrastructure and application delivery in line with DevOps principles, improving the overall developer experience, developers get an experience equivalent to provisioning resources from native public clouds.
  • VMware Service Broker: Service Broker provides simple, self-service access to multi-cloud infrastructure and application resources from a single catalog, without requiring disparate tools. With Service Broker, operations teams can more effectively govern resource access, and use and enforce security, deployment and business policies across multi-cloud environments.
  • VMware Code Stream: Enterprise development teams are creating and iterating on applications faster than ever, but this work is often delivered using a combination of manual scripting and a mix of delivery tools. This creates challenges with delivery speed, visibility, and troubleshooting for code releases. Code Stream automates the code and application release process with a comprehensive set of capabilities for application deployment, testing, and troubleshooting. It features integrations with popular developer tools and supports VMware-based private clouds, VMware Cloud on AWS and native public clouds. With Code Stream enterprises get code and applications out faster and reduce the time it takes to correct issues when they arise.

In part 1 of 2 of this blog post we will explore CAS and how to initially set it up and configure it starting with a new assigned Cloud Organization registered with the above mentioned Cloud Automation Services.

You can access VMware Cloud Services by visiting https://cloud.vmware.com/  then clicking on the Log In menu option to use the services.

cas-01

Once you sign in with your credentials you will have access to the Console Menu option which will take you in to access the Cloud Automation Services we mentioned above.

cas-02

cas-03

Most of the work we will be doing will be initially in VMware Cloud Assembly then we will be able to extend the work to the other two services, VMware Service Broker and the VMware Code Stream respectively.

In this setup we will be leveraging the following environments :

  • VMware SDDC Cloud ( Home Lab ) as my Production Environment.
  • AWS EC2 Cloud as my Development Environment.
  • Azure Cloud as my Testing Environment.

So let’s get started, Eh!

VMware Cloud Assembly

VMware Cloud Assembly is an infrastructure as code automation solution designed to expedite infrastructure consumption and application delivery in line with DevOps principles, through an intuitive symmetrical dual interface ( Code or Draw ) that supports declarative, intent-based application infrastructure provisioning, blueprint design and lifecycle management across multiple clouds such as VMware SDDC, Amazon Web Services, VMware Cloud on AWS and Azure as a minimum on GA date.

The infrastructure as code approach streamlines infrastructure consumption by enabling blueprint parameterization, iteration on blueprint development and easy version control through native controls or supported version control systems. The SaaS form factor enables VMware to keep the platform up to date, allowing operations teams to focus on higher value activities, such as business systems reliability and performance.

Our intent here to use Cloud Assembly to provision new projects to public clouds that we can then bring on-prem when they are ready to go to production for example. My goal here really is to show you how we can create an agnostic blueprint ( WordPress Application ) that the user can deploy from Cloud Assembly Directly or request it from the Service Broker ( Catalog ) and selecting which environment ( Dev, Test, Prod ) you want to deploy the application to.

And to do that we need to configure a few things to create our deployment stack and start deploying blueprints

  1. Create our Cloud Accounts.
  2. Create Cloud Zones.
  3. Create one or more Projects.
  4. Create Flavor mapping.
  5. Create Image mapping
  6. Create and deploy blueprints.

Cloud Accounts

Cloud accounts allow you to bring your public cloud and on-prem data centers under CAS management.

In Cloud Assembly, navigate to  Infrastructure > Connections > Cloud Accounts > ADD CLOUD ACCOUNT

cas-04

We will configure our 3 Account Types / Environments here :

cas-05

vCenter Account Type

Prerequisites Checklist

  1. You have at least one collector / Cloud Proxy VM installed.
  2. You have the vCenter IP address/FQDN.
  3. You have the vCenter user name and password.

Note that a collector VM can typically support 10,000 VMs

Installing Cloud Proxy

  • Click Add Cloud Account
  • Select vCenter as the account type. When you don’t have any previous Cloud Proxies setup, you will be presented with the steps needed to install one.

cas-06

  • Download the Cloud Proxy ova file to deploy it in vCenter OR
  • Copy the OVA link to directly deploy it in vCenter without having to download it first.
  • Import the .ova file to the vCenter Server and start the installation following the standard steps provided by the OVF Deployment Wizard.

cas-07

  • Once you get to the Customize Template section within the OVF Deployment Wizard we will provide the following properties:
    • CAS One Time Key (OTK)
    • Root User name and password
    • Remote Data Collector / Cloud Proxy Display Name in CAS
    • Network Proxy Settings ( Optional )
    • Networking Properties

cas-08

  • Click Next and Finish to deploy the cloud proxy. it takes a few minutes to detect your Cloud Proxy after it is deployed and powered up in vCenter.
  • To verify the detection of the Cloud Proxy is complete navigate to Infrastructure > Connections > Cloud Proxies and verify its listed with a good status.

cas-09

  • Navigate again to Infrastructure > Connections > Cloud Accounts > ADD CLOUD ACCOUNT 
  • Click Add Cloud Account
  • Select vCenter as the account type. Now that we setup a Cloud Proxy, you will be able fill all the requirement including the Cloud Proxy we just deployed.
  • Enter the vCenter user name and password and hit VALIDATE. 
  • Provide a Name and a description for the Cloud Account.
  • In the Configuration Section select which DataCenters you want to allow provisioning to
  • Allow to create a Cloud Zone for the Selected Datacenters by checking the check box, this will automatically create the Cloud Zone for us so we don’t have to later.
  • Add Capability Tags as required, this will be used for placement decisions as we will see later in the blog post.
  • Click ADD when Completed.

cas-10

  • Once added you should see the cloud account listed with OK Status

cas-11

Amazon Web Services Account Type

Prerequisites Checklist

  1. Access Key ID
  2. Secret Access Key
  • Navigate again to Infrastructure > Connections > Cloud Accounts > ADD CLOUD ACCOUNT 
  • Click Add Cloud Account
  • Select AWS Web Services as the account type.
  • Provide the Access Key ID and Secret Access Key and Click VALIDATE
  • Provide a Name and a description for the Cloud Account.
  • In the Configuration Section select which Regions you want to allow provisioning to.
  • Allow to create a Cloud Zone for the Selected Region by checking the check box, this will automatically create the Cloud Zone for us so we don’t have to later.
  • Add Capability Tags as required, this will be used for placement decisions as we will see later in the blog post.
  • Click ADD when Completed.

cas-12

  • Once added you should see the cloud account listed with OK Status

cas-13

Azure Account Type

Prerequisites Checklist

  1. Subscription ID
  2. Tenant ID
  3. Client Application ID
  4. Client Application Secret Key

Note: If you want to know how get these IDs, this is very similar to how we currently setup up vRealize Automation Azure endpoint and there are plenty of blogs you can reference such as my personal favourite by Jon Schulman

  • Navigate again to Infrastructure > Connections > Cloud Accounts > ADD CLOUD ACCOUNT 
  • Click Add Cloud Account
  • Select Azure as the account type.
  • Provide the IDs required and Click VALIDATE
  • Provide a Name and a description for the Cloud Account.
  • In the Configuration Section select which Regions you want to allow provisioning to.
  • Allow to create a Cloud Zone for the Selected Region by checking the check box, this will automatically create the Cloud Zone for us so we don’t have to later.
  • Add Capability Tags as required, this will be used for placement decisions as we will see later in the blog post.
  • Click ADD when Completed.

cas-14

  • Once added you should see the cloud account listed with OK Status

cas-15

Cloud Zones

Cloud zones associate compute resources with projects and account/regions to form the basis of deployable virtual machines. In addition, they enable you to define capabilities that Cloud Assembly matches with blueprint constraints to define where and how resources are configured for deployments.

Now remember that we checked the check box to create a cloud zone for the selected Datacenter/Region where we want to provision to for each of the cloud account types we have created. (vSphere, AWS and Azure )

Navigate to Infrastructure > Configure > Cloud Zones to list the pre-created Cloud Zones or to create new ones if you decide for example to add new Datacetners / Regions to provision machines to.

You don’t need to create any cloud zones if you selected the option to automatically create zones when you added your cloud accounts, we will customize the cloud zones in this section of the blog.

cas-16

Within each of the cloud zone > Summary Tab you can select a Placement Policy that defines how provisioned resources are distributed among hosts in this cloud zone. By default resources are placed on random hosts but:

One of the following strategies can be optionally applied:

  • BINPACK – Will place computes on the most loaded host that still has enough resources to run the given compute.
  • SPREAD – Will attempt to spread computes evenly across hosts.

For the purpose of the blog we will leave the Placement Policy as DEFAULT for all the Cloud Zones.

cas-17

You saw me mention the use of Capability tags and so far we have created tags on the Cloud Account type level.

cas-18

When it comes to Tagging Strategy you must carefully plan and implement an appropriate tagging strategy based on your organization’s IT structure and goals to maximize Cloud Assembly functionality and minimize potential confusion.

Tags are a critical component of Cloud Assembly that drive the placement of deployments through matching of capabilities and constraints. You must understand and implement tags effectively to make optimal use of Cloud Assembly. you also need to create an outline of your strategy and make it available to all users with privileges to create or edit tags.

For best practices for Tagging and Tagging Implementation, I would recommend spending few minutes first reading the documentation on What Are Tags.

vSphere Cloud Zone

Like we mentioned already a cloud zone defines a set of compute resources that can be used for provisioning.  In our Toronto Datacenter we have two clusters TOR-COMP-CL and TOR-MGMT-CL out of which we only want to use the TOR-COMP-CL for provisioning.

cas-19

Within the vSphere Cloud Zone and under the Compute tab we have what we call Filter Tags which we will use to remove or filter out the TOR-MGMT-CL from the cloud zone compute resource list since its our management cluster and it will not participate in being used as a resource we can provision workloads to.

At the beginning of the blog we mentioned that will be using our vSphere environment for our Production workloads so will we need to add a capability tag that we can use later in our blueprints as a constrain if we want to target our compute production cluster.

To do that we will first select the TOR-COMP-CL > Click TAGS, Type Env:Production and hit enter to form the tag then click Save

cas-20

Now we can also use the Env:Production tag to filter out the compute resource TOR-MGMT-CL by using the tag as a Filter Tag and list only those compute clusters that has the same tag, also like I mentioned I don’t want the TOR-MGMT-CL cluster to be part of the vSphere Cloud Zone at all.

cas-21

Now you may ask but why would you want to do that if you can simply use the Env:Production tag to target the TOR-COMP-CL cluster . What a great question I might say?

Its all about planning, where if for example I added another production cluster within the same Datacenter in the future, I can then simply tag it with the same tag  then leverage a higher level tag like the one we setup on the vCenter Account Type which we also could have setup on the Cloud Zone level within the Summary Tab to target all the vSphere production clusters. That cloud account tag was Cloud:vSphere which will allow me to target all my production clusters

Again you really don’t have to do that as I m just trying to prove a point here, as this can be done in many different ways.

AWS Cloud Zone

When we added the AWS cloud Account we selected the CA-Central-1 Region as the region we want to provision our development workload to. As you can see in the Screen shot below the AWS cloud Zone has two compute resources / availability zones that I can target for my Development workloads.

cas-22

Since I am okay utilizing all the AWS compute resources listed within the cloud zone I can place my Env:Development capability tab on the cloud zone level within the Summary Tab instead of placing it on the compute level like we did previously with the vSphere cloud zone. Click SAVE when your done.

cas-23

Azure Cloud Zone

For Azure when we created the Azure Account we selected the EAST US as the region we want to provision our test workload to. As you can see in the Screen shot below the Azure cloud Zone has one compute resources / availability zones that I can target for my Testing workloads.

cas-24

Just like the AWS Cloud Zone I can place my Env:Testing capability tag on the cloud zone level within the Summary Tab. Click SAVE when your done.

cas-25

So in summary we have added 3 different cloud account types, selected the Datacenter / Regions we want to provision workloads to and created there respective Cloud Zones and added capability tags on the Cloud Account Level , Cloud Zone level and Cloud Zone Compute level as we see fit, that we can leverage later as constraints when we create/design our blueprints.

Flavor Mapping

Cloud vendors use flavors, or instance types, to express standard deployment sizings such as small or large for compute resources. when we create a blueprint, you need to pick a flavor.

Flavor mappings are of course regional settings. This becomes critical in public cloud endpoints where sizes are dictated by a phrase like T2.Micro in AWS as opposed to fixed sizing details like in vCenter that might equate to a specific number of CPUs or GBs of Memory.

We will define three flavor mapping ( Small, Medium, Large ) across vSphere, AWS and Azure.

Small Flavor Mapping

  • In Cloud Assembly, navigate to Infrastructure > Configure > Flavor Mappings
  • Click + NEW FLAVOR MAPPING
  • Enter Flavor Name : Small
  • Click on Search for regions and create a Small Flavor Mapping for all 3 Clouds
  • Click CREATE

cas-26

Medium Flavor Mapping

  • In Cloud Assembly, navigate to Infrastructure > Configure > Flavor Mappings
  • Click + NEW FLAVOR MAPPING
  • Enter Flavor Name : Medium
  • Click on Search for regions and create a Medium Flavor Mapping for all 3 Clouds
  • Click CREATE

cas-27

Large Flavor Mapping

  • In Cloud Assembly, navigate to Infrastructure > Configure > Flavor Mappings
  • Click + NEW FLAVOR MAPPING
  • Enter Flavor Name : Large
  • Click on Search for regions and create a Large Flavor Mapping for all 3 Clouds
  • Click CREATE

cas-28

Once completed you should have 3 Flavor Mappings ( Small, Medium, Large ) for the 3 cloud platforms ( vSphere, AWS, Azure )

cas-29

Image Mapping

Cloud vendors use images to configure a VM based on OS Settings, such as an ubuntu-16 configuration. When you build a blueprint, you pick an image that fits your needs.

An image mapping associates a defined image name with a machine template. You can create one or more image names and map to a metadata file that contain pre-defined value sets. For example, an image might map to an OVA file that contains pre-populated cost or region specifications to import into the blueprint. Image mappings again are regional settings.

we will define three image mapping ( CentOS7, Ubuntu, Windows 2016 ) across vSphere, AWS and Azure.

Windows 2016 Image Mapping

  • In Cloud Assembly, navigate to Infrastructure > Configure > Image Mappings
  • Click + NEW IMAGE MAPPING
  • Enter Flavor Name : Windows 2016
  • Click on Search for regions and for images to create a Windows 2016 Image Mapping for all 3 Clouds
  • Click CREATE

cas-30

CentOS7 Image Mapping

  • In Cloud Assembly, navigate to Infrastructure > Configure > Image Mappings
  • Click + NEW IMAGE MAPPING
  • Enter Flavor Name : CentOS7
  • Click on Search for regions and for images to create a CentOS7 Image Mapping for all 3 Clouds
  • Click CREATE

cas-31

Ubuntu Image Mapping

  • In Cloud Assembly, navigate to Infrastructure > Configure > Image Mappings
  • Click + NEW IMAGE MAPPING
  • Enter Flavor Name : Ubuntu
  • Click on Search for regions and for images to create a Ububtu Image Mapping for all 3 Clouds
  • Click CREATE

cas-32

Once completed you should have 3 Image Mappings ( Ubuntu, CentOS7, Windows 2016 ) for the 3 cloud platforms ( vSphere, AWS, Azure ).

cas-33

Network Profiles

A network profile defines a group of networks and network settings that are available for a cloud account in a particular region or datacenter. A network profile defines the networking options and capabilities that are made available to deployed machines, based on the network tags in the network component YAML in a blueprint.

You typically define network profiles to support a target deployment environment, for example a small test environment where an existing network has outbound access only or a large load-balanced production environment that needs a set of security policies. Think of a network profile as a collection of workload-specific network characteristics.

AWS Network Profile

  • In Cloud Assembly, navigate to Infrastructure > Configure > Network Profiles
  • Click + NEW NETWORK PROFILE
  • In the Summary tab, For Account / Region click Search for regions and select your AWS Region.
  • Enter a Network Profile Name : AWS Network Profile
  • Enter a Capability Tag : Env:Development  This is again because we are using AWS as our development environment.

cas-34

  • In the Networks Tab, Select + ADD NETWORK  and select the discovered network or networks to use when provisioning a VM.
  • Select the added Network and assign a capability tag, for example here I setup Type:BackEnd-net and Type:FrontEnd-net as tags where both networks support Public IPs.
  • In the Security tab, I have added the default Security group that enables RDP and SSH Inbound and all communications Outbound within the selected VPC in the CA-Central-1a and CA-Central-1b zones.
  • Click CREATE

cas-35

Azure Network Profile

  • In Cloud Assembly, navigate to Infrastructure > Configure > Network Profiles
  • Click + NEW NETWORK PROFILE
  • In the Summary tab, For Account / Region click Search for regions and select your Azure Region.
  • Enter a Network Profile Name : Azure Network Profile
  • Enter a Capability Tag : Env:Testing  This is again because we are using Azure as our Testing environment.

cas-36

  • In the Networks Tab, Select + ADD NETWORK  and select the discovered network or networks to use when provisioning a VM.
  • Select the added Networks and assign a capability tag, for example here I setup Type:BackEnd-net and Type:FrontEnd-net as tags where both networks support Public IPs.
  • In the Security tab, I have added the vmwarelabnetworksecurity Security group that enables RDP and SSH Inbound and all communications Outbound within the selected Network Domain in the East US Zone.
  • Click CREATE

cas-37

vSphere Network Profile

  • In Cloud Assembly, navigate to Infrastructure > Configure > Network Profiles
  • Click + NEW NETWORK PROFILE
  • In the Summary tab, For Account / Region click Search for regions and select your vSphere Datacenter.
  • Enter a Network Profile Name : vSphere Network Profile
  • Enter a Capability Tag : Env:Production This is again because we are using vSphere as our Production environment.

cas-38

  • In the Networks Tab, Select + ADD NETWORK  and select the discovered network or networks to use when provisioning a VM.
  • Select the added Networks and assign a capability tag, for example here I setup Type:FrontEnd-net as a tag where the network support Public IPs. Since this is vSphere, this means that the  network can access internet and not necessarily have an actual public IP like in AWS or Azure.
  • The reason there is no Security tab in Network Profile for vSphere at this point is because we have not setup any NSX account types associated with the vCenter cloud account type.
  • Select the network and click on MANAGE IP RANGES > + NEW IP RANGE to define the set of IP addresses that can be reserved during provisioning.

cas-41

cas-42

  • Click CREATE

cas-40

Once completed you should have 3 Network Profiles for the 3 cloud platforms ( vSphere, AWS, Azure ).

cas-43

Storage Profiles

A storage profile is a cloud-specific set of storage policies that let the cloud administrator define storage for a cloud account region. Storage polices include disk customization, and a means to identifying the type of storage by applying capability tags. Tags are then matched against blueprint constraints to create the desired storage at provisioning time.

AWS Storage Profile

EBS Fast Storage

  • In Cloud Assembly, navigate to Infrastructure > Configure > Storage Profiles
  • Click + NEW NETWORK PROFILE
  • For Account / Region click Search for regions and select your AWS Region.
  • Enter a Storage Profile Name : AWS Storage Profile EBS Fast
  • Enter Device Type : EBS
  • Enter Volume Type : Provisioned IOPS SSD (IO1)
  • Enter Max IOPS : 800 and Select Support Encryption
  • Enter a Capability Tag : Env:Development  and Gold This is again because we are using AWS as our development environment and leveraging the fastest Disks

cas-44

Storage profiles are being grouped by Cloud Accounts. Now that we created the first storage profile for AWS, we will add additional profiles for the storage types we want to support such as a Slow Storage.

EBS Slow Storage

  • In Cloud Assembly, navigate to Infrastructure > Configure > Storage Profiles
  • Click + NEW NETWORK PROFILE
  • For Account / Region click Search for regions and select your AWS Region.
  • Enter a Storage Profile Name : AWS Storage Profile EBS Slow
  • Enter Device Type : EBS
  • Enter Volume Type : General Purpose SSD (GP2)
  • Select Support Encryption
  • Enter a Capability Tag : Env:Development  and Silver This is again because we are using AWS as our development environment and leveraging the Slower Disks

cas-45

Once completed will end up with two EBS Storage Profiles for AWS

cas-46

vSphere Storage Profile

  • In Cloud Assembly, navigate to Infrastructure > Configure > Storage Profiles
  • Click + NEW NETWORK PROFILE
  • For Account / Region click Search for regions and select your vSphere Datacenter
  • Enter a Storage Profile Name : vSphere Default Storage Profile
  • Select Storage Policy : Datastore Default
  • Enter a Capability Tag : Env:Production  and Silver This is again because we are using vSphere as our production environment and leveraging the default Disk.

cas-47

Azure Storage Profile

  • In Cloud Assembly, navigate to Infrastructure > Configure > Storage Profiles
  • Click + NEW NETWORK PROFILE
  • For Account / Region click Search for regions and select your Azure Region
  • Enter a Storage Profile Name : Azure Storage Profile
  • Select Storage Type : Managed Disks
  • Select Disk Type : Standard LRS
  • Select OS and Data disk caching : None
  • Select Supports encryption.
  • Enter a Capability Tag : Env:Testing  and Gold This is again because we are using Azure as our testing environment and leveraging the HDD backed Disks.

cas-48

Once completed you should have 3 Storage Profiles for the 3 cloud platforms ( vSphere, AWS, Azure ).

cas-49

Create A Project

Projects control who has access to Cloud Assembly blueprints and where the blueprints are deployed within the project. You use projects to organize and govern what your users can do and where they can deploy blueprints in your cloud infrastructure.

Cloud administrators setup projects, adding the required users and cloud zones. Anyone who creates and deploys blueprints must be a member of a least one project.

cas-50

As you can see, projects are simply groups that link users to cloud resources, controlling who can use what resource. Users become project members.

To deploy a blueprint , the deploying user must be a member of a project and the project must have one ore more cloud zones that support the development goals of the members. When the blueprint is deployed, the resource requirements defined in the blueprint as evaluated against the available zones and the blueprint is deployed to the cloud zone that supports those requirements.

How Can You Use Projects

You use projects in the way that best suits your users development goals.

  • Create a single project for a development team
    • The project includes a project administrator, the development team members, and all cloud zones that support the team workflow from development to testing to staging to production. the cloud zone capability tags we setup earlier target the zones where the blueprints are deployed.
  • Create multiple projects for a development team.
    • The project members might consist of all the same users or the membership might vary by role. For example, developer members for the development project, developers and testers for the testing and staging project, and lead developers for the production project.

Enough Talking lets go ahead and create a PROJECT

  • In Cloud Assembly, navigate to Infrastructure > Configure > Projects
  • Click + NEW PROJECT
  • Enter the following details for your prject
    • Name : VMWLAB Project

cas-51

    • Under Users, Click + ADD USERS. Here I m adding my self as an Administrator and clicking ADD

cas-52

    • Under the Provisioning tab > Cloud Zones add all the cloud zones we have created and give them a priority number.

cas-53

    • Click CREATE

Notice the Priority numbers we defined for each Cloud Zone when we added them, this mean if no capability tags were defined in a blueprint everything should go to AWS first, Azure second and vSphere Third.

Once completed you should see all the projects you created.

cas-54

Blueprinting

The Market place within Cloud Automation Services is a great way to quickly get started with blueprinting in Cloud Assembly. Not only do we provide several popular applications for deployment via Cloud Assembly, these blueprints also serve as example content you can learn from for how to complete complex tasks in Cloud Assembly YAML interface.

In order to get started with the market place we nee to first bind a My VMware Account

  • In Cloud Assembly, navigate to Infrastructure > Connections > Integrations
  • Click + ADD INTEGRATION
  • Select My VMware

cas-55

 

  • Enter your username and password and Click VALIDATE
  • Provide a name

cas-56

  • Click ADD
  • Select the Market Place Tab, you will be able to see the available sample blueprints. We can choose to either
    • Import the Blueprint directly into a Project
    • Download the Blueprint YAML file
  • For our blog I will be importing the Multi-Tier Web Application ( Word Press ) on On-Demand VMWare NSX-T Virtual Network listed under Technologies > Application Development.

cas-57

  • Clicking Open will give us a chance to read the summary of what this blueprint is about and more importantly the Tech Specs tab will tell us all the requirements for how we should be configuring the Blueprint and what Images to actually use for example
  • Click GET

cas-58

  • You may need to Read and Agree to the terms of a license agreement after that click NEXT to continue.
  • Here we will select to import it directly to our Project cas-59
  • Now we can switch to the Blueprint Tab to validate that the blueprint has been added to the project.

cas-60

  • Let’s Click on the Blueprint link to view its contents and observe the blueprint we imported from the marketplace.

cas-61

Here you go how awesome is that, infrastructure as code at our finger tips in a matter of seconds.

Blueprints from the market place will have temporary sample values assigned to them for the image, flavor, disk and network mappings. These will need to be updated with your own values of-course before attempting to do a deployment. For the propose of this blog we are simply demonstrating the existence of these blueprints to tweak and to learn from.

Creating and Deploying a Single Machine Blueprint

Here will be deploying a single-machine cloud agnostic blueprint based on all of our pervious configuration.

  • In Cloud Assembly, navigate to Blueprints 
  • Click + NEW 
  • Enter the following information, then Click CREATE:
    • Name: Ubuntu Small
    • Description: Ubuntu Small Cloud Agnostic Blueprint
    • Project: VMWLAB Project

cas-62

  • Drag a Cloud Agnostic machine to the canvas. Cloud Agnostic objects are designed to be portable between all supported cloud environments. This includes vSphere, AWS, GSP and Azure. Object types includes Machines, Networks, Load Balancers, and Disk Volumes.
  • In the code and under resources set the following :
    • Image as Ubuntu
    • Flavor as Small

cas-63

  • Click DEPLOY

cas-64

  • Select Create a New Deployment, then fill the required fields:
    • Deployment Name
    • Blueprint Version
  • Click DEPLOY and Monitor the status of the your request by navigating to the Deployment tab.

cas-65

  • When Provisioning is completed, view the deployment details by clicking on the deployment name and lets note where the machine was provisioned

cas-66

As you can see the machine was provisioned in AWS because if you remember, AWS Cloud Zone had the first priority when we added it during the creation of our project VMWLAB Project.

To figure out why AWS was selected we can also check the History Tab within the Deployment details where we can check all the Events for Requests for this deployment

cas-67

Here we can click on the Provisioning diagram shortcut for the ALLOCATE_FINISHED Event. This is will take us to Infrastructure > Activity > Requests to view the Request Details and see the various placement decisions made based on your Blueprint details.

Policy Based Placement

Multi-Cloud blueprints are capable of being moved between multiple environments leveraging tags to dictate their desired location via the Policy Based Placement Engine. In this section we will create a blueprint that is able to move between multiple cloud environment.

We have already created tags on the Cloud Zone Level that addresses the three environment we have Env:Development, Env:Testing, and Env:Production

We will go ahead and create additional tags against our environment but this time it will be based on our Cloud Platforms and on the compute Level for each of the platforms.

Note : Initially I have placed Capability Tags ( cloud:vspherecloud:aws, cloud:azure ) on the Cloud Account Type Level thinking I might need it but now I see more value in removing them from the Cloud Accounts level and instead setting them up at the Compute level within each of the Cloud Zone Type we have created. 

Configuring Tag Policies For Placement

For each of the cloud zones we have we will create a Capability Tag on the compute level. I will document here how we do it on the AWS Cloud Zone and then apply the same steps on the remaining Cloud Zones.

  • In Cloud Assembly, navigate to Infrastructure > Configure > Cloud Zones
  • Select the AWS Cloud Zone by Clicking OPEN 

cas-68

  • Select the Compute Tab and check the box for the Regions you want to use, here I am selecting both Availability Zones.

cas-69

  • Select TAGS  and enter the name of the tag cloud:aws under Add tags field then click SAVE

cas-70

  • Verify that the tag has been applied to the both compute resources then click SAVE to compete the task.

cas-71

  • Will complete the same process on the remaining cloud zones Azure and vSphere, instead we will be leveraging cloud:azure and cloud:vsphere respectively.

Placing the tag at the compute level is a common user case for customers to separate clusters within an environment based on a use case. An abstract version of this concept exists in public cloud as well ( People may use different regions/zones for different user cases).

We might tag a cluster designed for Oracle workloads to leverage the app:oracle tag, allowing us to place these workloads on this cluster via the placement engine. Another use case is for compliance reasons where users may tag clusters based on compliance capabilities on specific environments to ensure workloads land in an environment that will help them pass audits.

Creating Multi-Cloud Blueprint

Let’s create a multi-cloud blueprint leveraging our basic tag placement set, we can now create a blueprint that leverages these tags as part of the placement.

  • In Cloud Assembly, navigate to Blueprints 
  • Click + NEW 
  • Enter the following information, then Click CREATE:
    • Name: Multi-Cloud
    • Description: Multi-Cloud AWS/Azure/vSphere Blueprint
    • Project: VMWLAB Project

cas-72

  • Similar to our single machine blueprint, will drag a Cloud Agnostic Machine Object onto the canvas and configure it with an image type of Ubuntu and flavor of Small

cas-73

  • Under inputs we will add a new field as a drop down for our cloud environment. We can accomplish this with the following YAML:
inputs:
  cloud:
    type: string
    enum:
      - 'cloud:aws'
      - 'cloud:azure'
      - 'cloud:vsphere'
resources:
  Cloud_Machine_1:
    type: Cloud.Machine
    properties:
      image: Ubuntu
      flavor: Small
      constraints:
       -tag: '${input.cloud}'

This instantiates our menu to have AWS, Azure and vSphere as drop down menu options.

  • Also notice that we updated the Resources sections to include the constraints filed, referencing the tag properties, and a variable ‘${input.cloud}’ that references our drop down menu item. So what we select from the drop down menu will be the constraint tag that will decide the placement of the requested machine.

cas-74

  • Select DEPLOY and name the deployment and click Next to observe the Tagging option. Select the your choice and press DEPLOY

cas-75

  • After a few moments our deployment to AWS completes to our cloud environment.

cas-76

  • Select CLOSE  and return to Blueprints. Initiate another deployment and select any other Cloud environment like Azure for example .

cas-77

  • After a few moments our deployment to Azure completes to our cloud environment.

To summarize, we have created a Multi-Cloud Blueprint leveraging the YAML infrastructure as code and we presented to the requester a drop down menu based on Tagging constraints to select which Cloud environment he wants to deploy the machine to.

cas-78

Thank you very much if you have made it this far. I m hoping part 1 of this blog was beneficial and worth your time in exploring what you can do with Cloud Assembly .

In part 2, will explore more advanced topics such as Customizing Blueprints with Cloud-Config, versioning and Iterating on Blueprints.

The End, Eh!

 

 

 

 

 

Automation and Orchestration Blueprinting CAS Cloud Automation Services Machine Blueprints

Deploying and Upgrading vRealize Automation with vRealize Suite LifeCycle Manager 2.0 – Part 1

Wow the title is such a mouthful and so is this blog, so get your popcorn ready and get cosy friends cause we are going to try and capture everything we need to do, so we can use vRSLCM 2.0 to :

  1. Deploy vRA 7.4 and then
  2. Upgrade it to vRA 7.5

Just like that! how awesome is that ? So lets get started Eh!

Lab Overview

Deploying vRA 7.4 will consist of the vRA appliance ( mgmt-vra-02 ) and the IAAS windows machine ( mgmt-iaas-02 ) that will be running the vRA windows services and other important components. these two components does not exist yet.

In the lab we will be running vSphere 6.7 , SQL 2016 and vRSLCM 2.0 that were already configured.

Blog Project

Prerequisites

Please be aware that this what I did in my lab, so some of the items can be done in different ways if available.

  1. DNS A Records for both ( mgmt-vra-02 ) and ( mgmt-iaas-02 )
  2. AD Service account ( administrator@vmwarelab.org )
  3. Downloading the required software from VMware website to an NFS share that you can access from vRSLCM Appliance :
    1. VMware vRealize Automation 7.4.0 OVA file.
    2. VMware vRealize Automation 7.5.0 OVA file.
    3. VMware vRealize Automation 7.5.0 Update Repository.
  4. Microsoft SQL 2016 Server ( mgmt-sql-01 ).
  5. Microsoft Active Directory and DNS ( mgmt-dc-01 ).
  6. vRealize Suite Lifecycle manager 2.0 ( mgmt-lcm-01 ).
  7. vSphere 6.x vCenter ( mgmt-vcs-01 ).
  8. A quite and cosy place to work.

Step 1 : Adding Binaries

We have to add the binaries that we downloaded to the NFS share to vRSLCM. Once you are logged to vRSLCM , Select Settings -> Product Binaries -> ADD BINARIES. In my case my location is based on NFS so select NFS and enter the base location ( Case Sensitive ). Once completed hit DISCOVER to get the product binaries . Will select the product we downloaded and click ADD Selected product binaries are automatically mapped to product versions.

Blog Project1

Once completed you should see them listed under Product Binaries

Blog Project2

Another thing we need to do while we are here is copy a Windows ISO to vRSLCM via WinSCP for example to a folder I created under /data/iso. In may case I already copied Windows 2016 ISO to /data/iso  so in vRSLCM i will select ADD BINARIE again but this time I select Windows ISO and point it to the Base Location where I copied it to then I hit DISCOVER.

Select the ISO image name that are pre-populated after a successful discovery from base location, and fill the rest of the required fields as outlined below and click SUBMIT

One Important Note here is that Windows ISO has to be a Standard Edition for any of the following supported Windows editions :

  • Windows Server 2008 R2
  • Windows Server 2012 and 2012 R2
  • Windows Server 2016

Blog Project16

Once completed again you should see it listed under the ISO Binaries.

Blog Project17

Step 2 : Adding A Subject Alternative Names (SAN) Certificate

We will need to generate a certificate that we will reference later when you select to install vRA 7.4 , so lets go to Settings -> Certificate -> ADD CERTIFICATE and fill it similar to what I did in the figure below, then click GENERATE

Blog Project3

Make sure the certificate is generated successfully and its listed in the certificates table. You can create a certificate for each of the vRealize Suite products Or you can use the same certificate for all products as long you make sure you enter all the HostName/Domain Names in the Domain Name section and there respective IP addresses in the IP Address section of the certificate.

Blog Project4

If you are looking to how to deploy vRSLCM and Creating a SAN ( Subject Alternative Names ) Certificate using your CA Enterprise Server, Check out my colleague Steve Tilkens Blog  Here

Step 3 : Creating an Environment To Install vRealize Automation 7.4

We will be creating an environment in vRSLCM where we will be installing vRA 7.4, assuming you have your Data Center and its associated vCenter Server already setup in vRSLCM.

login to vRSLCM and click on + Create Environment from the left pane. Select your Data Centre and Fill the required fields and click NEXT

Blog Project5

Under Products, Select vRealize Automation by checking the box -> New Install -> 7.4 -> Small Deployment and Click NEXT

Blog Project6

Accept the terms and conditions of the end user agreement to proceed with the installation by scrolling all the way down and checking the box. after that click NEXT

Blog Project7

Enter the vRealize Suite license 2017 since we are deploying vRA 7.4 and click NEXT

Blog Project8

Using the drop down menus select all the applicable Infrastructure associated with the data centre you selected intialy when you created the environment, then click NEXT

Blog Project9

Fill all the network detail and click Next

Blog Project10

Select the Certificate we created in Step 1 for vRealize Automation and click NEXT

Blog Project11

In the Products Details Section and under Product Properties enter the domain accout and password as (Domain\user) of the service account that have administrative rights on the IaaS windows server and can be used across all the IaaS Components and Services.

Select / ADD the NTP servers

Select No to configure Cluster Virtual IPs since this is a minimal install that will be using 1 vRA appliance.

Select Yes to Configure a Windows Box the will run the IaaS Components and services

Blog Project12

Under the Windows Box section since we answer Yes. Select ISO then Select the ISO file Name we uploaded in Step 1.

Select Existing Spec for Customization Specification. I have one that I already created in vCenter Server for Windows 2016 Virtual Machine deployment that will join the provisioned windows machine to the domain.

Blog Project13

Scroll down to configure all the Components that will be running on the Iaas Server

A clarification here for some of the fields . when it says Hostname that is the FQDN of the Machine and when it says VM Name, that is simply the name of the VM in vCenter.

Click NEXT when your done.

Blog Project14

in next section will be doing a PreCheck before we can submit the request. Will start first with VALIDATE & DEPLOY.  You will be presented with Prerequisites for the IaaS Component Deployment Precheck Checks.  Since we are not using a template will simply ignore it for now but will perform the same operation once the VM is deployed. Click VALIDATE & DEPLOY to deploy the IaaS Windows Box.

Blog Project15

That will upload the windows iso image first to the vCenter Content Libraries under the LCM-LOCAL-ISO-LIB which will take some time and you can monitor it in vCenter. Once its done then it will deploy the Windows ISO image as a Virtual Machine.

Blog Project18

vRSLCM will make sure the build is completed and customized with all the required settings like the name of the machine / DNS , IP address and Domain membership, including installing the VMware Tools. All again based on the configuration that was submitted in previous steps. The IaaS machine is configured with 4 CPU, 16 GB and 40 GB Disk.

Blog Project19

Once the vRealize Automation Windows IAAS Deployment Validation in vRSLCM is successful and before I click on RUN PRECHECK . I made sure to login to the IAAS Machine and :

  • Turn off Windows Firewall for Domain, Private and Public Network which was already set.Blog Project20
  • Update the PowerShell execution policy to allow scripts to run by running command line and confirm by entering the letter Y  
  1. Set-ExecutionPolicy Unrestricted                
  • Disable UAC as mentioned in the Prerequisites for the IaaS Component Deployment Precheck Checks using the default Powershell running the following command as an administrator on the IAAS machine
Set-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\System" -Name "EnableLUA" -Value "0"
  • Upgrade the VMware Tools if there is an Upgrade available based on how recent your vSphere environment compared the VMware Tools that was installed (Optional)
  • Allow remote connections for Remote Desktop under Windows System Properties
  • Disable IPv6 on the IAAS Machine
  • Finally I Changed the configuration of the IAAS machine to 8 GB of Memory since this is only a Lab Testing Environment (Optional)

Now we are ready to click on RUN PRECHECK  to execute all the prerequisites needed on the IAAS Machine which we usually automatically fix using the installation Wizard when doing the vRA deployment manually, also this allow us to see if any errors or warnings appears that we need to deal with.

We will be presented again with a Prerequisite check list which we did most of it just make sure you touch on the rest like the SQL Server Privileges and User Rights Assignment. Once your ready to do click on RUN PRECHECK and monitor its progress or you can save and exit and come back later to view the status of PreCheck.

Blog Project23

We need to verify that we don’t have any issues and everything is green across Data, Infrastructure and vRealize Automation Validations, every type of validation have tons of checks that it performs and if there is an issue, you will quickly see the reason behind it and the recommendation on how to fix it.

When fixing any issues or warnings, Keep clicking on RE – RUN PRECHECK until everything is green across the three validation type I mentioned.

Blog Project24

click NEXT 

At the top right corner you have the option to run the Pre check again when you Submit the request, in my case just for the fact that we just ran it there is no reason to run it again cause it will just save us some time, there for I turned it off.

You will also see that your presented with a summary for the all the settings you entered and an option to download it as a json file that you can use anytime if you needed to redeploy the same settings again or modified to deploy additional environment somewhere else.

Blog Project25

One you are ready click SUBMIT and watch the Magic Happens!

Monitor your request as it goes through visually step by step by navigating to Requests and clicking on the Request States IN PROGRESS

Blog Project26

Once its completed successfully, you have a running vRA 7.4 Environment that you can start to configure and use in your organization, also manage and monitor going forward using vRSLCM 2.0.

now that all the steps were successful, we can try hitting the vRA Appliance URL at https://mgmt-vra-02.vmwarelab.org/

Blog Project27

Access the vRealize Automation Console and login with the local user Configurationadmin which has both the Infrastructure and Tenant Admin Roles.

Blog Project28

In the next part of this blog we will look at how easy it is to upgrade the vRA 7.4 instance we just deployed to vRA 7.5 using vRSLCM 2.0

The End of Part 1 Eh!

 

vRealize Automation vRealize Suite Lifecycle Manager

vRealize Automation 7.3 Plug-In for ITSM – Service Now 3.0 – Step by Step Guide!

Before I start I want to give credit to Spas Kaloferov original blog on this subject. I think you should take the time to check it out specially if your considering using ADFS, as his blog includes the ADFS configuration steps where in my setup I didn’t use ADFS! there for there will be a few caveats.

ADFS allows login for vRealize Automation users that are not in ServiceNow. However, it does not allow login for ServiceNow users that are not in vRealize Automation.

If you use the default authentication like we are going to do here, there are some restrictions and requirements around authentication that you should be aware of, as described in the following table.

SNOW-45

The vRealize Automation Plugin for ITSM 3.0 was released by VMware October 5, 2017 with a couple of Enhancements that I will touch on as part of the Step by Step Installation and configuration guide. I m hoping I do it justice, so lets dive right in.

The vRealize Automation plug-in for ServiceNow enables ServiceNow users to deploy virtual machines and perform day 2 actions on CMDB resources using vRealize Automation catalog and governance capabilities.

The vRealize Automation plug-ins for ServiceNow 3.0 works only with vRealize Automation 7.3, and are available only for the ServiceNow Istanbul and Jakarta releases. Also, the optional ADFS configuration , still uses ADFS 2.0.

For previous iterations of the ServiceNow ITSM plug-in please visit the solution exchange and search for ITSM. You will find ITSM 1.0 and ITSM 2.0

The latest version of the plug-in still supports vSphere and Amazon virtual machine provisioning but unlike the previous versions, we now have added support for Azure, and XaaS blueprints as well, including day 2 operations like Power ON/OFF, Reboot, and Destroy.

Stage 1 – Configuring a MID Server

Before installing the plug-in, you must configure a Management, Instrumentation, and Discovery (MID) Server to facilitate communication between ServiceNow and vRealize Automation.

Creating a MID Server User Account in ServiceNow

  • Log in to your ServiceNow portal and type System Security in the search field.
  • Expand Users and Groups > select Users > Click New to create a new user account.

SNOW-1

  • Fill the required information and click Submit

SNOW-2

  • Find the user you just created by using the search field and select it from the list by clicking on it.

SNOW-3

  • At the bottom of the screen, click Edit within the Role tab.

SNOW-4

  • Search for the mid_Server role and add it the user account, then click Save to get back to the user information page.

SNOW-5

SNOW-6

  • Enter a password for the user account and click Update.

SNOW-7

  • Now lets logoff and login back to ServiceNow using the MID server user to verify that the account is working properly, then logoff.SNOW-9SNOW-10

Installing and Configuring a MID Server Instance

In this step we will cover how to install and configure a MID Server instance which can be done on any servers in your DMZ or private Network as long as we have access to internet where we can communicate with our ServiceNow instance.

  • Login back to your ServiceNow instance with your admin account
  • Search for Mid Server in the search field and select Downloads

SNOW-11

  • Select the appropriate Mid Server package for your desired operating system, in our case here we will download the Windows 64 bit
  • On your Mid Server, create a folder called <MID Server> on your C: drive and then create a sub-folder and give it the name of your Mid Server.
  • Extract the package you downloaded into your <MID Server>/Server name folder. The resulting directory structure would be  //agent

SNOW-12.jpg

  • Navigate to the //agent directory and edit the config.xml file as follows:

Change 1
– Find the <parameter name=”url” value=”https ://YOUR_INSTANCE.service-now.com”/> element and change the value to the URL of your ServiceNow instance.

Change 2
– Enter the MID user credentials you created earlier in the mid.instance.username and mid.instance.password parameters.

Change 3
– Find the <parameter name=”name” value=”YOUR_MIDSERVER_NAME”/> element and change the value for the MID Server name. Use the same name you’ve used form the directory earlier.

Change 4 (Optional)
– Enter connection information for the proxy server. Remove the appropriate comment tags from the proxy configuration information. For example, you can configure the mid.proxy.use_proxy, mid.proxy.host, mid.proxy.port, mid.proxy.username, and mid.proxy.password.

  • Save the config.xml file and execute the start.bat script to start the service.

SNOW-13

  • Login back to your ServiceNow instance with your admin account
  • Search for Mid Server in the search field and select Server

SNOW-14

  • Select the Mid Server name by clicking the check box and select validate from Actions menu on the selected row. click OK to accept the initial criteria.

SNOW-15

 

Stage 2 – Installing the vRealize Automation Plug-in For ServiceNow

Now its time to install the XML plug-in which you must download from the Solution Exchange website Here for your ServiceNow version, either Istanbul or Jakarta type instance.

The plug-in when installed enables vRealize Automation to do the following :

  • Creates vRealize Automation Catalog and Resources menu items within the ServicesNow self-service module.
  • Creates a workflow for requesting vRealize Automation items.
  • Creates the catalog admin role and assigns it to the System Administrator.
  • Grants the users with the catalog admin role access to the integration > vRealize Automation module.

Procedure

  • Log in to your ServiceNow portal as a system administrator and type System System Update Sets in the search field.
  • Select Retrieved Update Sets from the menu and click on Import Update Set From XML

SNOW-16

  • Click Choose File on the dialog to choose the file to upload, and then select the vRealize Automation ServiceNow XML file you downloaded from the solution exchange and click Upload.

SNOW-17

  • In the Retrieved Update Sets list, select the vRealize Automation ServiceNow update set in the Name column and then Loaded in the State column.

SNOW-18

  • Select Preview Update Set to validate the update set before committing it. A dialog box confirms update set validation

SNOW-19

SNOW-20

  • Inspect the update set information, and then click Commit Update Set.

SNOW-21

  • A dialog box opens automatically after you click Commit Update Set while the commit action is in progress. A Close button appears on the dialog when the commit completes. Click this button to dismiss the dialog.

NOW-22

  • Click Udpate

SNOW-23.jpg

  • Select Retrieved Update Sets in the left menu and verify that the VMware update set has a status of Committed.

SNOW-24

Stage 3 – Configure Users for the vRealize Automation Plug-in for ServiceNow

You can configure users either before or after installing the vRealize Automation plug-in for ServiceNow. as I mentioned before we not leveraging ADFS here

Add the role vra_user in ServiceNow for all users that must access vRealize Automation, including vrasn_end_user, vrasn_catalog_admin, and vrasn_itil_user, to enable those users to see vRealize Automation catalog items.

  • Search for System Security and select Users and Groups > Users. Type vra into the user search. add the vra_user role to the above mentioned built-in users for now,  in addition to any user that must access vRealize Automation which you can do at the end.

SNOW-25

SNOW-27

  • Verify and, if necessary, update the appropriate users and roles in ServiceNow. See
    Creating Users and Associating to a group and Creating Roles for more information about working with users, groups, and roles in ServiceNow.
  • The ServiceNow plug-in for vRealize Automation uses the following ServiceNow roles:

SNOW-26

Stage 4 – Configure the vRealize Automation Workflow for Requested Items

The system admin can configure the vRA Workflow for Requested Item using the workflow editor.
At a minimum, you must assign the approval group that contains your ApprovalMgr. When users request vRealize Automation catalog items, this workflow runs, and approvals are sent to the ApprovalMgr within the approval group before the request is submitted to vRealize Automation.

Follow the steps below to use your own approval group and add it to the vRealize Automation workflow:

  • Search for Workflow Editor in the ServiceNow navigation pane and click it.

SNOW-28

  • Search for vRealize Automation Workflow for Requested Item and open it by clicking on it.

SNOW-29

  • Click the menu button and select Checkout.

SNOW-30

  • Double-click the Approval group stage in the workflow

SNOW-31

  • Click the Edit Groups button. Search the list of groups and make the appropriate selections, then Lock your selection by clicking the Lock icon -> Click Update -> Click the menu button -> Click Publish.

SNOW-32

  • By default you will see that the vRealizeAutomaion-ApprovalManagersGroup is already added.  in my instance I made sure that the ServiceNow System Administrator is part of this group.

Stage 5 – Set Basic Configurations the vRealize Automation Plug-in for ServiceNow

You must set up a vRealize Automation integration user. ServiceNow requires this user to import catalog items, categories, request statuses, and resources from vRealize Automation.
In order to import items, the integration users must be a business group manager within the business groups that you want ServiceNow to manage. The integration user does not require a role within ServiceNow.

Procedure

  • Log in to vRealize Automation as a business group manager.
  • Edit your business groups and assign the integration user as a business group manager. in my lab as you see below i will be using the cloudadmin which is a member of the cloudadmins group which has all the roles within vRealize Automation in addition to all the Business group Roles.

SNOW-33

Now that we installed the vRealize Automation plug-in for ServiceNow, and configured users and the integration user “cloudadmin“, we can complete the set up with basic configurations.

  • Search for Integration-vRealize Automation in the ServiceNow navigation pane -> click on Basic Configuration -> Enter the appropriate settings for your MIDServer Name, vRealize Automation tenant, URL, Integration Username and Password and plug-in.

Note : The MidServer Name should be the same as the Server folder name you created at earlier stage when you extracted the Mid Server config files.

SNOW-44

Stage 6 – Register the Plug-in for ServiceNow as a vRealize Automation OAuth 2.0 Client.

After setting up Basic Configurations, you must register the plug-in as a vRealize Automation OAuth 2.0 client.

To register the plug-in, you must provide user credentials to authenticate to vRealize Automation. we have two options here :

Option 1 : If you plan to use the vsphere.local tenant, you can use the administrator from the vsphere.local tenant. Set administrator as the username in the Register the Plug-in as a vRealize Automation OAuth 2.0 client dialog.

Option 2: Use the system admin, is to set up a user with local user and tenant admin roles within your tenant and provide these user credentials. This option registers the
ServiceNow plug-in only in the specified tenant. Providing the same tenant is set in Basic Configurations, this tenant is configured for the end users.

in my case we will be using Option 1.

Procedure

  • Search for Integration-vRealize Automation in the ServiceNow navigation pane -> Click Client Registration
  • Enter the user credentials in the Register the Plug-in as a vRealize Automation OAuth 2.0 Client dialog and since we are using Option 1, we will enter Administrator as the user and provide the password. – > click Submit

SNOW-35

  • Set the Client ID and Client Secret in the Set the Client ID and Client Secret dialog. You must choose what to set. for me I used the same account and password as the Client ID and Client Secret.

SNOW-36

  • Once set, the values are saved in the vrasn.clientID and vrasn.clientSecret properties within Integration > vRealize Automation > System Properties. Client ID and Client Secret are later used to get the access token of the users on login within the tenant specified in Basic Configurations.
  • On completion, you are redirected to the Basic Configurations page.

Note : You MUST logoff from ServiceNow and login again into the portal so you can be redirected to vRA ( you must be on Intranet, so you can reach vRA ) and logon using the integration User. This has to happen at least once after that is just black magic.

After that you can even access ServiceNow portal from the internet and when you are redirected to vRA obviously it will fail since you can’t reach vRA from the internet . Here you can re-enter the ServiceNow URL again and it will let you in the 2nd time. you can even request vRA blueprint .

Stage 7 – Configure and Run Scheduled Import Jobs in ServicesNow

On a first time install of the plug-in, you must manually execute scheduled jobs to import the catalog and resources. Though there is a default schedule for running jobs, you should edit the schedule time in each import according to your needs as you execute each job.

For example, you might want to import catalog items every 10 minutes for high
provisioning use.

The plug-in provides scheduled imports with the following functions. Scheduled imports should be configured and run in the order shown in the table below :

SNOW-37

SNOW-39

Procedure

  • Log in as the ServiceNow System admin
  • Search for Integration-vRealize Automation in the ServiceNow navigation pane and click on Scheduled Imports

SNOW-38

  • This would be a good time to Click on the applicable job name and change the Repeat Interval in Days, Hours, Minutes, and Seconds and update the Import Job Schedule based on your needs
  • Run scheduled jobs in the order shown in the table. Ensure that each job is complete before starting the next one. Completed jobs are shown as processed in the Scheduled Import Queue
  • For now will execute each manual based on the order outlined in the table mentioned above by opening the import job and click Execute Now

SNOW-40

  • Completed jobs are shown as processed in the Scheduled Import Queue. Click the Updated column which you need to add of the Scheduled Import Queue to refresh. The last updated time of the corresponding properties for these scheduled imports is also updated.
  • One thing I had to do in my instance which is mentioned in the Troubleshooting section of the Plug-in documentation is that in some cases, you may need to clear the Value field of the corresponding property in Integration > vRealize
    Automation > Properties and update the property prior to executing the appropriate scheduled import. Once the Value field was clear for all 5 records I started seeing all the jobs in the Scheduled Import Queue when I executed them in order.

Stage 8 – Configure the vRealize Automation Catalog in ServiceNow

Now its time to Choose the catalogs that you want end users to use for provisioning requests.

Procedure

  • Log in a the catalog admin or system admin
  • Select the vRealize Automation Catalog, then clear / delete all the default widgets. if you don’t that you wont see the Add here Section when you select the Category later.
  • Select the plus sign in the upper right corner to add vRealize Automation services, known as Catalog Categories in the ServiceNow, for provisioning

SNOW-41

  • Highlight the Catalog categories in the center pane -> Select Category Items to display the items within the Category and select Add Here based on where you want to place within the catalog page.

SNOW-42

  • Repeat the process for others Categories, to setup your final catalog and start provisioning.

SNOW-43

The End Eh!

 

Automation and Orchestration ITSM vRealize Automation

Virtual Container Host As A Service [VCHAAS] With vRealize Automation – vRA 7.x

vSphere Integrated Containers Engine is a container run-time for vSphere, allowing developers familiar with Docker to develop in containers and deploy them alongside traditional VM-based workloads on vSphere clusters, and allowing for these workloads to be managed through the vSphere UI in a way familiar to existing vSphere admins.

2017-04-24_12-55-08

vSphere Integrated Containers comprises three major components:

  • vSphere Integrated Containers Engine, a container runtime for vSphere that allows you to provision containers as virtual machines, offering the same security and functionality of virtual machines in VMware ESXi™ hosts or vCenter Server® instances.
  • vSphere Integrated Containers Registry, an enterprise-class container registry server that stores and distributes container images. vSphere Integrated Containers Registry extends the Docker Distribution open source project by adding the functionalities that an enterprise requires, such as security, identity and management.
  • vSphere Integrated Containers Management Portal, a container management portal that provides a UI for DevOps teams to provision and manage containers, including the ability to obtain statistics and information about container instances. Cloud administrators can manage container hosts and apply governance to their usage, including capacity quotas and approval workflows.

These components currently support the Docker image format. vSphere Integrated Containers is entirely Open Source and free to use. Support for vSphere Integrated Containers is included in the vSphere Enterprise Plus license.

Now that we are done with the intro, we will only be focusing on VIC Engine in this post and how we can leverage vRealize Automation 7.x to make it even better and faster to deploy by users as a service.

I have been playing with vSphere Integrated Containers for a while now and since the early beta days. I can tell you that deploying and deleting the VCH Endpoint so many time was a bit painful since the command line is so rich including so many parameters that you can choose from where some are mandatory and some are optional, which of course can be a bit overwhelming specially when you fat finger some of these parameters as often as I do.

Example of the Linux command line with some of its parameters to deploy a Virtual Container Host on vSphere, looks something like this :

./vic-machine-linux create –name VCH_Name -t ‘UserName@domain.com:Password@vCener_IP_or_FQDN‘ –compute-resource Target_Cluster –public-network Target_Managment_Network –bridge-network Target_Bridge_Network –image-store DataStore_Name –volume-store DataStore_Name :default –dns-server DNS_IP_Or_FQDN –public-network-ip VCH_IP –public-network-gateway Gateway_IP/CIDR–force –no-tlsverify

During all this testing time I had to save the entire command line in a text file with all of its parameters, so I can simply copy and past the command when I need to, after replacing some of these parameters with the values I wanted to use, so I don’t have to type it over and over every single time I decide to deploy or delete a Virtual Container Host to test.

Having in mind our main use case for vRealize Automation and that is IT Automating IT , I wanted to find a way where I can somehow provide this as a service in my home lab where I can simply select the service and submit the request from the catalog.

Well, I did that some time ago and today I m excited to share that publicly on my new blog with all of you out there !

So please sit tight, enjoy the ride as I Explain…

In vRealize Orchestrator I managed to leverage the Guest Script Manager to take the command line with the majority of its parameters and automate the life out of it by creating the desired workflows use cases ( The Creation and Deletion of the VCH process ) then use these workflows as Anything as a service XaaS type blueprints in vRA to essentially present it as an item catalog where users can easily request to create a new VCH or delete an existing one.

Of course there are many other ways on how you can do the VCH automation piece and probably even better than the one I’m sharing here, but this is simply how I did it!.

Steps and User Experience

ScreenShot-1

1. Request the Service from the Catalog


ScreenShot-2

2. Provide the VIC Machine Information


ScreenShot-3

3. Provide the targeted vCenter Server


ScreenShot-4

4. Provide the VCH Configuration needed for the deployment


ScreenShot-5

5. Workflow executes in vRO to deploy the VCH endpoint on vSphere

This is so great on so many levels since now you can easily entitle any development groups for example, that really don’t have to know a whole lot on how VIC works and are simply able to request the service to access a docker API and provision Containers.

You can also wrap an approval / governance policy around it which vRA can easily provide and have all the parameter’s values available to users in drop-down list format within the XaaS Forms on the request page, so the requester don’t have to wonder when filling out these form requests, things like which cluster I should be deploying this to, What network I should be selecting, What Storage I should use and more importantly standardize these inputs to avoid typos to standardize the service overall so its consistent across the IT organization.

 

I tested both XaaS blueprints ( Create and Delete VCH ) and both works like a charm. I still though have to clean it up a bit but I will be sharing both the vRO package and the XaaS blueprints here on this post so others can use it or build on top of it and make it even better since I am not really an expert when it comes to developing vRO workflow but I m doing my best to learn even more.

High level Deployment Guide

Please be aware that this has not been tested yet outside my lab, so please provide feedback if you have any issues, in case I need to tweak things :

  1. Download the VCH 1.0 (Here) or VCH 1.1 (Here) Automation package depending on the VIC version bundle you have or planning to download and extract its content. The package includes the vRO package that includes the VCH workflows and the 2 XaaS VCH Blueprints for the VCH Create and Delete operation.
  2. If you download the 1.0 VIC bundle (Here) make sure its extracted to /workspace/vic on the desired VIC machine (The Machine that host the VIC Bundle), here you will use the VCH 1.0 in step 1.
  3. If you download the 1.1 VIC bundle (Here) make sure its extracted to /workspace/vic on the desired VIC machine (The Machine that host the VIC Bundle), here you will use the VCH 1.1 in step 1.
  4. Import the vRO package into the vRA embedded vRO instance using the vRO client
  5. Use the Cloud Client (Here) to import the two XaaS Blueprints into vRA where you can then publish and entitle them to users.
  6. Confirm that the blueprints are actually pointing to the respective VCH workflows that you imported perilously.

Please make sure to map the right VCH Automation package version with the right VIC Bundle version since some of the command syntax changed in VIC 1.1

Important Deployement Notes

  • This was done using the Guest Script Manager as I mentioned before which is already bundled in the VCH 1.0 vRO package along with the VCH workflows in the vRO package I Exported, so you don’t have to install the GSM yourself.
  • All the fields for this version is mandatory and can’t be skipped for now, but its something that you can definatly modify if you want to.
  • All the fields are static, so later on you can configure some of the field’s in XaaS forms as drop-down lists and provide value from you own environment such as Clusters Name, Network port-groups or storage..etc
  • The Workflow will deploy VCH with Server-side authentication with auto-generated, untrusted TLS certificates that are not signed by a CA, with no client-side verification. i.e. –no-tlsverify is hard coded as you will see in the create command mentioned below.
  • You have VIC bundle deployed and extracted to a folder called /workspace/vic/ on a Linux machine called out in the XaaS forms as the VIC Machine VM available within the same vCenter/environment. This can be the vRA appliance as well and you can modify the original Workflow to preset the values for the VIC machine properties section (2nd Screenshot above) so the user don’t even have to select it or go through the first request tab.
  • The VCH deployment can be used and manually added in Admiral using the certificate type credentials which can be obtained from the VIC Machine from the VCH folder created after a successful deployment . for example if you deploy an endpoint called VCH01, both the server-cert.pem and server-key.pem would be located in /workspace/vic/VCH01 folder on the VIC Machine.
  • This is the command line that being executed on the VIC Machine VM ( which is the VM that has the VIC bundle deployed and extracted to /workspace/vic ) . All the parameters that are used between vRA and vRO are in-between brackets.

The Create Command Used in the Create Workflow for VIC 1.0

./vic-machine-linux create --name [vchName] --appliance-cpu [vchCpu] --appliance-memory [vchMem] -t '[vCenterUserName]:[password]@[vCenterIp]' --compute-resource '[clusterName]' --public-network [publicNetwork] --bridge-network [bridgeNetwork] --image-store [imageStore] --volume-store [volumeStore]:[volumeName] --dns-server [dnsServerIp] --public-network-ip [vchPublicIp] --public-network-gateway [vchPublicGateway]/[vchPublicGatewaySubnet] --force --no-tlsverify

The Create Command Used in the Create Workflow for VIC 1.1

./vic-machine-linux create --name [vchName] --endpoint-cpu [vchCpu] --endpoint-memory [vchMem] -t '[vCenterUserName]:[password]@[vCenterIp]' --compute-resource '[clusterName]' --public-network [publicNetwork] --bridge-network [bridgeNetwork] --image-store [imageStore] --volume-store [volumeStore]:[volumeName] --dns-server [dnsServerIp] --public-network-ip [vchPublicIp]/[vchPublicIpSubnet] --public-network-gateway [vchPublicGateway] --force --no-tlsverify

You notice if you compare the create command between the two versions that some of the parameters were changed. i.e.  –appliance-cpu  renamed to –endponit-cpu

The Delete Command Used in the Delete Workflow is same for both versions

./vic-machine-linux delete --force -t '[vCenterUserName]:[password]@[vCenterIp]' --compute-resource '[clusterName]' --name [vchName]

Have fun Everyone!

Automation and Orchestration vRealize Automation vsphere integrated containers