.webp?#)
Configurations stored in database & GitOps
I recently came upon the concept of GitOps. One idea that's central to GitOps is the use of static configurations (e.g. Git repositories are the source of truth for configurations). In my distributed architecture, there are multiple web APIs with CRUD interfaces for data stored in Cosmos DBs. In addition to components utilizing these web APIs, there are internal applications for administrative users to manually configure this data. A new subsystem that I've built utilizes some of these web APIs' data as configuration values when deploying to my subsystem, meaning that the once-dynamic data becomes static in my subsystem. If I wanted to utilize GitOps here, specifically by storing my subsystem's configuration values in my Git repository, is there a best or standard practice for doing so when the source of my subsystem's configuration values is upstream? A couple of approaches I've thought of include: Utilize Cosmos DB's Change Feeds to trigger PRs to my Git repository Migrating the upstream services to store configurations within Git repositories rather than in Cosmos DB With either approach, I feel like I'm bridging a gap between my distributed architecture and my subsystem for the sake of GitOps and that perhaps I'm missing something.
I recently came upon the concept of GitOps. One idea that's central to GitOps is the use of static configurations (e.g. Git repositories are the source of truth for configurations).
In my distributed architecture, there are multiple web APIs with CRUD interfaces for data stored in Cosmos DBs. In addition to components utilizing these web APIs, there are internal applications for administrative users to manually configure this data. A new subsystem that I've built utilizes some of these web APIs' data as configuration values when deploying to my subsystem, meaning that the once-dynamic data becomes static in my subsystem.
If I wanted to utilize GitOps here, specifically by storing my subsystem's configuration values in my Git repository, is there a best or standard practice for doing so when the source of my subsystem's configuration values is upstream?
A couple of approaches I've thought of include:
- Utilize Cosmos DB's Change Feeds to trigger PRs to my Git repository
- Migrating the upstream services to store configurations within Git repositories rather than in Cosmos DB
With either approach, I feel like I'm bridging a gap between my distributed architecture and my subsystem for the sake of GitOps and that perhaps I'm missing something.
