fly machine API entrypoint config

#1

Is it possible to pass the docker entrypoint configuration string with the fly machines API?

I attempted to include it under either config or config.init and get a 400 Bad Request response. (Using the equivalent entrypoint config worked for me when using the CLI’s --entrypoint parameter)

curl -i -X POST \
-H "Authorization: Bearer ${FLY_API_TOKEN}" -H "Content-Type: application/json" \
"http://${FLY_API_HOSTNAME}/v1/apps/APP/machines" \
-d '{
  "name": "TEST_NAME",
  "region": "ewr",
  "config": {
    "image": "registry.fly.io/MY_APP",
    # Tried:
    "entrypoint": "docker-entrypoint.sh SOME PARAMS",
    # Also tried:
    "init": {"entrypoint": "docker-entrypoint.sh SOME PARAMS"}
    ]
  }
}'
#2

Per fly machine docs (which may be incorrect), you cannot override entrypoint and cmd via config (at deploy-time). You’d have to define those in your dockerfile (at build-time).

config : An object defining the machine configuration.

Options

  • image : The Docker image to run
  • guest : An object with the following options:
  • cpus : Number of vCPUs (default 1)
  • memory_mb : Memory in megabytes as multiples of 256 (default 256)
  • env : An object filled with key/value pairs to be set as environment variables
  • services : An array of objects that define a single network service. Check the machines networking section for more information.
  • protocol : tcp or udp.
  • internal_port : Port the machine VM listens on
  • ports : An array of objects defining the service’s ports and associated handlers. Options:
    • port : Public-facing port number
    • handlers : Array of connection handlers for TCP-based services.
#3

Thanks, I did notice it was not in the docs but figured I’d ask just in case it was unintentionally missing or planned since (1) the POST /machines API’s 200 machine creation response includes an init section with an empty entrypoint property and (2) the CLI supports the entrypoint approach nicely well. I’d just use the CLI but there’s a separate issue in the context I’m trying to make this work from (essentially an API running a read-only bash context - works for starting the proxy but not running machine commands)

Purpose-wise, I’m attempting to use entrypoint/CLI arguments in place of env vars for configuration of the running binary - I could instead adapt the Dockerfile to make those bits configurable with env vars instead, just adds a bit of a delta between running on machines and our existing provider so raises the bar to continue experimenting with it with our existing workflow a bit.

1 Like