Англійська для інфраструктури як код

Інфраструктура як код (IaC) - це практика управління інфраструктурою через файли визначення, які можна читати машиною, а не ручні процеси. Такі інструменти, як Terraform, Pulumi, AWS CDK і Ansible створили спільний словник, який перетинає хмарних провайдерів і організацій.

Цей посібник містить основні терміни IaC з прикладами їх використання у технічній англійській мові — у перегляді коду, документації і обговоренні архітектури.

---

Основні концепції ІАК

Інфраструктура як код

** Інфраструктура як код ** означає визначення інфраструктури (серверів, мереж, баз даних, балансувальників навантаження) у коді — за допомогою файлів налаштувань або мов програмування — так, щоб її було можливо автоматично контролювати, переглядати, перевіряти і розгортати.

• “До IaC, облаштування нового середовища займало два дні ручної роботи. Тепер це terraform apply, який завершується менш ніж за двадцять хвилин.»*
• “Всі зміни в інфраструктурі проходять через процес запитів на звантаження, так само як і код програми. Не дозволено робити зміни в консолі вручну.”*

Idempotency

Операція idempotent дає той самий результат незалежно від того, скільки разів її застосовують. Інструменти IaC розроблені таким чином, щоб бути ідемпотентними — запуск apply кілька разів з тією ж конфігурацією не повинен створювати додаткові ресурси.

• “Скрипт не є ідемпотентним — його двічі запуск створює дублікат правил групи безпеки. Нам потрібно додати перевірки існування.»* “Дія Terraform apply є idempotent: якщо інфраструктура вже відповідає бажаному стану, вона не робить ніяких змін.”

---

Терраформ Workflow Vocabulary (англійською)

Plan

terraform plan (або еквівалент в інших інструментах) генерує попередній перегляд змін, які будуть внесені до інфраструктури, не роблячи їх фактично.

“Завжди виконуйте plan перед apply у виробничих умовах — це дає вам змогу отримати зрозумілий для людини попередній перегляд того, що саме буде змінено, створено або знищено.” “План показав, що 40 ресурсів будуть знищені і відтворені. Це викликало розмову з командою, перш ніж ми продовжили.»

Apply

terraform apply виконує зміни, описані в плані, і приводить інфраструктуру в бажаний стан.

“Ми запускаємо apply через конвеєр CI після того, як план був переглянутий і схвалений в запиті на витягування.” “Ніколи не виконуйте apply вручну у виробничих умовах — всі програми проходять через автоматизований конвеєр з обов’ язковим воротом схвалення.”

Destroy

• “Ми запустили terraform destroy на стаціонарному середовищі, щоб заощадити кошти на вихідних. Середовище відновлюється в понеділок вранці через трубопровід. “*

---

State

Державний архів

Файл state (в Terraform: terraform.tfstate ) є записом того, що інфраструктура Terraform вважає існуючим. Він відображає визначення ресурсів на реальні об’ єкти інфраструктури.

• “Файл стану є джерелом правди для Terraform. Якщо він вийде з синхронізації з реальною інфраструктурою, план Terraform буде неправильним. ”* “Ми зберігаємо файл стану в віддаленому сервері — контейнері S3 з блокуванням DynamoDB — тому вся команда має один і той же стан.”

Блокування стану

** Блокування стану ** запобігає двом паралельним операціям змінювати інфраструктуру одночасно і пошкоджувати стан.

• “Конвейєр зазнав невдачі, оскільки інше застосування вже було в процесі виконання і отримало блокування стану. Зачекайте, поки він завершиться, перш ніж спробувати знову.»*

Національний дрифт

** Дрейф ** (або ** Дрейф стану **) відбувається, коли фактична інфраструктура відхиляє від стану, який інструмент IaC вважає існуючим — зазвичай, це спричинено вручну змінами, зробленими поза робочим потоком IaC.

“Задача виявлення дрейфу виконується щоночі і повідомляє про будь-які відмінності між станом Terraform і фактичними налаштуваннями ресурсів AWS. Будь-який дрейф розглядається як помилка.»

• “Хтось вручну додав правило вхідних даних до групи безпеки. Terraform виявив дрейф і позначив його як несподівану зміну конфігурації. “*

---

Модулі та організація

Module

** Модуль ** є повторно використовуваним, інкапсульованим блоком коду IaC. Модулі сприяють послідовності і зменшують дублювання, дозволяючи командам ділитися стандартними шаблонами інфраструктури.

“У нас є спільний модуль для створення стандартної служби ECS — він створює визначення завдання, службу, групи безпеки і групу журналу CloudWatch з відповідними типовими значеннями.” “Модул мережі підтримується командою розробників платформи і використовується всіма командами розробників продукту для забезпечення послідовної конфігурації VPC.”

Кореневий модуль проти Дочірній модуль

• ** Кореневий модуль ** — це каталог верхнього рівня, у якому ви запускаєте Terraform.
• ** Дочірній модуль ** — це будь- який модуль, викликаний з кореня або з іншого модуля.

• “Кореневий модуль викликає три дочірніх модулі: один для мережі, один для бази даних, і один для рівня програми.” *

