Even if TF_LOG_PATH is set, TF_LOG must be set in order for any logging to be enabled.
Terraform starts with a single workspace named "default". This workspace is special both because it is the default and also because it cannot ever be deleted.
Terraform Cloud manages infrastructure collections with workspaces instead of directories. A workspace contains everything Terraform needs to manage a given collection of infrastructure, and separate workspaces function like completely separate working directories.
In addition to the basic Terraform content, Terraform Cloud keeps some additional data(state versions, run history) for each workspace
valid connection values(WinRm n ssh) for remote exec provisioners
Terraform Cloud and Terraform CLI have features called workspaces, but they function differently. T.Cloud: workspaces are required.You cannot manage resources in Terraform Cloud without creating at least one workspace.
terraform business plan : free(oss): state management, remote operations , private module registry team governance: team management , sentinel, run tasks, custom concurrency + free business plan: audit logs, sso, self hosted agents, drift detection, additional concurrency, (private n/w connectivity, clustering functionality) + team governance
terraform core is written in go. any fixes to the core should be also done in same language
For local state, (workspaces)Terraform stores the workspace states in a directory called terraform.tfstate.d. This directory should be treated similarly to local-only terraform.tfstate; some teams commit these files to version control, although using a remote backend instead is recommended when there are multiple collaborators.
Sensitive output values are still recorded in the state, and so will be visible to anyone who is able to access the state data
Terraform Import will find the existing resource from ID and import it into your Terraform state at the given ADDRESS. Example Syntax: terraform import aws_instance.example i-abcd1234
Named Workspaces allow conveniently switching between multiple instances of a single configuration within its single backend.
workspaces are not only suitable tool for system decomposition, because each subsystem should have its own configuration and backend -> thus have distinct set of workspaces
Terraform enterprise pre install checklist -> Postgresql Terraform Enterprise uses the following types of data.

-PostgreSQL Database -> Stateful Terraform Enterprise application data. This includes workspace settings, organization settings, run information, and user information. -Object Storage -> Artifacts that Terraform Enterprise produces during operation. This includes state files, plan files, run logs, configuration versions, etc. Vault -> Encryption keys that encrypt and decrypt objects within object storage. Redis ->Application coordination and data caching. Configuration -> Configuration settings. This includes the hostname, object storage credentials, database credentials, concurrency settings, etc.
Terraform Cloud supports the following VCS providers:

GitHub.com,GitHub.com (OAuth),GitHub Enterprise GitLab.com,GitLab EE and CE Bitbucket Cloud,Bitbucket Server Azure DevOps Server,Azure DevOps Services
terraform backend and locking
- local -> has locking feature ->xxx.lock.hcl file created
- s3 -> state locking implemented using s3 and dynamodb
- artifactory -> does not support state locking
- azurerm -> supports state locking and consistency checking with Azure Blob Storage native capabilities(stores state as a blob)
- consul -> supports state locking
- cos-> supports state locking (tencent cloud object storage, bucket versioning should be enabled)
- etcd does not support state locking but etcdv3 supports state locking
- gcs -> supports state locking
- http -> optionally supports state locking. When locking support is enabled it will use LOCK and UNLOCK requests providing the lock info in the body.
- kubernetes - Note: This backend is limited by Kubernetes' maximum Secret size of 1MB. See Secret restrictions for details.Stores the state in a Kubernetes secret.This backend supports state locking, with locking done using a Lease resource.
- manta-> supports state locking
- oss-> supports state locking via tablestore (alibaba cloud)
- pg-> postgres supports statelocking
- swift -> supports statelocking
When workspaces are linked to a VCS repository, Terraform Cloud can automatically initiate Terraform runs when changes are committed to the specified branch.
Terraform Cloud makes code review easier by automatically predicting how pull requests will affect infrastructure.
Publishing new versions of a private Terraform module is as easy as pushing a tag to the module's repository.
To use configurations from VCS, Terraform Cloud needs to do several things:
1. Access a list of repositories, to let you search for repos when creating new workspaces.
2. Register webhooks with your VCS provider, to get notified of new commits to a chosen branch.
3. Download the contents of a repository at a specific commit in order to run Terraform with that code.
A dynamic block (acts much like a for expression) produces nested blocks instead of a complex typed value. It iterates over a given complex value, and generates a nested block for each element of that complex value.
A splat expression provides a more concise way to express a common operation that could otherwise be performed with a for expression. If var.list is a list of objects that all have an attribute id, then a list of the ids could be produced with the following for expression: [for o in var.list : o.id] This is equivalent to the following splat expression:var.list[*].id splat expressions are mostly used for lists, sets and tuples, while for maps-> use "for expression"
Terraform versions offer the ability to use a private module registry?(other than oss , everything else does)
In both Terraform OSS and Terraform Cloud/Enterprise, workspaces provide similar functionality of using a separate state file for each workspace. 25.Terraform OSS and Terraform Enterprise are versions of Terraform that can be installed locally on your own servers, therefore giving you the ability to manage both the Terraform binary and the underlying operating system where Terraform runs.

Although Terraform Cloud for Business does offer Cloud Agents that could be used to provision resources on your local infrastructure on-premises, it is a hosted solution and you would NOT have full control over the operating system that runs the Terraform platform. Terraform Cloud (free) does not meet either of these use cases since you can't deploy to on-premises nor can you manage the underlying operating system since it's a hosted service.
If you have migrated or configured your state to use Terraform Cloud using the backend configuration, you can continue using your local Terraform CLI to execute operations while using Terraform Cloud. You can even specify the workspace you want to execute the operation in.
To configure each provider, you need to define a provider block and provide the configuration within that block. You would need to do this for each provider that you need to configure. For example, if you needed to customize the aws, gcp, and vault provider, you'd need to create three separate provider blocks, one for each provider. Don't forget that configurations for a provider go inside of a provider block, but any provider constraints go inside of the terraform ( required_providers block).
Providers can be installed using multiple methods, including downloading from a Terraform public or private registry, the official HashiCorp releases page, a local plugins directory, or even from a plugin cache. Terraform cannot, however, install directly from the source code.
When you run Terraform commands with a local state file, Terraform stores the state as plain text, including variable values, even if you have flagged them as sensitive. Terraform needs to store these values in your state so that it can tell if you have changed them since the last time you applied your configuration
Terraform builds a resource graph to determine resource dependencies and creates or modifies non-dependent resources in parallel. This allows Terraform to provision resources efficiently.
sentinel is available terraform cloud team governance and management tier
Anyone can develop and distribute their own Terraform providers.
Some organizations develop their own providers to configure proprietary systems, and wish to use these providers from Terraform without publishing them on the public Terraform Registry.. One option for distributing such a provider is to run an in-house private registry, by implementing the provider registry protocol.
Running an additional service just to distribute a single provider internally may be undesirable, so terraform supports placing placing provider plugins directly in specific directories in the local filesystem, via filesystem mirrors. 35.Terraform relies on plugins called "providers" to interact with remote systems. Terraform configurations must declare which providers they require, so that Terraform can install and use them. When using a provider, it can be explicitly defined in a provider block or implied by the presence of a resource that uses the provider.
Terraform Block Syntax contains: configuring terraform cloud, backend, terraform version, required_providers, providers_meta , experiments(feature where community can try out opt-in experiments).
In terraform cloud, you cannot use cli integration and state backend in same configuration as they are mutually exclusive. configuration can only provide cloud block and cloud block cannot refer to local, input variables, data source attributes.
The terraform_remote_state data source uses the latest state snapshot from a specified state backend to retrieve the root module output values from some other Terraform configuration. It is always available through a built-in provider with the source address terraform.io/builtin/terraform.
Use tfe_outputs data source in the Terraform Cloud/Enterprise Provider to access remote state outputs in Terraform Cloud or Terraform Enterprise. The tfe_outputs data source is more secure because it does not require full access to workspace state to fetch outputs.
The depends_on meta-argument may not be used in override blocks, and will produce an error
At present the dependency lock file tracks only provider dependencies.
Terraform automatically creates or updates the dependency lock file each time you run the terraform init command.
By default, Terraform compares your state file to real infrastructure whenever you invoke terraform plan or terraform apply. The refresh updates your state file in-memory to reflect the actual configuration of your infrastructure. This ensures that Terraform determines the correct changes to make to your resources.
Terraform Cloud offers the best of both worlds, allowing you to run remote plans from your local command line.
Many of Terraform Cloud's features rely on remote execution and are not available when using local operations. This includes features like Sentinel policy enforcement, cost estimation, and notifications.
You can disable remote operations for any workspace by changing its Execution Mode to Local. This causes the workspace to act only as a remote backend for Terraform state, with all execution occurring on your own workstations or continuous integration workers.
Comments in terraform : #(singleline comment - used default, / / -> multi line comment ,//(single line) 48.Terraform has a multi-cloud and provider-agnostic approach that makes it ideal for use across multiple clouds and services.
Terraform is written in GO(programmming language) and provided as a single binary that includes core components needed to parse n deploy terraform configuration(terraform.exe). Terraform makes use of plugins for its providers and provisioners instead of bundling them in the core binary. Each plugin executes as a separate process communicating with the core terraform binary using an RPC interface.
Provider aliases can also be used with modules
Terraform providers: official (owned and maintained by hashicorp) verified (maintained by other vendors but have gone through the partner approved process community approved ( are published and maintained by individuals and aren’t officially supported.)
hostname/organization/provider. If the hostname is omitted, Terraform assumes we’re using the public Terraform registry, registry.terraform.io.
To improve performance, plugin caching can be enabled either through plugin_cache_dir setting in the Terraform CLI configuration file or TF_PLUGIN_CACHE_DIR environment variable
to point plugins to internal location-> use mirrors , use plugin directories(TF_PLUGIN_DIR)
Terraform isn’t able to track the results and status of provisioners in the same way it can for other resources. For this reason, HashiCorp recommends using provisioners only as a last resort.
When a creation-time provisioner fails, it sets the resource as tainted because it has no way of knowing how to remediate the issue outside of deleting the resource and trying again. This behavior can be altered using the on_failure argument.
A single resource can have multiple provisioners described within its configuration block. The provisioners will run in the order they appear.
Which block would you use to specify provider versions for a configuration? required_providers
official public repository for Terraform providers? registry.terraform.io
The terraform import command can bring existing resources into management by Terraform. The command alone doesn’t create the necessary configuration to import a resource; that must be done manually.
Terraform workspaces are a combination of a state file and a configuration. They’re used to create multiple instances of a configuration in separate environments. We can’t delete the default workspace.
There are two primary methods to separate state between environments: directories and workspaces. To separate environments with potential configuration differences, use a directory structure. Use workspaces for environments that do not greatly deviate from one another, to avoid duplicating your configurations.
Modules have a hierarchical structure root module a -> child module b-> child module c If we are using terraform state list, we’d see a resource address for the subnet like module.a.module.b.azurerm_subnet.subnet[0].
If a lock file is present, Terraform Cloud, CLI, and Enterprise will all obey it when installing providers.
Terraform currently requires the state to exist after Terraform has been run.
The command : terraform console holds a lock on the state, and you will not be able to use the console while performing other actions that modify state.
When you develop new Terraform code, and you're ready to test it out, the first thing you need to do is run terraform init in order to initialize the working directory and download any required providers or referenced modules. (if you try running terraform validate (before init)-> error: missing required provider)
using remote backend allows you to execute your Terraform on infrastructure either locally or in Terraform Cloud
Workspaces in OSS are often used within the same working directory while workspaces in Enterprise/Cloud are often (but not required) mapped to unique repos.
Terraform (cloud for free) and terraform oss does not support Sentinel
Terraform taint is deprecated hence use terraform apply -replace=ADDRESS (from 0.15.2)
Single Sign-On is a feature of Terraform Enterprise and Terraform Cloud for Business. It is NOT available in Terraform Cloud (free tier)
When Terraform Enterprise needs to be installed in a location where it does not have internet access to download the installer and upgrades, the installation is generally known as to be airgapped
By default, Terraform Enterprise allocates 512 MB of memory to each Terraform run, with a default concurrency of 10 parallel runs. Therefore, by default Terraform Enterprise requires 5.2 GB of memory reserved for runs.
There is no Terraform binary for AIX. Terraform is available for macOS, FreeBSD, OpenBSD, Linux, Solaris, and Windows.
Terraform destroy will prompt for confirmation
Terraform OSS store the local state for workspaces? terraform.tfstate.d
Providers are plugins released on a separate rhythm from Terraform itself, and so they have their own version numbers. For production use, you should constrain the acceptable provider version via configuration. This helps to ensure that new versions with potentially breaking changes will not be automatically installed by terraform init in the future.
The terraform show command is used to provide human-readable output from a state or plan file.
Version constraints are supported only for modules installed from a module registry, such as the public Terraform Registry or Terraform Cloud's private module registry
Other module sources can provide their own versioning mechanisms within the source string itself, or might not support versions at all. In particular, modules sourced from local file paths do not support version; since they're loaded from the same source repository, they always share the same version as their caller.
terraform show will display all the states of resources in state file while terraform state show only display that resource as in state file
Use environment variables to pass credentials when you need to use different values between the plan and apply steps.
You do not need to specify every required argument in the backend configuration. Omitting certain arguments may be desirable to avoid storing secrets, such as access keys, within the main configuration. When some or all of the arguments are omitted, we call this a partial configuration. With a partial configuration, the remaining configuration arguments must be provided as part of the initialization process. There are several ways to supply the remaining arguments:
- Interactively: Terraform will interactively ask you for the required values unless interactive input is disabled. Terraform will not prompt for optional values.
- File: A configuration file may be specified via the init command line. To specify a file, use the -backend-config=PATH option when running terraform init. If the file contains secrets it may be kept in a secure data store, such as Vault, in which case it must be downloaded to the local disk before running Terraform.
- Command-line key/value pairs: Key/value pairs can be specified via the init command line. Note that many shells retain command-line flags in a history file, so this isn't recommended for secrets. To specify a single key/value pair, use the -backend-config="KEY=VALUE" option when running terraform init.
The core Terraform workflow has three steps:
- Write - Author infrastructure as code.
- Plan - Preview changes before applying.
- Apply - Provision reproducible infrastructure.
Before a new provider can be used, it must be declared/used in a configuration file and initialized.
Data sources allow data to be fetched or computed for use elsewhere in Terraform configuration. Use of data sources allows a Terraform configuration to make use of information defined outside of Terraform, or defined by another separate Terraform configuration.
Terraform login is used to login to terraform cloud
IaC makes changes idempotent, consistent, repeatable, and predictable
If a module or provider is marked as official, it is owned and maintained by HashiCorp themselves.
The attributes of resources within a module are only available to the calling module if exposed as outputs. Outputs can be simple or complex types.
The version constraint can only be used on modules sourced from a module registry
There’s a temporary state file that’s created during the first run of terraform plan against the configuration. It’s necessary for an execution plan to be generated, but because there’s no state data yet, the temporary file is discarded. The permanent state data is written once terraform apply is run.
The terraform init process downloads the modules and plugins we’re using in our configuration and validated that they had access to the local filesystem. Starting with Terraform 0.14, terraform init also creates the file .terraform.lock.hcl containing a list of providers used, including the version, version constraints, and hashes of the provider plugin. Initialization verifies the state back-end
Validation can be run explicitly by using the terraform validate command or implicitly during the terraform plan or terraform apply commands. By default, terraform plan validates the configuration before generating an execution plan. If terraform apply is run without a saved execution plan, Terraform also runs an implicit validation.
The Sentinel integration with Terraform runs within Terraform Cloud after a terraform plan and before a terraform apply. The policies have access to the created plan, the state at the time of the plan, and the configuration at the time of the plan. Sentinel policies can validate that the terraform plan results will align to corporate requirements (as defined within a Sentinel policy), and if it doesn’t, the creation of those resources (through terraform apply) is prevented.
Terraform Cloud includes both a private registry and workspaces for infrastructure configurations.
Terraform OSS is the free, open-source CLI that we can download and run on a local system.
Terraform Cloud is hosted Terraform for teams( T enterprise) -> free for teams < 5 members
Terraform Enterprise is on-premises Terraform for teams (formerly Private Terraform Enterprise).
Workspaces in Terraform OSS provide managed state using the same configuration. Terraform Cloud adds functionality to workspaces with value management, VCS integration, and historical logs.
in normal use, HashiCorp does not recommend including access credentials as part of the backend configuration. Instead, leave those arguments completely unset and provide credentials via the credentials files or environment variables that are conventional for the target system, as described in the documentation for each backend.
Best practice here is to provide your sensitive values OUTSIDE of Terraform, like storing and retrieving them from a secrets management platform like Vault, or using environment variable

Terraform

Subscribe to my newsletter

Aparna

Aparna