Tanzu Observability vRealize Operations Cloud Header

Tanzu Observability – Configuring vRealize Operations Cloud Integration

In this blog post, I am going to cover the configuration and consumption of the Tanzu Observability integration with vRealize Operations Cloud.

  • As this is blog post is released during VMware Explore, under the announcement of the VMware Aria brand for Cloud Management tooling, these products will become
    • vRealize Operations Cloud > VMware Aria Operations
    • Tanzu Observability > VMware Aria Operations for Applications
Recording

Below is a recording I put together, covering the same content as this blog post in 10 minutes or less.

Create a Cloud Services Portal API Token

The official documentation for this integration can be found here.

First, we need to create an API token that provides the following access:

  • Organisation Member
  • vRealize Operations Cloud > vROPs ReadOnly

Go to My Account in the CSP by clicking on your name in the top right-hand corner, then My Account. Select the API Tokens tab and generate an API token.

Save the API Token to a safe space for use in the next step. Continue reading Tanzu Observability – Configuring vRealize Operations Cloud Integration

vRealize Operations ElasticStack Header

Sending vRealize Operations Alerts to ElasticStack (ELK)

This blog post is thanks to an internal query, that I thought should be easy enough to complete, however my usage of an ELK environment is limited, so it was a good chance to dig in and learn something new.

In this blog post, I’m going to detail the configurations for pushing vRealize Operations Alert notifications to ElasticStack (aka ElasticSearch, ELK) using the Notification Webhook feature.

Again, I am not an ELK expert here, so there may (read this as probably) better ways to configure this when it comes to the date handling.

Configure an ingestion timestamp in ELK

One of the first issues I hit when testing all of this, is the fact that ELK doesn’t seem to like the date formats that vROPs alerts uses. Once an index (store of data records) is created, the fields are parsed, and the type attributed to a field cannot be changed. I went through various options to remedy this, so that my logs could be searched based on time stamps, but it seemed not easily feasible. If anyone knows of the best way to achieve this, let me know, see the end of this blog post for more details.

For those of you who do know ElasticSearch, vROPs sends the time/date in the notification payload in the following format "EEE LLL dd HH:mm:ss z uuuu"

The best way I found around this, is to add in the ability to create a ingestion timestamp on the data received by Elasticsearch, and add it to the settings of the created index.

To create this ingestion rule, in your Elastic UI, click on Three Lines to open the navigation options, then click on Dev Tools, under Management.

vROPS ELK - Elastic - Management - Dev Tools

This will give you an in-browser console access to send configurations to the Elastic environment. When reading the documentation, you’ll notice that the configuration for Elastic is provided a lot of the time via API commands and payloads. It seems like this is the preferred way to configure the system, with the UI lacking the ability to make these changes for most options.

Paste the content below the screenshot, which creates a pipeline rule to provide processing on the data that comes into the system.

When the syntax is validated, you will see a small Green Arrow appear to apply the configuration. The right-hand side console window shows the output from running the API call and payload.

vROPS ELK - Elastic - Create pipeline - ingestion timestamp

PUT _ingest/pipeline/set-timestamp
{
  "description": "sets the timestamp",
  "processors": [
    {
      "set": {
        "field": "timestamp",
        "value": "{{{_ingest.timestamp}}}"
      }
    }
  ]
}
Create the outbound webhook in vRealize Operations

Continue reading Sending vRealize Operations Alerts to ElasticStack (ELK)

vRA SaltStack Config Header

Deploying a Windows VM using vRealize Automation & configuring with SaltStack Config – Part 2

The first blog post of this two part series covered getting our vRealize Automation and SaltStack Config environments prepared, a Windows Server template prepared, and a testing a successful deployment that has the SaltStack minion installed.

In this second part, we’ll now focus on setting up out state files to configure the Windows Server to our example requirements and start deploying virtual machines using vRA that are configured by SaltStack Config.

We’ll cover the following areas:

For both blog posts I’ve also recorded an accompanying video detailing the configuration. Below is part two, and you can see the part one video on first blog post.

Configure the SaltStack State Files

