Send request to a specific VM

Hi,

First time here, How do I send a request (POST/GET) to a specific VM via its ID?

Context

I have 3 VMs running in 3 locations that listen for a GET request at a path (/test).

I’ve read from some threads here that I need to add a header "Fly-Instance-Id": "<instance_id>" to direct the request to a particular VM or by using fly-force-instance-id.

I’ve added this when making the GET request but my request always gets routed to a single location when viewing the app logs (flyctl logs) despite having other healthy VMs running in separate locations.

I believe a header should work. When you say ‘single location’, do you mean region or instance ID? The logs should show both and it may be the same region is hit (probably the closest one) but that gateway/load balancer is forwarding the request to a different (specified) vm/instance.

An alternative approach would be to use the DNS name. You can send the request to a specific VM using:

<alloc_id>.vm.<appname>.internal

… but that would only work internally, not from the outside world.

1 Like

Hi Greg,

I mean an Instance ID (VM)

I can see from the logs that the requests are being forwarded to a single instance “app [app_id]

Yes, but we need to send the request from an external network

Hi,

Ah. Yes, from an external network you could not use the .internal domains directly. So that option is out.

Back to the header approach then. That should work. I’ve also seen that approach mentioned e.g

Yet you say it’s ignored (as the same VM ID is given each request regardless). Hmm. Not sure I’m afraid. It sounds like someone at Fly will need to debug that for you.

1 Like

Thank you Greg!

@kurt @jerome, kindly assist me here

1 Like

Looks like there was a bug with our fly-force-instance-id header. We’re working on a fix.

Hello @jerome ,

Thank you for your prompt response, looking forward to that fix, would you be kind enough to notify us via this thread as soon as it is implemented? as this is an important part of our setup.

@mankind the fly-force-instance-id header should now be fixed.

1 Like

@jerome Been testing fly-force-instance-idand fly-prefer-region and both don’t seem to work. I’m not using the HTTP handler: Public Network Services Is that required for these headers to work?

Yes, it only works when using the HTTP handler, else we don’t parse HTTP at all and therefore can’t act on headers.

1 Like

Thanks, the problem is I’m running behind CloudFlare; not using any handlers, see also: Cloudflare 525 error randomly occurs - #8 by johan

I would still like to use the fly-force-instance-id and fly-prefer-region headers. Is there anyway, that this could be possible?

I don’t think there’s any way around that unless you use the private IP that doesn’t go through our proxy. That would work for targeting a specific instance, but it wouldn’t go through anything else, it would reach the instance directly on its port listener.

From your post in the other thread, I see you’re using CF Workers? Are there other features you rely on from Cloudflare?

We’d need to talk to an engineer there to fix these random 525 errors. We can’t tell what’s causing them precisely. The main thing I can see if we don’t have a compatible list of TLS ciphers, ours are a lot more restrictive. I’m not sure why that would even matter in most cases though (except perhaps forward secrecy?)

Thanks Jerome for the reply, I expected as much, still wanted to ask. Yes, the private IP approach is what I’m already using.

I initially build a little request forwarder using goreply, see fly-replay for every other instance? - #10 by johan). Have completely rebuild this in the past months using Swoole. I’m now running a multi-process container, with S6 overlay, and multiple Swoole services, forwarding requests between multiple fly app instances. Works like a charm.

About your question, yes we use and rely extensively on CloudFlare and CloudFlare Workers.

  1. Workers: We moved everything from AWS Lambda into CloudFlare Workers last year.
  2. Caching: We make extensive use of the CDN
  3. Access: We use CloudFlare Access to setup access to company resources, don’t need to worry about VPN’s, SSO, etc.
  4. DNS: We manage our DNS through CloudFlare.

Does that help?