github.com/hashicorp/packer@v1.14.3/website/content/docs/post-processors/artifice.mdx (about)

     1  ---
     2  description: >
     3    The `artifice` post-processor overrides the artifact list from an upstream builder or post-processor. Use it to build artifacts inside a Packer builder, such as starting an EC2 instance to build a Docker container, but only keep the Docker container's artifacts.
     4  page_title: artifice post-processor reference
     5  ---
     6  
     7  <BadgesHeader>
     8    <PluginBadge type="official" />
     9  </BadgesHeader>
    10  
    11  # `artifice` post-processor
    12  
    13  Artifact BuilderId: `packer.post-processor.artifice`
    14  
    15  The artifice post-processor overrides the artifact list from an upstream
    16  builder or post-processor. All downstream post-processors will see the new
    17  artifacts you specify.
    18  
    19  After overriding the artifact with artifice, you can use it with other
    20  post-processors, including most of the core post-processors and third-party
    21  post-processors.
    22  
    23  A major benefit of this is that you can modify builder
    24  artifacts using shell-local and pass those modified artifacts into
    25  post-processors that may not have worked with the original builder.
    26  For example, maybe you want to export a Docker container from an amazon-ebs
    27  builder and then use Docker-push to put that Docker container into your Docker
    28  Hub account.
    29  
    30  Artifice allows you to use the familiar packer workflow to create a fresh,
    31  stateless build environment for each build on the infrastructure of your
    32  choosing. You can use this to build just about anything: buildpacks,
    33  containers, jars, binaries, tarballs, msi installers, and more.
    34  
    35  Please note that the artifice post-processor will _not_ delete your old artifact
    36  files, even if it removes them from the artifact. If you want to delete the
    37  old artifact files, you can use the shell-local post-processor to do so.
    38  
    39  ## Workflow
    40  
    41  Artifice helps you tie together a few other packer features:
    42  
    43  - A builder, which spins up a VM (or container) to build your artifact
    44  - A provisioner, which performs the steps to create your artifact
    45  - A file provisioner, which downloads the artifact from the VM
    46  - The artifice post-processor, which identifies which files have been
    47    downloaded from the VM
    48  - Additional post-processors, which push the artifact to Docker hub, etc.
    49  
    50  You will want to perform as much work as possible inside the VM. Ideally the
    51  only other post-processor you need after artifice is one that uploads your
    52  artifact to the appropriate repository.
    53  
    54  ## Configuration
    55  
    56  The configuration allows you to specify which files comprise your artifact.
    57  
    58  ### Required:
    59  
    60  - `files` (array of strings) - A list of files that comprise your artifact.
    61    These files must exist on your local disk after the provisioning phase of
    62    packer is complete. These will replace any of the builder's original
    63    artifacts (such as a VM snapshot).
    64  
    65  ### Optional:
    66  
    67  - `keep_input_artifact` (boolean) - if true, do not delete the original
    68    artifact files after creating your new artifact. Defaults to true.
    69  
    70  ### Example Configuration
    71  
    72  You can use Packer to deploy HashiCorp Consul, which is a service discovery and service mesh solution. Refer to the [Consul website](https://www.hashicorp.com/en/products/consul) for additional information. 
    73  
    74  In this example, Packer uses a minimal configuration to perform the following actions:
    75  
    76  1. Spins up a cloned VMware virtual machine
    77  1. Installs a Consul release. 
    78  1. Downloads the Consul binary.
    79  1. Packages Consul into a `.tar.gz` file.
    80  1. Uploads Consul to S3.
    81  
    82  VMX is a fast way to build and test locally, but you can substitute a different builder.
    83  
    84  ```json
    85  {
    86    "builders": [
    87      {
    88        "type": "vmware-vmx",
    89        "source_path": "/opt/ubuntu-1404-vmware.vmx",
    90        "ssh_username": "vagrant",
    91        "ssh_password": "vagrant",
    92        "shutdown_command": "sudo shutdown -h now",
    93        "headless": "true",
    94        "skip_compaction": "true"
    95      }
    96    ],
    97    "provisioners": [
    98      {
    99        "type": "shell",
   100        "inline": [
   101          "sudo apt-get install -y python-pip",
   102          "sudo pip install ifs",
   103          "sudo ifs install consul --version=0.5.2"
   104        ]
   105      },
   106      {
   107        "type": "file",
   108        "source": "/usr/local/bin/consul",
   109        "destination": "consul",
   110        "direction": "download"
   111      }
   112    ],
   113    "post-processors": [
   114      [
   115        {
   116          "type": "artifice",
   117          "files": ["consul"]
   118        },
   119        {
   120          "type": "compress",
   121          "output": "consul-0.5.2.tar.gz"
   122        },
   123        {
   124          "type": "shell-local",
   125          "inline": [
   126            "/usr/local/bin/aws s3 cp consul-0.5.2.tar.gz s3://<s3 path>"
   127          ]
   128        }
   129      ]
   130    ]
   131  }
   132  ```
   133  
   134  **Notice that there are two sets of square brackets in the post-processor
   135  section.** This creates a post-processor chain, where the output of the
   136  proceeding artifact is passed to subsequent post-processors. If you use only
   137  one set of square braces the post-processors will run individually against the
   138  build artifact (the vmx file in this case) and it will not have the desired
   139  result.
   140  
   141  ```json
   142  {
   143    "post-processors": [
   144      [       // <--- Start post-processor chain
   145        {
   146          "type": "artifice",
   147          "files": ["consul"]
   148        },
   149        {
   150          "type": "compress",
   151          ...
   152        }
   153      ],      // <--- End post-processor chain
   154      {
   155        "type":"compress"  // <-- Standalone post-processor
   156      }
   157    ]
   158  }
   159  ```
   160  
   161  You can create multiple post-processor chains to handle multiple builders (for
   162  example, building Linux and Windows binaries during the same build).