Loading...

Expose RAILWAY_REPLICA_PRIVATE_IP variable

6 months ago

Please provide a RAILWAY_REPLICA_PRIVATE_IP variable that is only exposed at runtime (not in the dashboard) to make it easier for Elixir developers to cluster their applications across replicas. Developers could then set up clustering by creating a rel/env.sh.eex with the following contents:

#!/bin/sh

export DNS_CLUSTER_QUERY=$RAILWAY_PRIVATE_DOMAIN
export RELEASE_DISTRIBUTION=name
export RELEASE_NODE="$RAILWAY_SERVICE_NAME@$RAILWAY_REPLICA_PRIVATE_IP"
export ERL_AFLAGS="-proto_dist inet6_tcp"

For developers looking to get clustering working today, you can emulate it with

RAILWAY_REPLICA_PRIVATE_IP=$(hostname -I | tr -s " " "\012" | grep ":")

Under Review

0 Threads mention this feature

4 Replies

brody

EMPLOYEE

6 months ago

Hello,

Unfortunately, it would not be possible to have a RAILWAY_PRIVATE_IP exposed to the dashboard since its value will change every deployment, similarly to how the GitHub hash is not something you can use on the dashboard, and there are far more nuanced issues with this too, for example when a service has multiple replicas, there is no longer one single IP for the service, but instead an IP for each replica.

fugitech

PROOP

6 months ago

it would not be possible to have a RAILWAY_PRIVATE_IP exposed to the dashboard since its value will change every deployment, similarly to how the GitHub hash is not something you can use on the dashboard

It would be a meaningful improvement even if it wasn't usable in the dashboard, though I guess I would then file a second piece of feedback that it'd be useful to allow defining runtime env variables even if their value isn't known. For clustering I just need RELEASE_NODE set correctly right before the server is launched, I don't really care to see the value in the dashboard. I would prefer to be able to set that configuration easily in the dashboard rather than in a custom script.

there are far more nuanced issues with this too, for example when a service has multiple replicas, there is no longer one single IP for the service, but instead an IP for each replica

this does not strike me as a problem, I would want it set to the value of the private IP of the current replica. Maybe RAILWAY_REPLICA_PRIVATE_IP would be a more explicit name? There is already RAILWAY_REPLICA_ID so there is prior art of replica-specific variables.

brody

EMPLOYEE

6 months ago

Gotcha, thank you for explaining.

Could you perhaps update your post message to reflect what would be feasible for us to do?

AKA just the simple per replica RAILWAY_REPLICA_PRIVATE_IP variable that would only be exposed at runtime.

brody

Gotcha, thank you for explaining.Could you perhaps update your post message to reflect what would be feasible for us to do?AKA just the simple per replica RAILWAY_REPLICA_PRIVATE_IP variable that would only be exposed at runtime.

fugitech

PROOP

6 months ago

done