@kurt mentioned that the Machines feature is “not yet released” but it sounds intriguing. I wonder if you could share just a touch more about how we would be able to use machines. As it is I am unable to complete an end to end scenario but really don’t know what to expect so am sure it’s on me.
fly machine run -a machinetest registry.fly.io/<app image name from step 2>
That seems to have gotten a machine up and running
app[8d413be3] iad [info] HelloNode app listening on port 3000!
but I am not able to send requests to it. All of the following curl commands result in Could not resolve host: <host>.fly.dev or Could not connect to server.
curl http://machinetest.fly.dev:3000 – app name
curl http://purple-mountain-2208.fly.dev:3000 – machine name
curl -g -6 http://[fdaa:0:543a:a7b:775b:8d41:3be3:2]:3000/ – IP address of machine
Can you point to an end-to-end example of using a machine (where end to end starts with user source code and ends with a response to a user request from that code running on a machine.
They’re intended to be driven with API calls. We have a big API mesh that’s not fully rolled out yet, so when you start a machine in Sydney from Sydney, your traffic stays local. It lets you start machines in 500ms or so.
fly machines are a convenience wrapper around the API. When we started documenting the API, we realized APIs are kind of hard to poke at. So the CLI has commands that approximate the API.
Thanks for the quick response. I added -p 3000:80/tcp:http but still get the same errors. Having done that, what curl command should work?
FWIW, I’m very much in the API camp and am focused on high volume lambdas (your #2) with modest volume build (#1). Right now I’m scripting the CLI but would much rather be calling an API. All in due time, I get it. Right now I just need to do a proof of concept that this can actually work.
You’ll need to run fly ips allocate-v4 to put an anycast IP on that app. Then run fly ips list and use that IP in curl. We don’t setup the *.fly.dev certificate for machine apps yet.
OK. Feels like I’m getting closer but still not quite there. I added an IP address but now get a Connection reset by peer error with curl and nothing shows up in the machine’s console output. Here’s my updated set of steps:
fly launch --remote-only – using the defaults. just to get the code built and image published
fly create machinetest – need an app for the machine to use
fly ips allocate-v4 -a machinetest – setup an ip4 address for the machine’s app
fly m run -p 3000:80/tcp:http -a machinetest registry.fly.io/<app image name from step 2>
At that point I have a machine listening on port 3000 (great) and an IP4 address for the machinetest app. curling that address however either gets me Connection refused or Connection reset errors depending if I use port 3000 or port 80 (respectively).
For the -p option, the CLI doc says it’s format is edgePort[:machinePort]/[protocol[:handler]]. Since the code is listening on 3000 should that be the machinePort? I tried using 3000:3000/tcp:http but that didn’t change anything.
Other suggestions? I did poke around in the branches as suggested but didn’t find anything particularly illuminating.
(interestingly and perhaps unrelated, fly m list shows an empty list even though I’m running the machine)
Hmmm, that’s not working either. I tried 80:3000 and curl http://109.105.217.117:80 as well as 3000:3000 and curl http://109.105.217.117:3000. Hitting 3000 always gets an immediate Connection refused. Going for port 80 thinks for a bit and then gives a Connection reset.
Does any part of the fly.toml play a role in the networking built into the image being run by the machine? In my step 2 (launch), I let it generate the config. That includes a bunch of services.ports and other networking settings. Could they be messing me up here?
