Support web sockets - Githubissues

gsogol commented 3 years ago

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do * not help prioritize the request If you are interested in working on this issue or have submitted a pull request, please leave a comment

Tell us about your request Ability for the automatic load balancer to support web sockets

Describe alternatives you've considered Using Beanstalk and enabling web sockets support in application load balancer

gsogol commented 2 years ago

Just curious if there's an update. It's been over 16 months. Close to 200 people votes on this.

nebbles commented 2 years ago

Similarly, very keen to see even a brief word about where this is being prioritised from AWS team (@amitgupta85 please forgive the tag). Just to note (very selfishly), this is the one outstanding piece of functionality that prevents my team from migrating from Heroku, since our application uses websockets for GraphQL.

The top seven upvoted issues in this repo are all extremely desirable in my view, but this is the only one that outright blocks us from even experimenting with App Runner for our main app.

Top 7

bnicholl commented 1 year ago

Is there any update to this? My team wants to use App Runner for our streamlit applications, and this is a huge blocker for us

gsogol commented 1 year ago

I opened a support case, got the "No plans to support this". Isn't the idea to prioritize based on likes? You would think so but the team seems to be operating using their own prioritization and not Community.

bnicholl commented 1 year ago

Yea this seems like something a lot of people would need. Unfortunate they're not people their customers needs first.

amitgupta85 commented 1 year ago

@gsogol @bnicholl @nebbles We don't have native support for web sockets at this point. However, it is possible to place CloudFront and API Gateway in front of an App Runner service which has support for Web sockets.

For CloudFront, you can put a CloudFront distribution in front of a public App Runner service. For API Gateway, you have couple options

API Gateway in front of public App Runner service - You can use API Gateway HTTP proxy integration feature and put App Runner service behind an API Gateway. The traffic will flow from API Gateway -> public App Runner service. https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-create-api-as-simple-proxy-for-http.html
API Gateway in front of private App Runner service - Make the App Runner service private (accessible within a VPC) and use API Gateway VPCLink with HTTP proxy integration feature to put private App Runner service behind an API gateway. For VPCLink, you will have to set a NLB with targets as IP address of PrivateLink VPC endpoint. The traffic will flow from API Gateway -> NLB -> VPC endpoint -> private App Runner service. You can share the same API Gateway, NLB and VPC endpoint to access multiple private App Runner services so the cost of non App Runner infrastructure components (API Gateway, NLB and VPC endpoint) is shared as well as it is their one time setup and does not need to be repeated with every App Runner service - https://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started-with-private-integration.html

haversnail commented 1 year ago

For CloudFront, you can put a CloudFront distribution in front of a public App Runner service.

IIRC I did this very thing for Server-Sent Events, but to no avail. While yes, CloudFront does support WebSockets, the fact that the Envoy proxy used by AppRunner limits requests to 30 seconds means that this point is moot.

+1 to the AWS team prioritizing this.

wordiodev commented 1 year ago

I guess the App Runner team is very short-handed, making me worried in thinking to host my application with it.

henricook commented 1 year ago

Updates here would be much appreciated AWS team. I've just finished moving all my apps to app runner, spun up a test environment and only now realise there's no web socket support. I moved from a more complex (to manage) ALB/EC2 setup that supported it, so I expected it to be supported here.

Basically, I now have to move off App Runner to something else after spending hours/days moving my apps here - it's super infuriating.

henricook commented 1 year ago

@amitgupta85 All my hopes are on your post to save lots of wasted work. I've put a Cloudfront distribution in front of my public app runner service URL - but my app still seems to be getting a 403 when trying to open a wss:// connection - have I missed something?

amitgupta85 commented 1 year ago

We are taking a look at the CloudFront issue and will post updates soon. In the meantime, you can also try out the API Gateway option by following putting API Gateway in front of App Runner (as discussed above) and enabling web sockets on API Gateway - https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api-integration-requests.html

gsogol commented 1 year ago

@amitgupta85 or you can prioritize web sockets in AppRunner and call it a day. Community over internal priorities should always take precedence 🤔

henricook commented 1 year ago

It's not actually just websockets that's failing on a cloudfront distribution in front of my public apprunner endpoint, it's any request. Are there any special settings required above a normal origin-using-the-public-url? Does it have to be a custom domain? (I'm using my awsapprunner.com subdomain currently)

henricook commented 1 year ago

