AWS CDK Constructs: English Vocabulary for Infrastructure as Code (англійською)

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

Три рівні конструкторів

Найважливішим концептуальним словником в CDK є ієрархія конструктів. Інженери постійно говорять про L1, L2 і L3 конструкції.

1-й рівень (конструкторський)

** L1 конструкт ** є прямим, низькорівневим представленням ресурсу CloudFormation. Назва походить від « Level 1 ». Конструкції L1 надають вам повний контроль, але вимагають від вас явного вказування кожної властивості.

«Ми впали до L1 конструкції для дозволу Lambda, тому що L2 ще не виставив властивість FunctionUrlAuthType»

Фраза drop down to (або fall back to) L1 є дуже природною — вона означає, що ви переходите на нижчий рівень абстракції за необхідності.

L2 Конструкт (направлений на мету)

L2 конструкт є абстрактною, вищого рівня абстракцією, яка інкапсулює розумні типові значення і виставляє чистіший API. Більшість інженерів CDK працюють на цьому рівні з дня в день.

“Конструкція aws_s3.Bucket L2 автоматично встановлює шифрування на стороні сервера за замовчуванням. Ви повинні чітко відмовитися, якщо ви цього не хочете»

Ключові фрази: встановлює здорові типові значення, оцінює, націлений на намір, включає в себе стандарт.

Конструктор L3 (Pattern)

L3 конструкт — також званий патерном — збирає декілька ресурсів в архітектуру повторного використання. Вони часто походять від aws-solutions-constructs або написані вдома.

«Ми побудували L3 конструкцію, яка забезпечує API Gateway, Lambda функцію, і DynamoDB таблицю разом — з усіма IAM проводами, що обробляються внутрішньо.»

Втеча Хетч

** escape hatch ** — це механізм CDK, який надає вам змогу отримати доступ до основного ресурсу CloudFormation і змінити його, якщо абстракція L2 або L3 не надає вам необхідних даних.

«Ми мусили використовувати люк для виклику, щоб встановити сиру властивість CloudFormation, яку L2-конструкція не вивела на поверхню. Це не ідеальне, але це працює»

Термін походить від ідеї «втечі» від абстракції. У перегляді коду ви почуєте: * « Чи можемо ми уникнути аварійного люку? Можливо, є більш чистий спосіб використання L2 API.”*

Стейк і апп

Stack

** Стек ** є одиницею розгортання в CDK — він безпосередньо відображається на стеку CloudFormation. Інженери говорять про стеки як про контейнери для пов’ язаних ресурсів.

«Ми розділили VPC на свій власний стек, щоб інші стеки могли посилатися на нього без повторного розгортання мережі кожен раз»

Поширені дієслова: deploy a stack, synthesize a stack, destroy a stack, reference across stacks.

App

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

«Програма створює три стека: один для мережі, один для шару API, і один для шару даних»

Synthesis

** Синтез ** (дієслово: ** синтезувати **) — це процес перетворення вашого коду CDK на шаблони CloudFormation. Це відбувається перед розгортанням.

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

Також ви почуєте synth як скорочення: * « Запустити cdk synth і перевірити, який шаблон CloudFormation він створює. » *

Bootstrapping

Bootstrapping це одноразовий процес налаштування, який готує обліковий запис AWS і регіон для розгортання CDK — він створює контейнер S3 і ролі IAM, які CDK повинен обслуговувати.

“Конвейєр зазнав невдачі в новому обліковому записі, тому що ніхто ще не запустив cdk bootstrap. Середовище стажування не було завантажене»

Поширеною помилкою є плутати завантаження (налаштування облікового запису) з розгортанням (запуск cdk deploy ). У розмовах: “Цей обліковий запис завантажений?” є стандартним діагностичним питанням.

Акціонерне товариство

** З’ єднання активів ** стосується процесу пакування коду програми — функцій Lambda, зображень Docker — як частини збирання CDK. CDK може зберігати активи локально або в Docker.

“Складання пакетів активів сповільнює наш CI-канал. Ми розглядаємо використання bundling.image з нетиповим зображенням Docker для кешування шару node_modules»

Cross-Stack References (англійською)

** Cross- stack reference ** це коли один стек CDK експортує значення (наприклад, VPC ID або ARN), яке інший стек імпортує і використовує.

«Будьте обережні з крос-стековими посиланнями — якщо ви перейменуєте експорт, CloudFormation відмовиться від розгортання, поки ви не оновите всі стеки, які його імпортують»

Тут ви зрозуміли фразу: * « CloudFormation відмовиться від розгортання » * — це природне і пряме, а не * « CloudFormation не зможе розгортатися » *

Контекст CDK

** Context ** у CDK є сховищем ключів і значень для значень налаштування — таких як ідентифікатори облікових записів, назви середовищ або прапорці можливостей. Він зберігається в cdk.context.json.

