By using AWS re:Post, you agree to the Terms of Use
AWS re:Postre:Post

Issue with Tomcat container running on Fargate platorm 1.4

0

Hi,

We've been running an app in a container based on the tomcat:9.0-jdk8-corretto image. It has been running fine under Fargate with platform 1.3. But when we changed to platform 1.4, the app starting having issues.

The application in the container provides JWT tokens for authentication and access purposes. I notice in the Tomcat logs at start up under 1.4 that we get a message that we don't with 1.3:

INFO com.mchange.v2.uid.UidUtils - Failed to get local InetAddress for VMID. This is unlikely to matter. At all. We'll add some extra randomness java.net.UnknownHostException: bc7a746844e64dfd95a60014xxxxxxxx-yyyyyyyy: bc7a746844e64dfd95a60014xxxxxxxx-yyyyyyyy: Name or service not known When we try to obtain a token, we see this in the application log:

Unexpected error reading request
java.lang.NoSuchMethodError: io.jsonwebtoken.SignatureAlgorithm.assertValidSigningKey(Ljava/security/Key;)V

If I switch the exact same container back to 1.3, it works as expected. I've been reading up on the differences between platforms 1.3 and 1.4, but nothing is jumping out as a reason for why we are having this issues. Curious if anyone else has run into something similar and if there are some ideas for what to try.

Topics
ServerlessContainers
Tags
AWS FargateAmazon Elastic Container ServiceContainers
Language
English
Greg
asked a month ago35 views
2 Answers
0
Accepted Answer

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.

Greg
answered a month ago
0

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

profile picture
AWS
Roly
answered a month ago
  • Greg a month 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.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions

Relevant content