Skip to content

Application Provisioning

As an Operator, you will want to deploy or configure application layers after the OS is installed. DRP treats application provisioning as a continuation of the standard workflow pipeline: the same task and stage system that installs and configures the OS can also install and configure application software, integrate with configuration management tools, and hand off to specialized orchestration systems.

Post-OS Application Deployment

After an OS install workflow completes, DRP can automatically transition the machine to an application provisioning workflow by changing the machine's workflow at the end of the OS stage sequence. This is done via a change_workflow action in the classify system or by setting the machine's next workflow as a parameter. The application workflow runs tasks on the now-booted OS, using the DRP runner agent installed during OS provisioning to execute scripts and templates.

Typical application workflow tasks include:

  • Installing packages and configuring services
  • Applying configuration management (Ansible, Chef, Puppet)
  • Registering the machine with an orchestration system (Kubernetes, OpenShift)
  • Running validation and compliance checks

Configuration Management Integration

DRP integrates with major configuration management tools through dedicated tasks and stages:

Ansible

The ansible-playbooks task in the task-library content pack runs Ansible playbooks against the provisioned machine. DRP passes machine parameters as Ansible extra vars, making inventory data (RAM, CPUs, serial number, network interfaces) available to playbooks without maintaining a separate Ansible inventory file. The ansible-inventory stage can also generate a dynamic Ansible inventory from the DRP machine database for use with external playbook runners.

Bash
# Set the Ansible playbook to run on a machine
drpcli machines set <machine-uuid> param ansible/playbooks to '["site.yml", "harden.yml"]'

# Set the Ansible connection parameters
drpcli machines set <machine-uuid> param ansible/connection to "ssh"

Chef and Puppet

DRP does not ship native Chef or Puppet tasks, but the DRP runner agent can execute arbitrary scripts on the provisioned machine. Operators typically implement Chef/Puppet integration via shell tasks that install the Chef client or Puppet agent and point it at the organization's server. Machine parameters set by the classify and inventory stages are passed to the task as template variables for node configuration.

Handing Off to Application Layers

For complex application deployments (e.g., OpenShift), DRP manages the hardware provisioning and hands off to the application installer once the OS is ready. The hand-off pattern is:

  1. DRP provisions the OS and configures base networking, SSH access, and storage
  2. A DRP task installs the application installer or bootstrap script
  3. The application installer runs (potentially for a long time) while DRP monitors via job polling
  4. On completion, DRP runs post-install validation tasks and marks the machine as ready

This pattern keeps DRP responsible for the hardware layer while delegating application complexity to dedicated tools, preserving the benefits of both systems.