Для следования этой главой вам требуется понимание того что представляет собой Terraform и как вы можете установить его в своей машине. Некие базовые сведения относительно основных поставщиков облачных решений, таких как GCP, AWS и Azure, дадут вам дополнительные преимущества.

В этом разделе мы изучим что представляют собой поставщиков Terraform. Двигаясь далее мы попробуем разобраться с поставщиками Terraform для основных облачных решений, таких как GCP, AWS и Azure. После того как вы получите представление о поставщиках Terraform, мы рассмотрим как вы можете определить блок поставщиков Terraform в своём коде конфигурации как ваш код конфигурации Terraform выгружает конкретных поставщиков при исполнении terraform init.

Вас может удивлять как Terraform узнаёт куда ему идти и создавать там ресурсы, давайте скажем, к примеру, возьмём ситуацию при которой вы желаете развернуть некий виртуальный сетевой ресурс в Azure. Как Terraform будет понимать куда ему требуется следовать и создавать ресурсы именно в Azure, а не в прочих облачных решениях? Terraform управляется для указания необходимого поставщика Terraform. Итак, давайте попробуем разобраться что представляет собой поставщик Terraform:

Поставщик это исполняемый подключаемый модуль, который выгружается при исполнении вами команды terraform init. Блок поставщика Terraform определяет значение версии и передаваемые параметры инициализации, такие как аутентификация или подробности проекта. Поставщики Terraform являются компонентами, которые выполняют все вызовы к API HTTP для конкретных облачных служб, то есть AzureRM, GCP или AWS.

Некий набор типов ресурсов предлагается каждым подключаемым модулем поставщика, что способствует определению того какие параметры ресурса могут применяться и какие параметры могут экспортироваться в выводе значений такого ресурса.

Реестр Terraform это главный каталог общедоступных поставщиков Terraform и он размещает поставщиков для главных платформ инфраструктуры. Вы также можете писать т распространять своих собственных поставщиков Terraform, причём как для общедоступного, так и для частного применения. Для получения дополнительных сведений о Реестре Terraform вы можете обратиться к https://registry.terraform.io/.

Поставщики могут определяться внутри любого файла, завершающегося на .tf или .tf.json, однако, в качестве рекомендации, лучше создавать файл с названием providers.tf или required_providers.tf с тем, чтобы всем было бы проще отыскивать его и, внутри такого файла вы можете определять код своего поставщика. Реальные параметры внутри блока поставщика могут меняться в зависимости от самого поставщика, однако все поставщики поддерживают мета- аргументы version и alias.

В Terraform имеется список поставщиков сообщества, которые вносят свой вклад и совместно применяются большим числом пользователей и производителей. Эти поставщики не все проверены и официально не поддерживаются HashiCorp. Вы можете просмотреть перечень сообщества Terraform в https://docs.google.com/forms/d/e/1FAIpQLSeenG02tGEmz7pntIqMKlp5kY53f8AV5u88wJ_H1pJc2CmvKA/viewform#responses или посетить в https://registry.terraform.io/publish/provider.

Если вы заинтересованы в написании поставщиков Terraform, тогда вы можете заполнить такую форму: https://docs.google.com/forms/d/e/1FAIpQLSeenG02tGEmz7pntIqMKlp5kY53f8AV5u88wJ_H1pJc2CmvKA/viewform#responses или посетить https://registry.terraform.io/publish/provider.

Мы не будем обсуждать как вы можете писать своих собственных поставщиков Terraform, однако если это вам интересно для дальнейшего изучения, вы можете посетить https://learn.hashicorp.com/tutorials/terraform/provider-setup и https://github.com/hashicorp/terraform-plugin-docs.

{Прим. пер.: Уместным будет вопрос как применять Terraform в собственных, частных, ЦОД на своей площадке. Имеется целый ряд вариантов. Во- первых, самой HashiCorp поддерживается множество распространённых облачных решений на таких площадках, как OpenStack, VMWare vSphere, CloudStack, Kubernetes. В сообществе даже имеются разработки для Hyper-V, например: hyperv от taliesins и hyperv от tidalf.}

{Прим. пер.: но что если вы желаете работать с "голым железом", которое по умолчанию не поддерживается Terraform? Тут также есть несколько вариантов. Например, вы можете воспользоваться проектом с открытым исходным кодом Digital Rebar Provision (DRP), обладающим Поставщиком Terraform, который позволяет DSL Terraform совместно работать с DRP. Этот поставщик делает возможной полную поддержку предоставляемого "голого железа". Вам следует установить на своей площадке службу DRP RackN, после чего соответствующий поставщик Terraform придёт в состояние готовности. Или же разрушить и очистить все свои машины и вернуться обратно к состоянию готовности к Terraform своего пула серверов. Дальше вы можете построить свой портал DRP.}

{Прим. пер.: Существует и иной путь работы с "голым железом", через RedFish. Этот проект с открытым исходным кодом разрабатывается при поддержке Dell EMC.}

 

{Прим. пер.: или обратитесь к нам}.

Давайте попробуем разобраться как блок поставщика выглядит для AzureRM, GCP и AWS.

 

Поставщик AzureRM Terraform

Как мы уже обсуждали это относительно поставщиков в Terraform, HashiCorp представила поставщика AzureRM. Теперь давайте попробуем разобраться с необходимым кодом для такого поставщика Azure:

