Skip to content

Ansible collections

HybridOps is built on a feature-rich suite of Ansible collections published under the hybridops.* namespace.
Each collection is versioned independently and designed to be reused, while still composing cleanly into end-to-end platform workflows.

This page is the hub for:

  • what each collection is responsible for
  • how collections are consumed by HybridOps.Core modules and operator workflows
  • where to find role-level documentation and examples

Collection responsibilities

hybridops.app — platform and application roles

Runs platform services and control-plane components.

Typical scope:

  • Jenkins controller and agents
  • Kubernetes bootstrap and node configuration
  • NetBox deployment/seed flows
  • Platform services that sit “above the OS baseline”

See: Ansible Galaxy: hybridops.app

hybridops.common — shared utilities and plugins

Provides shared behaviour used across many roles and modules.

Typical scope:

  • environment guards and standard checks
  • shared filters/lookups/module_utils
  • common baselines and reusable helpers

See: Ansible Galaxy: hybridops.common

hybridops.helper — evidence and integration helpers

Captures evidence consistently and integrates with platform systems.

Typical scope:

  • evidence folder structuring and bundles
  • NetBox import/export helpers
  • “glue” roles used by CI and drills

See: Ansible Galaxy: hybridops.helper

hybridops.network — network automation

Automates network devices and network-adjacent services.

Typical scope:

  • baseline configuration
  • routing and routing policy (where appropriate)
  • VLANs and gateway patterns
  • backups and lightweight compliance checks

See: Ansible Galaxy: hybridops.network

Consumption model

HybridOps treats collections as building blocks, not vendored code.

  • Role-level usage is expressed via fully-qualified names (FQCN), e.g. hybridops.app.jenkins_controller.
  • Module orchestration lives in HybridOps.Core, where modules call drivers and roles as required, and emit evidence consistently.
  • Documentation links to role docs and Galaxy pages rather than duplicating role parameters in the portal.

Install example

HybridOps recommends pinning collection versions per release, aligned with the module set you run.

# collections/requirements.yml
collections:
  - name: hybridops.app
    version: ">=1.0.0"
  - name: hybridops.common
    version: ">=1.0.0"
  - name: hybridops.helper
    version: ">=1.0.0"
  - name: hybridops.network
    version: ">=1.0.0"

Install:

ansible-galaxy collection install -r collections/requirements.yml

Testing and release posture

Collections are expected to be testable in isolation and verifiable in integration:

  • Role-local smoke tests (fast functional checks)
  • Integration runs (role execution against representative hosts)
  • Evidence emission (structured outputs linked from docs)

When a role is used by a HybridOps.Core module, the module is responsible for:

  • declaring inputs and requirements (contract/spec)
  • running configuration steps
  • executing verification probes
  • emitting evidence artefacts suitable for review and support