Agones: Adding AGONES_SDK_GRPC_HOST to NewSDK

[castaneai]

In local development, I'd like to run Agones SDK server on docker-compose.
However, the current Agones SDK always connect to localhost.

GameServer and Local SDK server cannot be run on different containers.

https://github.com/googleforgames/agones/blob/10719304a746990a9d4cdad9a1a05814713a9beb/sdks/go/sdk.go#L45-L49

One solution is to add AGONES_SDK_GRPC_HOST that can override localhost. What do you think?

[roberthbailey]

Out of curiosity, what value would you put in for the server address running on docker compose? I'm assuming compose doesn't had a concept of pods to put the two containers into the same network namespace, which is why you would need to override the address.

[castaneai]

For example, in the following docker-compose.yml I will set AGONES_SDK_GRPC_HOST=agones-sdk-server.
(docker-compose provides DNS resolution with the same name as the service name.)

version: "3"
services:
  gameserver:
    ...
  agones-sdk-server:
    ...

[markmandel]

Could you do host networking for all your containers in compose?

(Not saying that's a great idea, but it's a workaround for now)

[roberthbailey]

Can you steer containers in compose to land on the same underlying node? If not, host networking wouldn't help.

[markmandel]

Docker compose is single node isn't it? (I haven't used it for a while) - so essentially local development only?

[roberthbailey]

Good question. I've never used it, but based on https://docs.docker.com/compose/production/ it looks like you can run across multiple nodes using docker swarm:

If you want to scale up your application, you can run Compose apps on a Swarm cluster.

[markmandel]

@castaneai I assume you are using this for just local development?

It sounds like you are trying to replicate a Pod system locally for development?

[castaneai]

Yes, I'm using docker-compose for local development (on single node).
I have no intention to run on Swarm.
The reason I want to separate services in this way is because Docker recommends running only one process on one container.

[roberthbailey]

In that case, does @markmandel's suggestion above about using host network unblock you?

[castaneai]

That's true for Linux. However, host network is not supported on Mac and Windows. 😢

https://docs.docker.com/network/host/

The host networking driver only works on Linux hosts, and is not supported on Docker Desktop for Mac, Docker Desktop for Windows, or Docker EE for Windows Server.

[markmandel]

Can you do a variation on https://blog.mikesir87.io/2019/03/sharing-network-namespaces-in-docker/ , but with compose?

(Basically use another container's network?)

[castaneai]

Adding network_mode: service:gameserver works fine on docker-compose!
Thank you for the advice!

Here is my example repo.

https://github.com/castaneai/agones-sdk-playground

version: "3"
services:
  gameserver:
    build: .
  sdk-server:
    build: ./sdk-server
    network_mode: service:gameserver

[markmandel]

This sounds like it could be a cool thing to add to our docs somewhere. 👍

[mthssdrbrg]

I currently have a use case where it would be beneficial to be able to set the host / address (for both HTTP and GRPC) for the SDKs so that they can reach a SDK server (custom SDK server that doesn't bind to localhost by default) running in a different pod. I'm currently working around this by adding a TCP proxy sidecar that listens on localhost and forwards any connections to the SDK server, which works, but it would be great if I didn't have to add the sidecar :)

[roberthbailey]

Can you elaborate more about why you find it useful to run a custom SDK server (and if you can say, how different is it from the canonical implementation)? If you are running a proxy sidecar anyway, I'm curious what the advantage is of running the sdkserver is a separate pod. Is it always on the same machine or can it be elsewhere in the cluster?

It would be straightforward to modify the SDKs to take an environment variable for the host to connect to, but by pointing it outside of the current pod, I wonder if that ends up breaking some of the assumptions that are currently built into the different SDKs (e.g. they don't implement much retry logic since grpc requests to localhost pretty much always succeed once the sdkserver is up and running).

[mthssdrbrg]

Can you elaborate more about why you find it useful to run a custom SDK server (and if you can say, how different is it from the canonical implementation)? If you are running a proxy sidecar anyway, I'm curious what the advantage is of running the sdkserver is a separate pod. Is it always on the same machine or can it be elsewhere in the cluster?

I have some custom readiness logic, otherwise the implementation is the same (it's in go so there isn't really much code as I'm reusing most of the original SDK server).
So the sdkserver is running in the GameServer pod as per usual (but with a different image via the flag available by the Agones controller) alongside the game container and other sidecars, and then I have other pods (for various reasons) that use the Agones client SDKs, and these typically run on different machines (at the mercy of the scheduler).

It would be straightforward to modify the SDKs to take an environment variable for the host to connect to, but by pointing it outside of the current pod, I wonder if that ends up breaking some of the assumptions that are currently built into the different SDKs (e.g. they don't implement much retry logic since grpc requests to localhost pretty much always succeed once the sdkserver is up and running).

Ah, good point! That is definitely a concern, and to be honest not something that I have thought much about this far. Perhaps having a proper proxy with retries and whatnot would be a more reasonable solution than changing the client SDKs.

[markmandel]

Came up in #2054 - but I'm wondering if a set of open source sidecars that have different types of use cases would be a good way to tackle this, rather than trying to resolve it in core?

[mthssdrbrg]

Came up in #2054 - but I'm wondering if a set of open source sidecars that have different types of use cases would be a good way to tackle this, rather than trying to resolve it in core?

Yeah, I'm not sure it fits in core. I think sidecar(s) makes the most sense at this time, to test different things to see what works and what doesn't for different scenarios.

[dzmitry-lahoda]

i have windows containers, for them options like network_mode: service:gameserver

 Cannot start service agones: sharing of hyperv containers network is not supported

[dzmitry-lahoda]

AGONES_SDK_HOST may be better name