# Мы настоятельно рекомендуем применять этот блок required_providers block для установки необходимого
# источника Azure Provider и подлежащей применению версии
terraform {
  required_version = ">= 1.0"
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "2.54.0"
    }
  }
}
# Настраиваем Поставщика Microsoft Azure
provider "azurerm" {
  features {}
  subscription_id    = "...."
  client_id          = "...."
  client_secret      = "...."
  tenant_id          = "...."
}
 	   

В своём предыдущем блоке кода AzureRM мы продумали аутентификацию Terraform к Azure с применением принципа этой службы. Давайте попробуем разобраться что поддерживают различные параметры:

Для аутентификации вашей подписки Azure от вас требуется предоставлять значения для subscription_id, client_id, client_secret и tenant_id. Теперь рекомендуется чтобы вы либо передавали эти значения через некую переменную среды, либо применяли кэшируемые полномочия из CLI Azure. В качестве настоятельной рекомендации, избегайте жёстко кодировать сведения секрета, такие как полномочия, в своей конфигурации Terreform. Для дополнительных сведений относительно того как выполнять аутентификацию Terraform у некого поставщика Azure, вы можете обратиться к https://www.terraform.io/docs/providers/azurerm/index.html.

Давайте теперь получим подробное понимание значений параметров version и features, определяемых в этом коде поставщика.

Определяемое в этом блоке кода значение параметра version в основном применяется для принуждения вашего поставщика к конкретной версии или к некому диапазону версий. Это предотвратит выгрузку нового поставщика, который может содержать некие основные разрушительные изменения. Если вы не определите значение параметра версии в своём блоке кода поставщика, Terraform поймёт это так, что вы желаете выгрузить в процессе terraform init самого последнего поставщика. Когда вы желаете определять версии в соответствующем блоке поставщика, HashiCorp рекомендует чтобы вы создавали для конфигурации Terraform специальный блок required_providers следующим образом:

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

Вместо того чтобы устанавливать значение версии поставщика для каждого экземпляра поставщика, соответствующий блок required_providers устанавливает его для всех экземпляров этого поставщика, причём включая дочерние модули. Применение блока required_providers упрощает обновление значения версии в сложной конфигурации.

Давайте рассмотрим различные возможные варианты, которые вы можете передавать значениями версии в соответствующем блоке кода:

Одним из наиболее распространённых вариантов является параметр ~>, что означает что вы желаете иметь ту же самую основную версию, в то время как допускаете обновления менее значимых версий. Например, имеется изменение основной версии поставщика Azure с версией 2.0. Устанавливая ~> 1.0, вы допускаете все выпускаемые обновления версии 1 и в то же время блокируете выпуск большой 2.0.

Давайте попробуем разобраться с тем, чем занимается аргумент features внутри этого блока кода поставщика Azure.

Как и в случае с самыми последними обновлениями, вы способны управлять при помощи этого блока features поведением некоторых ресурсов своего Azure. Дополнительные подробности относительно ресурсов, которыми вы способны управлять определяются так.

Блок features поддерживает следующие ресурсы или службы Azure:

Блок key_vault поддерживает следующие параметры:

Блок template_deployment поддерживает следующие параметры:

Блок virtual_machine поддерживает следующие параметры:

Блок virtual_machine_scale_set поддерживает следующие параметры:

Блок virtual_machine_scale_set поддерживает следующие параметры:

Приведённые выше параметры блока features были взяты из https://www.terraform.io/docs/providers/azurerm/index.html. Для получения дополнительных сведений можете обратиться по этому URL.

В нашем следующем примере вы можете наблюдать как определяется параметр features в соответствующем коде поставщика Azure и как можно управлять конкретными свойствами ключа vault. Вы можете применять тот же самый подход и персонализировать все ранее определённые параметры соответствующего ресурса или служб Azure:

provider "azurerm" {
  version = "~> 2.54.0"
  features {
    key_vault {
      recover_soft_deleted_key_vaults = false
    }
  }
}
 	   

Теперь давайте попробуем разобраться с вариантом применения в котором вы намерены развернуть множество ресурсов Azure в различных подписках. Terraform предоставляет в вашем блоке поставщика некий параметр с названием alias. Применяя параметр alias вы можете ссылаться на одного и того же поставщика множество раз в отличающихся конфигурациях в своём блоке конфигурации.

Вот пример такого кода:

terraform {
  required_version = ">= 1.0"
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "2.54.0"
    }
  }
}
# Настраиваем своего Поставщика Microsoft Azure
provider "azurerm" {
  features {}
}
provider "azurerm" {
  features {}
  alias = "nonprod_01_subscription"
}
# Для создания Resource Group в конкретной подписке
resource "azurerm_resource_group" "example" {
  provider = azurerm.nonprod_01_subscription
  name     = "example-resources"
  location = "West Europe"
}
 	   

Двигаясь далее, давайте попробуем разобраться как вы можете определять множество различных поставщиков в своём файле конфигурации Terraform. Вот один из фрагментов такого кода:

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"
}
 	   

Как предписывает приведённый выше код, мы определили двух отличающихся поставщиков: random и azurerm. Поставщик поможет нам выработать некое случайное целое от 1 до 50 и, в качестве полученного результата, это целое будет добавлено в конец значения имени группы ресурса Azure. Применяя данный подход мы способны определять множество поставщиков в одном и том же файле конфигурации.

Давайте попробуем разобраться как мы можем определять некого поставщика для своего AWS. Это также будет применять тот же самый подход, которым мы пользовались в AzureRM.

 

Поставщик AWS Terraform

