update hcl guides
This commit is contained in:
sylviamoss
parent
e0557f84e9
commit
9718af4982
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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,35 +63,38 @@ The following file :
|
|||
Becomes:
|
||||
|
||||
```hcl
|
||||
# the source block is what was defined in the builders section and represents a
|
||||
# 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 = {
|
||||
name = "ubuntu/images/*ubuntu-xenial-16.04-amd64-server-*"
|
||||
root-device-type = "ebs"
|
||||
virtualization-type = "hvm"
|
||||
}
|
||||
most_recent = true
|
||||
owners = ["amazon"]
|
||||
region = "us-east-1"
|
||||
}
|
||||
|
||||
# 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
|
||||
# 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" "example" {
|
||||
ami_name = "packer-test"
|
||||
region = "us-east-1"
|
||||
instance_type = "t2.micro"
|
||||
|
||||
source_ami_filter {
|
||||
filters = {
|
||||
virtualization-type = "hvm"
|
||||
name = "ubuntu/images/*ubuntu-xenial-16.04-amd64-server-*"
|
||||
root-device-type = "ebs"
|
||||
}
|
||||
owners = ["amazon"]
|
||||
most_recent = true
|
||||
}
|
||||
|
||||
communicator = "ssh"
|
||||
ssh_username = "ubuntu"
|
||||
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"
|
||||
}
|
||||
|
||||
# A build starts sources and runs provisioning steps on those sources.
|
||||
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
|
||||
|
|
|
|||
|
|
@ -1 +1,3 @@
|
|||
~> 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:** Starting from version **1.5.0** HCL2 templates were first introduced as a beta feature into Packer. As of **1.7.0**,
|
||||
HCL2 support is no longer in beta, and is the preferred way to write Packer
|
||||
configuration.
|
||||
|
|
|
|||
Loading…
Reference in New Issue