织梦源码网站建设好了后登录不了搜索 引擎优化

在 IT 领域，自动化无疑已成为提高工作效率和减少人为错误的关键。Sealos 作为一个强大的云操作系统，已经为许多企业和开发者提供了稳定可靠的服务。与此同时，随着技术不断发展，集成更多的功能和服务变得尤为重要。考虑到这一点，本文将介绍如何利用 GitHub Action 来进一步丰富 Sealos 在应用更新方面的自动化体验。

原文链接：https://forum.laf.run/d/1059

GitHub Action 介绍

在现代软件开发中，持续集成 (CI) 和持续部署/交付 (CD) 是至关重要的环节。它们可以帮助开发团队高效地验证代码的质量并确保其准确无误地交付到生产环境中。GitHub Action 正是在这个背景下诞生的 CI/CD 工具，致力于为开发者提供一种简洁且高效的自动化工具。

简单来说，GitHub Action 是一个 CI/CD 工具，它允许开发者在 GitHub 仓库中自动执行多种任务，从而极大地提高了工作效率。它可以自动进行代码的构建、测试和部署等关键步骤，确保在每次代码更新或合并请求中都能够进行快速而准确的验证和交付。

但 GitHub Action 不仅仅是一个传统的 CI/CD 工具。其独特之处在于，它与 GitHub 仓库实现了无缝集成。这意味着开发者无需离开 GitHub 环境，就能够配置和管理整个自动化流程，极大地简化了操作过程。此外，由于 GitHub 是目前世界上最大的代码托管平台，这种深度整合使得大量开发者能够轻松上手并利用 GitHub Action 进行自动化操作。

Sealos：同时面向初学者与专家

Sealos 的可视化桌面环境极大简化了用户对分布式应用的管理和维护，用户不再需要进行复杂的操作或拥有深厚的技术背景就能轻松管理分布式应用。通过减少复杂性和提供直观的界面，Sealos 显著地降低了用户的心智负担，使其可以更加集中地完成工作。

Sealos 海外集群：https://cloud.sealos.io

Sealos 国内集群：https://cloud.sealos.top

但 Sealos 不仅仅适用于普通用户，对于云原生领域的专业人员，提供了终端，您可以在终端中执行各种命令行操作。

同时还提供了 kubeconfig 文件的下载功能。拥有这个文件，专业人员可以将其下载到本地电脑，并使用 kubectl 命令行工具来直接管理和操作 Sealos 中的应用资源。这为那些希望深入管理和配置的云原生专家们提供了极大的灵活性。

有了 kubeconfig 之后，我们可以用来实现各种神奇的功能，比如本文将要介绍的自动更新应用镜像。

GitHub Action 自动构建镜像

对于自己开发的应用，要想自动更新应用的镜像，前提是得先自动构建镜像。

GitHub Action 完美集成在 GitHub 平台上，无需额外配置或切换到其他平台即可基于源码来构建镜像。对于公开的仓库，GitHub 提供了一定的免费计算额度，适合小型项目或个人开发者。

使用 GitHub Action 自动构建并推送镜像的流程如下：

1. 创建工作流文件：在你的 GitHub 仓库中创建一个 .github/workflows 目录，并在该目录下创建一个工作流配置文件，例如 docker_build.yml。

2. 配置 Secret：为了安全地推送镜像到 Docker Hub 和 ghcr.io，你需要在 GitHub 仓库的 "Secrets" 部分配置相应的认证信息。通常，这包括你的 Docker Hub 用户名、密码，以及 ghcr.io 的 token。例如：

   

3. 编写工作流脚本：在配置文件中，定义所需的触发条件（如 push 到 master 分支）、运行环境以及执行的命令。

   示例：

   # 定义工作流的名称
   name: Build and Push Docker Image# 定义触发工作流的条件
   on:workflow_dispatch: # 允许手动触发工作流push: # 当有代码推送事件发生时branches:- master # 只有推送到 master 分支时才触发# 定义工作流的任务
   jobs:build-image:# 定义运行此任务的环境：最新版本的 ubunturuns-on: ubuntu-latest# 定义任务中的步骤steps:# 检出代码。只检出最新的1次提交- uses: actions/checkout@v3with:fetch-depth: 1# 设置 QEMU 模拟器，这通常用于多平台的 Docker 构建- name: Set up QEMUuses: docker/setup-qemu-action@v2# 设置 Docker Buildx，用于构建多平台的 Docker 镜像- name: Set up Docker Buildxuses: docker/setup-buildx-action@v2# 登录到 Docker Hub- name: Login to DockerHubuses: docker/login-action@v2with:username: ${{ secrets.DOCKER_USERNAME }} # 使用存储在 GitHub Secrets 中的 DockerHub 用户名password: ${{ secrets.DOCKER_PASSWORD }} # 使用存储在 GitHub Secrets 中的 DockerHub 密码# 登录到 ghcr.io (GitHub Container Registry)- name: Login to ghcr.iouses: docker/login-action@v2with:registry: ghcr.iousername: ${{ github.repository_owner }} # 使用仓库的拥有者名作为用户名password: ${{ secrets.GHCR_TOKEN }} # 使用存储在 GitHub Secrets 中的 ghcr.io 的访问令牌# 构建并推送 Docker 镜像到 docker.io 和 ghcr.io- name: Build and push Docker images to docker.io and ghcr.iouses: docker/build-push-action@v2with:platforms: linux/amd64 # 设置构建平台为 linux/amd64context: . # Docker 构建上下文设置为当前目录push: true # 设置为真以确保构建后的镜像被推送tags: | # 定义推送的标签${{ secrets.DOCKER_USERNAME }}/xxxx:latestghcr.io/${{ github.repository_owner }}/xxxx:latest

