Terraform is a tool to define the infrastructure and services that make up a system. It allows us to not only build all the pieces of the system, but track and apply changes to a system over time. It's based on configuration files, which can be checked into version control, helping us achieve Infrastructure as Code. Terraform is a very high-level view of the solution. For a system using cloud-based services, Terraform may be all you need to achieve infrastructure as code. For more traditional on-prem environments, or Infrastructure as a Service (IaaS) environments in the cloud, you may need to combine Terraform to manage your infrastructure, and a lower level tool such as Ansible to maintain the internal state of servers over their lifespan.

Before we get going, let's define some terms. - Providers : A provider is a plugin that actually does the work. It provides a way to authenticate to the service, and resources to perform operations. If you take a look at the Terraform Registry , you'll see Terraform providers for popular clouds providers (AWS, Azure, Google Cloud Platform, Oracle Cloud Infrastructure (OCI), Alibaba Cloud etc.) as well as more traditional on-prem infrastructure such as VMware, and even providers for individual products. The provider is an interface to the service, which does all the heavy lifting while keeping our definition of the infrastructure simple and abstracted. - Resources : Resources are the things we use to build or change infrastructure. For example if we want to create a new Autonomous Database on Oracle Cloud, we would use the oci_database_autonomous_database resource in the OCI provider. - Data Sources : Data sources return information about existing resources. This information may be displayed, or used during the build of dependent resources. - Input Variables : Think of these as parameter values or command line arguments. We don't want to check sensitive information, such as authentication credentials, into source control, and we probably want to make our definitions reusable. Input variables allow us to achieve this. - Output Values : For a regular Terraform script an output value is a way to display information. For a Terraform module output values define what information is returned by the module. These are the data sources. - Modules : A group of related resource to complete a piece of work. We can achieve quite complicated builds without ever defining our own modules, but we may wish to package multiple resources into a module to simplify top-level definitions, and encourage reuse. Don't get hung up on modules in the early stages.

File names are not as important as file extensions. By default all files with the ".tf" extension will be loaded by Terraform. Even so, we will often see some common file names. - main.tf : The location of the provider and resource definitions. This could be one or many resource definitions. - variables.tf : The location of input variable definitions, not the variable values, although it could contain default values for some or all variables. - output.tf : The location of output definitions. - terraform.tvars : The location of variable values. If the file has this exact name it will be loaded by default. All other "*.tvars" file will not be loaded automatically, but they can be referenced using the flag. - {file-name}.auto.tvars : The location of variable values. All files with the ".auto.vars" extension will be loaded by default. - README.md : Documentation in markdown format. We don't need to use these file names, and we don't need to split Terraform definitions into different files. You'll see in some of my examples I keep the resource, variable and output definitions in a single file for simplicity. Having said that, module definitions should probably follow these naming conventions.

Assigning values to variables can be accomplished in several ways. Some ways were mentioned above, but there is a separate article about it here . There is no "best" method, but we should probably avoid putting variable values into source control. We don't want to risk accidentally exposing sensitive data to the outside world.

The installation process will vary depending on your client operating system. You can see examples of the installation for Windows and Linux here .

Once we have a Terraform definition we're going to want to build something. The first step is to initialize the directory holding our files. We do this using the command. We have a file called "main.tf" in the "C:\git\oraclebase\terraform\beginners\intro" directory with the following contents. It defines an input variable and an output variable. We initialize the directory as follows. Once the initialization is complete, a ".terraform.lock.hcl" file is created.

1
2
3
4
5
6
7
8
9
10
11

variable "my_variable" {
  type    = string
  default = "default-value"
}

output "my_variable_output" {
  value = var.my_variable
}

cd C:\git\oraclebase\terraform\beginners\intro
terraform init

With the directory initialized, we can use the command to create an execution plan. This is like a dry run of a build, which allows us to check what operations will take place if we do a real build. In this case we aren't building anything, so all we get is variable definition and default value displayed. We can save the plan using the flag.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

terraform plan

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:

Terraform will perform the following actions:

Plan: 0 to add, 0 to change, 0 to destroy.

Changes to Outputs:
+ my_variable_output = "default-value"
------------------------------------------------------------------------

Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.

terraform plan -out=plan.out

When we are ready to perform a build, we use the command. If no plan is specified, a new plan is generated and the build is done using that plan. Since we don't have a provider or any resources defined, the command doesn't build anything, but it saves the build state in a "terraform.tfstate" file. In the example below we perform a , passing a variable value on the command line using the flag. We use the flag so we don't have to manually confirm the action. We can apply an existing plan by giving the name of the plan file on the command line.

1
2
3
4
5
6
7
8

terraform apply -var="my_variable=melon" -auto-approve

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:
my_variable_output = "melon"

terraform apply plan.out

Now we know what terraform is and some of the basics of how to use it, it's time to build some things with it. It's worth reading the article about Terraform variables , then try building some components on Oracle Cloud Infrastructure (OCI) following the articles here . You can do that for free using the Oracle Cloud Free Tier . For more information see: - Introduction to Terraform - Terraform : Installation - Terraform : Variables - A Beginners Guide - Terraform : All Articles Hope this helps. Regards Tim...