An app with volumes doesn't deploy properly

So, I’ve given up waiting for a response on this botched v2 migration and tried to re-create everything from scratch, and it still doesn’t work :-/

This is a complete log of what I’ve done. Deploying an app with an attached volume works, but scaling it down and up fails, and the volume can’t be deleted.

This is my fly.toml:

app = "pacman-ghost-gitea2"
kill_signal = "SIGINT"
kill_timeout = 30
processes = []

  image = "gitea/gitea:1.17.2"

  # IMPORTANT: This configures sshd inside the container to listen on a different port (since uses port 22
  # for itself outside the VM, and configuring a service for it on another port exposes it to the internet).
  # Gitea in a container doesn't honor this setting in app.ini :-/
  # When the container starts, it generates /etc/ssh/sshd_config from a template:
  # which gets the port number from this environment variable. Sigh...
  SSH_LISTEN_PORT = "3022"

  allowed_public_ports = []
  auto_rollback = true

  http_checks = []
  internal_port = 3000
  protocol = "tcp"
  script_checks = []

    hard_limit = 25
    soft_limit = 20
    type = "connections"

    grace_period = "1s"
    interval = "15s"
    restart_limit = 0
    timeout = "2s"

  internal_port = 3022
  protocol = "tcp"

  # NOTE: Removed a health check here.

  source = "pacman_ghost_gitea2_data"
  destination = "/data"

There used to be a health check for the SSH port, but I took that out, in case Fly was getting confused because the machine wasn’t coming up properly, but the same thing happens.

Something is deeply screwed with volumes.

hi @pacman-ghost

There are a few differences in configuration and command options between V1 and V2 apps.

First, make sure flyctl is up to date: fly version update.

The fly regions set command doesn’t work for V2 apps, so the next thing to do is to add primary_region = "sin" to the top of your fly.toml file:

app = "pacman-ghost-gitea2"
kill_signal = "SIGINT"
kill_timeout = 30
primary_region = "sin"

After updating the fly.toml file with the primary region, try running fly deploy -r sin. (edit to add that on future deploys, you shouldn’t need the -r option, this is just to make sure the current issues get fixed.)

Other notes:
You don’t need to delete your volume if the deploy works, but for next time: to delete a volume you need to use the volume ID (starts with vol-) instead of the volume name: fly volumes destroy <volume ID>.

When you use fly scale count 0 and then fly scale count 1, it should pick up the volume you already created, not create a new one.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.