Use Hop Nodes on Oracle Linux Automation Manager

1
0
Send lab feedback

Use Hop Nodes on Oracle Linux Automation Manager

Introduction

Oracle Linux Automation Manage supports a service mesh technology based on the upstream receptor project. The service mesh links controller, hop, and execution nodes into an overlay network through a daemon-based receptor application.

Oracle Linux Automation Manager introduces the hop node as part of the service mesh. This node type allows relaying tasks from control plane nodes to execution nodes on remote or restricted networks in the same way SSH uses a jump host. This implementation enables running jobs across different execution nodes and moving tasks closer to the systems needing automation.

In the free lab environment, the below inventory defines the cluster deployment. To help automate the cluster installation on your hardware, check out the playbook in the Oracle Linux Automation Manager section of the ansible-collections project.

This inventory creates a cluster consisting of two control plane nodes, two execution nodes, a hop node with a single remote execution node, and a remote database.

playbook-inv

This image shows the service mesh topology for this cluster.

local-remote-exec-config

This tutorial shows several methods to check the status of a service mesh and confirm the topology communication between the various nodes.

Objectives

In this lab, you'll learn how to:

  • List the capacity of the control plane and execution nodes
  • View the Service Mesh status for a given cluster node
  • View the Service Mesh status using an API call

Prerequisites

  • A cluster with Oracle Linux Automation Manager installed and Service Mesh configured
  • An Oracle Cloud Infrastructure (OCI) account
  • A user in the OCI account with permission to work with resources in a compartment
  • Access to that accounts credentials and OCID information



For details on installing Oracle Linux Automation Manager 2, see the Oracle Linux Automation Manager Installation Guide .

Login to the WebUI

Note: When using the free lab environment, see Oracle Linux Lab Basics for connection and other usage instructions.

Information: The free lab environment deploys a running Oracle Linux Automation Manager multi-node cluster. The deployment takes approximately 30 minutes to finish after launch. Therefore, you might want to step away while this runs and promptly return to complete the lab.

  1. Open a terminal from the Luna Desktop and configure an SSH tunnel to the deployed Oracle Linux Automation Manager instance.

    ssh -L 8444:localhost:443 oracle@<hostname or ip address>

    In the free lab environment, use the IP address of the control-node01 VM as it runs one of the Oracle Linux Automation Manager control plane nodes.

  2. Open a web browser and enter the URL.

    https://localhost:8444

    Note: Approve the security warning based on the browser used. For Chrome, click the Advanced button and then the Proceed to localhost (unsafe) link.

  3. Log in to the Oracle Linux Automation Manager WebUI. Use the Username admin and the Password admin created during the automated deployment.

    olam2-login

  4. The WebUI displays after a successful login.

    olam2-webui

Confirm Instance Groups in the WebUI

An Instance Group allows for grouping instances within a cluster based on policies. These policies determine the instance group behavior and execution of which jobs.

  1. Click Instance Groups under Administration in the navigation menu.

    olam2-instance-grp-menu

  2. Review the Instance Groups page.

    olam2-instnace-grp-page

    The page shows the capacity based on policy settings.

See the Managing Instance Groups under the Setting Up Resources chapter of the Oracle Linux Automation Manager User's Guide documentation for more details on these policy settings.

List Instances

Using the awx-manage utility, an administrator can configure and list instances associated with the instance groups (queues). An administrator performs this action from any of the control plane nodes within the cluster.

  1. Switch to the terminal window.

  2. Connect to the Oracle Linux Automation Manager user.

    sudo su -l awx -s /bin/bash

  3. List the instances.

    awx-manage list_instances

    Example Output:

    [awx@control-node01 ~]$ awx-manage list_instances
[controlplane capacity=272]
	10.0.0.140 capacity=136 node_type=control version=19.5.1 heartbeat="2023-02-28 20:59:55"
	10.0.0.141 capacity=136 node_type=control version=19.5.1 heartbeat="2023-02-28 21:00:00"
  
[execution capacity=408]
	10.0.0.150 capacity=136 node_type=execution version=19.5.1 heartbeat="2023-02-28 21:00:05"
	10.0.0.151 capacity=136 node_type=execution version=19.5.1 heartbeat="2023-02-28 21:00:07"
	10.0.0.160 capacity=136 node_type=execution version=19.5.1 heartbeat="2023-02-28 21:00:09"

    The output shows the controlplane and execution queues and each associated node. Hop nodes do not appear in the output as they are not associated with a queue.

  4. Disconnect from the Oracle Linux Automation Manager user.

    exit

    The results return the prompt to the oracle user account on the free lab environment.