Мы уже обсудили поставщика AzureRM Terraform. Аналогично, HashiCorp представил поставщика AWS. Давайте попробуем разобраться как поставщик AWS может определять файл конфигурации Terraform.

Ниже приводится фрагмент кода:

terraform {
  required_version = ">= 1.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 3.35.0"
    }
  }
}
provider "aws" {
  region     = "us-east-1"
  access_key = "..."
  secret_key = "..."
}
 	   

Имеется большое число параметров, поддерживаемых блоком кода поставщика AWS. Несколько из них описывается здесь, но дополнительные сведения относительно всех имеющихся параметров вы можете получить, посетив https://registry.terraform.io/providers/hashicorp/aws/latest/docs:

Для аутентификации своей учётной записи AWS вы можете определять access_key и secret_key в своей переменной среды, потому что, как вы знаете, жёсткое кодирование секрета в блоке кода поставщика не рекомендуется, поэтому лучше передавать его в процессе самого времени исполнения, либо определять в соответствующей переменной среды. Для получения дополнительных сведений относительно варианта аутентификации вы можете посетить https://registry.terraform.io/providers/hashicorp/aws/latest/docs.

Все прочие общие параметры, такие как alias и version, которые мы уже обсуждали для поставщика Azure, могут точно так же применяться и в блоке поставщика AWS, поэтому здесь мы их пропускаем.

 

Поставщик Google Terraform

Также как и поставщики AWS and Azure, HashiCorp представила поставщика Облачного решения Google. На данный момент вы получили достаточное представление о поставщиках Terraform, поэтому давайте попробуем посмотреть как мы можем определять кодовый блок поставщика Terraform для Облачного решения Google:

terraform {
  required_version = ">= 1.0"
  required_providers {
    google = {
      source = "hashicorp/google"
      version = "3.63.0"
    }
  }
}
provider "google" {
  credentials = file("account.json")
  project     = "my-google-project-id"
  region      = "europe-west2"
  zone        = "europe-west2-b"
}
 	   

Как и поставщики AWS и Azure, поставщик Google также поддерживает большое число аргументов. Мы выделим несколько из них:

Для получения представления о параметрах alias и version вы можете вернуться обратно и прочесть раздел поставщика Azure, поскольку их принцип работы тот же самый; вам всего лишь следует понять стоящие за ними понятиями.

Мы рассмотрели поставщиков Terraform, в частности, обсудив Azure, AWS и GCP. Вы должны понимать как определять блок кода поставщика в своём файле конфигурации Terraform. Совместно с этим вы должны были изучить как вы можете применять множество одинаковых поставщиков в своём файле конфигурации определяя alias. После обучения поставщикам Terrafor, давайте попробуем разобраться как вы можете писать блок кода ресурсов в своём файле конфигурации Terraform, который является тем самым кодом, который в реальности поможет вам обеспечить выполнение изменение в уже имеющихся ресурсах. Мы обсудим блоки кода ресурсов в своих основных облачных решениях: Azure, AWS и Google.

Получив пристойное понимание поставщиков Terraform, теперь мы намерены обсудить как в файле конфигурации Terraform определяется блок кода ресурсов и почему он настолько важен. Прежде всего, давайте рассмотрим что представляют собой ресурсы Terraform.

Resources это наиболее важный блок кода в языке программирования Terraform. Определяя блок кода ресурсов в своём файле конфигурации, вы позволяете Terraform узнать какие объекты инфраструктуры вы планируете создавать, удалять или обновлять, например, compute, virtual network или компоненты PaaS более верхнего уровня, такие как web apps и databases. Когда вы определяете блок кода ресурсов в своём файле конфигурации, он начинается с собственно имени поставщика в самом начале, например, aws_instance, azurerm_subnet и google_app_engine_application.

 

Ресурсы Azure Terraform

Для вас очень важно понимать как вы должны писать свой код ресурсов Terraform в его файле конфигурации. Мы обсудим очень простой пример Azure public IP address, который вы можете наблюдать на следующем снимке экрана:

Как вы можете видеть на Рисунке 3-2, выделенный красным текст это реальный ресурс, который вы планируете обновлять, создавать или уничтожать. Аналогичным образом, Azure обладает большим числом ресурсов, о которых вы можете получить дополнительные сведения в https://www.terraform.io/docs/providers/azurerm/:

Здесь, с левой стороны нашего представленного ранее вебсайта, вы будете способны наблюдать все ресурсы Azure, которые показаны на Рисунке 3-3. Вы будете способны писать свой файл конфигурации применяя эти предоставляемые Azure ресурсы.

Выделенный синим текст это просто локальное название для Terraform определённого кода ресурса, который мы составляем. На Рисунке 3-2 некую группу ресурсов Azure и общедоступный адрес IP. Итак, мы задали локальное название для группы ресурсов в виде example и azure-pip для своего общедоступного Azure IP адреса.

Выделенный зелёным текст на Рисунке 3-2 предоставляет нам сведения о том как мы можем ссылаться на конкретные параметры из прочих блоков ресурсов. В своём предыдущем примере мы хотим создать некий общедоступный IP адрес Azure. Для обеспечения общедоступного IP адреса Azure, вам потребуется предоставить название и положение группы ресурсов, которые можно получить из определённого ранее блока кода группы ресурсов.

Когда теперь вы получили общее представление о том как определять блок кода ресурсов Azure в своём файле конфигурации Terraform, давайте рассмотрим как мы можем выполнять это в AWS.

 

Ресурсы AWS Terraform

