HCL: A human-friendly language for developers and operators

Slide 1

Slide 1 text

HCL (HashiCorp Configuration Language) A Human Friendly Language for Developers and Operators Anubhav Mishra Team Lead, Developer Advocacy, OOCTO at HashiCorp

Slide 2

Slide 2 text

$ whoami @build1point0 Anubhav Mishra Team Lead, Developer Advocacy, OOCTO Atlan&s

Slide 3

Slide 3 text

Gopher Artwork by Ashley McNamara

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

HCL (HashiCorp Configuration Language) @build1point0  ▪ Created in July 31st, 2014 by HashiCorp ▪ Used by HashiCorp Projects: Terraform, Consul, Nomad, Vault,   consul-template, envconsul ▪ Used by Github Actions ~45 million downloads/year

Slide 6

Slide 6 text

@build1point0 

Slide 7

Slide 7 text

⁄ History

Slide 8

Slide 8 text

@build1point0  HashiCorp in 2014 Ruby JSON JSON ?

Slide 9

Slide 9 text

@build1point0  HashiCorp in 2014

Slide 10

Slide 10 text

@build1point0  UCL (Universal Configuration Language) UCL is heavily infused by NGINX configuration as the example of a convenient configuration system. However, UCL is fully compatible with JSON format and is able to parse JSON files. CODE EDITOR param = value; section { param = value; param1 = value1; flag = true; number = 10k; time = 0.2s; string = "something"; subsection { host = { host = "hostname"; port = 900; } …

Slide 11

Slide 11 text

@build1point0  UCL (Universal Configuration Language) UCL is heavily infused by NGINX configuration as the example of a convenient configuration system. However, UCL is fully compatible with JSON format and is able to parse JSON files. CODE EDITOR { "param": "value", "param1": "value1", "flag": true, "subsection": { "host": [ { "host": "hostname", "port": 900 }, { "host": "hostname", "port": 901 }

Slide 12

Slide 12 text

@build1point0  HCL is created in 2014

Slide 13

Slide 13 text

⁄ HCL v1

Slide 14

Slide 14 text

HCL (HashiCorp Configuration Language) @build1point0  ▪ Configuration language ▪ Structured language built for both humans and machines ▪ Built for command line tools ▪ Targeting DevOps tools, servers, etc. (Terraform)

Slide 15

Slide 15 text

HCL Version 1 CODE EDITOR resource "aws_instance" "example" { ami = "ami-2757f631" instance_type = "t2.micro" } @build1point0 

Slide 16

Slide 16 text

HCL Version 1 CODE EDITOR job "example" { datacenters = ["dc1"] type = "service" group "cache" { count = 1 task "redis" { driver = "docker" config { image = "redis:3.2" port_map { db = 6379 } } } } @build1point0 

Slide 17

Slide 17 text

HCL Version 1 CODE EDITOR resource "aws_instance" "example" { ami = “${var.ami}” instance_type = "t2.micro" } resource "aws_instance" “example2” { ami = “${var.ami}” instance_type = "t2.micro" } @build1point0 

Slide 18

Slide 18 text

HIL (HashiCorp Interpolation Language) @build1point0  ▪ HIL (HashiCorp Interpolation Language) is a lightweight embedded language used primarily for configuration interpolation. ▪ HIL is built to interpolate any string, but is in use by HashiCorp primarily with HCL. ▪ HIL enables the configuration to be able to reference values from elsewhere. Example: foo = "hi ${var.world}"

Slide 19

Slide 19 text

HCL Version 1 CODE EDITOR resource "aws_instance" "example" { ami = "ami-2757f631" instance_type = "t2.micro" } data "aws_route53_zone" "default" { name = "hashicorp.live." } resource "aws_route53_record" "web_server" { zone_id = "${data.aws_route53_zone.default.zone_id}" name = "example.hashicorp.live" type = "A" ttl = "5" records = ["${aws_instance.example.public_ip}"] } @build1point0 

Slide 20

Slide 20 text

@build1point0  HCL JSON % backwards compatible

Slide 21

Slide 21 text

HCL <> JSON CODE EDITOR variable "ami" { description = "the AMI to use" } { "variable": { "ami": { "description": "the AMI to use" } } } @build1point0 

Slide 22

Slide 22 text

@build1point0  Why no JSON?

Slide 23

Slide 23 text

Why HCL? @build1point0  ▪ Prior to HCL, HashiCorp tools did used languages like Ruby and data structure languages such as JSON ▪ Some people wanted human-friendly language and other wanted machine-friendly languages ▪ JSON fits the bill here, but is fairly verbose and most importantly doesn't support comments. ▪ HashiCorp created HCL and made is JSON-compatible. ▪ HCL for HashiCorp tools and JSON is the interoperability layer.

Slide 24

Slide 24 text

JSON as the Interoperability Layer @build1point0  ▪ Languages like Python, Ruby, etc can manipulate JSON easily ▪ Machines can generate JSON easily

Slide 25

Slide 25 text

@build1point0  I love my YAMLS!

Slide 26

Slide 26 text

Why HCL? @build1point0  ▪ YAML was hard for beginners ▪ Hard to determine the actual structures, lots of guess work involved.

Slide 27

Slide 27 text

Our Findings @build1point0  ▪ The success of a new language depends on the tooling around it. – With HCL, the adoption was OK, thanks to Terraform. ▪ There is no perfect language – Programmers want both human friendly and machine readable code. ▪ HCL is a common configuration language.

Slide 28

Slide 28 text

Demo HCL v1

Slide 29

Slide 29 text

This wasn’t enough @build1point0 

Slide 30

Slide 30 text

HCL v1 Challenges @build1point0  ▪ Unhelpful error messages. ▪ Use of string interpolation for non-string results (HCL + HIL) ▪ Lack of rich type system. Eg: Use of strings vs maps, lists, etc. ▪ The ability to define complex logic. Eg: web applications, networks, etc. – Need for iteration constructs like for loops. – Need for templates.

Slide 31

Slide 31 text

⁄ HCL2

Slide 32

Slide 32 text

HCL2 Error Messages TERMINAL # HCL v1 __builtin_StringToInt: strconv.ParseInt: parsing "foo": invalid syntax in: ${1 + var.example} # HCL2 Error: Unsupported block type on example.tf line 4, in resource "aws_instance" "example": 2: provisionr "local-exec" { Blocks of type "provisionr" are not expected here. Did you mean "provisioner"? @build1point0 

Slide 33

Slide 33 text

HCL2 Expressions Outside of Interpolation (HCL + HIL) CODE EDITOR # HCL v1 variable "ami" { } variable "instance_type" { } resource "aws_instance" "example" { ami = "${var.ami}" instance_type = "${var.instance_type}" ..... } # HCL2 variable "ami" { } variable "instance_type" { } resource "aws_instance" "example" { ami = var.ami instance_type = var.instance_type ..... } @build1point0 

Slide 34

Slide 34 text

HCL2 Comprehensive List and Map Support CODE EDITOR # HCL v1 resource "aws_instance" "example" { ..... # Instead, it's necessary to use the list function to "trick" in HIL vpc_security_group_ids = "${var.security_group_id != "" ? list(var.security_group_id) : list()}" } # HCL2 resource "aws_instance" "example" { ..... vpc_security_group_ids = var.security_group_id != "" ? [var.security_group_id] : [] } @build1point0 

Slide 35

Slide 35 text

HCL2 Ability to Define Complex Logic CODE EDITOR # HCL2 resource "aws_instance" "example" { ….. tags = {for def in var.standard_tags: def.name => def.value} } output "instance_public_ips" { value = {for inst in aws_instance.example: inst.tags.name => inst.public_ip...} } @build1point0 

Slide 36

Slide 36 text

HCL2 Templates CODE EDITOR # HCL2 output "server_config" { value = <

Slide 37

Slide 37 text

Demo HCL2

Slide 38

Slide 38 text

@build1point0  Github Actions

Slide 39

Slide 39 text

Demo Github Actions

Slide 40

Slide 40 text

Future Work @build1point0  ▪ Continue to improve HCL (HCL2) ▪ Publish HCL specification on a website ▪ VS Code language server and LSP (Language Server Protocol)

Slide 41

Slide 41 text

Links @build1point0  ▪ HCL: https://github.com/hashicorp/hcl ▪ HIL: https://github.com/hashicorp/hil ▪ HCL2: https://github.com/hashicorp/hcl2 ▪ gohcl: https://godoc.org/github.com/hashicorp/hcl2/gohcl 

Slide 42

Slide 42 text

Thank You Questions? @build1point0 www.hashicorp.com