If you are just getting started, see our Quickstart guide. Once you have your organization up and running it’s time to set up your infrastructure. Your infrastructure is made up of the nodes, clusters, and environments in your organization. The way that these are set up determine how jobs run.

What is a Node?

Nodes are machines that run the node application, which allows jobs to run locally on the machine by connecting to your organization and listening for queued runs. When a queued run is assigned to the node, it gets the config and downloads the package before executing the queued run with the job listed in the config.

What is a Cluster?

Clusters are groups of nodes that are similar in physical location, access to resources such as networks or drives, or compliance with a standard like PCI or HIPAA. The nodes in a cluster are considered equal in that a job can run on any node in a cluster and will execute in the same manner and context. Nodes within a cluster can be on different hardware or operating systems, so long as these differences don’t cause a job to successfully run on one machine and fail on another.

The Node Application

The node application is packaged in different ways to make it convenient to run in various scenarios. You can run the node application:

Only one instance of the node application should run on a machine at any given time. A node can run jobs for multiple environments by deploying the environments to the cluster that the node is connected to.

Connecting to a Cluster

Nodes are connected to your organization by joining a cluster. When a cluster is created on the dashboard it is assigned a random API key. This key can be copied and used in the CLI with the set-apikey and start-node commands. The cluster key is unique to that cluster, so using the key both identifies which cluster to join and authenticates the connecting node.

Executing and Monitoring Jobs

When a node is assigned a job to run, it downloads the config and checks whether the package is in its local package cache, downloading and adding the package to the cache if it is not already there. The RunlyApi section of the config is overwritten with an auth token retrieved by the node for the job before the file is stored in a folder in the current user’s temporary folder. This folder will become the current working directory for the job. The package is then executed with the config’s path passed as a command line argument.

After the job has been started, the node monitors the job, sending the following to the API:

  • Start event, with a time and the process ID of the running executable,
  • Console standard output (stdout),
  • Console error output (stderr),
  • Exit event, with the time and exit code returned by the executable.

These events and information are displayed on the run page, indicating how the job ran from the node’s perspective.