Вы можете подумать, что Terraform будет вести себя обособленным образом и что потребуются изменения в его синтаксисе при определении блока кода ресурсов в файле конфигурации Terraform для AWS, но это не так. Он следует тем же самым подходом в плане того, как мы можем определять его для ресурсов Azure. Давайте попробуем обсудить это воспользовавшись примером AWS:

resource "aws_instance" "web" {
  ami           = "ami-a1b2c3d4"
  instance_type = "t2.micro"
}
 	   

Как вы можете видеть из предыдущего фрагмента кода, мы пытаемся развернуть в AWS некий экземпляр EC2. Для этого мы определили некий блок ресурсов, объявляя некий ресурс заданного типа ("aws_instance"), который обладает неким локальным названием, "web". Это локальное имя в основном применяется для ссылки на данный ресурс во всех прочих ресурсах, данных или модульных блоках кода. Для дополнительных сведений относительно доступных ресурсах AWS вы можете посетить https://registry.terraform.io/providers/hashicorp/aws/latest/docs.

На данный момент мы рассмотрели блоки кода ресурсов для Azure и AWS и не обнаружили никаких различий в их синтаксисе. Вы можете подумать, что он определённо изменится в Облачном решении Google. В своём следующем разделе мы намерены определить как вы можете писать блок кода ресурсов Google в его файле конфигурации Terraform.

 

Ресурсы Google Terraform

Мы уже видели как мы можем определять некий блок кода ресурсов для AWS и Azure. С точки зрения синтаксиса ресурсов Terraform не имелось никакой разницы; единственный момент, который будет отличаться для всех имеющихся поставщиков это соответствующие параметры блока ресурсов, потому как всякий поставщик обладает собственными параметрами, которые могут передаваться в соответствующий блок кода ресурсов. Давайте рассмотрим образец кода ресурсов Terraform Облачного решения Google для создания Google App Engine (Механизма прикладного приложения Google):

resource "google_project" "my_project" {
  name       = "My Project"
  project_id = "your-project-id"
  org_id     = "1234567"
}
resource "google_app_engine_application" "app" {
  project     = google_project.my_project.project_id
  location_id = "us-central"
}
 	   

Здесь мы применяем блок ресурсов google_project, имеющим локальное название my_project для создания проекта Облачного решения Google и google_app_engine_application с локальным именем app для создания некого ресурса Google App Engine.

Мы рассмотрели блок кода ресурсов Terraform и изучили как писать блок ресурсов для таких поставщиков облачного решения, как AWS, Azure и GCP. Мы даже ознакомились с тем, в чём состоят отличия соответствующих блоков кода ресурсов; может иметься большое число отличий в плане параметров, поддерживаемых каждым поставщиком. Двинемся далее, мы намерены разобраться с тем, как вы можете получать входные данные от пользователей, такие как название соответствующего экземпляра EC2, через определение переменных Terraform.

В предыдущем разделе вы изучили как вы можете писать некий блок кода ресурсов в своём файле конфигурации Terraform. В таком блоке кода ресурсов мы либо жёстко кодируем значения параметров, либо мы ссылаемся на них из другого блока кода ресурсов. Теперь мы попробуем разобраться как мы способны определять такие жёстко кодируемые значения в некой переменной и определять их в неком обособленном файле, который мы будем применять снова и снова.

Если вы обладаете базовой практикой написание какого бы то ни было сценария или языка программирования, вы должны были заметить, что мы можем определять некоторые переменные и применять такие заданные переменные снова и снова во всём своём сценарии. Аналогично тому, как это делается в прочих языках программирования, Terraform также поддерживает переменные, которые могут определяться в соответствующем файле конфигурации Terraform. Единственное отличие между переменными прочих языков программирования и переменными Terraform состоит в том, что в переменных Terraform вы предполагаете определять входные значения когда вы желаете исполнять свой код конфигурации Terraform. Мы поясним такой подход входных переменных Terraform для всех трёх облачных решений - Azure, AWS и GCP.

 

Входные переменные Azure Terraform

Давайте попробуем предпринять тот же самый пример общедоступного IP адреса Azure, который мы обсуждали в разделе Знание ресурсов Terraform. Мы попробуем определить переменные для большинства необходимых параметров с тем, чтобы мы могли применять этот код ресурса снова и снова, всего лишь предоставляя значения для определения входных переменных. Вот фрагмент кода, который мы предоставляем вам с некой идеей того, как вы можете определять переменные в соответствующем коде конфигурации Terraform. Вы можете просто взять этот код в некий файл, заканчивающийся на .tf. Обычно мы пытаемся помещать его в main.tf:

# To Create Resource Group
resource "azurerm_resource_group" "example" {
  name     = var.rgname
  location = var.rglocation
}
# To Create Azure Public IP Address
resource "azurerm_public_ip" "azure-pip" {
  name                    = var.public_ip_name
  location                = azurerm_resource_group.example.location
  resource_group_name     = azurerm_resource_group.example.name
  allocation_method       = var.allocation_method
  idle_timeout_in_minutes = var.idle_timeout_in_minutes
  tags                    = var.tags
}
		

В нашем предыдущем коде вы могли наблюдать как мы определили свои переменные для всех параметров ресурсов. Синтаксис таков: <argument name> = var.<variable name> мы выделили в своей группе ресурсов name и location с тем, чтобы вы получили представление о том, как обычно мы предполагаем определять переменные ввода. После определения необходимых входных переменных Terraform не забывайте объявлять их. Мы можем объявлять их в любом файле, заканчивающемся на .tf. Обычно мы объявляем их в неком обособленном файле с названием variables.tf. Переменные требуется определять внутри соответствующего блока переменных, иными словами, variables <variable name>. Вот фрагмент кода для вашей справки:

