I’m finally learning how to setup a proper game server architecture on fly.io, and I have some questions since I’ve never actually done this before
So far, my I have the following apps & their deployment pipelines ready
client: responsible of a spa application on the frontend. No problems there.
api: responsible of a regular application communication with database/api handling and can create machines with the machines api
game-server-gateway: I recently created this to communicate with the game-server app’s machines via fly-replay
game-server: the host of N amount of game-server machines created dynamically from the api app
Now, the real question is; how to actually communicate with the game-server machines? Currently I’m trying to just make a request to game-server-gateway app’s root path, with machine header information. Here is the code for it:
// Game server gateway machine
app.get('*', (c) => {
const region = c.req.header('region')
const instance = c.req.header('instance')
if (!region || !instance) {
throw new Error('Machine not found')
}
console.log('replaying', `region=${region};app=floating-islands-game-server;instance=${instance}`)
c.header('fly-replay', `region=${region};app=floating-islands-game-server;instance=${instance}`)
return c.body('OK')
})
It seems to “work”, since I do get a timeout and the console log information to the gameway app log. But is this the right way to do things, if I just want to replay the request to the game server machine? There should be a root path returning arbitrary data in the game server machines end:
// Game server machine
app.get('/', async (c) => {
const adventure = await getAdventure()
console.log(adventure)
return c.json(adventure)
})
But since I do get a timeout, I may have done something terribly wrong. I’ve allocated ip:s for the game server apps as well but I wonder if this is required? Should the replay header work in the internal networkings of fly without any hassle?
Here is the toml file. It used to be a bit less complex, but I copy pasted some configs in desperation from a previous (singular) application/machine I had like two years ago. It used to have udp but this might not be the case now. Would just like to get http/ws working before that
# fly.toml app configuration file generated for floating-islands-api on 2024-03-29T21:25:59+02:00
#
# See https://fly.io/docs/reference/configuration/ for information about how to use this file.
#
app = 'floating-islands-game-server'
primary_region = 'ams'
[env]
PORT = '8000'
[build]
dockerfile = 'Dockerfile'
[experimental]
allowed_public_ports = []
auto_rollback = true
[[services]]
internal_port = 10000
protocol = "udp"
[[services.ports]]
port = 10000
[[services]]
http_checks = []
internal_port = 8000
processes = ["app"]
protocol = "tcp"
script_checks = []
[services.concurrency]
hard_limit = 2000
soft_limit = 1000
type = "connections"
[[services.ports]]
handlers = ["http"]
port = 80
[[services.ports]]
handlers = ["tls", "http"]
port = 443
[[services.tcp_checks]]
grace_period = "1s"
interval = "15s"
restart_limit = 0
timeout = "2s"
[[vm]]
memory = '256mb'
cpu_kind = 'shared'
cpus = 1
Also, here is my github actions script/step for this (btw just noticed I was building from wrong dockerfile, but fixing it seems to not work either):
I also noticed that all my secrets are all still staged… This might prevent the machine from booting normally since it might crash because of the database connection not being able to initialize. I’ve not actually deployed the app at all since it should only contain machines that are spawned by the api -app. What is the best course of action on this, to get the secrets deployed properly?
Hmmm, it says: 'fly secrets deploy' will only work if the app has been deployed and there are machines available There is currently one machine “running”, as in it might be crashed since the secrets are not available… What to do…
EDIT: Does this mean my app is not deployed at all and might be causing all the problems? How to deploy it if I do not want any machines running other than the dynamic ones?
I think things may have gotten into a non-intuitive state that is (as far as I know) primarily intended for Fly Postgres machines: the app exists and has a machine, but there are no “releases” in the strictest sense.
Maybe try the following, first, to confirm:
$ fly app releases -a floating-islands-game-server
$ fly m status -d -a floating-islands-game-server
$ fly logs -a floating-islands-game-server
For the second one, you’re looking for fly_release_id and fly_release_version as metadata keys.
(And the third will typically help resolve doubts about why it’s crashing, .)
If the hypothesis does hold up, then you might be able to use --update-only to introduce a release without the creation of any machines.