Remote Worker Best Practices

Remote Worker Best Practices Guide

Introduction to Remote Workers in Pliant

In a standard Pliant instance operating within a Kubernetes cluster, there are typically two workers functioning as part of the default worker group. These workers are responsible for the execution of flows within the default configuration.

Pliant introduces a feature known as the "Remote Worker", designed to extend workflow execution capabilities to remote networks. This feature is particularly useful in scenarios where workflows need to be executed in locations not directly accessible by the main Pliant workers.

Deployment and Connectivity of Remote Workers

Remote workers can be deployed in various forms: as appliances, containers, or executable programs. Their primary function is to operate from remote locations, establishing a connection back to the main Pliant instance. This connection is secured via an encrypted HTTPS protocol (using Port 443), enabling the remote worker to join a custom worker group without necessitating firewall modifications.

Upon successful connection, the remote worker becomes part of the designated custom worker group, and is then responsible for executing workflows assigned to that group. It is possible to connect multiple remote workers to a single remote worker group for enhanced operational flexibility.

Worker Groups: Organization and Function

Worker Groups are a pivotal concept in managing workflows across remote workers. These groups allow for the targeting of specific workflows to particular remote workers based on geographic or operational requirements. For instance, to execute certain workflows exclusively in New York, a worker group named "New York" can be established, to which a remote worker located in that region is added. Workflows designated for the "New York" group will be exclusively executed by the associated remote worker.

For optimal performance and reliability, it is recommended to have multiple workers in each worker group to ensure redundancy.

Upgrading Remote Workers

To maintain consistency and functionality, remote workers should be upgraded in tandem with updates to the core Pliant application. The upgrade process varies based on the type of remote worker deployment:

Binary Workers

  • Binary workers are now deprecated; these workers should be migrated to an OVA based worker.

Container-Based Workers

  • Upgrade involves updating the container in which the remote worker is running.

OVA Deployments

  • Remote workers deployed using Pliant-supplied OVAs can be upgraded using the "rwupdate" command.

  • This command should be executed within the OVA to initiate the upgrade process.