`mix release` node name not being set | Elixir Language | Page 1

crimson rune Feb 21, 2025, 11:27 PM

#

hi! i've been trying to transition my phoenix setup from the development iex -S mix phx.server to doing something involving mix release. here's my actual dev command:

HTTPS_PORT="$HTTPS_PORT" iex --erl "-kernel inet_dist_listen_min 9100 inet_dist_listen_max 9105" --name "$NODE_NAME" --cookie "$COOKIE" -S mix phx.server

here's my attempt at turning this into some mix release thing:

MIX_ENV=prod mix release --overwrite && \
  RELEASE_DISTRIBUTION=name RELEASE_NODE="$NODE_NAME" ERL_COOKIE="$COOKIE" ELIXIR_ERL_OPTIONS="-kernel inet_dist_listen_min 9100 inet_dist_listen_max 9105" HTTPS_PORT="$HTTPS_PORT" _build/prod/rel/my_app/bin/my_app start_iex

i'm glad that the HTTPS_PORT is being passed in correctly, but it's not setting the node name -- it's defaulting to my_app@my_hostname instead of the passed-in $NODE_NAME which is [email protected]. i ran System.get_env() and RELEASE_NODE is indeed my_app@my_hostname not [email protected]. i'm aware i can set something in the build artifact to change the env variables but I don't want to do that every time i run mix release --overwrite.

how do i bake in my desired RELEASE_NODE with running mix release --overwrite? i've tried exporting all the env variables before running mix release --overwrite but that didn't seem to do it:

run_release () {
  export RELEASE_DISTRIBUTION=name
  export RELEASE_NODE="$NODE_NAME"
  export ERL_COOKIE="$COOKIE"
  export ELIXIR_ERL_OPTIONS="-kernel inet_dist_listen_min 9100 inet_dist_listen_max 9105"
  export MIX_ENV=prod
  mix release --overwrite && \
  HTTPS_PORT="$HTTPS_PORT" _build/prod/rel/my_app/bin/my_app start_iex
}

woven iris Feb 21, 2025, 11:32 PM

#

did you ever run mix release.init?

crimson rune Feb 21, 2025, 11:32 PM

#

nope! should i do that?

woven iris Feb 21, 2025, 11:33 PM

#

it creates some useful files, I think that might shed some light on the issue

#

I'm not 100% sure if it'll help though

#

see this section: https://hexdocs.pm/elixir/config-and-releases.html#configuring-releases
and specifically about rel/env.sh.eex and rel/vm.args.eex

crimson rune Feb 21, 2025, 11:35 PM

#

i see -- it looks like it created some config files that are used by every release

#

i guess i have an issue with this -- the reason i want to pass it in is because i want to run multiple instances of the phoenix server, each with a different node name

woven iris Feb 21, 2025, 11:36 PM

#

yeah, so if you don't modify those, I think it uses some default ones internally. mix release.init generates the default ones for you and let's you modify them however you need, for example, you don't need to specify those erl options every time, you can bake them into your vm.args.eex (I think)

crimson rune Feb 21, 2025, 11:36 PM

#

thanks for the pointers :)

woven iris Feb 21, 2025, 11:37 PM

#

well, yes, this is set up to run multiple nodes

#

i'm not totally sure why your RELEASE_NODE env var wasn't being honored

crimson rune Feb 21, 2025, 11:37 PM

#

wait it is? do i get to specify the node names at least

#

maybe i am running an old version of elixir :( i don't remember when i updated but it was several months ago

#

i am running 1.18.2

woven iris Feb 21, 2025, 11:38 PM

#

do you specifically want to run multiple instances on the same machine?

crimson rune Feb 21, 2025, 11:38 PM

#

yeah -- just two instances, and they should also be able to send messages to each other

#

one called blue and one called green

woven iris Feb 21, 2025, 11:40 PM

#

running them on the same machine isn't really a good idea, the BEAM is set up to take all the resources on the machine, i.e. it's CPU scheduler is a fair scheduler on all CPU cores, but if you have two BEAM instances on the same machine, they'll compete

crimson rune Feb 21, 2025, 11:40 PM

#

ah, i see. well the idea is to do an easy blue/green deployment -- if i spin up a second instance it will send a message to the existing instance and pull all state, and then kill the existing instance

#

so there should normally be one instance running at a time, sorry i was unclear about this ><

#

this all works with the dev setup with iex -S mix phx.server -- just the release stuff is being troublesome haha

woven iris Feb 21, 2025, 11:42 PM

#

yeah, it's just that in "real world prod" setups this should be on two different machines

#

for example, at work we run a 3-node cluster and do rolling deployes, so there are always 2 nodes running at any given time

#

and we use AWS load balancers to route the traffic to the live nodes

crimson rune Feb 21, 2025, 11:42 PM

#

that's how it was set up yesterday, actually! but the load balancer free tier on OCI is very low on bandwidth while the machines themselves are high bandwidth, so we're going back to one machine

woven iris Feb 21, 2025, 11:42 PM

#

and because each instance is on its own machine it's node name is just app_name@<private-ip>

crimson rune Feb 21, 2025, 11:43 PM

#

yeah :') i am definitely not doing best practices by switching away from the standard 2 node load balancer setup

#

another upside of one machine is that you don't have to pay for running two instances haha

#

thanks for the mix release.init tip i will see if i can configure 2 identical release setups whose only difference is RELEASE_NODE, and see if that works

woven iris Feb 21, 2025, 11:45 PM

#

yeah, give it a try, sorry I'm not super sure about all the nuances of the configs and env vars

crimson rune Feb 21, 2025, 11:46 PM

#

no worries i'll report back, thank you for the help!

crimson rune Feb 22, 2025, 12:08 AM

#

ugh

#

you know what worked? rm -r _build/prod and building again 😭

woven iris Feb 22, 2025, 12:08 AM

#

lol

#

the worst

#`mix release` node name not being set