blueprint
- blueprint JSON format
{
"arch": "ARCHITECTURE",
"files": {
"PATHNAME": {
"content": "CONTENT",
"encoding": "ENCODING",
"group": "GROUP",
"mode": "MODE",
"owner": "OWNER"
},
"PATHNAME": {
"encoding": "ENCODING",
"group": "GROUP",
"mode": "MODE",
"owner": "OWNER",
"template": "TEMPLATE"
},
"PATHNAME": {
"dat": "DATA"
"encoding": "ENCODING",
"group": "GROUP",
"mode": "MODE",
"owner": "OWNER",
"template": "TEMPLATE"
},
"PATHNAME": {
"encoding": "ENCODING",
"group": "GROUP",
"mode": "MODE",
"owner": "OWNER",
"source": "SOURCE"
}
},
"packages": {
"MANAGER": {
"PACKAGE": ["VERSION"],
"PACKAGE": ["VERSION", "VERSION"]
},
"MANAGER": {
"PACKAGE": ["VERSION"],
"PACKAGE": ["VERSION"]
},
"rpm": {
"PACKAGE": ["URL"]
}
},
"services": {
"MANAGER": {
"SERVICENAME": {
"enable": true,
"ensure": "running",
"files": ["PATHNAME"],
"packages": {
"MANAGER": ["PACKAGE"]
},
"sources": ["DIRNAME"]
}
}
},
"sources": {
"DIRNAME": "FILENAME",
"DIRNAME": "URL"
}
}
(Keys and values written in CAPITALS represent variable data.)
blueprint-create
(1) commits blueprint.json
to the appropriate branch in the local blueprint repository. The format described here is used to generate Puppet modules, Chef cookbooks, and POSIX shell scripts in blueprint-show
(1) and blueprint-apply
(1). These sections must be followed in order.
Each key in the optional sources
object is the fully-qualified path to a directory. These directory names should be traversed in alphabetical order. The associated value is the name of a tarball of the contents of that directory at the time the blueprint was created. It must be extracted there when the blueprint is applied. The tarball is stored in Git alongside blueprint.json
.
If sources
is present and non-empty, arch
will also be present indicating the architecture of the server that created the blueprint. If present, this value will be amd64 or i386 on Debian-based systems or x86_64 or x86 on RPM-based systems. It is legal to refuse to apply a blueprint with a mismatched architecture. The architecture can be found by running dpkg --print-architecture
or rpm --eval %_arch
as appropriate.
For compatibility with AWS cfn-init
, a URL may appear in the value in place of a filename. If such a value is encountered, the URL should be fetched and extracted. Blueprint will never generate such objects.
Each key in the optional files
object is the fully-qualified pathname to a file. These pathnames should be traversed in alphabetical order. The associated value contains the owner
, owning group
, mode
(a string containing the full 6-digit octal representation), content
, and the encoding
of content (one of plain or base64). Each file must be placed at its pathname and its metadata must be updated when the blueprint is applied.
The file's content may alternately be specified as template
and (optionally) data
which contain a mustache.sh
template in the mustache
(5) format and POSIX shell code, respectively. When a blueprint is applied, the template should be given as standard input to mustache.sh
with this data and other default data available in the environment. The resulting standard output should be taken as the file's content. A copy of mustache.sh
is distributed with Blueprint.
For compatibility with AWS cfn-init
, source
takes precedence over content
. If a file with a source
is encountered, the source
URL should be fetched as the file's content. Blueprint will never generate such objects.
Each key within packages
names a package manager. Each manager contains keys that name packages to be installed by that manager. Each package name is associated with an array of versions that must be installed. In most cases, for most managers, this array will have only one element.
Each manager is itself the name of a package that appears elsewhere. packages
must be processed by starting with the apt
, rpm
, and yum
managers, installing their dependencies. Any manager that was installed during this pass must next have its dependencies installed, continuing recursively until all managers and all dependencies have been installed.
For compatibility with AWS cfn-init
, the rpm
manager is included. Packages managed by rpm
specify URLs in place of version numbers. If such a package is encountered, the URL should be installed via rpm
(1). Blueprint will never generate such objects.
Each key within services
names a service manager. Each manager contains keys that name services on the system. Each service name is associated with a set of dependencies which themselves take a form much like a blueprint: files
may be present and point to a list of pathnames; packages
may be present and point to a set of package managers which each point to a list of packages; sources
may be present and point to a list of directory names.
If any of the resources on which the service depends are changed, upgraded, initailized, or otherwise acted upon, the service should be restarted.
For compatibility with AWS cfn-init
, "enable": true
and "ensure": "running"
are included with each service. Blueprint ignores these when generating code.
The Flaming Lips - "The W.A.N.D. (The Will Always Negates Defeat)"
Richard Crowley richard@devstructure.com
Part of blueprint
(1).
mustache
(5) at http://mustache.github.com/mustache.5.html and mustache.sh
at https://github.com/rcrowley/mustache.sh.