在哪里存储微服务的配置并组成：在同一仓库或单独的单个或多个中

发布于 2025-01-28 23:07:53 字数 2208 浏览 3 评论 0原文

目标：从适当的分支（功能，hotfix，dev甚至prod）中实现环境（Dev1…Dev3，QA，登台）的CI \ CD和更新（通过提交或拉的请求）。任何分支机构的申请都可以交付给所需的环境。

问题：需要确定在何处存储配置（例如连接字符串或某些设置或docker-compose文件）：

在代码的存储库中（当然是代码）或
创建新的配置每个微服务的存储库，或
为所有微服务创建一个单个配置存储库（per 环境）。

我找不到足够的信息。在大多数情况下，他们谈论单个应用程序和单个存储库。也许有一些来自gitops和devops的混音，这些混合物不允许完整地了解该怎么做。您能澄清一下这部分并提供正确的策略吗？

另外，我发现了一些分离级别：

基础架构 +配置 +应用程序代码（全部在同一仓库中）
（基础架构 +配置）代码（每个应用程序的2个回购）来自配置代码（每个应用程序）
的基础架构代码（每个应用程序 + Infra的2个存储库） repo，看起来像每个环境不同的分支）

不清楚什么属于基础架构以及配置代码。例如：记录级别，docker-compose文件，env。 AppSettings.json中的连接字符串的变量。

基础架构描述：带有.NET核心的10+微服务。每个都有自己的代码存储库。配置文件现在存储在与AppSettings.json的代码的同一存储库中（具有AppSettings.QA.JSON）或AS ENV。变量（将其传递给Docker-Compose）或Docker-Compose或Jenkins文件。因此，至于我，配置与代码分开。

容器：我们使用Docker创建一个容器和Nexus的图像作为图像存储库。我们在撰写阶段将配置从配置YAML文件传递。有有关Gitops的信息，该信息说将每个服务的配置存储在单独的存储库中。但这听起来很奇怪，而且不一致，因为现在我的代码接近设置，一个地方的变化，这看起来不正确。

例如，存在这样的方案：

我在服务1存储库的新功能分支中添加了对我的一半微服务的rebbitmq支持。如果我将配置存储在Micro Service的代码中，则将在编码过程中设置所有设置并通过新集成（使用RebBitMQ）通过CI \ CD。之后，我可以通过连接到rebbitmq到开发环境的连接服务，请检查其工作原理，并合并是否可以使用。，

但是如果我有单独的服务1配置。每个服务的存储库中的分支=环境（dev1，QA），那么我应该更新哪个Env \分支，而功能不发布，但是DEV1环境将通过REBBITMQ设置进行更新。但是，此功能可能永远不会释放和删除，而Dev1分支的更改已经存在。

还是我应该遵循不同的方法并在配置存储库中创建分支，等于应用程序存储库中的分支（每个功能分支）？在这种情况下，我将不得不为每个仓库（额外的工作）创建一个功能分支，并牢记，不要忘记以后为所有人提交配置。这看起来像是一件巨大的过复杂的事情，不是吗？

另外，尚不清楚如何处理AppSettings.json文件，这些文件是应用程序的一部分（Micro Service），如果ENV变量（如果Env = QA）将使用ENV变量（AppSettings.QA.JSON），以及它们应该如何出现在配置存储库？

另一种情况也不清楚：

如何部署“服务1 V.2.0”和“服务2 V.1.0”。到相同的环境Dev1。，而“服务1 V.1.0”和“服务2 V.1.0”。致质量检查。在哪里存储配置，在这种情况下，连接字符串？

以下是存储库的示例，该库将配置作为代码在同一存储库中使用Microservice：

这是存储库的示例，该库将配置作为代码存储在拆分配置存储库中（每种微型服务一对一）：

原文

Goal: implement CI\CD and update (by commit or pull request) of environment (dev1…dev3, qa, staging) from appropriate branch (feature, hotfix, dev or even prod). Application from any branch could be delivered to required env.

Problem: need to decide where to store configuration (for example connection string or some settings or docker-compose files):

in the repository of the code (Configuration as code, for sure) or
create a new configuration repository for each microservice, or
create a single configuration repository for all microservices (per
environment).

I can’t find enough information about this. In most cases they talk about single application and single repository. Maybe there are some mixes from GitOps and DevOps which doesn't allow to have a complete picture of what to do.
Could you please clarify this part and maybe provide the right strategy?

Also I found some levels of separation:

infrastructure + configuration + app code (all in the same repo)
(infrastructure + configuration) code from app code (2 repos for each app)
infrastructure code from configuration code (2 repos for each app + infra repo, which looks like different branch per environment)

Not clear what belongs to infrastructure and what to configuration code.
For example: logging level, docker-compose files, env. variables with connection string in appsettings.json.

Infrastructure description: 10+ micro services with .net core. Each has own repository for code. The configuration files are stored now in the same repository with code as appsettings.json (has overriders like appsettings.qa.json) or as env. variables (pass it to docker-compose), or docker-compose or Jenkins files. So, as for me configuration is split from code.

Containers: we use docker to create an image of the container and nexus as image repository. We pass configuration from config yaml files during compose phase.
There is an information about GitOps which says to store configuration of each service in a separate own repository. But this sounds strange and not consistent, because now my code is close to the settings, changes in one place and this looks correct not overcomplicated.

For example, there is such a scenario:

I add RebbitMQ support for half of my micro services in a new Feature Branch of Service 1 Repository. If I store configuration in the same repo with micro service’s code, then I’ll have no problems to set all settings during coding and pass CI\CD with new integration (with RebbitMQ). After that I can deploy service with connection to RebbitMQ to Dev Environment, check how it works and merge if all is ok to prod.

But if I have a separate Service 1 Config. Repositories for each service where branch = environment (dev1, qa), then it’s not clear which env\branch should I update, while feature was not release, but the dev1 environment will be already updated with RebbitMQ settings. But this feature may be never release and removed, while changes in dev1 branch already exist.

Or should I follow different approach and create branches in Configuration Repository equal to branches in Application repository (branch per feature)? In this case I will have to create a feature branch for each repo (extra work) and keep in mind, not to forget to commit configuration for all of them later. It looks like a huge overcomplicated thing, doesn’t it?

Also, it’s not clear what to do with appsettings.json files which are part of application (micro service), could be overridden by ENV variables (appsettings.qa.json will be used if env=QA) and how should they appear in the Configuration Repository ?

Another scenario is also not clear:

How to deploy “Service 1 v.2.0” and “Service 2 v.1.0.” to the same environment DEV1., while “Service 1 v.1.0” and “Service 2 v.1.0.” to QA env. Where to store configuration, connection strings in this case?

Here is an example of repository which stores configuration as code in the same repository with microservice: