fargate_获取ECS Fargate容器的持久地址。

最新推荐文章于 2024-01-04 15:20:15 发布

weixin_26752759

最新推荐文章于 2024-01-04 15:20:15 发布

阅读量268

点赞数

文章标签： python docker

原文链接：https://itnext.io/getting-a-persistant-address-to-a-ecs-fargate-container-3df5689f6e56

版权

fargate

实用的DevOps (Practical DevOps)

So we had an EC2 instance that outlived itself, keys were lost (read about how we recovered the contents here) and needed to replace it.

因此，我们有一个EC2实例已过期，密钥丢失了(请阅读此处有关如何恢复内容的信息) ，需要替换它。

Instead of reinstalling a whole new EC2 server for it, I thought, hey, why not just make a small docker container and deploy it on Fargate, it should be simple enough, right?

我想，与其为它重新安装一台全新的EC2服务器，不如为什么不制作一个小型Docker容器并将其部署在Fargate上，它就应该足够简单，对吧？

Well, it turns out that there were actual two complications, one of which I will talk about here and the other is a topic for another post: Hint, it will involve Bytesafe using a locked down/ freezed registry.

好吧，事实证明，实际上有两种复杂性，我将在这里讨论其中一种，另一种是另一篇文章的主题：提示，它将涉及使用已冻结/冻结的注册表的Bytesafe。

The other challenge, at first glance, seemed trivial.

乍一看， 其他挑战似乎微不足道。

Image for post — Photo by Victor Garcia on Unsplash

I just needed to retain the same public address for my ECS Fargate container that was running the Statsd application. As one might guess this address was used throughout our environment, configuration in plenty of services and applications. And to keep changing that configuration t would be a nightmare.

我只需要为运行Statsd应用程序的ECS Fargate容器保留相同的公共地址。可能有人猜测此地址已在我们的整个环境，大量服务和应用程序中使用。而要不断更改配置，将是一场噩梦。

And using an internal IP (which totally could make sense for a service like this) was unfortunately not possible as the service needed to be reachable from multiple VPCs without possibility of VPC peering due to IP overlap.

不幸的是，使用内部IP(对于这样的服务完全有意义)是不可能的，因为该服务需要能够从多个VPC访问，并且由于IP重叠而无法进行VPC对等。

Now, before you all scream “Use AWS ECS Service Discovery” I would just like to point out… That service does not currently work for Public IPs, only internal ones. And if you made it so far to read all the way here, please go ahead and add your vote for adding this ECS feature on the link below 😃

现在，在大家大喊“使用AWS ECS服务发现”之前，我想指出一下……该服务当前不适用于公共IP，仅适用于内部IP。如果到目前为止您已经阅读了全文，请继续并在下面的链接中添加投票以添加此ECS功能😃

ECS Service Discovery does not currently publish public IPs, only Internal ones unfortunately…

ECS服务发现当前不发布公共IP，不幸的是仅内部IP…

But until the good folks at AWS adds this feature, keep reading.

但是，直到AWS的优秀人员添加此功能之前，请继续阅读。

So what we will do is make ECS update Route53 with the public IP address every time the docker container is started. This way we can use the DNS name for the service in our applications and services.

因此，我们要做的是每次启动Docker容器时，使用公共IP地址使ECS更新Route53。这样，我们可以在应用程序和服务中使用DNS名称作为服务。

I’ve seen some different variants of this solution while looking around, but the closest I got was to deploy a Lambda function that got triggered by state changes in the ECS life cycle. Like this one or this one. For me such solutions felt a bit...bloated for my use case. I wanted to have my solution well, contained…in the container. And not start using (and paying for) more services. (The cost of using a ALB/NLB for a small ECS Fargate task can easily surpass the cost of the actual ECS itself)

环顾四周时，我看到了该解决方案的一些不同变体，但最接近的是部署Lambda函数，该函数是由ECS生命周期中的状态更改触发的。喜欢这个或这个。对我来说，这样的解决方案让我的用例感到有点膨胀。我想将解决方案很好地保存在容器中。而不是开始使用(并支付)更多的服务。 (针对小型ECS Fargate任务使用ALB / NLB的成本很容易超过实际ECS本身的成本)

