Runners
Runners are responsible for deploying, updating and managing installs.
Runners are deployed into each install, and are responsible for updating, monitoring and managing your running application. Please refer to the Terraform reference for full configuration options.
Configuration
Runner configurations are managed using a runner config, and depending on which type of platform you are using, might have different capabilities (or not be compatible).
To configure your app runner:
You can set environment variables in your runner config using an env_var. Environment variables are set when runners
are performing jobs such as provisioning, updating and monitoring.
Runner Types
The nuon platform is responsible for deploying, and managing the runner in each install. It uses sandbox outputs to authenticate and correctly configure your runner.
Each app can only have one type of runner.
AWS EKS Runner
The AWS EKS runner is deployed using Helm, into a dedicated namespace in the cluster.
This runner is granted ClusterAdmin permissions, so that it can properly manage the entire kubernetes cluster.
To configure an AWS EKS runner:
The aws-eks runner is only compatible with aws-eks sandboxes.
AWS ECS Runner
The AWS ECS runner is deployed using ECS Fargate.
To configure an ecs runner:
Technically, you can use an aws-ecs Fargate runner with an aws-eks app but this is not recommended.
If you have a use case for this runner/sandbox combination, we would love to hear more. Please get in touch.
Azure AKS Runner
The Azure AKS runner is deployed using Helm, into a dedicated namespace in the cluster.
This runner is granted ClusterAdmin permissions, so that it can properly manage the entire kubernetes cluster.
To configure an Azure AKS runner:
Runner Responsibilities
The runner performs the following jobs, inside of an install:
- provisioning or deprovisioning components.
- syncing container images into the local artifact store.
- monitoring running containers in the compute cluster.
- executing terraform in the cluster.
- returning telemetry and log data upon request.
Runner Permissions
Each runner works by listening for jobs from the Nuon managed data plane server it belongs too. This server dispatches jobs, which the runner will pick up and then run tasks to perform.
The runner will use different IAM roles for different component jobs, to minimize the permissions available on each job. These IAM roles are defined in each sandbox, and outputs are used to allow the runner to use them.
Since the runner is deployed into the customer install, no long-lived permissions are required after the initial install. This creates a more secure operating environment, as the only thing that can dispatch work to the runner is the data plane server it belongs to.
Runner Installation (AWS)
Each sandbox is provisioned with a runner_install_role that Nuon will use to install the runner. In most cases this is
the IAM role of the install.
The sandbox grants access to internal resources such as ECS or EKS so that the runner can be installed.