Does my fly.toml look correct?

Hi :wave: I’m new to fly.io and trying to stand up a HLDS gold src server docker image I put together. It works locally without issue, but I’m not sure if how I have the fly.toml setup is correct. I have the following that need to be exposed/published in my dockerfile (see below). The deployment looks like it works but I am not able to access any of the ports externally.

  • I’m not sure if its a matter of ipv6 messing with the older server or what. I can manually bind it to eth0’s ipv4 address also if necessary.

  • Do TCP health checks work for any TCP ports?

--> Validating app configuration done
Services
UDP 27015 ⇢ 27015
UDP 27020 ⇢ 27020
UDP 26900 ⇢ 26900
TCP 27015/27015 ⇢ 27015
App
  Name     = [REDACTED]
  Owner    = personal
  Version  = 0
  Status   = running
  Hostname =  [REDACTED]

Services
PROTOCOL PORTS
UDP      27015 => 27015 []
UDP      27020 => 27020 []
UDP      26900 => 26900 []
TCP      27015 => 27015 []
         27015 => 27015 []
Instance
  ID            = bc95b9da
  Process       =
  Version       = 0
  Region        = lax
  Desired       = run
  Status        = running
  Health Checks = 1 total, 1 critical
  Restarts      = 0
  Created       = 2m45s ago

Recent Events
TIMESTAMP            TYPE       MESSAGE
2022-02-11T06:36:08Z Received   Task received by client
2022-02-11T06:36:08Z Task Setup Building Task Directory
2022-02-11T06:36:54Z Started    Task started by client

Checks
ID                               SERVICE   STATE    OUTPUT
238cd0125d26d540a884fa119a624ef5 tcp-27015 critical dial tcp 172.19.10.154:27015: connect: connection refused

fly.toml

app = "[REDACTED]"

kill_signal = "SIGINT"
kill_timeout = 5
processes = []

[env]

[experimental]
  allowed_public_ports = []
  auto_rollback = true

[[services]]
  http_checks = []
  internal_port = 27015
  processes = ["app"]
  protocol = "udp"
  script_checks = []

  [services.concurrency]
    hard_limit = 25
    soft_limit = 20
    type = "connections"

  [[services.ports]]
    handlers = []
    port = 27015

[[services]]
  http_checks = []
  internal_port = 27020
  processes = ["app"]
  protocol = "udp"
  script_checks = []

  [services.concurrency]
    hard_limit = 25
    soft_limit = 20
    type = "connections"

  [[services.ports]]
    handlers = []
    port = 27020

[[services]]
  http_checks = []
  internal_port = 26900
  processes = ["app"]
  protocol = "udp"
  script_checks = []

  [services.concurrency]
    hard_limit = 25
    soft_limit = 20
    type = "connections"

  [[services.ports]]
    handlers = []
    port = 26900

[[services]]
  http_checks = []
  internal_port = 27015
  processes = ["app"]
  protocol = "tcp"
  script_checks = []

  [services.concurrency]
    hard_limit = 25
    soft_limit = 20
    type = "connections"

  [[services.ports]]
    handlers = []
    port = 27015

  [[services.ports]]
    handlers = []
    port = 27015

  [[services.tcp_checks]]
    grace_period = "1s"
    interval = "15s"
    restart_limit = 0
    timeout = "2s"

For TCP connectivity you’ll need to bind to the IPV6 interface. The easy way is to just bind to ::.

But for UDP connectivity, you’ll want to bind to fly-global-services. That should work for both UDP and TCP. I don’t know if the +ip option can use a hostname like that, but worth a try!

So is fly-local-services some kind of hostname that should be resolvable inside the container? Tried to ssh in and ping that with no response.

fly-local-services — errr, sorry, fly-global-services — is just an entry in /etc/hosts on your VM that makes it easier for you to bind to the special address you need to bind for UDP services.

Here’s some recent documentation: