脚步不能达到的地方，眼光可以达到；眼光不能达到的地方，精神可以飞到

k8s笔记20--基于 K8S 的 cicd 概述1 介绍2 方案实施2.1 Jenkins + kubectl + k8s2.2 Jenkins + helm + k8s2.3 Zadig + helm + k8s3 注意事项4 说明1 介绍近年来云服务|原生发展迅猛，企业上云已经成为家常便饭。当企业大量服务上云后，如何在云上快速部署、更新服务就是一个必须面对的问题。本文结合当下经典方案，分享以下3种常见基于 K8S的CICD方案，并加以案例介绍。方案 概述 评价jenkins +

工单系统ferry 02--本地运行ferry实例1 介绍2 操作3 注意事项4 说明1 介绍工单系统ferry 01–docker部署ferry 已经介绍了如何使用docker部署ferry，本文继上文介绍如何在本地通过源码运行ferry实例，包括前端和后端服务。2 操作前置条件：参考 工单系统ferry 01–docker部署ferry 启动一个mysql 和redis 实例，并将host 信息更新到 config/settings.dev.yml 中。

工单系统ferry 01--docker部署ferry介绍部署说明介绍开源软件ferry是集工单统计、任务钩子、权限管理、灵活配置流程与模版等等于一身的开源工单系统，当然也可以称之为工作流引擎。致力于减少跨部门之间的沟通，自动任务的执行，提升工作效率与工作质量，减少不必要的工作量与人为出错率。本文主要介绍如何在linux 系统上通过docker 的方式部署 ferry，以便于体验ferry 系统。部署部署mysql安装 mysql：$ docker run -d -p3306:3306 --

cicd 08--基于Jenkins的通用可扩展CICD架构1 介绍2 架构架构图主要模块功能3 案例3.1 场景说明3.2 Job-multi 的功能脚本3.3 执行结果4 优化实施5 注意事项6 说明1 介绍随着运维业务的逐渐增加，团队维护的 cicd 流程种类也随之增加，基于Jenkins 的流程基本可以认为绝大多数都是一种定制(当然有些流程可以通过参数解决一类的问题)，会对后期带来越来越多的工作量。因此需要将 jenkins job 抽象出来，使其功能单一、可复用，基于抽象出来的基础 job

cicd 07--构建前后端一体化自动化发布流程介绍构建过程功能说明jenkins & gitlab 配置测试结果注意事项说明介绍cicd 04–构建自动化发布流程 介绍了一种通用的自动化发布流程，其适用于单个前端或者后端的服务，若某个服务同时包括前后端，且前后端代码分离，那么改方法就不适用了。为此需要设计一种同时包括前后端的自动化发布流程，其思路是分别先后clone 前端、后端代码，然后对前端编译|预处理后将其和后端一起打包为线上可用的镜像，最后发布到集群中。本文介绍 构建前后端一体化自动化发

cicd 06--jenkins 常见问题和注意事项1 介绍2 常见用法3 注意事项4 说明1 介绍近期由于工作需要开始尝试做各种各样的jenkins流程，也遇到了各类奇怪的问题，当然包含一些新书会踩到的坑。因此准备写一篇文章专门记录jenkins 中常见的用法和异常，以便于后续查阅和学习，后续也会持续在这里更新相关问题。2 常见用法获取指定格式时间获取事件可以使用内置的Data 函数，但是其输出格式有限(方法1);也可以通过sh 执行 date 命令的方式输出多样的日期类型，但是其需要指定ag

cicd 05--通过api调用jenkins job1 介绍2 api 案例2.1 python api 调用2.2 curl api 调用3 注意事项4 说明1 介绍笔者在 cicd 01 - cicd 04 中已经介绍了多种常见的jenkins流程， 和其创建的细节、注意事项。而在实际中，除了可以手动在前端触发流程外，偶尔也需要通过API来触发流程; 因此，本文基于之前的流程，完善了调用jenkins api 的案例。分享在此处以便于自己或者有需要的小伙伴查阅，后续会在此处持续更新jenkins

cicd 04--构建自动化发布流程1 简介2 构建过程2.1 功能说明2.2 jenkins & gitlab 配置2.3 测试结果3 注意事项4 说明1 简介在实际项目中，为了提高开发人员的服务发布效率，避免用户手动build镜像、通过脚本(或kubectl)更新服务，通常需要为重要的服务构建一套自动化发布流程。简单来说，开发人员提交代码，MR 到 master 分支，触发 build 镜像操作，并自动推送到镜像仓库，然后更新到测试或者预发布环境，用户测试ok后通知sre团队，sre团队触

cicd 03--构建通用scale流程1 介绍2 cicd构建过程2.1 基本配置2.2 测试结果3 注意事项4 说明1 介绍在实际项目中， 如果没有专用的变更系统，那么可以使用jenkins来快速实现各类基础流程，而且能够达到操作溯源的效果。本文基于jenkins做了一个简单的k8s服务scale流程，用于用户scale服务，同时达到操作溯源的目的。2 cicd构建过程2.1 基本配置参数Cluster 参数：名称: Cluster类型: Choice Parameter数值:

cicd 02--构建通用的CD流程1 介绍2 CD 构建过程2.1 参数配置说明2.2 pipeline 脚本2.3 测试流程3 注意事项4 说明1 介绍笔者在 cicd 01–构建通用的CI流程 中介绍了一个通用的docker 镜像build 和 发布的流程，基于该流程继续构建一个通用的服务发布流程，实现k8s服务的快速更新。2 CD 构建过程以下前提条件是项目中很多服务已经部署好了，因此没有重新部署的必要，对其更新的时候只需要更新其镜像即可。2.1 参数配置说明已有服务沿用现有的yaml配

cicd 01--构建通用的CI流程1 介绍2 CI构建过程2.1 参数配置说明2.2 pipeline 脚本2.3 测试流程3 注意事项4 说明1 介绍笔者在 docker笔记3–配置jenkins 和 k8s笔记7.3–基于gitlab、jenkins、helm、k8s的CI/CD 中介绍了jenkins的安装和基于helm 的k8s 流程。本文基于上述基础继续分享一个构建和发布镜像的通用jenkins流程，以便于为企业中所有的服务实现镜像发布。2 CI构建过程本案例中涉及多种agent，比如普

监控告警03--夜莺新增飞书告警模块-v4版本介绍方法源码变动测试效果说明介绍上文 监控告警02–夜莺飞书告警-v4版本 中，笔者通过更改夜莺 v4 源码 src/modules/server/dingtalk/dingtalk.go 使其发送告警到飞书群。基于上文思路，现在可以在源码中新增 src/modules/server/feishu/ 模块，是夜莺server同时可以按需要使用钉钉和飞书告警模块。方法源码变动新建 src/modules/server/feishu/feishu.g

监控告警02--夜莺飞书告警-v4版本1 介绍2 方法2.1 源码改动2.2 测试效果3 说明1 介绍v4版本的夜莺集成了shell、api、wechat、wechat_robot、dingtalk_robot 等5中常见的告警，然而没有集成飞书告警。当前飞书已经被很多企业采纳，因此做企业运维平台的时候很有必要将告警通知发送到飞书。使用过钉钉和飞书的小伙伴肯定都知道，可以通过群机器人的webhook来发送告警，基于这种方式我们只需要改动源码中 send_im模块，去掉多余的参数和数据结构，将钉钉相关的

监控告警01--夜莺部署与接入滴滴夜莺简介部署docker-compose部署二级制部署 v4 版本客户端部署告警配置邮件告警飞书告警短信告警电话告警测试效果说明常见问题参考文档滴滴夜莺简介夜莺是滴滴开源的一套监控告警系统，其主要包括如下四个子系统，分别是：用户资源中心（RDB）资产管理系统（AMS）任务执行中心（JOB）监控告警系统（MON）更多详细介绍请参考官方文档：滴滴夜莺官方文档部署docker-compose部署线上部署docker-compose版本无意义，因此此处不做介