Github Actions中替换Kubernetes Manifests中的镜像标签

38次阅读
没有评论

问题描述

在使用Github Actions时遇到了问题。他的项目是一个monorepo,包含了三个NodeJS应用的组件:/core、/worker和/frontend。每个应用都有自己的目录和Dockerfile。此外,项目中还有一个/deployments目录,其中包含了所有将通过ArgoCD应用的Kustomize manifests。

用户的问题出现在Github Actions的工作流程中,尤其是在最后一步。问题出在他在Kustomize目录中替换Kubernetes manifests中的镜像标签,然后将更改后的文件推送到另一个分支或仓库。然而,如果在未来的构建中再次执行替换操作,之前推送的manifests将被其他空的、未替换的manifests覆盖。

用户希望知道如何避免这个问题,以及如何保留所有manifests中的过去更改。

解决方案

在解决这个问题之前,建议备份你的代码和配置文件,以防止意外更改。以下是解决方案的步骤。

使用不同的替换标记

当前的替换方法在后续构建中可能会导致覆盖问题。为了避免这个问题,你可以尝试使用不同的替换标记,以确保在不同的构建中替换不同的内容。

例如,你可以将sed命令中的”IMAGE_TAG”和”DEPLOY_TIMESTAMP”替换为其他字符串,以便在每次构建中替换不同的标记。这将确保之前推送的manifests不会被覆盖。

以下是修改后的步骤示例:

- name: Setting Image Tags/Annotations
  run: |
    for yaml in $(find deployment/kustomize/base -type f -name "core-*.yaml" -print); do
      sed -i "s/NEW_IMAGE_TAG/$COMMIT_SHA/g" $yaml;
      sed -i "s/NEW_DEPLOY_TIMESTAMP/$TIMESTAMP/g" $yaml;
    done
- name: Committing to Staging Branch
  run: |
    export COMMIT_MESSAGE=$(git log --format=%B -n 1 | sed '2d')
    git config --global user.name "CI"
    git config --global user.email "ci@github.com"
    git checkout -b staging
    git add .
    git commit -m "$COMMIT_MESSAGE"
    git push -u -f origin dummy

使用版本控制来管理变更

另一个方法是使用版本控制系统来管理manifests的变更。每次替换镜像标签后,不直接提交到分支,而是创建一个新的提交并将其保存在版本控制系统中。这样,你可以轻松地查看每个构建的变更,并在需要的时候将特定的变更应用到特定的环境中。

使用Git分支来管理变更

你可以为每个构建创建一个新的Git分支,将替换后的manifests提交到这些分支中。这样,你可以保留每个构建的状态,避免覆盖问题,并可以根据需要将特定的变更合并到主分支中。

自动化脚本或工具

如果你经常需要在不同构建中替换manifests中的内容,考虑编写一个自动化脚本或使用适合的工具来管理这个过程。这可以帮助你更容易地执行替换操作,并确保在不同的构建中保持一致的配置。

无论哪种方法,都建议在进行更改之前进行充分的测试,并在执行之前确保备份重要的文件和配置。这将帮助你避免意外的问题,并保持项目的稳定性和可靠性。

请记住,不同的解决方案可能适用于不同的情况,根据你的项目需求和团队的工作流程,选择最适合的方法来解决问题。

正文完