news 2026/7/7 13:16:57

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

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
基于 Docker + GitLab + Kubernetes 的 CI/CD 流程实践

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

    • 一、 引言
    • 二、核心概念：CI 与 CD
      • 2.1 持续集成（Continuous Integration, CI）
        • 核心目标
      • 2.2 持续部署（Continuous Deployment, CD）
        • CD 核心价值
    • 三、 Docker + GitLab + Kubernetes 的 CI/CD 实践
      • 3.1 构建流程
        • 流程说明
      • 3.2 Docker部署 GitLab Runner
      • 3.3 配置与注册 GitLab Runner
        • 1. 获取注册 Token
        • 2. 填写 Tags
        • 3. 执行注册命令
        • 注册 gitlab runner
      • 3.4 编写 Dockerfile
      • 3.5 编写 CI/CD 流水线配置 (.gitlab-ci.yml)
      • 3.6 配置环境变量
      • 3.7 运行流水线

一、 引言

在现代软件工程中，构建高效、可靠的持续集成与持续交付（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 并触发流水线，以该标签作为镜像版本，依次执行构建 -> 部署，实现从代码到生产环境的自动化交付。

版权声明: 本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：809451989@qq.com进行投诉反馈，一经查实，立即删除！
网站建设 2026/7/6 10:03:41

10大关键指标评估YashanDB数据库性能表现

在现代企业信息系统中，数据库性能对业务响应速度和系统可用性具有决定性影响。YashanDB作为一款面向高性能和高可用的关系型数据库系统，其性能表现直接关系到实时数据处理和分析能力的有效实现。如何科学、全面地评估YashanDB的性能，确保系统…

作者头像 李华
网站建设 2026/7/7 6:36:36

一文搞懂 LLM 的 Transformer！看完能和别人吹一年

如果你想对当下 AI LLM(大语言模型) 的工作原理有所了解，揭开 ChatGPT、DeepSeek 背后的秘密，那一定要认识一下本文的主角 Transformer。当提起 Transformer 这个话题时，仿佛人人都可以讲些相关名词出来，什么自注意力机制啊、enco…

作者头像 李华
网站建设 2026/7/5 16:28:29

构建软件质量防线：测试缺陷的系统性预防措施

在快速迭代的软件开发环境中，缺陷发现得越晚，修复成本就呈指数级增长。研究表明，生产环境中发现的缺陷其修复成本是编码阶段发现的100倍以上。因此，现代软件测试已从单纯的缺陷检测向缺陷预防演进，致力于在缺陷产生前构…

作者头像 李华
网站建设 2026/7/5 19:01:04

构建高效可持续的自动化测试框架：从架构设计到落地实践

随着敏捷开发与DevOps实践的普及，自动化测试已成为保障软件质量的核心环节。2025年的今天，现代应用架构正朝着微服务、云原生和智能化的方向演进，这对测试框架的适应性、可维护性和扩展性提出了更高要求。一个设计良好的自动化测试框架不仅能…

作者头像 李华