您的位置:  首页 > 技术杂谈 > 正文

Zadig + Gitee:完美实现微服务架构持续交付

2022-04-28 14:00 https://my.oschina.net/koderover/blog/5520625 Zadig云原生交付 次阅读 条评论
 

概述

Gitee.com(码云) 是开源中国推出的代码托管平台,支持 Git 和 SVN,目前已有超过 800 万的开发者选择 Gitee,随着 Zadig 社区小伙伴对 Gitee 呼声越来越高,在刚刚发布的 Zadig V1.11.0 版本中正式加入了对 Gitee 代码源的支持,同时结合 Zadig 强大的环境管理能力和 Git Webhook 能力,可以帮助更多工程师高效、愉悦的交付。
本文将介绍 Gitee 仓库管理的项目如何在 Zadig 上快速搭建,下面以 microservice-demo 项目为例,该项目包含 Vue.js 前端服务和 Golang 后端服务,以下步骤包含从 Code 到 Ship 的整个过程的演示。

准备工作

案例源码

本案例所用代码及配置 fork 自 项目案例源码,主要包含:

接入 Gitee 代码源

新建 Gitee 第三方应用

  • 点击 Gitee 账号头像 -> 设置 -> 数据管理 -> 第三方应用 -> 创建应用来新建应用程序。

配置 Gitee 第三方应用

填写以下内容后点击创建:
  • 应用名称:zadig,也可以填写可识别的任一名称。
  • 应用主页:http://[koderover.yours.com]
  • 应用回调地址: http://[koderover.yours.com]/api/directory/codehosts/callback
  • 上传 LOGO: 上传符合格式和大小的图片
  • 权限: 勾选 projectspull_requestshookgroups
注意:应用回调地址中 koderover.yours.com 需要替换为 Zadig 系统部署的实际地址

获取 Client ID、Client Secret 信息

应用创建成功后,可获取该应用对应的 Client IDClient Secret 信息。

将配置填入 Zadig 系统

切换到 Zadig 系统,管理员依次点击 系统设置 -> 集成管理 -> 代码源集成 -> 点击添加按钮。
依次填入如下已知信息:
  • 代码源:此处选择 Gitee
  • Client ID:上一步中获取的 Client ID
  • Client Secret:上一步中获取的 Client Secret
  • 组织/用户名称:推荐填写 Gitee 账号的用户名,方便在 Zadig 系统中标识 Gitee 代码源的出处
信息确认无误后点击 前往授权,耐心等待,此时系统会跳转到 Gitee 进行授权。
点击 同意授权 后,跳转到 Zadig 系统,至此 Gitee 集成完毕。

项目配置

进入 Zadig 系统,点击 新建项目 -> 填写项目名称 microservice-demo -> 选择 K8s YAML 项目 -> 点击 立即创建 -> 点击 下一步

新建服务并配置构建

新建服务

服务配置指的是 YAML 对这个服务的定义,Kubernetes 可以根据这个定义产生出服务实例。可以理解为 Service as Code。
Zadig 提供三种方式管理服务配置:
  • 手工输入:在创建服务时手动输入服务的 K8s YAML 配置文件,内容存储在 Zadig 系统中。
  • 从代码库同步:服务的 K8s YAML 配置文件在代码库中,从代码库中同步服务配置。之后提交到该代码库的 YAML 变更会被自动同步到 Zadig 系统上。
  • 使用模板新建:在 Zadig 平台中创建服务 K8s YAML 模板,创建服务时,在模板的基础上对服务进行重新定义。
这里,我们使用手工输入的方式:点击 手工输入按钮 -> 填写服务名称 -> 填写服务 YAML 配置内容 -> 点击 保存按钮即可。
 
backend 服务的配置内容如下:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
  labels: 
    app.kubernetes.io/name: demo
    app.kubernetes.io/instance: backend
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: demo
      app.kubernetes.io/instance: backend
  replicas: 1
  template:
    metadata: 
      labels:
        app.kubernetes.io/name: demo
        app.kubernetes.io/instance: backend
    spec:
      containers:
        - name: backend
          image: ccr.ccs.tencentyun.com/koderover-public/backend:latest
          imagePullPolicy: Always
          command:
            - /workspace/backend
          ports:
            - protocol: TCP
              containerPort: 20219
      imagePullSecrets:
        - name: default-registry-secret
