Issues when using "Google Cloud Run"

aretrace commented 2 years ago

First of all, thank you for making such a convenient piece of software!

Details:

JPro Version: 2022.1.7
Java Version: 17
Cloud Platform: GCP/Cloud Run
Operating System: Docker situation
Building with maven/"jproRelease"

As alluded to in the docs, lack of SSL can make JPro not play nice in environments of certain kind of proxies. I'm currently tying to deploy a demo project to Google Cloud Run, compose is not available there so just using a straight faward multi-stage build to run a maven jpro:release start.sh artifact.

The issue is containers can only be run if certain conditions are met, one of them is: "The container should not implement any transport layer security directly. TLS is terminated by Cloud Run for HTTPS and gRPC, and then requests are proxied as HTTP/1 or gRPC to the container without TLS." - Container runtime contract

The Problem:

It seems that JPro attempts to establish a wss:// (a secure websocket) connection directly with the client, a clear violation of the container runtime contract (read more about the contract here). In jpro:run mode the websocket connection is unsecured but I am unable to replicate that on Cloud Run.

My request is to enable a production mode/plugin/config that allows all necessary traffic between the server and the client to run \'insecurely\' (without requiring a TLS/SSL connection(s)) such as to enable JPro to run in environments like Cloud Run. This is basically a anti-#76 request.

I know SSL is recommended but I suspect Cloud Run isn't the only container host platform where SSL would complicate the picture (and in this case it will not solve the issue as its strictly forbidden).

Please let me know of a workaround and/or if you consider to implement my proposition.

FlorianKirmaier commented 2 years ago

@aretrace , First, thank you for your ticket. I fear your assumption is wrong, that JPro enforces SSL. It's a recommendation to use SSL, but it's enforced nowhere. Actually, the JPro server itself doesn't even support SSL. It's just recommended to use some kind of Reverse Proxy/Load Balancer, which accepts the request with SSL and forwards it to the JPro server without SSL.

Which is kind of exactly what you are trying to do.

So please keep us updated, if you encounter any further issues!

aretrace commented 2 years ago

I see, I getting the following from the logs:

c.jpro - application requested: !0 ... p.a.h.DefaultHttpErrorHandler - ... Internal server error, for (GET) [/app/ws/!0] ... play.api.UnexpectedException: Unexpected exception[MatchError: AppByID(0,None) (of class com.jpro.internal.config.ApplicationStarter$AppByID)] at play.api.http.HttpErrorHandlerExceptions$.throwableToUsefulException(HttpErrorHandler.scala:358) at play.api.http.DefaultHttpErrorHandler.onServerError(HttpErrorHandler.scala:264) at play.core.server.Server$$anonfun$handleErrors$1$1.applyOrElse(Server.scala:112) at play.core.server.Server$$anonfun$handleErrors$1$1.applyOrElse(Server.scala:108) at scala.runtime.AbstractPartialFunction.apply(AbstractPartialFunction.scala:38) at play.core.server.Server$.getHandlerFor(Server.scala:132) at play.core.server.AkkaHttpServer.handleRequest(AkkaHttpServer.scala:323) at play.core.server.AkkaHttpServer.$anonfun$createServerBinding$1(AkkaHttpServer.scala:225) at akka.http.scaladsl.Http2Ext.$anonfun$handleUpgradeRequests$1(Http2.scala:145) at akka.stream.impl.fusing.MapAsync$$anon$30.onPush(Ops.scala:1307) Caused by: scala.MatchError: AppByID(0,None) (of class com.jpro.internal.config.ApplicationStarter$AppByID) at com.jpro.internal.config.Config$$anon$1.$anonfun$getAppDef$3(Config.scala:159) at scala.Option.map(Option.scala:230) at com.jpro.internal.config.Config$$anon$1.getMultiViewStart$1(Config.scala:159) at com.jpro.internal.config.Config$$anon$1.$anonfun$getAppDef$8(Config.scala:185) at scala.Option.orElse(Option.scala:447) at com.jpro.internal.config.Config$$anon$1.getAppDef(Config.scala:185) at controllers.jpro.jproApp(jpro.scala:500) at jpro.Routes$$anonfun$routes$1.$anonfun$applyOrElse$36(Routes.scala:916) at play.core.routing.HandlerInvokerFactory$$anon$1$$anon$2.call(HandlerInvoker.scala:65) at play.core.routing.GeneratedRouter$$anon$2.call(GeneratedRouter.scala:491)

FlorianKirmaier commented 2 years ago

Can you elaborate a bit, on how you get this error? Which JPro Version are you using? Is this reproducible locally? How does the html-page/jpro-tag look like?

aretrace commented 2 years ago