# variables for Resource Group
variable "rgname" {
  description = "(Required)Name of the Resource Group"
  type        = string
  default     = "example-rg"
}
variable "rglocation" {
  description = "Resource Group location like West Europe etc."
  type        = string
  default     = "West Europe"
}
# variables for Azure Public IP Address
variable "public_ip_name" {
  description = "Name of the Public IP Address"
  type        = string
  default     = "Azure-pip"
}
variable "allocation_method" {
  description = "Defines the allocation method for this IP address. Possible values are `Static` or `Dynamic`"
  type        = string
  default     = "Dynamic"
}
variable "idle_timeout_in_minutes" {
  description = "Provide Idle timeout in minutes"
  type        = number
  default     = 30
}
variable "tags" {
  description = "A map of tags to assign to the resource. Allowed values are `key = value` pairs"
  type        = map(any)
  default = {
    environment = "Test"
    Owner       = "Azure-Terraform"
  }
}
		

Простое объявление переменных Terraform не окажется полезным. Чтобы выполнить этот рабочий процесс Terraform, данные переменные должны получить значения с тем, итак, существует четыре способа получения значений переменных Terraform. Самый первый подход которым мы можем следовать, состоит в определении значений переменных в соответствующих переменных среды Terraform. Terraform будет просматривать эти значения в своих переменных среды, начинающихся с TF_VAR_, за которыми следует собственно название объявленной переменной, как вы это можете видеть здесь:

$ export TF_VAR_rgname=example-rg
		

Во- вторых, мы можем сохранять значения переменных либо в установленном по умолчанию файле поддержки с названием terraform.tfvars или terraform.tfvars.json, либо в файле с названием. заканчивающемся на .auto.tfvars или .auto.tfvars.json.

Здесь мы покажем как вы можете определять их в своём файле terraform.tfvars:

rgname                  = "Terraform-rg"
rglocation              = "West Europe"
idle_timeout_in_minutes = 10
tags = {
  environment = "Preprod"
  Owner       = "Azure-Terraform"
}
allocation_method = "Dynamic"
public_ip_name    = "azure-example-pip"
 	   

Если вы планируете определять значения входных переменных в любом ином файле, например в testing.tfvars, тогда вам потребуется упоминать в явном виде имя этого файла в выбранном cmdlet Terraform: terraform apply -var-file="testing.tfvars". Это означает, что Terraform будет способен считывать необходимые значения из такого файла .tfvars.

Третий способ получения значений переменных Terraform происходит в процессе времени исполнения. Если вы определили необходимую переменную в main.tf или variables.tf, а её входные значения пропущены, тогда вы получите приглашение на ввод для предоставления соответствующего значения переменной на протяжении самого времени исполнения, как мы это можем обнаружить в следующем фрагменте кода:

$ terraform plan
var.rglocation
  Resource Group location like West Europe etc.
  Enter a value:
		

Наш четвёртый способ, которым мы могли бы определять значение переменной, состоит в прямом default value при определении соответствующих переменных, как это можно увидеть из следующего фрагмента кода:

variable "rgname" {
  description = "(Required)Name of the Resource Group"
  type        = string
  default     = "example-rg"
}
		

Применяя все эти методы мы можем получать необходимые значения переменных и Terraform будет иметь возможность выполнения своего рабочего процесса.

В определённом выше коде variables.tf вы можете наблюдать множество типов ограничений, включая number, string и map. Мы обсудим их в последующей Главе 7, Модули Terraform, на данный момент просто понимайте как вы можете определять переменные и как вы можете определять значения переменных ввода. Имеется ещё один момент, на который вы могли обратить внимание, в своём коде переменной мы упомянули значения по умолчанию. Здесь основной вопрос состоит в том, какое из них будет предпочтительным; когда вы определяете значения переменных в переменных среды Terraform, задаёте их в terraform.tfvars, определяете значение по умолчанию или предоставляете значения в процессе времени исполнения. Здесь вещи происходят в следующей последовательности: Значения переменной среды | Значения в процессе времени исполнения | terraform.tfvars | Значения по умолчанию.

 

Входные переменные AWS Terraform

В своём предыдущем разделе мы изучили входные переменные Azure Terraform. Вы ознакомились с тем, что в точности представляют переменные и как вы можете определять входные переменные Terraform.Давайте попробуем рассмотреть один из образцов для AWS:

# You can define this code in main.tf or in any file named like aws-ec2.tf
# To create ec2 instance in AWS
resource "aws_instance" "web" {
  ami           = var.ami
  instance_type = var.instance_type
}
 	   

Определённый выше блок кода ресурсов AWS помогает нам предоставлять некий экземпляр EC2 в AWS. Давайте попробуем определить для него файл variables.tf:

# variables for Resource Group
variable "ami" {
  description = "Name of the AMI"
  type        = string
}
variable "instance_type" {
  description = "Name of the instance type"
  type        = string
}
 	   

Нам следует определить соответствующий файл variables.tf для своего кода ресурсов ec2 instance, затем нам придётся получить значения для этих определённых переменных. Итак, давайте зададим эти значения в своём файле terraform.tfvars:

ami           = "ami-a1b2c5d6" 
instance_type = "t1.micro"
 	   

 

Входные переменные GCP Terraform