---

Життєвий цикл

Життєвий цикл

** Цикл життя ресурсу ** описує, як створюється, оновлюється і знищується ресурс. Інструменти IaC керують циклом життя автоматично на основі змін налаштувань.

• “Зміна типу екземпляра бази даних RDS у Terraform викликає заміну — стара база даних буде знищена, а нова створена. Переконайтеся, що ви розумієте наслідки життєвого циклу перед зміною цього поля.”*

create_before_destroy

Таке налаштування життєвого циклу забезпечує створення нового ресурсу до знищення старого, що корисно для заміни ресурсів без перерв.

“Ми додали create_before_destroy до цільової групи ALB, щоб нова група була зареєстрована до того, як стара буде скасована.”

prevent_destroy

• “Ми додали prevent_destroy = true до виробничого екземпляра RDS. Тепер Terraform відмовляється знищувати його, навіть якщо хтось випадково вилучить його з конфігурації. “*

---

Практичні фрази для роботи з IaC

• “Всі зміни в інфраструктурі слід вносити за допомогою IaC — ніяких змін у консолі вручну.”
• • “План виглядає чистим — змінюються лише очікувані ресурси. Я згоду заявляю.”*
• • “В мережевому шарі є дрейф. Хтось змінив групу безпеки вручну.”*
• • “Ми видобили налаштування бази даних у модуль, який можна використовувати повторно і який можна поділити між усіма середовищами.” *
• • “Стан зберігається віддалено у S3. Блокування стану ввімкнено через DynamoDB.”*
• • “Ця зміна призведе до заміни. Нам потрібно вікно обслуговування.”*

---

IaC лексика стала стандартом у хмарній інженерії. Правильне використання цих термінів дозволяє вам вносить свій внесок у бази кодів IaC, переглядати запити на витягування інфраструктури і обговорювати зміни конфігурації хмари з точністю і впевненістю.

Національна стратегія розвитку: стратегія та стратегічні напрямки

Будьмо чесними - навіть досвідчені інженери інфраструктури можуть наткнутися на правильну фразу, коли спілкуються про код. Для людей, які не є носієм англійської мови, вивчаючи професійний словник, пов’ язаний з інфраструктурою як кодом (IaC), це не просто про те, щоб знати визначення « модуля » або « стану ». Це про розуміння * як * ці поняття обговорюються в спільному середовищі, особливо під час перегляду коду і командного спілкування. Здається простою фразою може радикально змінити значення залежно від контексту, що призводить до непорозумінь і затримок.

Однією з поширених пасток є припущення, що всі розуміють наслідки « імпотенції ». Хоча технічне визначення — що застосування тієї ж конфігурації декілька разів дає той же результат — є ясним, ефективне описання його у повідомленні Slack або описі PR вимагає більшої витонченості. Замість того, щоб просто вказати « Цей модуль є ідемпотентним », розгляньте можливість сформулювати його так: « Повторне застосування цієї конфігурації * завжди * призведе до ідентичного стану інфраструктури, запобігаючи небажаним змінам ». Це підкреслює * переваги * ідемпотентності — уникнення несподіванок і забезпечення передбачуваного розгортання. Аналогічно, під час обговорення « виявлення дрейфу », уникайте технічного жаргону, наприклад, « моніторинг відхилень ». Поясніть це вашій команді, сказавши: « Ми реалізували виявлення дрейфу, щоб проактивно визначати будь- які відхилення від нашої запланованої конфігурації інфраструктури, що дозволяє нам вирішувати проблеми до того, як вони вплинуть на доступність послуг »

Інша проблема, яка часто виникає, пов’ язана з концепцією « життєвого циклу ресурсу ». Розробники часто використовують такі терміни, як « створення », « модифікація » і « вилучення » — ці терміни цілком прийнятні окремо, але можуть викликати плутанину під час обговорення переходів. Краще описати його як « повний шлях ресурсу, від його початкового створення через зміни конфігурації і, врешті-решт, його виведення з експлуатації ». Цей цілий погляд допомагає кожному зрозуміти повний обсяг операцій і потенційних залежностей.

Нарешті, пам’ятайте, що короткість не завжди найкраща. Під час написання описів PR, розробляйте трохи - особливо якщо ви вводите нову термінологію або пояснюєте складну логіку. Ясність переважає короткість, коли йдеться про забезпечення спільного розуміння у вашій команді. Метою є не лише передати * те, що * ви зробили, але також і * чому * і * як * це сприяє загальній стабільності і підтримці інфраструктури.

Ось приклад команди terraform, яку використовують у сценарії, де використовується виявлення дрейфу:

resource "aws_instance" "webserver" {
  ami           = "ami-0c55b497628f51d3a"
  instance_type = "t2.micro"
  tags = {
    Name = "Web Server Instance"
    DriftDetected = true # Simulate drift detection triggered by a configuration change
  }
}

Це демонструє, як навіть здавалося б прості теги можуть бути використані для повідомлення про намір і запуску автоматизованих процесів, таких як попередження про виявлення дрейфу, що є ключовою концепцією для проактивного управління інфраструктурою.