上云小技巧

理解核心上云流程

• 所有微服务的源代码都必须经过 构建 ➡ 打包 ➡ 部署 这三个步骤才可以发布到云环境。
• DORY支持两种部署环境，kubernetes环境和主机环境，因此核心上云流程分为两类:

• kubernetes环境上云流程

• 构建阶段: 设置构建阶段各个微服务的源代码目录，如何进行编译构建，形成编译构建包并存放在共享存储的workspace目录。例如: java的源代码目录，如何进行编译构建，形成jar包。

• 镜像打包阶段: 设置镜像打包阶段如何把构建阶段编译构建出来的编译构建包，打包成容器镜像。例如: jar包如何打包成容器镜像，并推送到harbor镜像仓库中。

• 容器部署阶段: 设置容器部署阶段如何把镜像打包阶段打包出来的容器镜像，在kubernetes环境以微服务形式运行。例如: 微服务的对外服务的端口、微服务的启动命令、微服务启动需要多少CPU或者内存资源、微服务的健康检查方式等等。

• 相关阶段模块定义位于项目定义页面，参见下图

• 主机部署环境上云流程

• 构建阶段: 设置构建阶段各个微服务的源代码目录，如何进行编译构建，形成编译构建包并存放在共享存储的workspace目录。例如: java的源代码目录，如何进行编译构建，形成jar包。

• 制品打包阶段: 设置制品打包阶段如何把构建阶段编译构建出来的编译构建包，打包成制品压缩包。例如: jar包如何打包成制品压缩包，并推送到nexus制品仓库中。

• 制品部署阶段: 设置制品部署阶段如何把制品打包阶段打包出来的制品压缩包，在主机环境以微服务形式运行。例如: 需要设置微服务主机部署的ansible-playbook脚本。

• 相关阶段模块定义位于项目定义页面，参见下图

如何编译源代码

• 设置模块构建定义

• 一个代码仓库支持同时存放多个微服务的源代码，每个微服务的源代码目录可以单独执行编译命令进行编译构建，每个微服务的源代码目录就是一个独立的构建模块。
• 每个构建模块在独立的docker编译构建环境中执行编译，形成的编译构建包会存放在共享存储的workspace目录。
• 编译过程使用的依赖配置文件位于代码仓库的BuildDepends目录。
• 编译构建执行过程:
  1. 自动拉取代码仓库特定分支的源代码，并且把源代码保存在共享存储的workspace目录。
  2. 启动独立的docker编译构建容器，挂装代码仓库的buildPath目录，执行buildCmds模块编译构建命令。
  3. 生成的编译构建包会存放在共享存储的workspace目录，执行buildChecks模块构建结果验证命令，确认生成的编译构建包文件是否存在以及大小是否正常。
  4. 编译结束，docker编译构建容器被清理回收。
• 特殊构建设置说明:
  • 构建步骤ID(buildPhaseID):
    • 假设某个java程序，分了两个代码目录，一个代码目录是common的通用类，另外一个代码目录是webapp的服务类，需要先编译common通用类，再使用common通用类生成的jar包作为webapp服务类的编译依赖。那么可以设置common模块的buildPhaseID=1，webapp模块的buildPhaseID=2。实现分阶段编译
  • 需要缓存的子目录路径(buildCaches):
    • 对于npm的编译环境，由于每次执行编译都要拉取依赖，并在代码目录中形成node_modules目录需要花费很长时间，此时可以指定对node_modules目录进行缓存。缓存的node_modules目录使用挂装的方式挂装到共享存储的workspace目录，在每次执行编译的时候自动挂装进来，实现node_modules目录缓存，大幅提高npm的编译速度。
    • 注意：buildCaches缓存子目录实际不在共享存储的workspace目录，因此，在镜像打包阶段和制品打包阶段共享存储的workspace目录中不存在这些缓存的目录。如果打包阶段需要使用这些缓存目录中的文件，请在构建阶段把缓存目录保存成其他目录。

