В настоящее время нет никаких сомнений в том, что «Инфраструктура как реальный код» - это способ выделения облачных ресурсов. CDK - отличный способ сделать это в экосистеме AWS. В этой статье будет рассказано о ситуации, когда есть шаблон CloudFormation, и вы хотите выполнить новую настройку с CDK с использованием TypeScript. Мое мнение принадлежит мне.

Дело

Представим, что у вас есть новый проект в команде, где CFN использовалась долгое время. Уже существует множество шаблонов, и люди повторяют одно и то же снова и снова. Также существует некоторая пользовательская настройка CI / CD. На этом фоне вы готовы начать новый проект с CDK. В восторге? Я тоже. Но есть некоторые сложности, потому что CFN - это механизм шаблонов на основе YAML / JSON. Короче говоря, CDK - это абстракция поверх CFN, которая использует язык программирования для структурирования инфраструктуры. Вот мои советы о том, как начать переход с Cloudformation / SAM после использования инструмента в течение почти года.

Начни с небольшого проекта

Рассмотрим проект без множества элементов. Старайтесь избегать проектов, в которых вам необходимо самостоятельно настроить VPC. Также будет лучше избегать проектов с оркестровкой контейнеров с использованием ECS или Kubernetes. Идеальным первым проектом будет тот, у которого есть разрешения S3, Lambda, CloudFront, API Gateway, DynamoDB и IAM. Примеры проектов могут быть:

  • Запланированное событие, размещение данных в S3 / DynamoDB
  • Событие из Github / Bitbucket
  • Вызов API для выполнения некоторой простой работы, например, маршрутизации запроса другой стороне.

Еще один важный момент - использовать CDK версии 2. x. В большинстве руководств будет предложено использовать первое. Он устарел и имеет много проблем с зависимостями. Опыт развития будет намного приятнее. Для его установки - запустить:

npm install cdk@next

Изучите основные концепции CDK

Когда дело доходит до CDK, существует несколько важных терминов. Первый - «Приложение». Это корневой элемент конструкции. Там вы можете описать стеки и их создание.

Самый интересный концепт - это конструкт. Из документов AWS:

Конструкции - это основные строительные блоки приложений AWS CDK. Конструкция представляет собой «облачный компонент» и инкапсулирует все, что необходимо AWS CloudFormation для создания компонента.

По сути, это модуль ресурсов, собранных вместе как логическая единица. Конструкции имеют разные уровни абстракции. Есть те, которые наиболее близки к CloudFormation. Как правило, у них плохой набор текста.

Есть 3 уровня абстракции:

  • Ресурсы CFN - они отображаются на подчеркнутые ресурсы CFN.
  • 2 уровень - дают абстракции и набор текста. Конструкции также могут быть взяты из библиотеки здесь. Многие конструкции позволят иметь типы и делать меньше ошибок.
  • Уровень 3 - это целые паттерны. Они могут быть выполнены AWS или другими разработчиками. Те, что исходят от защитников и героев AWS, можно найти здесь.

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

Планирование штабелей

Еще один важный момент - иметь представление о том, сколько стеков вам понадобится для успешного предоставления инфраструктуры. Один стек во многих случаях бесполезен. Это означает, что стеки должны иметь такую ​​архитектуру, чтобы каждый из них решал одну проблему. Может возникнуть проблема при определении того, использовать ли конструкцию или стек.

Согласно документации AWS: Стек - это набор ресурсов AWS, которыми можно управлять как единым целым. Когда у вас есть API с лямбдами - это может быть стек. Однако, если у вас есть базы данных и другие типы хранилищ - это может быть другой стек.

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

Всегда проверяйте оригинальную документацию

CDK просто потрясающий, с моей точки зрения. Но это не спасает нас от чтения и понимания Cloudformation. Де-факто CDK синтезирует шаблон CloudFormation в формате JSON. Таким образом, обязательно видеть, что он делает для нас.

В официальной документации, когда вы ее читаете, спрятаны отличные уловки. В большинстве случаев я ищу в Google что-то вроде «AWS :: DynamoDB :: Table». В ответе будет указана необходимая страница документации для элемента инфраструктуры.

Неудачи важны

Мое путешествие с CDK началось с неудачного развертывания, когда я попытался создать корзину S3. На его развертывание ушло 15 минут, но безуспешно. Вначале нормально потерпеть неудачу с CDK. Не стоит торопиться и сразу перенести все приложение.

Во время одного из проектов я выполнял настройку CI / CD с SAM и CloudFormation. Полная миграция на CDK потребует времени от фактической разработки функции. Таким образом, решение заключалось в том, чтобы перенести инфраструктуру кода реализации на CDK и оставить конвейер с той же настройкой. Я многому научился во время этого перехода для следующего проекта, в котором я перенес всю инфраструктуру в CDK.

В общем, CDK стоит попробовать на следующем PoC или внутреннем инструменте, потому что он дает реальный опыт кодирования при создании инфраструктуры. Это особенно важно, когда вы собираетесь использовать образ мышления DevOps для новых функций, когда инженеры несут ответственность не только за реализацию. Использование одного и того же языка для инструмента IaC исключает переключение контекста между TypeScript и YAML. Таким образом, повысится продуктивность всей команды.

Больше контента на plainenglish.io