googleforgames / agones

Dedicated Game Server Hosting and Scaling for Multiplayer Games on Kubernetes
https://agones.dev
Apache License 2.0
6.09k stars 812 forks source link

Register GameServers with local IP addresses #469

Closed markmandel closed 5 years ago

markmandel commented 5 years ago

Problem

For development/QA purposes, it is useful to be able to register a gameserver with Agones, but overwrite it with a specific local IP address, so that it can run through the same Agones system, but QA testers can connect to it, without having to do a full build + deploy pipeline.

Design

We assume all port configuration should be static. If the GameServer has an annotation of: stable.agones.dev/dev-address: "192.168.0.1" then we intercept this in the controller:

  1. Don't create a Pod
  2. Use this as the Status.State address.
  3. Static port configurations are moved directly into Status.Ports
  4. Automatically mark this GameServer as Ready.

Example:

apiVersion: "stable.agones.dev/v1alpha1"
kind: GameServer
metadata:
  name: "xonotic"
  annotations:
    stable.agones.dev/dev-address: "192.168.0.1"
spec:
  ports:
    - name: default
      portPolicy: static
      containerPort: 26000
      hostPort: 26000
  template:
    spec:
      containers:
        - name: xonotic
          image: gcr.io/agones-images/xonotic-example:0.4

Questions

markmandel commented 5 years ago

/cc @ReDucTor - we talked about this a while back, can you see if this design captures what we discussed?

reductor commented 5 years ago

Looks good, would simplify some of our alternative approaches to the problem.

jeremyje commented 5 years ago

I'm looking into this.

jeremyje commented 5 years ago

I'm still working through the bug, I have a test and the logic implemented here, https://github.com/jeremyje/agones/tree/local-ip.

I have a question though, When you say don't create a pod. Does that mean the QA server isn't managed by Agones/Kubernetes and that the goal is to mainly register the existence of the QA server? Bypass all those liveness checks and all that.

markmandel commented 5 years ago

Exactly. The active game server likely sits on someone's machine at their desk, and this gives them a way to basically "fake" a Ready gameserver on an Agones cluster, that someone can then connect to within their corp-network.

Then all your other tooling (matchmaking, etc) can still work as per normal - you can even allocate this GameServer - but it makes life easier for development.

jeremyje commented 5 years ago

Wouldn't you want this server to be marked as Allocated then?

reductor commented 5 years ago

Marking it as already allocated would be game specific

markmandel commented 5 years ago

:+1: on what @ReDucTor said - I think in most cases you would want it to be ready, so you can flow through from your matchmaker to your game server just like you would normally.

At the very least, we should start with Ready and see if people have a desire to have an option to move to Allocated as well - and we can do that as a separate PR.

WDYT?

markmandel commented 5 years ago

Implemented in #558