Featured

TerraForm Deployment Series Part-5

Good Day Fellas and a Very Namaste to all my Tech friends. I hope you all doing great and Pumping up the technology faster during this Pandemic through veins.

So Today I would be discussing the Deployment part of Terraform. Here is the topics we would go through in today’s Blog.

  • Provider.
  • Resource.
  • Destroying the Infrastructure.
  • State Files.
  • Current and Desired State.
  • Provider Versioning.

So let’s start deploying the Infrastructure :-

But before how would you login to your Azure Subscription using Terraform, you definitely need a medium to authenticate the Terraform with your Azure Subscription.

How to Authenticate Terraform ?

We can authenticate using the following methods mentioned below:-

  1. CLI
  2. Service Principal and Client Certificate.
  3. Service Principal and Client Secret.
  4. Using Managed Identity.

I’ll not be covering these methods however you can please follow this link to learn the authentication methods:-

https://www.terraform.io/docs/providers/azurerm/guides/azure_cli.html

Well I Already discussed about the Resources and Providers in my previous Blogs however the purpose of discussing about them is how you can use them.

Resource :-

Cloud Computing Cartoons and Comics - funny pictures from CartoonStock

A resource block declares a resource of a given type (“azurerm_virtual_network”) with a given local name (“example”).

A resource block describes your intent for a particular infrastructure object to exist with the given settings. If you are writing a new configuration for the first time, the resources it defines will exist only in the configuration, and will not yet represent real infrastructure objects in the target platform.

The resource type and name together serve as an identifier for a given resource and so must be unique within a module.

The name is used to refer to this resource from elsewhere in the same Terraform module, but has no significance outside of the scope of a module.

resource “azurerm_virtual_network” “example” {

  name                = “virtualNetwork1”

  location            = azurerm_resource_group.example.location

  resource_group_name = azurerm_resource_group.example.name

  address_space       = [“10.0.0.0/16”]

}

Within the block body (between { and }) are the configuration arguments for the resource itself.

How Does Provider help you writing the Configuration files?

Provider is always set the behavior of the resource type and they defined the course of configuration of Terraform Module.

Provider is useful and we have many providers updated in Terraform and has been validated by Hashicorp itself which you can see of the Hashicorp website.

Provider Version is important cause it will define which version of Provider you have been using .

Hashicorp will update the version of provider and update the version of Terraform configuration as well . It is very similar the way we see OS versions gets changed periodically.

But they don’t get an update parallelly, which means you may have been running the older version of the code but then if you don’t have the provider block , terraform automatically updates the configuration to the latest and you lose all your hard work .

Hence it is important to know the difference between the version of Provider and the version of Terraform Configuration.

Terraform has current configuration version is 0.12 and 0.13 is in pipeline.

There are third party providers but not validated by Hashicorp. Hence we need to download them and execute manually.

We won’t be looking much into it.

That’s how the provider.tf file looks like:-

provider “azurerm” {
  # Whilst version is optional, we /strongly recommend/ using it to pin the version of the Provider being used
  version = “=1.44.0”

}

So now we know what is provider. We also needed to understand that how you can initiate and load Terraform for Deploying the Infrastructure.

Terraform Init play a major role for downloading the plugins and validating the provider configuration. Once you run the Terraform init command it will download all the plugins related to current provider we have defined in our configuration.

PS C:\Users\Rahul\Desktop\terraform-exam\tf-exam> terraform init

Initializing the backend…

Initializing provider plugins…

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running “terraform plan” to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun “terraform init” command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

If you want to update the Terraform Configuration just type terraform init -upgrade {this command also upgrades to the latest versions of all Terraform modules}

Plugin gets installed in the following folder:–

Windows :- “%APPDATA%\terraform.d\plugins“

All other OS :-  “~/.terraform.d/plugins”.

Once you installed the Plugins and Providers configuration based on your .TF file. you need to plan your configuration to execute them in controlled manner and You use Terraform Plan to draw out the configuration .

TERRAFORM PLAN:– usage :- terraform plan [options] [dir]

The terraform plan command is used to create an execution plan. Terraform performs a refresh, unless explicitly disabled, and then determines what actions are necessary to achieve the desired state specified in the configuration files.

This command is a convenient way to check whether the execution plan for a set of changes matches your expectations without making any changes to real resources or to the state. For example, terraform plan might be run before committing a change to version control, to create confidence that it will behave as expected.

You can consider terraform plan as a dry-run of your changes. Once you have reviewed the execution plan above, and confirmed that your changes are as expected, you can proceed to run terraform apply in order to have your changes applied.

This is the message you see while performing the Terraform Plan and Plan will refersh the state file as well.

PS C:\Users\Rahul\Desktop\Project\VNET-HUB-arch\vnet-hub-spoke-model>terraform plan


Refreshing Terraform state in-memory prior to plan…
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

Applying (Terraform Apply) Terraform configuration is the process of creating, updating, and destroying real infrastructure objects in order to make their settings match the configuration.

Terraform Plan will calculate the Configuration of your desired state code in .tf configuration file  and deploy the infra as per the code.

Terraform plan also refresh the state of the terraform file as per the current configuration and make changes in the state file.

Terraform destroy will check what all resources has been created. It will refresh the state file and confirm the resources created which has been created and needs to destroyed.

Anyone can destroy the infrastructure by running this destructive command hence If you want to prevent the destroy command to break the Infrastructure. Then you can use the following code which acts as lock for the specific resource or a module.

 lifecycle {     
prevent_destroy = true   
}

Terraform State File:-  Terraform stores the state of the infrastructure that is being created from TF files. This state allows terraform to map real world resources to your existing configuration.

Talking about state, think of a database with a list of resources that maps everything it know to the real world resources.

Desired State :- Desired state is something which is on par with the Configuration provided in TF file for a resources

Current State :- Current state is something which is on par with the real world. Means what is exactly running in infrastructure.

Whenever we do the Terraform Plan it always tries to match with desired configuration. And Terraform Plan will always refresh the file, which also check the state file for any changes that needs to be done or update.

If in case you want to see the Terraform state file , you can use Terraform show command which will provide the information of State file.

I do not have much example however If you want please do visit my Git hub Link and Check the Hub and Spoke Model configuration via terraform using Modules.

https://matrahul.github.io/Azure-hub-spoke-architecture/

Rating: 1 out of 5.

TerraMate Blog Series -Part-4

Hope you all started your year with a Bang and I wish all of you who is working hard right now and had fruitful 2019, A very Happy New year .

If anyone is continue to read my previous blogs, I stopped at Configuration Language and I hope all of you should have gain something till now. If you really leaning towards Terraform or any sort of Automation. These blogs may not give you a depth knowledge however these blogs can let you start and help you read another blogs or connect you with different links you may want to give it a try.

We would be working on how to Create a Configuration file , what is required to Create them and How does it work.

We also look to compile Providers, Resources information as these details are required to have.

Let’s start a new year on a good note 🙂

HOW TO WORK WITH  Configuration

The set of files used to describe the resources in a HCL format or json format knowns as a Configuration language.

In this lesson you write your first configuration to create and configure a resource group in Azure.

Terraform uses a declarative model for defining infrastructure: You write a configuration that declares your desired state and then leave it up to Terraform and the Azure provider to determine how to create and configure Azure to match the desired state. Configuration files are made up of resources with settings and values representing the desired state of your infrastructure.

Terraform configurations are made up of one or more files in a directory. By default this directory will also contain provider binaries, plan file, and state files once Terraform has run the configuration. Plugins and other binary files needed by Terraform are saved in a hidden .terraform directory. The directory that contains the configuration files is often called the “working directory” or the “home directory.”

Terraform persists state (described later in this guide) over multiple sessions, allowing Terraform to compare the configuration files with previous and current state of Azure resources. When you change a configuration and apply it to existing infrastructure, Terraform compares the new configuration to the state saved from the previous terraform apply to create an execution plan that includes only the directly affected resources and dependencies.

It’s common to work with secrets in Terraform configurations. Secrets can include user account, passwords, connection strings, ssh keys, certificates, storage access keys, etc. — any information in your configuration that you don’t want everybody to know is a secret. Be careful not to include secrets in configuration files that get checked into source control.

Configuration Files:-

Terraform configuration (.tf) files have specific requirements, depending on the components that are defined in the file. For example, you might have your Terraform provider defined in one file (provider.tf), your variables defined in another (variables.tf), your data sources defined in yet another.

I have also provided much of the information on my other blogs and that can be used as reference.

What does these Files has?

These files actually made up of Provider, main, Variable, Data, output file and many as per your own requirements. We would go through them in this blog.

It is recommended that all files you create in a particular directory or a module , keep them separate.  I meant about creating the provider, resources,  data file separate rather than forming the entire infrastructure in one file.

Configuration file format

Configuration files can be in either of two formats: HashiCorp Configuration Language (HCL), or JSON. HCL is a structured language created with DevOps in mind; it is machine-friendly yet easy for humans to read, and it supports comments. HCL format files have a .tf extension. JSON is sometimes preferable when configurations are generated by a machine. JSON files have a .tf.json extension. A configuration can be composed of both .tf and .tf.json files. In general, we recommend that you work with HCL.

Providers

Terraform can configure resources across multiple clouds. For example, a single configuration can span both Azure and AWS. In such cases, there needs to be a way for Terraform to know how to manage each cloud. This is where cloud providers come in. Each cloud provider can have a provider block present in the configuration.

The provider block is used to configure the named provider, in this instance the Azure provider (azurerm). The Azure provider is responsible for creating and managing resources on Azure, and for all other interactions with Azure including authentication.

A basic Azure provider block looks like this:

provider “azurerm” {
    version = “~>1.32.0”
}

The version argument is optional, but recommended. It is used to constrain the provider to a specific version or a range of versions in order to prevent downloading a new provider that may possibly contain breaking changes. If the version isn’t specified, Terraform will automatically download the most recent provider during initialization. The ~> symbol is the pessimistic constraint operator. It tells Terraform to use all non-beta versions >=1.32.0 and <1.33.0.

Provider blocks may contain additional fields for identity, environment, role, and many others. 

A provider is responsible for understanding API interactions and exposing resources. Providers generally are an IaaS (e.g. Alibaba Cloud, AWS, GCP, Microsoft Azure, OpenStack), PaaS (e.g. Heroku), or SaaS services (e.g. Terraform Cloud, DNSimple, CloudFlare).

From <https://www.terraform.io/docs/providers/index.html>

DATA SOURCES

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.

A data source is accessed via a special kind of resource known as a data resource, declared using a data block:

data “aws_ami” “example” {
  most_recent = true

owners = [“self”]
  tags = {
    Name   = “app-server”
    Tested = “true”
  }
}

Resources

Resources are the most important element in the Terraform language. Each resource block describes one or more infrastructure objects, such as virtual networks, compute instances, or higher-level components such as DNS records.

resource “azurerm_resource_group” “example” {
  name     = “testResourceGroup1”
  location = “West US”

tags = {
    environment = “Production”
  }
}

A resource block declares a resource of a given type (“azurerm_resource_group”) with a given local name (“example”). The name is used to refer to this resource from elsewhere in the same Terraform module, but has no significance outside of the scope of a module.

The resource type and name together serve as an identifier for a given resource and so must be unique within a module.

Within the block body (between { and }) are the configuration arguments for the resource itself. Most arguments in this section depend on the resource type, and indeed in this example both name and location are arguments defined specifically for the azurerm_resource_group  resource type.

Note: Resource names must start with a letter or underscore, and may contain only letters, digits, underscores, and dashes.

Each resource is associated with a single resource type, which determines the kind of infrastructure object it manages and what arguments and other attributes the resource supports.

Each resource type in turn belongs to a provider, which is a plugin for Terraform that offers a collection of resource types. A provider usually provides resources to manage a single cloud or on-premises infrastructure platform.

Most of the items within the body of a resource block are specific to the selected resource type. These arguments can make full use of expressions and other dynamic Terraform language features.

Configuration Syntax

The Configuration Syntax is built around two keys syntax constructs :- Arguments and Blocks

ARGUMENTS :-

An Argument assigns a value to a particular name :-

subnet_id = “Subnet123”

The identifier before the equals sign is the argument name, and the expression after the equals sign is the argument’s value.

BLOCKS :-

A block has a type (resource in this example). Each block type defines how many labels must follow the type keyword. The resource block type expects two labels, which are azure_virtual_network and default in the example above. A particular block type may have any number of required labels, or it may require none as with the nested subnet block type.

resource “azure_virtual_network” “default” {
  name          = “test-network”
  address_space = [“10.1.2.0/24”]
  location      = “West US”

subnet {
    name           = “subnet1”
    address_prefix = “10.1.2.0/25”
  }
}

That’s all folks for Configuration language and other dependencies required to understand the Configuration. Well the request is to read them in more details again and again and start deploying the resources.

It will definitely help to build your base. Happy learning fellas.

TerraMate Blog Series Part 3

Good Day my Tech Fellas. Here I come with my another blog .  But I truly hope you have kept reading my other blogs as well.

Motto here remain same, to cover most of the basics terminology in depth. As promised to continue the discussion MODULES, we will continue to do the same however I shall cover the related terms as well in between.

Let’s start this Journey together on TERRAMATION.

In which FORMAT does Terraform saved his file and where it can be saved. Why it is important to know?

Well written query it is and answer is .TF State file.   State file is all about your infrastructure information and Hence the format of this file can be saved locally or remotely as well in >TF file format which basically a JSON version.

Terraform to map real world resources to your configuration, keep track of metadata, and to improve performance for large infrastructures.

Terraform uses this local state to create plans and make changes to your infrastructure. Prior to any operation, Terraform does a refresh to update the state with the real infrastructure.

Now how can someone edit the File if there is any issue in code .

This is why Terraform gives you an option to change the file and perform the Sanity check.

While the format of the state files are just JSON, direct file editing of the state is discouraged. Terraform provides the terraform state command to perform basic modifications of the state using the CLI.

STATE COMMAND:-

The terraform state command is used for advanced state management. As your Terraform usage becomes more advanced, there are some cases where you may need to modify the Terraform state. Rather than modify the state directly, the terraform state commands can be used in many cases instead.

Terraform state is a json file describing the infrastructure managed by terraform.

Terraform State is a scary part for many who tried Terraform before version 0.9. Back then you had to manage the state yourself, many people have told me how this turn them off from using it.

Example format :-     terraform state <subcommand> [options]

Remote State Management on Azure

(https://blog.jcorioland.io/archives/2019/09/09/terraform-microsoft-azure-remote-state-management.html)

There are two natural options to implement remote state management when targeting Microsoft Azure:

  1. you can use Terraform Cloud: I will not cover this topic, but you can find more information on this blog post from HashiCorp. https://www.hashicorp.com/blog/using-terraform-cloud-remote-state-management/
  2. you can use Azure Blob Storage, as detailed in the following. Like for providers, Terraform remote state management is based on a plugins architecture: for each project you are working on, you can choose what is the remote state backend (provider) that you want to use.

Terraform project Structure  :-

Before going deep dive into Terraform modules, let’s discuss about the basic structure/organization of a Terraform project.  As you Already know Terraform project is, basically, a collection of *.tf files in a specific directory.

Here is what could look like a minimal Terraform project directory:

/myproject
— main.tf
— feature1.tf
— feature2.tf
— outputs.tf
— variables.tf
— README.md

You can further break it down to have a Sub-directory per environment. If you want to manage the configuration from your git repository or your infrastructure is different depending on the environment.

/Terraformproject

 –/Azureproject

—–/Azuresubproject

——-/main.tf

——/feature.tf

——/output.tf

——/vars.tf

—–/README.md

main.tf:   This file usually contains provider configuration, backend configuration, imports to the modules to use and eventually some common resources that was not isolated into a specific file. It has all information related to the Infrastructure

resource “azurerm_virtual_network” “vnet” {

  name                = “${var.vnet_name}”

  resource_group_name = “${var.vnet_rg}”

  address_space       = [“${var.address_space}”]

  location            = “${var.location}”

  tags                = “${var.tags}”

  # dns_servers         = [“${var.dns_server}”]

}

vars.tf:   Here we actually define the information based on Main.tf file. Constants related to this environment

variable “location” {

  description = “The location/region where resource will be created. Changing this forces a new resource to be created.”

}

variable “vnet_name” {

  description = “Custom name provided to the vnet.”

}

variable “vnet_rg” {

  description = “The resource group where resource will be created.”

}

variable “address_space” {

  description = “The address space that is used the virtual network. You can supply more than one address space. Changing this forces a new resource to be created.”

Outputs.tf: contains the definitions for the deployment output variables, i.e. all the information that you want to retrieve and output the deployment.

output “resource_group_name” {
  value = “${azurerm_resource_group.rg.name}”
}

output “location” {
  value = “${var.location}”
}

output “environment” {
  value = “${var.environment}”
}

Resource Definitions VS Data Sources

There are two ways to reference an instance of a service running in Azure when working with Terraform. You can use a resource definition, with the resource keyword, like this is done in the snippets above or you can use a data source, with the data keyword:

resource “azurerm_resource_group” “rg” {
  name     = “${var.environment}-rg”
  location = “${var.location}”
}

data “azurerm_resource_group” “rg” {
  name = “${var.environment}-rg”
}

When you use the resource keyword, you indicate to Terraform that the current configuration is in charge of managing the life cycle of the object, i.e. to create/update it when terraform apply is called or to destroy it when the terraform destroy command is called.

When you use the data keyword, you indicate to Terraform that you only want to get a reference of the existing object, but don’t want to manage it part of this configuration (because it’s managed by another team, another module etc…). If the object does not exist when you apply the configuration, the Terraform command will fail.

Once you have a resource or a data source reference, you can use it in other part of your template, using it’s resource / data source name (in that case rg – the string that comes after the object type) like the following:

# reference a resource
resource_group_name = “${azurerm_resource_group.rg.name}”

# reference a data source
resource_group_name = “${data.azurerm_resource_group.rg.name}”

Now that we all reach here  and know the basic architecture structure of a Terraform , we shall start to discuss the Modules.

MODULES:-  In a very simple language, Module is comprising the Infrastructure information irrespective of the Providers.

Now we know let me put it through in technical Terms, for everyone understanding.

Modules help you to standardise your defined building blocks into defined and self-contained packages. Modules can be referenced by multiple terraform configurations if they are centrally placed, which promotes re-usability and therefore facilitates your default reference architectures and application patterns.

You can write multiple modules into separate directory of your project, or you can write modules in separate repositories. It’s also possible to import existing modules from the Terraform Registry.

Now Look at the below Virtual Network main.tf file

data “azurerm_virtual_network” “sys” {

  name                = “sys-vnet”

  resource_group_name = “sys-resourcegroup”

  provider            = “azurerm.sys”

}

data “azurerm_virtual_network” “stag” {

  name                = “stag-vnet”

  resource_group_name = “stag-resourcegroup”

  provider            = “azurerm.stag”

}

You can see that I’ve used the data keyword to reference the virtual network that  needs to be deployed in order to perform the Peering between the network.

 In that case, this is because I made the assumption that those two resources that are part of the core module need to be deployed before Peering Module.  This allows me to manage the pattern differently.

You can read more about Terraform modules on this page of the Terraform documentation and other related source which I have also read.

https://www.terraform-best-practices.com/key-concepts#composition

https://registry.terraform.io/browse/modules?provider=azurerm —> Terraform Registry

https://blog.jcorioland.io/archives/2019/09/11/terraform-microsoft-azure-modules.html

Organising the Folders

dev/qa/prd/core folder

Each environment folder corresponds to the terraform defining the infrastructure for each environment.

By separating our terraform in the mentioned folders every environment will have its own terraform state file.

By having a different terraform state file we isolate environments.

Composition

Composition is a collection of infrastructure modules, which can span across several logically separated areas (eg., AWS Regions, several AWS accounts). Composition is used to describe the complete infrastructure required for the whole organization or project.

Composition consists of infrastructure modules, which consist of resources modules, which implement individual resources.

Why so difficult?

While individual resources are like atoms in the infrastructure, resource modules are molecules. Module is a smallest versioned and shareable unit. It has exact list of arguments, implement basic logic for such unit to do required function. Eg. terraform-aws-security-group creates aws_security_group and aws_security_group_list resources based on input. This resource module by itself can be used together with other modules to create infrastructure module.

Access to data across molecules (resource modules and infrastructure modules) is performed using (module) outputs and data sources.

Access between compositions is performed using remote state data sources. When putting concepts described above in pseudo-relations it may look like this:

composition-1 {

  infrastructure-module-1 {

    data-source-1 => d1

    resource-module-1 {

      data-source-2 => d2

      resource-1 (d1, d2)

      resource-2 (d2)

    }

    resource-module-2 {

      data-source-3 => d3

      resource-3 (d1, d3)

      resource-4 (d3)

    }

  }

}

Conclusion:-

So we have understood the Module and Understood the dependencies around the resource and data source.

We have also understood the State of Terraform, Understood the Project Structure and other nitty gritty terms behind the Hashicorp Language

I hope everyone gets benefited with this information. I have provided the sources of blog and Website which can be helpful to explore more beyond this blog.

Stay Tuned we will be discussing about the Configuration Language in our next Blog.

See you all next week.

TerraMate the Cloud Series Part-2

Welcome to yet another Terramate series on Automating the Infrastructure. Again ,Until I cover relevant topics on Terraform, I’ll not jump the gun and start providing knowledge on IAC.

So please be patient with me and let’s Learn together step by Step.

In Today’s Blog we should be covering Configuration Files and related topics

Configuration Files:-     The set of files used to describe infrastructure in Terraform is known as a Terraform configuration.  Terraform uses a declarative model for defining infrastructure: You write a configuration that declares your desired state and then leave it up to Terraform and the Azure provider to determine how to create and configure Azure to match the desired state. Configuration files are made up of resources with settings and values representing the desired state of your infrastructure.

These files can be in 2 formats:-

  1. Hashicorp Configuration
  2. JSON

Terraform configurations are made up of one or more files in a directory. By default this directory will also contain provider binaries, plan file, and state files once Terraform has run the configuration.

Plugins and other binary files needed by Terraform are saved in a hidden .terraform directory. The directory that contains the configuration files is often called the “working directory” or the “home directory.”

Now since we know what is Configuration file , We can now jump towards knowing the underline architecture of this Language.

The main purpose of the Terraform language is declaring resources. All other language features exist only to make the definition of resources more flexible and convenient.

Resources are the most important element in the Terraform language. Each resource block describes one or more infrastructure objects, such as virtual networks, compute instances, or higher-level components such as DNS records.

RESOURCE SYNTAX

A resource block declares a resource of a given type (“azurerm-resource-group”) with a given local name (“web”). The name is used to refer to this resource from elsewhere in the same Terraform module, but has no significance outside of the scope of a module.

The resource type and name together serve as an identifier for a given resource and so must be unique within a module.

Within the block body (between { and }) are the configuration arguments for the resource itself. 

This is how the simple syntax looks alike:-

resource “azure_vnet” “vnet” {
  cidr_block = var.base_cidr_block
}

<BLOCK TYPE> “<BLOCK LABEL>” “<BLOCK LABEL>” {
  # Block body
  <IDENTIFIER> = <EXPRESSION> # Argument

A resource block has 2 string parameters before opening the block. First is the RESOURCE TYPE and second is RESOURCE NAME .

 The combination of the type and name must be unique.

Resource Block  :-  A resource block defines a resources that exists within the Infrastructure. A resource might be a physical component such as a network Interface or it can be a logical resource such as an Application.

A resource block declares a resource of a given type (“azure_vnet”) with a given local name (“vnet”). The name is used to refer to this resource from elsewhere in the same Terraform module, but has no significance outside of the scope of a module.

The resource type and name together serve as an identifier for a given resource and so must be unique within a module.

Within the block body (between { and }) are the configuration arguments for the resource itself. Most arguments in this section depend on the resource type.

Few Abbreviation now you must be thinking of :-

  • Blocks are containers for other content and usually represent the configuration of some kind of object, like a resource. Blocks have a block type, can have zero or more labels, and have a body that contains any number of arguments and nested blocks. Most of Terraform’s features are controlled by top-level blocks in a configuration file.
  • Arguments assign a value to a name. They appear within blocks.
  • Expressions represent a value, either literally or by referencing and combining other values. They appear as values for arguments, or within other expressions.
  • Providers :- The provider block is used to configure the named provider.

Basic Azure provider block looks like this

Provider “azurerm” {

Version = “1.20.0”

“}

The version Argument is optional but recommended

Now everyone will be thinking what is Module:-

A module is a container for multiple resources that are used together.

Every Terraform configuration has at least one module, known as its root module, which consists of the resources defined in the .tf files in the main working directory.

A module can call other modules, which lets you include the child module’s resources into the configuration in a concise way. Modules can also be called multiple times, either within the same configuration or in separate configurations, allowing resource configurations to be packaged and re-used.

Will now continue to discuss more in details about Modules and other related terms in our next blog please keep yourself tuned to Terramate.

Source :- https://www.terraform.io/docs/configuration/

TerraMate the CLOUD

Namaste to all my Techies . I hope someone across the world is also Automating something at this moment and I’m writing this blog :).  My Technical journey has just started to walk but unfortunately I can’t just walk, So I thought let me start with brisk running.

Let me introduce myself. My name is Rahul Mathuria. I work as Cloud engineer who has learnt Azure quite a bit and has been certified with Az-103 certification . Phew…. No DUMPS has been used. It was pure heart and Hard work.

For quite a while I wanted to write a blog on Terraform. But for me writing a code or working on any Infra as a code domain is like get a beating , which I never wanted to.

But then I actually thought I should help and learn with my connections be it LinkedIn, Instagram(what Terraform on Insta, Never)….

I have seen many videos on multiple Platforms like Udemy, Pluralsight, Cloud Academy and name it… They are providing amazing videos on Terraform , Please do watch them if you don’t like reading Blogs…

My goal is to reach out every learner who has never written a code in his/her life, can start doing this eventually.  Let me put it this way, This Blog is for Non-Coders.  But Everyone receives a warm welcome. They can definitely correct me and provide their feedback’s.

I request you all to start pushing this Infrastructure as Code (IAC) learning as soon as possible .  I thank you all if you have read this far. Now I and you are in same zone, that is no idea Zone. Now will learn and grow together.

Note:- This blog is referencing multiple different blogs, links and other open Sources. These all info which I have provided is already over Internet and lot of Great minds has provided this info already. Idea behind to write this blog is to provide all documents and links related to Terraform should be in one place.

TERMINOLOGY  NEEDED TO KNOW BEFORE YOU START :-  

I would be going through some basic terminology, for everyone to kick start the learning. People who are reading this can google around this terms and understand them in detail if possible.

I’m providing link at the end of every Term, least go through once.

What is DEVOPS, Infrastructure as a Code?

Very meaningful and useful thing which is needed to know for all who wanted to step in this arena.

Referenced Link:– https://techbeacon.com/enterprise-it/infrastructure-code-engine-heart-devops

IAC:-  

Infrastructure as Code (IaC) is the process of describing infrastructural components such as servers, services, or databases using a programming language. Once all infrastructural requirements are described in code, that code can be stored in source control.

Source control means that the infrastructure is versioned, transparent, documented, testable, mutable and discoverable. Once the first version is stored in source control, all team members see which infrastructure is required to bring a project alive. Everyone sees which configuration settings are required to make -for example- the database perform as good as expected.

DevOps:-  

DevOps is a culture which promotes collaboration between Development and Operations Team to deploy code to production faster in an automated & repeatable way. The word ‘DevOps’ is a combination of two words ‘development’ and ‘operations.’

DevOps helps to increases an organization’s speed to deliver applications and services. It allows organizations to serve their customers better and compete more strongly in the market.

In simple words, DevOps can be defined as an alignment of development and IT operations with better communication and collaboration.

Lifecycle of DevOps:-

Repository:- 

In software development, a repository is a central file storage location. It is used by version control systems to store multiple versions of files. While a repository can be configured on a local machine for a single user, it is often stored on a server, which can be accessed by multiple users.

Example:- Git repository, (may be a water repository like WELL)

Reference:-  https://techterms.com/definition/repository

Version Control:-

Version control is used to manage multiple versions of computer files and programs. A version control system, or VCS, provides two primary data management capabilities. It allows users to

1) lock files so they can only be edited by one person at a time.

2) track changes to files.

Source Code:-

Every computer program is written in a programming language, such as Java, C/C++, or Perl. These programs include anywhere from a few lines to millions of lines of text, called source code.

Source code, often referred to as simply the “source” of a program, contains variable declarations, instructions, functions, loops, and other statements that tell the program how to function. Programmers may also add comments to their source code that explain sections of the code

Variable :-

Variables are used to store information to be referenced and manipulated in a computer program. It is a piece of memory that contain a data value.

It is the information to be referenced and manipulated in a computer Program. They also provide a way of labelling a data with a descriptive name, So our programs can be understand more clearly by the reader and ourselves.

It is helpful to think of variables as a container.  When you use a Variable to assign a Value use “=” symbol .

Useful Link:-  https://launchschool.com/books/ruby/read/variables

Instructions:-

The instruction is the key element in the computer as it tells the processor which action should be performed. The instructions which are to be executed are indicated in the source file and the computer goes from one instruction to the next following the instructions from top to bottom (as a file is read in sequence from top to bottom).

An instruction is generally comprised of two elements:

the operator: the action that the processor is to carry out

the operand(s): one or more pieces of data on which the operation is performed

Operator operand(s)

https://ccm.net/contents/313-programming-languages-instructions

Functions:-

A function is a block of code that performs a specific task.

Suppose, you need to create a program to create a circle and color it. You can create two functions to solve this problem:

create a circle function

create a color function

Link:- https://www.programiz.com/c-programming/c-functions

Loops:-

In computer programming, a loop is a sequence of instructions that is repeated until a certain condition is reached. An operation is done, such as getting an item of data and changing it, and then some condition is checked such as whether a counter has reached a prescribed number.

CI/CD Pipeline:-

A CI/CD Pipeline implementation, or Continuous Integration/Continuous Deployment, is the backbone of the modern DevOps environment. It bridges the gap between development and operations teams by automating the building, testing, and deployment of applications.

What do CI and CD mean?

CI, short for Continuous Integration, is a software development practice in which all developers merge code changes in a central repository multiple times a day. CD stands for Continuous Delivery, which on top of Continuous Integration adds the practice of automating the entire software release process.

With CI, each change in code triggers an automated build-and-test sequence for the given project, providing feedback to the developer(s) who made the change. The entire CI feedback loop should run in less than 10 minutes.

Continuous Delivery includes infrastructure provisioning and deployment, which may be manual and consist of multiple stages. What’s important is that all these processes are fully automated, with each run fully logged and visible to the entire team. Reference :– https://semaphoreci.com/blog/cicd-pipeline

With All these small information Let’s begin to learn Terraform 🙂

TERRAFORM(A Big Word)

Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. Terraform can manage existing and popular service providers as well as custom in-house solutions. Configuration files describe to Terraform the components needed to run a single application or your entire datacentre.

Basically this tools helps deploying the infrastructure resources in one go. Azure Engineers can relate this with ARM Template, AWS engineers can relate the with AWS CLI/cloud formation. However both of the tools and method are different but concept behind this is same is TO AUTOMATE THE ENTIRE INFRASTRUCTURE WITH AN EASE WITHOUT ANY MUCH OF MANUAL INTERVENTION.

Reference Link :-

https://www.terraform.io/intro/index.html

YES TERRAMATE THAT..

We all know that there is Race going on between the Cloud Vendors and all of them uses it.  There are so many in the market. Try to get a grip in any one of those.

AWS CloudFormation. …

Puppet. …

Ansible. …

Chef. …

Kubernetes. …

Terraform. …

Google Cloud Deployment Manager. …

Microsoft Azure Automation.

However let’s not distract ourselves from our main agenda TERRAFORM.

There are many cloud providers actually using this Automation masterpiece. Like Azure, AWS, Google itself. Whole point of talking boils down to this is that, Terraform will never let you down in current market situation. LEARN and GROW.

WHAT IS TERRAFORM’s BASE OR SOURCE ?

Terraform has started by HCL , I mean not a company but HASHICORP CONFIGUARTION LANGUAGE. It is small domain specific language which is based on JSON. The hashicorp team has removed some language specific add-ons to make it more productive .

SNEAK PEEK

resource “azurerm_redis_cache” “sample” {

  name                = “tf-redis-basic”

  location            = “${azurerm_resource_group.test.location}”

  resource_group_name = “${azurerm_resource_group.test.name}”

  capacity            = 0

  family              = “C”

  sku_name            = “Basic”

  enable_non_ssl_port = “${var.redis_enable_non_ssl}”

  tags                = “${local.all_tags}”

}

So we have covered a basics of what is Terraform and How it looks . It is time to know more what Terraform offers.

COMMANDS ON TERRAFORM-

TERRAFORM PLAN:–   it does not make any changes to your real Azure/AWS resources. It is used to create an execution plan. Terraform performs a refresh, unless explicitly disabled, and then determines what actions are necessary to achieve the desired state specified in the configuration files.

For example, terraform plan might be run before committing a change to version control, to create confidence that it will behave as expected.

TERRAFORM APPLY:-     The terraform apply command is used to apply the changes required to reach the desired state of the configuration, or the pre-determined set of actions generated by a terraform plan execution plan. There are many CLI Commands which we need to go through, Like Console, destroy, env, fmt, force-unlock, get, graph, init, output. Here is the reference Link :-   https://www.terraform.io/docs/commands/index.html

How to Perform a Terraform Installation (windows)?

  •  you can install Terraform manually. You can install Terraform by downloading the binary and adding it to the system path environment variable.
  • Make a folder on your C:\ drive where you can put the Terraform executable.
  • After the  download finishes, go find it in File Explorer. Extract the zip file to the folder you created in step 2.
  • Open your Start Menu and type in “environment” and the first thing that comes up should be Edit the System Environment Variables option. Click on that and you should see this window.

   Click on Environment Variables… at the bottom and you’ll see this:

  • Under the bottom section where it says System Variables, find one called Path and click edit. You’ll then see a list of where to find the binaries that Windows might need for any given reason.
  •   Click New and add the folder path where terraform.exe is located to the bottom of the list. It should look like this when you finish.

Click OK to save your changes and then click OK to exit the Environment Variables windows. Then click OK again to exit the System Properties window

  • To verify your installation and check the version, launch Windows PowerShell and enter: terraform -version.
  • You’ll see the Terraform version displayed in the output. For example: Terraform v0.11.8

Download the Terraform Modules

To get started creating infrastructure components in Oracle Cloud Infrastructure using Terraform, download the Terraform modules.

  1. Use Git or a web browser to clone or download the Terraform modules on your local system. Click Download Code in the left navigation for the link to the Git repository.
  2. Unzip or extract the Terraform modules to any folder on your local system.
  3. Launch Windows PowerShell and navigate into the folder where your Terraform modules are located. Enter terraform init.
  4. Terraform initialises the modules along with the provider plugin. When initialisation is complete, you’ll see the message Terraform has been successfully initialised!

Thanks All reaching here at the bottom of the page, We have successfully installed Terraform in Windows. Stay tuned for more gathering on Terraform I would come up with whole new section combining all Terraform knowledge in one place.

Design a site like this with WordPress.com
Get started