12

Context

We are trying to use edeliver to deploy a "Hot Upgrade" of a Phoenix Web Application to a remote Virtual Machine instance.

Our aim is to build an "upgrade" version of the app each time so that the app can be "hot" upgraded in production without any down-time.

We have succeeded in doing this "hot upgrade" on a "Hello World" phoenix app: https://github.com/nelsonic/hello_world_edeliver which is automatically deployed from Travis-CI when the build passes. see: https://travis-ci.org/nelsonic/hello_world_edeliver/builds/259965752#L1752

So, in theory this technique should work for our "real" app.

Attempting to Deploy a "Real" Phoenix App using Edeliver

Ran the following command (to build the upgrade):

mix edeliver build upgrade --auto-version=git-revision --from=$(git rev-parse HEAD~) --to=$(git rev-parse HEAD) --verbose

i.e. "build the upgrade from the previous git revision to the current one"

So far, so good. "Release successfully built!"

edeliver-upgrade-build-successful

Error: vm.args: No such file or directory

When we attempt to deploy the upgrade:

mix edeliver deploy upgrade to production --version=1.0.3+86d55eb --verbose

vm.args-no-such-file-or-directory

cat: /home/hladmin/healthlocker/releases/1.0.3+86d55eb/vm.args: No such file or directory

Note: we have a little bash script that reads the latest upgrade version available in .deliver/releases and deploys that see: version.sh

Question:

Is there a way to ignore the absence of the vm.args file and continue the deployment?

Or if the file is required to complete the deployment, is there some documentation on how to create the file?

Note: we have read the distillery "Runtime Configuration" docs: https://github.com/bitwalker/distillery/blob/master/docs/Runtime%20Configuration.md and are sadly none-the-wiser ...

Additional Info

Environment

This question was also asked on: https://github.com/edeliver/edeliver/issues/234

nelsonic
  • 31,111
  • 21
  • 89
  • 120
  • 1
    You got answer under the topic under github. – mico Aug 09 '17 at 12:18
  • 1
    vm.args is essential for the BEAM (The Erlang VM) to run for a release. It's generated by the exrm package when you run `mix release` and you should see it in the verbose logs as well - but not visible in your example, maybe due to the image cropping. Could you check if you see a line `==> Generating vm.args` in your output? – Máté Aug 10 '17 at 15:19
  • I believe you answer is in your question itself: "Note: we have a little bash script that reads the latest upgrade version available in .deliver/releases and deploys that see: version.sh". If the absence of the file can be causing an error, put a condition in your script in order to verify its existence. – Cleriston Aug 16 '17 at 07:30

1 Answers1

1

As mentioned by others, the vm.args file is necessary for BEAM to run the release. A default file is created by distillery during the release build process and should be located in releases/<version>/vm.args. From your log output it looks like expected directory is being checked.

  • Can you show us the contents of /home/hladmin/healthlocker/releases/?
  • Can you confirm that the default vm.args file is being created when building the release and extracting it (outside of the upgrade process)?

You also asked:

Or if the file is required to complete the deployment, is there some documentation on how to create the file?

If diagnosing the problem with the default vm.args file doesn't get you anywhere, you can also write your own file and configure distillery to use that file instead of the default. The details for this are in the distillery configuration docs. In short, add the vm_args setting to your distillery config, which should be at rel/config.exs(relative to your project root), for example:

environment :prod do
  set vm_args: "<path>/vm.args"
  [...]
end
Keyan P
  • 920
  • 12
  • 20