如何使用 Terraform +/ Cloudformation 连接 AWS Database Migration Service 和 Kinesis Data Streams?
How to use Terraform +/ Cloudformation to connect AWS Database Migration Service and Kinesis Data Streams?
我正在尝试将数据从本地 SQL Server 2016 Enterprise Edition 实例获取到云端。我遇到了障碍,所以如果有人对解决方法有任何指导,我非常感谢您分享您的知识!
我计划在这方面使用 AWS Database Migration Service (aws.amazon.com), which I'm going to call 'DMS' for this post. The database must remain on-premise for regulatory reasons, so I have a need to continually capture data from this database and ship it to the cloud. I'm going to use Change Data Capture (docs.microsoft.com)。
此用例已在 DMS 文档中明确调用,因此它似乎是合适的工具。此外,我从这个 2018 blog post 看到 Kinesis Data Streams 是 DMS 的有效目标。那太棒了;我想使用 Kinesis 来处理来自 CDC 下游的数据。
问题出在 Terraform docs for DMS targets (terraform.io) don't give Kinesis as an endpoint option type. Here's an issue on the Terraform github project (github.com) where someone else has noticed the same thing. And an associated PR (github.com) 中,看起来应该提供修复。虽然好像还得靠其他的修复,所以我也没有屏住呼吸。
现在,一些具体的问题:
- 在 github 问题下面的线程中,有人提到混合使用 Cloudformation 和 Terraform。一些快速搜索抛出 aws_cloudformation_stack (terraform.io) 作为实现这一目标的手段。对吗?
- 我真的应该屏住呼吸让 Hashicorp 合并到 DMS 修复中吗?
- 有没有其他我没有想到的解决这个问题的方法?
不确定回答您自己的问题时的 SO 礼节,(Meta 有点不清楚 (meta.stackexchange.com))[https://meta.stackexchange.com/questions/17845/etiquette-for-answering-your-own-question] 所以这里是:
使用 Terraform + CloudFormation 连接 DMS 和 Kinesis Data Streams
aws_cloudformation_stack
确实有效。 CloudFormation 其实比较简单。下面的第一个代码块显示了我的 Terraform。我正在使用 Terraform 0.12 的 templatefile
函数将参数插入 CloudFormation JSON。在您看到 <Xxx>
或类似内容的地方,这些是我不想共享的我的环境的常规标识符的占位符。
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_alphanumeric
是我将此堆栈创建的组件的 ARN 与之相关联的键的名称。事实证明,在您的 Terraform 代码中的其他地方使用此值并非完全简单。参见(数据来源:aws_cloudformation_stack (terraform.io))[https://www.terraform.io/docs/providers/aws/d/cloudformation_stack.html]。
复杂的是,您必须在代码中明确声明依赖关系,否则当 Terraform 尝试将该值插入代码库的其他位时,CloudFormation 堆栈的输出将不可用。或者您将不得不逐步推出您的更改、注释和取消注释资源以手动满足依赖关系。恶心。
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.aws.amazon.com))[https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dms-endpoint.html] 声称 EngineName
属性 是强制性的,它只能是所提供列表中的值之一(不包括 kinesis
),情况并非如此。
为了清楚起见,我将 EngineName
留在那里,并期望有一天 kinesis
会被添加到列表中,并且验证规则可能会收紧。事实上,我还没有尝试在 EngineName
不存在的情况下部署此基础设施。尽管如此,推出它没有任何问题。
所以,这回答了我的问题 (1)。
我还没有尝试在 Terraform 中表达这一点,这会更简洁,并且无需显式声明资源之间的依赖关系。我不确定 Terraform 的 engine_name
验证是否超出了 CloudFormation 的范围;如果是这样,CloudFormation 方法可能是目前最好的方法。如果没有,我宁愿将上面的内容重写为纯 Terraform。与此同时,我的工作。
这也回答了我的问题 (2)。我不需要屏住呼吸来合并这些修复程序。
仍然可以输入 (3)!我还没有端到端验证 DMS 按预期工作,但是,因为我被网络问题阻止了。一位评论者对 DMS 表示怀疑,这有点令人担忧...
当我对此有更多要说的时候,我会回来报告!
我正在尝试将数据从本地 SQL Server 2016 Enterprise Edition 实例获取到云端。我遇到了障碍,所以如果有人对解决方法有任何指导,我非常感谢您分享您的知识!
我计划在这方面使用 AWS Database Migration Service (aws.amazon.com), which I'm going to call 'DMS' for this post. The database must remain on-premise for regulatory reasons, so I have a need to continually capture data from this database and ship it to the cloud. I'm going to use Change Data Capture (docs.microsoft.com)。
此用例已在 DMS 文档中明确调用,因此它似乎是合适的工具。此外,我从这个 2018 blog post 看到 Kinesis Data Streams 是 DMS 的有效目标。那太棒了;我想使用 Kinesis 来处理来自 CDC 下游的数据。
问题出在 Terraform docs for DMS targets (terraform.io) don't give Kinesis as an endpoint option type. Here's an issue on the Terraform github project (github.com) where someone else has noticed the same thing. And an associated PR (github.com) 中,看起来应该提供修复。虽然好像还得靠其他的修复,所以我也没有屏住呼吸。
现在,一些具体的问题:
- 在 github 问题下面的线程中,有人提到混合使用 Cloudformation 和 Terraform。一些快速搜索抛出 aws_cloudformation_stack (terraform.io) 作为实现这一目标的手段。对吗?
- 我真的应该屏住呼吸让 Hashicorp 合并到 DMS 修复中吗?
- 有没有其他我没有想到的解决这个问题的方法?
不确定回答您自己的问题时的 SO 礼节,(Meta 有点不清楚 (meta.stackexchange.com))[https://meta.stackexchange.com/questions/17845/etiquette-for-answering-your-own-question] 所以这里是:
使用 Terraform + CloudFormation 连接 DMS 和 Kinesis Data Streams
aws_cloudformation_stack
确实有效。 CloudFormation 其实比较简单。下面的第一个代码块显示了我的 Terraform。我正在使用 Terraform 0.12 的 templatefile
函数将参数插入 CloudFormation JSON。在您看到 <Xxx>
或类似内容的地方,这些是我不想共享的我的环境的常规标识符的占位符。
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_alphanumeric
是我将此堆栈创建的组件的 ARN 与之相关联的键的名称。事实证明,在您的 Terraform 代码中的其他地方使用此值并非完全简单。参见(数据来源:aws_cloudformation_stack (terraform.io))[https://www.terraform.io/docs/providers/aws/d/cloudformation_stack.html]。
复杂的是,您必须在代码中明确声明依赖关系,否则当 Terraform 尝试将该值插入代码库的其他位时,CloudFormation 堆栈的输出将不可用。或者您将不得不逐步推出您的更改、注释和取消注释资源以手动满足依赖关系。恶心。
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.aws.amazon.com))[https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dms-endpoint.html] 声称 EngineName
属性 是强制性的,它只能是所提供列表中的值之一(不包括 kinesis
),情况并非如此。
为了清楚起见,我将 EngineName
留在那里,并期望有一天 kinesis
会被添加到列表中,并且验证规则可能会收紧。事实上,我还没有尝试在 EngineName
不存在的情况下部署此基础设施。尽管如此,推出它没有任何问题。
所以,这回答了我的问题 (1)。
我还没有尝试在 Terraform 中表达这一点,这会更简洁,并且无需显式声明资源之间的依赖关系。我不确定 Terraform 的 engine_name
验证是否超出了 CloudFormation 的范围;如果是这样,CloudFormation 方法可能是目前最好的方法。如果没有,我宁愿将上面的内容重写为纯 Terraform。与此同时,我的工作。
这也回答了我的问题 (2)。我不需要屏住呼吸来合并这些修复程序。
仍然可以输入 (3)!我还没有端到端验证 DMS 按预期工作,但是,因为我被网络问题阻止了。一位评论者对 DMS 表示怀疑,这有点令人担忧...
当我对此有更多要说的时候,我会回来报告!