How to specify regions to run in?

1

Problem: Flyctl List shows two VM’s per region, rather than having an instance in each region.

App
  Name     = name
  Owner    = name
  Version  = 12
  Status   = running
  Hostname = name.fly.dev

Deployment Status
  ID          = 
  Version     = v12
  Status      = successful
  Description = Deployment completed successfully
  Instances   = 6 desired, 6 placed, 6 healthy, 0 unhealthy

flyctl
Instances
ID       VERSION REGION DESIRED STATUS  HEALTH CHECKS      RESTARTS CREATED
2d383ff9 12      ord    run     running 1 total, 1 passing 0        7m29s ago
a061e8dd 12      ord    run     running 1 total, 1 passing 0        7m59s ago
0d41ccbe 12      sea    run     running 1 total, 1 passing 0        8m8s ago
5931d3ed 12      sea    run     running 1 total, 1 passing 0        8m46s ago
5a884205 12      atl    run     running 1 total, 1 passing 0        8m46s ago
923db441 12      atl    run     running 1 total, 1 passing 0        9m17s ago

Here’s my region pool:

Region Pool: 
atl
ewr
iad
lax
ord
sea

Can I force Fly to keep VM’s running in each region?

As an aside, my use case is running a latency benchmark from each edge location. I plan on calling the instance internally with region.name.fly.dev. If I send a request like that to a region that’s offline, what happens? A 500 error?

1 Like
2

@austincollinpena could you run flyctl autoscale show? Just want to see if this app is on standard or balanced autoscaling.

Either way though, the best way to force apps to run in certain regions is a to attach them to volumes, which is covered in Anchor Scaling: Scaling and Autoscaling

Regarding the region.app.fly.dev question, we don’t actually have that enabled right now on external DNS. There is such a feature on the region.app.internal system, and that will return empty if there are no instances in the region.

3

Actually, in this case you might not even need to bother with volumes: fly scale count 6 --max-per-region 1 ought to spread your instances across the regions.

3 Likes
4

Thanks @sudhir.j

Oddly enough, my scale mode is Scale Mode: Disabled. Just launched the application yesterday. Happy to help debug.

I think my fly CLI was quite old though, that might have been it.

After running flyctl scale count 6 --max-per-region 1

I still have this:

VM Resources for name
        VM Size: shared-cpu-1x
      VM Memory: 256 MB
          Count: 6
 Max Per Region: Not set

But my regions list is actually correctly distributed now.

Any idea as to why --max-per-region doesn’t work? I don’t even see it in the docs.

5

The “Not set” might just be a CLI bug, I’ll double check it and raise a report.

And the default autoscale mode is disabled, that’s fine for now. Do you need the number of instances to scale up automatically?

6

Perhaps it’s “not set” because my max is six and the total is six?

7

Would still expect it to show whatever was last passed in as --max-per-region… I’ve raised an issue, will post again here if we’re both mis-reading it somehow :stuck_out_tongue:

8

Oh, I met I’d expect the autoscale not to show. I would expect --max-per-region to show the right item.

9

I’d expect the autoscale not to show.

fly autoscale show should still just be Scale Mode: Disabled at this point… not sure I understand. Since the scaling system is separate from the autoscaling system, we haven’t actually engaged autoscaling yet.

10

Accessing https://atl.app-name.internal gave me an error. Any ideas?

443: connect: connection refused

11

Inside the internal network HTTPS isn’t really used or necessary — all communication is already internal and secured by Wireguard. So http://atl.app-name.internal should work, assuming you have an instance running in atl.

12

Makes sense. Let me know about the --max-per-region once you hear back. I’ll just attach a disk if it’s a big issue :slight_smile:

13

Would you still need to attach a disk? I think the --max-per-region setting has taken effect, probably just not being displayed correctly on the show call. Let me know if it deviates from running one instance per region?

14

I think it is working, just not showing. I bet my problem is solved there :slight_smile:

I’m still getting this error though:

Get "http://ewr.name.internal/path": dial tcp [fdaa:0:389a:a7b:21a1:25d0:2766:2]:80: connect: connection refused

  • Not a typo on the app name
  • region is running
  • Request is being made from a fly.io VM

Other info:

Region Pool: 
atl
ewr
iad
lax
ord
sea

Is it because my container isn’t listening on port 80?

15

Listening on port 80 from my container seemed to fix it.

1 Like
16

I think the port mapping is applied, but your application might not be binding on IPv6. I can help if you share the details of the tech stack, but usually applications will bind to 0.0.0.0:$PORT — you want them to bind to [::]:$PORT which is the IPv6 equivalent. Each server / programming language has a slightly different way to do this, if it’s not clear you can let me know what stack you’re using.

EDIT: the problem was the port, keeping this here for later reference.

17

Oh, right good point. Port mappings are not applied on .internal.

18

All looks great now. Thanks so much @sudhir.j, you’re awesome!

1 Like
19

Neat. If there were 3 VMs running in atl, say, which VM does the DNS query for atl.app-name.internal return? Round robin among the 3? Sorted by private IP? Random? Or all 3?

20

These are actually DNS calls, so I think they return all 3, someone from the team will correct me if I’m wrong. See Private Networking and GitHub - fly-apps/privatenet: Examples around querying 6PN private networking on Fly

1 Like