search

Particular / ServiceControl

Backend for ServiceInsight and ServicePulse
https://docs.particular.net/servicecontrol/
Other
51 stars 47 forks source link

Enable cloud configuration as a 1st class option for containers #3966

Open dbelcham opened 6 months ago

dbelcham commented 6 months ago

Describe the feature.

Is your feature related to a problem? Please describe.

With the movement to provide support for Linux containers #3651, configuration of SC, the bus it connects to, etc, needs to be able to be done outside of the container. Because we are cloud first, we should be able to use a cloud native configuration tool for this functionality. As security conscious cloud users, we need to be able to leverage things like Azure Key Vault as a storage location for sensitive information, like connection strings to our transports.

There are solutions to this in cloud native environments and we should be able to use them to manage all of the configuration of any container.

Describe the requested feature

  1. Have Service Control load configuration from a default appsettings.json file that is bundled in the container
  2. Subsequently, SC should load configuration values from other locations based on values passed into the container as environment variables when it is started. For example -e ENABLE_AZURE_APPCONFIG='true' -e AZURE_APPCONFIG_CONNECTIONSTRING='......'. This could be done for any number of different providers as long as the appropriate extensions for loading configurations are available inside the SC container.
  3. Any configuration that is available in the embedded appsettings.json file will be overridable if the same entry exists in the configuration provider passed in via the environment variables.
  4. We should be able to configure the Service Control instances (whatever are available in the container in question) that are show in this image. The configuration under the gear icon for each of the instances should be included in this scheme. image
  5. Have Service Control look for a license from a fixed configuration entry that can be overridden by an entry in Azure App Config (or any other app config provider) with a full license string in it.
  6. In the Azure world, the 1st class choice would be Azure App Configuration. There are extensions to the .NET Configuration ecosystem to seamlessly integrate this capability during .NET application startup. Azure App Configuration already fronts Azure Key Vault (the 1st class choice for secret storage in Azure) so no direct connection to Key Vault would be needed.
  7. A second choice for Azure, and possibly other environments, would be Consul.

Describe alternatives you've considered

Mounting volumes and modifying a configuration file in that volume.

I have used this technique on containers in the past and it adds a lot of overhead, and a rather large failure point, to the operations side of the container management story. This also creates a situation where we have to manage our configurations in both Azure App Configuration/Key Vault (for our endpoint containers) as well as config files that are pushed to containers. This creates a lot of build pipeline overhead, the possibility for diverging values, and a challenge to maintaining a configuration-as-code policy.

Modifying a configuration file and rebuilding the SC container to include the new file with the new settings.

This pushes container build and management onto the companies that are using SC which will require an intimate knowledge of how to properly do these tasks. This solution will also create a potential barrier for those companies to run on the latest versions of the codebase/tooling as they might not update their container pipelines as quickly as Particular does. As with the previous alternative, there are also concerns with this solution surrounding pipeline overhead, diverging values, and configuration-as-code.

Additional Context

No response

danielmarbach commented 6 months ago

@dbelcham Thanks for raising this feature request. Fully agree with your assessment. As part of the work scheduled for container support we are also revamping parts of the configuration system (quite likely leveraging where possible Microsoft.Extensions.Configuration) to enable some of the scenarios you mentioned.

I realize what I'm going to say now is not helping you currently but I wanted to mention for completeness reasons that ServiceControl already today has the capability of turning settings from environment variables into settings it understands.