Requirements

This page describes the basic deployment models and requirements to quickly get up and running.

Deployment Models

RunWhen Hybrid Deployment Model

This is the most common deployment option for most use cases.

In the hybrid deployment model, the RunWhen Platform manages Engineering Assistant activities, but delegates resource discovery and execution of tasks to self-hosted runners that operate in customer managed Kubernetes clusters. In this configuration, task execution and secrets remain local to the customer infrastructure.

Self Hosted Runner Deployment Architecture

Requirements

• A dedicated Kubernetes namespace and available CPU/Memory (to execute tasks)

Resource Quotas are highly encouraged to prevent a large discovery of cloud resources from taking up more cpu/memory than you are willing to allocate to RunWhen. Please contact us through Slack to discuss your specific resource requirements.

• The ability to deploy a Helm chart

• Review the Data Security Framework

• Network access:

  • To pull public container images (this can be overridden for private registries)

  • To clone GitHub repositories (for automatic configuration of discovererd resources)

  • Outbound 443 access to the RunWhen SaaS Platform

  • Outbound 443 access to the GCP Storage Service

  • Connectivity to any Kubernetes or Cloud infrastructure APIs that will be included in the discovery process.

• Authentication and authorization to perform discovery, perform tasks, etc.

  • By default, the Helm chart will attempt to create a service account with Cluster View permissions on the cluster it is installed into. This can be overridden with a customer provided kubeconfig.

  • Cloud provider service account / access key credentials can be provided for each cloud provider.

Detailed Network Requirements

The self-hosted runner is an operator, establishing a connection to the RunWhen Platform and coordinating activities such as starting and stopping pods that perform troubleshooting or SLI tasks.

In order for the self-hosted runner to function properly, it must access the following URLs:

In addition to the above, access to the Kubernetes / Azure / GCP / AWS management APIs is required for discovery of resources.

For outbound proxy configuration, all settings can be applied through the Helm values file.

Container Registry Images

The RunWhen Helm-Charts repository provides a complete list of all images used in the hybrid deployment, updated twice daily with Trivy vulnerability scan results. It includes images from both the Helm Chart and CodeCollection repositories.

The following container registries & images are used when functioning in a Hybrid deployment model:

In addition to the above container images, each CodeCollection has new images built when new content is added to the appropriate branch. The following examples highlight the images built from the mainbranch of each CodeCollection:

RunWhen Fully Hosted Deployment Model

In the fully hosted deployment option, the RunWhen Platform manages and executes Engineering Assistant activities within dedicated tenant infrastructure that is managed by the RunWhen team. Our Live Demos are configured in this manner and provide a great starting point to evaluate the platform.

Requirements

This deployment requires the least amount of effort, but does require:

• Secrets to be stored in our secure Vault service

  • For example, kubeconfigs, cloud service account files, or client IDs must be securely available to the automation tasks

• APIs to be publicly accessible

  • For example, if running this Kubernetes Namespace Health TaskSet, the RunWhen SaaS service must be able to communicate with your Kubernetes API endpoint