Runners

The runner serves as the essential element in executing all actions within a Workflow. It offers the flexibility of deployment either on Blink's cloud infrastructure or within your own environment. To enhance scalability and distribute the workload efficiently, you have the option to create a runner group that can incorporate multiple instances of the runner.

How a Runners works

Action execution flow

1. The runner is given a task and determines the specific action containers needed for the task.
2. The runner establishes communication with an existing action container. If no action container is currently running, the runner initiates a new one.
3. The action container receives information about the specific action required for the task.
4. The action container runs the action and returns back the results to the runner.
5. The action container executes the action and sends the resulting output back to the runner.

The communication of a runner

• The runner establishes communication with Blink's Controller to receive assigned jobs for execution.
• A runner may fetch secret information from:
  • The Blink’s Cloud secret store
  • The Customer’s secret store

Security using Image Signing

Image signing is a process that guarantees the security and authenticity of container images as they are transferred from the Blink controller to the runner. It ensures that the images originate from a trustworthy source and have not been modified. To achieve this, all images sent from the controller to the runner are digitally signed using a Blink certification. . The runner has a public key, which it uses to validate any content received from the controller. For example, if an image is signed, the runner will proceed to install it. On the other hand, if an image is not signed or fails the verification process, the runner will disregard it and report a failure.

Blink Runners and Self-Hosted Runners

In most cases, the default Blink Runner works well when using our platform. However, there may be times when you want to use your own runner to meet specific needs. These needs can include things like network setup, security, performance, and control over data transfers. Here are some examples:

• 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.
• Achieving low latency for resources in different regions or cloud providers: If you need fast interaction with resources that are located in different regions or cloud providers than the default runner, you can deploy your own runner closer to those resources. This helps reduce latency and ensures a smoother experience.

Blink Public IPs

Outbound Traffic

Any traffic initiated by Blink cloud services (e.g. controller, runner) and directed at customers and their vendors. These should be allowlisted on the customer side (and any 3rd parties the customer integrated with and require an allowlist) for any incoming traffic from Blink cloud.

IP
44.194.139.218
3.217.19.166
54.81.101.61
107.20.97.38

Inbound Traffic

Any traffic initiated by a self-hosted runner (on the customer side) and directed at Blink’s cloud services (app.blinkops.com).

IP	Service	Type
CloudFront Global IP List	CloudFront	JSON list of all CloudFront IP ranges