Мы изучили определение входных переменных в AWS и Azure и также нет никакой разницы с точки зрения их определения для GCP. Давайте попробуем некий образец кода конфигурации Terraform для GCP и увидим как мы можем определять для него код входных переменных. Мы намерены обсудить это в том же самом коде ресурса, что и ранее, для App Engine в Облачном решении Google:

resource "google_project" "my_project" {
  name       = var.myproject_name
  project_id = var.project_id
  org_id     = var.org_id
}
resource "google_app_engine_application" "app" {
  project     = google_project.my_project.project_id
  location_id = var.location_id
}
 	   

Давайте попробуем определить свой файл variables.tf для нашего предыдущего кода, который намерен развёртывать нам Google App Engine:

# variables for Google Project
variable "myproject_name" {
  description = "Name of the google project"
  type        = string
}
variable "project_id" {
  description = "Name of the project ID"
  type        = string
}
variable "org_id" {
  description = "Define org id"
  type        = string
}
variable "location_id" {
  description = "Provide location"
  type        = string
}
 	   

Мы выполнили определение всех необходимых переменных в variables.tf. Теперь давайте попробуем передать им значения в terraform.tfvars:

yproject_name = "My Project" 
project_id = "your-project-id"
org_id = "1234567"
location_id = "us-central"
 	   

Мы обсудили переменные Terraform и получили некоторое понимание рекомендаций определений переменных Terraform и того, как мы можем получать ввод от пользователей передавая значения переменных в переменных среды Terraform, terraform.tfvars, значениях по умолчанию и во время исполнения через CLI. Основной вывод этой темы состоит в том насколько действенно вы можете писать файл конфигурации Terraform при помощи переменных Terraform. В своей следующей теме мы обсудим вывод Terraform. Вывод Terraform поможет вам в валидации того что вы ожидали в качестве вывода при создании или обновлении вами любых ресурсов.

В этом разделе мы намерены рассмотреть как вы можете определять вывод Terraform, а также рекомендации для справочного руководства по выводу одного ресурса в качестве входных данных для других зависимых ресурсов. Мы будем обсуждать вывод Terraform для AWS, GCP и Azure.

Давайте попробуем разобраться что представляет собой вывод Terraform и, в идеале, чего мы можем достигать им, а также почему нам требуется определять вывод Terraform для всех начертанных файлов конфигурации Terraform. Значения вывода представляют собой возвращаемые значения Terraform ресурса/ модуля/ данных Terraform и они обладают большим числом вариантов применения:

Terraform управляет всеми вашими экземплярами ресурсов. Каждый экземпляр ресурса помогает вам некоторым экспортом атрибута вывода, который может применяться в других боках кода конфигурации. Значения вывода помогают вам выставлять некоторые сведения, которые вы могли бы искать. После того как вы обеспечили определённый экземпляр ресурса при помощи Terraform, или даже для имеющихся ресурсов, на значения выводов также можно ссылаться при помощи блока кода соответствующего источника данных.

Давайте попробуем разбираться как мы можем определять вывод Terraform в Azure, AWS и GCP.

 

Вывод Azure Terraform

В соответствующей теме ресурса Terraform мы касались общедоступного IP адреса Azure. Давайте попробуем взять тот же самый блок кода ресурса и посмотрим как мы можем выделить вывод из этого ресурса:

resource "azurerm_resource_group" "example" {
  name     = "resourceGroup1"
  location = "West US"
}
resource "azurerm_public_ip" "example" {
  name                = "acceptanceTestPublicIp1"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location
  allocation_method   = "Static"
  tags = {
    environment = "Production"
  }
}
 	   

Из этого блока кода azurerm_public_ip у нас есть возможность экспортировать следующие атрибуты:

Давайте посмотрим как вы можете определять необходимый блок кода вывода в своём файле main.tf, или как вы можете создавать обособленный файл output.tf и определять всё в нём самом. Мы рекомендуем вам определять весь ваш код вывода в неком отдельном файле, то есть в output.tf:

output "id" {
  value = azurerm_public_ip.example.id
}
output "name" {
  value = azurerm_public_ip.example.name
}
output "resource_group_name" {
  value = azurerm_public_ip.example.resource_group_name
}
output "ip_address" {
  value = azurerm_public_ip.example.ip_address
}
output "fqdn" {
  value = azurerm_public_ip.example.fqdn
}
 	   

В своём предыдущем коде мы управляем получением всего возможного вывода после создания некого общедоступного IP адреса Azure.

Мы обсудили вывод Terraform и увидели как мы можем его подтверждать. Давайте попробуем посмотреть как мы можем применять ссылки на атрибут Terraform из кодового блока ресурса/ модуля/ данных при создании некого нового ресурса. Для того чтобы лучше разобраться со ссылкой на атрибут Terraform, мы воспользовались ресурсом балансировщика нагрузки Azure:

Как показано на Рисунке 3-4, при создании некого балансировщика нагрузки Azure мы берём некие значения ссылок из общедоступного IP адреса Azure, иными словами, название общедоступного IP адреса и идентификатор ресурса общедоступного IP адреса. В действительности это не вывод Terraform, но это некая ссылка на атрибут, что означает, что значение одного блока способно ссылаться на другой.

 

Вывод AWS Terraform

Поскольку мы уже изучили как мы можем выделять вывод при создании любого ресурса Azure, давайте посмотрим как мы можем определять то же самое в AWS. Если вы уже понимаете синтаксис определения значений вывода, он остаётся тем же самым для всех поставщиков Terraform. Мы поговорим о неком образце ресурса VPC (Virtual Path Connection, соединение виртуальных путей) для дальнейшей демонстрации вывода AWS Terraform:

