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.
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.