I’m looking for a way to set the node’s longname dynamically at startup. The use case is AWS, where one can grab the IP from the local instance metadata. I have tried the following:
First attempt:
a) Create a custom command
b) grab ip with curl in command, export as NODE_IP
c) exec “myapp.sh foreground” (NODE_IP is in the environment)
This fails because ${NODE_IP} in vm.args is already wiped by the first command run before the exec
Second attempt:
a) do not set -name in vm.args
b) at app startup, query metadata and use Node.start()
This fails with vm.args needs to have either -name or -sname parameter because myapp.sh is doing a check for this. Why? It doesnt seem like it’s absolutely required…
My next idea is to use a custom command but not call it using myapp.sh. This feels a bit dirty but I think I can move forward with it.
Another alternative might be to to use a pre_configuration script, but that hook looks to be called after configuration and definitely after the call to _replace_os_vars.
Thoughts? Has anyone accomplished this with distillery yet?
What I’ve done for this is create a small wrapper script around bin/myapp which does whatever is needed to set up the environment, and then runs exec bin/myapp "$@". In my case I was deploying via Docker so I could choose where to dump that script - if deploying via other means, you will have to handle deployment of your shim outside of Distillery, but that’s usually a trivial problem to solve.
Ok, I will do this for now. Is there any reason not to have a hook for before_env_var_replacement and/or defer setting up the node networking (not requiring it in vm.args)?
The distribution configuration is required in order to manage the node, so deferring it to after boot is explicitly a non-goal at this time. Since one can execute code prior to boot, it’s trivial to execute arbitrary programs to do the heavy lifting to get that configuration in place anyway. That said, I recognize that currently Distillery has a gap here.
As for why Distillery doesn’t have a hook early in the boot process for this - it does have pre_configure, but that is executed after vm.args is injected with env vars, and that’s done because I’ve always felt that the base configuration needed to be in place before handing anything off to user scripts. In general it’s expected that required env vars for replacement are set before the release is booted - that said, clearly even I have needed to handle things earlier in the process, so I may change things such that pre_configure occurs before env var replacement - it’s technically a breaking change, but since it occurs very early in process, there is very little you can actually do anyway, and it was really intended for this kind of thing - I probably should provide an option to enable that behaviour and go through a deprecation cycle. I haven’t done that yet since it was trivial to work around in my case, so you could chalk it up to laziness .
Could you open an issue on the Distillery tracker? I’ll add it to my TODO for the next release.
.
