基于 Docker + GitLab + Kubernetes 的 CI/CD 流程实践

一、 引言

在现代软件工程中，构建高效、可靠的持续集成与持续交付（CI/CD）流水线是提升交付速度与保障系统稳定性的关键。本文将详细介绍如何利用 Docker、GitLab 与 Kubernetes（K8s）三大核心技术，构建一套端到端的自动化交付体系。通过容器化应用、代码托管与自动化流水线的深度集成，实现从代码提交到应用部署的无缝衔接，为团队提供可复现、可扩展且运维友好的开发运维体验。

二、核心概念：CI 与 CD

CI/CD 是 DevOps 文化的实践核心，旨在通过自动化手段加速软件交付周期，同时保障代码质量与发布安全性。它主要包含以下两个阶段：

2.1 持续集成（Continuous Integration, CI）

持续集成要求开发人员频繁地（通常每天多次）将代码变更合并到共享的主干分支。

核心目标

• 降低集成风险：尽早发现并解决代码冲突，避免“集成地狱”（Integration Hell）。
• 保障代码质量：每次提交自动触发构建和测试（单元测试、静态扫描），确保主干代码始终处于可编译、可运行的状态。

2.2 持续部署（Continuous Deployment, CD）

在持续交付的基础上，通过自动化流程将已通过测试的代码变更直接部署到生产环境，无需人工干预。

CD 核心价值

• 缩短交付周期：将功能上线时间从数天压缩至分钟级。
• 提升研发效能：让开发者从繁琐的部署工作中解脱，专注于业务逻辑创新。

三、 Docker + GitLab + Kubernetes 的 CI/CD 实践

3.1 构建流程

流程说明

1. 代码提交：开发人员将代码推送到 GitLab 仓库，触发预定义的 CI/CD Pipeline。
2. 镜像构建：GitLab Runner 根据项目中的 Dockerfile 构建应用镜像。
3. 镜像推送：GitLab Runner 将构建好的镜像推送到 Harbor 私有仓库。
4. 应用部署：GitLab Runner 调用 Kuboard 提供的 CI/CD 集成 API，更新 Kubernetes 中的 Deployment 镜像版本，触发滚动更新。

注：建议在构建镜像前加入单元测试或代码扫描步骤，以确保质量。

3.2 Docker部署 GitLab Runner

docker run -itd --restart=always --name gitlab-runner -v /home/gitlab-runner/config:/etc/gitlab-runner -v /var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner:latest

为了让 Runner 能够执行 Docker 命令（如 docker build），我们采用 Docker Socket Binding 模式。将宿主机的 docker.sock 挂载到容器内部，使 Runner 可以直接调用宿主机的 Docker 守护进程。

3.3 配置与注册 GitLab Runner

1. 获取注册 Token

进入GitLab 项目页面 -> 设置 (Settings) -> CI/CD -> Runner，点击“新建 Runner”或查看现有 Token。

2. 填写 Tags

设置 Runner 的标签（Tags），例如 assistant-runner。该标签将用于在.gitlab-ci.yml中指定特定的 Runner 执行任务。

3. 执行注册命令

注册 gitlab runner

进入容器并执行注册流程：

# 进入容器dockerexec-it gitlab-runnerbash# 注册runnergitlab-runner register

交互式配置说明：

1. URL: 填写 GitLab 实例的地址。
2. Token: 填写上一步获取的 Registration Token。
3. Description: 输入 Runner 的描述（如 assistant-runner-host）。
4. Tags: 输入标签（如 assistant-runner）。
5. Executor: 输入 docker。
6. Default Docker image: 输入 docker:24.0.5 (建议使用稳定的 Docker 版本镜像)。

注：若使用 docker 执行器并希望共享宿主机 Docker 环境，注册完成后需修改 /etc/gitlab-runner/config.toml，在 [runners.docker] 部分的 volumes 中添加 “/var/run/docker.sock:/var/run/docker.sock”，否则流水线中的 docker 命令将无法连接守护进程。

3.4 编写 Dockerfile

Dockerfile样例：

# 使用官方 Python 3.11 镜像作为基础镜像FROM python:3.11.13-slim# 设置工作目录WORKDIR /app# 设置环境变量ENVTZ=Asia/Shanghai# 安装系统依赖RUNapt-getupdate&&apt-getinstall-y --no-install-recommends\libaio1&&rm-rf /var/lib/apt/lists/*# 安装 Python 依赖COPY requirements.txt.RUN pipinstall--no-cache-dir -r requirements.txt&&\pip cache purge# 复制项目代码COPY..# 暴露服务端口EXPOSE7000# 运行服务启动脚本CMD["sh","run_container_server.sh"]

3.5 编写 CI/CD 流水线配置 (.gitlab-ci.yml)

.gitlab-ci.yml

stages: - build - deploy variables:# 镜像仓库地址HARBOR_URL:"xxx"# 服务名称/Deployment名称SERVICE_NAME:"xxx"# 完整的镜像地址IMAGE_FULL_NAME:"${HARBOR_URL}/xxx/${SERVICE_NAME}"before_script: -exportIMAGE_TAG="$CI_COMMIT_TAG"-echo"Current IMAGE_TAG is:$IMAGE_TAG"# 构建阶段build_image: stage: build image:# 基础镜像name: docker:29.1.2 pull_policy: if-not-present script:# 指定连接到本地的 Unix Socket 文件-exportDOCKER_HOST=unix:///var/run/docker.sock -echo"Logging into Harbor..."# 需要在 GitLab CI/CD Variables 中配置 HARBOR_USERNAME 和 HARBOR_PASSWORD- docker login -u"$HARBOR_USERNAME"-p"$HARBOR_PASSWORD""$HARBOR_URL"-echo"Building Docker image..."- docker build -t"${IMAGE_FULL_NAME}:${IMAGE_TAG}".-echo"Pushing Docker image..."- docker push"${IMAGE_FULL_NAME}:${IMAGE_TAG}"only: - tags# 需与之前定义的tag一致tags: - assistant-runner# 部署阶段deploy_k8s: stage: deploy image: curlimages/curl:8.11.1 script: -echo"Deploying to Kubernetes via Kuboard API..."# 需要在 GitLab CI/CD Variables KUBOARD_USERNAME，KUBOARD_ACCESS_KEY-|curl-X PUT\-H"content-type: application/json"\-H"Cookie: KuboardUsername=$KUBOARD_USERNAME; KuboardAccessKey=$KUBOARD_ACCESS_KEY"\-d"{\"kind\":\"deployments\",\"namespace\":\"xxx\",\"name\":\"${SERVICE_NAME}\",\"images\":{\"${IMAGE_FULL_NAME}\":\"${IMAGE_FULL_NAME}:${IMAGE_TAG}\"}}"\"http://xxxx"# 只需要在 tags 触发时执行only: - tags tags: - assistant-runner

3.6 配置环境变量

为了安全起见，敏感信息不应直接写在 YAML 文件中。请在GitLab 项目 -> 设置 -> CI/CD -> 变量 (Variables)中添加以下变量：

• HARBOR_USERNAME: Harbor 仓库用户名
• HARBOR_PASSWORD: Harbor 仓库密码
• KUBOARD_USERNAME: Kuboard 用户名
• KUBOARD_ACCESS_KEY: Kuboard 访问密钥

3.7 运行流水线

完成上述配置后，开发人员只需在本地打上 Git Tag 并推送：

gittag v1.0.0gitpush origin v1.0.0

GitLab 将自动识别 Tag 并触发流水线，以该标签作为镜像版本，依次执行构建 -> 部署，实现从代码到生产环境的自动化交付。