---
apiVersion: v1
kind: Service
metadata:
  name: backend
  labels:
    app.kubernetes.io/name: demo
    app.kubernetes.io/instance: backend
spec:
  type: NodePort
  ports:
    - protocol: TCP
      port: 20219
      targetPort: 20219
 
frontend 服务的配置内容如下:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
  labels:
    app.kubernetes.io/instance: frontend
    app.kubernetes.io/name: demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/instance: frontend
      app.kubernetes.io/name: demo
  strategy: 
    type: RollingUpdate
    rollingUpdate: 
      maxUnavailable: 1
      maxSurge: 1
  template:
    metadata:
      labels:
        app.kubernetes.io/instance: frontend
        app.kubernetes.io/name: demo
    spec:
      containers:
        - name: frontend
          image: ccr.ccs.tencentyun.com/koderover-public/frontend:latest
          imagePullPolicy: Always
          ports:
            - protocol: TCP
              containerPort: 80
          resources:
            limits:
              cpu: 1
              memory: 512Mi
            requests:
              cpu: 100m
              memory: 100M
      imagePullSecrets:
        - name: default-registry-secret
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: frontend
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: 100m
  labels:
    app.kubernetes.io/instance: frontend
    app.kubernetes.io/name: demo
spec:
  rules:
  - host: {{.demo_domain}}
    http:
      paths:
      - path: /
        backend:
          serviceName: frontend
          servicePort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: frontend
  labels:
    app.kubernetes.io/instance: frontend
    app.kubernetes.io/name: demo
spec:
  type: NodePort
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

 

配置构建

配置后端服务构建:选择 backend 服务 -> 点击 添加构建 -> 填写构建配置和构建脚本后保存。
构建配置说明:
  1. 应用列表:选择 go 1.13
  2. 代码信息:准备工作中 fork 的代码仓库
  3. 构建脚本如下:
cd zadig/examples/microservice-demo/backend
make build-backend
docker build -t $IMAGE -f Dockerfile .
docker push $IMAGE
同样的步骤为 frontend 服务配置构建并保存。
 
构建配置说明:
  1. 代码信息:准备工作中 fork 的代码仓库
  2. 构建脚本如下:
cd zadig/examples/microservice-demo/frontend
docker build -t $IMAGE -f Dockerfile .
docker push $IMAGE

加入环境

  • 点击向导的「下一步」。这时,Zadig 会根据你的配置,创建两套包括上述 2 个服务的环境以及相关工作流,如下图所示。

 

  • 继续点击下一步完成向导流程。

 

  • 点击完成向导,一个有 2 个微服务的项目、2 套环境、3 条工作流已经产生,项目概览如下。

工作流交付

使用工作流对环境中的服务进行部署更新,以 dev 环境为例操作步骤如下。
  • 点击 microservice-demo-workflow-dev 工作流 -> 选择服务,点击「启动任务」运行工作流。

 

  • 触发工作流后,可查看工作流运行状况,点击服务左侧的展开图标可查看服务构建的实时日志。

 

  • 待工作流运行完毕,进入 dev 环境,可看到 backend 服务和 frontend 服务被部署更新成功,镜像信息均被更新。

配置自动触发工作流

添加触发器,使得代码 Push commit、Pull Request、Push tag 都能自动触发服务的重新构建和部署。
  • 配置工作流

 

  • 添加 Webhook 触发器 -> 打开 Webhook 开关 -> 添加配置 -> 填写配置 -> 保存配置 -> 保存对工作流的修改

改动代码,触发工作流

  • 以 Pull Request 事件为例说明,提交 Gitee PR 修改源代码

 

  • 切换到 Zadig 系统,查看工作流 microservice-demo-workflow-dev,被自动触发执行

 

  • 待工作流执行完毕,进入 项目->microservice-demo->环境,可看到服务的镜像已被自动触发的工作流更新。

配置 IM 通知

  • 配置工作流

 

  • 添加通知 -> 参考 IM 通知填写相关配置 -> 保存修改

 

  • 工作流执行后,会自动将运行结果和环境、服务等信息推送到 IM 系统中,方便及时跟进
Zadig,让工程师更专注创造! 欢迎加入 开源吐槽群🔥
展开阅读全文
  • 0
    感动
  • 0
    路过
  • 0
    高兴
  • 0
    难过
  • 0
    搞笑
  • 0
    无聊
  • 0
    愤怒
  • 0
    同情
热度排行
友情链接