What is Terraform?

Terraform can be defined as a tool for versioning, changing, and building infrastructure efficiently and safely. It can manage popular and existing service providers and custom in-house solutions also.

Configuration files explain to terraform that the elements required executing our entire data center or an individual application. Terraform produces a single execution plan explaining what it'll do for reaching the desired state after it runs for building the desired infrastructure. Terraform is capable of determining what will change and build execution plans that can be used as the configuration modifications.

The infrastructure terraform could handle low-level elements like networking, storage, compute instances, also high-level elements like SaaS features, DNS entries, etc.

Terraform can provide support with multi-cloud via having a single workflow for every cloud. Various manages of terraform infrastructure could be hosted over Google Cloud Platform, Microsoft Azure, and Amazon Web Services, or on-prem within the private clouds like CloudStack, OpenStack, or VMWare vSphere. Terraform considers IaC (Infrastructure as Code). So, we need not to be worried about our infrastructure drifting away through the desired configuration.

Architecture of Terraform

The architecture includes the given components:

Terraform Core: The core of Terraform is liable for creating the dependency graph and reading configuration. Terraform heavily relies on the current graph theory to manage dependencies. The core of Terraform is an actual project of Terraform on GitHub.

Plugins: Terraform plugins can be defined as the external individual static binaries. The core of Terraform communicates with the plugins by the RPC interface during the applying and planning phases. If we are unknown to RPC, assume that these plugins are the servers and the core of Terraform creates API calls for these servers. The most common plugin type is the

Terraform Provider Plugin. These plugins implement the resources along with any basic create, read, update, and delete (CRUD API) to communicate with various services of the third party.

Upstream API: Upstream API can be defined as a third party. It is an external API or service. It is necessary to remember that the core of Terraform never interacts with the APIs directly. Rather than, the core of Terraform asks the plugin of Terraform Provider for performing any operation. After that, these plugins will communicate with upstream API. It facilitates a clear corner separation. The core of Terraform doesn't require understanding API nuances. Terraform Provider Plugin doesn't require understanding the graph theory.

IaC (Infrastructure as Code)

IaC or Infrastructure as Code has attained enough momentum because it provides support in solving issues that previously bothered management of Infrastructure:

• Reproducible environments: The similar environment can be built again and again by applied code for generating infrastructure. An environment may drift away through the desired state and complex to recognize problems that may creep into our release pipeline. New environments can be destroyed and created easily and no environment will get specific treatment with IaC.
• Convergence and Idempotence: Idempotence can be defined as a trait that means no matter we use the configuration defines by our IaC. There will no side effects over the environments. Besides, convergence can be defined as a trait which means actions are taken when they require. Only those actions that are required to fetch the environment towards the desired condition are run. In case, an environment is in the desired condition already then no actions are required.
• Easing collaboration: If we have code within the version control system such as Git, it will permit teams for collaborating on infrastructure. Various members of the team can get the code's specific version and build their environments to test and other purposes.
• Self-service infrastructure: Cloud elasticity permits resources to be built on-demand. Various developers can plan any infrastructure they require when they require it. Further, IaC improves the condition by permitting developers to apply modules of the infrastructure for creating identical environments in the application development lifecycle. The modules of the infrastructure can be shared with many developers and built by operations.

Some other options of IaC

Usually, cloud providers facilitate the native infrastructure as the solutions of code. For example:

• Microsoft Azure contains Azure Resource Manager templates
• Google Cloud Platform contains deployment manager
• Amazon Web Services contain Cloud Formation

All come with the specific form of defining Infrastructure as Code (IaC). Also, that holds for various private clouds such as OpenStack, which includes heat for defining Infrastructure within the code.

Hybrid-cloud is more powerful to have a common workflow and one tool for managing infrastructure. Even if we are using a single cloud only, it can be worth futureproofing in case we do leverage more than one cloud later on.

Supported Infrastructure of Terraform

Terraform infrastructure assimilation permits to manage services and software, including databases such as MySQL, configuration management tools such as Chef, and source control systems such as GitHub, and many others.

Use Cases of Terraform

Let's consider a few example use cases of terraform:

• Disposable environments: It is general to have QA or staging and production environments. These types of environments are the production counterpart's smaller clones. But these environments are used for testing newer applications before publishing in production. As the environment of production is more complex and grows larger, it becomes harsh for maintaining the up-to-date environment.
  The environment of production could be codified and begun with dev, QA, or staging using terraform. These configurations are used for spinning-up newer environments rapidly to test in and be disposed of easily. Terraform can support reduce the complexity of controlling parallel environments. Also, it can destroy and create environments elastically.
