Unable to deploy non-Phoenix Elixir app

Questions / Help
1

Tried following the recommendation I found here: Is it OK to run non HTTP apps in Fly?

Removing the [[services]] section of my fly.toml didn’t do the trick, the deploy still gets stuck during my release command which is a app/bin/app_name start (mix release). I assume this is because the health checks fail.

Any help would be greatly appreciated.

2

I recently did this, what does your fly.toml config look like?

3

After removing the [[services]] section:

app = "app_name"

kill_signal = "SIGTERM"
kill_timeout = 5

[env]

[deploy]
  release_command = "/app/bin/app_name start"
4

Anything useful in the logs for your app (flyctl logs -a app_name)?

5

Just standard logs for the apps in the umbrella starting up. Last line:

13:03:44.591 [info] Application processor started on node 'dharma-qa@fdaa:0:30cf:a7b:ab8:9c46:e5cc:2'

6

There should be logs for your release command failure during deploy.

Looking at our internal logs infra, for a previously failed release, I see a log near the end like:

Crash dump is being written to: erl_crash.dump...done

For the latest release (I think), it looks like it’s never ending. Spamming logs like:

13:42:58.299 [error] Error in fetch_changes with the
             following reason: connection refused
7

Yeah it does look like there were some errors but only quite some time after the deploy.
What is considered a successful release command with a non-Phoenix app? There are no health checks to a port, so surely it should just be the apps starting up?

8

Oh sorry, I just looked at your fly.toml and I don’t think it’s doing what you think it should :slight_smile:

deploy.release_command is a command that runs before actually deploying your new app version. These are meant to be short-lived. Usually migrations.

I assume you explicitly set a command there because your Dockerfile has a different one?

You can do:

[experimental]
cmd = ["/app/bin/app_name", "start"]
9

Ohhh okay that makes more sense!
So the deploy.release_command is for release tasks.
If I already have the command I want being set in my Dockerfile I don’t need to set anything?
And if I don’t have the command set in the Dockerfile I can then use the experimental.cmd?

1 Like
10

If you have the right CMD already in your Dockerfile, you don’t have to set anything.

If not, you do need the experimental.cmd to override whatever if set (if any) as the CMD in your Dockerfile.

11

Makes sense. Thank you!

1 Like