Show the Service Mesh Status

With the service mesh running, getting the status of the service mesh and the associated nodes is possible.

  1. Use the existing terminal window.

  2. Get the status of the service mesh.

    sudo receptorctl  --socket /var/run/receptor/receptor.sock status

    Example Output:

    [oracle@control-node01 ~]$ sudo receptorctl  --socket /var/run/receptor/receptor.sock status
Node ID: 10.0.0.140
Version: +g
System CPU Count: 2
System Memory MiB: 15701
   
Connection   Cost
10.0.0.170   1
10.0.0.151   1
10.0.0.150   1
   
Known Node   Known Connections
10.0.0.140   {'10.0.0.150': 1, '10.0.0.151': 1, '10.0.0.170': 1}
10.0.0.141   {'10.0.0.150': 1, '10.0.0.151': 1, '10.0.0.170': 1}
10.0.0.150   {'10.0.0.140': 1, '10.0.0.141': 1}
10.0.0.151   {'10.0.0.140': 1, '10.0.0.141': 1}
10.0.0.160   {'10.0.0.170': 1}
10.0.0.170   {'10.0.0.140': 1, '10.0.0.141': 1, '10.0.0.160': 1}
   
Route        Via
10.0.0.141   10.0.0.150
10.0.0.150   10.0.0.150
10.0.0.151   10.0.0.151
10.0.0.160   10.0.0.170
10.0.0.170   10.0.0.170
   
Node         Service   Type       Last Seen             Tags
10.0.0.141   control   Stream     2023-03-01 14:51:08   {'type': 'Control Service'}
10.0.0.170   control   Stream     2023-03-01 14:51:13   {'type': 'Control Service'}
10.0.0.140   control   Stream     2023-03-01 14:51:59   {'type': 'Control Service'}
10.0.0.150   control   Stream     2023-03-01 14:51:08   {'type': 'Control Service'}
10.0.0.151   control   Stream     2023-03-01 14:51:08   {'type': 'Control Service'}
10.0.0.160   control   Stream     2023-03-01 14:51:08   {'type': 'Control Service'}
   
Node         Work Types
10.0.0.141   local
10.0.0.170   local
10.0.0.140   local
10.0.0.150   ansible-runner
10.0.0.151   ansible-runner
10.0.0.160   ansible-runner

    The receptorctl command is the front-end CLI that interacts with the service mesh over its control socket interface. Passing --help to the receptorctl command shows the CLI options and different commands.

  3. Run a traceroute from the control plane node to the remote execution node.

    sudo receptorctl  --socket /var/run/receptor/receptor.sock traceroute 10.0.0.160

    Example Output:

    [oracle@control-node01 ~]$ sudo receptorctl  --socket /var/run/receptor/receptor.sock traceroute 10.0.0.160
0: 10.0.0.140 in 88.687µs
1: 10.0.0.170 in 684.183µs
2: 10.0.0.160 in 1.142118ms

    Note: If you see special characters in the output that fails to render, switch the encoding in the terminal window to UTF-8 by clicking Terminal > Set Encoding > Unicode in the menu.

    In the above example, the route starts on the first control plane node, passes through the hop node, and lands on the remote execution node.

Check the Service Mesh Status in the WebUI

The Oracle Linux Automation Manger API uses a rest api call that allows an administrator to view the status information about each node in the service mesh cluster.

  1. Switch to a browser window in the free lab environment and enter the URL.

    https://localhost:8444/api/login/

    Note: Approve the security warning based on the browser used, if necessary. For Chrome, click the Advanced button and then the Proceed to localhost (unsafe) link.

  2. Log in to the Oracle Linux Automation Manager REST API. Use the Username admin and the Password admin created during the automated deployment.

    olam2-restapi-login

  3. The REST API displays after a successful login.

    olam2-restapi

  4. Click one of the /api/v2/ hyperlinks from the response area.

    The click performs a GET request and displays all the available API resources.

  5. Scroll to the bottom and click the mesh_visualizer link.

    olam2-mesh-visualizer

  6. Look through the output.

    Notice the different nodes and their specific node_type. The links section shows how each node associates with one another in the service mesh.

Summary

This output shows a running cluster with hop and execution nodes for running playbooks using Oracle Linux Automation Manager. Check out our other labs in the links below.

For More Information

Oracle Linux Automation Manager Documentation
Oracle Linux Automation Manager Training
Oracle Linux Training Station

SSR