I guessed my way through a Websockets API API Gateway setup, because your instructions are pretty vague. I used a $request.body.action route selection expression, and in the $default route I connected an HTTP PROXY integration to my awsapprunner.com URL. I deployed to a stage called 'Prod' which gave me a url like this:

https://a1ykizot66.execute-api.ap-southeast-1.amazonaws.com/Prod/@connections

I think that means I should expect https://a1ykizot66.execute-api.ap-southeast-1.amazonaws.com/Prod/ping to return "Hello World"

to behave the same as https://gx6d3sumsa.ap-southeast-1.awsapprunner.com/ping which returns "Hello World"

.. which it does not. Although I've almost surely missed something because API Gateway is so complicated, any idea what?

henricook commented 1 year ago

For readers. I couldn't get this working with Cloudfront. Using the app runner domain it returned 404s/403s, after configuring a custom domain it only returned 502s.

Instructions are insufficient for API Gateway and I couldn't figure it out.

I've had to bail to Lightsail Containers (LC) until this gets sorted out but with barely any signs of life from the AppRunner team it seems unlikely.

Trade offs:

No github integration
LC lets you deploy images from your ECR but unfortunately doesn't have auto-hooks to deploy images on push, it requires a manual jiggle in the AWS UI.
Also its logs don't integrate with Cloudwatch logs and are fairly cumbersome to use.

haversnail commented 1 year ago

@henricook thanks for sharing your solution here, I appreciate the details. 👏 FWIW, I also had to find another solution for my own WS/SSE-powered containerized app and ended up having to create an entire ALB + Fargate Service just to run it.

IMO it is very disappointing that this issue has remained open for so long, with so many upvotes, with so little communication/guidance from the AWS team. Although I was able to navigate around this issue for a personal project, the lack of WS support in AppRunner has caused our team at work to re-evaluate deploying our service on AWS entirely, as we are currently leveraging multiple cloud providers at the moment. I would think it would be in the AWS team's best interest to prioritize this request, as without it, GCP's Cloud Run will continue to siphon current and potential customers away from AWS. 😞

pclokcer commented 1 year ago

I am working since 2 week. I learned not supported. big mistake for aws 👎

matteocontrini commented 1 year ago

We don't have native support for web sockets at this point. However, it is possible to place CloudFront and API Gateway in front of an App Runner service which has support for Web sockets.

For CloudFront, you can put a CloudFront distribution in front of a public App Runner service.

@amitgupta85 I'm not sure I understand how CloudFront would solve this problem. If the App Runner load balancer doesn't support WebSockets, how would adding an additional layer in front of App Runner enable it? Could you clarify? Thanks!

emeagenciadigital commented 1 year ago

This is something that you already have on ELB , api gateway etc why not just activate it on app runner ? Currently app runner is extremely easy to use but a modern need of apps as real-time is put under appreaciated

emeagenciadigital commented 1 year ago

+1

I know I’m making noise but maybe that is what’s needed .

pclokcer commented 1 year ago

@emeagenciadigital I dont want use ELB. I want to configure as I want

Harsh4999 commented 1 year ago

Is there any update on this any way around to use websockets with app runner without adding load balancer

amitgupta85 commented 1 year ago

Thank you for having patience on this issue. We would like to get some feedback on maximum request timeout that you would like us to have for Web sockets support in App Runner.

emeagenciadigital commented 1 year ago

All websocket libraries have their own timeout and reconnect functionality already and timeouts shouldn't really be something that happens when you app runs normally.

There’s also the need that some endpoints have different timeouts than others . It will be nice to keep it as normal as possible.

On Fri, 28 Apr 2023 at 7:05 PM amitgupta85 @.***> wrote:

Thank you for having patience on this issue. We would like to get some feedback on maximum request timeout that you would like us to have for Web sockets support in App Runner.

— Reply to this email directly, view it on GitHub https://github.com/aws/apprunner-roadmap/issues/13#issuecomment-1528264239, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJOJFKZBMXTNJ7YTDBQNFLXDRLLFANCNFSM45D3LC7A . You are receiving this because you were mentioned.Message ID: @.***>

-- Daniel Vengoechea Head of Growth e-me.co

-- Pd: Conoce nuestra nueva página web www.e-me.co http://e-me.co/?utm_source=email-signature-pd&utm_medium=email&utm_campaign=email-signature-pd

gsogol commented 1 year ago

@amitgupta85 Socket.io and many libraries default to 30 min. Your question, however is a maximum timeout. So not sure there. Many of us will be super happy just having websocket support regardless of the maximum value. Many libraries provide events for us to handle timeouts and ability to reconnect. So I will default to saying 30 min - 60 min.

But even if you're thinking in seconds, I'll take that and just handle timeouts myself (easy enough) as long as the wss actually goes through.

Any approximate timelines?

andymac4182 commented 1 year ago

Max connection time or idle timeout?

amitgupta85 commented 1 year ago

App Runner currently supports 2 mins of maximum request timeout. We are looking to understand what would be a reasonable maximum request timeout for web sockets support and if App Runner needs to support higher maximum request timeout as a prerequisite. If that is the case, what would be its value. Thank you.

emeagenciadigital commented 1 year ago

it is difficult to provide a general recommendation, as it will depend on the specific use case and the resources available. However, a reasonable starting point for WebSocket connections might be in the range of 5 to 10 minutes, with the ability to configure this value as needed based on the application's requirements.

On Fri, 28 Apr 2023 at 9:53 PM amitgupta85 @.***> wrote:

App Runner currently supports 2 mins of maximum request timeout. We are looking to understand what would be a reasonable maximum timeout for web sockets support and if App Runner needs to support higher maximum request timeout as a prerequisite. If that is the case, what would be its value. Thank you.

— Reply to this email directly, view it on GitHub https://github.com/aws/apprunner-roadmap/issues/13#issuecomment-1528546562, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJOJFPPDYWS745NLVZ2ELDXDR7D5ANCNFSM45D3LC7A . You are receiving this because you were mentioned.Message ID: @.***>

-- Daniel Vengoechea Head of Growth e-me.co

-- Pd: Conoce nuestra nueva página web www.e-me.co http://e-me.co/?utm_source=email-signature-pd&utm_medium=email&utm_campaign=email-signature-pd

gsogol commented 1 year ago

App Runner currently supports 2 mins of maximum request timeout. We are looking to understand what would be a reasonable maximum request timeout for web sockets support and if App Runner needs to support higher maximum request timeout as a prerequisite. If that is the case, what would be its value. Thank you.

Makes sense. Standard http requests should be quick. Those who are running jobs obviously will take longer. Those who run a websocket connection will be the longest. The key is to not scale down while the websocket connection is live and active.

Maybe start with 10 min?

nebbles commented 1 year ago

App Runner currently supports 2 mins of maximum request timeout

Is this the case even with data actively being transmitted? Heroku's approach^1 is:

"An application has an initial 30 second window to respond with a single byte back to the client. However, each byte transmitted thereafter (either received from the client or sent by your application) resets a rolling 55 second window. If no data is sent during the 55 second window, the connection will be terminated."

This is great since provided everything is healthy, the client and server can confirm with keepalive pings, keeping the connection open.

haversnail commented 1 year ago

App Runner currently supports 2 mins of maximum request timeout

Is this the case even with data actively being transmitted? Heroku's approach1 is:

"An application has an initial 30 second window to respond with a single byte back to the client. However, each byte transmitted thereafter (either received from the client or sent by your application) resets a rolling 55 second window. If no data is sent during the 55 second window, the connection will be terminated."

This is great since provided everything is healthy, the client and server can confirm with keepalive pings, keeping the connection open.

Footnotes

https://devcenter.heroku.com/articles/request-timeout#long-polling-and-streaming-responses ↩

@amitgupta85 rather than a fixed timeout, I would second the above approach, as this is the idiomatic way SSE connections are kept open as well — so as long as some data is being sent across the wire, the connection should stay open indefinitely — only when some data stops being sent should the connection timeout begin counting down.

bitnom commented 1 year ago

wow I've already baked in apprunner for months. now must add ws but oh no I found this

oleksandrzhyhalo commented 1 year ago

Any update on this?

JuanTelleria commented 1 year ago

Websockets would enable the usage of Streamlit for Python:

https://streamlit.io/ https://discuss.streamlit.io/t/new-deployment-option-aws-app-runner/13084

fabiobeoni commented 1 year ago

Supporting web socket is also strategic from a product management view, since competitor's services like GCP Cloud Run do support web socket ;)

pSnehanshu commented 1 year ago

Wait, this is ridiculous. Why would websockets not work? They are just normal TCP (HTTP) connections. But if that's the case, maybe I can use the long-polling strategy of socket.io, but even that wouldn't work without sticky sessions.

imcconley commented 1 year ago

I feel like I know the answer after reading this thread, but its been 3 months since anyone asked, so... any update here?

