Lucas Bajolet c1c1577073 hcl2template: rework parsing logic
In previous versions of Packer, the parser would load a HCL file (in
either HCL or JSON format), and process it in phases.
This process meant that if the file was not valid in the first place,
we'd have some duplicate errors first.

Another thing is that sources and build blocks were not being parsed at
the beginning of the parsing phase at all, but were discovered later in
the process, when the data sources have been executed and variables have
been evaluated.

This commit changes the parsing to happen all at once, so we parse the
files with the parser, which will fail should one file be malformatted,
then we visit the body once using the top-level schema for a Packer
build template, handling misplaced blocks once in the process.

Then, since the builds and sources may contain some dynamic blocks that
need to be expanded once their context is ready (i.e. the
variables/datasources they depend on), we can expand the build block for
them, and populate their respective objects.

This last step should also be adapted for datasources later, as they may
need to support dynamic blocks, and be expanded lazily.
2023-10-03 14:47:24 -04:00
2021-10-11 10:19:49 +02:00
2023-08-10 15:53:29 -07:00
2021-04-16 10:31:09 -04:00
2021-04-21 10:52:55 +02:00
2023-10-03 10:32:42 -04:00
2023-08-18 15:38:13 -04:00
2022-02-25 15:56:20 -08:00
2023-10-03 10:32:42 -04:00
2023-09-26 12:16:40 -04:00
2023-09-26 12:16:40 -04:00
2023-08-10 15:53:29 -07:00
2023-08-10 15:53:29 -07:00
2023-08-04 13:30:41 -04:00
2023-08-10 15:53:29 -07:00

Packer

Build Status Discuss PkgGoDev GoReportCard

HashiCorp Packer logo

Packer is a tool for building 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 comes out of the box with support for many platforms, the full list of which can be found at https://www.packer.io/docs/builders.

Support for other platforms can be added via plugins.

The images that Packer creates can easily be turned into Vagrant boxes.

Quick Start

Note: There is a great introduction and getting started guide for those with a bit more patience. Otherwise, the quick start below will get you up and running quickly, at the sacrifice of not explaining some key points.

First, download a pre-built Packer binary for your operating system or compile Packer yourself.

After Packer is installed, create your first template, which tells Packer what platforms to build images for and how you want to build them. In our case, we'll create a simple AMI that has Redis pre-installed.

Save this file as quick-start.pkr.hcl. Export your AWS credentials as the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables.

variable "access_key" {
  type    = string
  default = "${env("AWS_ACCESS_KEY_ID")}"
}

variable "secret_key" {
  type      = string
  default   = "${env("AWS_SECRET_ACCESS_KEY")}"
  sensitive = true
}

locals { timestamp = regex_replace(timestamp(), "[- TZ:]", "") }

source "amazon-ebs" "quick-start" {
  access_key    = "${var.access_key}"
  ami_name      = "packer-example ${local.timestamp}"
  instance_type = "t2.micro"
  region        = "us-east-1"
  secret_key    = "${var.secret_key}"
  source_ami    = "ami-af22d9b9"
  ssh_username  = "ubuntu"
}

build {
  sources = ["source.amazon-ebs.quick-start"]
}

Next, tell Packer to build the image:

$ packer build quick-start.pkr.hcl
...

Packer will build an AMI according to the "quick-start" template. The AMI will be available in your AWS account. To delete the AMI, you must manually delete it using the AWS console. Packer builds your images, it does not manage their lifecycle. Where they go, how they're run, etc., is up to you.

Documentation

Comprehensive documentation is viewable on the Packer website at https://www.packer.io/docs.

Contributing to Packer

See CONTRIBUTING.md for best practices and instructions on setting up your development environment to work on Packer.

Unmaintained Plugins

As contributors' circumstances change, development on a community maintained plugin can slow. When this happens, HashiCorp may use GitHub's option to archive the plugins repository, to clearly signal the plugin's status to users.

What does unmaintained mean?

  1. The code repository and all commit history will still be available.
  2. Documentation will remain on the Packer website.
  3. Issues and pull requests are monitored as a best effort.
  4. No active development will be performed by HashiCorp.

If you are interested in maintaining an unmaintained or archived plugin, please reach out to us at [email protected].

S
Description
No description provided
Readme
163 MiB
Languages
Go 94.2%
HCL 4%
Shell 0.8%
Makefile 0.3%
MDX 0.3%
Other 0.4%