Hello all,
How can I run a phoenix server in background of my droplet ( or just say the os).
I am looking for some process manager like pm2 is there for nodejs.
Thanks.
The approach people often take is to build a release with something like https://github.com/bitwalker/distillery and run bin/your_app start.
2 Likes
see this article series A Beginner's Guide To Deployment with Edeliver and Distillery - in part 2 systemd is setup…
1 Like
Are you thinking at --detached?
MIX_ENV=prod PORT=80 elixir --detached -S mix phoenix.server
This thread needs an update, since 1.9 negates the need for Distillery and Edeliver (yay), but I’m still a little confused as to how to run my app as a daemon. Running mix release.init generates these bash scripts in a .eex file (???) and then the documentation seems to say “you’re all set” when I really have no idea what this is suppose to do.
So this documentation: https://hexdocs.pm/mix/Mix.Tasks.Release.html#module-vm-args-and-env-sh-env-bat refers to both the .eex file and the non-.eex file. Does one translate to another? How? Running mix release will read the .eex file and compile a regular bash script in the build which you can just run and then your daemon is running in the background?
Does this approach negate the previous answer of using systemd services? Are those not necessary anymore?
Even this documentation https://elixir-lang.org/getting-started/mix-otp/config-and-releases.html#operating-system-environment-configuration seems to just say “uncomment the lines and you’re set”. What?? Uncomment the lines, run the build on my host server, and my app will magically be running as a daemon?
Can anyone clarify what’s going on here?
mix release.init just prepares your project to be “released”. You run this one once. AFAIK the out of the box defaults for the rel/* files just created are fine, and just need to be tweaked if you’re building a cluster or know what you’re doing. In my production app only rel/vm.args.eex has been changed to set some specific BEAM configuration options.
Then mix release creates the actual release ready to be executed. It does not negate the use of systemd, in fact you will have to create a systemd unit file that starts and stops the final release: these days it’s much better to have an app that does not daemonise but writes to stdout and stderr, and delegate the daemonising/monitoring to appropriate tools such as systemd or Docker or Kubernetes.
I don’t have any specific details on how to run Elixir on systemd, since I’m running it in a Docker container but the logic is the same:
RUN mix release --path /app # This builds the release under /app
[...]
CMD /app/bin/my_application start # Start the application in foreground
The Releases documentation can be confusing because it’s very in-depth, but if you play with it you’ll see it’s quite easy to use.
Considering i’m not doing either, do I need to run mix release.init then? I would have thought that this command would have generated the systemd unit file that I would need to run. I’ve never created a systemd unit file but from what I gather I can use something like this GitHub - cogini/mix_systemd: Library of mix tasks to generate a systemd unit file for an Elixir project
Either way, I’m not really sure what the point of mix release.init is if I’m not creating my own cluster.