«Ми використовуємо CDK context для введення назви середовища в час синтезу. Ті ж самі коди стека розгортаються для dev, staging і prod з різними контекстними значеннями»

Перегляд коду Фрази для IaC

** Запит на нижчий рівень абстракції: **

• “Це може бути конструкція L2 — чи дійсно нам потрібно налаштовувати кожну властивість CloudFormation вручну?”

Правка аварийного люка:

• “Ми використовуємо тут аварійний люк. Давайте додамо коментар, що пояснює, чому L2 API недостатньо.”

** Обговорення крос-стека: **

• • “Я не хочу створювати посилання на крос- стек для цього. Це щільно з’єднує ці два стеки і робить вилучення стека болючим.”*

** Проблеми синтезу: **

• “Вивід синтезатора виглядає коректно, але давайте порівняємо його зі стеком, який було розгорнуто, перед тим, як застосувати: cdk diff.”

Ключові слова

Collocation	Usage context
drop down to an L1	when the L2 abstraction is insufficient
synthesize a stack	converting CDK code to CloudFormation
bootstrap an account	one-time account preparation for CDK
bundle assets	packaging Lambda code or Docker images
reference across stacks	cross-stack output/import pattern
expose a property	when a construct surfaces a config option
escape the abstraction	use an escape hatch to access raw CFN

Practice

Візьмемо конструкцію CDK, яку ви написали нещодавно — навіть простий контейнер S3 або Lambda. Напишіть три речення з описом англійською мовою: який рівень конструкції це, які типові значення воно встановлює, і чи потрібні вам якісь шлюзові клавіатури. Потім напишіть одне речення, яке ви можете сказати про це в обзоре кода. Сфокусуйтеся на використанні колокації з цього посту, а не перекладайте українські структури речень безпосередньо.

Розрізняють: розуміння мовлення; розуміння мовлення в мовленнєвому процесі

Будьмо чесними - навіть з чітким розумінням * технічних * концепцій за AWS CDK, ефективне спілкування про вашу інфраструктуру як код все ще може відчувати… виклик. Точна мова, яку використовують під час перегляду коду, коли пояснюють рішення про проектування колегам, або навіть просто документують те, що ви побудували, часто є неймовірно нюансована. Для розробників, чия перша мова не є англійською, це може бути особливо складно. Це не просто про те, щоб знати визначення «конструювати» і «складати»; це про те, щоб розуміти як ці слова використовуються в професійному контексті - тонкі наслідки за ними.

Уявіть, що ви отримуєте коментар про перегляд коду, наприклад: «Це CDKConstruct визначення надто багатослівне. Розгляньте рефакторинг, щоб використовувати більш короткий, декларативний синтаксис для поліпшення читабельності.” На перший погляд, це здається простим, але що означає « короткий » * насправді * в цій ситуації? Це не просто означає довжину; це говорить про те, що код не такий чіткий або ефективний, яким він міг би бути. Аналогічно, повідомлення Slack, що запитує «Чи можете ви пояснити логіку розгортання функції Lambda безпосередньо в стеку?», Вимагає більше, ніж просто відповідь «так/ні». Питання проаналізовує, чому був зроблений цей конкретний вибір — основні роздуми щодо дизайну. Ключовим є визнання того, що ці фрази не є довільними; вони несуть конкретні очікування щодо ясності, підтримки та відповідальності. Навчання правильно їх інтерпретувати є ключовим. Також важливо розуміти різницю між заявою про проблему («Це не відповідає нашим вимогам безпеки») і пропозицією рішення («Давайте реалізуємо роль IAM з найменш привілейоване доступ»).

Іншим поширеним сценарієм є написання описів PR. Хороший опис — це не просто список змін; це розповідь, яка пояснює що було змінено, чому це було змінено, і як це сприяє загальним цілям проекту. Наприклад: «Впроваджено нову політику S3 bucket для обмеження доступу до конфіденційних даних у стеку програм. Це відповідає найкращим практикам безпеки нашої організації і зменшує потенційні ризики, пов’ язані з несанкціонованим отриманням даних. » Зауважте, що у цьому описі використовуються такі фрази, як « зменшує потенційні ризики » — поширений спосіб позначення технічних вдосконалень у бізнес- термінах, підкреслюючи їх цінність.

// Example CDK Construct - S3 Bucket Creation
import * as cdk from 'aws-cdk-lib';
import * as s3 from 'aws-cdk-lib/aws-s3';

export class MyS3Bucket extends cdk.Construct {
  public readonly bucket: s3.Bucket;

  private constructor(scope: cdk.Scope, id: string) {
    super(scope, id);
    this.bucket = new s3.Bucket(this, 'MyBucket', {
      removalPolicy: cdk.RemovalPolicy.DESTROY, // Important for cleanup!
    });
  }
}

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