search

groovenauts / capistrano-systemd-multiservice

Capistrano Plugin to control services with systemd
MIT License
45 stars 17 forks source link

Best strategy for environment variables #24

Closed gencer closed 3 years ago

gencer commented 3 years ago

Hi,

I was using foreman and switched to capistrano-systemd-multiservice which gives me more fine-control over my configuration files, however, one thing bothers me when I work with environments.

With foreman we simply have .env file (dotenv) and when we export to systemd, this file read then added to the systemd config file. However, with this plugin I see they are hardcoded. As you might know, ENV params may contains sensitive data, therefore, I would like to keep them out of my git repository.

What is the best strategy to reflect my .env file that resides in production server only when I export to systemd? Is it already implemented? Because, I just couldn't see it. If not what can we do about it?

P.S.: One thing that came to my mind is to use ERB-style syntax and read .env file in config file but I would like to know your thoughts first.

Thanks, Gencer.

gencer commented 3 years ago

Hm.. I think using something like Dotenv::Railtie.load from https://github.com/bkeepers/dotenv will suits better in this case instead of statically insert environments into systemd config files, I believe.

minimum2scp commented 3 years ago

Yes, dotenv gem will be good tool to manage envrionment variables for your application. You need to upload .env file by your own custom capistrano task or something.

gencer commented 3 years ago

Exactly. Just finished implementing dotenv and it worked very well (i already upload .env on prod using cap).

Thanks for confirming on this. A second opinion always a value for me!

Issue closed.

P.S> Thank you for this great capistrano plugin.