Dot11 Guru

automation, scripting, Tools & Scripts

Terraform Associate Certification – Part 2

This series is a compilation of my study notes and references towards the Terraform Associate Certification but geared towards the Networking domain.

https://www.hashicorp.com/certification/terraform-associate

Terraform Associate Certification – Part 1

Terraform Providers

Providers are plugins used within a configuration. When you add providers to a configuration you have to run or re-run the init command. The init command will download the required plugins to the working directory. Providers use a plug-in based architecture

There are 3 types of terraform providers:

Offical: Owned and maintained by Hashicorp. Include most cloud providers.

Verified: Owned and maintained by thirdparty technology companies, but undergo a review process by Hashicorp

Community: Owned and maintained by individual contributors.

Plugins are downloaded into a hidden directory ./terraform/plugins

Organisational Namespace

The organisational namespace is an address associated to a module. It follows the following syntax:

hostname / namespace / name / system

Hostname: The hostname is optional, where it is not defined it will default to registry.terraform.io

Namespace: The namespace is unique to a particular hostname, and contains one or more related modules.

Name: Is used to describe the module being used.

System: Describes the remote system that the module is designed to be used on.

Provider Arguments

Provider arguments are used in configuration files to overwrite default values and in some situations to provide the ability to use a configuration against different versions. The arguments available to each provider differs, and is found in the provider documentation.

Referencing Resource Attribute

You can reference resource attributes to help link attributes between different providers. The attributes are found in the provider documentation.

[command] Terraform providers

The terraform providers command gives information about the provider requirements for a configuration.

terraform providers lock: writes information into the dependencies lock file by consulting upstream providers. Typically this is done via the terraform init command, but in some complex scenarios it may not be sufficient and the providers lock command needs to be used.

terraform providers mirror: In some situations, terraform init will not be able to download copies of the providers to the local filesystem. As an example, if terraform is run on an isolated network without internet access, the providers mirror command can be used to download an offline copy of the provider.

terraform providers schema -json: Downloads a copy of the schema in a machine readable format.

[command] terraform version

The terraform version command displays the version of terraform and installed plugins. Optionally, you can use the -json switch to print the output in a machine readable format.

Controlling Provider Version

It’s recommended to control the version of a provider. This helps ensure newer releases of the provider do not break your configuration due to changes in functionality. This can be achieved by specifying version (and even source) inside the required_providers block.

=, or no operator: Specifies the exact version to use

!=: Do not use a specific version

< or >: Greater than, or less than but not equal to

<= or >=: Greater than or less than or equal to

~>: Allow only the right most component. Example, ~> 1.0.0 will allow 1.0.9 but not 1.1.0

These operators can be used in conjunction with each other. Example, > 2.1.0 != 2.2

The required providers above configured inside of the Terraform block. This block is used to configure terraform specific parameters for a configuration. This is not the only location a version constraint can be defined. This can also be acheived within modules, or inside of a required_version argument.

Share this:

Leave a Reply