The main part of SaltStack is the SLS, or SaLt State file. This is a representation of the state in which a system should be in, contains the configuration information that the system should adhere to, or be configured to. By default, a State file is built using the YAML format.

You can read more about State Files on the official Salt website which gives you a good introduction in getting started, and background information on the configuration I am going to detail below.

As a quick overview, but I really suggest you read the above link if this is your first look into Salt.

# The first line is the ID for the data that follows
my_first_state:
# The second line, two space indented, is state module to be run, in the format {module.function}
  service.enabled:
# The third line, four space indented, are the parameters for the state module
    - name: Spooler

Within a state file, you also have the ability to use a templating language, such as Jinja, which is the default for State Files. This language within a state file is evaluated and computed before the YAML itself, making it useful for writing statements, and computing user inputs or dynamic variables. You can learn more about this templating language in the Salt documentation.

For this blog post example, I am going to configure the following file structure, and explain what is going on in each step. I think the naming makes it obvious which configurations I’ll be passing through to my deployed Windows Server VMs.

Base
- Windows
  - ad-join
  - baseline
  - remote-desktop
  - services
  - software-install
  - users

Each state file will be configured on the SaltStack Config file server, via the UI. The file server, is actually a database on the backend, but looks like a file server configuration within the UI (we won’t dive into how the backend works in this blog post).

To create your folders and file structure: Continue reading Deploying a Windows VM using vRealize Automation & configuring with SaltStack Config – Part 2

vRA SaltStack Config Header

Deploying a Windows VM using vRealize Automation & configuring with SaltStack Config – Part 1

In this two-part blog post series, I’m going to detail what I consider a basic customer use case when deploying new Windows Servers in their environment.

  • Deploy a Windows Server Virtual Machine
  • Add to the Active Directory Domain
  • Install software
  • Configure some system settings

To achieve this, I’m going to use vRealize Automation to deploy the virtual machine, and then the SaltStack Config component to configure the virtual machine once it’s up and running.

vRA SaltStack Config is part of the vRealize Automation product, it comes from the  VMware acquisition of SaltStack (the company). VMware integrated SaltStack Enterprise (the product) into vRA, as either a licence stand-alone component, i.e. you can still buy just SaltStack on its own, or as part of vRealize Automation itself. Additionally, features such as SaltStack Protect+Comply, how now transformed into vRA SaltStack SecOps, an addon licence to the existing product.

You may have previously heard of Salt, the open-source project focusing on the core features of configuration management, but lacks the enterprise features of SaltStack Config, such as (but not limited to) centralised management UI and RBAC. This remains an open-source project, with VMware becoming the guardians of the product.

In this Part 1, we are going to cover the following:

For both blog posts I’ve also recorded an accompanying video detailing the configuration. Below is part one, and you can see the part two video on second blog post.

Preparing the Windows Server Template

For my example, I am using a Windows Server 2019 image. For no other reason than I already had one in my environment.

The following configurations need to be in place:

  • Create a firewall rule for TCP 445 – Allow on all profiles
    • New-NetFirewallRule -Name "SMB445" -DisplayName "SMB445" -Protocol TCP -LocalPort 445
      
      Set-Item (dir wsman:\localhost\Listener\*\Port -Recurse).pspath 445 -Force
      
      Restart-Service winrm
  • Ensure SMB2 is enabled
    • get-smbserverconfiguration | select EnableSMB2Protocol
  • Configure winrm
    • winrm quickconfig -transport:http
  • Set UAC to never notify
    • Select Start > Control Panel 
      
      Click System Security
      
      Under Action Center, choose Change User Account Control settings
      
      Move the slider bar down to the Never notify selection and click OK
      
      Reboot the machine for changes to take effect

These steps should have you fully covered. The best SaltStack resource I could find on configuring your Windows images is here, however most of the information is pointed at examples for Salt running on a Windows image in AWS for example. Which has specific requirements. There is also this VMware Documentation page as well.

vRealize Automation with SaltStack Config integration

Continue reading Deploying a Windows VM using vRealize Automation & configuring with SaltStack Config – Part 1