传统的单机构建环境在项目变大、任务变多时,容易出问题,比如容易崩溃、资源不够用、任务排队,以及成本和资源利用的矛盾。本文会介绍用容器化技术Docker-in-Docker(DinD)来解决这些问题,打造一个灵活、高效的CI/CD系统。
1. 背景
当前构建环境因依赖单台机器,面临诸多挑战:
- 单点故障风险,硬件或网络故障易致构建流程中断;
- 资源瓶颈,频繁的构建任务使机器负载过高,频繁触发告警,影响系统稳定性;
- 任务堆积,大量任务积压致后续任务延迟甚至超时失败,降低构建效率;
- 成本与资源利用问题,增加机器虽可缓解资源紧张,但会增加运维和硬件成本,且任务非持续高峰,部分时间资源闲置浪费。
2. 技术选型方案
2.1 Kaniko
Kaniko 是谷歌开源的一款构建容器镜像的工具。Kaniko 并不依赖于 Docker 守护进程,完全在用户空间根据 Dockerfile 的内容逐行执行命令来构建镜像,这就使得在一些无法获取 docker 守护 进程的环境下也能够构建镜像。
Kaniko 通过提取基础镜像的文件系统,按顺序执行 Dockerfile 中的指令,每执行一条指令后在用户空间创建文件系统的快照并与上一状态对比,若有变化则生成新镜像层并更新元数据,最终将构建好的镜像推送到镜像仓库。
2.1.1 简单例子
下面是一个使用kaniko的构建的简单例子
创建密钥
kubectl create secret generic -n blazehu kaniko-secret-common --from-file=config.json |
构建测试
apiVersion: v1 |
- 使用 kaniko-project/executor:latest 镜像执行构建任务
- 构建参数 –context: 上下文指定 Git Repository(仅支持 git://[repository url][#reference][#commit-id] 格式)
- 构建参数 –destination: 指定配置的推送镜像的地址
- 镜像推送挂载了 kaniko-secret 密钥
2.1.2 构建新的CI镜像
那我们如何结合蓝盾来实现Dind呢?我们需要重新制作一个新的蓝盾CI镜像,参考《构建并托管一个 CI 镜像 》,该CI镜像需要包括 kaniko 执行器。这里通过多阶段构建来制作新的CI镜像。
FROM m.daocloud.io/gcr.io/kaniko-project/executor:latest as kaniko |
2.1.3 蓝盾流水线
- 第一步使用蓝盾 Checkout 插件拉取代码
- 第二步使用蓝盾 Shell Script 插件执行 kaniko 构建命令
kaniko/executor --context=/data/devops/workspace --dockerfile=Dockerfile --destination=blazehu1122/example:latest --ignore-path=/ "
2.2 Dind Unix Socket
使用 DaemonSet 来启动 Dind Pod,将 Docker socket 文件 /var/run/docker.sock 挂载到 Pod 中。在要使用Docker服务的 Pod 中都需要挂载 socket文件。
2.2.1 简单例子
apiVersion: apps/v1 |
在这个配置中,/var/run/docker.sock 被挂载到 Pod 中,允许 Pod 直接与宿主机上的 Docker 守护进程通信。这种方式不需要设置 DOCKER_HOST 环境变量,因为 Docker 客户端和守护进程直接通过 socket 文件通信。
2.3 Dind TCP
定义一个 Deployment 和一个 Service,用于启动一个包含 Dind 的 Pod,并通过 Service 对外提供 Docker 服务。在要使用Docker服务的 Pod 中设置 DOCKER_HOST 环境变量,使得 Docker 客户端知道如何连接到 Docker 守护进程(比如在bkci的基础镜像中注入该环境变量)。
2.3.1 简单例子
apiVersion: apps/v1 |
在需要使用 Docker 的 Pod 中设置 DOCKER_HOST 环境变量为 bk-ci-docker-dinp.blueking.svc.cluster.local,通过 Kubernetes Service 的域名解析和端口转发机制,使 Pod 内的 Docker 客户端能够连接到后端的 Docker 守护进程。
2.3.2 蓝盾流水线
- 第一步使用蓝盾 Checkout 插件拉取代码
- 第二步使用蓝盾 Shell Script 插件执行 docker 构建命令
docker context create dind --docker "host=tcp://bk-ci-docker-dinp.blueking.svc.cluster.local:2375,ca=/root/.docker/certs/ca.pem,cert=/root/.docker/certs/cert.pem,key=/root/.docker/certs/key.pem"
docker context use dind
docker build --platform=linux/amd64 -t ${IMAGE_REPO}:${IMAGE_TAG} -f Dockerfile . --push
3. 技术选型对比
特性/方案 | Kaniko | Dind Unix Socket | Dind TCP |
---|---|---|---|
依赖环境 | 不依赖 Docker 守护进程 | 依赖宿主机 Docker Socket | 依赖宿主机 Docker 守护进程(TCP) |
部署复杂度 | 简单,只需部署 Pod | 中等,需要配置 DaemonSet | 较复杂,需要配置 Deployment 和 Service |
资源消耗 | 低 | 中等 | 较高 |
安全性 | 高 | 中等 | 中等 |
适用场景 | Kubernetes 环境 | 单机或多节点集群 | 跨节点或 Kubernetes 集群 |
蓝盾集成难度 | 中等 | 低 | 中等 |
虽然我们最终选择了 Kaniko 方案,但在实际应用中发现,基于 m.daocloud.io/gcr.io/kaniko-project/executor:latest 制作的蓝盾 CI 镜像存在一些兼容性问题。根据 Kaniko 的官方文档,这种做法并不被推荐,可能会导致一些不可预见的问题。后续将根据蓝盾的官方文档和 Kaniko 的最佳实践,建议重新制作 CI 镜像。