Notes.txt

Create high quality terraform content



	-------------------
Infrastructure as Code (IaC) 
	Process of managing and provisioning the complete IT infrastructure 
	(comprises both physical and virtual machines) 
		using machine-readable definition files. 
	Automate environment provisioning process.
	Ease maintenance of the environment.
	Manage the source code of it in SCM.


Challenges with Infrastructure as Code :
	Need to learn to code
	Don’t know the change impact.
	Need to revert the change
	Can’t track changes
	Can’t automate a resource
	Multiple environments for infrastructure
	Terraform has been created to solve these challenges.


Terraform introduction	
----------------------
What is Terraform?
	Open-source infrastructure as Code 
	Developed by HashiCorp. 
	Used to define and provision the complete infrastructure 
	Declarative language.

	Infrastructure provisioning tool 
	Cloud infrastructure setup as codes. 
	Similar to tools like CloudFormation
		However provider independent.
	
	
Adv. of Terraform
	Does orchestration, not just configuration management
	Supports multiple providers such as AWS, Azure, GCP, DigitalOcean and many more
	Provide immutable infrastructure where configuration changes smoothly
	Uses easy to understand language, HCL (HashiCorp configuration language)
	Easily portable to any other provider
	Supports Client only architecture, so no need for additional configuration management on a server


References: D:\PraiseTheLord\HSBGInfotech\DevOps\Terraform\TerraformTOC.txt

Understanding terraform

	Terraform Providers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	https://github.com/vilasvarghese/terraform-tutorial/blob/master/2e_Providers/providers.tf

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


The Core Terraform Workflow


The core Terraform workflow has three steps:
    Write - Author infrastructure as code.
    Plan - Preview changes before applying.
    Apply - Provision reproducible infrastructure.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Terraform core commands
	terraform init
	terraform validate
	terraform plan 
	terraform apply
	terraform destroy
	
	init

		Initialize a working directory
		First command in workflow
		Downloads plugins specific to the provider
	validate
		Verifies the 
			syntax 
			consistency 
				of the configuration.
	plan
		Creates execution plan
		Performs a refresh and determines what action to performance
		
		Compare .tfstate to current state 
		compare your changes with current state and above state
		create the plan (order of execution)
		display all the delta to us.
		
	apply
		Again executes the plan (unless we have persisted)
		CRUD of infrastructure
	destroy
		Destroy infrastructure.

	

	
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	
How Terraform Works With Plugins
https://www.terraform.io/docs/extend/how-terraform-works.html
	Terraform
		tool for building, changing, and versioning infrastructure 
			safely and efficiently. 
		built on a plugin-based architecture
		enable capabilities using  plugins.

	Terraform 
		logically split into two main parts: 
			Terraform Core and 
			Terraform Plugins. 
	Terraform Core 
		The primary responsibilities of Terraform Core :
			Infrastructure as code: 
				reading and interpolating configuration files and modules
			Resource state management
			Construction of the Resource Graph
			Plan execution
			Communication with plugins over RPC
				offers multiple ways to discover and load plugins
			high-level framework that abstracts plugin discovery and RPC communication	
		Includes statically-compiled binary CLI
			written in Go 
			entrypoint for anyone using Terraform. 
			open source code 
				github.com/hashicorp/terraform.
		
	Terraform Plugins 
		expose an implementation for a specific 
			service provider e.g. AWS, or 
			provisioner e.g. bash.

		written in Go 
		executable binaries invoked by Terraform Core over RPC. 
		Each plugin exposes an implementation for a specific 
			service e.g. AWS, or 
			provisioner, e.g. bash. 
		All Providers and Provisioners used in Terraform configurations are plugins. 
			Provider:
				Actual service with which we want to provision resources
				e.g. create ec2 instance
			Provisioners:
				execute scripts on a local or remote machine as part of resource creation
				e.g. install java on an ec2 instance
		Executed as a separate process 
		communicate with the main Terraform binary over an RPC interface. 
		Terraform has several Provisioners built-in
		Providers are discovered dynamically as needed 
		 so developers do not need to manage either.
		»The primary responsibilities of Provider Plugins are:
			Initialization of any included libraries used to make API calls
			Authentication with the Infrastructure Provider
			Define Resources that map to specific Services
	
	
		
	
	
Terraform Lifecycle
-------------------
	Terraform lifecycle consists of – 
		#validate: validates the syntax
		init, 
		plan, 
		apply
		destroy.

	
	Terraform init 
		initializes the working directory which consists of all the configuration files
	Terraform plan 
		creates an execution plan to reach a desired state of the infrastructure. Changes in the configuration files are done in order to achieve the desired state.
		This is optional
	Terraform apply 
		Makes the changes in the infrastructure as defined in the plan, and the infrastructure comes to the desired state.
	Terraform destroy 
		delete all the old infrastructure resources, which are marked tainted after the apply phase.
	
	
Terraform Core
---------------
Terraform core 
	uses two input sources to do its job.
	first input source 
		User configured Terraform configuration 
		define what needs to be created or provisioned. 
	second input source 
		state where terraform keeps the current state.

	Utility which can calculate the delta between the current state and the desired state - 
		make/apply these changes on the infrastructure.
	
	terraform core 
		takes the input
		figures out the plan of what needs to be done. 
		Compares current 
			state and configuration 
		with 
			desired state and configuration 
		
		Figures out plan to get to that desired state. 
		i.e. what needs to be 
			created
			updated
			deleted 
				to provision the infrastructure.

	CRUD: create, read, update and delete
	
