Створено GamerRazor на Tenor
Зміст
· Огляд
· Необхідні умови для розгортання
· Огляд
· Фаза перша (Закладка основ для Terraform)
∘ Terraform Block
∘ Local Name
∘ Source
∘ Version
∘ Provider Block
∘ Resource Block
∘ Implementation
· Фаза друга (Що ми розгорнули і чому це важливо)
· Фаза третя (Втілення вашого Terraform проєкту в реальність)
· Висновок
Огляд
Давайте почнемо з короткого підсумку. У попередньому епізоді, ми побачили, як автор представив Terraform, інструмент для інфраструктури як коду (IaC), пояснивши його переваги, функціональність та базові команди для автоматизації та керування хмарною інфраструктурою. Подивимось, що він підготував для нас цього разу 😄.
Примітка автора
Привіт, хлопці! Бажаю вам усім дуже щасливого Нового року. Час так швидко летить. Здається, що ще вчора я пояснював вам про Terraform, а ось я вже пишу зовсім новий блог у абсолютно іншому році 😬.
Необхідні умови для розгортання
Огляд
Багато з нас пройшли через навчання, де теорія переважала над практичною реалізацією, і щоразу, коли ми бачили практичність, вона начебто говорила: "Et tu, Brute?"
Але не хвилюйтеся, я не дозволю своєму Юлію говорити так мені 😅.
Цього разу я занурюся глибше у сценарієву частину написання базової конфігурації Terraform для Azure.
Конфігурація Terraform — це загальний термін, що використовується для всіх сценаріїв, які використовуються для створення інфраструктури.
Не переживайте, якщо ви не маєте попереднього досвіду роботи з Azure. Я розподілив цей блог на три фази. У фазі першій я поясню сценарії та їх функціональність. У фазі другій я надам вам огляд того, що я розгорнув в Azure, а також поясню призначення та значення цих ресурсів. У фазі третій я поділюсь сценаріями, що використовувались для розгортання архітектури.
Хочу зауважити, що ми будемо використовувати базові сценарії. Я не буду охоплювати теми використання модулів і змінних. Залишимо ці теми для іншого дня.
Почнемо 😎
Фаза перша (Закладка основ для Terraform)
Рис.1: Конфігурація Terraform
Зазвичай, один виконуваний сценарій Terraform повинен містити:
Дотримуйтесь хронології при написанні вашого коду в одному сценарії.
Звертаючись до Рис.1:
- Provider.tf містить Terraform Block та Provider
- RGMain.tf, VNetMain.tf та Subnet_Main.tf містять Resource Block
Тепер давайте детально розглянемо роботу кожного компонента.
Terraform Block
Рис.2: Базова структура Terraform Block
Terraform Block є основою всього проєкту.
Terraform Block містить налаштування та постачальників (providers), які використовуються для надання інфраструктури.
Отже, якщо розглядати реальний приклад, можна сказати, що Terraform Block — це як молодий хлопець, який говорить своєму батькові (Terraform), який велосипед (разом з моделлю) (required_providers) він хоче, коли батько готується купити йому один.
(PS: Я б хотів, щоб переконати батьків у реальному житті було так само легко, як це робить Terraform Block🥲).
Технічно кажучи, блок requiredproviders_ є точкою, що описує всі конфігурації постачальників (providers), які використовуються у проєкті, як це було показано в попередньому прикладі.
Ми можемо ініціалізувати кілька постачальників (providers) всередині блоку requiredproviders_.
Блок requiredproviders_ містить:
- Local name (Локальна назва)
- Місце розташування (Source)
- Обмеження версії (Version constraint)
Рис.3: Базова структура блоку requiredproviders_
Давайте почнемо з розгляду ролі кожного компонента блоку requiredproviders_:
Local Name (Локальна назва)
Поговоримо про концепцію пестливих імен. Коли людині дають пестливе ім'я, це ім’я дозволяють використовувати лише близьким людям. Так само ми можемо сказати, що Local Name (Локальна назва) — це як пестливе ім'я для Providers (Постачальників). Модулі в директорії (що містить сценарії Provider) використовують Local Name, щоб посилатися на Provider.
Source (Місце розташування)
Як вказує назва, source (джерело) виступає як глобальний ідентифікатор, який дозволяє Terraform знайти та завантажити потрібного постачальника (provider) з Інтернету.
Типовий source (джерело) виглядає за таким синтаксисом: [/]/. Зазвичай ми надаємо перевагу запису /.
Повністю кваліфікована адреса — це назва, яку використовують для позначення джерела, що містить всі три компоненти (hostname, namespace та type).
Розглянемо кожен елемент у синтаксисі:
- Hostname (Ім’я хосту): Це необов'язкове значення. Зазвичай ми не вказуємо значення hostname. За замовчуванням Terraform вважає його registry.terraform.io.
- Namespace (Простір імен): У випадку з Provider Block (Блоком постачальника), namespace позначає назву організації, яка опублікувала цей постачальник.
- Type (Тип): Для Provider Blocks (Блоків постачальника) Type визначає назву постачальника, яку використовують для виклику з реєстру Namespace, що містить цей постачальник.
Примітка: Local Name (Локальна назва) та Source (Місце розташування) виступають як унікальні ідентифікатори для постачальника (provider). Головна різниця в тому, що Local Name (Локальна назва) ідентифікує постачальника на локальному рівні (всередині директорії), а source (джерело) дозволяє Terraform знайти постачальника через реєстр Terraform.
Version (Версія)
Можливо, ви думаєте, що «версія» просто означає версію постачальника (provider), яку використовує Terraform. Так, це вірно, але це лише часткова правда. Давайте дізнаємося більше (PS: Давайте розберемо правду добре 😉).
Семантичне версіонування (Пояснення про версії)
Семантичне версіонування або SemVer — це поширений спосіб позначення версій програмного забезпечення.
Формат SemVer виглядає як Major.Minor.Patch. Якщо у нас є програмне забезпечення з версією X.Y.Z, то:
X — це Основна версія (Major Version). Основна версія визначає зміни, які можуть зламати API.
Y — це Мінорна версія (Minor Version). Мінорна версія визначає невеликі оновлення, що не ламають API.
Z — це Патч-версія (Patch Version), яка визначає виправлення помилок.
Примітка: Хоча зміни, зроблені як доповнення, зазвичай не вважаються руйнівними змінами, руйнування API в програмному забезпеченні означає зміну або видалення існуючої частини API.
Як Terraform обробляє версії? 🧐
Terraform пропонує два способи версіонування за допомогою:
- Оператор ~> вказує як основну, так і мінорну версію, дозволяючи оновлювати лише патчі.
Припустимо, ми маємо ~>3.1.0; ми можемо посилатися на це як X.Y.0, де X та Y координати зафіксовані. Зміни будуть помітні тільки в останній позиції. - Оператор >= дозволяє вказати тільки мінімальні версії. Використовуючи оператор >=, версія може автоматично оновлюватися за потреби.
Припустимо, ми маємо >=1.0.0; Terraform може автоматично встановити версію 2.1.0.
Цю техніку використовуємо лише тоді, коли хочемо, щоб наш модуль працював з новішими версіями (постачальника (provider)), і якщо він (модуль) не залежить від специфічних функцій або патчів помилок, що відносяться до певної версії (постачальника (provider)).
Тепер, перед тим як рухатись далі, давайте подивимось на практичне порівняння між двома, щоб теорія стала зрозумілішою 🧑🏫:
Рис.4: Використання оператора ~>
terraform init показує, що оператор ~> використав обмеження і ініціалізував версію 3.0.2, що означає, що змінюється тільки Patch Version (Патч-версія), в той час як основні та мінорні версії залишаються незмінними.
Рис.5: Використання оператора >=
Коли ми запускаємо terraform init, ми можемо побачити, що оператор >= використовував обмеження для інформування Terraform про мінімальну необхідну версію. Terraform ініціалізував версію 4.14.0, що є вищою за обмежену версію.
Я розумію, що це може здаватися трохи страшним, але не хвилюйтеся, ми охопили найскладніший і найбільш витратний за часом аспект; решта частини містить кілька простих кроків для налаштування і початку роботи ☺️.
Provider Block (Блок постачальника)
Ми використовуємо Provider Block (Блок постачальника) для налаштування постачальника (тобто для визначення, як постачальник працюватиме). Кожен постачальник має свій набір налаштувань, які потрібно конфігурувати, щоб його Provider Block (Блок постачальника) працював.
Рис.6: Базова структура блоку Provider
Resource Block (Блок ресурсу)
Рис.7: Базова структура блоку Resource
Resource Blocks (Блоки ресурсів) дозволяють нам визначати компоненти, які будуть розгорнуті в нашій інфраструктурі. Resource Block (Блок ресурсу) містить аргументи для налаштування параметрів ресурсу.
Resource Block (Блок ресурсу) складається з двох компонентів:
- Resource Type (Тип ресурсу): Resource Type (Тип ресурсу) ідентифікує тип ресурсу, що розгортається в хмарному середовищі.
- Resource Name (Назва ресурсу): Resource Name (Назва ресурсу) — це унікальна назва, призначена для конкретного типу ресурсу. Інші Resource Block (Блоки ресурсів) використовують Resource Name (Назву ресурсу) для посилання на конкретний ресурс у сценарії.
Resource Type (Тип ресурсу) та Resource Name (Назва ресурсу) комбінуються для створення унікального ідентифікатора (Unique ID) для ресурсу. У Рисунку 6, Унікальний ідентифікатор (Unique ID) = azurermresourcegroup.RG.
Створено bigglar на Tenor
Ох, нарешті 😮💨, ми завершили всі базові етапи Фази 1, які потрібно знати перед реалізацією нашої інфраструктури. Тепер перейдемо до важливої частини — реалізації (Implementation) Фази 1 😁
Реалізація
Примітка: У наступних фазах я не буду пояснювати роботу кожної команди, що використовується. Всі команди, що використовуються, були пояснені в моєму попередньому документі (перейдіть за посиланням, щоб отримати доступ).
Крок 1: Запустіть VS Code і створіть директорію. Створіть усі сценарії в цій директорії. Відкрийте термінал у цій директорії та увійдіть в Azure.
(Використовуйте az login для доступу до вашого облікового запису Azure).
Рис.8: Вхід до облікового запису Azure
Крок 2: Виконайте terraform init
Рис.9: Створюються файли .terraform та .terraform.lock.hcl
Примітка: Цей .terraform діє як папка, що використовується для управління постачальниками (providers), модулями тощо.
Крок 3: Виконайте terraform fmt
Крок 4: Виконайте terraform refresh
Рис.10: Створюються файли terraform.tfstate та .terraform.tfstate.lock.info
Крок 5: Виконайте terraform plan
Рис.11: Створюється правильний план інфраструктури
Примітка: Слід зазначити, що команда terraform plan також створює файл terraform.tfstate та terraform.tfstate.lock.info. Але вони будуть видні тільки на короткий час.
Для постійного перегляду файлу terraform.tfstate використовуйте або команду terraform refresh, або terraform apply.
Крок 6: Виконайте terraform apply
Рис.12: Створюється файл terraform.tfstate
Рис.13: Інфраструктура розгорнута
Використовуйте terraform apply –auto-approve, коли виконуєте terraform apply, щоб уникнути постійного введення "yes".
Якщо ви виконаєте terraform apply знову після зміни скриптів (наприклад, збільшення групи ресурсів), ви побачите створення файлу terraform.tfstate.backup
Рис.14: Інфраструктура розгорнута на порталі Azure
Примітка: Команда terraform apply також створює файли terraform.tfstate та terraform.tfstate.lock.info
Крок 7: Виконайте terraform show
Крок 8: Виконайте terraform destroy
Рис.15: Створюється terraform.tfstate.backup
Фаза Друга (What We Deployed and Why It Matters)
Всі основні знання щодо Infrastructure as Code (IaC) завершені. Але, як кажуть, навчання не закінчується. Тому, перед завершенням, давайте розглянемо, яку інфраструктуру ми розгорнули за допомогою Terraform.
Рис.16: Архітектура мережі
Ми розгорнули архітектуру мережі згідно з Рис.15 з конфігурацією Terraform, обговореною в цій статті.
Замість того, щоб занурюватися у технічну мову, я дам вам дуже короткий огляд того, що означає архітектура на Рис.15.
Розглянемо приклад:
Припустимо, ви — Pahadi (широке поняття в Індії для опису людей, які мешкають у містах на або поблизу гір) з Уттаракханду. Додатково, скажімо, ви живете в Муссурі, Уттаракханд. Вашу адресу будинку можна визначити як X/Y біля Library Chowk, і ви там живете.
Весь цей приклад описує фізичний простір, який ви займаєте у Всесвіті. Уявіть світ за межами фізичного контакту, доступний через Інтернет.
Якщо порівняти це, на дуже поверхневому рівні, можна сказати наступне:
- Resource Group (Група ресурсів) = Pahadi з Уттаракханду
У технічних термінах це означає, що всі ресурси, пов'язані з певним проєктом, можна об'єднати в одну групу ресурсів. - Mussoorie (Муссурі) = Virtual Network (Віртуальна мережа)
У технічних термінах це означає, що всі ресурси, такі як віртуальні машини, повинні знаходитися в межах віртуальної мережі. - House (Будинок) = Subnet (Підмережа)
У технічних термінах, навіть якщо всі Pahadi з Муссурі, це не означає, що вони живуть разом; підмережа є аналогом будинку, в якому знаходяться багато ресурсів разом.
4.
Ви = Azure Resource (Ресурс Azure)
У технічних термінах ми створюємо віртуальну мережу та підмережу, щоб надати місце для розміщення ресурсів, таких як віртуальні комп'ютери.
Фаза Третя (Bringing Your Terraform Project to Life)
Файл Provider.tf
# Azure Provider Block
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~>3.0.0"
}
}
}
# Налаштування Microsoft Azure Provider
provider "azurerm" {
features {}
}
Файл RG_Main.tf
resource "azurerm_resource_group" "RG" {
name = var.RG_Name
location = var.RG_Location
tags = var.Tags
}
Файл RG_Var.tf
variable "RG_Name" {
description = "Назва групи ресурсів"
type = string
default = "RG-1"
}
variable "RG_Location" {
description = "Назва локації групи ресурсів"
type = string
default = "Central India"
}
variable "Tags" {
description = "Назва тегу"
type = map(string)
default = {
Environment = "Production"
Department = "Cloud"
}
}
Файл Subnet_Main.tf
# Створена підмережа
resource "azurerm_subnet" "Subnet" {
name = var.Subnet_Name
resource_group_name = azurerm_resource_group.RG.name
virtual_network_name = azurerm_virtual_network.VNet.name
address_prefixes = [var.Subnet_Address_Space]
}
Файл Subnet_Var.tf
variable "Subnet_Name" {
description = "Назва підмережі"
type = string
default = "Subnet-1"
}
variable "Subnet_Address_Space" {
description = "Адресний простір підмережі"
type = string
default = "10.0.0.0/26"
}
Файл VNet_Main.tf
# Створена віртуальна мережа
resource "azurerm_virtual_network" "VNet" {
name = var.VNet_Name
address_space = [var.VNet_Address_Space]
location = azurerm_resource_group.RG.location
resource_group_name = azurerm_resource_group.RG.name
tags = var.Tags
}
Файл VNet_Var.tf
variable "VNet_Name" {
description = "Назва віртуальної мережі"
type = string
default = "VNet-1"
}
variable "VNet_Address_Space" {
description = "Адресний простір віртуальної мережі"
type = string
default = "10.0.0.0/24"
}
Висновок
Привіт! Перед тим, як завершити, хочу зазначити, що цей блог не охоплює налаштування Terraform і Azure CLI. Якщо вам потрібна допомога з налаштуванням на вашій системі, просто дайте знати в коментарях!
Якщо у вас є будь-які питання чи думки щодо цього посібника, не соромтесь звертатися. Ви можете залишити коментар нижче або зв'язатися зі мною:
- Слідуйте за мною на Medium для нових пригод у хмарі
- Знайдіть мене на LinkedIn: KARTIKEYA JAIN
- Перегляньте моє портфоліо на Kartikeya_Jain
Є питання? Зв'яжіться зі мною у Twitter @KARTIKEYA47JAIN або через електронну пошту на [email protected]
Це все на сьогодні!! Ми побудували нашу першу інфраструктуру в Azure за допомогою Terraform, і я сподіваюся, що вам сподобалась ця практична пригода так само, як і мені 😌.
Слідкуйте за новими історіями🤗 — попереду ще багато захопливих пригод у світі інфраструктури!
До зустрічі, нехай інфраструктура буде з вами🚀
Перекладено з: Mastering Terraform on Azure: A Step-by-Step Guide for Beginners