Amazon web services CodeDeploy如何使用动态端口映射？

几周来，我一直在努力使CodeDeploy/CodePipeline适用于我们的解决方案。制作某种CI/CD，使部署更快、更安全……等等

当我不断地钻研它时，我觉得要么我做得根本不对，要么它不适合我们的情况

我们所有的AWS基础设施是什么：

• 我们有一个ECS集群，目前包含一个服务（在EC2下），与一个或多个任务关联，一个反向代理和一个API。因此反向代理在内部侦听端口80，当到达端口80时，代理在内部传递到端口5000上的API

• 我们有一个与此服务关联的应用程序负载平衡器，可以公开访问。它目前有两个侦听器，http和https。两个侦听器重定向到同一个目标组，该目标组中只有反向代理所在的实例。请注意，要重定向到的实例端口是随机的（请选中此项）

• 我们有一个自动伸缩组，即根据调用应用程序负载平衡器的次数来伸缩实例的数量

我们未来可能拥有的：

• 其他任务将与我们的API位于同一实例中。例如，我们可以使用另一个反向代理和另一个负载平衡器在另一个端口上创建另一个API，该API与以前在同一集群中。我们可能有一些批处理运行，和其他东西

有什么问题：

那么就目前而言，“手动”部署（即告诉服务在ECS上进行新的部署）不起作用。CodeDeploy在创建替换任务时陷入困境，当我查看服务日志时，出现以下错误

服务xxxx无法放置任务，因为没有容器 实例满足其所有要求。最接近的匹配 容器实例yyyy已在使用任务所需的端口

我真的不明白，因为端口分配是随机的，但可能CodeDeploy在此之前就开始运行了，只知道分配的端口是0，它与前面的任务定义相同

我真的不知道如何解决这个问题，我甚至怀疑CodeDeploy在我们的情况下是否可用

--编辑2021年2月18日--

所以，我知道为什么它现在不起作用了。正如我所说，我的主机侦听反向代理的端口是随机的。但我的API监听的端口仍然不是随机的

但是现在，即使我告诉API端口是随机的，就像反向代理一样，我的反向代理怎么知道API在哪个端口可以访问呢？我尝试链接容器，但在配置文件中似乎不起作用（我使用nginx作为反向代理）

--

不指定主机端口似乎在主机上分配了一个“随机”端口

---

但是，由于NGINX和API是两个不同的容器，我需要我的第一个NGINX容器来调用我的第一个API容器，即API:32798。我想我遗漏了一些东西

您可能会遇到端口冲突，因为您在同一台主机上有两个任务要将主机的端口80映射到它们的容器中

我试图将冲突形象化：

紫色框共享端口名称空间，绿色框和橙色框也共享端口名称空间。这意味着您可以在每个框中使用1-65k端口一次。当您明确需要一个主机端口时，它将尝试将端口80映射到两个容器端口，但这不起作用

您不想显式地将这些容器端口映射到主机端口，让ECS担心吧

只需在服务定义中的负载平衡器集成中指定容器端口，它就会为您进行映射。如果将容器端口设置为80，则表示绿色端口80和橙色端口80。它将这些端口公开为随机端口，并自动向负载平衡器注册这些随机端口

---

（搜索

containerPort

）

您是否碰巧在任务定义中硬编码到docker主机端口的映射？类似于中描述的

HostPort

？如果您使用的是HostPort，它与random相反，它将尝试获取Docker主机的端口80，如果不起作用，您将看到此错误。请在帖子中包含与帖子相关的信息，而不是在外部链接中，这些链接有死亡的趋势；-）哦，好吧，我知道为什么。确定反向代理的端口是随机的，但不是API的端口。。。所以我还需要使其随机，但我仍然需要在API的随机端口和反向代理配置之间有一个链接。。。因为我需要反向代理来代理传递到随机API端口。。。我会调查并编辑我的初始帖子这很难用语言表达，我会画一幅图我知道你用来画图表的应用程序吗？很明显，任务中的容器应该共享端口空间，因此，反向代理可以转发到端口5000—这就是内核名称空间的魔力为您所做的—无需为此使用HostPort。HostPorts仅适用于您希望以守护进程模式（或我忘记了它的名称）部署服务的情况，该模式在群集中的每个节点上调度一个任务实例。否则你应该让服务来处理端口映射的事情。对安全组来说，我就是这么做的。我还链接了我的nginx和API，它似乎在本地工作，因为我现在可以调用linkedAPI:5000，所以看起来一切都很好。CodeDeploy仍然有一个问题，但是我想我会做另一个线程，谢谢你的帮助！