How to create machines from a toml file without doing a deploy/build?

Questions / Help
,
1

I have a toml file with all the configuration for my app machines.

I have the app created running fly apps create --name app_name --org org_name but I can’t figure out how to create the app machine(s) without triggering building my backend and/or deploying.

Technically I think I should be able to do that with fly machine create, but when I use it to create, it doesn’t seem to read the machine config from my toml file, it creates a machine with the default values.

The only way I found to make this work is to do a real deploy, but I do not want to do that at the time, just create the machines

2

fly machines create/run are more lower-level ways of creating machines that require more in detail knowledge of http://api.machines.dev/ to get going indeed.

Our CLI handles our PaaS around fly deploy (including some commands such as fly scale ... and fly secrets set too).

My question to be able to help further is: why deploying is an issue? I think I could help more if I know what’s the real caveat and what you’re trying to achieve here. What’s you current state and what’s your end state goal?

But one quick tip I can give is to clone an existing machine and change what needs to be changed:

❯ fly m clone --help
Clone a Fly Machine. The new Machine will be a copy of the specified Machine. If the original Machine has a volume,
then a new empty volume will be created and attached to the new Machine.

Usage:
  fly machine clone [machine_id] [flags]

Flags:
  -a, --app string                    Application name
      --attach-volume string          Existing volume to attach to the new Machine in the form of
                                      <volume_id>[:/path/inside/machine]
      --clear-auto-destroy            Disable auto destroy setting on the new Machine
      --clear-cmd                     Set empty CMD on the new Machine so it uses default CMD for the image
  -c, --config string                 Path to application configuration file
      --detach                        Return immediately instead of monitoring deployment progress
      --from-snapshot string          Clone attached volumes and restore from snapshot, use 'last' for most
                                      recent snapshot. The default is an empty volume.
  -h, --help                          help for clone
      --host-dedication-id string     The dedication id of the reserved hosts for your organization (if any)
      --name string                   Optional name for the new Machine
      --override-cmd string           Set CMD on the new Machine to this value
  -r, --region string                 The target region (see 'flyctl platform regions')
      --standby-for strings           Comma separated list of Machine IDs to watch for. You can use
                                      '--standby-for=source' to create a standby for the cloned Machine.
      --vm-cpu-kind string            The kind of CPU to use ('shared' or 'performance')
      --vm-cpus int                   Number of CPUs
      --vm-gpu-kind string            If set, the GPU model to attach (a100-pcie-40gb, a100-sxm4-80gb, l40s, a10,
                                      none)
      --vm-gpus int                   Number of GPUs. Must also choose the GPU model with --vm-gpu-kind flag
      --vm-memory string              Memory (in megabytes) to attribute to the VM
      --vm-size string                The VM size to set machines to. See "fly platform vm-sizes" for valid values
      --volume-requires-unique-zone   Require volume to be placed in separate hardware zone from existing
                                      volumes. Default true. (default true)

Global Flags:
  -t, --access-token string   Fly API Access Token
      --debug                 Print additional logs and traces
      --verbose               Verbose output

You could use one of the flags to overwrite existing configs or pass --config to a path of a newly written config.

To get an existing machine config you can LOG_LEVEL=debug fly m status MACHINE_ID and that will output the config.

3

The main reason is because I’m creating a script for my dev team to use to setup new environments on-demand, I would prefer to make the script setup everything (in this case, the machines creation too) when it is run, but I don’t want to add a deploy call to it since that means that the script can fail if the dev local code fails to compile.

The second reason is that I want to only have one machine created in the app, but when I run the first deploy, for some reason it always create 2, so I need to run fly scale count 1 afterwards. Since that command only works after the machines are created, then I can’t run it before a deploy and I have to rely on the dev remembering to call it.

4

If compilation is an issue you could do a fly deploy --build-only to check if it compiles and later fly deploy ... to actually deploy it. Would that work for your case?

That’s for high availability, you can disable by fly deploy --ha=false. In case you’re using it, so does fly launch --ha=false also works.

1 Like
5

Is it possible to set the ha field in the toml file to be declarative?

6

I looked at App configuration (fly.toml) · Fly Docs and flyctl and ha seems to be only a flag so you’d need to put it on your script instead

7

Ah, got it.

Thanks for the tip, the ha flag works great and solves my issue :slight_smile:

1 Like