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, 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.
TLS/SSL Agents and the TLS Gateway, when used for the Automic Automation Kubernetes Edition, establish a connection to an ingress / HTTPS load balancer and not the JCP directly. The ingress / HTTPS load balancer must be reachable and requires a certificate for authentication. The address of the load balancer must be defined on both sides: the Automation Engine and the Agent / TLS Gateway.
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 Manually.
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 the Agents from the Automic Web Interface
You can create a new Agent and download a pre-configured Agent directly from the Administration perspective. You can do so 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.
In Client 0, you can also download an Agent from the Process Assembly perspective.
This example video walks you through the installation of a Linux Agent in Automic Automation:
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
-
Register to the host with your user ID, for example, AE.
-
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.
-
-
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.
-
-
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
-
-
Run the ucxjlx6 binary file to start the Agent.
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
TLS/SSL Agents and the TLS Gateway, when used for the Automic Automation Kubernetes Edition, establish a connection to an ingress / HTTPS load balancer and not the JCP directly. The ingress / HTTPS load balancer must be reachable and requires a certificate for authentication. The address of the load balancer must be defined on both sides: the Automation Engine and the Agent / TLS Gateway.
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:
-
Agents INI files
-
TLS Gateway INI file
Next step:
Installing the Additional Components - Container-Based Systems