# To Create AWS VPC 
resource "aws_vpc" "terraform-vpc" {
  cidr_block       = "10.0.0.0/16"
  instance_tenancy = "default"
  tags = {
    Environment = "Terraform-lab"
  }
}
 	   

Давайте попробуем рассмотреть какие выводимые значения мы ожидаем увидеть из этого блока ресурсов VPC. Может быть экспортировано большое число аргументов, как мы можем видеть на Рисунке 3-5 или посетив https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/vpc#attributes-reference. Мы собираемся обсудить некоторые из них, такие как id и cidr_block. На их примере вы можете получить общее представление о том как можно выделять вывод из прочих упомянутых атрибутов.

Приводимый ниже код снабдит вас представлением о том как мы можем подтверждать соответствующий вывод вслед за созданием VPC AWS:

output "id" {
  value = aws_vpc.terraform-vpc.id
}
output "cidr_block" {
  value = aws_vpc.terraform-vpc.cidr_block
}
 	   

Вы можете удивляться всякий раз, когда вам требуется потребить получаемый из этого VPC AWS вывод во всяком прочем ресурсе, таком как подсеть AWS и то как вы можете делать это. Давайте попробуем разобраться с этим, что носит название ссылок атрибутов Terraform. В разделе Вывод Azure Terraform мы уже поясняли как применять некую неявную ссылку, которую вы бы были способны употреблять в другом кодовом блоке ресурса/ модуля/ данных. Вот соответствующий фрагмент кода для создания подсети внутри конкретного VPC AWS:

resource "aws_subnet" "terraform-subnet" {
  vpc_id     = aws_vpc.terraform-vpc.id
  cidr_block = "10.0.0.0/24"
  tags = {
    Environment = "Terraform-lab"
  }
}
 	   

В нашем предыдущем коде вы можете видеть как мы управляем осуществлением ссылок на атрибут Terraform из одного блока кода ресурса и его употребления в другом блоке кода ресурса. Точно так же вы можете выполнять это с источниками данных и модулями.

 

Вывод GCP Terraform

В этом разделе мы попробуем разобраться с тем, как вы можете определять значения вывода для ресурсов GCP. Давайте начнём с того, что разберёмся с простым ресурсом Облачного решения Google. В приводимом ниже коде мы определяем блок кода ресурсов для создания ресурса Механизма прикладного приложения Google:

resource "google_project" "my_project" {
  name       = "My Project"
  project_id = "your-project-id"
  org_id     = "1234567"
}
resource "google_app_engine_application" "app" {
  project     = google_project.my_project.project_id
  location_id = "us-central"
}
 	   

Вот перечень тех атрибутов, которые могут экспортироваться в качестве вывода из ресурса Механизма прикладного приложения Google:

Из всего списка определённых на Рисунке 3-6 параметров мы рассмотрим id и name, которые, как вы можете наблюдать в следующем фрагменте кода, вы можете определять внутри main.tf или такого отдельного файла как output.tf:

output "id" {
  value = google_app_engine_application.app.id
}
output "name" {
  value = google_app_engine_application.app.name
}
 	   

 

Не обязательные параметры вывода Terraform

Вывод Terraform поддерживает некие параметры, такие как description, sensitive и depends_on, которые описываются следующим образом:

Мы обсудили вывод Teraform. Теперь вы должны обладать достаточным пониманием того, как вы можете применять выводимые значения Terraform для подтверждения обеспечиваемых вами ресурсов, а также вы получили знания о том, как вы осуществляете ссылки на атрибуты Terraform из одного блока кода ресурсов/ модуля/ данных к другому блоку кода ресурсов/ модуля/ данных. В своём следующем разделе мы намерены обсудить данные Terraform. Там вы изучите как вы можете считывать уже имеющиеся ресурсы вашей инфраструктуры. Для этих пояснений мы снова рассмотрим три основные облачные службы: Azure, AWS и GCP.

В этом разделе мы собираемся обсудить как вы можете определять исходные данные Terraform. Вы также можете обращаться к https://www.terraform.io/docs/configuration/data-sources.htm чтобы увидеть при каких обстоятельствах вы сможете применять источники данных Terraform. Точно так же как и при выводе, ресурсах, поставщиках и переменных Terraform, мы будем рассматривать Terraform для AWS, GCP и Azure.

Давайте попробуем разобраться с источниками данных Terraform при помощи некоторого примера. Боб с двумя коллегами работает на компанию с названием Obs, базирующуюся в США. Obs является компанией- поставщиком, которая имеет бизнес по всему миру и в последнее время они приступили к использованию множества облачных решений AWS и Azure. Между Бобом и Мэттом прошли горячие переговоры. Боб сказал, что он будет осуществлять всё развёртывание инфраструктуры применяя шаблоны ARM, предоставляемые Azure, в то время как Мэтт сказал, что он бы предпочёл применять Terraform. Теперь основная проблема состоит в том, что Боб уже предоставил некоторые промышленные инфраструктуры в Azur с применением шаблонов ARM. Скажем, в качестве примера, он предоставил одну виртуальную сеть, пять подсетей и пять виртуальных машин. У Мэтта запросили создать пять дополнительных виртуальных машин в этих уже имеющихся виртуальных сетях и подсетях. Он хотел бы воспользоваться для такого развёртывания Terraform. У него в голове множество вопросов, например, как он будет способен считывать уже имеющуюся инфраструктуру и как он будет способен записывать файл конфигурации Terraform для этой новой разработки? После некоторых поисков он ознакомился с источниками данных Terraform, которые позволяют ему выделять вывод или сведения из уже имеющихся ресурсов, которые были развёрнуты прочими конфигурациями Terraform, или же вручную, или иным способом.

 

