Author Phase Terms and Concepts
1. Author Phase Terms and Concepts
We’ve covered Terraform configurations and the HashiCorp Language. Now let’s discuss common terms and concepts that you encounter during the author phase of the Terraform workflow. Resources are code blocks that define the infrastructure components. A resource is identified by the keyword resource, followed by the resource type and a custom name. The resource type depends on the provider defined in your configuration. Inside the curly brackets are the resources arguments, where you specify the inputs needed for the configuration. Terraform uses the resource type and the resource name to identify an infrastructure element. The keyword resource identifies the block as a cloud infrastructure component. The resource type is google_storage_bucket, which identifies the Google Cloud resource. This terminology is Terraform-specific and the convention cannot be customized. The resource type varies based on the provider defined. The resource name is example-bucket. Terraform uses the resource type and the resource name together as an identifier for the resource. This example assumes that Google Cloud is defined as the provider and shows two resource blocks: a Cloud Storage bucket and a compute instance. The arguments differ based on the resource type being defined. For the google_storage_bucket resource, you only must specify the name and location to successfully create the resource. For the google_compute_instance resource, you must specify the name, machine_type, and the network_interface. Zone and tags are optional. You can use separate files – for example, files for instances, storage buckets, and datasets – if you have lengthy resource configurations. Providers implement every resource type; without providers, Terraform can't manage any kind of infrastructure. In the providers.tf file, you specify the Terraform block that includes the provider definition you will use. Terraform downloads the provider plugin in the root configuration when the provider is declared. Providers expose specific APIs as Terraform resources, and manage their interactions. Provider configurations belong in the root module of a Terraform configuration. An example of a provider block is shown on screen. The source argument provides the global source address for the provider that you intend to use. In the above example, the source argument is assigned to the Terraform Registry URL hashicorp/google. The name Google is the local name of the provider to be configured. To ensure that the local name is configured correctly, the provider must be included in the required provider block. The arguments – such as project and region – are specific to the Google provider. When a provider block is not included within a Terraform configuration, Terraform assumes an empty default configuration. You can also assign a version to each provider. The version argument is optional, but recommended. Version arguments constrain the provider to a specific version or a range of versions to prevent downloading a new provide that may contain breaking changes. If the version isn't specified, Terraform will automatically download the most recent provider during initialization. Variables are used to parameterize your configuration. Input variables serve as parameters for Terraform, allowing easy customization and sharing without having to alter source code. Once a variable is defined, there are different ways to set its values at runtime: environment variables, CLI options, key or value files, and so forth. You can define a resource attribute at run time or centrally in a file with a . tvars extension. You can also easily separate attributes from deployment plans. In this example, main.tf declares a Cloud Storage bucket. The location attribute has been parameterized because it’s declared as a variable in the variables.tf file. By parameterizing the attribute, you can define the values of these variables at run time. You’ll learn more about variables in the next module. The outputs.tf file holds output values from your resources. Resource instances managed by Terraform each export attributes whose values can be used elsewhere in configuration. If needed, output values are a way to expose some of that information. Some resource attributes are computed upon their creation. For example, a self-link of the resource or the URL of a bucket is generated upon bucket creation. These computed attributes might be required for accessing the bucket or uploading objects. With an output value, you can output this information and make it accessible. The label after the output keyword is the name, which must be a valid identifier. In a root module, this name is displayed to the viewer. In a child module, it can be used to access the value. The value argument takes an expression that returns the results to the user. Terraform saves the state of resources that it manages in a state file. By default, the state file is stored locally, but it can also be stored remotely. Remote storage is often the preferred method when working in a team environment. Do not modify or touch this file; it’s created and updated automatically. States are covered in detail in an upcoming module. Finally, a Terraform module is a set of Terraform configuration files in a single directory. Even a simple configuration consisting of a single directory with one or more . tf files is considered a module. Modules are the primary method for code reuse in Terraform. They are reused by specifying the source from which the code can be retrieved. Sources can either be local or remote. You can use an upstream module from the HashiCorp module registry or create your own.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.