如何把编译结果打包成容器镜像

• 设置模块镜像打包定义

• 支持把多个不同的构建模块构建出来的编译构建包文件打包到同一个容器镜像中。
• 镜像打包执行过程:
  1. 自动挂装共享存储的workspace目录，该目录包含了代码仓库的全部源代码，以及编译构建阶段所有构建模块生成的编译构建包。
  2. 使用设置的dockerFile，打包容器镜像，并自动把容器镜像推送到harbor镜像仓库。
  3. 对于relatedBuilds来源构建模块涉及多个不同的模块情况下，假如有部分模块没有执行编译，那么镜像打包过程中会提示找不到文件的错误。请务必保证relatedBuilds都同时执行了编译构建。

如何把容器镜像发布到kubernetes

• 设置模块容器部署定义

• 镜像打包阶段生成的容器镜像，可以部署到kubernetes中。
• 用户无需学习复杂的kubernetes部署文件如何编写，通过设置模块容器部署定义，即可以指定微服务的启动命令、对外暴露的端口、需要分配多少资源给该服务、如何进行健康检查等等配置，实现自行把应用部署到kubernetes。
• 容器部署执行过程:
  1. 自动把模块容器部署定义翻译成kubernetes的部署文件，通过kubernetes api接口自动部署到kubernetes中。
  2. 生成的kubernetes部署资源包括: deployment/statefulset, service, hpa, ingress。
  3. 完成部署后，自动检测微服务的pod容器状态是否正常，直到服务的状态为ready或者失败超时为止。假如状态检测失败，会自动输出容器启动的事件信息；假如容器启动成功，但运行启动命令失败，会自动输出启动指令的输出日志，便于错误调试。

如何把编译结果打包成制品压缩包

• 设置模块制品打包定义

• 支持把多个不同的构建模块构建出来的编译构建包文件打包到同一个制品压缩包中。
• 制品打包执行过程:
  1. 自动挂装共享存储的workspace目录，该目录包含了代码仓库的全部源代码，以及编译构建阶段各个构建模块生成的编译构建包。
  2. 根据artifacts制品路径设置，把workspace目录的编译构建包或者相关配置文件打包成压缩包，并自动把制品压缩包推送到nexus依赖与制品仓库的raw仓库。
  3. 对于relatedBuilds来源构建模块涉及多个不同的模块情况下，假如有部分模块没有执行编译，那么制品打包过程中会提示找不到文件的错误。请务必保证relatedBuilds都同时执行了编译构建。

如何把制品压缩包发布到主机

• 设置模块制品部署定义

• 为环境添加新主机

• 项目维护者maintainer可以打开 项目控制台 -> 项目管理 -> 选择特定项目 -> 项目环境设置 -> 环境主机设置 -> 配置新主机

• 创建相关主机，设置主机名和主机分组，以及主机的ssh连接设置。注意，由于使用ansible来远程连接主机，请保证远程主机上安装了python3

• 制品打包阶段生成的制品压缩包，可以部署到多个不同的主机中。
• 添加主机后，就可以在模块制品部署定义中设置制品部署的ansible脚本，向特定的主机分组或者主机上部署制品。
• 制品部署执行过程:
  1. 从nexus拉取最新的制品压缩包。
  2. 自动启动ansible的docker容器，连接对应的主机，通过ansible脚本把制品发送到远程主机，执行ansible部署脚本，进行主机部署。

如何配置流水线实现应用动态上云

• 设置流水线定义
• 由于一条流水线支持同时进行多个微服务模块上云操作，通过流水线设置，用户可以设置本次流水线执行，要执行哪些微服务模块的应用上云。
• 用户可以通过设置流水线步骤开关，设置本次流水线执行，哪些步骤需要执行，以及每个步骤的设置。

