On top of raw system artifacts (such as packages and configuration files), rPath layers several unique system modeling concepts. Here’s how two of the most important concepts at rPath—blueprints and manifests—work together to deliver model-driven automation.
Blueprints
An rPath blueprint is a comprehensive model for one or more systems. It describes all components to include on a system: OS platform, OS patches, middleware stacks, applications, compliance policies, and configurations. The description is declarative and human-understandable; you can create and edit blueprints with an easy-to-use GUI or with a powerful command line interface.
Blueprints are hierarchical. For example, instead of specifying corporate-standard Linux security requirements in the web server blueprint, you can create a corporate standard Linux blueprint, and use that as the basis for the web server blueprint. The web server blueprint becomes simple and easy to understand, since it needs to describe only the specialized web server requirements—such as configuring Apache—and inherits the definition of the corporate standard blueprint. That eliminates redundant effort in patching and software deployment, and reduces the risk of accidental change.
Blueprints are version-controlled. Each change to a blueprint is recorded as an immutable version, so you can always find the exact specification that created a particular system. That leads to:
- Faster troubleshooting—As demonstrated in The Visible Ops Handbook, 80% of outages stem from deliberate configuration changes. Version control makes it easy to see all recent changes that affected a system, eliminating hours of detective work from the troubleshooting process.
- Reproducibility—Complete versioning makes it possible to rebuild a system from any of its versions, enabling disaster recovery and capacity expansion.
- Auditability—It’s easy to obtain any previous version of a complete system model, making it possible to answer detailed questions about the prior state of a system.
Manifests
How do blueprints drive automation? The first step is the automated generation of a manifest. A manifest is a granular, flat bill of materials for a system. For example, if the blueprint called for Red Hat Enterprise Linux 5, the manifest lists the hundreds of specific Linux packages that are included in that OS.
rPath automates system construction steps when generating a manifest:
- Dependency resolution—rPath deeply models dependency requirements for every artifact in the hub. When generating a manifest, rPath adds software to the manifest as necessary to satisfy all dependencies.
- IT policy verification—rPath can apply custom IT policy to validate any aspect of a manifest. For example, regulatory requirements and internal security requirements are easy to enforce at manifest construction time.
Manifest build automation makes your systems “correct by construction.” Before a production system is ever provisioned or updated, build automation catches and prevents many common configuration errors.
This two step process—describe a blueprint, then generate a manifest—cleanly separates the human-input side of system creation and the automatable grunt-work side of system creation, making both sides faster and more effective. The result is better productivity and predictability in IT operations.
What’s Next?
The manifest is a great model, but what can you actually do with it? In upcoming posts, we’ll dig into the tasks rPath automates given a manifest, such as image generation and incremental system updates.
