You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are going to use consul (https://consul.io/) as a service discovery and configuration server as well as vault (https://vaultproject.io/) for secure credentials, and it would be ideal to integrate them into our standard nomad config usage.
How about adding a means of prepending additional phases in the preference ordering for reading config values? Maybe this is just handing nomad functions that will return a map? This way we can check consul and/or vault for config values, and then fall back to the config file.
It would also be great to support live config updates. Consul uses long-polling to allow for real-time updating of config values. (I guess nomad could do the same for local files with a watcher too.) Maybe add a listen function?
Hi Jeff, sorry for the tardy response. Will have a think about the best way to incorporate this into Nomad - it might be that this is a layer above Nomad, and that we just have to make sure that Nomad's extensible enough to be able to cope with it?
After digging into this more we are going to use environment vars instead of config files, so no changes needed for us. Thanks for getting back though.
On Tue, May 19, 2015 at 1:48 PM, James Henderson [email protected]
wrote:
Hi Jeff, sorry for the tardy response. Will have a think about the best way to incorporate this into Nomad - it might be that this is a layer above Nomad, and that we just have to make sure that Nomad's extensible enough to be one with it?
James
Reply to this email directly or view it on GitHub: #22 (comment)
We are going to use consul (https://consul.io/) as a service discovery and configuration server as well as vault (https://vaultproject.io/) for secure credentials, and it would be ideal to integrate them into our standard nomad config usage.
How about adding a means of prepending additional phases in the preference ordering for reading config values? Maybe this is just handing nomad functions that will return a map? This way we can check consul and/or vault for config values, and then fall back to the config file.
It would also be great to support live config updates. Consul uses long-polling to allow for real-time updating of config values. (I guess nomad could do the same for local files with a watcher too.) Maybe add a listen function?
(nomad/listen CONFIG [:sql :host] sql-host-change-callback)
What do you think?
The text was updated successfully, but these errors were encountered: