4.8 Using a relay server

The following procedure assumes that the relay server is already configured. For more information on relay server settings, see “Setting a relay server”.

When using a relay server, follow Steps ① to ⑥ below.

Perform Steps ① to ③ in System Management and Steps ④ to ⑥ in the automation application (AWX). Step ⑦ describes what to specify in the workflow YAML file.

Users who perform Steps ① to ③ must be granted the Primitive role “automation_manager”. Users who perform Steps ④ to ⑥ must be granted the role that the AWX organization has. For details on AWX roles, refer to the AWX manuals listed in “OSS version/edition and reference manuals” in APPENDIX. For overview of organizations, creating organizations, and assigning each role, see “Configuring organization” and “Organization management”. For general information on assigning roles, see “Roles” and “Correspondence between roles and support functions in Ops I”.


[System Management]

① Add a node group.

When a node group is added, an instance group with the node group ID name is automatically created in the automation application (AWX) and associated with the job template. Jobs are executed on one of the nodes in the node group, resulting in the load of job execution to be distributed across multiple nodes. In addition, nodes can be added or replaced without affecting the job template.
For details on adding a node group, see "Node group management".

(Figure) Node Group window

(Figure) Node Group window (Figure) Node Group window

(Figure) Instance Groups window

(Figure) Instance Group window (Figure) Instance Group window

② Add an IP block.

For details on adding an IP block, see "IP block management".

③ Associate nodes and IP blocks with the node group.

A job executed in a node group with no IP block associated with it can access all IP addresses. For information on associating nodes and IP blocks with a node group, see "Node group management".

[Automation application (AWX)]

Steps ④ to ⑥ describe the AWX settings required to use a relay server. For information on standard AWX settings, see “Automation”.

④ Register information of the managed server to be connected from the relay server in the authentication information.

Configure the settings according to the authentication method of the managed server. For example, select [Machine] as the authentication type according to the sever to connect to. Do not use "Outpost" as the name, as it is a reserved word. For details on the settings, refer to the AWX manuals listed in "OSS version/edition and reference manuals" in Appendix.

(Figure) Window to register authentication information for managed server

(Figure) Window to register authentication information for managed server (Figure) Window to register authentication information for managed server

⑤ Create a job template.

Select the instance group automatically generated at Step ① as the instance group for the job template. As a result, the node group is associated with the job template.

(Figure) Job template window

(Figure) Job template window (Figure) Job template window

(Figure) Instance group selection window

(Figure) Instance group selection window (Figure) Instance group selection window

⑥ Specify “OpsI Outpost EE” as the execution environment for the job template.

"OpsI Outpost EE" is provided by default in AWX for Ops I.

(Figure) Execution environment window

(Figure) Execution environment window (Figure) Execution environment window


[What to specify in the YAML file]

⑦ Specify the job template created at Step ④ in the workflow YAML file.

In the workflow YAML file, specify the provided Ops I component "awx.run_job_template" for the "action" of the Task model and define the job template created at Step ④ for the "input".
This allows the job template associated with the node group to be used from the workflow.

When a user launches a catalog item, the AWX job template is executed at the step where awx.run_job_template is set in the workflow, and the job is registered in the control plane. The agent of the relay server acquires the job and executes it against the managed server.
For information on the workflow YAML file, see "Workflow".

(Figure) Flow of job execution

(Figure) Flow of job execution (Figure) Flow of job execution


[Restrictions on the number of jobs]

The number of jobs that can be run simultaneously on a single node is limited based on the hardware configuration; for example, the maximum number of jobs is 12 in the case of the minimum configuration described in “Prerequisites for installing RPM package”. If more jobs than the limit are run at the same time, the jobs exceeding the limit are placed in pending status, one of which is executed when one of the running jobs completes. However, a pending job that is not executed within the maximum waiting time of 5 minutes results in an error.
To run more jobs than the limit, you need to divide the node and ensure that the limit per node is not exceeded.


[Monitoring outpost operations]

It is recommended that you periodically check to see if the agent is running properly. It can be checked by seeing the status of the Ops I window or by running the status monitoring command. Process monitoring is also possible.

  • Checking by seeing the status of the Ops I window:
    If the status is displayed as “Not Ready” on the node details window, the agent is stopped. For information on the node details window, see “Node management”.

  • Checking by running the status monitoring command “opsiopctl.sh status”:
    The agent runs the chisel and k3s systemd services, and the status of each service is output on the command line as a result of executing “opsiopctl.sh status”. If the service is stopped, “inactive” is displayed. If the status of either of the services is not “active”, “Outpost Agent is NotActive” is output and “1” is returned as the return value of the command.
    The startup status can be checked by periodically running “opsiopctl.sh status” and viewing the return value of the command (0 or 1). For details on the commands, see [Monitoring outpost agent status: opsiopctl.sh status] in “Command scripts for RPM package”.

  • Process monitoring: process monitoring can be performed for chisel and k3s. The paths to the executable files for the processes are as follows.

    • chisel: /opt/opsi/outpost/bin/chisel
    • k3s: /opt/opsi/outpost/bin/k3s