Merge pull request #11017 from hashicorp/d-hcl2upgrade-tutorial
Add link to the new HCL2 upgrade command tutorial
This commit is contained in:
Wilken Rivera
parent
8b491ec8cf
commit
12db775411
|
|
@ -1,191 +0,0 @@
|
|||
---
|
||||
page_title: Transforming Packer v1 files for Packer v1.5.0
|
||||
description: |-
|
||||
Learn how to manually move from a Packer v1 working JSON build file to a
|
||||
working v1.5.0 HCL file.
|
||||
---
|
||||
|
||||
# Transforming Packer v1 config files to HCL2 for Packer v1.5
|
||||
|
||||
@include 'guides/hcl2-beta-note.mdx'
|
||||
|
||||
As of v1.6.4, Packer provides a tool to help you convert legacy JSON files to
|
||||
HCL2 files. To run it, you can use the `hcl2_upgrade` command.
|
||||
|
||||
for example,
|
||||
|
||||
```sh
|
||||
packer hcl2_upgrade mytemplate.json
|
||||
```
|
||||
|
||||
will convert your packer template to a new HCL2 file in your current working
|
||||
directory named mytemplate.json.pkr.hcl. It is not a perfect converter yet;
|
||||
please open an issue if you find a problem with the conversion. Packer will not
|
||||
destroy your legacy json template, so this is not a risky command to call.
|
||||
|
||||
Following is an explanation of how to manually upgrade a JSON template to an
|
||||
HCL2 template.
|
||||
|
||||
The following file :
|
||||
|
||||
```json
|
||||
{
|
||||
"builders": [
|
||||
{
|
||||
"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
|
||||
},
|
||||
|
||||
"ssh_username": "ubuntu",
|
||||
"type": "amazon-ebs"
|
||||
}
|
||||
],
|
||||
"provisioners": [
|
||||
{
|
||||
"type": "shell",
|
||||
"inline": ["sleep 5"]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Becomes:
|
||||
|
||||
```hcl
|
||||
# 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 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"
|
||||
}
|
||||
|
||||
# A build starts sources and runs provisioning steps on those sources.
|
||||
build {
|
||||
sources = [
|
||||
# there can be multiple sources per build
|
||||
"source.amazon-ebs.autogenerated_1"
|
||||
]
|
||||
|
||||
# All provisioners and post-processors have a 1:1 correspondence to their
|
||||
# current layout. The argument name (ie: inline) must to be unquoted
|
||||
# and can be set using the equal sign operator (=).
|
||||
provisioner "shell" {
|
||||
inline = ["sleep 5"]
|
||||
}
|
||||
|
||||
# post-processors work too, example: `post-processor "shell-local" {}`.
|
||||
}
|
||||
```
|
||||
|
||||
### 1:1 correspondence of components ... except :
|
||||
|
||||
All fields of builders, provisioners and post-processors have a 1:1
|
||||
correspondance except for the following:
|
||||
|
||||
- builders:
|
||||
|
||||
- aws ami_block_device_mappings
|
||||
- aws launch_block_device_mappings
|
||||
- aws run_volume_tags
|
||||
- alicloud image_disk_mappings
|
||||
- osc omi_block_device_mappings
|
||||
- osc launch_block_device_mappings
|
||||
- proxmox network_adapters
|
||||
- proxmox disks
|
||||
- tencentcloud data_disks
|
||||
- ucloud image_copy_to_mappings
|
||||
|
||||
- provisioner:
|
||||
|
||||
- converge module_dirs
|
||||
|
||||
- post-processor:
|
||||
- alicloud-import image_disk_mappings
|
||||
|
||||
One could think that these are defined as "arrays of blocks" - they are in fact
|
||||
repeatable blocks with the same identifier. For example:
|
||||
|
||||
```json
|
||||
"builders": [
|
||||
{
|
||||
"type": "amazon-ebs",
|
||||
"launch_block_device_mappings": [
|
||||
{
|
||||
"device_name": "/dev/xvda",
|
||||
"volume_size": "20",
|
||||
"volume_type": "gp2",
|
||||
"delete_on_termination": "true"
|
||||
},
|
||||
{
|
||||
"device_name": "/dev/xvdf",
|
||||
"volume_size": "500",
|
||||
"volume_type": "gp2",
|
||||
"delete_on_termination": "true",
|
||||
"encrypted": true
|
||||
}
|
||||
],
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
Becomes:
|
||||
|
||||
```hcl
|
||||
source "amazon-ebs" "example" {
|
||||
launch_block_device_mappings {
|
||||
device_name = "/dev/xvda"
|
||||
volume_size = 20
|
||||
volume_type = "gp2"
|
||||
delete_on_termination = true
|
||||
}
|
||||
launch_block_device_mappings {
|
||||
device_name = "/dev/xvdf"
|
||||
volume_size = 500
|
||||
volume_type = "gp2"
|
||||
delete_on_termination = true
|
||||
encrypted = true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
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 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 preferred HCL2 templates.
|
||||
|
|
@ -14,14 +14,14 @@
|
|||
"title": "Overview",
|
||||
"path": "hcl"
|
||||
},
|
||||
{
|
||||
"title": "From JSON v1",
|
||||
"path": "hcl/from-json-v1"
|
||||
},
|
||||
{
|
||||
"title": "Variables",
|
||||
"path": "hcl/variables"
|
||||
},
|
||||
{
|
||||
"title": "Upgrade Packer JSON Template to HCL2",
|
||||
"href": "https://learn.hashicorp.com/tutorials/packer/hcl2-upgrade"
|
||||
},
|
||||
{
|
||||
"title": "Making a plugin HCL2 enabled",
|
||||
"path": "hcl/component-object-spec"
|
||||
|
|
|
|||
|
|
@ -218,6 +218,11 @@ module.exports = [
|
|||
destination: '/docs/post-processors/docker/docker-:path*',
|
||||
permanent: true,
|
||||
},
|
||||
{
|
||||
source: '/guides/hcl/from-json-v1',
|
||||
destination: 'https://learn.hashicorp.com/tutorials/packer/hcl2-upgrade',
|
||||
permanent: true,
|
||||
},
|
||||
// disallow '.html' or '/index.html' in favor of cleaner, simpler paths
|
||||
{ source: '/:path*/index', destination: '/:path*', permanent: true },
|
||||
{ source: '/:path*.html', destination: '/:path*', permanent: true },
|
||||
|
|
|
|||
Loading…
Reference in New Issue