Last week I dug into two key rPath concepts: the blueprint and the manifest. Manifests drive many automated tasks in rPath, starting with image generation.
Traditionally, deployment poses a difficult choice. You can deploy each system by installing its components one by one. That’s completely flexible, but very slow and error prone. Or, you can deploy each system from a physical, virtual, or cloud “golden image.” That’s fast and reliable, but doesn’t solve the fundamental problem—it really just begs the question. Instead of manually maintaining lots of individual systems, you are manually maintaining lots of golden images.
rPath solves the dilemma by automatically generating images from manifests. Given a manifest, rPath can automatically generate:
- Installable ISO and WIM images for physical provisioning
- Virtual machines for any hypervisor, including VMware, Xen, and Hyper-V
- Cloud images for any cloud, including Amazon EC2 and Eucalyptus
Once provisioning is complete, you can simply discard the image. Since rPath generated the image from completely versioned inputs, you can regenerate the same image at any time. We believe large artifacts like images should always be ephemeral and recreatable—object code, not source code.
This technique gives the best of both worlds. The blueprint yields complete flexibility and customization, while the generated image enables rapid provisioning. Provisioning becomes faster and more reliable while policy setters and platform engineers retain flexible control over system contents.
Next week we’ll talk about how the same manifest drives incremental system updates.
