Connecting to the CP

Non-TLS/SSL Agents and the OS CallAPIs, when used for the Automic Automation Kubernetes Edition, establish a connection to a TCP load balancer or TCP proxy, which must be reachable for the relevant component. The address of the load balancer must be defined on both sides: the Automation Engine and the Agent / OS CallAPI. The only exceptions are the Java and SAP CallAPIs, which must be upgraded to use TLS/SSL to connect to the Automation Engine. These two CallAPIs establish a connection with the Java communication process (JCP) through an ingress / HTTPS load balancer.

Important! Check Broadcom Software Academy. There is a course available for this topic. For more information, see the Education section at the end of this topic.

This page includes the following:

Reaching the CP Endpoint

You can still use your non-TLS/SSL Agents and OS CallAPIs even if you use Automic Automation Kubernetes Edition. To do so, you have to make sure that the relevant component can connect to a communication process (CP) through a load balancer. Since the CP communication relies on the TCP protocol (load balancer or proxy) it is not possible to route the communication using an ingress.

A new AAKE environment does not require communication processes (CPs). However, if you want to connect non-TLS/SSL Agents or OS CallAPIs and cannot use the TLS Gateway, you do require a CP.

The CP replicas are set to zero by default. If you do require a CP, make sure set the CP replicas to scale your deployment as required. For more information, see Scaling Deployments.

If you know the relevant address before the installation, you can also use the CP_EXTERNAL_ENDPOINT environment variable in the values.yaml file to add the URL.

If you set the CP endpoint through the values.yaml file before the installation, it is automatically configured as CP_ENDPOINT in the UC_SYSTEM_SETTINGS variable during deployment. Otherwise you have to set it manually after the installation, as this is the endpoint that the Agent / OS CallAPI uses to connect to the load balancer.

You also have to define the cp= parameter on the [TCP/IP] section of the INI file of the respective non-TLS/SSL Agent and/or OS CallAPI.

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

More information:

Using a LoadBalancer Service

If you do not use AAKE with a managed service from a cloud provider, then you have to install and configure a TCP load balancer / TCP proxy yourself. For example, the MetalLB load balancer implementation for bare metal Kubernetes clusters, allows you to create a service of type LoadBalancer for the communication process (CP). For more information, please see to the official MetalLB documentation.

If you do use AAKE with a managed service from a cloud provider, then the TCP load balancer / TCP proxy is provisioned automatically upon creating a service of type LoadBalancer.

Example cp-loadbalancer.yaml

You can create these services using the following command:

kubectl apply -f cp-loadbalancer.yaml

apiVersion: v1
kind: Service
metadata:
  name: cp-loadbalancer
spec:
  ports:
  - name: cp
    protocol: TCP
    port: 2217
    targetPort: 2217
  type: LoadBalancer

The cloud provider creates a TCP load balancer / TCP proxy and reveals the external endpoint for the created service. For more information, please consult the documentation of your cloud provider or the official Kubernetes documentation.

Using a NodePort Service

You could also create a service of type NodePort (with or without a proxy) for the communication process (CP). For more information, please see to the official Kubernetes documentation.

Example cp-nodeport.yaml

You can create these services using the following command:

kubectl apply -f cp-nodeport.yaml

apiVersion: v1
kind: Service
metadata:
  name: cp-nodeport
spec:
  ports:
  - name: cp
    port: 2217
    protocol: TCP
    targetPort: 2217
  type: NodePort

Depending on the configuration of your cluster, you could connect directly to the exposed port (nodePort) of the service. For more information, see Communication Processes (CP).

Alternatively, you could use a proxy that is capable of routing the TCP traffic to the exposed nodePort. In this case, the CP_EXTERNAL_ENDPOINT environment variable must point to your proxy, which is then accessed by the non-TLS/SSL Agents or OS CallAPIs.

Education

The Broadcom Software Academy provides a wide range of free online trainings. For information about how to navigate through the Academy and on how to register for courses, see Free Online Courses.

The following course(s) are associated with this topic:

See also: