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:-
- CLI
- Service Principal and Client Certificate.
- Service Principal and Client Secret.
- 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 :-
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.
TerraMate the Cloud 