All Projects → hashicorp → Hcl

hashicorp / Hcl

Licence: mpl-2.0
HCL is the HashiCorp configuration language.

Programming Languages

go
31211 projects - #10 most used programming language
Ragel
52 projects
ruby
36898 projects - #4 most used programming language
perl
6916 projects
python
139335 projects - #7 most used programming language
HCL
1544 projects

Projects that are alternatives of or similar to Hcl

rust-hcl
A Rust library for working with the HashiCorp Configuration Language (HCL).
Stars: ✭ 14 (-99.63%)
Mutual labels:  hcl, hashicorp, configuration-language
Terraform Best Practices
Terraform Best Practices for AWS users
Stars: ✭ 931 (-75.17%)
Mutual labels:  hashicorp, hcl
K2tf
Kubernetes YAML to Terraform HCL converter
Stars: ✭ 477 (-87.28%)
Mutual labels:  hashicorp, hcl
Nomadfiles
A collection of Nomad job files for deploying applications to a cluster
Stars: ✭ 89 (-97.63%)
Mutual labels:  hashicorp, hcl
Resticprofile
Configuration profiles for restic backup
Stars: ✭ 48 (-98.72%)
Mutual labels:  hcl, json
Config
📝 Go config manage(load,get,set). support JSON, YAML, TOML, INI, HCL, ENV and Flags. Multi file load, data override merge, parse ENV var. Go应用配置加载管理,支持多种格式,多文件加载,远程文件加载,支持数据合并,解析环境变量名
Stars: ✭ 225 (-94%)
Mutual labels:  hcl, json
Atlantis On Gke
A set of @HashiCorp Terraform configurations for running Atlantis on @GoogleCloud GKE
Stars: ✭ 44 (-98.83%)
Mutual labels:  hashicorp, hcl
Config Lint
Command line tool to validate configuration files
Stars: ✭ 118 (-96.85%)
Mutual labels:  hcl, json
stein
A linter for config files with a customizable rule set
Stars: ✭ 92 (-97.55%)
Mutual labels:  hcl, hashicorp
terraform-github-actions-demo
HashiCorp Terraform Github Actions Demo for Github Satellite 2020.
Stars: ✭ 40 (-98.93%)
Mutual labels:  hcl, hashicorp
Hcloud Okd4
Deploy OKD4 (OpenShift) on Hetzner Cloud
Stars: ✭ 29 (-99.23%)
Mutual labels:  hashicorp, hcl
Jk
Configuration as Code with ECMAScript
Stars: ✭ 322 (-91.41%)
Mutual labels:  hcl, json
Vaultron
🤖 Vault clusters Terraformed onto Docker for great fun and learning!
Stars: ✭ 96 (-97.44%)
Mutual labels:  hashicorp, hcl
vim-hcl
Syntax highlighting for HashiCorp Configuration Language (HCL)
Stars: ✭ 83 (-97.79%)
Mutual labels:  hcl, hashicorp
vim-hclfmt
Vim plugin for hclfmt
Stars: ✭ 68 (-98.19%)
Mutual labels:  hcl, hashicorp
Kubernetes Digitalocean Terraform
📋 🌊 🌎 Setup a simple Kubernetes cluster in Digital Ocean using Terraform
Stars: ✭ 324 (-91.36%)
Mutual labels:  hcl
Underscore Java
java port of Underscore.js
Stars: ✭ 327 (-91.28%)
Mutual labels:  json
C Ray
C-Ray is a small, simple path tracer written in C
Stars: ✭ 323 (-91.38%)
Mutual labels:  json
Cryptr
Cryptr: a GUI for Hashicorp's Vault
Stars: ✭ 324 (-91.36%)
Mutual labels:  hashicorp
Terraform Aws Consul
A Terraform Module for how to run Consul on AWS using Terraform and Packer
Stars: ✭ 331 (-91.17%)
Mutual labels:  hcl

HCL

HCL is a toolkit for creating structured configuration languages that are both human- and machine-friendly, for use with command-line tools. Although intended to be generally useful, it is primarily targeted towards devops tools, servers, etc.

NOTE: This is major version 2 of HCL, whose Go API is incompatible with major version 1. Both versions are available for selection in Go Modules projects. HCL 2 cannot be imported from Go projects that are not using Go Modules. For more information, see our version selection guide.

HCL has both a native syntax, intended to be pleasant to read and write for humans, and a JSON-based variant that is easier for machines to generate and parse.

The HCL native syntax is inspired by libucl, nginx configuration, and others.

It includes an expression syntax that allows basic inline computation and, with support from the calling application, use of variables and functions for more dynamic configuration languages.

HCL provides a set of constructs that can be used by a calling application to construct a configuration language. The application defines which attribute names and nested block types are expected, and HCL parses the configuration file, verifies that it conforms to the expected structure, and returns high-level objects that the application can use for further processing.

