Skip to main content

Introduction

A runner is the component responsible for executing all actions of an Automation. Runners can be deployed on Blink's cloud or self-hosted in your environment. A runner group can be created to include multiple runner instances to help with scalability and load balancing.

How a runner works​

Action execution flow​

  1. The runner is assigned a job and resolves which action containers the job requires.
  2. The runner starts to communicate with an already running action container. If no action container is available the runner starts a new one.
  3. The action container receive information of the action the job requires.
  4. The action container runs the action and returns back the results to the runner.
  5. The runner analyzes the results and returns it to Blink’s Controller.

runner

The communication of a runner​

  • A runner communicates with Blink’s Controller in order to get dispatched jobs to execute.
  • A runner may fetch secret information from:
    • Blink’s Cloud secret store
    • Customer’s secret store

Security using image signing​

Image signing ensures the integrity of container images as they move from the Blink controller to the runner. It verifies that the images come from a trusted source and that they have not been modified. All images sent from the controller to the runner are signed with a Blink certification. The runner holds a public key that it validates against anything received from the controller. For example, if an integration is signed; the runner will install it, and if not; it will ignore and report a fail.

In most use cases, the default Blink Runner is suitable when using our platform, however you may wish to deploy your own runner to address specific requirements. Such requirements can be related to network topology, security, performance, and control on data transfer. Some examples are outlined below:

  • Running actions on a Kubernetes cluster, which has no public access to its API controller. You can deploy a runner within the cluster, so it can run Kubernetes commands from there.
  • Accessing resources located in a private subnetwork. For example, you can deploy a runner in a public subnetwork with access to the private subnetwork.
  • Limiting inbound/outbound data transfer. For example, if you need access to an S3 bucket and want to minimize data transfer cost using a private endpoint, you can deploy a runner in a subnetwork with access to the private endpoint.
  • Keeping all secrets used for Blink connections in a self-hosted vault.
  • Keeping low latency while interacting with resources located in different regions or cloud providers than the default runner.