- Newest
- Most votes
- Most comments
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
To add to this, the JVM loads classes non-deterministically between OS versions. Fargate will periodically update its underlying OS, which means it’s possible for this to occur even without changing platform versions.
This can manifest as a number of errors, such as “class not defined”, “object is not assignable”, or “no such method”, as seen here.
Since this is an interaction between the JVM and the OS, Fargate doesn’t have any direct control over it; the best way to handle this is to enforce deterministic class loading order in your applications.
Here are some related issues and articles on the subject:
Relevant content
- AWS OFFICIALUpdated 5 months ago
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.