terraform providers - ghdrako/doc_snipets GitHub Wiki

Terraform today supports multiple providers and more than 800 provider binaries. To manage these multiple provider binaries, HashiCorp would need to manage each of them. This would be difficult. Instead, HashiCorp has made the Terraform architecture an extensible architecture. This means the respective platforms provide support with Terraform core and maintain their own provider plugins and as well as life cycle of these provider plugins. Terraform offers the “provider SDK,” which is a software development kit that defines how the Terraform core interacts with the plugins that are to be written by a specific platform that wants to support Terraform. Further, to support the writing of providers (which are specific to each platform), Terraform offers “Terraform-provider- scaffolding,” which is a code repository that provides a template defining how a provider should be written. This template contains the following:

• A resource and a data source (internal/provider/)
• Examples (examples/) and generated documentation (docs/)
• Miscellaneous meta files This template provided by HashiCorp contains boilerplate code that you will need to edit to create your own Terraform provider. Once the Terraform provider is written, the platform vendor needs to publish in the Terraform registry maintained by HashiCorp so that the provider is available to a wide audience.

There are two main components of the Terraform architecture:

• the Terraform core and
• Terraform plugins. The Terraform core interacts with plugins over remote procedure calls (RPCs) and offers multiple ways to discover and load plugins for further interaction with the destination platform. It’s the Terraform plugins that enable Terraform to expose an implementation for a specific service such as support on Azure, VMware, GCP, etc.

https://registry.terraform.io/namespaces/hashicorp

• https://registry.terraform.io/providers/hashicorp/aws/latest/docs
• https://registry.terraform.io/providers/hashicorp/google/latest
• https://registry.terraform.io/providers/hashicorp/azurerm/latest

Typy:

• official - stworzeni przez hashicorp
• partner - stworzeni przez wlasciceli technologi np Alibaba Cloud - troszke gorzej udokumentowani
• Community - na podstawie sdk oferowanego przez hashicorpa przez community

• add a required_providers block to your code to specify which provider you want to use
• add a provider block to configure that provider

terraform {
  required_providers {
    <LOCAL_NAME> = {
      source = "<URL>"
      version = "<VERSION>"
    }
  }
}

• LOCAL_NAME - must give each provider a unique name, and you use that name in the provider block configuration. In almost all cases, you’ll use the preferred local name of that provider: e.g., for the AWS Provider, the preferred local name is aws, which is why you write the provider block as provider "aws" { … }

• URL - URL from where Terraform should download the provider, in the format [<HOSTNAME>/]<NAMESPACE>/<TYPE>, where HOSTNAME is the hostname of a Terraform Registry that distributes the provider, NAMESPACE is the organizational namespace (typically, a company name), and TYPE is the name of the platform this provider manages (typically, TYPE is the preferred local name). For example, the full URL for the AWS Provider, which is hosted in the public Terraform Registry, is registry.terraform.io/hashicorp/aws. However, note that HOSTNAME is optional, and if you omit it, Terraform will by default download the provider from the public Terraform Registry, so the shorter and more common way to specify the exact same AWS Provider URL is hashicorp/aws. You typically only include HOSTNAME for custom providers that you’re downloading from private Terraform Registries (e.g., a private Registry you’re running in Terraform Cloud or Terraform Enterprise).

Example

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
}

Example

provider "aws" {
  region = "us-east-2"
}

Once you’ve configured a provider, all the resources and data sources from that provider (all the ones with the same prefix) that you put into your code will automatically use that configuration. So, for example, when you set the region in the aws provider to us-east-2, all the aws_ resources to your code will automatically deploy into us-east-2.

main. tf:
terraform {
  required_version = ">= 1.0"
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "2.54.0"
    }
  }
}

# Configure the Microsoft Azure Provider
provider "azurerm" {
  features {}
  subscription_id    = "...."
  client_id          = "...."
  client_secret      = "...."
  tenant_id          = "...."
} 

Options you have when passing version values in the provider code block:

• >= 2.54.0: Greater than or equal to the version.
• = 2.54.0: Equal to the version.
• != 2.54.0: Not equal to the version.
• <= 2.54.0: Less than or equal to the version.
• ~> 2.54.0: This one is funky. It means any version in the 2.54.X range. It will always look for the rightmost version increment.
• >= 2.46, <= 2.54: Any version between 2.46 and 2.54, inclusive.

 Configure the Microsoft Azure Provider
Terraform {
  required_version = ">= 1.0"
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "2.54.0"
    }
  }  
}

provider "azurerm" {
  features {}
}

provider "azurerm" {
  features {}
  alias = "nonprod_01_subscription"
}

# To Create Resource Group in specific subscription
resource "azurerm_resource_group" "example" {
  provider = azurerm.nonprod_01_subscription
  name     = "example-resources"
  location = "West Europe"
}

Scenarios:

• Working with multiple AWS regions

provider "aws" {
  region = "us-east-2"
  alias = "region_1"
}
provider "aws" {
  region = "us-west-1"
  alias = "region_2"
}

An alias is a custom name for the provider, which you can explicitly pass to individual resources, data sources, and modules to get them to use the configuration in that particular provider.

To tell those aws_region data sources to use a specific provider, you set the provider parameter as follows: Working with Multiple Copies of the Same Provider |

data "aws_region" "region_1" {
  provider = aws.region_1
}
data "aws_region" "region_2" {
  provider = aws.region_2
}

resource "aws_instance" "region_1" {
  provider = aws.region_1
  # Note different AMI IDs!!
  ami = "ami-0fb653ca2d3203ac1"
  instance_type = "t2.micro"
}
resource "aws_instance" "region_2" {
  provider = aws.region_2
  # Note different AMI IDs!!
  ami = "ami-01f87c43e618bf8f0"
  instance_type = "t2.micro"
}
Note that the ami parameter has to be different on the two aws_instance resources: that’s because AMI IDs are unique to each AWS
region, so the ID for Ubuntu 20.04 in us-east-2 is different than for Ubuntu 20.04 in us-west-1.

• Working with multiple AWS accounts
• Creating modules that can work with multiple providers

terraform {
  required_version = ">= 1.0"
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "2.54.0"
    }

    random = {
      source  = "hashicorp/random"
      version = "3.1.0"
    }
  }
}

# Configure the Microsoft Azure Provider
provider "azurerm" {
  features {}
}

# Configure the Random Provider
provider "random" {}
resource "random_integer" "rand" {
  min = 1
  max = 50
}

resource "azurerm_resource_group" "examples" {
  name     = "example1-resources-${random_integer.rand.result}"
  location = "West Europe"
}

main.tf:
provider "docker" {} 
resources "docker_image" "terraform_centos" {
  name = "centos:7"
  keep_localy = true
} 
resources "docker_container" "centos" {
  image = docker_image.terraform_centos.latest
  name = "terraform_centos" 
  start = true
  command = ["/bin/sleep", "500"] 
} 

terraform apply
terraform state list
terraform state show docker_container.centos
docker ps
terraform state rm docker_container.centos
terraform destroy #not remove centos because are unregister
docker ps