Community-maintained builders are not part of the core Packer binary, but
can run alongside Packer with minimal extra effort.
page_title: Community - Builders
Community-supported builders are developed and maintained by third-parties and not HashiCorp. Use them with Packer to extend Packer functionality.
page_title: Community-supported builders
---
# Community Builders
# Community-supported builders
The following builders are developed and maintained by various members of the
Packer community, not by HashiCorp. For more information on how to use community
builders, see our docs on [extending Packer](/packer/docs/plugins/creation).
builders, refer to our docs on [extending Packer](/packer/docs/plugins/creation).
@include 'builders/community_builders.mdx'
- ARM builders
- [packer-plugin-arm-image](https://github.com/solo-io/packer-plugin-arm-image): Lets you extend onto existing system images.
- [packer-builder-arm](https://github.com/mkaczanowski/packer-builder-arm): Lets you extend or build new images with a variety of options, such as custom partition tables.
- [Exoscale builder](https://github.com/exoscale/packer-plugin-exoscale) - Creates Exoscale custom templates based on a compute instance snapshot.
- [Citrix XenServer/Citrix Hypervisor](https://github.com/xenserver/packer-builder-xenserver) - Plugin for creating [Citrix XenServer/Citrix Hypervisor](https://xenserver.org/) images from an ISO image or from an existing template.
- [XCP-NG/Citrix XenServer/Citrix Hypervisor/Updated Fork](https://github.com/ddelnano/packer-plugin-xenserver) - Plugin for creating [XCP-NG/Citrix XenServer/Citrix Hypervisor](https://xcp-ng.org/) images from an ISO image or from an existing template. This is a fork of the orginal and reccomended by the developers of XCP-NG.
Builders are responsible for creating machines and generating images from them
for various platforms.
page_title: Builders
Builders create machines and generate images from them for various platforms. Learn about the types of builders you can use in your Packer templates.
page_title: Builders overview
---
# Builders
# Builders overview
Builders create machines and generate images from those machines for various platforms. Packer also has some builders that perform helper tasks, like running provisioners.
Builders create machines and generate images from those machines for various platforms. Some builders in Packer perform helper tasks, such as running provisioners.
Packer has the following types of builders:
- [Plugin](/packer/plugins): Each plugin has its own associated set of builders. For example, there are separate builders for EC2, VMware, VirtualBox, etc.
- [File](/packer/docs/builders/file): The `file` builder creates an artifact from a file.
- [Null](/packer/docs/builders/null): The `null` builder sets up an SSH connection and runs the provisioners.
- [Plugins](/packer/plugins): Plugins that you install have their own associated set of builders. For example, EC2, VMware, and VirtualBox use their own separate sets of builders.
- [`file`](/packer/docs/builders/file): The `file` builder creates an artifact from a file.
- [`null`](/packer/docs/builders/null): The `null` builder sets up an SSH connection and runs the provisioners.
- [Custom](/packer/docs/plugins/creation/custom-builders): You can write new builders for new or existing platforms.
- [Community-Supported](/packer/docs/builders/community-supported): The Packer community develops and maintains builders for several additional platforms.
- [Community-supported](/packer/docs/builders/community-supported): The Packer community develops and maintains builders for several additional platforms.
Refer to the [`source`](/packer/docs/templates/hcl_templates/blocks/source) block documentation to learn more about configuring builders in the Packer templating language.
The null Packer builder is not really a builder, it just sets up an SSH
connection and runs the provisioners. It can be used to debug provisioners
without incurring high wait times. It does not create any kind of image or
artifact.
page_title: Null - Builders
The `null` builder creates an SSH connection and runs provisioners. Use the `null` builder to debug provisioners without incurring long wait times.
page_title: null builder reference
---
<BadgesHeader>
<PluginBadge type="official" />
</BadgesHeader>
# Null Builder
# `null` builder
Type: `null`
The `null` Packer builder is not really a builder, it just sets up an SSH
connection and runs the provisioners. It can be used to debug provisioners
without incurring high wait times. It does not create any kind of image or
artifact.
The `null` builder sets up an SSH connection and runs provisioners. You can use it to debug provisioners without incurring long wait times. It does not create a images or artifacts.
Packer has a vibrant community of contributors who have built a number of
great tools on top of Packer. There are also quite a few projects
demonstrating the power of Packer templates.
Packer community contributors have built many Packer tools and projects that demonstrate Packer templates. Learn about Packer community projects you can download.
---
# Download Community Projects
# Download Packer Community Projects
Packer has a vibrant community of contributors who have built a number of great
tools on top of Packer. There are also quite a few projects demonstrating the
Packer can publish metadata for completed builds to an HCP Packer Registry. Legacy JSON templates can connect to the registry using environment variables. HCL2 templates can connect using an hcp_packer_registry block.
page_title: HCP Packer
Packer can publish metadata for completed builds to the HCP Packer registry. Learn how to connect Packer to the HCP Packer registry.
page_title: Connect to the HCP Packer registry overview
---
-> **Note:** On May 16th 2023, HCP introduced multi-project support to the platform. In order to use multiple projects
in your organization, you will need to update Packer to version 1.9.1 or above. Starting with 1.9.1, you may specify
a project ID to push builds to with the `HCP_PROJECT_ID` environment variable. If no project ID is specified,
Packer will pick the project with the oldest creation date. Older versions of Packer are incompatible with multi-project
support on HCP, and builds will fail for HCP organizations with multiple projects on versions before 1.9.1.
# Connect to the HCP Packer Registry
# HCP Packer
This topic provides an overview of how to connect JSON and HCL2 templates to the HCP Packer registry and provides a full list of HCP Packer environment variables. Refer to the
[Packer Template Configuration](/hcp/docs/packer/store-image-metadata/packer-template-configuration) page in the HCP
Packer documentation for configuration details and examples.
# Introduction
The HCP Packer registry bridges the gap between artifact factories and artifact deployments, allowing development and
security teams to work together to create, manage, and consume artifacts in a centralized way.
@ -24,12 +24,11 @@ configurations.
You can use HCP Packer with both JSON and HCL2 templates. If you are using JSON templates, we recommend getting started with
the [HCP Packer environment variables](#hcp-packer-environment-variables) and then migrating to HCL when possible.
This page summarizes the methods you can use to connect JSON and HCL2 templates to the HCP Packer registry. It also
provides a full list of HCP Packer environment variables. Refer to the
[Packer Template Configuration](/hcp/docs/packer/store-image-metadata/packer-template-configuration) page in the HCP
Packer documentation for full configuration details and examples.
## Requirements
Packer version 1.9.1 or newer is required to use the `HCP_PROJECT_ID` environment variable, which lets Packer connect to specific projects in HCP. Your builds will fail if you configure them to send mulit-project metadata using Packer versions older than 1.9.1.
### HCP Packer Environment Variables
## HCP Packer environment variables
The following environment variables let you configure Packer to push artifact metadata to an active registry without
changing your template. You can use environment variables with both JSON and HCL2 templates.
@ -70,7 +69,7 @@ principal, otherwise Packer will attempt to get the list of projects for an orga
permissions for a project-level service principal. This is supported starting with Packer 1.9.3; older versions of
Packer do not support using project-level service principals.
### HCP Packer Registry Block
## HCP Packer registry block
The only metadata that Packer can infer from a template with the basic configuration are the build name and build fingerprint.
For HCL2 templates, we recommend adding the `hcp_packer_registry` block to your template so that you can customize
@ -82,7 +81,7 @@ Refer to [`hcp_packer_registry`](/packer/docs/templates/hcl_templates/blocks/bui
of configuration arguments. Refer to [Custom Configuration](/hcp/docs/packer/store-image-metadata/packer-template-configuration#custom-configuration)
in the HCP Packer documentation for information and examples about how to customize artifact metadata.
### Version Fingerprinting
## Version fingerprinting
Packer uses a unique fingerprint for tracking the completion of builds associated to a version. By default a fingerprint
is automatically generated by Packer during each invocation of `packer build`, unless a fingerprint is manually provided
Packer allows you to create identical machine images for multiple platforms from a single source template.
page_title: Documentation
The Packer documentation describes how to use Packer and providers reference information for configuring Packer templates.
page_title: Packer documentation
---
# Packer Documentation
@ -16,4 +16,8 @@ The HCP Packer registry stores metadata about your artifacts. You can use the re
artifacts from your Packer builds, clearly designate which artifacts are appropriate for test and production
environments, and query for the right artifacts to use in both Packer and Terraform configurations.
To get started, visit the [HCP Packer documentation](/hcp/docs/packer) or try the [Get Started with HCP Packer tutorials](/packer/tutorials/hcp-get-started).
Welcome to the world of Packer! This introduction guide will show you what
Packer is, explain why it exists, the benefits it has to offer, and how you
can get started with it. If you're already familiar with Packer, the
documentation provides more of a reference for all available features.
page_title: Introduction to Packer
description: Packer is a community tool for creating identical machine images for multiple platforms from a single source configuration. Learn about Packer benefits and how to get started.
---
# Introduction to Packer
Welcome to the world of Packer! This introduction guide will show you what
Packer is, explain why it exists, the benefits it has to offer, and how you can
get started with it. If you're already familiar with Packer, the
[documentation](/packer/docs) provides more of a reference for all available
features.
This introduction describes Packer benefits and how you can get started with it.
## What is Packer?
@ -27,5 +19,9 @@ use tools like Chef or Puppet to install software onto the image.
A _machine image_ is a single static unit that contains a pre-configured
operating system and installed software which is used to quickly create new
running machines. Machine image formats change for each platform. Some examples
include [AMIs](https://en.wikipedia.org/wiki/Amazon_Machine_Image) for EC2,
VMDK/VMX files for VMware, OVF exports for VirtualBox, etc.
include AMIs for EC2, VMDK and VMX files for VMware, and OVF exports for VirtualBox.
## HCP Packer
For information about using HCP Packer to store metadata about build artifacts, refer to the
[HCP Packer documentation](/hcp/docs/packer) or [sign into HCP](https://portal.cloud.hashicorp.com/sign-in) to explore HCP Packer features.
By now you should know what Packer does and what the benefits of image
creation are. In this section, we'll enumerate *some* of the use cases for
Packer. Note that this is not an exhaustive list by any means. There are
definitely use cases for Packer not listed here. This list is just meant to
give you an idea of how Packer may improve your processes.
Learn about use cases for Packer, such as continuous delivery, dev/prod parity, and appliance and demo creation.
---
# Use Cases
# Packer use cases
By now you should know what Packer does and what the benefits of image creation
are. In this section, we'll enumerate _some_ of the use cases for Packer. Note
that this is not an exhaustive list by any means. There are definitely use cases
for Packer not listed here. This list is just meant to give you an idea of how
Packer may improve your processes.
In this topic describes some of the use cases for Packer. This is a partial list of use cases intended to give you an idea of how Packer may improve your processes.
### Continuous Delivery
## Continuous delivery
Packer is lightweight, portable, and command-line driven. This makes it the
perfect tool to put in the middle of your continuous delivery pipeline. Packer
@ -28,12 +20,12 @@ tested, verifying the infrastructure changes work. If the tests pass, you can be
confident that the image will work when deployed. This brings a new level of
stability and testability to infrastructure changes.
### Dev/Prod Parity
## Environment parity
Packer helps [keep development, staging, and production as similar as
possible](http://www.12factor.net/dev-prod-parity). Packer can be used to
generate images for multiple platforms at the same time. So if you use AWS for
production and VMware (perhaps with [Vagrant](https://www.vagrantup.com/)) for
Packer helps keep development, staging, and production as similar as
possible. Refer to the following external article to learn more about parity between environments: ["X. Dev/prod parity"](http://www.12factor.net/dev-prod-parity).
You can use Packer to generate images for multiple platforms at the same time. So if you use AWS for production and VMware, perhaps with [Vagrant](https://www.vagrantup.com/), for
development, you can generate both an AMI and a VMware machine using Packer at
the same time from the same template.
@ -41,9 +33,9 @@ Mix this in with the continuous delivery use case above, and you have a pretty
slick system for consistent work environments from development all the way
through to production.
### Appliance/Demo Creation
## Appliance and demo creation
Since Packer creates consistent images for multiple platforms in parallel, it is
Because Packer creates consistent images for multiple platforms in parallel, it is
perfect for creating
[appliances](https://en.wikipedia.org/wiki/Software_appliance) and disposable
product demos. As your software changes, you can automatically create appliances
Pre-baked machine images have a lot of advantages, but most have been unable
to benefit from them because images have been too tedious to create and
manage. There were either no existing tools to automate the creation of
machine images or they had too high of a learning curve. The result is that,
prior to Packer, creating machine images threatened the agility of operations
teams, and therefore aren't used, despite the massive benefits.
Learn about the advantages of using Packer to automate the creation of machine images and artifacts.
---
# Why Use Packer?
# Why use Packer
Pre-baked machine images have a lot of advantages, but most have been unable to
This topic describes why you should use Packer to automate the creation of machine images over traditional _pre-baked_ images, which are pre-configured digital images that include the necessary software, settings, and data.
## Pre-baked images
Pre-baked machine images have a lot of advantages, but most people have been unable to
benefit from them because images have been too tedious to create and manage.
There were either no existing tools to automate the creation of machine images
There are either no existing tools to automate the creation of machine images
or they had too high of a learning curve. The result is that, prior to Packer,
creating machine images threatened the agility of operations teams, and
therefore aren't used, despite the massive benefits.
@ -23,10 +22,7 @@ any type of machine image. It embraces modern configuration management by
encouraging you to use a framework such as Chef or Puppet to install and
configure the software within your Packer-made images.
In other words: Packer brings pre-baked images into the modern age, unlocking
untapped potential and opening new opportunities.
## Advantages of Using Packer
## Advantages of using Packer
**_Super fast infrastructure deployment_**. Packer images allow you to launch
completely provisioned and configured machines in seconds, rather than several
@ -48,8 +44,4 @@ launched.
**_Greater testability_**. After a machine image is built, that machine image
can be quickly launched and smoke tested to verify that things appear to be
working. If they are, you can be confident that any other machines launched from
that image will function properly.
Packer makes it extremely easy to take advantage of all these benefits.
The HashiCorp Packer Integration Program allows vendors to integrate
their products to work with Packer.
page_title: Integration Program
The Packer Integration Program helps vendors integrate their products with Packer. Learn how to participate in the Packer integration program.
page_title: Packer integration program
---
# Packer Integration Program
# Packer integration program
The HashiCorp Packer Integration Program allows vendors to integrate their products to work with Packer.
@ -13,7 +12,7 @@ Vendors integrating their solutions via the Packer Integration Process provide t
This program is intended to be largely a self-service process with links and guidance to information sources, clearly defined steps, and checkpoints.
### Types of Packer Integrations
## Types of Packer integrations
Packer is a community tool for creating identical machine images for multiple platforms from a single source configuration.
Packer is lightweight, runs on every major operating system, and is highly performant, creating machine images for multiple platforms in parallel. Packer does not replace configuration management like Chef or Puppet. In fact, when building images, Packer is able to use tools like Chef or Puppet to install software onto the image.
@ -39,7 +38,7 @@ Main Packer categories for partners to integrate with include:
- **Post-Processors**
- Post-Processors manage the image artifact after it has been created. This can be something general like running a compression tool against the artifact, or something specific like uploading it to a particular cloud service.
### Development Process
## Development process
The Packer integration development process is divided into six steps. By following these steps, Packer integrations can be developed alongside HashiCorp to ensure that the integrations are able to be verified and supported in Packer as quickly as possible. A visual representation of the self-guided steps is depicted below.
@ -54,15 +53,15 @@ The individual Packer integration steps include:
1. Release: Verified integration made available and listed on the HashiCorp website once the HashiCorp technology partnership agreement has been executed
1. Support: Ongoing maintenance and support of the provider by the vendor.
#### 1. Engage
### Engage
Please begin by providing some basic information about the integration that is being built via a simple [webform](https://docs.google.com/forms/d/e/1FAIpQLSfgq3HJ9Rfsi7LgPLFln28ZrmarATGlD_6A47-Io-bPUftKUw/viewform)
Begin by providing some basic information about the integration that is being built via a simple [webform](https://docs.google.com/forms/d/e/1FAIpQLSfgq3HJ9Rfsi7LgPLFln28ZrmarATGlD_6A47-Io-bPUftKUw/viewform)
This information is recorded and used by HashiCorp to track the integration through various stages. The information is also used to notify the integration developer of any overlapping work, perhaps coming from the community so you may better focus resources.
Packer has an active community and ecosystem of partners that may have already started working on a similar integration. We'll do our best to connect similar parties to avoid duplicate work.
#### 2. Enable
### Enable
While not mandatory, HashiCorp encourages vendors to sign an MNDA (Mutual Non-Disclosure Agreement) to allow for open dialog and sharing of ideas during the integration process.
@ -77,7 +76,7 @@ In an effort to support our self-serve model we’ve included links to resources
We encourage vendors to closely follow the above guidance. Adopting the same structure and coding patterns helps expedite the review and release cycles.
#### 3. Dev & Test
### Develop and test
Packer requires all code-level integrations to be written in the [Go](https://go.dev/) programming language and contain an [MPL-2.0](https://en.wikipedia.org/wiki/Mozilla_Public_License) open source license. The only knowledge necessary to write a plugin is basic command-line skills and knowledge of the Go programming language. When writing in Go, HashiCorp has found the integration development process to be straightforward and simple when vendors pay close attention and follow the resources and by adopting the same structure and coding patterns helps expedite the review and release cycles. Please remember that all integration major steps should contain acceptance testing and the appropriate documentation.
@ -105,26 +104,26 @@ Packer-Plugin-SDK
- The [Packer-plugin SDK](https://github.com/hashicorp/packer-plugin-sdk) contains tools to help plugin developers with common needs, like handling SSH connections or basic plugin architecture.
#### 4. Review
### Review
During the review process, HashiCorp will provide feedback on the newly developed integration. This is an important step to allow HashiCorp to review and verify your Packer integration. Please send the integration code and other relevant logs for verification to: [Packer-integration-dev@hashicorp.com](mailto:packer-integration-dev@hashicorp.com).
In order to document your plugins with Packer, please submit a GitHub pull request (PR) against the [Packer project](https://github.com/hashicorp/packer). See [Registering Plugin Documentation](/packer/docs/plugins/creation#registering-plugin-documentation) for instructions on how to register your remote plugin documentation with Packer.
The review process can take a while to complete and may require some iterations through the code to address any problems identified by the HashiCorp team.
#### 5. Release
### Release
At this stage, it is expected that the integration is fully complete, the necessary documentation has been written, the acceptance tests have all passed, and that HashiCorp has reviewed the integration. Once the plugin has been validated and accepted by HashiCorp, the plugin can be hosted on GitHub so it can easily be [downloaded then installed within Packer](/packer/docs/plugins/creation#creating-a-github-release).
Once the integration has been released the vendor is requested to sign the HashiCorp Technology Partner Agreement so that we can have their integration be listed on the HashiCorp website.
#### 6. Support
### Support
Many vendors view the release step to be the end of the journey, while at HashiCorp we view it to be the beginning of the journey. Getting the integration built is just the first step in enabling users to leverage it against their infrastructure. Once development is completed, on-going effort is required to support the developed integration, maintain the plugin and address any issues in a timely manner.
The expectation from the vendor/partner is to create a mechanism for them to track and resolve all issues on an ongoing basis. Vendors who choose to not support their integration will not be considered a verified integration and cannot be listed on the website.
### Checklist
## Checklist
Below is an ordered checklist of steps that should be followed during the integration process. This just reiterates the steps already documented in the sections above.
@ -142,6 +141,6 @@ Below is an ordered checklist of steps that should be followed during the integr
</Checklist>
### Contact Us
## Contact Us
For any questions or feedback, please contact us at: packer-integration-dev@hashicorp.com.
It is possible to write custom builders using the Packer plugin interface, and
this page documents how to do that.
page_title: Custom Builders - Extending
You can create custom builders for Packer that extend building functionality. Learn how write custom builders using the Packer plugin interface.
page_title: Create custom builders
---
# Custom Builders
# Create Custom Builders
Packer builders are responsible for creating a virtual machine, setting the virtual machine up for provisioning, and then turning that provisioned virtual machine into a machine image. We officially maintain and distribute several builders, including builders to create images on Amazon EC2, VMware, Google
Compute Engine, and many more. Refer to the [Builders](/packer/docs/builders) documentation for details.
Packer Post-processors are the components of Packer that transform one
artifact
into another, for example by compressing files, or uploading them.
page_title: Custom Post-Processors - Extending
Post-processors compress files, upload files, and perform other tasks that transform artifacts. Learn how to create customm post-processors that extend Packer.
page_title: Create custom post-processors
---
# Custom Post-Processors
# Create custom post-processors
Packer post-processors transform one artifact into another. For example, a post-processor might compress or upload files.
Packer Provisioners are the components of Packer that install and configure
Provisioners install and configure software prior to turning a machine into an image. Learn how to create custom provisioners that extend Packer functionality.
software into a running machine prior to turning that machine into an image.
An
example of a provisioner is the shell provisioner, which runs shell scripts
within the machines.
page_title: Custom Provisioners - Extending
page_title: Create custom provisioners
---
# Custom Provisioners
# Create Custom Provisioners
Packer provisioners install and configure software into a running machine prior to turning that machine into an image. For example, the [shell
provisioner](/packer/docs/provisioners/shell), which runs shell scripts within
the machines.
Packer provisioners install and configure software into a running machine prior to turning that machine into an image. For example, the [shell provisioner](/packer/docs/provisioners/shell) runs shell scripts within machines.
Provisioner plugins implement the [`packer.Provisioner`](https://pkg.go.dev/github.com/hashicorp/packer-plugin-sdk/packer#Provisioner) interface and are served
using the `plugin.ServeProvisioner` function.
@ -43,7 +35,7 @@ type Provisioner interface {
}
```
### The "Prepare" Method
### The `Prepare` Method
The `Prepare` method for each provisioner is called prior to any runs with the
configuration that was given in the template. This is passed in as an array of
@ -69,14 +61,14 @@ validate the configuration.
The `Prepare` method is called very early in the build process so that errors
may be displayed to the user before anything actually happens.
### The "ConfigSpec" Method
### The `ConfigSpec` Method
This method returns a hcldec.ObjectSpec, which is a spec necessary for using
This method returns a `hcldec.ObjectSpec`, which is a spec necessary for using
HCL2 templates with Packer. For information on how to use and implement this
HCP Packer support allows plugins to manage image metadata that can be stored in a HCP Packer registry.
page_title: HCP Packer Support
You can create or modify custom plugins to support HCP Packer. Add support for HCP Packer to let plugins manage image metadata stored in the HCP Packer registry.
page_title: Enable HCP Packer support for custom plugins
---
# HCP Packer Support
~> **Note:** HCP Packer is under active development, and we suggest plugin maintainers to keep up with the SDK changes
for more on HCP Packer support.
# Enable HCP Packer Support for Custom Plugins
This page explains how to update a custom plugin so that it can publish image metadata to the [HCP Packer registry](/hcp/docs/packer). Refer to [Custom Builders](/packer/docs/plugins/creation/custom-builders) and [Custom Post-Processors](/packer/docs/plugins/creation/custom-post-processors) for details about creating an external Packer plugin.
@ -16,6 +13,8 @@ to query a builder artifact for the image metadata that a particular component w
For details and examples of how to manage image metadata, refer to the [HCP Packer GitHub documentation](https://pkg.go.dev/github.com/hashicorp/packer-plugin-sdk/packer/registry/image).
HCP Packer is under active development, and we suggest plugin maintainers to keep up with the SDK changes for more on HCP Packer support.
## Builder Artifact
To support HCP Packer, changes must be made to the plugin's build artifact. The artifact should keep the appropriate
@ -110,6 +109,8 @@ The following plugins currently support HCP Packer and are great references for
## HCP Packer
To get to know HCP Packer, visit the
[HCP Packer documentation](/hcp/docs/packer) or try the
[Get Started with HCP Packer tutorials](/packer/tutorials/hcp-get-started).
Refer to the following resources to learn about HCP Packer:
Packer is designed to be extensible. Because the surface area for workloads is
infinite, Packer supports plugins for builders, provisioners, and
post-processors.
page_title: Extending
Learn about extending Packer by creating custom plugins for builders, provisioners, and
post-processors.
page_title: Create custom plugins to extend Packer overview
---
# Developing Plugins
# Create Custom Plugins to Extend Packer
Packer is extensible and supports plugins that let you
create and use custom builders, provisioners, post-processors, and data sources. This page explains how to develop Packer plugins. Before you begin, we recommend reviewing the Packer documentation and the instructions for [installing external plugins](/packer/docs/plugins/install).
Install external Packer plugins that extend Packer functionality.
You can install plugins to extend Packer functionality. Learn how to install external plugins.
page_title: Install Plugins
---
# Installing Plugins
# Install Plugins
This topic describes how to install external plugins for Packer. Refer to [Packer Plugins Overview](/packer/docs/plugins) for additional information about plugins.
There are a handful of terms used throughout the Packer documentation where
the
meaning may not be immediately obvious if you haven't used Packer before.
Luckily, there are relatively few. This page documents all the terminology
required to understand and use Packer. The terminology is in alphabetical
order
for quick referencing.
page_title: Terminology
Packer and the Packer documentation uses a vocabulary of terms that have specific meaning. Learn about Packer terminology in this glossary.
page_title: Packer terminology
---
# Packer Terminology
# Packer terminology
There are a handful of terms used throughout the Packer documentation where the
meaning may not be immediately obvious if you haven't used Packer before.
Luckily, there are relatively few. This page documents all the terminology
required to understand and use Packer. The terminology is in alphabetical order
for quick referencing.
This page documents terminology we use throughout this documentation that have a specific meaning in Packer. These terms may not be immediately obvious if you have not used Packer before.
- `Artifacts` are the results of a single build, and are usually a set of IDs
- _Artifacts_ are the results of a single build, and are usually a set of IDs
or files to represent a machine image. Every builder produces a single
artifact. As an example, in the case of the Amazon EC2 builder, the
artifact is a set of AMI IDs (one per region). For the VMware builder, the
artifact is a directory of files comprising the created virtual machine.
- `Builds` are a single task that eventually produces an artifact for a single
- _Builds_ are a single task that eventually produces an artifact for a single
platform. Multiple builds run in parallel. Example usage in a sentence:
"The Packer build produced an AMI to run our web application." Or: "Packer
is running the builds now for VMware, AWS, and VirtualBox."
- `Builders` are components of Packer that are able to create a machine image
- _Builders_ are components of Packer that are able to create a machine image
for a single platform. Builders read in some configuration and use that to
run and generate a machine image. A builder is invoked as part of a build
in order to create the actual resulting artifacts. Example builders include
VirtualBox, VMware, and Amazon EC2.
- `Commands` are sub-commands for the `packer` program that perform some job.
- _Commands_ are sub-commands for the `packer` program that perform a job.
An example command is "build", which is invoked as `packer build`. Packer
ships with a set of commands out of the box in order to define its
command-line interface.
- `Data Sources` are components of Packer that fetch data from outside Packer
- _Data sources_ are components of Packer that fetch data from outside Packer
and make it available to use within the template.
Example of data sources include Amazon AMI, and Amazon Secrets Manager.
- `Post-processors` are components of Packer that take the result of a
- _Post-processors_ are components of Packer that take the result of a
builder or another post-processor and process that to create a new
artifact. Examples of post-processors are compress to compress artifacts,
upload to upload artifacts, etc.
- `Provisioners` are components of Packer that install and configure software
- _Provisioners_ are components of Packer that install and configure software
within a running machine prior to that machine being turned into a static
artifact. They perform the major work of making the artifact contain useful
software. Example provisioners include shell scripts, Chef, Puppet, etc.
- `Templates` are either [HCL](https://packer.io/templates/hcl_templates) or JSON files which
define one or more builds by configuring the various components of Packer.
Packer is able to read a template and use that information to create
multiple machine images in parallel.
- _Templates_ are either [HCL](https://packer.io/templates/hcl_templates) or JSON files that define one or more builds by configuring the various components of Packer. Packer reads a template and uses the information to create multiple machine images in parallel.
- [packer-plugin-arm-image](https://github.com/solo-io/packer-plugin-arm-image) - simple builder lets you extend on existing system images.
- [packer-builder-arm](https://github.com/mkaczanowski/packer-builder-arm) - flexible builder lets you extend or build images from scratch with variety of options (ie. custom partition table).
- [Exoscale builder](https://github.com/exoscale/packer-plugin-exoscale) - A builder to create Exoscale custom templates based on a Compute instance snapshot.
- [Citrix XenServer/Citrix Hypervisor](https://github.com/xenserver/packer-builder-xenserver) - Plugin for creating [Citrix XenServer/Citrix Hypervisor](https://xenserver.org/) images from an iso image or from an existing template.
- [XCP-NG/Citrix XenServer/Citrix Hypervisor/Updated Fork](https://github.com/ddelnano/packer-plugin-xenserver) - Plugin for creating [XCP-NG/Citrix XenServer/Citrix Hypervisor](https://xcp-ng.org/) images from an iso image or from an existing template. This is a fork of the orginal, and reccomended by the developers of XCP-NG.
trujillo-adam
1 year ago
committed by
GitHub