aws terraform_如何使用Terraform通过Direct Connect扩展AWS基础架构

aws terraform

Sometimes, when you face a challenge, you might be able to solve it with routine processes. But other times you need to try something completely new, something that you know nothing about.

有时，当您面临挑战时，您也许可以通过常规流程解决它。 但是有时您需要尝试全新的东西，而您对此一无所知。

Usually in these scenarios you should apply engineering thinking. For me, these moments are the most insightful and I want to share some of mine with the community.

通常，在这些情况下，您应该应用工程思维。 对我而言，这些时刻是最有见地的时刻，我想与社区分享我的一些经历。

Here I will guide you through the steps that my team and I took when we connected existing AWS infrastructure to a large private network using Direct Connect.

在这里，我将指导您完成团队和我使用Direct Connect将现有AWS基础设施连接到大型专用网络时所采取的步骤。

Along the way, I will provide Terraform code snippets that will show you how to implement all of these components as "infrastructure as code" with accompanying design schemes.

在此过程中，我将提供Terraform 代码段 ，这些代码段将向您展示如何通过随附的设计方案将所有这些组件实现为“ 基础结构即代码 ”。

我们将介绍的内容 (What we'll cover)

1. Problems to Solve
   要解决的问题
2. What is Direct Connect?
   什么是直接连接？
3. How to embed it
   如何嵌入
4. Transit VPC using Terraform
   使用Terraform传输VPC
5. Direct Connect using Terraform
   使用Terraform直接连接
6. Peering between main and transit VPCs
   在主VPC和过渡VPC之间对等
7. Do you use OpenVPN (optional)?
   您是否使用OpenVPN(可选)？
8. Router Service
   路由器服务
9. Closing thoughts
   总结思想

要解决的问题 (Problems to Solve)

We had services within our VPC that should be able to communicate with other services in a separate virtual private network

我们在VPC中拥有服务，这些服务应该能够与单独的虚拟专用网络中的其他服务进行通信

In order to establish the connection, we needed to accept an AWS hosted connection from a network provider as part of a signed contract to grant access to the VPN using AWS Direct Connect.

为了建立连接，我们需要接受网络提供商提供的AWS托管连接，作为已签署合同的一部分，以使用AWS Direct Connect授予对VPN的访问权限。

So how were we to implement all of this? How were we going to embed it a current solution that was managed using Terraform? Were there any best practices for doing that?

那么我们如何实现所有这些呢？ 我们如何将其嵌入使用Terraform管理的当前解决方案？ 有没有这样做的最佳实践？

什么是直接连接？ (What is Direct Connect?)

AWS Direct Connect makes it easy to establish a dedicated network connection from your premises to your Amazon VPC or among Amazon VPCs. This option can potentially reduce network costs, increase bandwidth throughput, and provide a more consistent network experience than the other VPC-to-VPC connectivity options. (source)

通过AWS Direct Connect，可以轻松地建立从您的房屋到Amazon VPC或Amazon VPC之间的专用网络连接。 与其他VPC到VPC连接选项相比，此选项可以潜在地降低网络成本，增加带宽吞吐量并提供更一致的网络体验。 ( 来源 )

Essentially you have a network provider who has AWS facilities in a shared data centre. Then you both can make a direct connection between your AWS network components and the network using the provider's hardware (literally a patchcord in the nest) with subsequent access.

本质上，您拥有一个网络提供商，该提供商在共享数据中心中拥有AWS设施。 然后，您都可以使用提供者的硬件(嵌套中的拼凑而成)并随后进行访问，在AWS网络组件和网络之间建立直接连接。

Generic implementation in terms of AWS looks like the following:

AWS的通用实现如下所示：

• You configure one or two (reserved) Direct Connections in the console, which creates a Direct Connect Gateway.
  您在控制台中配置一个或两个(保留的)直接连接，这将创建一个直接连接网关。
• Then you attach a private VIF (one per connection) to the gateway.
  然后，将专用VIF(每个连接一个)连接到网关。
• Once you make a few calls with the provider's network engineers and exchange routing policies, it is done.
  一旦与提供商的网络工程师打了几个电话并交换了路由策略，就完成了。

Usually all instructions regarding how to enable the connection will be sent over to you by the provider.

通常，有关如何启用连接的所有说明将由提供商发送给您。

如何嵌入 (How to embed it)

Our first assumption was that we would enable the connection in the VPC and create the routing configuration to direct connect gateway for the required requests (for example, we'd distinguish them by the header "Host" or by IPs).

我们的第一个假设是，我们将在VPC中启用连接并创建路由配置以直接连接网关以响应所需的请求(例如，我们通过标头“ Host”或IP区分它们)。

On high level, it would look something like this:

从高层次看，它看起来像这样：

During a call with the provider's network engineers, they asked us about our IP range that we advertised to the network. We wondered why. It was because Direct Connect work is declared by a protocol called BGP. If you want more info, there are a lot of videos that will teach you about one of the major Internet protocols that are running under the hood.

在与提供商的网络工程师通话时，他们询问了我们向网络发布的IP范围。 我们想知道为什么。 这是因为Direct Connect工作是通过称为BGP的协议声明的。 如果您需要更多信息，有很多视频可以教您有关幕后运行的主要Internet协议之一的信息。

Our initial thought was that it needed to be a subnet which contained services that we wanted to access the network. After that, we were asked to configure the subnet 10.1.2.0/24 as an allowed prefix in our Direct Connect configuration.

我们最初的想法是，它必须是一个子网，其中包含我们要访问网络的服务。 之后，系统要求我们将子网10.1.2.0/24配置为Direct Connect配置中允许的前缀 。

Long story short,  "allowed prefixes" here stand for an IP range that we were going to advertise to the network provider that they would register in the routing policies.Well, after all that, it did not work. The provider did not "see" our advertised routes despite the fact that we could see them.

长话短说，“允许的前缀”在这里代表我们要向网络提供商广播的IP范围，它们将在路由策略中注册。嗯，毕竟这是行不通的。 尽管我们可以看到它们，但提供者没有“看到”我们的广告路由。

A bit of investigation and voilà:

一点调查和注意 ：

AWS will allocate private IPs (/30) in the 169.x.x.x range for the BGP session and will advertise the VPC CIDR block over BGP. You can advertise the default route via BGP.

AWS将在169.xxx范围内为BGP会话分配私有IP(/ 30)，并将通过BGP通告VPC CIDR块。 您可以通过BGP发布默认路由。

Additionally, we found other folks who seemed faced the same issue:

此外，我们发现其他似乎面临相同问题的人：

we ended up with creating a new VPC with smaller CIDR our partner wanted.

我们最终用合作伙伴想要的较小的CIDR创建了一个新的VPC。

So basically, the IP's range that you can advertise over Direct Connect is limited up to /30. Also, you can not advertise subnets – rather you should advertise the whole VPC CIDR.

因此，基本上，您可以在Direct Connect上发布的IP范围限制为/30 。 另外，您不能播发子网–而是应播发整个VPC CIDR。

Our network CIDR was 10.1.0.0/16 and we had an issue with that - it was too large to accept for the network provider. On top of that, during the call we discovered another thing we had to do when connecting to the network: we needed to contact the network IP access management department (if the network was large enough, I suppose) to ask them to provide us with a unique range within the network. Subsequently, it should be our new VPC CIDR.

我们的网络CIDR为10.1.0.0/16 ，对此我们有一个问题- 它太大了，网络提供商无法接受 。 最重要的是，在通话过程中，我们发现连接到网络时必须要做的另一件事： 我们需要联系网络IP访问管理部门(如果我想如果网络足够大的话)，请他们为我们提供网络中唯一的范围。 随后，应该是我们的新VPC CIDR。

We decided to create a separate VPC. To get some proofs of work we found some official guides form AWS such as this one. Shortly after this, we learned that the AWS community would start using separate words for that separate VPC - they'd call it a transit VPC.

我们决定创建一个单独的VPC。 为了获得工作证明，我们发现了一些来自AWS的官方指南，例如本指南。 此后不久，我们了解到AWS社区将开始为该单独的VPC使用单独的单词-他们将其称为中转VPC。

Before getting a reply to a request a unique IP range in the network, we asked the provider about currently unused IP ranges so we could implement it quickly on our side. This would give us the proof of work we needed for a solution. Everything worked perfectly.

在获得对网络中唯一IP范围的请求的答复之前，我们向提供商询问了当前未使用的IP范围，以便我们可以在我们这边快速实施它。 这将为我们提供解决方案所需的工作证明。 一切正常。

The next step was to implement everything (Direct Connect configurations + VPCs peering) in our existing Terraform configuration.

下一步是在我们现有的Terraform配置中实现所有功能(直接连接配置+ VPC对等)。

使用Terraform传输VPC (Transit VPC using Terraform)

First of all, before we start to dig into the code, I want to say that you can find all the code below on GitHub here.

首先，在我们开始深入到代码，我想说的是，你可以找到下面所有的代码在GitHub上这里 。

Let's first recap what we discussed before. We have conditions where we had an existing VPC. And we wanted some services within it to be able to communicate through the network that we connected to using Direct Connect.

让我们首先回顾一下我们之前讨论过的内容。 我们拥有现有VPC的条件。 我们希望其中的某些服务能够通过使用Direct Connect连接的网络进行通信。

We were granted two AWS-hosted connections (primary and secondary, in order to ensure connection fallback). The main idea was to extend our existing infrastructure somehow. Somehow meant Transit VPC – the solution that helped us integrate with such connections.

我们获得了两个AWS托管的连接(主要和辅助连接，以确保连接回退)。 主要思想是以某种方式扩展我们现有的基础架构。 某种程度上意味着Transit VPC –帮助我们与此类连接集成的解决方案。

Now let's look at some code to represent what we have discussed. The first thing to define is going to be our main VPC. I want to present it for illustration purposes only, so it makes all further steps seem more consistent.

现在，让我们看一些代码来表示我们所讨论的内容。 首先要定义的将是我们的主要VPC。 我仅出于说明目的提供它，因此使所有其他步骤看起来更加一致。

Next, some of the main VPC's parameters are going to be used in the transit VPC. So let's define them as output:

接下来，将在传输VPC中使用一些主要VPC的参数。 因此，让我们将它们定义为输出：

Now we can start to configure our transit VPC. Just for sake of good design, we decided to manage it in a separate state under a separate folder (e.g. tranist-vpc/). Let's first import above outputs as locals:

现在我们可以开始配置传输VPC。 出于良好设计的考虑，我们决定在单独的文件夹下(例如tranist-vpc / )以单独的状态对其进行管理。 首先，将以上 输出作为本地数据导入：

Next, we can start defining the transit VPC configuration. First, I want to list all variables that we need (pay attention to the IPs of the DNS servers in the network that we want to connect to. You should know them to specify as DNS servers in transit VPC):

接下来，我们可以开始定义传输VPC配置。 首先，我要列出我们需要的所有变量( 注意我们要连接的网络中DNS服务器的IP。您应该知道它们可以指定为传输VPC中的DNS服务器 )：

And, secondly, the configuration:

其次，配置：

使用Terraform直接连接 (Direct Connect using Terraform)

Let's continue with the Direct Connect configuration. First, let's define all variables that we need in order to continue. You should get all these values from your network provider. I assume they will be sent over to you (the same worked for us) in a separate document like a spreadsheet:

让我们继续直接连接配置。 首先，让我们定义继续所需的所有变量。 您应该从网络提供商那里获得所有这些值。 我假设它们将在单独的文档(例如电子表格)中发送给您(对我们同样有用)：

And now we can do the rest of the configuration:

现在我们可以完成其余的配置：

Now, if you go to your AWS console, next to Direct Connection you should see something like this:

现在，如果您转到AWS控制台，则在“直接连接”旁边，您应该看到类似以下的内容：

在主VPC和过渡VPC之间对等 (Peering between main and transit VPCs)

The last issue to solve is to configure connectivity between our services and transit VPC in order to establish access to the network.

要解决的最后一个问题是配置我们的服务与中转VPC之间的连接，以建立对网络的访问。

To accomplish this, we decide to use VPC peering. Here we will need some of the locals' variables that we imported before:

为此，我们决定使用VPC对等 。 在这里，我们需要一些之前导入的locals变量：

Next we need to allow inbound HTTP traffic from the main VPC. That configuration can be done like this:

接下来，我们需要允许来自主VPC的入站HTTP通信。 可以这样配置：

Great. Now we have two VPCs that are peered and coexist together.

大。 现在，我们有两个对等并共存的VPC。

您是否使用OpenVPN(可选)？ (Do you use OpenVPN (optional)?)

In our case, we have an OpenVPN server to manage access (SSH) to the main VPC's internal resources. And we wanted to access the transit VPCs resources in the same way. In order to do that we needed to create few additional resources within the transit VPC:

在我们的案例中，我们有一个OpenVPN服务器来管理对主要VPC内部资源的访问(SSH)。 我们希望以相同的方式访问中转VPC资源。 为此，我们需要在传输VPC内创建一些其他资源：

And then add an ingress rule to transit-vpc-SG that was created on the previous step:

然后将入口规则添加到上一步中创建的transit-vpc-SG ：

To make all of this work you need to specify the transit VPC's CIDR along with the main VPC's CIDR in the OpenVPN server routing setting under the VPN Setting section:

为了完成所有这些工作，您需要在“ VPN设置”部分下的“ OpenVPN服务器路由”设置中指定传输VPC的CIDR以及主VPC的CIDR：

So now we are almost there. The last thing to do is to design and configure how our services within the main VPC will be able to programmatically access the network.

所以现在我们快到了。 最后要做的是设计和配置主VPC中我们的服务将如何以编程方式访问网络。

路由器服务 (Router Service)

To recap, the main reason why we've done all of that is that we need to be able to access other services in the network (for example request or submit data). We found two possible ways to achieve that here:

概括地说，我们完成所有这些操作的主要原因是我们需要能够访问网络中的其他服务(例如，请求或提交数据)。 我们在这里找到了两种实现方法：

• Migrate required services to the transit VPC and use them there, assigned with new private IPs. Main VPC internal routing should be adjusted. On top of that, any access to DB servers, logs' storage, and so on should be managed as well.
  将所需的服务迁移到转接VPC并在其中使用，并为其分配新的专用IP。 主VPC内部路由应进行调整。 最重要的是，还应管理对数据库服务器的任何访问，日志的存储等。

• Create router service (running HAproxy or NGingx) within the transit VPC. Add router private IP to the hosts file in each service in the main VPC that wants to access the network so the IP will be resolved behind the required domain name.

  在传输VPC中创建路由器服务(运行HAproxy或NGingx)。 将路由器专用IP添加到要访问网络的主VPC中每个服务中的hosts文件中，以便在所需的域名后面解析IP。

We choose the second option as it seemed to be the most aligned with the open-close principle. Here how it approximately looks:

我们选择第二种选择，因为它似乎最符合开闭原则 。 大致情况如下：

Let's configure it in Terraform:

让我们在Terraform中对其进行配置：

Here router_init.sh contains a script to configure and launch the HAproxy service in a container. For illustration purposes, let's assume that we want to access two internal domain names in the network:

这里的router_init.sh包含一个脚本，用于在容器中配置和启动HAproxy服务。 为了便于说明，假设我们要访问网络中的两个内部域名：

• domain-name-1.internal.com

  domain-name-1.internal.com

• domain-name-2.internal.com

  domain-name-2.internal.com

The last step is to check that our domains were added to the hosts file on the instances in the main VPC and start making requests over HTTP.

最后一步是检查我们的域是否已添加到主VPC中实例上的hosts文件中，并开始通过HTTP发出请求。

总结思想 (Closing Thoughts)

In this article, I showed you how to integrate Direct Connect into your existing AWS infrastructure. I also talked about how you can efficiently manage it using Terraform.

在本文中，我向您展示了如何将Direct Connect集成到现有的AWS基础架构中。 我还谈到了如何使用Terraform有效管理它。

Then I discussed what approach would be appropriate for a network routing configuration that would make the solution transparent and easy to maintain as much as possible.

然后，我讨论了哪种方法适用于网络路由配置，该方法可以使解决方案透明并易于维护。

Transit VPC, which is recommended by AWS to solve such challenges, was indeed easy to configure. And the approach we tried with router service within transit VPC to access the private network showed its proof of work. But it didn't seem to be any better than other alternatives.

AWS推荐使用Transit VPC来解决此类挑战，它确实易于配置。 我们尝试在传输VPC中使用路由器服务访问专用网络的方法证明了其工作证明。 但这似乎并没有比其他选择更好。

Lastly, I introduced Terraform code snippets are will hopefully be useful for anyone who wants to do something similar.

最后，我介绍了Terraform代码段，希望对那些想做类似事情的人有用。

I hope you enjoyed this article and found it helpful!

希望您喜欢这篇文章并发现对您有所帮助！

翻译自: https://www.freecodecamp.org/news/how-to-extend-your-aws-infrastructure/

aws terraform