Installing and Configuring Agents for Container-Based Systems

When you install Automic Automation Kubernetes Edition, this is the moment to install your Agents. You can do so manually, in a container, using the Automic Web Interface, or using scripts.

Important!

Regardless of how you install your Agents, they remain outside the AAKE cluster.
CAPKI is not supported in the Automic Automation Kubernetes Edition but you can use the ServiceManager without CAPKI to start your agents, see ServiceManager.

Once you have installed them, you have to configure them so that they can connect to the AAKE system.

Important! TLS/SSL Agents (in containers and on-premises) as well as the TLS Gateway, when used for the Automic Automation Kubernetes Edition, establish a connection to an ingress / HTTPS load balancer, which requires a certificate for authentication.

Make sure that address of the load balancer is defined on both sides: the Automation Engine and the Agent / TLS Gateway and that your HTTPS load balancer has the required certificates in place. For more information, see Connecting to AWI, the JCP and REST Processes Using an Ingress.

For more information about the TLS/SSL server authentication implementation, see TLS/SSL Considerations for Automic Automation .

Non-TLS/SSL Agents, when used for the Automic Automation Kubernetes Edition, establish a connection to a TCP load balancer, which must be reachable for the Agent. The address of the load balancer must be defined on both sides: the Automation Engine and the Agent.

This page includes the following:

Prerequisites

For an Automic Automation Kubernetes Edition system, before installing the Agents, you must cover the following topics:

Installing the Agents Manually for AAKE

You can install your Agents manually. Since the Agents for the Automic Automation Kubernetes Edition remain outside the AAKE cluster, the manual Agent installation is basically the same as in an on-premises environment; therefore, the instructions are located in a common section. For more information, see Installing the Agents.

The only difference is that in AAKE, the Agents, TLS Gateway, and CallAPIs establish a connection to a load balancer - either TCP or HTTPS - and not directly to a communication process (CP) or Java communication process (JCP).

Important! When you install or upgrade Agents manually for an Automic Automation Kubernetes Edition system, you have to make sure that you configure your Agents and/or TLS Gateway to reach the TCP or HTTPS load balancer and not the CP or JCP directly. Also, make sure that your HTTPS load balancer has the required certificates in place. For more information, see Connecting to the AAKE Cluster.

Installing Containerized Agents for AAKE

You can also install containerized Java, UNIX or Windows Agents to be used with your Automic Automation Kubernetes Edition system by building and running a Docker image hosting one of these Agents.

These Agents too remain outside the AAKE cluster and their installation is the same as in an on-premises environment; therefore, the instructions are located in a common section. For more information, see Installing the Agents and Installing Containerized Agents.

Important! When you install or upgrade containerized Agents for an Automic Automation Kubernetes Edition system, you have to make sure that you configure your Agents to reach the TCP or HTTPS load balancer and not the JCP directly. Also, make sure that your HTTPS load balancer has the required certificates in place. For more information, see Connecting to AWI, the JCP and REST Processes Using an Ingress.

Installing the Agents from the Automic Web Interface

You can create a new Agent and download a pre-configured Agent in Client 0 in the Process Assembly perspective.

You can also do the same in directly from the Administration perspective in any Client in the system. However, the Agent object is always also available in Client 0. When you download a pre-configured Agent, you don not have to make any additional definitions. However, you can change them as needed in Client 0.

This applies to UNIX, Windows, all Java based Agents (also in containers) and the TLS Gateway

Watch the Video: Adding and Downloading UNIX Agents in AWI

Adding and Downloading an Agent

Open the Administration perspective and select Agents & Groups > Agents from the navigation pane on the left.
You have two options:
- Right-click anywhere on the list and select Add > Add Agent
- Click the Add Agent button on the toolbar
Select the relevant Agent from the list and click the Add button. The Object Name dialog is displayed.
Enter a descriptive Name.
Optionally, enter a short and descriptive Title that helps you recognize the Agent.
Click OK.

The new Agent is available in the Agents list.
You can download an Agent either from the Administration or the Process Assembly perspective:
- In the Administration perspective, add an Agent as described before. On the Agents list you have two options:
  - select the Agent and click the Download Agent button on the toolbar
  - right-click the relevant Agent and select Download Agent
