Теперь, давайте будем честными, есть несколько несгибаемых поклонников терраформирования. Есть также заядлые поклонники CDK, и этот пост, вероятно, субъективен, но я попытаюсь рассмотреть его с логической точки зрения с плюсами и минусами.

Почему это сравнение

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

Тогда зачем мне CDK, а не Terraform, если Terraform настолько универсален. Ну, для изменчивости. Terraform с его HCL и модулями делает повторное использование более проблематичным, чем CDK.

Разница

Во-первых, давайте взглянем на общий файл terraform.

provider "aws" {
  region = "us-east-1"
}
resource "aws_iam_role" "medium_tf_role" {
  name = "test-role"
}

Теперь давайте сравним это с CDK.

import * as cdk from '@aws-cdk/core';
import { Bucket } from '@aws-cdk/aws-s3'
import { Duration } from '@aws-cdk/core';
export class MediumS3Bucket extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const bucket = new Bucket(this, 'MediumS3', {
      versioned: true
    })

    bucket.addLifecycleRule({
      enabled: true,
      id: 'MediumLifeCycle',
      expiration: Duration.days(2)
    })
  }

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

С CDK у вас есть почти все функциональные возможности вашего языка (в данном случае typescript). Хотя это может показаться не таким уж большим, но он уже дает вам широкий спектр инструментов для использования. Это не означает, что вы можете использовать все, что есть на вашем языке. Например, в typescript/javascript асинхронные объявления почти невозможны, но это все же дает вам большую гибкость по сравнению с HCL.

Еще одним преимуществом CDK являются методы построения или методы ресурсов. В приведенном ниже примере с CDK вы можете использовать методы для своей конструкции/ресурса, когда по сравнению с Terraform у вас нет такой возможности.

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

В терраформе:

provider "aws" {
  region = "us-east-1"
}
resource "aws_iam_role" "medium_tf_role" {
  name = "test-role"
}
resource "aws_iam_policy" "medium_tf_policy" {
  name = "test-policy"
  policy = "SOME JSON POLICY HERE"
}
resource "aws_iam_policy_attachment" "medium_tf_attachment" {
  name = "test-attach"
  roles = [aws_iam_role.medium_tf_role.name]
  policy_arn = aws_iam_policy.medium_tf_policy.arn
}

В машинописном тексте CDK:

const myRole = new Role(this, 'MediumRole', {
  assumedBy: new ServicePrincipal('ec2.amazonaws.com')
})
myRole.addManagedPolicy(new ManagedPolicy(this, 'MediumPolicy', {
  statements: [
    new PolicyStatement({
    actions: ['sns:SubScribe'],
    resources: ['*']
    })
  ]
}))

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

Петля Терраформ:

variable "users" {
  type = list(string)
  default = ['Mo', 'Dave', 'Sam']
}
resource "aws_iam_user" "creating-user" {
  count = length(var.users)
  name  = var.users[count.index]
}

Цикл CDK машинописи:

import { User } from '@aws-cdk/aws-iam'
const names: string[] = ['Mo', 'Dave', 'Sam']
names.forEach((name) => {
  new User(this, `creating-user${name}`, {})
})

При создании ресурса из цикла for обычный программист/человек предположил бы, что вы будете перебирать этот список/массив, а не ресурс, перебирающий список/массив для вас. Мало того, при терраформировании имена ресурсов становятся create-user.1, create-user.2 и create-user.3, что не очень чисто.

По сравнению с CDK для фактического создания ресурса вы сначала выполняете итерацию по массиву строк и создаете ресурс с переменной цикла в имени ресурса. Это значительно упрощает отслеживание по сравнению с именами ресурсов, такими как creating-user.1, и значительно облегчает понимание в целом.

Преимущества Терраформ

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

В Terraform, если вы выводите значение, любой из любого другого терраформа, если у него есть доступ к вашим состояниям терраформирования, он может извлечь это значение по мере необходимости. CDK требует, чтобы вы находились в той же среде (учетная запись, а иногда и регион).

Terraform также имеет большой список провайдеров, просто посмотрите на ссылку ниже, с ней сложно конкурировать.

https://registry.terraform.io/browse/providers

Преимущества CDK

Почти полное использование языка программирования по вашему выбору (python, машинописный текст, javascript, C# и скоро будет доступно и в Go). Который, если любой разработчик привык к любому из вышеупомянутых языков, должен легко читаться.

Это делает CDK лучшим инструментом, поскольку вы позволяете другим, которые могут не разбираться в AWS, вносить изменения, не разбираясь в нюансах HCL.

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

Вы также можете написать свой собственный пользовательский ресурс, который может быть практически для любого сервиса AWS, у которого еще нет конструкции. см. https://docs.aws.amazon.com/cdk/api/latest/docs/custom-resources-readme.html

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

См. конструкцию DataDog здесь: https://constructs.dev/packages/datadog-cdk-constructs/v/0.5.0?lang=typescript

Почему ЦДК?

Из-за своей гибкости. Скорее всего, вы никогда не будете ждать, пока обновятся typescript, python, javascript или c#, чтобы вы могли написать свой IAC (инфраструктура как код) определенным образом.

Спасибо за чтение.