And Since I’m kind of old-school, I’m going to be using Bash and CLI tools to get this done. 😁

而且由于我有点老套，我将使用Bash和CLI工具来完成此任务。 😁

I’ll start out with my container, which is the offical Statsd container and from there we will modify our Dockerfile a bit to install the AWSCLI package and the jq tool as well as adding custom scripts that prepares and executes an UPSERT to Route53.

我将从容器开始，这是正式的Statsd容器，然后我们将对Dockerfile进行一些修改，以安装AWSCLI软件包和jq工具，并添加自定义脚本来准备和执行UPSERT到Route53。

We will also make use of ECS variables to know which DNS record to modify. This way we will be able to run the same containers with different public IPs, one for our test environment, one for the. production etc.

我们还将利用ECS变量来了解要修改的DNS记录。这样，我们将能够运行具有不同公共IP的相同容器，一个用于我们的测试环境，一个用于。生产等

Docker文件 (Dockerfile)

We will create a wrapper script and use that instead of our existing ENTRYPOINT configuration

我们将创建一个包装器脚本，并使用该脚本代替我们现有的ENTRYPOINT配置

The unchanged Dockerfile to start up statsd looked something along the lines of:

用于启动statsd的未更改的Dockerfile看起来类似于以下内容：

We are going to swap out the ENTRYPOINT above to a wrapper script that performs our Route53 magic and then starts the node application. And while we are at it, let’s add our dependencies, awscli and jq

我们将把上面的ENTRYPOINT换成一个包装脚本，该脚本执行Route53魔术，然后启动节点应用程序。在此过程中，让我们添加依赖项awscli和jq

‼️ Be mindful of which version of the awscli you are using. I just spent too much time troubleshooting why my container didn’t behave like expected. My first try using apt-get to install it gave me an older version which did not fail but rather leaving out some elements in the API response.

！️请注意您使用的是哪个版本的awscli。我只是花了很多时间来排查为什么我的容器的行为不符合预期。我第一次尝试使用apt-get安装它给了我一个较旧的版本，它没有失败，但是在API响应中遗漏了一些元素。

Entrypoint.sh is trivial:

Entrypoint.sh很简单：

It’s in update-route53.sh is where our magic happens.

它是在update-route53.sh中发生的。

First we call the Task Metadata Endpoint to get our current TaskARN and Cluster ID.
首先，我们调用任务元数据端点以获取当前的TaskARN和群集ID。
Using those, we call the ECS API to get our attached network interface (ENI).
使用这些，我们调用ECS API来获取连接的网络接口(ENI)。
And lastly we call the EC2 API to get the details for the ENI, i.e. our public IP address.
最后，我们调用EC2 API以获取ENI的详细信息，即我们的公共IP地址。

When we know our public IP we construct an UPSERT record that we send to the Route53 API using the settings provided in the ECS Task definition.

当我们知道公共IP时，我们将使用ECS任务定义中提供的设置来构建UPSERT记录，并将其发送到Route53 API。

Here is the full update-route53.sh:

这是完整的update-route53.sh：

ECS任务配置 (ECS Task Configuration)

Now, to pull off the above, we need some additional access rights to be able to get the information from the APIs and to be able to update Route53.

现在，要实现上述功能，我们需要一些其他访问权限，以便能够从API中获取信息并能够更新Route53。

You might want to make the below a bit stricter depending on your setup and security requirements.

您可能需要根据设置和安全要求对以下内容进行更严格的设置。

💡 Don’t forget to change the Resource below to the Route53 ZoneID before you add it to your ECS Task Role

💡不要忘记更改下面的资源到Route53你了zoneid它添加到您的ECS任务角色之前

Last step is to configure the ECS environment variables which will instruct the script which Route53 Zone to modify and which DNS record to create or update.

最后一步是配置ECS环境变量，该环境变量将指示脚本修改哪个Route53区域以及创建或更新哪个DNS记录。

That’s it! Now you are able to reboot the ECS instance and once the new container starts up it will automatically update Route53 DNS entry with its public IP.

而已！现在您可以重新启动ECS实例，一旦新容器启动，它将自动使用其公共IP更新Route53 DNS条目。