- 최신
- 최다 투표
- 가장 많은 댓글
The issue turned out to be an older jar being included in the build. I guess the Docker runtime used in 1.3 handles classpaths different than the containerd runtime in 1.4.
Probably a good Blog to read:
https://aws.amazon.com/blogs/containers/aws-fargate-launches-platform-version-1-4/
From here, I suspect that this change has an effect, as before 1.4 it went through a Fargate ENI not controlled by you. In 1.4, Task ENI inherits your VPC settings.
Starting with 1.4.0 that traffic flows through the Task ENI. Task ENIs will inherit the networking connectivity patterns you have enabled in your own VPCs. This is important for customers that, for example, want to have visibility of that specific traffic inside VPC Flow Logs.
I suspect now that you have to update your outbound rule
In terms of network connectivity, now either your VPCs need to allow outbound traffic to reach the same public endpoints or you need to configure Private Links for said services so that your Task ENI can reach the endpoint on your VPC. A practical example is that, previously on Fargate, if you were using private links for ECR, you only needed to set up the ecr.dkr endpoint. With platform version 1.4.0, you also need to set up the api.ecr endpoint.
I am not sure if the specific error points to that, but I do suspect folks to look at their permissions since we moved control over to user in 1.4
관련 콘텐츠
AWS 공식업데이트됨 일 년 전
Thanks for the info. That post was one of the ones I read in trying to figure out the issue. I'm nearly certain now the first message about UnknownHostException is a red herring. We are thinking now there might be something different between Docker and containerd runtimes regarding classpath loading, and we are checking the jars of the build to see if maybe we have an older jar that isn't getting evicted in the build.