Context Architecture¶
What Are Contexts?¶
Contexts are a DRP abstraction that allow tasks to execute on a container running on the DRP endpoint itself, rather than on a target machine. This enables automation for workloads that do not boot via PXE or that require specific tooling environments (e.g., Ansible, Terraform, OpenShift installers).
The docker-context plugin implements contexts using Podman or Docker to manage containers,
bind-mounting drpcli into the container so it can communicate with DRP.
How Contexts Work¶
- A Context object is created in DRP, referencing a container image
- A machine is created with
Meta.BaseContextset to the context name - When DRP runs tasks for that machine, it invokes the container instead of PXE-booting
- The container runs
drpcli machines processjobsto execute tasks
This allows DRP's full task/workflow/pipeline system to drive non-PXE workloads.
Contexts in Pipeline Phases¶
A workflow-mode WorkOrder pipeline can run different phases in different Contexts. Each phase resolves its execution Context from the universal/<phase>-phase-context param, so a single pipeline run can move between on-machine execution and one or more container Contexts as it advances through prepare, discover, hardware, os, and app.
The Context each phase ran in is recorded on the WorkOrder. Every PipelinePhaseRecord in the WorkOrder's PipelinePhase list carries a Context field capturing the Context active for that phase (empty means the phase ran on the machine). This provides a per-phase history of where each part of the pipeline executed.
Context vs. Machine vs. Endpoint¶
| Object | Description |
|---|---|
| Endpoint | A DRP server instance |
| Machine | A managed target (physical, virtual, or container-backed) |
| Context | A container engine configuration that backs a machine |
Use Cases¶
- Ansible execution environment — run Ansible playbooks in a controlled container
- Kubernetes installer — run OpenShift or k8s install workflows
- Cloud provisioning — use cloud CLIs (AWS, Azure, GCP) in a context container
- Custom tooling — run any automation that needs specific tooling not on the target
Versioning and Images¶
Context images follow the naming convention $(Image)_v1.2.0 where the version suffix allows
DRP to track image upgrades without disrupting running tasks.
Images are stored at files/docker-contexts/$(Image) on the DRP file server.
Operational Details¶
For step-by-step instructions on creating, configuring, and using contexts, see Setting Up Docker Contexts.
For the Context model reference, see Context Model.