package main

import (
	"log"

	"github.com/hashicorp/hcl/v2/hclsimple"
)

type Config struct {
	IOMode  string        `hcl:"io_mode"`
	Service ServiceConfig `hcl:"service,block"`
}

type ServiceConfig struct {
	Protocol   string          `hcl:"protocol,label"`
	Type       string          `hcl:"type,label"`
	ListenAddr string          `hcl:"listen_addr"`
	Processes  []ProcessConfig `hcl:"process,block"`
}

type ProcessConfig struct {
	Type    string   `hcl:"type,label"`
	Command []string `hcl:"command"`
}

func main() {
	var config Config
	err := hclsimple.DecodeFile("config.hcl", nil, &config)
	if err != nil {
		log.Fatalf("Failed to load configuration: %s", err)
	}
	log.Printf("Configuration is %#v", config)
}

A lower-level API is available for applications that need more control over the parsing, decoding, and evaluation of configuration. For more information, see the package documentation.

Why?

Newcomers to HCL often ask: why not JSON, YAML, etc?

Whereas JSON and YAML are formats for serializing data structures, HCL is a syntax and API specifically designed for building structured configuration formats.

HCL attempts to strike a compromise between generic serialization formats such as JSON and configuration formats built around full programming languages such as Ruby. HCL syntax is designed to be easily read and written by humans, and allows declarative logic to permit its use in more complex applications.

HCL is intended as a base syntax for configuration formats built around key-value pairs and hierarchical blocks whose structure is well-defined by the calling application, and this definition of the configuration structure allows for better error messages and more convenient definition within the calling application.

It can't be denied that JSON is very convenient as a lingua franca for interoperability between different pieces of software. Because of this, HCL defines a common configuration model that can be parsed from either its native syntax or from a well-defined equivalent JSON structure. This allows configuration to be provided as a mixture of human-authored configuration files in the native syntax and machine-generated files in JSON.

Information Model and Syntax

HCL is built around two primary concepts: attributes and blocks. In native syntax, a configuration file for a hypothetical application might look something like this:

io_mode = "async"

service "http" "web_proxy" {
  listen_addr = "127.0.0.1:8080"
  
  process "main" {
    command = ["/usr/local/bin/awesome-app", "server"]
  }

  process "mgmt" {
    command = ["/usr/local/bin/awesome-app", "mgmt"]
  }
}

The JSON equivalent of this configuration is the following:

{
  "io_mode": "async",
  "service": {
    "http": {
      "web_proxy": {
        "listen_addr": "127.0.0.1:8080",
        "process": {
          "main": {
            "command": ["/usr/local/bin/awesome-app", "server"]
          },
          "mgmt": {
            "command": ["/usr/local/bin/awesome-app", "mgmt"]
          },
        }
      }
    }
  }
}

Regardless of which syntax is used, the API within the calling application is the same. It can either work directly with the low-level attributes and blocks, for more advanced use-cases, or it can use one of the decoder packages to declaratively extract into either Go structs or dynamic value structures.

Attribute values can be expressions as well as just literal values:

# Arithmetic with literals and application-provided variables
sum = 1 + addend

# String interpolation and templates
message = "Hello, ${name}!"

# Application-provided functions
shouty_message = upper(message)

Although JSON syntax doesn't permit direct use of expressions, the interpolation syntax allows use of arbitrary expressions within JSON strings:

{
  "sum": "${1 + addend}",
  "message": "Hello, ${name}!",
  "shouty_message": "${upper(message)}"
}

For more information, see the detailed specifications:

Changes in 2.0

Version 2.0 of HCL combines the features of HCL 1.0 with those of the interpolation language HIL to produce a single configuration language that supports arbitrary expressions.

This new version has a completely new parser and Go API, with no direct migration path. Although the syntax is similar, the implementation takes some very different approaches to improve on some "rough edges" that existed with the original implementation and to allow for more robust error handling.

It's possible to import both HCL 1 and HCL 2 into the same program using Go's semantic import versioning mechanism:

import (
    hcl1 "github.com/hashicorp/hcl"
    hcl2 "github.com/hashicorp/hcl/v2"
)

Acknowledgements

HCL was heavily inspired by libucl, by Vsevolod Stakhov.

HCL and HIL originate in HashiCorp Terraform, with the original parsers for each written by Mitchell Hashimoto.

The original HCL parser was ported to pure Go (from yacc) by Fatih Arslan. The structure-related portions of the new native syntax parser build on that work.

The original HIL parser was ported to pure Go (from yacc) by Martin Atkins. The expression-related portions of the new native syntax parser build on that work.

HCL 2, which merged the original HCL and HIL languages into this single new language, builds on design and prototyping work by Martin Atkins in zcl.

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].