我在AWS上使用多容器泊坞窗获得了不对称的容器可发现性。也就是说,第一个容器可以找到第二个容器,但第二个容器找不到第一个容器。
我在AWS Elastic Beanstalk上有一个多容器docker部署。两个容器都使用相同的初始代码运行节点服务器,并使用相同的Dockerfiles构建。一切都是最新的。
我的Dockerrun.aws.json文件的匿名版本:
{
"AWSEBDockerrunVersion": 2,
"containerDefinitions": [
{
"name": "firstContainer",
"image": "firstContainerImage",
"essential": true,
"memoryReservation":196,
"links":[
"secondContainer",
"redis"
],
"portMappings":[
{
"hostPort":80,
"containerPort":8080
}
]
},
{
"name": "secondContainer",
"image": "secondContainerImage",
"essential": true,
"memoryReservation":196,
"environment":
"links":[
"redis"
]
},
{
"name": "redis",
"image": "redis:4.0-alpine",
"essential": true,
"memoryReservation":128
}
]
}
firstContainer
通过地址secondContainer
代理端口8080上http://secondContainer:8080
的{{1}}请求的子集,完全正常。但是,如果我尝试以另一种方式发送请求,从secondContainer
到http://firstContainer:8080
,我会收到一个错误地址"一种或另一种错误。从在这些容器上运行的服务器内部以及使用wget
直接从容器本身来看都是如此。尝试不同的暴露端口时也是如此。
如果我将"firstContainer"
添加到第二个容器的Dockerrun文件的"links"
字段中,则会收到错误。
我的本地设置,使用docker-compose,根本没有这个问题。
任何人都知道这是什么原因?如何在AWS多容器部署中获得对称可发现性?
答案 0 :(得分:0)
我收到了AWS支持部门对该主题的回复。
链接确实是单向的,这是一个不幸的限制。他们建议采用以下两种方法之一:
我选择了第三种方法,即让容器能够发现其余的发送ping通知其他人的docker-network IP地址。
答案 1 :(得分:0)
我正在探索另一个选项,它是链接,端口映射和extraHosts的组合。
{
"name": "grafana",
"image": "docker.pkg.github.com/safecast/reporting2/grafana:latest",
"memoryReservation": 128,
"essential": true,
"portMappings": [
{
"hostPort": 3000,
"containerPort": 3000
}
],
"links": [
"renderer"
],
"mountPoints": [
{
"sourceVolume": "grafana",
"containerPath": "/etc/grafana",
"readOnly": true
}
]
},
{
"name": "renderer",
"image": "grafana/grafana-image-renderer:2.0.0",
"memoryReservation": 128,
"essential": true,
"portMappings": [
{
"hostPort": 8081,
"containerPort": 8081
}
],
"mountPoints": [],
"extraHosts": [
{
"hostname": "grafana",
"ipAddress": "172.17.0.1"
}
]
}
这允许grafana照常通过链接来解析renderer
,但是渲染器容器将grafana
解析为绑定了端口3000的主机IP(172.17.0.1
是默认的docker bridge网关)回到格拉法纳港口。
到目前为止,它似乎可行。渲染器上的portMappings
可能不是必需的,但我仍在解决所有问题。