• Multi-cloud Deployment: It can be creative to spread the infrastructure across more than one cloud for increasing fault-tolerance. Fault-tolerance is bound by the provider availability by using a single cloud provider or region. Multi-cloud deployment permits for more loss recovery of the entire provider or a region. Also, increasing fault-tolerance uses for hybrid clouds where we have our private cloud executing on-prem. However, leverage any public cloud for disaster recovery and business continuity. For example, executing a secondary application or database, tiring access to information, backing up data when our servers of primary on-prem fails. Also, we may encounter some situations where a single public cloud provider contains the services that are not available on our approved public provider. Accomplishing multi-cloud deployments may be very asserting as various tools for management of Infrastructure are cloud-specific. Also, terraform is cloud-agnostic and permits one configuration to be applied for managing more than one provider. It simplifies orchestration and management and supporting operators create multi-cloud large-scale infrastructures.
• Multi-tier applications: A common arrangement is N-tier architecture. The web server pool is the most general 2-tier architecture that uses the database tier. Other additional tiers included for API servers, routing meshes, caching servers, etc. This arrangement is used due to tiers could be independently scaled and facilitate the corners separation. Terraform is useful for managing and building these infrastructures. All tiers can be defined as the resources collection. The dependencies among all tiers are automatically managed. Terraform will make sure that the tier of the database is present before all the web servers are begun. Then all the tiers could be scaled efficiently with terraform by changing a single value of count configuration because the provisioning and creation of any resource are automated and codified.
• Resource Schedulers: The application's static assignment for machines becomes challenging increasingly with large-scale infrastructures. To solve this issue, there are a lot of schedulers such as Kubernetes, YARN, Mesos, and Borg. These schedulers can be used for scheduling the Docker containers, Spark, Hadoop, and many more. Terraform is not bound to physical providers such as AWS. The resource schedulers may be treated like a provider, allowing terraform to claim resources through them. It also permits terraform to be applied inside the layers. It is further used for setting up various physical infrastructures executing the schedulers and also provisioning on the scheduled grid.

Product Streams of Terraform

Terraform can be referred to as distinct tiers and products. These tiers and products are discussed as follows:

• The basic product is Open-Source Terraform Version. It contains each piece required for providing IaC and facilitates support over a hundred infrastructure integrations. The open-source terraform product's source code lives on the GitHub platform and is specified in the Go language. This version facilitates the command-line interface to manage the infrastructure.
• Another product of Terraform is Terraform Enterprise. It is available within two tiers. These tiers add other features helpful for various teams and include the open-source version's features.
• Pro is the initial tier. Pro is SaaS (Software as a Service). It is managed via HashiCorp and executes inside the cloud. The pro tier provides the user interface graphically, version control connections for changing the infrastructure, API access for integrating terraform into tooling, and a module registry of private infrastructure to share re-usable modules in our organization.
• The second enterprise tier is Premium. The Premium can be installed on our cloud infrastructure. It should be inside AWS currently. It includes various aspects of Pro and code. It facilitates audit logs of all infrastructure modifications. Also, we get great support from HashiCorp.

Terraform CLI

The version-specific open-source Terraform product assembles to any tool that we interact with over a command-line. A command-line tool applies configuration files and these files describe our IaC (Infrastructure as Code).

Typical Workflow of CLI

We know that there are configuration files and a CLI. This topic will define how we can apply Terraform if we are developing infrastructure code.

Initially, we can change configuration files for our infrastructure. These configuration files announce the objective state of our infrastructure. We change configuration files for declaring how we wish to modify any existing infrastructure.

We may ask Terraform for producing the execution plan for it once we are fine with our declared configuration. This execution plan will tell us what modifications terraform would require to make for bringing our latest infrastructure to the published state into our configuration. It'll plan a few required actions for bringing the infrastructure into the desired state. Also, terraform considers dependencies for determining the sequence that modifications should be used in. Relatively, the plan state is inexpensive than actually used modifications. So, we can liberally apply the plan command when developing our configuration to determine what modifications would require to take. The plan state can take time for some complex infrastructures. Terraform should get the latest state of each component in our infrastructure by creating API requests. This is due to plan changes correctly. There are so many ways for working around the slow generation of a plan if we ever encounter this type of situation. We can tell to terraform for targeting only an infrastructure subset or for using the information of stale state for any plan.
According to the required modifications we see within the plan, we can either reject or accept the modifications. Terraform allows us to avoid uncertainty and mistakes by planning modifications before using them.
If we do not like the plan, then we can go back and change our configuration without any harm.
If we accept the plan we can instruct terraform for applying modifications. We use an apply command for accomplishing this. This apply command can apply the plan that we produce with this plan command. When we do not facilitate any plan, apply could produce one and ask for us for accepting the plan before using the modifications. Terraform will create the API calls needed for implementing the modifications. If something goes wrong then terraform will not be attempted to rollback an infrastructure automatically to a state it was in before executing to apply. This is due to apply observes to the plan. It would not delete any resource when the plan does not call for it. If we version control our code of Infrastructure configuration, we can use our configuration's previous version to roll back. We can alternatively use a taint or destroy command for targeting components that require be recreating or deleting respectively.

Resource Graph of Terraform

Terraform creates a resource graph that picks all the information of dependency inside our infrastructure. Usually, the dependencies are naturally represented from the configuration. Terraform can use modifications in parallel if dependencies do not exist and create our infrastructure as attractive as possible with these resource graphs. Terraform can provide a graph and we can visualize it for understanding more about our infrastructure. This graph illustrates the dependencies among VPC, subnets, or instance.

Automation workflow of Terraform

Automation support can be provided by terraform, for example, with integration into continuous deployment pipelines or continuous integration. Automatically, we can create the infrastructure for deploying new branches.
Automatically, we can accept the plans to include updates of Infrastructure to the current version without the intervention of humans. Probably, it is not a great concept for production environments.
Instead of we can choose to keep approval steps manually. Using the generated resource graph and execution plan, it is efficient for understanding what is going to be modified and in what sequence. The chances of creating unintentional modifications are greatly reduced for various complex change-sets.
Lastly, we can produce only a plan. It could be helpful to review pull requests. Quickly, we can determine the change's implications on our latest infrastructure via inspecting any plan.

Migrating to Terraform

Terraform can support our infrastructure transfer control to terraform. It supports to import existing resources to get them under control with an import command. We can try to import resources within the AWS Resources using Terraform Lab. We will start via import any resource handled by the AWS CloudFormation in this lab.