Starting with version 26.2, Raynet One agents no longer communicate with the backend server directly. Instead, all agent traffic is routed through the runner. The runner acts as a communication gateway that receives messages from agents and forwards them securely to the backend on their behalf.
This architecture ensures that agents only require network connectivity to the runner, rather than directly to the backend infrastructure. It simplifies network segmentation and reduces the number of required firewall rules in environments where agents are deployed across distributed or restricted network segments.
Communication flow
The following describes how agent messages are handled in the updated architecture:
1.The agent establishes a connection to the runner using the runner's IP address and port.
2.All agent messages — including enrollment requests, status updates, resource requests, and inventory upload tokens — are received and processed by the runner.
3.The runner forwards these messages to the backend server over the existing secure runner-to-backend gRPC connection.
4.Responses from the backend are relayed back to the agent via the same runner connection.
Agent endpoint configuration
When deploying an agent in environments that use this architecture, configure the agent's serving endpoint to point to the runner's IP address and port, not the backend server URL. This applies to all agent deployments managed through runners.
The runner's IP address and port are visible in the Details view of the runner entry in Raynet One. Use these values when configuring the agent endpoint parameter during installation or reconfiguration. Refer to Runners for details on how to inspect runner properties.
|
Note: |
Agent endpoint failover
Agents support automatic endpoint failover. If the primary runner endpoint becomes unavailable, the agent automatically switches to the next available endpoint in its configured list. This behavior requires no manual intervention and ensures that inventory and communication operations continue uninterrupted even when a single runner becomes temporarily unreachable.
To take advantage of failover, configure the agent with multiple runner endpoints during deployment. The agent will attempt each endpoint in sequence and connect to the first one that responds successfully.
Agent assignment tracking in the job graph
Agent assignments are fully integrated into job tracking. When an agent assignment is part of a job, the assignment step appears as a dedicated node in the job graph, giving you a clear view of where agent work fits within the overall job workflow.
Selecting an agent assignment node in the job graph opens a details view that shows the current progress, execution logs, and any results produced by the assignment. Results from agent assignments can propagate downstream within the job workflow, enabling subsequent job steps to consume and act on the agent's output.
This visibility helps you monitor agent-driven operations with the same level of transparency as other job steps and simplifies troubleshooting when an agent assignment does not complete as expected.
Agent message dispatching modes
The agent supports two modes for dispatching messages and results, allowing it to operate in environments that do not have a continuous connection to the runner or backend.
•Queued mode (SQLite): Results are stored as rows in the agent's local SQLite database. The agent uploads the queued results to the backend once a connection to the runner is available. This mode is suited for agents that are temporarily offline or operate in intermittently connected environments.
•Disk-based mode: Results are written directly to disk. This mode is intended for fully offline or standalone deployments where no runner connection is expected. Results stored on disk can be retrieved and processed separately according to your operational workflow.
The dispatching mode is configured as part of the agent's deployment settings. Select the mode that matches your connectivity and operational requirements.