Providers
---------
Second component of the architecture 
could be cloud providers like 
	AWS, 
	Azure, 
	GCP
	other infrastructure as service platform. 
	It is also a provider for more high-level components like Kubernetes or other platform-as-a-service tools, even some software as a self-service tool.

Supports
	For example – 
		create an AWS infrastructure
		deploy Kubernetes on top of it 
		create services/components inside that Kubernetes cluster.

Terraform has 
	over a hundred providers 
	different technologies
	each provider then gives terraform user access to its resources. 
	For e.g. AWS provider
		gives access to hundreds of AWS resources 
			like EC2 instances
			AWS users, etc. 
		With Kubernetes provider
			access to commodities resources like services and deployments and namespaces, etc.	

Further reference: https://geekflare.com/terraform-for-beginners/


HCL
---
Low-level syntax of Terraform language 
	defined in HCL (HashiCorp configuration language)
	also used by configuration languages in other applications
		particular other HashiCorp products. 
	
	Full definition of HCL syntax can be seen in https://github.com/hashicorp/hcl/blob/hcl2/hclsyntax/spec.md
	
	Includes
		Arguments
		Blocks
		Identifiers
		Comments
	
	
	
Arguments
---------
An argument assigns a value to a particular name:
	image_id = "abc123"

Syntax is like 	
	argument name / identifier =  argument's value.
	
	Terraform uses the word "attribute" instead of "argument".
	 
	Blocks
	------
	A block is a container for other content:

	} 


	Syntax 
	<block type> <parameters> {
		key1 = value1
		key2 = value2
	}
		Block
		-----
		Block options
			resource
			provider
			terraform 
			settings
			input variables - variable
			output  - output
			data sources - data
			ect.
			
		Types of block
			Top level
			Block inside block

	Defined in curly braces.
	Has key value pair
	Defines 
		an infrastructure platform
		a set of resources with in that we want to create/manage
		
	
	e.g. we want to create a file
	mkdir temp
	cd temp
	
	
	 Identifiers
	 ----------
	 In key = value
	 key - identifier
	 value - argument value
		Arguments
			Mandatory arguments
			Optional arguments
			Meta arguments 
	 
	  Comments
	  Character Encoding and Line Endings 
	
	
	Comments
	--------
	//single line
	/*
		multi-line comment
	*/
-------------------------------------
Terraform Resources

vi local.tf

<block type> "<block label>" "Block Name" {
	#Block body
	<Identifier> = <Expression> #Argument
}

resource "local_file" "vilas"{
	filename = "/root/vilas.txt"
	content = "My name is Vilas"
}
-------------------------------------	
This is a standard terraform block because the look and curly braces.
type of block : resource
	defined by terraform
local_file: resource type
	fixed value
	depends on the provider
	provides two information 
		seperated by "_"
		first: provider 
		second: type of resource
"vilas": resource name. variable name - other syntax 
	Logical name
	Can be named anything.
{Arguments}
	Specific to type of resource we are creating.
	Here specific to local_file.
	filename: absolute path to the location where we want to create file.
	content: content which should be in the file.
	arguments vary based on the resource type.
	We should follow the standard defined by the resource type.
	
-------------------------------------	

resource "aws_instance" "example" {
  ami = "abc123"

  network_interface {
	# ...
  }
}

type: resource
provider: aws
require: EC2 instance
example: name
ami: ami of the instance
network_interface: network interface for the instance
-------------------------------------	
Update local.tf

vi local.tf

resource "local_file" "vilas"{
	filename = "/root/vilas.txt"
	content = "My name is Vilas!!"
	file_permission = "0700"
}
-------------------------------------	
terraform apply 

terraform will delete and create a new file.


-------------------------------------	

terraform init
	executed from a directory with terraform configurations
	terraform downloads and installs plugins for provider used in the configuration.
	shows the version of the plugin installed
		more on plugins latter
		
	
	
Providers
---------
	can be 
		cloud providers
			aws
			azure
			gcp ect.
		local providers
		ect.
	Distributed by HashiCorp
	Publicly available in the Terraform registry
		registry.terraform.io
	3 tiers of providers
		1. Owned and maintained by HashiCorp
			e.g. 
			aws
			azure
			gcp .
			local providers
			regirsty.hashicorp.io
		2. Verified provider
			Owned and maintained by 3rd party provider company
				Company in partnership with HashiCorp
				
			e.g. 
				bigip provider from FI network
				heroku
				digitalocean
		3. Community providers
			Published and maintained by individual community providers of HashiCorp community.
				activedirectory
				ucloud
				netapp-gcp

Terraform uses a plugins based architecture
	to work with 100's of infrastructure platforms
	
