如何使用Terraform/Cloudformation连接AWS数据库迁移服务和Kinesis数据流？

Question

我正在尝试将本地SQL Server 2016 Enterprise Edition实例中的数据获取到云中。我遇到了一个障碍，所以如果有人对解决方法有任何指导，我真的很感谢你分享你的知识！

我计划使用AWS数据库迁移服务（aws.amazon.com），在这篇文章中我将其称为“DMS”。出于监管原因，数据库必须保持在本地，因此我需要不断地从该数据库中捕获数据并将其发送到云端。在这方面，我将使用更改数据捕获（docs.microsoft.com）。

这个用例在DMS文档中被明确调用，因此它似乎是合适的工具。此外，我从2018年的这篇博文中看到，运动数据流是DMS的有效目标。那太好了；我想使用Kinesis来处理CDC下游的数据。

问题是在DMS目标的Terraform文档（terraform.io）中没有将Kinesis作为endpoint选项类型。这是Terraform github项目（github.com）的一个问题，其他人已经注意到了同样的事情。以及相关的PR（github.com），看起来它应该提供一个修复程序。虽然它似乎取决于另一个修复程序，所以我没有屏住呼吸。

现在，一些具体问题：

1. 在github问题下面的帖子中，有人提到使用云形态和地形的混合体。一些快速搜索会抛出aws\u cloudformation\u堆栈（terraform.io）作为实现这一点的一种方法。对吗

Answer 1

不确定回答自己的问题是否有礼貌，（Meta有点不清楚（Meta.stackexchange.com））[https://meta.stackexchange.com/questions/17845/etiquette-for-answering-your-own-question]下面是：

将DMS和Kinesis数据流与Terraform CloudFormation连接

aws_cloudformation_stack确实有效。CloudForm实际上相对简单。下面的第一个代码块显示了我的Terraform。我正在使用Terraform 0.12的templatefile函数将参数插入CloudForm JSON。您在哪里看到

resource "aws_cloudformation_stack" "kinesis_target" {
  name = "xxx-xxx-kinesis-target"

  template_body = templatefile("kinesis-target-stack.json.tpl",
    {
      identifier_alphanumeric = "<Xxx><Xxx>KinesisTarget",
      identifier              = "<xxx>-<xxx>-kinesis-target",
      access_role_arn         = aws_iam_role.dms_data_stream_role.arn,
      stream_arn              = "${data.terraform_remote_state.data_stream.outputs.arn}",
      output_alphanumeric     = var.kinesis_dms_target_arn_output_key
    }
  )
}

需要进一步注意的是，output\u alphanumeric是与此堆栈创建的组件的ARN关联的键的名称。事实证明，在Terraform代码的其他地方使用此值并不完全简单。请参阅（数据源：aws\U cloudformation\U stack（terraform.io））[https://www.terraform.io/docs/providers/aws/d/cloudformation_stack.html].

这带来的复杂性是，您必须在代码中显式声明依赖项，否则当Terraform尝试将该值插入代码库的其他位时，CloudForm堆栈的输出将不可用。或者，您将不得不逐个推出您的更改，注释和非注释资源以手动满足依赖项。恶心。

CloudFormation JSON非常简单：

{
  "Resources": {
    "${identifier_alphanumeric}": {
      "Type": "AWS::DMS::Endpoint",
      "Properties": {
        "EndpointIdentifier": "${identifier}",
        "EndpointType": "target",
        "EngineName": "kinesis",
        "KinesisSettings": {
          "MessageFormat": "json",
          "ServiceAccessRoleArn": "${access_role_arn}",
          "StreamArn": "${stream_arn}"
        }
      }
    }
  },
  "Outputs": {
    "${output_alphanumeric}": {
      "Description": "ARN of DMS Target for Kinesis Data Stream",
      "Value": { "Ref" : "${identifier_alphanumeric}" },
      "Export": {
        "Name": "${output_alphanumeric}"
      }
    }
  }
}

需要注意的是，虽然（AWS：：DMS：：Endpoint docs（docs.AWS.amazon.com））[https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dms-endpoint.html]声称EngineName属性是必需的，并且它只能是所提供列表中的一个值（不包括运动学），但事实并非如此。

为了清楚起见，我将Engineering Name留在了那里，并期望有一天kinesis会被添加到列表中，并且可能会收紧验证规则。事实上，我还没有尝试在没有Engineering Name存在的情况下部署这个基础设施。尽管如此，推出它没有问题。

所以，这回答了我的问题（1）。

我还没有尝试用Terraform来表达这一点，这样会简洁得多，并且无需明确说明资源之间的依赖关系。我不确定Terraform是否会在CloudForm之外进行engine_name验证；如果是，CloudForm方法可能是目前最好的。如果不是，我宁愿将上述内容重写为纯Terraform。与此同时，我所拥有的工作。

这也回答了我的问题（2）。我不需要屏住呼吸等待这些修复被合并。

仍然打开（3）输入！我还没有得到端到端验证DMS是否能按预期工作，因为我被一个网络问题阻止了。一位评论家对DMS表示怀疑，这有点令人担忧。。。

当我有更多的话要说的时候，我会向你汇报的！