Back to Packer

`manifest` post-processor

website/content/docs/post-processors/manifest.mdx

1.15.34.8 KB
Original Source

⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️

[!IMPORTANT]
Documentation Update: Product documentation previously located in /website has moved to the hashicorp/web-unified-docs repository, where all product documentation is now centralized. Please make contributions directly to web-unified-docs, since changes to /website in this repository will not appear on developer.hashicorp.com. ⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️

<BadgesHeader> <PluginBadge type="official" /> </BadgesHeader>

manifest post-processor

Artifact BuilderId: packer.post-processor.manifest

The manifest post-processor writes a JSON file with a list of all of the artifacts packer produces during a run. If your Packer template includes multiple builds, this helps you keep track of which output artifacts (files, AMI IDs, Docker containers, etc.) correspond to each build.

The manifest post-processor is invoked each time a build completes and updates data in the manifest file. Builds are identified by name and type, and include their build time, artifact ID, and file list.

If packer is run with the -force flag the manifest file will be truncated automatically during each packer run. Otherwise, subsequent builds will be added to the file. You can use the timestamps to see which is the latest artifact.

You can specify manifest more than once and write each build to its own file, or write all builds to the same file. For simple builds manifest only needs to be specified once (see below) but you can also chain it together with other post-processors such as Docker and Artifice.

Configuration

Optional:

@include 'post-processor/manifest/Config-not-required.mdx'

~> Note: Unlike most other post-processors, the keep_input_artifact option doesn't apply for the manifest post-processor. We will always retain the input artifact for manifest, since deleting the files we just recorded is not a behavior anyone should ever expect.

Example Configuration

The minimal way to use the manifest post-processor is by just writing its definition, like:

<Tabs> <Tab heading="HCL2">
hcl
post-processor "manifest" {}
</Tab> <Tab heading="JSON">
json
{
  "post-processors": [
    {
      "type": "manifest"
    }
  ]
}
</Tab> </Tabs>

A more complete example:

<Tabs> <Tab heading="HCL2">
hcl
post-processor "manifest" {
    output = "manifest.json"
    strip_path = true
    custom_data = {
      my_custom_data = "example"
    }
}
</Tab> <Tab heading="JSON">
json
{
  "post-processors": [
    {
      "type": "manifest",
      "output": "manifest.json",
      "strip_path": true,
      "custom_data": {
        "my_custom_data": "example"
      }
    }
  ]
}
</Tab> </Tabs>

An example manifest file looks like:

json
{
  "builds": [
    {
      "name": "docker",
      "builder_type": "docker",
      "build_time": 1507245986,
      "files": [
        {
          "name": "packer_example",
          "size": 102219776
        }
      ],
      "artifact_id": "Container",
      "packer_run_uuid": "6d5d3185-fa95-44e1-8775-9e64fe2e2d8f",
      "custom_data": {
        "my_custom_data": "example"
      }
    }
  ],
  "last_run_uuid": "6d5d3185-fa95-44e1-8775-9e64fe2e2d8f"
}

If the build is run again, the new build artifacts will be added to the manifest file rather than replacing it. It is possible to grab specific build artifacts from the manifest by using packer_run_uuid.

The above manifest was generated with the following template:

<Tabs> <Tab heading="HCL2">
hcl
source "docker" "docker"{
    image = "ubuntu:latest"
    export_path = "packer_example"
    run_command = ["-d", "-i", "-t", "--entrypoint=/bin/bash", "{{.Image}}"]
}

build {
    sources = ["docker.docker"]

    post-processor "manifest" {
        output = "manifest.json"
        strip_path = true
        custom_data = {
          my_custom_data = "example"
        }
    }
}
</Tab> <Tab heading="JSON">
json
{
  "builders": [
    {
      "type": "docker",
      "image": "ubuntu:latest",
      "export_path": "packer_example",
      "run_command": ["-d", "-i", "-t", "--entrypoint=/bin/bash", "{{.Image}}"]
    }
  ],
  "post-processors": [
    {
      "type": "manifest",
      "output": "manifest.json",
      "strip_path": true,
      "custom_data": {
        "my_custom_data": "example"
      }
    }
  ]
}
</Tab> </Tabs>

Example usage:

The manifest can be very useful for cleaning up old artifacts, or printing important values to logs. The following example uses jq, a command-line tool for parsing json output, to find and echo the AWS ami-id of an AMI created by a build.

bash

#!/bin/bash

AMI_ID=$(jq -r '.builds[-1].artifact_id | split(":") | .[1]' manifest.json)
echo $AMI_ID