Hey, hope any one more experienced with Distillery can shed some light on this issue.
So I have read through quite a bit of disparate sources on how to access env variables when deploying through Distillery. What I ended up doing was to create a prod.secret.exs the deployment user folder. This works - I’ve used interpolated values with “${…}” on my ~/.profile I have:
export REPLACE_OS_VARS=true
On /.deliver/config I have the following hook pointing to the prod.secret.exs on the server. pre_erlang_get_and_update_deps()
And I also uncommented the load profile line on the clean_compile hook.
pre_erlang_clean_compile() {
status "Running phoenix.digest" # log output prepended with '---->'
__sync_remote " # runs the commands on the build host
-f ~/.profile ] && source ~/.profile # load profile (optional)
source ~/.profile
...
}
This is for the compilation and is working as expected. Whenever I build and release, or upgrade and release the correct ENV variables are fetched from the ENV, and used in the interpolation in prod.secret.exs
But, whenever I restart through edeliver, or if I reboot the server, no longer are they used.
If I open~/app/var/sys.config the correct values appear on the erlang config.
If I go to a release where I restart the server and open sys.config (e.g. ~/app/releases/0.0.11/sys.config), those values are not interpolated, whereas if I check on a release that wasn’t rebooted they are.
What else am I missing about it in order to have them correctly populated on reboot? Or do I need a different setup altogether to have this working, like fetching from env and setting them on runtime? If so anyone knows a good place to check an example of how to hook that up before app start?
And there’s this part of setting up systemd restarts of the app - which are working because if I edeliver stop the server is restarted again without needing edeliver start.
Might it be something about this?
[Unit]
Description=Phoenix server for DeployPhoenix app
After=network.target
[Service]
User=deploy
Group=deploy
Restart=on-failure
Environment=HOME=/home/deploy/deploy_phoenix
ExecStart= /home/deploy/deploy_phoenix/bin/deploy_phoenix foreground
ExecStop= /home/deploy/deploy_phoenix/bin/deploy_phoenix stop
[Install]
WantedBy=multi-user.target
But it shouldn’t be right, since it’s using the same deploy user it should load the .profile?
That path would never have config values modified - they would always be the original uninterpolated config values. The only modifications are written to ~/app/var/sys.config, and this happens every time the release is started.
My assumption is that the ~/.profile is not being loaded - I thought profiles were only loaded in interactive shells, but perhaps edeliver tries to execute remote commands such that profiles are loaded? My recommendation would be to provide ENV variables via some other method than ~/.profile. IIRC, edeliver provides some method for doing that (either a config setting, or an env file of some sort).
On the Distillery side, the behaviour you want is how it works, so this is definitely an issue at a higher level (either edeliver or the method you are using to set REPLACE_OS_VARS)
Hey, thanks for the work you’ve put into distillery and docs! And thanks for the clarification - I probably checked a release where I hardcoded the values on prod.secret.exs and that’s why I saw them on the release sys.config - from a security point of view is it troublesome to have those credentials live on the deployment server under prod.secret.exs? I guess it’s the same right? If someone has access to that file they’ll also have access to the ENV…
Thanks
ps- REPLACE_OS_VARS is being set on the same .profile file
I am personally not a big fan of prod.secret.exs because I find that it is generally better if a production system can be configured with environment variables following the Twelve-Factor App principles.
You could debug whether your .profile is run by simply logging the result of System.get_env/0 and verifying that all your required variables (including REPLACE_OS_VARS) are set.