Plugins
-------
	Terraform init downloads and installs plugins
	Provider specific.
	Installed into a <directory>/.terraform/
	<directory>
		directory where terraform configuration files are present.
		Generate terraform init is executed being here.
	plugin name : source address
		e.g. hashicorp/local
		can be seen while executing terraform init.
		indentifier to locate and download pluigns
		hashicorp: organizational namespace
		local: type - provider name
			can be 
				aws
				azure
				rm
		plugin name can have a host name 
		registy.terraform.io/hashicorp/local
		
		
--------------------------------------------------------------------------------------------
		
Configuration Directory
-----------------------
	Directory can have any number of configuration files.
	Any file with .tf extension will participate in CRUD of the infrastructure components.
	One file may have any number of configuraiton blocks.
	Common naming convention: main.tf, terraform.tfvars, providers.tf, output.tf and variables.tf
	
	Common other files found
		main.tf - main configuration
		variables.tf - variables delclaration
		outputs.tf - outputs from resources.
		providers.tf - define providers
		
			can be .tf.json also - but commonly used.

Multiple Providers
------------------
	Terraform supports working with multiple providers
		e.g. random
			can produce
				random_id
				random_password
				random_int
				random_string
				ect.
		
	
	
Further reference: https://www.youtube.com/watch?v=YcJ9IeukJL8

Find 	
az account list-locations -o table


Core concepts/terminologies used in Terraform:
---------------------------------------------
	Variables
		Input-variables
			like function arguments	
		Output variables
			like function return values
		Local values 
			like a function's temporary local variables.
			
    Input-variables:
		Also called 
			Variables 
			Terraform variables
		key-value pair 
		used by Terraform modules to allow customization.
		Serve as parameters for a Terraform module
		module can be customized without altering the module's own source code
		modules can be reused between different configurations.
		While declaring variables in the root module of your configuration
			you can set their values using CLI options and environment variables. 
		While declaring variables in child modules
			the calling module should pass values in the module block.
	
	Output Variables
		id of a resource


    Module: 
		Folder with Terraform templates 
		all the Terraform configurations are defined here
		Similar to function definitions in traditional languages
    State: 
		Consists of cached information about the infrastructure managed by Terraform and the related configurations.
    Resources: 
		It refers to a block of one or more infrastructure objects 
			compute instances
			virtual networks, etc.
			used in configuring and managing the infrastructure.
    Data Source: 
		Implemented by providers to return information on external objects to terraform.
		We can define our own data sources - which reads data from existing resources and returns it to us for use in terraform.
		e.g. get ami id in aws.
    Output Values: 
		Return values of a terraform module that can be used by other configurations.
    Plan: 
		One of the stages 
		Determines what needs to be 
			created, 
			updated, or 
			destroyed to move from 
				real/current state of the infrastructure --> desired state.
    Apply: 
		One of the stages 
		Applies the changes real/current state of the infrastructure in order to move to the desired state.

	Destroy
		Removes all configurations applied as defined in the module

	

	Variables 
	---------
	Declaring an Input Variable

Each input variable accepted by a module must be declared using a variable block:

------------------------------------------------------
variable "image_id" {
  type = string
}

variable "availability_zone_names" {
  type    = list(string)
  default = ["us-west-1a"]
}

variable "docker_ports" {
  type = list(object({
    internal = number
    external = number
    protocol = string
  }))
  default = [
    {
      internal = 8300
      external = 8300
      protocol = "tcp"
    }
  ]
}
------------------------------------------------------

	The label 
		after the variable keyword 
		like a variable in the function.
		name for the variable (image_id e.g.)
		must be unique among all variables with in a module. 
		name used to 
			assign a value to the variable from outside 
			reference the variable's value from within the module.

		can be any valid identifier except the following: 
			source, 
			version, 
			providers, 
			count, 
			for_each, 
			lifecycle, 
			depends_on, 
			locals.
		These names are reserved for meta-arguments in module configuration blocks
		cannot be declared as variable names.
	
	Like other blocks, variable also supports attributes
	Following optional arguments for variable declarations:

		default - 
			default value 
			If present, the variable is considered to be optional
			default value will be used if no value is set 
			Should be a literal value 
			cannot reference other objects in the configuration.
		type - 
			define type of variable.
			allows you to restrict the type of value 
			type constraints are optional
			recommend specifying them
			If no type constraint is set 
				then a value of any type is accepted.
			Advantages
				helpful reminders for users
				Terraform can return a helpful error message if the wrong type is used.

			e.g. Supported type keywords (value) are:
				string
				number
				bool
				any
					keyword any 
					indicate that any type is acceptable.

			The type constructors allow you to specify complex types such as collections:
				list(<TYPE>)
				set(<TYPE>)
				map(<TYPE>)
				object({<ATTR NAME> = <TYPE>, ... })
				tuple([<TYPE>, ...])

			If both the type and default arguments are specified, 
				the given default value must be convertible to the specified type.
		
		
		description - 
			description.
			
			Input Variable Documentation


			variable "image_id" {
			  type        = string
			  description = "The id of the machine image (AMI) to use for the server."
			}

			Concisely explain the 
				purpose of the variable 
				what kind of value is expected. 
				Might be included in documentation 
				writte from the perspective of the user and not dev.
			
		validation - 
			A block 
			define validation rules
			usually in addition to type constraints.
			
			
			
			Custom Validation Rules
				Feature introduced in Terraform CLI v0.13.0.
				Module author can specify custom validation rules 
				use validation block nested within the corresponding variable block:
--------------------------------------------------------------------------------------
variable "image_id" {
  type        = string
  description = "The id of the machine image (AMI) to use for the server."

  validation {
    condition     = length(var.image_id) > 4 && substr(var.image_id, 0, 4) == "ami-"
    error_message = "The image_id value must be a valid AMI id, starting with \"ami-\"."
  }
}
--------------------------------------------------------------------------------------


			condition argument 
				expression must use the value of the variable to return 
					true if the value is valid
					false if it is invalid. 
				expression can refer only to the variable that the condition applies to
				expression must not produce errors.

			If the failure of an expression is the basis of the validation decision, 
				use the can function to detect such errors. For example:

			variable "image_id" {
			  type        = string
			  description = "The id of the machine image (AMI) to use for the server."

			  validation {
				# regex(...) fails if it cannot find a match
				condition     = can(regex("^ami-", var.image_id))
				error_message = "The image_id value must be a valid AMI id, starting with \"ami-\"."
			  }
			}

			If condition evaluates to false
				Terraform will produce an error message 
					includes the sentences given in error_message. 
			The error message string should be at least one full sentence explaining the constraint that failed
			
			
			
			
		
---------------------------			
		sensitive - 
			Limits Terraform UI output when the variable is used in configuration.	
			
			»
			Suppressing Values in CLI Output
			--------------------------------
				Feature was introduced in Terraform v0.14.0.

				Hands-on: Try the Protect Sensitive Input Variables tutorial on HashiCorp Learn.

				Setting a variable as sensitive prevents Terraform from showing its value in the plan or apply output
					when you use that variable elsewhere in your configuration.

				Terraform will still record sensitive values in the state
				anyone who can access the state data will have access to the sensitive values in cleartext. 
				
			Declare a variable as sensitive by setting the sensitive argument to true:

			variable "user_information" {
			  type = object({
				name    = string
				address = string
			  })
			  sensitive = true
			}

			resource "some_resource" "a" {
			  name    = var.user_information.name
			  address = var.user_information.address
			}

			Any expressions whose result depends on the sensitive variable will be treated as sensitive 
			so in the above example 
				"some_resource" "a" will also be hidden in the plan output:

			Terraform will perform the following actions:

			  # some_resource.a will be created
			  + resource "some_resource" "a" {
				  + name    = (sensitive)
				  + address = (sensitive)
				}

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

			In some cases where you use a sensitive variable inside a nested block, Terraform may treat the entire block as redacted. This happens for resource types where all of the blocks of a particular type are required to be unique, and so disclosing the content of one block might imply the content of a sibling block.

			  # some_resource.a will be updated in-place
			  ~ resource "some_resource" "a" {
				  ~ nested_block {
					  # At least one attribute in this block is (or was) sensitive,
					  # so its contents will not be displayed.
					}
				}

			A provider can also declare an attribute as sensitive, which will cause Terraform to hide it from regular output regardless of how you assign it a value. For more information, see Sensitive Resource Attributes.

			If you use a sensitive value from as part of an output value then Terraform will require you to also mark the output value itself as sensitive, to confirm that you intended to export it.
			»
			Cases where Terraform may disclose a sensitive variable

			A sensitive variable is a configuration-centered concept, and values are sent to providers without any obfuscation. A provider error could disclose a value if that value is included in the error message. For example, a provider might return the following error even if "foo" is a sensitive value: "Invalid value 'foo' for field"

			If a resource attribute is used as, or part of, the provider-defined resource id, an apply will disclose the value. In the example below, the prefix attribute has been set to a sensitive variable, but then that value ("jae") is later disclosed as part of the resource id:

			  # random_pet.animal will be created
			  + resource "random_pet" "animal" {
				  + id        = (known after apply)
				  + length    = 2
				  + prefix    = (sensitive)
				  + separator = "-"
				}

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

			...

			random_pet.animal: Creating...
			random_pet.animal: Creation complete after 0s [id=jae-known-mongoose]

			»
			Using Input Variable Values

			Within the module that declared a variable, its value can be accessed from within expressions as var.<NAME>, where <NAME> matches the label given in the declaration block:

			Note: Input variables are created by a variable block, but you reference them as attributes on an object named var.

			resource "aws_instance" "example" {
			  instance_type = "t2.micro"
			  ami           = var.image_id
			}

			The value assigned to a variable can only be accessed in expressions within the module where it was declared.
			»
			Assigning Values to Root Module Variables

			When variables are declared in the root module of your configuration, they can be set in a number of ways:

				In a Terraform Cloud workspace.
				Individually, with the -var command line option.
				In variable definitions (.tfvars) files, either specified on the command line or automatically loaded.
				As environment variables.

			The following sections describe these options in more detail. This section does not apply to child modules, where values for input variables are instead assigned in the configuration of their parent module, as described in Modules.
			»
			Variables on the Command Line

			To specify individual variables on the command line, use the -var option when running the terraform plan and terraform apply commands:

			terraform apply -var="image_id=ami-abc123"
			terraform apply -var='image_id_list=["ami-abc123","ami-def456"]' -var="instance_type=t2.micro"
			terraform apply -var='image_id_map={"us-east-1":"ami-abc123","us-east-2":"ami-def456"}'

			The above examples show appropriate syntax for Unix-style shells, such as on Linux or macOS. For more information on shell quoting, including additional examples for Windows Command Prompt, see Input Variables on the Command Line.

			You can use the -var option multiple times in a single command to set several different variables.

			»
			Variable Definitions (.tfvars) Files

			To set lots of variables, it is more convenient to specify their values in a variable definitions file (with a filename ending in either .tfvars or .tfvars.json) and then specify that file on the command line with -var-file:

			terraform apply -var-file="testing.tfvars"

			Note: This is how Terraform Cloud passes workspace variables to Terraform.

			A variable definitions file uses the same basic syntax as Terraform language files, but consists only of variable name assignments:

			image_id = "ami-abc123"
			availability_zone_names = [
			  "us-east-1a",
			  "us-west-1c",
			]

			Terraform also automatically loads a number of variable definitions files if they are present:

				Files named exactly terraform.tfvars or terraform.tfvars.json.
				Any files with names ending in .auto.tfvars or .auto.tfvars.json.

			Files whose names end with .json are parsed instead as JSON objects, with the root object properties corresponding to variable names:

			{
			  "image_id": "ami-abc123",
			  "availability_zone_names": ["us-west-1a", "us-west-1c"]
			}

			»
			Environment Variables

			As a fallback for the other ways of defining variables, Terraform searches the environment of its own process for environment variables named TF_VAR_ followed by the name of a declared variable.

			This can be useful when running Terraform in automation, or when running a sequence of Terraform commands in succession with the same variables. For example, at a bash prompt on a Unix system:

			$ export TF_VAR_image_id=ami-abc123
			$ terraform plan
			...

			On operating systems where environment variable names are case-sensitive, Terraform matches the variable name exactly as given in configuration, and so the required environment variable name will usually have a mix of upper and lower case letters as in the above example.
			»
			Complex-typed Values

			When variable values are provided in a variable definitions file, you can use Terraform's usual syntax for literal expressions to assign complex-typed values, like lists and maps.

			Some special rules apply to the -var command line option and to environment variables. For convenience, Terraform defaults to interpreting -var and environment variable values as literal strings, which need only shell quoting, and no special quoting for Terraform. For example, in a Unix-style shell:

			$ export TF_VAR_image_id='ami-abc123'

			However, if a root module variable uses a type constraint to require a complex value (list, set, map, object, or tuple), Terraform will instead attempt to parse its value using the same syntax used within variable definitions files, which requires careful attention to the string escaping rules in your shell:

			$ export TF_VAR_availability_zone_names='["us-west-1b","us-west-1d"]'

			For readability, and to avoid the need to worry about shell escaping, we recommend always setting complex variable values via variable definitions files. For more information on quoting and escaping for -var arguments, see Input Variables on the Command Line.
			»
			Values for Undeclared Variables

			If you have defined a variable value, but not its corresponding variable {} definition, you may get an error or warning depending on how you have provided that value.

			If you provide values for undeclared variables defined as environment variables you will not get an error or warning. This is because environment variables may be declared but not used in all configurations that might be run.

			If you provide values for undeclared variables defined in a file you will get a warning. This is to help in cases where you have provided a variable value meant for a variable declaration, but perhaps there is a mistake in the value definition. For example, the following configuration:

			variable "moose" {
			  type = string
			}

			And the following .tfvars file:

			mosse = "Moose"

			Will cause Terraform to warn you that there is no variable declared "mosse", which can help you spot this mistake.

			If you use .tfvars files across multiple configurations and expect to continue to see this warning, you can use the -compact-warnings option to simplify your output.

			If you provide values for undeclared variables on the command line, Terraform will error. To avoid this error, either declare a variable block for the value, or remove the variable value from your Terraform call.
			»
			Variable Definition Precedence

			The above mechanisms for setting variables can be used together in any combination. If the same variable is assigned multiple values, Terraform uses the last value it finds, overriding any previous values. Note that the same variable cannot be assigned multiple values within a single source.

			Terraform loads variables in the following order, with later sources taking precedence over earlier ones:

				Environment variables
				The terraform.tfvars file, if present.
				The terraform.tfvars.json file, if present.
				Any *.auto.tfvars or *.auto.tfvars.json files, processed in lexical order of their filenames.
				Any -var and -var-file options on the command line, in the order they are provided. (This includes variables set by a Terraform Cloud workspace.)

			Important: In Terraform 0.12 and later, variables with map and object values behave the same way as other variables: the last value found overrides the previous values. This is a change from previous versions of Terraform, which would merge map values instead of overriding them.

			


	
	
		
	
	
---------------------------------------------------------------------------------------------------------------------------------------------------------	

Skipping
	Install VSCode Editor, VS Code Terraform Plugin and AWS CLI
Windows: Install Terraform & AWS CLI on Windows
	Step-03: Configure AWS CLI
Linux: Install Terraform Windows
---------------------------------------------------------------------------------------------------------------------------------------------------------	


Terraform Workflow 
	using Terraform Commands

AMI ID and Region
Terraform core commands
Terraform Configuration Syntax
Terraform Arguments, Meta-Arguments and Attributes
Blocks in Terraform
	Terraform Top Level Blocks
	Terraform fundamental block
	Terraform Settings Block Introduction
	required_version in Terraform Block
	required_providers in Terraform Block

Terraform Providers 
	Understand about Provider Block
	Create VPC Resource, Test and Clean-Up
	Terraform Multiple Providers and clean up
	Terraform Provider Dependency Lock File 

	Create S3 bucket with existing Lock File AWS provider version
	Upgrade AWS Provider, Test, Fix S3 Bucket Issues and Clean-Up



Resources
	Terraform Resources Syntax Introduction
	Terraform Resources Behavior Part-1
	Terraform State 
		terraform.tfstate file
	Terraform Resource 
		Update In Place
		Destroy and Recreate and Destroy
	Terraform Desired & Current State 
		Clean-Up
	Resources Meta-Arguments
		depends_on



	Create Key Pair terraform-key and also review c1-versions.tf
	Create VPC 
	Create EC2 Instance 
	Create Elastic IP 
		depends_on 
	Verify and Clean-Up VPC, EC2 Instance and Elastic IP
	Resources Meta-Argument count

	Create EC2 Instance 
		Count & 
		Count.Index and 
		Clean-Up
	Resources Meta-Argument for_each
		for_each with Maps
		for_each with Set of Strings
	Resource Meta-Argument lifecycle
	Lifecycle Meta-Argument - 
		create_before_destroy - 
		prevent_destroy 
		ignore_changes implement and test



Variables
	Terraform Input Variables Introduction
	Assign value When Prompted using CLI
	Override default value with -
		var argument
	environment vairables
	Assign with terraform.tfvars
	Assign with -var-file argument
	Assign with .auto.tfvars files
	Complex Constructor of Type List
	Complex Constructor of Type Map
	Length and SubString Functions
	Custom Validation Rules
	Sensitive Variables
	Variable Definition Precedence
	File Function
	Terraform Output Values Introduction
	Terraform Outputs Implementation
	Terraform Local Values Introduction



Datasource
	Terraform Datasources Introduction
	Create a data resource to get latest AMI ID



State

Terraform STATE 
Remote State Storage Introduction
Configure AWS S3 as Terraform Backend for Remote State Storage

Implement State Locking using AWS DynamoDB
Understand Terraform internals
Terraform commands
	Terraform refresh command
	Terraform state command - 
		List, 
		Show  
		mv
		rm 
		replace provider
		pull, 
		push 
		force-unlock
		Clean-Up
	Terraform taint and untaint commands
	Terraform plan or apply -target command




Workspaces
	Review / Create Terraform Manifests to support multiple workspaces
	Local Backend: 
		Create Resources in default workspace
		Create Resources in new workspace
		Switch and Delete non-default workspaces
		Remote Backends with Workspaces

Creating a typical aws network of resources using terraform
Create EC2 Instances using Terraform Modules
Create Outputs 
Taint resources in modules and clean-up
Create S3 such that it is accessible from EC2 instance created.
Create Re-usable Terraform Module


	IAM - users and roles
	EC2, EBS
	Docker (Redis & MySQL)
	VPC (public and private subnets)
	NACL, SG (Security Group)
	S3 (with VPC endpoint & RT entry for the endpoint)
	Cloud Trail, Event Bridge
	Cloud Watch (log group expiry, contributor insights)
	DynamoDB (with VPC Endpoint & RT entry for the endpoint)
	Lambda (Frontend, backend, scheduled, asynch)
	SES, SNS, SQS
	Budgets


AWS CLI (ssh scripts, db backup script)




Terraform Debug

Include the below
https://datafloq.com/read/terraform-benefits-use-cases/11354
https://www.hashicorp.com/resources/terraforming-real-world-experience-best-practices

https://github.com/wardviaene/terraform-course
https://github.com/hashicorp/tfc-guide-example
https://github.com/terraform-aws-modules/terraform-aws-eks
https://github.com/collabnix/terraform
https://github.com/LinkedInLearning/advanced-terraform-2823489


Business expectation
	https://www.plutora.com/blog/infrastructure-as-code
	https://sensu.io/blog/infrastructure-as-code-evolution-and-practice
	https://superadmins.com/infrastructure-as-code-demystified-iac-benefits-challenges-best-practices/

Challenges of Terraform
https://www.terraform.io/docs/cloud/guides/recommended-practices/part1.html

Recommended practices
https://www.terraform.io/docs/cloud/guides/recommended-practices/index.html

Internet Gateway/Router
VPC Peering

https://www.slideshare.net/wlscaudill/aws-network-topologyarchitecture

https://github.com/cloudposse/terraform-aws-efs
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_bucket
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/ebs_volume

IaC
Consistency
Terraform feeding to configuration
Security expectation
Performance expectation
High availability expectation
Dev/prod parity



file:///D:/PraiseTheLord/HSBGInfotech/DevOps/Terraform/terraform-modules.pdf
file:///D:/PraiseTheLord/HSBGInfotech/DevOps/Terraform/terraform-Deep-dive-with-no-fear.pdf

