I'm looking for insights on how to efficiently manage configurations for multiple microservices and applications using Azure App Configuration Service. My platform ingests data from numerous sources, employing a range of Azure Function Apps with Durable Orchestrators. Each microservice has default configurations for elements like storage paths and service bus queues, and while most rely on these defaults, some require custom tweaks.
I've been using Azure App Configuration to centralize these settings, but I'm curious about other people's strategies. How do you handle your default configurations? Do you label them as 'Default' or 'Global' in separate configuration files for each service? Do you replicate defaults across all consuming apps, or set them in source control and override only when needed?
Additionally, any tips on deploying or importing configuration files efficiently? I've automated this in my CI/CD process, but it tends to be slow, taking 7-12 seconds per service.
4 Answers
I keep shared defaults in Azure App Configuration under a special 'Global' label, while specific service configs reside under their own labels. The workflow is that apps check the Global settings first, then overwrite them with their own if needed. For deployment, we handle configurations as code and use scripts in our CI/CD to import them into Azure App Configuration, making the whole process quite streamlined.
I like to use a variable group concept. I prefix shared configuration variables, like Redis settings, so the app can choose what to pull. Each app gets its specific Key Vault for app-specific secrets while shared secrets stay in a common vault. This way, services can overwrite shared settings with their app-specific versions without hassle.
In my setup, we use a similar approach where all our services share a common Azure App Configuration. It's nice because we can manage everything centrally. We tag our settings with labels for different environments like 'dev' or 'prod'. However, some settings need to be overridden through environment variables specific to each service, like log names or storage accounts. Since we have a multi-tenant application, sometimes we store connection strings specific to certain tenants in a private library, which our services can reference.
We use Azure App Configuration for basic settings and rely on Azure Key Vault for any secrets—it's a great way to keep sensitive data secure. When it comes to managing defaults across services, we maintain a 'global' label for shared configs and let each service use its label for specific overrides. For deployment, we manage our configurations as code, making updates via CI/CD pipelines—it’s much easier than doing it manually.
Thanks for sharing! So do you find any downsides to managing configs this way? How often is it updated?
That's a neat approach! How do you handle the actual key management for the app configurations? Do you have a process in place for syncing them with a source file?