These are standard console outputs when the container is running the bin/start.sh script (and bin/restart.sh)
JPro version and other related info in first post
This is not reproducible locally. My local docker build works as expected (normal server/application behavior), when deployed to Cloud Run the above messages show on every request
The web app just hangs (stuck showing the connection loading spinner) and the client console shows its unable to connect to a websocket connection.

FlorianKirmaier commented 2 years ago

Hm, what does the HTML-page look like? I guess it's the default from the jpro-server?

It looks to me like "Cloud Run" is somehow manipulating the request. Especially because you don't get this error when running localy.

aretrace commented 2 years ago

Here is the html:

<!DOCTYPE html>

<html>
    <head>
        <title>JPro Application: default</title>

        <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no">

        <link href="/jpro/img/favicon.png" rel="icon">
<link rel="stylesheet" type="text/css" href="/jpro/css/jpro.css">
<script src="/jpro/js/jpro.js" type="text/javascript"></script>

    </head>

    <body>

        <jpro-app href="/app/default" fullscreen="true"/>

    </body>
</html>

Screenshot:

Console info from both client and server in previous comments

FlorianKirmaier commented 2 years ago

Thank you for mentioning this. I've just checked, we've got also a similar report, when using "Digitalocean app-platform".

At a minimum, the error-message is very missleading. We will investigate this.

besidev commented 1 year ago

Hello @aretrace We are now able to reproduce exactly the same issue on DigitalOcean App Platform, so we can look closely to it and find the appropriate solution as soon as possible. Thank you for your patience.

FlorianKirmaier commented 1 year ago

@aretrace We've fixed the issue! It was a really stupid error. You can try version 2023.1.0-SNAPSHOT ! We did some refactoring for the Maven/Gradle plugin, so here is a snippet of the Changelog, with the new dependency names:

2023.1.0

NEW

Complete rewrite of the gradle plugin. Gradle Kotlin DSL is now supported.
Gradle plugin was renamed from com.sandec.jpro to jpro-gradle-plugin
Rename gradle and maven plugins group from com.sandec.jpro to one.jpro

Feel free to reopen it, or create new tickets if you have any further issues!

aretrace commented 1 year ago

@FlorianKirmaier Nice!

Could we get an updated Maven template file, I'm getting a dependency resolution error and the website's POM is still on version 2022.1.8

FlorianKirmaier commented 1 year ago

Try these instructions:

Previous Maven plugin configuration:

<plugin>
      <groupId>com.sandec.jpro</groupId>
      <artifactId>jpro-maven-plugin</artifactId>
      <version>2022.1.8</version>
      <configuration>
           ...
      </configuration>
</plugin>

New Maven plugin configuration:

<plugin>
      <groupId>one.jpro</groupId>
      <artifactId>jpro-maven-plugin</artifactId>
      <version>2023.1.0-SNAPSHOT</version>
      <configuration>
           ...
      </configuration>
</plugin>

(we've changed the group-id)

aretrace commented 1 year ago

I've got a full vanilla pom from the updated examples and the image builds, but still getting erroneous ws behavior. Here is what I get: err In the future I will attempt to run this with another docker application deployment platform to see if this is a Cloud Run specific issue. Please let me know if you need any additional information from me.

FlorianKirmaier commented 1 year ago

@aretrace Thank you for the feedback! I have to say, that we didn't try it on Google Cloud Run, because we've been able to reproduce the issue with another environment. So, I guess we will now reproduce this issue - and find out why this is happening.

besidev commented 1 year ago

We have just reproduced the issue on Google Cloud Run platform and the solution was to disable the option: use of HTTP/2 end-to-end on Networking section of the revision deployer. After this change, it worked for us.

@aretrace if your issue still persists, please provide use with a sample project you are currently using so we are perfectly sure on reproducing it. Thank You.

aretrace commented 1 year ago

The issue still persists. THIS is an MRE, it's config is what i'm using. In the GCP console im building from the GitHub source (based on the dockerfile) and keeping everything else default (including no use of HTTP/2 end-to-end).

besidev commented 1 year ago

Hello @aretrace. The issue is inside your Maven POM, specifically in the configuration of the JPro Maven Plugin. Replace line <mainClass>...</mainClass> with <mainClassName>com.example.example.Main</mainClassName> in:

<plugin>
    <groupId>one.jpro</groupId>
    <artifactId>jpro-maven-plugin</artifactId>
    <version>${jpro.version}</version>
    <configuration>
      ...
       <mainClassName>com.example.example.Main</mainClassName>
      ...
    </configuration>
</plugin>

We also made a pull request so you can try our changes.

besidev commented 1 year ago

@aretrace Do you have any issues with running JPro using Google Cloud Run after the merge. We would appreciate your feedback. Thank you.

aretrace commented 1 year ago

@besidev Thank you! (XML gives me a bit of a headache) My application is now in working order. @FlorianKirmaier thank you as well.

JPro-one / JPro