实现基于 GitLab 的数据库 CI/CD 最佳实践
数据库变更一直是整个应用发布过程中效率最低、流程最复杂、风险最高的环节,也是 DevOps 流程中最难以攻克的阵地。那我们是否能在具体的 CI/CD 流程中,像处理代码那样处理数据库变更呢?
DORA 调研报告
DORA(DevOps Research & Assessment)是一家专注于 DevOps 的研究机构, 在该领域以专业与客观著称。自 2014 年以来,DevOps 调研了全球范围内超过 32,000 名专业人员,并以年度报告的形式对外发布研究成果。DORA 明确指出,将数据库变更纳入应用发布流程将显著提升整体发布效率。
这一结论并不令人意外。问题是,该怎么做?
一个完整的基于 GitLab 的数据库 CI/CD 工作流
通过 Bytebase,我们将实现一个完整的基于 GitLab 的数据库 CI/CD 工作流:
- 开发者将变更 SQL 脚本提交到代码分支;
- 触发 Bytebase 提供的 SQL 审核 CI 进行自动化 SQL 审核,并给出修改建议;
- 修改完成后的 SQL 脚本合并入主分支;
- 自动触发发布流程,脚本将被推送到 Bytebase 工具中;
- Bytebase 内置的自动审核将对变更语句进行二次确认,根据变更风险等级自动匹配审批流,根据审批流审批;
- 审批后的语句可以通过手动或自动触发在目标库中执行;
- 变更完成后的数据库最新 schema 结构将被自动回写入代码仓库;
- 确认变更完成后,触发下一阶段的应用发布流程。
通过 Bytebase 社区版实现
让我们一步一步看看这个过程怎样实现的。
第一步 通过 Docker 启动 Bytebase,并配置外部 URL
ngrok 是一个反向代理工具,我们需要它的公网地址,以便从 GitHub 接收 webhooks。这里使用 ngrok 是出于测试目的;生产环境建议使用 Caddy。
- 登录 ngrok Dashboard,并按照 Getting Started 步骤进行安装和配置。
- 在 Docker 中运行 Bytebase:
docker run --init \ --name bytebase \ --restart always \ --publish 5678:8080 \ --health-cmd "curl --fail http://localhost:5678/healthz || exit 1" \ --health-interval 5m \ --health-timeout 60s \ --volume ~/.bytebase/data:/var/opt/bytebase \ bytebase/bytebase:2.8.0 \ --data /var/opt/bytebase \ --port 8080
- Bytebase 通过 Docker 成功启动,你可以通过
localhost:5678
来访问。注册一个管理员账号。 - 在命令行运行 ngrok http 5678 ,并获得公共 URL。
- 登录 Bytebase,点击右上角的齿轮,将公共 URL 填入到网络部分的外部 URL,点击更新。
第二步 在 Bytebase 种添加 GitLab.com 作为 Git Provider
- 通过公共 URL 来访问 Bytebase,点击右上角的齿轮 > 集成 > GitOps,选择 gitlab.com,点击下一步。你会进入到第二步,拷贝 Redirect URI。
- 访问 GitLab,点击头像,选择下拉菜单中的偏好设置,在左侧栏中选择应用。填写表格如下并保存:
- Name: Bytebase
- Redirect URI: 从 Bytebase GitOps 配置里步骤 2 里复制
- Confidential: Yes
- Scope: api
- 从 GitLab 的应用页面复制 Application ID 和 Secret,然后粘贴到 Bytebase 的 GitOps 配置页面步骤 2 里。
第三步 在 Bytebase 中配置一个 GitOps 工作流
- 访问 GitLab,并建立一个新项目 bytebase-gitlabcom-demo。将 Visibility Level(可见级别)设置为公共。点击建立项目。
- 访问 Bytebase,进入项目 Sample Project。点击 GitOps 标签,选择 GitOps 工作流。点击 配置 GitOps。
- 选择 GitLab.com(就是你在上一步配置的),然后选择 bytebase-gitlabcom-demo 这个项目。你会来到步骤三,保持其它参数不变,滑动到页面底部,勾选 基于 GitLab CI 开启 SQL 审核。点击完成。 Image
- 系统会自动在 GitLab 中建立实现 CI 的 MR,跳转到 GitLab 中手动合并。
- 回到 Bytebase,你会见到 GitOps 工作流已设置成功。
第四步 建立一个 MR(合并请求)去触发 SQL 审核 CI
- 点击界面顶端环境,你可以看到在 Prod 最下方有连接了一个 SQL 审核策略,点击编辑,你会看到有 3 条开启的规则。它们将通过 CI 应用。
- 为了测试 SQL 审核 CI,我们将创建一个合并请求来更改 Prod 数据库 schema。不过,我们会让它先违反下 SQL 审核策略。转到 GitLab 上的 bytebase-gitlabcom-demo。单击新建分支,命名为 add-nickname-table-employee,点击创建分支。
- 在新分支上创建子目录 bytebase,并创建子子目录 prod。在 prod 目录中创建文件
employee##202309262500##ddl##add_nickname_table_employee.sql
。将以下 SQL 脚本复制到文件中,并提交更改。
ALTER TABLE "public"."employee" ADD COLUMN "nick_name" text;
- 创建包含上述提交的合并请求。SQL 审核 CI 将自动运行并显示失败消息。不过,无论 CI 结果如何,你仍然可以合并它。
- 更新 SQL 脚本并提交到当前分支。SQL 审核 CI 将再次运行并显示通过信息。单击合并。
ALTER TABLE "public"."employee" ADD COLUMN "nick_name" text NOT NULL DEFAULT '';
6. 返回 Bytebase 中的 Sample Project,你会看到推送事件产生了一个工单。 7. 点击 issue/102 到问题详情页面。因为没有配置审批流或手动发布,此工单会自动发布。您可以点击查看变更来查看差异。
通过 Bytebase 企业版解锁更多功能
您可以升级到企业版,解锁更多功能。点击左下角的开始免费试用并升级到企业版,点击顶部实例,为现有的两个实例分配证书。
手动发布
在环境 > 2.Prod,找到发布策略,然后选择 人工发布 > 需要 DBA 或者 Bytebase 实例所有者发布。
自定义审批
- 访问设置 > 安全性 & 策略 > 自定义审批。将项目 Project Owner -> DBA 设置为 DDL > 高风险的审批流。
- 访问设置 > 安全性 & 策略 > 风险中心。点击添加规则,然后点击加载第一个模板,点击添加。
最新 schema 写回
Schema 变更完成后,Bytebase 会将最新 schema 写回 Git 代码库。这样,团队在 Git 中就始终有一个数据库 schema 的标准真实源。
- 返回 GitLab,新建一个分支
add-country-table-employee
。在 bytebase/prod 目录下创建文件employee##202309261700##ddl##add_country_table_employee.sql
。将以下 SQL 脚本复制到文件中并提交更改。
ALTER TABLE "public"."employee" ADD COLUMN "country" text NOT NULL DEFAULT '';
- 返回 Bytebase,转到新创建的工单,它符合 Project Owner -> DBA 的审批流程。
- 按照审批流程点击批准后,横幅将显示等待发布。然后,负责人就可以点击 发布了。
- 回到 GitLab,在
bytebase/prod/
下有一个新的文件.employee##LATEST.sql
,包含了 Bytebase 写回的最新 schema。
Schema 漂移
Bytebase 内置了 schema 漂移检测功能,可以检测到意外的 schema 变更。让我们使用 SQL 编辑器管理员模式来模拟一下。
- 点击右上角的终端图标(SQL 编辑器)。你将跳转到 SQL 编辑器。点击管理员模式。在此模式下所做的一切与直接连接服务器相同,Bytebase 不会记录。
- 选择左侧的 (Prod) Employee,粘贴并运行以下脚本:
ALTER TABLE "public"."employee" ADD COLUMN "city" text NOT NULL DEFAULT '';
- 返回 Bytebase 主页,点击顶部的数据库, 选择 Prod 下的 employee。点击现在同步。看到成功消息后,刷新页面。你将看到 schema 漂移。你可以在实例详情页配置自动扫描,以避免手动同步。
- 访问异常中心,也会看到 schema 漂移。
总结
有了 Bytebase,你就有了一套完整的 GitLab 数据库 CI/CD 工作流程。您可以将此工作流程应用到自己的项目中,并根据自己的需要进行定制。 Bytebase 也支持 GitHub,Bitbucket 以及 Azure DevOps。具体的配置步骤可以查看文档。
💡 你可以访问官网,免费注册云账号,立即体验 Bytebase。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
微宏科技基于 KubeSphere 的微服务架构实践
作者:尹珉,KubeSphere Ambassador、contributor,KubeSphere 社区用户委员会杭州站站长。 公司简介 杭州微宏科技有限公司于 2012 年成立,专注于业务流程管理和自动化(BPM&BPA)软件研发和解决方案供应商。创始团队毕业于浙江大学、清华大学、美国 Rice 大学和 University of Texas 等海内外知名高校,曾服务于世界知名软件公司和 500 强企业。 微宏已为超过 1000 家的国内国外大中型企业和政府提供了从流程规划设计、流程运行、流程自动化、流程集成、流程挖掘的全生命周期流程软件产品和解决方案,客户分布于制造、金融、电器电子、医药、服务业、高科技和政府等十多个行业。 微宏科技是国家高新技术企业、浙江省专精特新企业,通过了 ISO9001 质量管理体系认证、CMMI 认证、ISO27001 信息安全管理体系认证。获赛迪“2021 年智能 BPM 领域最佳产品”奖、“2021-2022 业务流程管理&自动化领域优秀产品”奖、中国软件网“2021 年度智能流程平台优秀产品奖”、“2022 应龙杯最佳 BPA 业务...
- 下一篇
SRE实战:如何低成本推进风险治理?稳定性与架构优化的3个策略
一分钟精华速览 SRE 团队每天面临着不可控的各类风险和重复发生的琐事,故障时疲于奔命忙于救火。作为技术管理者,你一直担心这些琐事会像滚雪球一样,越来越多地、无止尽地消耗你的团队,进而思考如何系统性地枚举、掌控这些风险?怎么能更低成本地推进风险治理? 本文根据多家企业 SRE 实战总结,重点分享稳定性和架构优化的核心策略。实践已经验证,多且散的风险是可以被低成本解决的。 作者介绍 数列科技联合创始人、CTO——陆学慧 TakinTalks 稳定性社区发起人。参编《信息系统稳定性保障能力建设指南 1.0》和《稳定性保障服务商能力要求》。2017 年联合创立数列科技,专注于高可用性领域,为企业提供稳定性解决方案,帮助快速稳定地应对技术挑战。 温馨提醒:本文约 5000 字,预计花费 9 分钟阅读。 「TakinTalks 稳定性社区」公众号后台回复 “交流” 进入读者交流群;回复“0926”获取课件资料; 背景 最近一两年,我和很多公司的 SRE 团队进行了交流,发现大家日常都在面临一些故障处理、应急、琐事等等之类的难题。总的来说,就是团队能力和掌控系统风险之间存在一些差距。 其实,系统和...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2全家桶,快速入门学习开发网站教程
- Hadoop3单机部署,实现最简伪集群
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- CentOS关闭SELinux安全模块
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS8安装Docker,最新的服务器搭配容器使用