Preparers

The preparer (sometimes referred to as the "agent" due to some mixed nomenclature) is a root-level service running on every p2 host. It watches the intent store for new pod manifests being scheduled on the node, and it executes the steps necessary to install and launch that pod manifest's contents. Then it updates the reality store to reflect the changes. Essentially, the intent store represents what reality is supposed to look like, and the preparer's job is to make it so.

Configuration

The preparer recognizes various configuration keys in its pod manifest. All of them must be under the preparer key, so your manifest should look like this:

id: p2-preparer # the ID of the preparer cannot be changed, it must be this string exactly!
launchables:
  p2-preparer:
    launchable_id: p2-preparer
    launchable_type: hoist
    location: /my/tarball.tar.gz
config:
  preparer:
    my_config_key: my_config_value

• keyring: The path to a PGP public keyring. Keys on this ring will be recognized by the preparer for manifest signing, or for artifact digest signatures. This key is mandatory. The preparer will not operate without manifest signing, for security reasons.
• consul_address: The address to a Consul instance to communicate with. The default is 127.0.0.1:8500, which corresponds to Consul's own defaults. Using a remote Consul agent is not supported. Your Consul agent should be running on the same host as the preparer that's configured to talk to it.
• node_name: the name of the preparer. This corresponds to the entries in the intent store that the preparer should monitor. The default value is the hostname of the machine, which is generally suitable.
• ca_path: the path to a CA certificate to use for health checking. The certificate is used by Consul, so the local Consul agent needs to be able to read it. This feature is useful if your health checking endpoint uses HTTPS with its own CA certificate.
• consul_token_path: the path to a file, whose contents are a consul ACL token that the preparer should use. For external use, we recommend letting the preparer write services and any keys in the KV store. In the future, we will refine and narrow the ACL permissions that the preparer requires.