• 内置流水线步骤包括:

  • 拉取代码(gitPull): 从特定分支拉取代码仓库的源代码到共享存储的workspace目录。
  • 创建流水线运行文件(createRunFiles): 根据各类模块定义和流水线定义，生成流水线运行需要的配置文件。
  • 编译构建代码(build): 根据模块构建定义，对微服务模块的代码目录进行编译构建。注意: 假如该步骤关闭，后续所有步骤都会关闭
  • 代码扫描(scanCode): 使用sonarqube对微服务模块的代码目录进行代码扫描，并输出代码扫描报告。
  • 镜像打包上传(packageImage): 根据模块镜像打包定义，把完成编译的编译构建包打包成容器镜像，并自动上传到harbor镜像仓库。
    • 注意: 假如该步骤关闭，后续scanImage、syncImage、deploy、applyIngress、applyMesh、checkDeploy、checkQuota步骤都会关闭
  • 镜像扫描(scanImage): 使用trivy镜像扫描工具对harbor镜像仓库中的容器镜像进行扫描，并输出镜像扫描报告。
  • 制品打包上传(artifact): 根据模块制品打包定义，把完成编译的编译构建包打包成压缩包，并自动上传到nexus依赖与制品仓库。
    • 注意: 假如该步骤关闭，后续deployArtifact步骤都会关闭
  • 同步生产环境镜像到集成环境(syncImage): 假如该流水线设置了正式环境，那么自动把正式环境中除本次需要部署的模块之外的其他模块的容器镜像版本同步到集成环境，以保证集成环境上所有微服务的版本与正式环境完全一致来进行上线前测试。注意: 假如流水线没有设置正式环境，本步骤不执行
  • 容器应用部署(deploy): 根据模块容器部署定义，自动生成kubernetes的部署配置(包括 deployment/statefulset, service, hpa)，并通过api接口自动部署到kubernetes集群中。注意: 假如该步骤关闭，后续applyIngress、applyMesh、checkDeploy、checkQuota步骤都会关闭
  • 部署ingress(applyIngress): 根据模块容器部署定义，自动生成kubernetes的ingress部署配置，并通过api接口自动部署到kubernetes集群中。后续kubernetes集群中的微服务即可以通过域名的方式进行访问。
  • 服务网格设置(applyMesh): 根据模块服务网格定义和模块服务网格网关定义，自动生成kubernetes的服务网格配置，并通过api接口自动部署到kubernetes集群中。
    • 一旦启用服务网格，网格中的微服务将具备蓝绿发布 AB测试发布 金丝雀发布 三种混合灰度发布能力
      • 蓝绿发布: 普通用户访问www.example.com域名访问旧版本微服务，测试人员访问test.example.com域名访问新版本微服务
      • AB测试: 普通用户访问www.example.com，如果http请求带上特定的http header(例如访问的浏览器是Chrome)，可以访问新版本微服务；否则访问旧版本微服务
      • 金丝雀发布: 通过OPS流水线，例如调整10%的流量给新版本微服务，那么访问www.example.com将会有10%的几率访问到新版本微服务。
    • 注意: 只有 模块服务网格网关定义 的 是否启用服务网格(enable) 设置为启用的情况下，才会把微服务部署在网格中
  • 容器应用状态检查(checkDeploy): 检查kubernetes中的微服务的启动状态，假如超过检查时间依然状态为异常，那么自动输出pod容器的事件信息以及pod容器的错误日志
  • 项目容器资源配额检查(checkQuota): 检查kubernetes环境namespace下的资源配额的占用情况。
  • 主机应用部署(deployArtifact): 根据模块制品部署定义，自动生成ansible-playbook自动部署脚本，并自动从nexus依赖与制品仓库拉取微服务的制品，然后启动ansible容器，通过ansible容器向目标部署主机发送应用部署指令，把微服务的制品部署到目标主机上。支持把微服务部署到多台主机上。
  • 接口自动化测试(testApi): 自动扫描代码仓库的Tests/api下的接口自动化脚本，使用robotframework容器执行接口自动化测试，并自动输出测试报告。
  • 性能自动化测试(testPerformance): 自动扫描代码仓库的Tests/performance下的性能自动化脚本，使用jmeter容器执行性能自动化测试，并自动输出测试报告。
  • 界面自动化测试(testWebui): 自动扫描代码仓库的Tests/webui下的界面自动化脚本，使用robotframework容器执行界面自动化测试，并自动输出测试报告。
  • 等待输入(input): 假如该流水线设置了正式环境，执行正式环境的deploy或者deployArtifact步骤之前，弹出人工确认提示框，只有人工点击确认才会执行正式环境的部署。注意: 假如流水线没有设置正式环境，本步骤不执行