4. 触发工作流：每当符合触发条件的事件发生时，GitHub Action 就会自动执行定义的工作流，从而构建和推送 Docker 镜像。

5. 监控与调试：你可以在 GitHub 仓库的 "Actions" 标签页中，查看工作流的执行情况，包括日志、状态和结果。

使用 GitHub Action 自动构建镜像不仅可以简化开发流程，还可以确保每次代码的更改都得到了有效且一致的处理，大大提高了开发效率和代码质量。同时通过使用 GitHub 的 secrets 功能，还确保了认证信息的安全。

自动更新 Sealos 应用镜像

现在我们来到了最后一步。要想自动更新镜像，首先我们来回顾一下整个流程：

首先，当你的应用代码更新并合并到主分支时，GitHub Action 会自动触发构建镜像的任务。构建完成后，新的应用镜像会被推送到镜像仓库。

接下来，你需要在 GitHub Action 中调用 kubectl，更新 Sealos 集群中对应的 Deployment 或 StatefulSet。这样，Sealos 集群的应用就会使用新的镜像版本进行滚动更新。

我们可以利用一个特定的 GitHub Action：actions-hub/kubectl。这个 Action 提供了在 GitHub Actions 工作流中执行 kubectl 命令的能力。

以下是如何在你的 GitHub Actions 工作流中使用 actions-hub/kubectl 来更新 Sealos 应用镜像：

设置 kubeconfig

为了让 kubectl 能够与你的 Sealos 或其他 Kubernetes 集群进行通信，你需要提供一个有效的 Kubeconfig，Sealos 的 kubeconfig 可以在桌面中下载。

下载完成后，你需要将其中的内容转换为 base64 格式：

$ cat kubeconfig.yaml | base64

然后将转换后的内容存储到 GitHub 仓库的 Secret 中，假设 Secret 名为 KUBE_CONFIG 。Secret 配置方式参考上文。

使用 actions-hub/kubectl

现在您只需要在前面自动构建镜像的工作流脚本中添加一个新的 job 来调用 kubectl 即可。例如：

# 定义工作流的名称
name: Build and Push Docker Image# 定义触发工作流的条件
on:workflow_dispatch: # 允许手动触发工作流push: # 当有代码推送事件发生时branches:- master # 只有推送到 master 分支时才触发# 定义工作流的任务
jobs:build-image:......deploy:needs: build-imageruns-on: ubuntu-latestif: github.repository == '<your_repository>'steps:- name: Checkout codeuses: actions/checkout@v3- uses: actions-hub/kubectl@masterenv:KUBE_CONFIG: ${{ secrets.KUBE_CONFIG }}with:args: rollout restart deployment my-deployment

在这个例子中，我们更新一个名为 my-deployment 的 Deployment，更新的方法非常简单：直接滚动重启。因为 Deployment 的 imagePullPolicy 默认都是 Always，且镜像 tag 保持 latest 不变，所以直接重启就会拉取最新的镜像。

如果您的镜像每次构建的 tag 都不同，那可以使用这个命令来更新镜像：

...with:args: set image deployment/my-deployment my-container=my-repo/my-image:<tag>

在这个例子中，我们更新一个名为 my-deployment 的 Deployment，将 my-container 的镜像设置为 my-repo/my-image:<tag>。其中 tag 可以通过环境变量的形式从构建镜像的 job 中获取。

如果您的应用不是自己开发的，且这个应用已提供了镜像，那么您可以设计一个定时触发的工作流，工作流的任务是检测镜像仓库（例如 Docker Hub）的镜像有没有更新，如果更新了，就调用 kubectl 来更新镜像。