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.
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.
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.
@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?
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.
Workers: We moved everything from AWS Lambda into CloudFlare Workers last year.
Caching: We make extensive use of the CDN
Access: We use CloudFlare Access to setup access to company resources, don’t need to worry about VPN’s, SSO, etc.