Источники данных Azure Terraform

В этом разделе мы поясним как вы можете определять источники данных Terraform, специфичные для Azure. Давайте попробуем разобраться с этим на неком примере. Допустим, у вас уже имеется некая созданная виртуальная сеть Azure, а теперь вы пытаетесь создать некую новую подсеть в этой имеющейся виртуальной сети. В данных обстоятельствах, как бы мы могли определить ваш кодовый блок источника даных Terraform? В приводимом далее фрагменте кода мы демонстрируем как вы можете получить некий вывод из уже имеющейся виртуальной сети:

data "azurerm_virtual_network" "example" {
  name                = "production-vnet"
  resource_group_name = "Terraform-rg"
}
output "virtual_network_id" {
  value = data.azurerm_virtual_network.example.id
}
 	   

Когда вы желаете создать некую подсеть в уже имеющейся виртуальной сети, тогда приводимый ниже фрагмент кода способен помочь вам решить это, выделяя уже имеющуюся группу ресурсов и виртуальную сеть, с последующим разрешением вам предоставлять новую подсеть внутри этой имеющейся виртуальной сети:

data "azurerm_resource_group" "example" {
  name = "Terraform-rg"
}
data "azurerm_virtual_network" "example" {
  name                = "production-vnet"
  resource_group_name = data.azurerm_resource_group.example.name
}
resource "azurerm_subnet" "example" {
  name                 = "terraform-subnet"
  resource_group_name  = data.azurerm_resource_group.example.name
  virtual_network_name = data.azurerm_virtual_network.example.name
  address_prefixes     = ["10.0.1.0/24"]
}
 	   

Что касается виртуальных сетей Azure, для каждой службы Azure существует некий источник данных Terraform. Если вы желаете ознакомиться с синтаксисом и написанием некого кодового блока источника данных Terraform Azure в файле конфигурации Terraform, вы можете обратиться к https://www.terraform.io/docs/providers/azurerm/.

 

Источники данных AWS Terraform

Аналогично тому способу, которым мы определяли свой блок кода источников данных Azure Terraform, давайте попробуем рассмотреть как мы можем определять источники данных Terraform для AWS. Мы хотим создать подсеть в VPC (Virtual Path Connection, соединение виртуальных путей) AWS. В качестве справки вы можете воспользоваться следующим фрагментом коде где мы определили в качестве входной переменной vpc_id.

variable "vpc_id" {}
data "aws_vpc" "example" {
  id = var.vpc_id
}
resource "aws_subnet" "example" {
  vpc_id            = data.aws_vpc.example.id
  availability_zone = "us-west-2a"
  cidr_block        = cidrsubnet(data.aws_vpc.example.cidr_block, 4, 1)
}
 	   

Для подробностей относительно всех служб AWS, которые могут быть определены в источниках данных AWS Terraform, вы можете обратиться к справочному вебсайту поставщиков AWS.

 

Источники данных GCP Terraform

В этом разделе мы намерены обсудить как вы можете определять в своей конфигурации код источников данных GCP Terraform. С целью понимания, давайте воспользуемся простым примером выделения деталей имеющегося вычислительного экземпляра GCP. Следующий фрагмент кода снабдит вас пониманием того как вы можете начертать источники данных GCP Terraform:

data "google_compute_instance" "example" {
  name = "Terraform-server"
  zone = "us-central1-a"
}
 	   

Если вам требуются дополнительные сведения, за справками вы можете обратиться к вебсайту поставщиков Terraform Google, где поясняются все службы Google со всеми его источниками данных.

Мы обсудили блоки кода источников данных в файлах конфигурации Terraform. Мы изучили как мы можем проектировать свой файл конфигурации Terraform применяя источники данных для различных поставщиков, таких как Azure, AWS и GCP. Источники данных помогают считывать уже имеющиеся конфигурации и применять такой вывод в новых или обновляемых инфраструктурах.

В данной главе вы получили понимание центральных компонентов Terraform, включая поставщиков, ресурсы, переменные, вывод и источники данных. В самой сердцевине, поставщик это некий подключаемый модуль, который требуется вам когда вы желаете развёртывать/ обновлять службы для своей инфраструктуры. Ресурсы это реальные службы, которые вы можете планировать для обновления/ развёртывания для своих соответствующих поставщиков. Переменные выступают вводом от соответствующих пользователей, что превращает ваш код конфигурации в повторно используемый. Соответствующий вывод это то, что вы ожидаете при создании/ обновлении вами своих ресурсов. Источники данных помогают вам с извлечением существующих конфигураций ресурсов. Всё это поможет вам создать файл конфигурации Terraform.

В своей следующей главе мы проведём подробное обсуждение относительно соответствующих конфигураций серверной основы, оснасток и встроенных функций, как в Terraform осуществлять отладку и как вы можете выполнять различные виды итераций применяя for и прочие циклы в Terraform.

Ответы на данные вопросы можно обнаружить в разделе Аттестация в самом конце этой книги:

Для получения дополнительных сведений по рассматривавшимся в этой главе темам вы можете обратиться к следующим ссылкам: