gpt4 book ai didi

kubernetes - 在 Monorepo 中使用许多包构建条件云

转载 作者:行者123 更新时间:2023-12-02 11:30:35 24 4
gpt4 key购买 nike

动机

我想完全自动化部署很多服务 Google Cloud Build 的帮助下和 Google Kubernetes Engine .这些服务位于 内monorepo ,其中有一个名为 services 的文件夹.

所以我创建了一个 cloudbuild.yaml为每个服务创建一个构建触发器。 cloudbuild.yaml做:

  • 运行测试
  • 构建新版本的 Docker 镜像
  • 推送新的 Docker 镜像
  • 将更改应用于 Kubernetes 集群

  • 问题

    随着服务数量的增加,构建触发器的数量也会增加。也有越来越多的服务被构建,即使它们没有改变。

    因此我想要一个机制,它只有 build 触发器并自动确定哪些服务需要重建。

    例子

    假设我有一个具有此文件结构的 monorepo:
    ├── packages
    │ ├── enums
    │ ├── components
    └── services
    ├── backend
    ├── frontend
    ├── admin-dashboard

    然后我在 frontend 中做了一些更改服务。自 frontendadmin-dashboard服务依赖于 components打包多个服务需要重建:
  • 前端
  • 管理仪表板

  • 但是 不是 后端!

    我试过的

    (1) 多个构建触发器

    设置多个构建触发器每服务。但是这些构建中有 80% 是多余的,因为代码中的大多数更改仅与个人服务相关。管理许多看起来几乎相同的构建触发器也越来越复杂。单 cloudbuild.yaml文件如下所示:
    steps:
    - name: "gcr.io/cloud-builders/docker"
    args:
    [
    "build",
    "-f",
    "./services/frontend/prod.Dockerfile",
    "-t",
    "gcr.io/$PROJECT_ID/frontend:$REVISION_ID",
    "-t",
    "gcr.io/$PROJECT_ID/frontend:latest",
    ".",
    ]
    - name: "gcr.io/cloud-builders/docker"
    args: ["push", "gcr.io/$PROJECT_ID/frontend"]

    - name: "gcr.io/cloud-builders/kubectl"
    args: ["apply", "-f", "kubernetes/gcp/frontend.yaml"]
    env:
    - "CLOUDSDK_COMPUTE_ZONE=europe-west3-a"
    - "CLOUDSDK_CONTAINER_CLUSTER=cents-ideas"

    (2) 循环遍历cloudbuild文件

    This问题是关于一个非常相似的问题。所以我试图设置一个“入口点” cloudbuild.yaml项目根目录中的文件并循环访问所有服务:
    steps:
    - name: 'gcr.io/cloud-builders/gcloud'
    entrypoint: 'bash'
    args:
    - '-c'
    - |
    for d in ./services/*/; do
    config="${d}cloudbuild.yaml"
    if [[ ! -f "${config}" ]]; then
    continue
    fi

    echo "Building $d ... "
    (
    gcloud builds submit $d --config=${config}
    ) &
    done
    wait

    这将消除具有多个构建触发器的需要。但我也遇到了这种方法的问题:

    每个服务都被发送到它自己的构建过程中,并使用此特定服务的文件范围。这意味着,我只能访问 /services/specific-service 中的文件在构建过程中。这对我来说太糟糕了(我需要访问父目录中的文件,如 packages 和根目录中的配置文件)。

    (3) 只构建改变的服务

    由于我想要一种仅构建更改服务的机制,因此我尝试确定需要重建的服务。在 lerna 的帮助下,这似乎很容易做到。 .运行
    lerna changed --all --parseable

    将返回一个列表文件路径到更改的包,如下所示:
    /home/username/Desktop/project/packages/components
    /home/username/Desktop/project/services/frontend
    /home/username/Desktop/project/services/admin-dashboard

    但是,该列表还包括 packages我不知道如何在脚本中使用此列表来循环访问受影响的服务。另外:当我触发构建(例如通过标记提交)时,lerna 将无法在构建过程中识别更改的包,因为更改已经提交。

    我知道这是很长的一段。但我认为这是一个重要的话题,所以我真的很感激任何帮助!

    附注: This如果您想仔细查看特定用例,这就是我的实际项目的样子。

    最佳答案

    构建monorepo 您真的想逐步构建(更改的内容以及取决于更改的部分的部分)。为此,您的构建工具需要以某种方式处理依赖关系图。

    您描述的 Lerna 是为 monorepos 设计的。但也是如此 Bazel它作为 Google Cloud Builder 中的一个选项提供,cloud-builders/bazel带有与 docker builder 结合使用的文档。

    但是,为 monorepos 设计的构建工具通常设置起来更复杂。

    关于kubernetes - 在 Monorepo 中使用许多包构建条件云,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/58755655/

    24 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com