Skip to content

Bootstrap Linux Ops Runner (HyOps Module)

Module ref: platform/linux/ops-runner

Use this module after you create a runner VM. It installs the HybridOps release and selected toolchain on that host.

Two delivery modes are supported:

  • controller-local unpacked release root (runner_release_root or HYOPS_CORE_ROOT)
  • versioned release archive download (runner_release_archive_url)

Typical GCP runner flow

  1. Create the private runner VM with networking/gcp-ops-runner@v1
  2. Ensure the provider-specific access and egress layers exist for that runner
  3. Bootstrap the host with platform/linux/ops-runner

Example:

HYOPS_CORE_ROOT=/home/user/hybridops-studio/hybridops-core \
hyops validate --env dev --skip-preflight \
  --module platform/linux/ops-runner \
  --inputs "$HYOPS_CORE_ROOT/modules/platform/linux/ops-runner/examples/inputs.min.yml"

Notes:

  • runner_release_root may be omitted when HYOPS_CORE_ROOT is already exported by the installed hyops wrapper.
  • for a more durable runner pattern, prefer runner_release_archive_url backed by your release artifact repository
  • when bootstrapping from a local unpacked release root, HyOps vendors the already-installed HybridOps Python runtime dependencies from the controller and copies them into the staged release on the runner, so the private-runner bootstrap path does not require direct PyPI access
  • HyOps records the staged release archive hash on the runner and automatically reinstalls when that hash changes, so runner refreshes pick up new shipped payloads without a manual force toggle
  • The bootstrap ensures baseline execution dependencies such as git are present so Terragrunt-backed modules can download versioned module sources directly on the runner.
  • current shipped cloud runner blueprints standardize on Ubuntu LTS images for the execution host; on-prem runner blueprints follow the validated local template contract and may use Rocky 9 where that is the proven on-prem base image
  • The module is reusable for GCP, Azure, AWS, and on-prem runners.
  • Provider-specific egress belongs in a separate network module or blueprint step; do not hide it inside the generic runner bootstrap contract.
  • This module does not create the runner VM. Pair it with the relevant platform VM module or runner blueprint.
  • For private GCP runners, prefer ssh_access_mode: gcp-iap.
  • Private GCP runners using gcp-iap must carry the allow-iap-ssh tag or be covered by an equivalent firewall policy that permits IAP TCP/22.
  • For first bootstrap immediately after VM creation, use a small connectivity_wait_s window such as 60 to absorb guest and IAP readiness lag.
  • Private GCP runners using gcp-iap still require outbound HTTPS egress for package and tool installation during bootstrap. Treat Cloud NAT or an explicitly accepted runner public-egress posture as a prerequisite until the artifact-based bootstrap path replaces these downloads.