docker

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 镜像的一次大升级。

OpenVAS 打包记

docker pull dustise/openvas

git clone https://github.com/fleeto/docker-openvas.git


上回书说到的 OpenVAS,其中的安装过程用的居然不是 Docker,其主要原因有:

  • 第一,安装使用都不熟悉,直接上手第三方比较容易跑偏,官网靠谱一点(现在我知道了,官网也有不靠谱的)。
  • 第二,因为上面的原因,Docker Hub 上的 mikesplain/openvas-docker 不得要领,尤其是客户端连接这部分。(后来知道他的强制更新高估了天朝的网络条件)。
  • 第三,我喜新厌旧,不想用老旧的 8 版本。
  • 第四,多语言支持,在上述 Docker Hub 版本上删节了。

但是作为一个容器云鼓吹者,不弄个顺手的封装的确是不合适的,所以花了些时间,重新来了一次,中间波折蛮多,不过也多了些容器封装方面的经验,就此记录下来。

为 Gitlab 和 Jenkins 添加 InfluxDB 支持

概述

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

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

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

环境准备

Docker

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

这里假设宿主机 IP 为 10.211.55.5

网络

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

docker network create devops

Kubernetes 中的容器运行时接口

文中多次出现了个单词 shim,胡翻成代理了,虽然垫片还是比鲁棒啥的好听。。

归根结底,Kubernetes Node 的最底层就是启动和停止容器的组件了,这一部分我们称之为容器运行时( Container Runtim ),这其中最知名的也就是 Docker 了,这一领域正在快速成长,他并不孤独。为了让 Kubernetes 更具扩展性,我们投入了不少精力,在 Kubernetes 中加入了容器运行时插件 API,我们称之为 “CRI”。

Kompose: Docker-compose 到 Kubernetes 的迁移工具

Docker 给了开发者以巨大的帮助。让每个人都能够从 Docker Registry 启动一个打包好的 Docker 应用。为了对付多容器应用, Docker 开发了 Docker-compose (也就是 Compose)。Compose 借助 yaml 格式的描述文件来定义一个多容器应用,然后就可以用一个简单的 docker-compose up 来启动这一应用中的多个容器。然而,Compose 只能够在本地或者 Docker Swarm 集群中运行。 那如果我们需要在 Swarm 之外运行怎么办?比如 Kubernetes?

我又污染 Github 了!

镜像的清理

最近一直忙些不靠谱的玩意,意外的发现, Docker 和 DevOps 的苟合之后,没有计划生育的结果就是镜像的极度膨胀,兄弟团队每天上百次的构建,让他们可怜的存储条件无法镜像爆炸的后果,因此就有了这俩工具。

两个工具分别用于清理 Docker 的本地镜像以及私库镜像,Github 地址:

  • https://github.com/fleeto/clear-registry-image
  • https://github.com/fleeto/clear-docker-image

基本思路就是把镜像/私库的信息保存在 sqlite 的内存表之中,利用配置文件中保存的 sql 条件对其进行过滤,并进行后续的删除等工作。

之所以没有采用 request 之类而是用的原始的命令行方式,主要是考虑降低部署依赖。

页面