Retrieve mounted volume ID within instance.

Is there a way to retrieve a mounted volume ID from a running instance?

I’d like to use the volume ID in my distributed application in order to route queries across a cluster of instances.

Also, I assume that once created a volume ID never changes afterwards. Is it right?

There’s no way to retrieve the volume ID directly, but you can use the VM hostname instead. The hostname will always be the same for a VM on a given volume.

The ID, hostname, and private IPv6 address do not change. In the future we might end up migrating volumes, around, however, which could end up looking like an old volume going away and a new snapshot being restored with a new volume ID.

It might be worth writing a permanent ID out to your volume if you need to uniquely identify the set of data it owns. Then you can rely on that even if we end up migrating volumes.

There’s no way to retrieve the volume ID directly, but you can use the VM hostname instead. The hostname will always be the same for a VM on a given volume.

I’ve was under the impression that I got a new hostname (and instance ID) each time I redeploy my app. We’re talking about the internal hostname (067ff9bc, 0fe6a382, 1a41a3d3, etc.), not the DNS right?

It might be worth writing a permanent ID out to your volume if you need to uniquely identify the set of data it owns. Then you can rely on that even if we end up migrating volumes.

This seems like a very good solution I did not think about :face_with_hand_over_mouth:. It’s also a much more generic way to solve my problem than relying on specific hosting infrastructure attributes. :+1:

1 Like

Yes, but it’s confusing. fly status will show different instance IDs between deploys, but if you ssh in and run hostname or hostname -f you’ll see that those don’t change.

I just redeployed my app with a new Docker image.

2021-09-14T22:37:00.522577370Z runner[067ff9bc] fra [info] Shutting down virtual machine
2021-09-14T22:37:00.624672037Z app[067ff9bc] fra [info] Sending signal SIGTERM to main child process w/ PID 519
2021-09-14T22:37:00.626439341Z app[067ff9bc] fra [info] 22:37:00.625 [info] SIGTERM received - shutting down
2021-09-14T22:37:09.369093543Z runner[bd84478c] fra [info] Starting instance
2021-09-14T22:37:09.412662914Z runner[bd84478c] fra [info] Configuring virtual machine
2021-09-14T22:37:09.415372784Z runner[bd84478c] fra [info] Pulling container image
2021-09-14T22:37:14.294700728Z runner[bd84478c] fra [info] Unpacking image
2021-09-14T22:37:17.982609297Z runner[bd84478c] fra [info] Preparing kernel init
2021-09-14T22:37:18.151810179Z runner[bd84478c] fra [info] Setting up volume 'git_limo_data'
2021-09-14T22:37:18.399387314Z runner[bd84478c] fra [info] Configuring firecracker
2021-09-14T22:37:18.501157032Z runner[bd84478c] fra [info] Starting virtual machine
2021-09-14T22:37:18.717261271Z app[bd84478c] fra [info] Starting init (commit: 9445492)...
2021-09-14T22:37:18.738031646Z app[bd84478c] fra [info] Mounting /dev/vdc at /data
2021-09-14T22:37:19.138086964Z app[bd84478c] fra [info] Running: `./entrypoint.sh bin/git_limo start` as root
2021-09-14T22:37:19.151626374Z app[bd84478c] fra [info] 2021/09/14 22:37:19 listening on [fdaa:0:24ce:a7b:66:0:1ca0:2]:22 (DNS: [fdaa::3]:53)
2021-09-14T22:37:20.147268774Z app[bd84478c] fra [info] Reaped child process with pid: 575 and signal: SIGUSR1, core dumped? false
2021-09-14T22:37:21.215543669Z app[bd84478c] fra [info] 22:37:21.211 [info] Migrations already up
2021-09-14T22:37:22.151592917Z app[bd84478c] fra [info] Reaped child process with pid: 577 and signal: SIGUSR1, core dumped? false
2021-09-14T22:37:22.152167805Z app[bd84478c] fra [info] Reaped child process with pid: 610, exit code: 0
2021-09-14T22:37:24.963827518Z app[bd84478c] fra [info] 22:37:24.962 [info] Running GitGud.Web.Endpoint with cowboy 2.9.0 at :::4000 (http)
2021-09-14T22:37:24.966244219Z app[bd84478c] fra [info] 22:37:24.965 [info] Access GitGud.Web.Endpoint at https://git.limo
2021-09-14T22:37:25.156942922Z app[bd84478c] fra [info] Reaped child process with pid: 631 and signal: SIGUSR1, core dumped? false
2021-09-14T22:37:25.157693829Z app[bd84478c] fra [info] Reaped child process with pid: 636, exit code: 0
2021-09-14T22:37:28.666198054Z app[bd84478c] fra [info] 22:37:28.662 [info] tzdata release in place is from a file last modified Tue, 22 Dec 2020 23:35:21 GMT. Release file on server was last modified Sun, 24 Jan 2021 19:35:23 GMT.
2021-09-14T22:37:30.084422200Z app[bd84478c] fra [info] 22:37:30.082 [info] Tzdata has updated the release from 2020e to 2021a
2021-09-14T22:37:40.025404231Z proxy[bd84478c] fra [info] Health check status changed 'critical' => 'passing'
2021-09-14T22:37:54.033709584Z app[bd84478c] fra [info] 22:37:54.032 request_id=FqTRSG5AesRENsUAAAHB [info] GET /
2021-09-14T22:37:54.049074268Z app[bd84478c] fra [info] 22:37:54.047 request_id=FqTRSG5AesRENsUAAAHB [info] Sent 200 in 14ms

Running hostname via SSH console got me 067ff9bc before redeployment and bd84478c afterward.

Also I monitor my app with AppSignal.com and basically see a new host on each deployment there too.

This app has a [mount] section in the config? The host names and IPs “stick” when there’s a volume mounted, but don’t otherwise. I didn’t really clarify that before. :slight_smile:

Yes, the app has a [mounts]section in the fly.toml config:

[env]
  GIT_ROOT = "/data/git"
  SSH_HOST_KEY_DIR = "/app/ssh-keys"

[experimental]
  auto_rollback = true

[mounts]
  source="git_limo_data"
  destination="/data"

Just wanted to ask again. My app has a mounts section and a volume assigned.

$ fly vol list
ID                   NAME          SIZE  REGION ATTACHED VM CREATED AT   
vol_02gk9vwqk1v76wm8 git_limo_data 100GB fra    57c4ad39    4 months ago 

Each time I run flyctl deploy I get a new hostname on the instance. This does not happen with flyctl restart.

The host names and IPs “stick” when there’s a volume mounted, but don’t otherwise.

So my app in fra should alway have the same IP and hostname when configured with a volume right? Also across redeploys?

I wonder if I was misremembering something. Does fly ips private stay the same? It turns out, I was extracting an “id” from the private 6pn address for Consul: https://github.com/fly-apps/consul/blob/main/start_consul.sh#L3-L4

Nope, private IP stay the same:

$ fly ips private
ID       REGION IP                          
57c4ad39 fra    fdaa:0:24ce:a7b:66:0:1ca0:2 

after redeploy

$ fly ips private
ID       REGION IP
d2776255 fra    fdaa:0:24ce:a7b:66:0:1ca0:2

Ok then I am either wrong about the hostname or we haven’t shipped that feature yet, sorry about that. :slight_smile:

1 Like