Scaling
	https://dzone.com/articles/managing-infrastructure-at-scale-with-terraform
	https://www.brighttalk.com/webcast/13895/436834/how-to-scale-your-infrastructure-using-terraform
	
	https://www.hashicorp.com/resources/scaling-with-terraform-startup-enterprise
	https://www.singlestoneconsulting.com/blog/terraform-iac-at-enterprise-scale/
	https://medium.com/manomano-tech/managing-a-terraformed-infrastructure-at-scale-a-feedback-43e4675e5769

Cost	
	https://github.com/antonbabenko/terraform-cost-estimation
	https://www.ionos.com/digitalguide/server/tools/what-is-terraform/
	
Adv. IaC
	https://bluesentryit.com/benefits-of-infrastructure-as-code/
	https://superadmins.com/infrastructure-as-code-demystified-iac-benefits-challenges-best-practices/
	
Idemopotency
	https://shahadarsh.com/2020/07/12/principles-patterns-and-practices-for-effective-infrastructure-as-code/
	https://stackoverflow.com/questions/51495993/terraform-how-do-you-make-a-resource-idempotent-i-e-create-if-not-exists-but
	
Configuration drift
	https://www.hashicorp.com/blog/detecting-and-managing-drift-with-terraform
	https://newcontext.com/managing-terraform-configuration-drift/
	
Terraform in IaC
	https://medium.com/workfall/how-to-manage-infrastructure-as-code-iac-with-terraform-on-aws-1fa6cd6bccfe
	https://aviatrix.com/learn-center/cloud-networking/terraform-and-infrastructure-as-code/
	https://blog.knoldus.com/infrastructure-as-code-using-terraform/
	https://www.toptal.com/devops/terraform-aws-cloud-iac


Terraform with configuration mgmt
	https://victorops.com/blog/writing-ansible-playbooks-for-new-terraform-servers
	https://www.digitalocean.com/community/tutorials/how-to-use-ansible-with-terraform-for-configuration-management
	https://www.cprime.com/resources/blog/terraform-and-ansible-tutorial-integrating-terraform-managed-instances-with-ansible-control-nodes/
	
Security 
	https://bridgecrew.io/infrastructure-as-code-security/terraform/
	https://www.hashicorp.com/blog/using-terraform-to-improve-infrastructure-security
	https://www.datocms-assets.com/2885/1598300367-tfc4bsecuritybriefv2.pdf
	https://blog.gitguardian.com/security-in-infrastructure-as-code-with-terraform/
	https://support.snyk.io/hc/en-us/articles/360010916577-Scan-and-fix-security-issues-in-your-Terraform-files
	
---------------------------------------------------------------------------------------------------------------------------------------------------------	
Skipping
Provisioners and Null resources

Step-02: Implement Connection Block for File Provisioners & Review Manifests
Step-03: File Provisioner: Execute Terraform Commands to Verify
Step-04: Learn Provisioner failure behavior using onfailure=continue
Step-05: remote-exec Provisioner Demo
Step-06: local-exec Provisioner Demo
Step-07: Terraform Null Resource Introduction & Review Manifests
Step-08: Null Resource - Execute Terraform Commands and Test





Modules







Cloud and enterprise capabilities


Introduction to Terraform Cloud VCS Integration
Step-02: Setup Github Repository Local & Remote
Step-03: Create Terraform Organization, Workspace and Input Variables
Step-04: Set Environment Variables in Terraform Cloud
Step-05: Understand Queue Plan & also check-in changed files to git and observe
Step-06: Understand Workspace Settings and Destroy Resources using TF Cloud
Step-07: Introduction to Private Modules Registry
Step-08: Create Github Repo for a Private Module
Step-09: Add VCS Provider as Github using OAuth App in TF Cloud
Step-10: Import Terraform Module from Github and Review
Step-11: Call from Root Module using CLI and Test
Step-12: Introduction to Terraform Cloud CLI-Driven Workflow
Step-13: Create TF Cloud Workspace with CLI-Driven Workflow
Step-14: Execute Terraform Commands & Fix Provider credentials issue
Step-15: Review terraform manifests and provision using local backend
Step-16: Migrate State to Terraform Cloud


Cloud sentinels

Step-02: Review Terraform Manifests used as part of this Demo
05:05
Step-03: Understand Terraform Free and Paid Plan Features and Enable Trial for T
07:04
Step-04: Create CLI-Driven Workspace in Terraform Cloud
09:54
Step-05: Review Sentinel Policy: Check Terraform Version
10:10
Step-06: Review Sentinel Policy: Restrict S3 Buckets
13:20
Step-07: Review sentinel.hcl file where we reference policies
05:25
Step-08: Create Github Repo for Sentinel Policies and Policy Sets in TF Cloud
07:17
Step-09: Test Sentinel Policies - Passing case
07:16
Step-10: Test Sentinel Policies - Failing case
08:13
Step-11: Review Sentinel Cost Control Policies and Publish to Git Repo
07:36
Step-12: Add Policy Set and Test Pass and Failed cases with terraform-cloud-demo
11:26
Step-13: Review Sentinel CIS Policies and Publish to Git Repo
07:16
Step-14: CIS: Add Policy Set and Test with terraform-cloud-demo1 workspace



Import