- In the Process Assembly perspective, right-click the relevant Agent object and select Download Agent.
The Download Agent dialog is displayed. The Name field is populated automatically.
Define the corresponding Operating System and Architecture.
Optionally, select the ServiceManager checkbox.

Note: When the Service Manager checkbox is not selected, the Operating System and Architecture fields are disabled for Java based Agents. Also, when you select a Windows Agent, the Operating System is Windows by default and the field is disabled.
Once you have defined all parameters, click Download. Your browser notification shows the Agent .zip file is being downloaded.
Unpack the .zip file on the same machine on which the Agent runs.
Once the file is unpacked, you must do the following:

UNIX (Linux) Agents
1. Register to the host with your user ID, for example, AE.
2. Ensure that all files have the correct owner and group entry. The owner must be the same user you used to register (AE) and the group must correspond to the code of the user (AE). Only a privileged user, such as root, can make these modifications.
  
  Example
  - chown AE * changes the owners of all files to AE
  - chgrp Group_name * changes the user groups of all files.
3. For actual operation, the ucxj??? file can be given the permissions of a privileged user such as root.
  - Change the owner to root: chown root ucxj???
  - Set S-Bit (Set-Userid): chmod 4755 ucxj???
  Note: You need at least the permissions 755 for executable objects such as agents.
4. Set the SSL_CERT_DIR and SSL_CERT_FILE environment variables with the User which will start the Agent.
  
  These variables allow you to load the certificates from the TLS/SSL store. The certificates can be stored either in one file per certificate or all certificates in one .pem file :
  - SSL_CERT_DIR location of the trusted CA certificates with each certificate in a separate file, for example,/etc/ssl/certs/
  - SSL_CERT_FILE location of the .pem file with all the trusted CA certificates, for example, /etc/pki/tls/certs/ca-bundle.crt
5. Run the ucxjlx6 binary file to start the Agent.
Windows Agents

Do one of the following:
- Update the trustedCertFolder= parameter in the [AUTHORIZATION] section of the INI file of the Windows Agent, see Agent Windows 64-bit
- Import the JCP cert into the Windows OS store
The downloaded Agent is ready to work.

Installing an Agent Using Scripts

You can use scripts to easily create, download and extract agent packs, as well as start agents running on a Windows or UNIX system.

We have gathered a number of deployment script examples for SQL, REST, Windows, and UNIX agents. They allow you to deploy and start the agents without having to create your own script. You can also merge separate scripts used in the examples into one large script.

More information:

Configuring TLS/SSL Agents for Container-Based Systems

If you use a cloud provider (not self-managed systems) and you deploy an ingress, an HTTPS load balancer and the corresponding certificate are created automatically. The ingress is configured to use the certificate and the address of the load balancer. This address is the endpoint that the Agent uses to connect to and it is configured in the JCP_ENDPOINT parameter of the UC_SYSTEM_SETTINGS variable. The endpoint is then the value defined in the connection= parameter on the [TCP/IP] section of the INI file of the respective TLS/SSL Agent and/or TLS Gateway.

If you do not use a cloud provider (self-managed systems), you have to install your own load balancer and make sure you that you have a certificate in place. You also have to configure the ingress, variables and INI files yourself. For more information, see Connecting to AWI, the JCP and REST Processes Using an Ingress.

You can also define where to reach the JCP before the installation if the following applies:

you know the relevant JCP address to be used before the installation
you have not enabled an ingress (ingress: false)

In this case, you can use the JCP_WS_EXTERNAL_ENDPOINT environment variable in the values.yaml file to add the URL.

Example

JCP_WS_EXTERNAL_ENDPOINT: "https://ws-temp.10.49.164.77.xip.io:443"

When an Agent starts using the value defined in the connection= parameter, it receives all entries from the JCP_ENDPOINT variable and stores the information in the JCPLIST section of its configuration (INI) file. In this case, the list contains the addresses of all load balancers available. The Agent can then select an available endpoint from the list the next time it starts or reconnects to the Automation Engine.

More information:

Next step:

Installing the Additional Components - Container-Based Systems