• 特殊构建设置说明:

  • 是否开启构建模块自动检测(isAutoDetectBuild):
    • 注意: 在isAutoDetectBuild开启状态下，如果没有任何代码提交，不会执行任何模块的构建、打包、部署

FAQ

如何配置、查看和清理编译依赖

• 为提高编译速度，编译构建的依赖包文件分为两级缓存:

  • 一级缓存为共享存储中的项目依赖缓存目录，编译构建过程中启动的构建容器会直接挂装项目依赖缓存目录，每次编译的时候自动挂载该缓存提高编译速度。
  • 二级缓存为nexus依赖与制品仓库，假如一级缓存中没有相关依赖，那么会通过nexus从互联网的可信依赖源拉取依赖。

• 编译构建过程中使用的编译依赖配置可以在代码仓库的BuildDepends目录中设置。在执行构建步骤的时候，流水线自动把本目录的配置文件复制到构建容器中，用于拉取构建依赖。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

└── BuildDepends # 构建依赖配置文件存放目录，流水线执行过程会把该目录的依赖配置复制到构建环境中进行代码构建
    ├── .config # go的构建依赖配置文件存放目录
    │   └── go
    │       └── env
    ├── .gradle # gradle的构建依赖配置文件存放目录
    │   ├── gradle.properties
    │   └── init.gradle
    ├── .m2 # maven的构建依赖配置文件存放目录
    │   └── settings.xml
    ├── .npmrc # npm的构建依赖配置设置
    ├── .pip # python的构建依赖配置文件存放目录
    │   └── pip.conf
    ├── README.md # 构建依赖配置目录说明
    └── go # go的构建依赖配置文件存放目录
        └── pkg
            └── .gopkg

• 模块构建定义中可以设置模块构建命令(buildCmds)，输入ls -alh ~命令可以查看依赖缓存目录的文件清单；也可以通过模块构建命令(buildCmds)的设置，清理特定目录的依赖缓存。

如何使用本地镜像提高镜像打包速度

