jenkins

CI/CD 工具链的分分合合

作案动机

一种对 ci/cd 工具的轻量化和解耦的尝试?

Jenkins 的传统集群方式,是使用不同环境的服务器构成不同能力的 Jenkins 节点,由主节点根据任务 环节的需要,调度不同能力的子节点来完成构建或部署任务。

进入容器云时代,情况发生了变化,我们可以使用不同能力的 Jenkins 镜像,使用 Kubernetes 插件来 完成这种任务的拆分和调度,为此,我构建了一个包含所有我们平时用到的工具的 Jenkins 镜像,简化了 节点的扩展和选择过程。

然而随着学习和应用的深入,我意识到这种做法有几个问题:

  • DevOps 中隐含着发挥个人能力的愿景,工具链的所谓大而全,只不过是在画一个比较大的圈,使用这样的 一套 Jenkins,还是要被其中所包含的仅有的工具中进行选择,对身陷其中的技术人员绝不能说是友好,也 绝不是鼓励各展所长的态度。

  • 现有的功能测试、接口测试、压力测试等工具,越来越专业化,往往会有各自的工作集群调度甚至是托管方案, 例如 selenium grid、JMeter 集群等。

实用 Jenkins Docker 镜像

Jenkins 跟 GKE 的 Load Balancer 不兼容怎么办?当然是选择原谅他啊。

最近在玩 Google 的 Container Engine,发现 Jenkins 的安装过程的安全防护跟 GKE 的负载均衡器有点不和谐。要在启动初始化过程之前,完成对 CSRF 特性的调整。弄着弄着就收不住了,所以就有了对我那个 “要你命3000” Jenkins 镜像的一次大升级。

为 Gitlab 和 Jenkins 添加 InfluxDB 支持

概述

量化和监控对现在的开发运维工作的重要性是毋庸置疑的。在大肆鼓吹 DevOps 的今天,一体化的数据采集和可视化展示就尤为重要了。

为了能在同一视图下对 Jenkins 和 Gitlab 的操作进行监控,本来写了一些数据采集的脚本,后发现这两个系统都有实现向 InfluxDB 发送指标数据的能力,虽说结构和数据的细致程度可能不及定制脚本,但懒人方案始终是更快的解决办法。

非常对不起各位的是,下面的内容主要是堆代码了。

环境准备

Docker

为方便部署,这里采用 Docker 作为执行环境,过程中需要下载一些镜像,所以这里可能要配置代理或者其他途径来获得镜像文件并导入。

这里假设宿主机 IP 为 10.211.55.5

网络

因为几个组件之间互相需要访问,因此我们首先用如下命令创建一个虚拟网络:

docker network create devops

页面