Docker:compose文件与亚马逊云服务器不兼容



我正在尝试在AWS ECS中部署我的docker映像。我已经创建了ECR存储库,并完成了所有必需的步骤,直到将映像推送到ECS。

我的docker-compose.yaml看起来像这个

version: '3'
services:
djangoapp:
image: xxxxx.dkr.ecr.ca-central-1.amazonaws.com/abc:latest #uri after pushing the image
build: .
volumes:
- .:/opt/services/djangoapp/src
- static_volume:/opt/services/djangoapp/static  # <-- bind the static volume
- media_volume:/opt/services/djangoapp/media  # <-- bind the media volume
networks:
- nginx_network
- database1_network
depends_on:
- database1

nginx:
image: nginx:1.13
ports:
- 80:5000
volumes:
- ./config/nginx/conf.d:/etc/nginx/conf.d
- static_volume:/opt/services/djangoapp/static  # <-- bind the static volume
- media_volume:/opt/services/djangoapp/media  # <-- bind the media volume
depends_on:
- djangoapp
networks:
- nginx_network
database1:
image: postgres:10
env_file:
- config/db/database1_env
networks:
- database1_network
volumes:
- database1_volume:/var/lib/postgresql/data
networks:
nginx_network:
driver: bridge
database1_network:
driver: bridge
volumes:
database1_volume:
static_volume:  # <-- declare the static volume
media_volume:  # <-- declare the media volume

我正在尝试运行命令:

docker ecs compose  -n abc up 

我得到以下错误:

WARN[0000] services.build: unsupported attribute        
WARN[0000] services.volumes: unsupported attribute      
ERRO[0000] published port can't be set to a distinct value than container port: incompatible attribute 
WARN[0000] services.volumes: unsupported attribute      
WARN[0000] services.env_file: unsupported attribute     
WARN[0000] services.volumes: unsupported attribute      
WARN[0000] networks.driver: unsupported attribute       
WARN[0000] networks.driver: unsupported attribute       
compose file is incompatible with Amazon ECS

我使用的是最新版本的docker,即19.03.08和最新的aws-cli/2.0.39。

我面临着同样的问题,我通过删除docker-compose.yaml中除image之外的所有属性来完成它。

image属性下的djangoapp服务中,您将值设置为带有注释"的URI;推送图像后的uri";。据推测,这是本地构建的djangoapp的docker映像的URI,该映像被推送到ECR存储库。

由于您已经构建并将djangoapp映像推送到ECR,只需保留image属性,并注释掉docker-compose.yaml:错误消息中列出的所有其他属性

  1. 构建

在我的情况下,它有所帮助。

支持的属性列表:https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cmd-ecs-cli-compose-parameters.html

我不确定你想要实现什么,但看起来你想要一个由postgres数据库支持的django服务,并且你想要使用nginx作为反向代理将请求转发到django?

如果您正在尝试这样做,那么只需为您的集群提供一个单独的网络,并且取消网络的驱动程序选项。删除这些驱动程序选项将消除networks.driver错误。docker compose中的网络将映射到EC2安全组。它们不像VMWare或Hyper-V那样在虚拟机管理中使用的专用/桥接/nat网络。如果你想要的是将所有服务放在同一个网络上,它们就可以相互通信。他们也将能够通过互联网进行通信,但只有那些设置了端口的人才能直接从互联网上访问。

关于端口,ECS只支持对称端口映射。这意味着你不能将一个外部端口映射到另一个内部端口。它们必须相同。因此,您的nginx配置必须使用80或5000,而不是两者都使用。修复它将消除你的第三个错误。

正如@Maksym所指定的,您不需要djangoapp服务下的build选项。你已经建立了图像,并且正在部署它。

对于您的卷,您正在尝试使用.:/opt/services/djangoapp/src装载主机路径。当您使用docker compose部署到ECS时,它使用CloudFormation来部署您的堆栈,并且您的每个服务都运行";"无服务器";,因此没有主机可以装载路径。在您的情况下,由于您自己构建djangoapp映像,因此只需更新Dockerfile,将所需内容复制到/opt/services/djangoapp/src过滤器中,作为映像构建的一部分。对你的nginx服务也做同样的事情——创建你自己的nginx镜像,并在/etc/nginx/conf.d中包含你想要的文件,将其推送到ECR,然后在你的compose yaml中使用该镜像。其中一个文件应该是将代理端口80反向到djangoapp:5000端口的配置。

对于你的其他错误,我不确定。env_file的配置看起来不错,像static_volume:/opt/services/djangoapp/static这样的命名卷映射也是如此。我不知道将文件顶部的版本标题更新为3.7是否会有所帮助。

最后,你的文件应该看起来像这样:

version: '3.7'
services:
djangoapp:
image: xxxxx.dkr.ecr.ca-central-1.amazonaws.com/abc:latest #uri after pushing the image
volumes:
- static_volume:/opt/services/djangoapp/static  # <-- bind the static volume
- media_volume:/opt/services/djangoapp/media  # <-- bind the media volume
networks:
- app_network
depends_on:
- database1

nginx:
image: xxxxx.dkr.ecr.ca-central-1.amazonaws.com/my-nginx:latest
ports:
- 80
volumes:
- static_volume:/opt/services/djangoapp/static  # <-- bind the static volume
- media_volume:/opt/services/djangoapp/media  # <-- bind the media volume
depends_on:
- djangoapp
networks:
- app_network
database1:
image: postgres:10
env_file:
- config/db/database1_env
networks:
- app_network
volumes:
- database1_volume:/var/lib/postgresql/data
networks:
app_network:
name: app_network
volumes:
database1_volume:
name: app_database1_volume
static_volume:
name: app_static_volumne
media_volume:
name: app_media_volume
Docker决定不允许这样做。这是他们在Slack会议上说的话:"We decided to not support this as this would only apply to ingress traffic, not service-to-service, which would be both confusing and inconsistent with local development"

相关内容

最新更新