• 为提高镜像打包速度，模块镜像打包定义的制作镜像的Dockerfile指令(dockerFile)中，来源镜像FROM设置尽量避免使用公网镜像，建议使用内网镜像。内网镜像有两种使用方式:

  1. 把来源镜像推送到harbor镜像仓库
  • 在开发电脑上设置harbor域名的主机名解析
  • 设置开发电脑上的docker的daemon.json，具体参见 https://docs.docker.com/registry/insecure/
  • 重启开发电脑上的docker服务
  • 拉取并推送镜像到harbor的项目仓库下

    1 2 3 4 5 6 7 8 9 10

    # ${IMAGE_NAME} 为目标镜像名字 # ${HARBOR_DOMAIN_NAME} 为harbor的域名 # ${PROJECT_NAME} 为本项目的名字 # 拉取目标镜像 docker pull ${IMAGE_NAME} # 调整镜像标签 docker tag ${IMAGE_NAME} ${HARBOR_DOMAIN_NAME}/${PROJECT_NAME}/${IMAGE_NAME} # 推送镜像到harbor docker push ${HARBOR_DOMAIN_NAME}/${PROJECT_NAME}/${IMAGE_NAME}

  • 推送后就可以在模块镜像打包定义的制作镜像的Dockerfile指令(dockerFile)中，来源镜像FROM设置为使用harbor镜像
  2. 使用nexus依赖与制品仓库的镜像代理缓存功能
  • nexus依赖与制品仓库有三个镜像仓库的代理，分别是hub.docker.io，gcr.io，quay.io，DORY管理员可以通过查看 管理控制台 -> 查看系统配置 获取nexus镜像仓库代理仓库的主机名和端口
    • nexus镜像仓库的主机名 ${NEXUS_HOSTNAME}: artifactRepoConfigs.hostnameInternal
    • nexus镜像仓库的hub.docker.io代理的端口 ${NEXUS_PORT_DOCKER}: artifactRepoConfigs.portDocker
    • nexus镜像仓库的gcr.io代理的端口 ${NEXUS_PORT_GCR}: artifactRepoConfigs.portGcr
    • nexus镜像仓库的quay.io代理的端口 ${NEXUS_PORT_QUAY}: artifactRepoConfigs.portQuay
  • 在模块镜像打包定义的制作镜像的Dockerfile指令(dockerFile)中，来源镜像FROM设置为使用nexus代理的镜像 ${NEXUS_HOSTNAME}:${NEXUS_PORT_DOCKER}/openjdk:20-jdk ，例如: 192.168.0.1:30004/openjdk:20-jdk

如何使用kubernetes-dashboard管理微服务

• kubernetes-dashboard是一个容器管理界面，通过这个管理界面可以管理项目namespace下所有资源和容器。kubernetes-dashboard的项目token具备以下权限:

  • 注意: 项目token不能创建资源，资源只能通过流水线进行创建
  • 检查资源状态
  • 删除资源，例如删除 deployment/statefulset/service/等
  • 进入pod容器中执行指令
  • 查看pod容器的日志输出
  • 对deployment/statefulset进行扩缩容

• 打开kubernetes-dashboard并获取项目的管理token

  • 打开项目kubernetes-dashboard，并获取项目的管理token

• 查看pod容器状态，管理pod容器

  • 获取项目名字空间下所有pod容器

  • 查看pod容器的信息和状态
  • 可以查看pod容器输出的日志
  • 可以进入pod容器，手工执行命令
  • 可以删除pod容器，进行服务重启
  • 注意: 不能通过kubernetes-dashboard修改pod容器信息

• 查看部署deployment/statefulset的状态，管理部署

  • 查看部署deployment/statefulset的状态
  • 可以调整部署的副本数，如果想彻底停止服务，可以把副本数设置为0
  • 可以重启部署，这样部署涉及的所有pod容器都会重启
  • 可以删除部署，对于无用的部署可以在这里永久删除。
  • 注意: 不能通过kubernetes-dashboard修改部署信息

如何使用调试组件管理项目应用的文件目录

• 调试组件是两个部署在kubernetes的项目namespace中的容器，类似一种部署在kubernetes中的跳板机。

• 调试组件这两个容器都挂装了项目应用的共享存储，项目各个应用写入的日志或者数据都存放在这两个容器的/${PROJECT_NAME}目录，其中${PROJECT_NAME}为项目名。

• 这两个调试组件的容器分别是:

  • ssh命令行调试组件(ssh-debug)，通过SSH客户端连接，可以通过scp方式把项目应用共享存储中的文件复制出来，或者把本机的文件复制到项目应用的共享存储中，或者调整项目应用的共享存储的目录权限。
  • vnc图形化调试组件(vnc-debug)，通过浏览器打开对应链接访问，可以在vnc中以图形界面的方式访问项目应用，例如通过vnc中的浏览器来访问项目应用的前端界面。

• 创建并连接调试组件

  • 打开项目控制台 -> 项目管理 -> 项目详情 -> 项目环境设置 -> 环境调试组件设置 -> 新增调试组件，在项目对应kubernetes集群环境中部署调试组件
  • 部署后可以看到两个调试组件在kubernetes环境中部署的容器名字信息
  • 部署后可以查看连接说明，查看如何连接两个调试容器

