Our next repo (not a plugin this time) by @fermin is ready from some feedback and has been released on github and nuget
It is for using the key/value store in Consul via an implementation of IAppSetting that feels as natural to use as if it were your local appsettings.config and it allows seamless shared configuration between your services.
More on the readme. As previously mentioned, we accept feedback, good or bad and PR’s too.
Cool, a writable IAppSettings provider would be a natural feature people who adopt Consul would be looking to adopt.
Not sure if you’ve looked at it, but a lot of IAppSettings providers are able to save a lot of code by inheriting AppSettingsBase, but not sure if there’s something that would block you from using it or it’s just easier to implement IAppSettings interface directly.
Thanks for the suggestion, we’ll take a look. It’s just the basic get/set at the moment but it can store complex objects as json. It is also a hierarchical k/v store though so we’re thinking about adding a plugin to wire up service specific config with a fall-through to global.
It comes in handy on our next plugin when applying global or service specific policies across services.
There is also support for acl tokens for read/write restrictions and creating a secure vault with config encryption/decryption but I’m not sure if the appsettings interfaces have anything specific to that
As for perf, my initial tests indicate that most config lookups and service discovery lookups are ~1ms from the local agent and replicating settings globally across a consul datacenter takes around a second or two
The Config plugin has now been updated to have fine control over a single appsettings key.
You can change at runtime via consul the value of any key for
and @fermin threw in some caching for free to effectively ratelimit queries against consul
Next up:
We are looking at secure encryption of AppSettings with hashicorp’s Vault using consul as the backend but are not yet sure how it can be opt-in from an IAppSettings to choose a GetSecret(key) over a Get(key)
This functionality will allow our deployment pipeline to setup individual secure expiring and auto-rotating keys per service for accessing connectionstrings, access tokens, credentials and private encryption keys. Or anything really that you want kept secret or need to delegate to Ops or Admin roles to maintain.
this allows us to have service instance specific access revokation and full auditing capabilities as every instance of every service uses a unique key which is tracked.
It also allows us to use Consul as an x-plat distributed certificate store, again for our deployment pipeline to issue and assign service-specific certs for transport-level service encryption.