1. blueprint(5)
  2. Blueprint
  3. blueprint(5)

NAME

blueprint - blueprint JSON format

SYNOPSIS

{
  "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.)

DESCRIPTION

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.

Sources

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.

Files

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.

Packages

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.

Services

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.

THEME SONG

The Flaming Lips - "The W.A.N.D. (The Will Always Negates Defeat)"

AUTHOR

Richard Crowley richard@devstructure.com

SEE ALSO

Part of blueprint(1).

mustache(5) at http://mustache.github.com/mustache.5.html and mustache.sh at https://github.com/rcrowley/mustache.sh.

  1. DevStructure
  2. December 2011
  3. blueprint(5)