Http Transport integrated with aspnet core could enable easy deployment of PAAS services

[valeriob]

I would like to deploy akka.net clusters in cloud PAAS services like Azure Web Apps, but those environment are constrained to HTTP(s). They do not allow connections on other ports. I was thinking if an integration package providing a new transport that could be easely integrated with aspnetcore, could enable this scenario :

Maybe there are already solution out there that i could not find, but from my research right now it's not possible to deploy akka clusters on Azure Web App and Web Apps for containers. I'm trying Container App but with whout much luck untill now, maybe some one has some guide about it ?

Thanks

[cecilphillip]

Something like Azure Containers Apps might be a good option for you. PaaS for container. Use whatever internal port and protocol you want

[valeriob]

Thank you @cecilphillip i'll try to make it work there, but still there are serious limitations on the ingress : https://github.com/microsoft/azure-container-apps/issues/201 this will impact the debug and diagnostic of the cluster (no petabridge.cmd, no external join to the cluster) :( Also going for containers (and complicating the deployment) would be a requirement imposed by akka and not by the application per se, that's unfortunate.

For the transport i would love to give it a try, but the code is quite articulated, is there some resource i could learn from ? At the moment i'm studyng the TestTransport because the DotNettyTransport is very complex, and it's hard to discern akka concepts from dotnetty ones.

Thanks Valerio

[Aaronontheweb]

Don't think you need a custom HTTP transport at all TBH, what you need is a custom vNET that allows you to expose additional ports added to your Azure App Service application: https://docs.microsoft.com/en-us/azure/app-service/networking/private-endpoint <-- one possible way of doing it.

@Arkatufus is working on, as part of Akka.NET v1.5, a service discovery plugin that should help automate cluster formation in these environments. This will include a sample + guide on how to do this. He can speak more to it on this thread.

[Aaronontheweb]

For what it's worth, I do have a 100% complete gRPC Akka.Remote implementation lying around that will fallback to working over HTTP 1.1, I think, but I wouldn't recommend using it on an unsecured public HTTP port. All Akka.Remote communication channels should be non-public.

[valeriob]

Don't think you need a custom HTTP transport at all TBH, what you need is a custom vNET that allows you to expose additional ports added to your Azure App Service application: https://docs.microsoft.com/en-us/azure/app-service/networking/private-endpoint <-- one possible way of doing it.

Thank you @Aaronontheweb i'll look into it. My point for an aspnet core transport (it's more appropriate than calling it http) is to lower the infrastructure barrier for using akka.net, making it play ball with aspnet core you could virtually deploy everywhere it works (like everywhere), because the listening part would be done by a piece of code integrating as an aspnetcore middleware opening a websocket, the outbound connection should be easy too, just a websocket client. Something like :

@Arkatufus is working on, as part of Akka.NET v1.5, a service discovery plugin that should help automate cluster formation in these environments. This will include a sample + guide on how to do this. He can speak more to it on this thread.

Thanks, i look forward to read more, i was curious if akka remote requires a fully connected graph or not, if not the routing node could become bottleneck for a sharded cluster ?

For what it's worth, I do have a 100% complete gRPC Akka.Remote implementation lying around that will fallback to working over HTTP 1.1, I think, but I wouldn't recommend using it on an unsecured public HTTP port. All Akka.Remote communication channels should be non-public.

Thanks but i do not think this will help, i was thinking to be able to receive incoming connection via aspnet pipeline. Anyway i understand the security implication of exposing the akka.remoting endpoint, in such scenarion an auth mechanism should be used (maybe just certificates).

[Arkatufus]

@valeriob Aaron is right, you will need Azure Virtual Network (VNet) to open private ports in the web app container. VNet are linked to the container provider, in Azure App Service this is usually the Azure Server Farms service, to provide us with usable private IP addresses, these are in the form of a CDIR block and the actual IP address will be passed to the web app instance via the WEBSITE_PRIVATE_IP environment variable.

The biggest problem right now is that you do not have any control over these ports, they're assigned by random, you only have the options of asking how many private ports you would like to have, at least when you are using Azure App Service. These private ports are then passed to your application instance as a comma separated value via the WEBSITE_PRIVATE_PORTS environment variable.

The problem problem we're having is caused by the dynamic nature of these IP address and port numbers assignment, we would not know how to connect our cluster together. We would need to create an address registry outside of the PaaS service for all cluster nodes that have started up and needed to connect to one another.

[valeriob]

Thanks for explaining it. If I understand correctly a transport alone will not be enough because the hosts should be able to connect to each other, and that's not allowed on Web Apps, not even via http. An hub approach could enable this cenario but would introduce a bottleneck correct ?

[to11mtm]

For what it's worth, I do have a 100% complete gRPC Akka.Remote implementation lying around that will fallback to working over HTTP 1.1, I think, but I wouldn't recommend using it on an unsecured public HTTP port. All Akka.Remote communication channels should be non-public.

Yes Please.

[Arkatufus]

@valeriob Sorry for the late reply, the VNet appears to allow for private network communication between the instances, the main problem is the dynamic port assignment. There would need to be a discovery service that connects all the instances as a cluster.

[valeriob]

Thanks for your reply @Arkatufus very insightfull ! So in theory could be possible to have an akka cluster in azure web apps, I look forward for 1.5 and the sample !

Valerio

[Arkatufus]

@valeriob we do have code samples for setting up Akka.NET inside Azure App Service and Azure Container App now. You can download them here: https://github.com/petabridge/azure-app-service-akkadotnet https://github.com/petabridge/azure-container-app-akkadotnet