• 连接ssh命令行调试组件(ssh-debug)，并查看项目共享目录中的内容

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

# 连接ssh命令行调试组件(ssh-debug)
ssh -p ${SSH_PORT} sshuser@${REMOTE_HOST}

# sudo切换到root账号
sudo su -

# 查看项目目录，该目录是项目各个微服务挂装的共享存储目录
tree /${PROJECT_NAME}
├── tp1-gin-demo
│   ├── config1
│   │   ├── config.json
│   │   ├── config.yaml
│   │   ├── prod
│   │   │   ├── config.json
│   │   │   └── config.yaml
│   │   ├── test
│   │   │   ├── config.json
│   │   │   └── config.yaml
│   │   └── uat
│   │       ├── config.json
│   │       └── config.yaml
│   ├── config2
│   │   ├── app.yaml
│   │   ├── prod
│   │   │   └── app.yaml
│   │   ├── test
│   │   │   └── app.yaml
│   │   └── uat
│   │       └── app.yaml
│   └── logs
│       └── tp1-gin-demo.logs
├── tp1-go-demo
│   └── logs
│       └── tp1-go-demo.logs
├── tp1-node-demo
│   └── logs
│       └── tp1-node-demo.logs
├── tp1-python-demo
│   └── logs
│       └── tp1-python-demo.logs
└── tp1-spring-demo
    └── logs
        └── tp1-spring-demo.logs

24 directories, 155 files

• 连接vnc图形化调试组件(vnc-debug)

  • 通过浏览器方式打开vnc图形界面
  • 注意: vnc容器中需要使用服务名+内部端口的方式访问项目微服务
  • vnc支持剪贴板功能，能够把vnc容器的文字复制到个人电脑上，也可以把个人电脑的文字复制到vnc容器中

  • 注意: 切勿进行logout操作，一旦logout就会导致无法再连接vnc容器
  • 直接关闭浏览器即可退出vnc
  • 如果不小心点击了logout操作，请在kubernetes-dashboard中删除vnc-debug的pod容器，重新创建vnc-debug容器。

• 调试组件为CentOS操作系统，支持使用yum命令安装软件工具，配合项目应用调试与应用部署配置。

如何在kubernetes中调试启动失败的微服务

• 通过流水线打包的容器镜像部署到kubernetes中，容器启动失败常见的原因有以下几种:

1. 模块镜像打包定义的Dockerfile设置不正确，导致容器镜像不正确

• 请检查容器镜像的目录存储是否正确，可以在Dockerfile中使用RUN ls -alh ${PATH}指令打印特定目录，查看目录文件以及目录权限是否正确。
• 请检查容器镜像的启动用户以及目录权限是否正确。

2. 模块容器部署定义的设置不正确，导致容器无法启动，并且没有任何日志输出

   • 请检查流水线的checkDeploy步骤的执行日志，执行日志会输出有异常状态的容器的events启动事件信息。
   • 也可以打开kubernetes-dashboard，查看有问题的pod容器，在pod详情中可以看到pod的相关event。

3. 模块容器部署定义的设置不正确，导致容器不断重启，但能看到日志输出

   • 请检查流水线的checkDeploy步骤的执行日志，执行日志会输出有异常状态的容器的logs日志信息。
   • 也可以打开kubernetes-dashboard，查看有问题的pod容器，在pod详情中可以查看pod的日志信息。

4. 不明确启动失败原因

• 可以在模块容器部署定义中设置启动应用的命令行(deployCommand)为tail -f /dev/null，清除应用状态检查设置(deployHealthCheck)设置。
• 以上方式可以启动一个实际没有启动服务的容器。然后使用kubernetes-dashboard，进入刚刚启动的容器，手工执行服务启动命令，定位问题原因。

如何在kubernetes中部署mysql数据库

