Chapter 11: Terraform Glossary

In this glossary, we are going to list all the acronyms and key terms used throughout this book. This will help to clarify all the technical terms. These terms should assist in helping you to get to grips with the different conversations currently taking place in the Terraform community:

  • API: An application programming interface. This is an interface that has been designed to manipulate some functionality of an application. Terraform uses cloud or on-premises API software to manage infrastructure. Terraform resources are responsible for mapping to each API call that is required to create, update, or delete the infrastructure.

    Terraform Cloud also has APIs that can be used to easily manage policies and workspaces.

  • Apply: This is one of the phases in the Terraform life cycle that helps Terraform to perform implementation by accepting planned changes, or to make real changes to the Terraform providers using their resource APIs.
  • Azure: This is a public cloud provided by Microsoft.
  • AzureRM: This is one of the Terraform providers specific to Azure.
  • AWS: This is a public cloud provided by Amazon.
  • Arguments: When we write a Terraform configuration file, arguments take the form <IDENTIFIER> = <EXPRESSION> and are defined by a block of resources and data sources. Generally, they hold the properties of the Terraform providers.
  • Attribute: An attribute is a property of an object that can be exported. For example, we can get an attribute value in a defined way: aws_instance.eg.id.
  • Backend: A backend is required to store the Terraform state files, so it could be remote or local. The choice of backend determines how the state is stored and where Terraform will execute.
  • Block: The HashiCorp configuration syntax used to create a container that holds all the defined objects like a resource. A block contains one or more labels and a body containing name and value pairs:

    <BLOCK TYPE> "<BLOCK LABEL>" "<BLOCK LABEL>" {

      # Block body

      <IDENTIFIER> = <EXPRESSION> # Argument

  • CI/CD: Continuous Integration/Continuous Delivery. CI/CD involves operating principles and practices that enable a reliable sequence in terms of the development and deployment of cloud resources, typically an application. This helps as regards complete automation. In our course, we used Azure DevOps Pipeline to explain CI/CD concepts using Infrastructure as Code using Terraform.
  • CLI: The command-line interface. We can run Terraform commands on any terminal, such as a Unix shell or the Windows CLI. The Terraform CLI is an open source binary. In other words, terraform.exe can be downloaded and placed in local system environment variables and Terraform commands can start to be used.
  • Clone: Cloning means copying files to the local system so that it will be easy for us to make changes and push them back to the repository. It is basically a git clone command that helps to perform cloning from the source control repository to the local system.
  • Configuration language: Terraform files used to have code written in declarative format describing the desired state of the infrastructure. It is mainly referred to as HashiCorp Configuration Language (HCL).
  • Data source: Like a Terraform resource code block, we have a data source that generally helps you to fetch information regarding the already existing infrastructure that has been deployed by some other means, for example, manually, or using any other Terraform configuration code. In places, you may also find it referred to as a data resource.
  • Fork: This is like a clone where one copy of the repository gets cloned into the VCS server. It might be the case that you are copying content and history from one repository to another. For example, suppose you need to work on the Microsoft repository. What you can do is that you can clone it to your local VCS so that it will be easy for you to work on it. You would be getting the full option of copying content to your local VCS with all its branches. The main goal of a fork is to copy a source repository to another repository.
  • Git: A distributed version control system that will hold all the change history that has been performed on any file or folder defined in the source code. This is beneficial when you are working with many developers, as they would easily be able to coordinate with one another.
  • HCL: HashiCorp Configuration Language. This is a structured configuration syntax that is used to write Terraform code. It uses specific block types, such as a resource, variable, provider, and built-in function. It is written as a named value pair.
  • IaC: Infrastructure as Code is a way of writing infrastructure in code format and keeping it in a file so that it will be easy to manage infrastructure, for example, Terraform configuration files.
  • Input variables: This is a method of declaring a variable in Terraform and taking a value from the user.
  • Locking: A Terraform state file is used to go into a locked state so that it can avoid another Terraform process, such as apply, when a Terraform operation is already running.
  • Log: This is a text-based output that gets printed to stderr following the execution of any Terraform operations, such as plan and apply.
  • Module: A Terraform module is more like a code function. You have input and a module can provide output, but all processes are internal to the module. It is like a self-defined container where it has all the Terraform configuration code that can be used to manage the infrastructure. Other Terraform configurations can call the module that tells Terraform to manage a resource that is defined in the module configuration code.
  • Output values: Suppose we want to see what Terraform operation had been performed, irrespective of whether a defined resource was created. We can see them during the runtime itself by defining them in the output file as an output value.
  • Plan: This is one of the Terraform workflow operations where Terraform compares the infrastructure's real state to the configuration, and is shown to the user in a readable format, about the changes it is going to perform to match the desired state.
  • Policy: This is basically a rule that is enforced by Terraform to validate the plan, irrespective of whether the resources comply with company policy.
  • Policy set: A list of policies defined to be enforced globally or in relation to a specific workspace.
  • Provider: This is a plugin for Terraform that holds collections of the available resources. There are many Terraform providers, including AWS, Azure, and GCP. Terraform has already published a list of available providers that can be found at https://www.terraform.io/docs/providers/index.html.
  • Remote backend: Terraform state files can be stored in defined storage, such as S3 and Google Cloud Storage. If we want to store the state file securely, then it's desirable to configure the remote backend.
  • Repository: This is a place where code files can be kept and managed. Primarily, this will be any version control system that can hold the entire history of changes to the file. A repository is mainly a Git repository that will retain all Terraform configuration files except secrets.
  • Resource: In the Terraform configuration file, we defined a resource code block that describes one or more infrastructure objects. A resource block instructs Terraform to manage the defined resource. Terraform uses cloud provider APIs to create, edit, and destroy resources.
  • Sentinel: Sentinel is a feature available in all paid HashiCorp products, including Terraform Cloud, Terraform Enterprise, HashiCorp Enterprise Vault, and HashiCorp Enterprise Consul, where we can define policy as code.
  • State: Terraform generates a state file in a JSON format where it holds all the information about the defined infrastructure and maps those resources to the real world. Without state, Terraform can't know which resources got provisioned during the previous run. So, it is very important to know what action has been performed during the previous run if you are working with many people. That is why Terraform generates state files and records all the defined infrastructure resources in the state file.
  • VCS: A version control system, such as Git. This is a software application that tracks changes to collections of files and helps you to monitor changes, undo changes, or combine them.
  • Workspace: In the Terraform CLI, a workspace is an isolated instance that can be used to deploy multiple environments using a single Terraform configuration file.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
35.172.193.238