Merge pull request #10635 from hashicorp/docs_small_changes
Docs small updates
This commit is contained in:
Megan Marsh
GitHub
commit
0d14df3020
|
|
@ -19,7 +19,7 @@ can quickly merge or address your contributions.
|
|||
already fixed the bug you're experiencing.
|
||||
|
||||
- Run the command with debug output with the environment variable `PACKER_LOG`.
|
||||
For example: `PACKER_LOG=1 packer build template.json`. Take the _entire_
|
||||
For example: `PACKER_LOG=1 packer build template.pkr.hcl`. Take the _entire_
|
||||
output and create a [gist](https://gist.github.com) for linking to in your
|
||||
issue. Packer should strip sensitive keys from the output, but take a look
|
||||
through just in case.
|
||||
|
|
@ -91,7 +91,7 @@ The instructions below are for go 1.7. or later.
|
|||
4. After running building Packer successfully, use
|
||||
`$GOPATH/src/github.com/hashicorp/packer/bin/packer` to build a machine and
|
||||
verify your changes work. For instance:
|
||||
`$GOPATH/src/github.com/hashicorp/packer/bin/packer build template.json`.
|
||||
`$GOPATH/src/github.com/hashicorp/packer/bin/packer build template.pkr.hcl`.
|
||||
|
||||
5. If everything works well and the tests pass, run `go fmt` on your code before
|
||||
submitting a pull-request.
|
||||
|
|
|
|||
|
|
@ -116,7 +116,7 @@ Usage:
|
|||
$ export AWS_ACCESS_KEY_ID="anaccesskey"
|
||||
$ export AWS_SECRET_ACCESS_KEY="asecretkey"
|
||||
$ export AWS_DEFAULT_REGION="us-west-2"
|
||||
$ packer build packer.json
|
||||
$ packer build template.pkr.hcl
|
||||
|
||||
### Shared Credentials file
|
||||
|
||||
|
|
|
|||
|
|
@ -155,7 +155,7 @@ This builder requires privileged actions, such as mounting disks, running
|
|||
permissions, for example:
|
||||
|
||||
```shell-session
|
||||
$ sudo -E packer build example.json
|
||||
$ sudo -E packer build example.pkr.json
|
||||
```
|
||||
|
||||
### Using a VM with a Managed Identity
|
||||
|
|
@ -164,6 +164,30 @@ On a VM with a system-assigned managed identity that has the contributor role
|
|||
on its own resource group, the following config can be used to create an
|
||||
updated Debian image:
|
||||
|
||||
<Tabs>
|
||||
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
source "azure-chroot" "example" {
|
||||
image_resource_id = "/subscriptions/{{vm `subscription_id`}}/resourceGroups/{{vm `resource_group`}}/providers/Microsoft.Compute/images/MyDebianOSImage-{{timestamp}}"
|
||||
source = "credativ:Debian:9:latest"
|
||||
}
|
||||
|
||||
build {
|
||||
sources = ["source.azure-chroot.example"]
|
||||
|
||||
provisioner "shell" {
|
||||
inline = ["apt-get update", "apt-get upgrade -y"]
|
||||
inline_shebang = "/bin/sh -x"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
{
|
||||
"builders": [
|
||||
|
|
@ -184,6 +208,9 @@ updated Debian image:
|
|||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
### Using a Service Principal
|
||||
|
||||
Here is an example that creates a Debian image with updated packages. Specify
|
||||
|
|
@ -195,40 +222,6 @@ Set the `ARM_IMAGE_RESOURCEGROUP_ID` variable to an existing resource group in t
|
|||
subscription where the resulting image will be created.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
{
|
||||
"variables": {
|
||||
"client_id": "{{env `ARM_CLIENT_ID`}}",
|
||||
"client_secret": "{{env `ARM_CLIENT_SECRET`}}",
|
||||
"subscription_id": "{{env `ARM_SUBSCRIPTION_ID`}}",
|
||||
"resource_group": "{{env `ARM_IMAGE_RESOURCEGROUP_ID`}}"
|
||||
},
|
||||
"builders": [
|
||||
{
|
||||
"type": "azure-chroot",
|
||||
|
||||
"client_id": "{{user `client_id`}}",
|
||||
"client_secret": "{{user `client_secret`}}",
|
||||
"subscription_id": "{{user `subscription_id`}}",
|
||||
|
||||
"image_resource_id": "/subscriptions/{{user `subscription_id`}}/resourceGroups/{{user `resource_group`}}/providers/Microsoft.Compute/images/MyDebianOSImage-{{timestamp}}",
|
||||
|
||||
"source": "credativ:Debian:9:latest"
|
||||
}
|
||||
],
|
||||
"provisioners": [
|
||||
{
|
||||
"inline": ["apt-get update", "apt-get upgrade -y"],
|
||||
"inline_shebang": "/bin/sh -x",
|
||||
"type": "shell"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
|
|
@ -265,5 +258,39 @@ build {
|
|||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
{
|
||||
"variables": {
|
||||
"client_id": "{{env `ARM_CLIENT_ID`}}",
|
||||
"client_secret": "{{env `ARM_CLIENT_SECRET`}}",
|
||||
"subscription_id": "{{env `ARM_SUBSCRIPTION_ID`}}",
|
||||
"resource_group": "{{env `ARM_IMAGE_RESOURCEGROUP_ID`}}"
|
||||
},
|
||||
"builders": [
|
||||
{
|
||||
"type": "azure-chroot",
|
||||
|
||||
"client_id": "{{user `client_id`}}",
|
||||
"client_secret": "{{user `client_secret`}}",
|
||||
"subscription_id": "{{user `subscription_id`}}",
|
||||
|
||||
"image_resource_id": "/subscriptions/{{user `subscription_id`}}/resourceGroups/{{user `resource_group`}}/providers/Microsoft.Compute/images/MyDebianOSImage-{{timestamp}}",
|
||||
|
||||
"source": "credativ:Debian:9:latest"
|
||||
}
|
||||
],
|
||||
"provisioners": [
|
||||
{
|
||||
"inline": ["apt-get update", "apt-get upgrade -y"],
|
||||
"inline_shebang": "/bin/sh -x",
|
||||
"type": "shell"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
|
|
|||
|
|
@ -75,7 +75,7 @@ Usage:
|
|||
$ export OUTSCALE_ACCESSKEYID="anaccesskey"
|
||||
$ export OUTSCALE_SECRETKEYID="asecretkey"
|
||||
$ export OUTSCALE_REGION="eu-west-2"
|
||||
$ packer build packer.json
|
||||
$ packer build template.pkr.hcl
|
||||
|
||||
### x509 Certificate Authentication
|
||||
|
||||
|
|
|
|||
|
|
@ -10,6 +10,8 @@ sidebar_title: <tt>fix</tt>
|
|||
|
||||
# `fix` Command
|
||||
|
||||
-> **Note** This command is not available on HCL2 templates yet, it will be added when we need to introduce the first 'fix'.
|
||||
|
||||
The `packer fix` command takes a template and finds backwards incompatible
|
||||
parts of it and brings it up to date so it can be used with the latest version
|
||||
of Packer. After you update to a new Packer release, you should run the fix
|
||||
|
|
|
|||
|
|
@ -22,15 +22,15 @@ Check if configuration file(s) need to be formatted, but don't write the changes
|
|||
|
||||
```shell-session
|
||||
$ packer fmt -check .
|
||||
my-template.json
|
||||
my-template.pkr.hcl
|
||||
|
||||
```
|
||||
|
||||
Format a configuration file, writing the changes back to the original file.
|
||||
|
||||
```shell-session
|
||||
$ packer fmt my-template.json
|
||||
my-template.json
|
||||
$ packer fmt my-template.pkr.hcl
|
||||
my-template.pkr.hcl
|
||||
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ description: >
|
|||
components a template defines. This can help you quickly learn about a
|
||||
template
|
||||
|
||||
without having to dive into the JSON itself. The command will tell you things
|
||||
without having to dive into the HCL itself. The command will tell you things
|
||||
|
||||
like what variables a template accepts, the builders it defines, the
|
||||
|
||||
|
|
@ -18,7 +18,7 @@ sidebar_title: <tt>inspect</tt>
|
|||
|
||||
The `packer inspect` command takes a template and outputs the various
|
||||
components a template defines. This can help you quickly learn about a template
|
||||
without having to dive into the JSON itself. The command will tell you things
|
||||
without having to dive into the HCL itself. The command will tell you things
|
||||
like what variables a template accepts, the builders it defines, the
|
||||
provisioners it defines and the order they'll run, and more.
|
||||
|
||||
|
|
@ -35,19 +35,29 @@ of your template by necessity.
|
|||
Given a basic template, here is an example of what the output might look like:
|
||||
|
||||
```shell-session
|
||||
$ packer inspect template.json
|
||||
Variables and their defaults:
|
||||
$ packer inspect template.pkr.hcl
|
||||
> input-variables:
|
||||
|
||||
aws_access_key =
|
||||
aws_secret_key =
|
||||
var.aws_access_key: "<sensitive>"
|
||||
var.aws_secret_key: "<sensitive>"
|
||||
|
||||
Builders:
|
||||
> local-variables:
|
||||
|
||||
amazon-ebs
|
||||
amazon-instance
|
||||
virtualbox-iso
|
||||
> builds:
|
||||
|
||||
Provisioners:
|
||||
> <unnamed build 0>:
|
||||
|
||||
sources:
|
||||
|
||||
amazon-ebs.foo
|
||||
amazon-instance.bar
|
||||
virtualbox-iso.basic
|
||||
|
||||
provisioners:
|
||||
|
||||
shell
|
||||
|
||||
post-processors:
|
||||
|
||||
<no post-processor>
|
||||
```
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ outputted.
|
|||
Example usage:
|
||||
|
||||
```shell-session
|
||||
$ packer validate my-template.json
|
||||
$ packer validate my-template.pkr.hcl
|
||||
Template validation failed. Errors are shown below.
|
||||
|
||||
Errors validating build 'vmware'. 1 error(s) occurred:
|
||||
|
|
|
|||
|
|
@ -49,6 +49,18 @@ compressed raw disk image artifact for us to work with, and that the GCS bucket
|
|||
has been created.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL">
|
||||
|
||||
```hcl
|
||||
post-processor "googlecompute-import"{
|
||||
account_file = "account.json"
|
||||
bucket = "my-bucket"
|
||||
project_id = "my-project"
|
||||
image_name = "my-gce-image"
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
|
|
@ -61,19 +73,6 @@ has been created.
|
|||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
|
||||
<Tab heading="HCL">
|
||||
|
||||
```hcl
|
||||
post-processor "googlecompute-import"{
|
||||
account_file = "account.json"
|
||||
bucket = "my-bucket"
|
||||
project_id = "my-project"
|
||||
image_name = "my-gce-image"
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
|
@ -82,9 +81,68 @@ post-processor "googlecompute-import"{
|
|||
Here is a complete example for building a Fedora 31 server GCE image. For this
|
||||
example Packer was run from a Debian Linux host with KVM installed.
|
||||
|
||||
$ packer build -var serial=$(tty) build.json
|
||||
$ packer build -var serial=$(tty) build.pkr.hcl
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
variables {
|
||||
account_file = "account.json"
|
||||
bucket = "my-bucket"
|
||||
project = "my-project"
|
||||
serial = ""
|
||||
}
|
||||
|
||||
source "qemu" "example" {
|
||||
accelerator = "kvm"
|
||||
boot_command = [
|
||||
"<tab> console=ttyS0,115200n8 inst.text inst.ks=http://{{ .HTTPIP }}:{{ .HTTPPort }}/fedora-31-ks.cfg rd.live.check=0<enter><wait>"
|
||||
]
|
||||
disk_size = "15000"
|
||||
format = "raw"
|
||||
iso_checksum = "sha256:225ebc160e40bb43c5de28bad9680e3a78a9db40c9e3f4f42f3ee3f10f95dbeb"
|
||||
iso_url = "https://download-ib01.fedoraproject.org/pub/fedora/linux/releases/31/Server/x86_64/iso/Fedora-Server-dvd-x86_64-31-1.9.iso"
|
||||
headless = "true"
|
||||
http_directory = "http"
|
||||
http_port_max = "10089"
|
||||
http_port_min = "10082"
|
||||
output_directory = "output"
|
||||
shutdown_timeout = "30m"
|
||||
shutdown_command = "echo 'vagrant'|sudo -S shutdown -P now"
|
||||
ssh_username = "vagrant"
|
||||
ssh_password = "vagrant"
|
||||
vm_name = "disk.raw"
|
||||
qemu_binary = "/usr/bin/kvm"
|
||||
qemuargs = [
|
||||
["-m", "1024"],
|
||||
["-cpu", "host"],
|
||||
["-chardev", "tty,id=pts,path=${var.serial}"],
|
||||
["-device", "isa-serial,chardev=pts"],
|
||||
["-device", "virtio-net,netdev=user.0"]
|
||||
]
|
||||
}
|
||||
|
||||
build {
|
||||
sources = ["source.qemu.example"]
|
||||
|
||||
post-processors {
|
||||
post-processor "compress" {
|
||||
output = "output/disk.raw.tar.gz"
|
||||
}
|
||||
post-processor "googlecompute-import" {
|
||||
account_file = var.account_file
|
||||
bucket = var.bucket
|
||||
project_id = var.project
|
||||
image_name = "fedora31-server-packertest"
|
||||
image_description = "Fedora 31 Server"
|
||||
image_family = "fedora31-server"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
|
|
@ -146,64 +204,5 @@ example Packer was run from a Debian Linux host with KVM installed.
|
|||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="HCL">
|
||||
|
||||
```hcl
|
||||
variables {
|
||||
account_file = "account.json"
|
||||
bucket = "my-bucket"
|
||||
project = "my-project"
|
||||
serial = ""
|
||||
}
|
||||
|
||||
source "qemu" "example" {
|
||||
accelerator = "kvm"
|
||||
boot_command = [
|
||||
"<tab> console=ttyS0,115200n8 inst.text inst.ks=http://{{ .HTTPIP }}:{{ .HTTPPort }}/fedora-31-ks.cfg rd.live.check=0<enter><wait>"
|
||||
]
|
||||
disk_size = "15000"
|
||||
format = "raw"
|
||||
iso_checksum = "sha256:225ebc160e40bb43c5de28bad9680e3a78a9db40c9e3f4f42f3ee3f10f95dbeb"
|
||||
iso_url = "https://download-ib01.fedoraproject.org/pub/fedora/linux/releases/31/Server/x86_64/iso/Fedora-Server-dvd-x86_64-31-1.9.iso"
|
||||
headless = "true"
|
||||
http_directory = "http"
|
||||
http_port_max = "10089"
|
||||
http_port_min = "10082"
|
||||
output_directory = "output"
|
||||
shutdown_timeout = "30m"
|
||||
shutdown_command = "echo 'vagrant'|sudo -S shutdown -P now"
|
||||
ssh_username = "vagrant"
|
||||
ssh_password = "vagrant"
|
||||
vm_name = "disk.raw"
|
||||
qemu_binary = "/usr/bin/kvm"
|
||||
qemuargs = [
|
||||
["-m", "1024"],
|
||||
["-cpu", "host"],
|
||||
["-chardev", "tty,id=pts,path=${var.serial}"],
|
||||
["-device", "isa-serial,chardev=pts"],
|
||||
["-device", "virtio-net,netdev=user.0"]
|
||||
]
|
||||
}
|
||||
|
||||
build {
|
||||
sources = ["source.qemu.example"]
|
||||
|
||||
post-processors {
|
||||
post-processor "compress" {
|
||||
output = "output/disk.raw.tar.gz"
|
||||
}
|
||||
post-processor "googlecompute-import" {
|
||||
account_file = var.account_file
|
||||
bucket = var.bucket
|
||||
project_id = var.project
|
||||
image_name = "fedora31-server-packertest"
|
||||
image_description = "Fedora 31 Server"
|
||||
image_family = "fedora31-server"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
description: |
|
||||
This section describes the configruation language used to create Packer
|
||||
This section describes the configuration language used to create Packer
|
||||
templates.
|
||||
page_title: Templates
|
||||
---
|
||||
|
|
@ -9,7 +9,7 @@ page_title: Templates
|
|||
|
||||
Packer's behavior is determined by the Packer template, which consists of a
|
||||
series of declarations and commands for Packer to follow. This template tells
|
||||
Packer what plugins (builders, provisioners, post-proecssors) to use, how to
|
||||
Packer what plugins (builders, provisioners, post-processors) to use, how to
|
||||
configure each of those plugins, and what order to run them in.
|
||||
|
||||
The template contains flexible variable injection tools, as well as built-in
|
||||
|
|
@ -24,5 +24,8 @@ new features in the Packer core will only be implemented for the newer HCL
|
|||
format. Please use the side bar to find documentation for the different
|
||||
template formats.
|
||||
|
||||
From version **1.7.0**, HCL2 becomes officially the preferred way to write Packer
|
||||
configuration(s).
|
||||
|
||||
If you need help upgrading a JSON template to an HCL template, check
|
||||
our upgrade guide [here](/guides/hcl/from-json-v1).
|
||||
|
|
|
|||
|
|
@ -38,14 +38,17 @@ for quick referencing.
|
|||
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 images. Example builders include
|
||||
VirtualBox, VMware, and Amazon EC2. Builders can be created and added to
|
||||
Packer in the form of plugins.
|
||||
VirtualBox, VMware, and Amazon EC2.
|
||||
|
||||
- `Commands` are sub-commands for the `packer` program that perform some 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
|
||||
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
|
||||
builder or another post-processor and process that to create a new
|
||||
artifact. Examples of post-processors are compress to compress artifacts,
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ and the Packer plugin SDK. Prior to version 1.7.0, the Packer core repository (h
|
|||
|
||||
The goal of the SDK is to clearly separate the Packer core from the Packer plugins; as a plugin maintainer, you should only have to import the SDK and not the core. The SDK will allow us to use semantic versioning to express the changes to the API that our maintainers are expected to use, and will help us keep a clearer promise to you about the location and functionality of our helper tools.
|
||||
|
||||
### How to update plugins to use the packer-plugin-SDK
|
||||
### How to update plugins to use the Packer plugin SDK
|
||||
|
||||
We have created a [packer-sdk-migrator](https://github.com/hashicorp/packer-sdk-migrator) cli tool to help you migrate your plugin to use the new import paths. To use it, follow the installation instructions for the migration tool, then call `packer-sdk-migrator migrate` from the root of your plugin directory. More details can be found in the migrator's [README](https://github.com/hashicorp/packer-sdk-migrator/blob/main/README.md).
|
||||
|
||||
|
|
@ -28,7 +28,7 @@ There are two main reasons we wrote the new server type.
|
|||
|
||||
First, it enables multiple related components, for example a builder and a post-processor that share a hypervisor or cloud, to live together in the same plugin. This helps maintainers who are experts in a specific technology to focus on that technology without having to maintain several repositories that submodule the same common code. You can think of a multi-component plugin as being in some ways analogous to Terraform providers, in the sense that both frequently bundle common resources or components by hypervisor or cloud.
|
||||
|
||||
Second, the new server provides the Packer core with structured metadata that allows the new `packer init` feature to work. This data includes semantic versioning that we need to implement the new `required_plugins` block, which allows us to ensure that users are using the correct _version_ of their plugin for a given Packer template. If you don't upgrade, your users cannot take advantage of the `packer init` tooling.
|
||||
Second, the new server provides the Packer core with structured metadata that allows the new `packer init` feature to work. This data includes semantic versioning that we need to implement the new [`required_plugins`](/docs/templates/hcl_templates/blocks/packer#specifying-plugin-requirements) block, which allows us to ensure that users are using the correct _version_ of their plugin for a given Packer template. If you don't upgrade, your users cannot take advantage of the `packer init` tooling.
|
||||
|
||||
### How to upgrade the plugin
|
||||
|
||||
|
|
|
|||
|
|
@ -68,9 +68,9 @@ Check the table below to better understand whether your plugin is compatible wit
|
|||
installation, or with both for the the Packer version you are using.
|
||||
|
||||
| Packer Core Version | Single Component Plugin - API v4 | Single Component Plugin - API v5.0 | Multi Component Plugin - API v5.0 |
|
||||
| ------------------- | ---------------------------------------------- | ---------------------------------------------- | ------------------------------------------------------ |
|
||||
| v1.5.0 to v1.6.6 | Plugin must be manually installed | Plugin cannot be used with this Packer version | Plugin cannot be used with this Packer version |
|
||||
| v1.7.0 | Plugin cannot be used with this Packer version | Plugin must be manually installed | Plugin can be installed manually or with `packer init` |
|
||||
| ------------------- | ------------------------------------------------- | ------------------------------------------------- | -------------------------------------------------------- |
|
||||
| v1.5.0 to v1.6.6 | ✋ Plugin must be manually installed | ⛔ Plugin cannot be used with this Packer version | ⛔ Plugin cannot be used with this Packer version |
|
||||
| v1.7.0 | ⛔ Plugin cannot be used with this Packer version | ✋ Plugin must be manually installed | 📦 Plugin can be installed manually or with `packer init` |
|
||||
|
||||
### How to upgrade your template
|
||||
|
||||
|
|
|
|||
|
|
@ -8,8 +8,6 @@ description: |-
|
|||
|
||||
# Transforming Packer v1 config files to HCL2 for Packer v1.5
|
||||
|
||||
-> **Note:** Starting from version **1.5.0** Packer can read HCL2 files.
|
||||
|
||||
@include 'guides/hcl2-beta-note.mdx'
|
||||
|
||||
As of v1.6.4, Packer provides a tool to help you convert legacy JSON files to
|
||||
|
|
@ -65,27 +63,30 @@ The following file :
|
|||
Becomes:
|
||||
|
||||
```hcl
|
||||
# the source block is what was defined in the builders section and represents a
|
||||
# reusable way to start a machine. You build your images from that source. All
|
||||
# sources have a 1:1 correspondance to what currently is a builder. The
|
||||
# argument name (ie: ami_name) must be unquoted and can be set using the equal
|
||||
# sign operator (=).
|
||||
source "amazon-ebs" "example" {
|
||||
ami_name = "packer-test"
|
||||
region = "us-east-1"
|
||||
instance_type = "t2.micro"
|
||||
|
||||
source_ami_filter {
|
||||
# The data block defines a data source that is used to fetch data from outside Packer.
|
||||
# The amazon-ami data source was generated from the source_ami_filter present in
|
||||
# the amazon builder from the JSON template.
|
||||
data "amazon-ami" "autogenerated_1" {
|
||||
filters = {
|
||||
virtualization-type = "hvm"
|
||||
name = "ubuntu/images/*ubuntu-xenial-16.04-amd64-server-*"
|
||||
root-device-type = "ebs"
|
||||
virtualization-type = "hvm"
|
||||
}
|
||||
owners = ["amazon"]
|
||||
most_recent = true
|
||||
owners = ["amazon"]
|
||||
region = "us-east-1"
|
||||
}
|
||||
|
||||
communicator = "ssh"
|
||||
# The source block is what was defined in the builders section and represents a
|
||||
# reusable way to start a machine. You build your images from that source. All
|
||||
# sources have a 1:1 correspondence to what currently is a builder. The
|
||||
# argument name (ie: ami_name) must be unquoted and can be set using the equal
|
||||
# sign operator (=).
|
||||
source "amazon-ebs" "autogenerated_1" {
|
||||
ami_name = "packer-test"
|
||||
instance_type = "t2.micro"
|
||||
region = "us-east-1"
|
||||
source_ami = "${data.amazon-ami.autogenerated_1.id}"
|
||||
ssh_username = "ubuntu"
|
||||
}
|
||||
|
||||
|
|
@ -93,7 +94,7 @@ source "amazon-ebs" "example" {
|
|||
build {
|
||||
sources = [
|
||||
# there can be multiple sources per build
|
||||
"source.amazon-ebs.example"
|
||||
"source.amazon-ebs.autogenerated_1"
|
||||
]
|
||||
|
||||
# All provisioners and post-processors have a 1:1 correspondence to their
|
||||
|
|
@ -105,7 +106,6 @@ build {
|
|||
|
||||
# post-processors work too, example: `post-processor "shell-local" {}`.
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
### 1:1 correspondence of components ... except :
|
||||
|
|
@ -183,12 +183,10 @@ There is soon going to be a PR to drop the `s` at the end of these fields.
|
|||
|
||||
### Deprecation
|
||||
|
||||
As we become more confident in the new templates, we may begin to add new
|
||||
features that are HCL2-only; one of our major motivations to moving to the new
|
||||
template format is that HCL2 provides us with the flexibility to implement some
|
||||
As we become more confident in the new templates, we may add more and more features that are HCL2-only.
|
||||
As of **1.7.0**, the new Data Source component type is the first HCL2-only feature.
|
||||
One of our major motivations to moving to the new template format is that HCL2 provides us with the flexibility to implement some
|
||||
features which would be very difficult to add to the legacy JSON templates.
|
||||
|
||||
However, the Packer team will continue to support the main functionality of the
|
||||
current "legacy JSON" packer templates alongside the new HCL2 templates until
|
||||
we and the community love the new templates. Only then the v1 format will be
|
||||
deprecated. We do not anticipate this happening until late 2021 at the earliest.
|
||||
current "legacy JSON" Packer templates alongside the new preferred HCL2 templates.
|
||||
|
|
|
|||
|
|
@ -5,8 +5,6 @@ sidebar_title: HCL guides
|
|||
|
||||
# Introduction to Packer HCL2
|
||||
|
||||
-> **Note:** Starting from version **1.5.0** Packer can read HCL2 files.
|
||||
|
||||
@include 'guides/hcl2-beta-note.mdx'
|
||||
|
||||
It is not necessary to know all of the details of the HCL syntax in order to
|
||||
|
|
|
|||
|
|
@ -8,7 +8,13 @@ description: |-
|
|||
|
||||
# How to use jq to strip unsupported comments from a Packer template
|
||||
|
||||
One of the biggest complaints we get about packer is that json doesn't use comments. We're in the process of moving to HCL2, the same config language used by Terraform, which does allow comments. But in the meantime, you can add detailed comments beyond the root-level underscore-prefixed field supported by Packer, and remove them using jq.
|
||||
|
||||
-> **Note:** Packer supports HCL2 from version 1.6.0, the Hashicorp Configuration
|
||||
Language allows to comment directly in template files. Consider upgrading your
|
||||
JSON template to HCL2 using the `packer hcl2_upgrade` command.
|
||||
|
||||
One of the biggest complaints we get about Packer is that JSON doesn't use comments.
|
||||
For Packer JSON templates, you can add detailed comments beyond the root-level underscore-prefixed field supported by Packer, and remove them using jq.
|
||||
|
||||
Let's say we have a file named `commented_template.json`
|
||||
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
~> Support for HCL2 is currently in Beta, which means the feature you are looking for may still need some polishing. If you find problems, please check the [Packer Issue Tracker](https://github.com/hashicorp/packer/issues/9176) for a list of supported features and open issues. For any strange behavior not already captured please create a new issue so that we can fix it!
|
||||
-> **Note:** Packer version **1.5.0** introduced support for HCL2 templates as a beta feature. As of version **1.7.0**, HCL2 support is no longer in beta and is the preferred way to write Packer configuration(s).
|
||||
|
|
|
|||
|
|
@ -15,17 +15,6 @@ export default [
|
|||
{
|
||||
category: 'templates',
|
||||
content: [
|
||||
{
|
||||
category: "legacy_json_templates",
|
||||
content: [
|
||||
'builders',
|
||||
'communicator',
|
||||
'engine',
|
||||
'post-processors',
|
||||
'provisioners',
|
||||
'user-variables',
|
||||
]
|
||||
},
|
||||
{
|
||||
category: 'hcl_templates',
|
||||
content: [
|
||||
|
|
@ -190,6 +179,17 @@ export default [
|
|||
'syntax-json',
|
||||
],
|
||||
},
|
||||
{
|
||||
category: "legacy_json_templates",
|
||||
content: [
|
||||
'builders',
|
||||
'communicator',
|
||||
'engine',
|
||||
'post-processors',
|
||||
'provisioners',
|
||||
'user-variables',
|
||||
]
|
||||
},
|
||||
],
|
||||
},
|
||||
'----------',
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ export default function Homepage() {
|
|||
<span></span>
|
||||
<span></span>
|
||||
</div>
|
||||
$ packer build template.json
|
||||
$ packer build template.pkr.hcl
|
||||
<span className="green">
|
||||
==> virtualbox: virtualbox output will be in this color.
|
||||
</span>
|
||||
|
|
|
|||
Loading…
Reference in New Issue