• DORY除了支持部署动态应用到kubernetes集群，也支持部署静态应用(各类中间件)到kubernetes集群。

  • 打开项目控制台 -> 项目管理 -> 项目详情 -> 项目环境设置 -> 环境组件设置 -> 新增组件，在项目对应kubernetes集群环境中部署调试组件
  • 完成创建后可以看到在kubernetes集群中部署的mysql组件

如何把代码仓库中的数据库脚本注入到kubernetes中的mysql数据库

1. 把刚才创建的mysql数据库配置成环境数据库，这样代码中的数据库脚本后续可以注入到刚刚创建的数据库中。

• 打开项目控制台 -> 项目管理 -> 项目详情 -> 项目环境设置 -> 环境数据库设置 -> 配置新数据库，把刚刚创建的mysql数据库添加到环境数据库设置中
• 新增一个数据库标识为tp1-mysql的数据库，指向刚才创建的数据库实例。
• 注意: 数据库连接方式要使用完整的服务名包含 jdbc:mysql://${SERVICE_NAME}.${PROJECT_NAME}:3306/${DB}，例如: jdbc:mysql://tp1-mysql.test-project1:3306/testdb

2. 在代码仓库的为新的tp1-mysql创建相关注入和回滚脚本

• 代码仓库的DBScripts/README.md中包含相关数据库注入和回滚文件的说明
• 在代码仓库中创建以下目录DBScripts/${ENV_NAME}/${DB_NAME}，其中${ENV_NAME}为环境的名字，${DB_NAME}为数据库标识的名字，这里为tp1-msyql。
• 根据DBScripts/README.md的说明创建相关注入脚本和回滚脚本。
• 代码仓库目录结构样例:

  1 2 3 4 5 6 7 8 9 10

  DBScripts ├── README.md └── test └── tp1-mysql ├── execute │   ├── V1.0.0.1.1__create_persons_table.sql │   └── V1.0.0.1.2__insert_persons.sql └── rollback ├── V1.0.0.1.3__delete_persons.sql └── V1.0.0.1.4__drop_persons_table.sql

3. 把数据库脚本代码推送到代码仓库中

4. 执行ops流水线，进行数据库脚本注入

• 执行ops流水线，进行数据库脚本注入

• 执行过程提示选择代码仓库的分支，不同分支对应不同的集成环境以及正式环境
• 提示选择操作类型，这里选择执行数据库脚本注入，点击确定，使用代码仓库中的execute目录的脚本注入到tp1-mysql数据库中。

执行ops交互式流水线

• 流水线(pipeline)分为两种类型:

  • 持续交付流水线: 会根据应用源代码的更新进行应用的 构建 ➡ 打包 ➡ 发布。每一条持续交付流水线对应代码仓库一个分支。
  • ops交互式流水线: 有部分跟操作与持续交付无关，例如微服务出现问题，需要对微服务的版本进行回滚，那么这类操作则放在ops交互式流水线中，需要由用户手工触发，并且在界面上选择分支，选择操作类型等信息来执行流水线。ops交互式流水线不绑定固定的代码分支，而是在执行流水线过程中由人工选择从哪个分支拉取代码。

  • 两种流水线

• ops交互式流水线执行过程:

  1. 选择代码仓库的分支，根据选择的分支拉取对应分支的代码，根据不同的分支，在不同的集成环境以及正式环境执行相关操作。

  2. 选择操作类型，根据选择的操作类型执行相关操作。

  3. 选择执行操作的模块，或者确认执行相关操作。

  4. 执行实际操作。

如何调整部署定义，直接部署镜像到kubernetes

• 如果你并没有修改微服务的代码，只是想调整微服务的模块容器部署定义，然后重新部署微服务。那么你不必执行 编译、打包、部署 的持续交付流水线。
• 你只需要执行ops交互式流水线，选择代码仓库的分支，操作类型选择执行容器发布，选择需要部署的微服务，即可重新在kubernetes环境部署微服务。