Volume data gone on deploy

Questions / Help
1

Hi, I’ve migrated a notetool application running locally to run on fly.io. Since the application writes plain text files in a /data/ folder, I created a volume and attached it to the app. This works fine. However, when I redeploy the application, it wipes out all data.

  • I have made sure there is only one volume attached to the app. There was one volume earlier that I deleted while playing around, but it doesn’t show up in fly vol list.
  • The notetool used to check in data to a Git repository. I’ve since added the data folder to my .gitignore and .dockerignore. It does not seem to make a difference if I include the data folder itself or not (I don’t think it’s a good idea to deploy a stale copy of the data!).
  • Deploys are successful every single time, no errors or warnings out of the ordinary.

Similar problems are

Hope someone can help! I have an archival and restore function in the tool, so I can work around the issue in the meantime, but it does suck a bit. What if I forget?

2

Did you mount it? See: Fly Volumes overview · Fly Docs

If you run fly ssh console -C df you should see something like:

/dev/vdb         3026704   12528   2840712   1% /data
3

Thanks for the quick response!
The volume is mounted in fly.toml, which I’ve included below.

The volume does show up using the command you posted, so apparently it’s not getting linked to the application somehow? I’m reading and writing to the relative path ‘./data/’ in my application, maybe I’ve misunderstood the docs as to how that works?

[rik@rik notetool]$ fly ssh console -C df
Update available 0.0.433 -> v0.0.435.
Run "flyctl version update" to upgrade.
Connecting to fdaa:0:e475:a7b:23c5:2:fddc:2... complete
Filesystem     1K-blocks   Used Available Use% Mounted on
devtmpfs          109964      0    109964   0% /dev
/dev/vdb         8191416 389700   7365904   6% /
shm               113224      0    113224   0% /dev/shm
tmpfs             113224      0    113224   0% /sys/fs/cgroup
/dev/vdc         1011672   2564    940500   1% /data

Full fly.toml:

# fly.toml file generated for notetool on 2022-11-20T18:16:56+01:00

app = "notetool"
kill_signal = "SIGINT"
kill_timeout = 5
processes = []

[build]
  builder = "paketobuildpacks/builder:base"

[env]
  PORT = "8080"

[experimental]
  allowed_public_ports = []
  auto_rollback = true

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

[[services]]
  http_checks = []
  internal_port = 8080
  processes = ["app"]
  protocol = "tcp"
  script_checks = []
  [services.concurrency]
    hard_limit = 25
    soft_limit = 20
    type = "connections"

  [[services.ports]]
    force_https = true
    handlers = ["http"]
    port = 80

  [[services.ports]]
    handlers = ["tls", "http"]
    port = 443

  [[services.tcp_checks]]
    grace_period = "1s"
    interval = "15s"
    restart_limit = 0
    timeout = "2s"
4

You are going to either need to read and write to the absolute path /data or change the mount point in your fly.toml to match whatever ./data/ resolves to in your application; typically whatever is specified as WORKDIR in your Dockerfile followed by /data. In my app that would be /app/data.

5

I don’t have a Dockerfile because it’s a Python application so I just followed the quickstart. I changed the mount point to be /workspace/data, which is what the folder you were referring to is.

Then it started giving me permission errors, which I found here Can't create Sqlite database in mounted volume - #2 by sudhir.j
As stated in the thread, I first ran ls -la workspace/data to see who owned what, and I noticed that a subdirectory was owned by root instead of cnb. Running chown -R cnb:cnb workspace/data fixed that issue.

Then I had some issues with relative paths and zipfiles, but that was a straightforward fix in Python (by specifying arcname to ZipFile.write).

Thanks a lot for the help!

1 Like