k-koehler commented 1 year ago

Just deployed my app which is using websockets and getting 403 error. I assume this is on app runner's side? Frustrating as hell

pSnehanshu commented 1 year ago

@k-koehler What is the exact error you receive? Not that I can solve it, but just curious.

k-koehler commented 1 year ago

@k-koehler What is the exact error you receive? Not that I can solve it, but just curious.

Thanks for the reply. I'm not receiving any error messages that I can see. I'm just getting 403 Forbidden when I hit wss://example.com/ws. I'm using nginx also, my config is:

    location /ws {
      proxy_pass http://localhost:8085;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
      proxy_set_header Host $host;
    }

instantiator commented 1 year ago

Looking forward to seeing any update on this issue. For now I guess I'll need to find another solution to host a websockets/socket.io service.

emeagenciadigital commented 1 year ago

I know app runner is easier to setup, if anyone is looking for another solution use aws fargate . It could be a long setup process. there’s a video on YouTube that shows the complete process but it takes long as you need to dockerize your NodeJS , send it to AWS ECR then create cluster and service on fargate connect it to a load balancer, manage redis for sockets connections etc . Its kind of a headache . I have done it before , takes a long time but ones is done it works pretty good and is less expensive than app runner .

fabiobeoni commented 1 year ago

Fargate, more steps to do but I would say pretty basic if you are used to containers.. I can help you need to move from AppRunner to Fargate.

On Fri, Sep 29, 2023, 1:06 PM EMEDIGITAL @.***> wrote:

I know app runner is easier to setup, if anyone is using for another solution use aws fargate but it could be a log setup process. there’s a video on YouTube that shows the complete process but it takes long as you need to dockerize your NodeJS , send it to AWS ECR then create cluster and service on fargate connect it to a load balancer etc . Is kind of a headache .

— Reply to this email directly, view it on GitHub https://github.com/aws/apprunner-roadmap/issues/13#issuecomment-1740715517, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEAZTKMEULBXMSFMV5C7M6TX42TSVANCNFSM45D3LC7A . You are receiving this because you commented.Message ID: @.***>

instantiator commented 1 year ago

I went with Lightsail in the end.

emeagenciadigital commented 1 year ago

Did you dockerize it on Lightsail or what was your approach ?

I think Lightsail is a lot more expensive with clusters

Daniel Vengoechea Head of Growth e-me.co

On Fri, 29 Sep 2023 at 5:12 PM Lewis Westbury @.***> wrote:

I went with Lightsail https://aws.amazon.com/lightsail/ in the end.

— Reply to this email directly, view it on GitHub https://github.com/aws/apprunner-roadmap/issues/13#issuecomment-1741539144, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJOJFPDDDEEQSNTTBSHRVDX45BUPANCNFSM45D3LC7A . You are receiving this because you were mentioned.Message ID: @.***>

-- Pd: Conoce nuestra nueva página web www.e-me.co http://e-me.co/?utm_source=email-signature-pd&utm_medium=email&utm_campaign=email-signature-pd

instantiator commented 1 year ago

Did you dockerize it

Yes. Here's my process, I ...

dockerised the application with a Dockerfile,
built the image locally (I used dockerx to build for amd64 - although iirc, lightsail does support arm64, too, I think),
pushed to ECR (although there's also a lightsail extension to awscli that allows you to push an image directly to your container service),
connected my lightsail container service to my private ECR repository (it takes care of permissions),
used the image from there in my container service deployment.

I've a script that creates the ECR repository, build and pushes the docker image to it.

What I've not done yet is figure out the CloudFormation to create the lightsail container service, connect it to ECR, and define the deployment inside it. So at the moment, I've done it all with clickops (which wasn't too complicated).

Modi08 commented 1 year ago

Hey is there any update on adding WebSocket support to AppRunner. I have shifted my application from Fargate to app runner And I need WebSocket. Does the apiGate way method still work

ivadenis commented 1 year ago

oh god....why web sockets dont work! pls fix this!

jamilAbbas commented 11 months ago

Oh no! I shifted from AWS Fargate to AWS App Runner thinking it is simple to manage and can pause the instances if not actively using them, but I did not know that App Runner does not have support for web sockets. Is the App Runner team working on adding this feature soon?

henricook commented 11 months ago

I think what you'll find is they're ignoring everyone asking for it, I'd move away again if I were you - it doesn't really seem like AppRunner is being maintained based on this

aws / apprunner-roadmap

Support web sockets #13

Footnotes