Technical details for Frends Agent

This document describes a typical Frends Agent installation details.

The Agent is a service that executes Frends Processes, which it receives from the Frends UI. These executions are then reported back to the Frends Log Service. All the functionality/requirements described in this document are related to the base functionality of the Agent, any Processes deployed on the Agent may require additional requirements.

Outgoing connections

The Agent requires connectivity to the Azure or Cleura cloud where the Frends UI is hosted. It mainly uses the Azure Service Bus or RabbitMQ as a message bus for communication and Azure Storage or Ceph (Blob storage) for larger data amounts.

IP Addressing for Frends Agents

The IP address behavior of a Frends Agent depends on how and where it's deployed.

Cloud Agents are provisioned with static public IP addresses by Frends. The outbound IP address remains constant throughout the agent's lifecycle, even during restarts, updates, or scaling operations. This allows you to reliably whitelist Cloud Agent IPs in external firewall configurations.

Self-hosted Agents use the IP configuration of the infrastructure where they're deployed to. Whether that IP is static or dynamic depends entirely on your own network configuration. If you need a static IP for a self-hosted agent, configure that at the infrastructure level through your network administrator or cloud provider.

Private Cloud Agents deployed in customer-managed cloud environments follow the same principle as self-hosted agents. The IP addressing is determined by your cloud network configuration. If you need static outbound IPs, configure this through your cloud provider's networking features, such as Azure NAT Gateway with a static public IP or AWS Elastic IPs attached to a NAT Gateway.

Message Bus

Connections to the Message Bus are SSL secured and the Agent uses a limited access connection string for authentication. The Agent uses the Message Bus for the following purposes:

• Receiving Process deployments from the UI

• Receiving other configuration data from the UI, such as Environment Variables, API Key configurations, OAuth settings, etc

• Sending Process log data to the Log Service

• Sending Heartbeats and system log data to the Log Service

• Requesting Remote Subprocess executions on Agents in the same Environment

• Receiving Remote Subprocess execution requests from Agents in the same Environment

• Receiving Manual Process execution requests from the UI

See the Agent connectivity requirements for required open ports.

Blob Storage

The Agent's access to the Blob Storage is SSL secured and authenticated with limited access Shared Access Signatures (SAS) at a Blob Container or Blob level. The Agent uses the Blob storage for the following purposes:

• Reading and writing to the Large Message Storage:

  • - Used to store messages that do not fit inside of a single Azure Service Bus Message (>200KB)

  • Each Agent Group has its own Blob container for storing large messages

  • Service Bus messages contain a SAS signed URI to access the Blob containing the large messages

• Retrieving compiled Processes as Process Host packages (Process host package store)

• Storing Process step log data (when Blob logging is enabled for the Agent Group)

Databases

The Agent has different databases to store configuration data, caching log data and storing shared state between Agents inside of an Agent Group.

When Agents inside of an Agent Group are configured to function as a High Availability group, they require a Shared State Store to orchestrate File Watch, Schedule and Conditional Triggers.

It is possible, although not recommended, to install more than one Agent without a Shared State Store. In this case only one predefined Primary Agent (not dynamic) executes File, Schedule and Conditional Triggers. This is not a recommended installation model and may not support all future features.

The Agent supports the following databases:

• Microsoft SQL Server or Azure SQL Database

  • Can be used for configuration and shared state storage

  • Secured either through an SQL Login or Integrated security

  • Agent user has the following access to the database: db_datareader, db_datawriter, execute

• SQLite

  • Used for caching log data when there's no access to the Service Bus or Azure Storage

  • Can be used by the Cross-platform Agent for Configuration storage

  • Can be used by the Cross-platform Agent for shared state storage when in a non-HA configuration

  • Secured through file access on the local machine

Please see Installing Frends Agent and How to set up High Availability configuration for more details on how to set up the databases for Agents.

File system

The Agent requires access to the local file system for operation. It uses the local file system for storing Process deployment executables and SQLite databases.

A Cross-platform Agent uses the Agent user account's <home>/.local/share/HiQ Finland\Frends Agent(<EnvironmentName>_<AgentName>) folder by default, but this can be overridden.

For storage available to be used in Processes see Agent storage availability.