Step-01: Terraform State Import Introduction
03:51
Step-02: Import State using terraform command and write tf configuration for ec2
11:09
Step-03: Manage EC2 Instance using Terraform for Modify and Destroy commands fro
05:28
Step-04: Terraform Import - S3 Bucket Demo


Graph

ep-01: Terraform Graph Implementation
05:00
Step-02: Graphviz Offline Install on Windows and generate graphs


Expressions
Step-00: Introduction to Terraform Expressions
02:27
Step-01: Part-1: Learn various Terraform Functions using Terraform Console
12:35
Step-02: Part-2: Learn various Terraform Functions using Terraform Console
05:30
Step-03: Understand in detail about templatefile and concat functions with AWS E
06:26
Step-04: Execute Terraform Commands and view the behavior of templatefile and co
04:36
Step-05: Part-1: Review Terraform Manifests c1 to c7
11:32
Step-06: Part-2: Review Terraform Manifests c1 to c7
11:59
Step-07: Part-3: Review Terraform Manifests c1 to c7
03:39
Step-08: Execute Terraform Commands to Test Dynamic and Splat Expressions
12:46
Step-09: Terraform Dynamic Block Implementation



Debug
Step-01: Terraform Debug

---------------------------------------------------------------------------------------------------------------------------------------------------------	

---------------------------------------------------------------------------------------------------------------------------------------------------------

Introduction to IaC
	What is IaC
		Infrastructure as code, also referred to as IaC, is an IT practice that codifies and manages underlying IT infrastructure as software. The purpose of infrastructure as code is to enable developers or operations teams to automatically manage, monitor and provision resources, rather than manually configure discrete hardware devices and operating systems. Infrastructure as code is sometimes referred to as programmable or software-defined infrastructure.

		The concept of infrastructure as code is similar to programming scripts, which are used to automate IT processes. However, scripts are primarily used to automate a series of static steps that are repeated numerous times across multiple servers. Infrastructure as code uses higher-level or descriptive language to code more versatile and adaptive provisioning and deployment processes. For example, infrastructure-as-code capabilities included with Ansible, an IT management and configuration tool, can install MySQL server, verify that MySQL is running properly, create a user account and password, set up a new database and remove unneeded databases.

		The code-based infrastructure automation process closely resembles software design practices in which development teams carefully control code versions, test iterations and limit deployment until the software is proven and approved for production.

	Advantages of IaC
		Speed and efficiency. 
			Automated provisioning and management are faster and more efficient than manual processes. This stretches not just to provisioned resources and virtualization, but also to databases, networking, user account management and other tied-in services. IaC also can include code that automatically scales (adds or shuts down environments and resources when they are no longer needed).
		Consistency. 
			Software developers can use code to provision and deploy servers and applications according to business practices and policies, rather than rely on system administrators in a DevOps environment. A developer might create a configuration file to provision and deploy a new application for quality assurance or experimental deployment before operations takes over for live deployment in production.
		Alignment with DevOps.
			With the infrastructure setup written as code, it can go through the same version control, automated testing and other steps of a continuous integration and continuous delivery (CI/CD) pipeline that developers use for application code. An organization may choose to combine infrastructure as code with containers, which abstract the application from the infrastructure at the operating system level. Because the OS and hardware infrastructure are provisioned automatically and the application is encapsulated atop it, these technologies prove complementary for diverse deployment targets, such as test, staging and production.
			


	Infrastructure as code and cloud computing

		Cloud computing shares a general starting vision with infrastructure as code: IT resources such as compute, storage and networking are abstracted from physical hardware, tied to additional services, and loaded into instances that are spun up and down as needed.

		IaC takes this a step further, to automate this process through predefined sets of instructions:

			Provision resources.
			Configure the instance.
			Configure and deploy a workload into the instance.
			Connect associated services.
			Monitor and manage the deployment over time.

		This depth of automation is especially important because of the cloud's vast array of applications, services and functions, stacked together and mainly connected through APIs. The scale and scope of cloud requires an automated governed process, rather than doing everything manually. Organizations with hybrid cloud benefit even more, as such templated configurations and resources can be applied across multiple environments.

	Immutable vs. mutable infrastructure
		Mutable infrastructure refers to the practice whereby infrastructure components are changed in production, while the overall service or application continues to operate as normal. Immutable infrastructure assembles and sets components and resources to create a full service or application. If a change is required for any component, they are not changed or reconfigured -- they are all updated and effectively redeployed in an instance. A new iteration is assembled, tested, validated and launched, while the old iteration is discontinued and its resources released for reuse.

		Immutable infrastructure has gained favor particularly for cloud and microservices environments, which are highly scalable and involve many more interdependent components and services. Any one-off updates to address specific issues can cause configuration drift that cascades as updates are rapidly pushed to production. It's more efficient and effective to reissue sets of immutable services and components than to patch and reconfigure individual infrastructure components.

	Difference between IaC and Configuration Managmenet
		https://www.quora.com/What-is-the-difference-between-Infrastructure-Management-and-Configuration-Management
	
Terraform Introduction
	https://learn.hashicorp.com/tutorials/terraform/infrastructure-as-code
	https://www.terraform.io/intro/index.html
	

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~