您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center 汽车系统工程   模型库  
会员   
   
企业架构方法与实践
7月27-28日 北京+线上
AI智能体开发技术实践
8月6-7日 上海+线上
敏捷测试-简单而可行
8月14-15日 北京+线上
     
   
 订阅
GitLab CICD全流程攻略:Runner 注册、项目 CI 搭建、触发规则配置,小白也能上手!
 
作者:SRE运维小张
  5   次浏览      1 次
 2026-7-27
 
编辑推荐:
本文主要详细介绍了GitLab CICD工具的安装和CICD流程的实现相关内容,希望对你的学习有帮助。
本文来自于微信公众号SRE运维小张,由火龙果软件Alice编辑推荐。

GitLab Runner 依托 GitLab CI/CD 场景,可快速落地CICD流程、低维护成本, 如果不想在多个工具间切换,且追求“一站式” 工作流,可以试试GitLab CICD流程配置。这篇文章详细介绍该工具的安装和CICD流程的实现

一、安装GitLab Runner

安装步骤:

# 下载安装包源
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh" -o script.rpm.sh
# 临时设置环境变量,强制指定为CentOS 7兼容模式(推荐)
os=el dist=7 bash script.rpm.sh

 


# 安装 GitLab Runner(与 CentOS 流程一致)
yum install gitlab-runner -y

 

# 启动并设置开机自启
systemctl start gitlab-runner
systemctl enable gitlab-runner
# 验证安装
gitlab-runner --version

二、注册GitLab Runner

Gitlab是v18.7版本,获取注册命令,在需要CI的项目里操作,如下图

注册Runner需注意:

1、GitLab 实例 URL 必须填写正确,URL 填写错误会导致「注册成功但 Runner 离线」,或「拉取代码时连接被拒绝」

2、标签(tags)的配置:作用是关联.gitlab-ci.yml 与runner的关键;标签不匹配会找不到对应的runner执行流水线作业,注册时标签与配置文件必须保持一致

3、执行器(Executor)的选择:优先贴合你的环境(新手推荐 Shell),不要选择不熟悉的执行器

4、维护备注(optional):可填可跳过,不影响功能,出现Enter optional maintenance note for the runner:提示时,直接按回车键跳过即可

注册完成,可以在页面Runner,看到可用的runner(类似于jenkins的slave节点)状态在线,表示注册正确

三、执行项目CI构建

GitLab CICD 提供配置规则和调度能力

GitLab Runner 负责实际执行构建、测试、部署等任务

整体CI构建逻辑:在项目app-demo-src里,配置项目代码app.py,通过Dockerfile去构建docker镜像,CI流水线放在.gitlab-ci.yaml文件里,通过GitLab Runner 执行安装-构建-部署,并启动docker镜像,最终展示结果。

步骤1、配置项目代码和CI文件

配置CI文件 .gitlab-ci.yaml

# 定义全流程三个阶段,按顺序执行:install → build → deploy

stages:

   - install # 阶段1:安装Python/Flask依赖,验证依赖可用性

   - build # 阶段2:验证应用语法,构建Docker镜像

   - deploy # 阶段3:本地停止旧容器,启动新构建的Docker镜像

# ==================== 阶段1:install(安装项目依赖) ====================

install_flask_deps:

   stage: install

   tags:

      - docker # 与你的GitLab Runner标签一致,无标签可删除该行

   cache:

      # 缓存依赖包,避免重复下载,提升CI效率

      paths:

            - ~/.cache/pip/

   script:

      - echo "===== 开始升级pip ====="

      - pip3 install --upgrade pip --user

      - echo "===== 开始安装Flask项目依赖 ====="

      - pip3 install --no-cache-dir -r requirements.txt --user

      - echo "===== 验证依赖安装结果 ====="

      - python3 -c "import flask; print('Flask依赖安装成功,版本:', flask.__version__)"

   artifacts:

      # 保存安装成功的依赖相关信息,供后续阶段使用(可选,提升容错性)

      paths:

         - requirements.txt

      when: on_success

      expire_in: 1 hour

# ==================== 阶段2:build(构建Docker镜像) ====================

build_flask_docker:

   stage: build

   tags:

      - docker

   # 依赖install阶段执行成功,才会运行该阶段(可选,增强流程连贯性)

   dependencies:

      - install_flask_deps

   script:

      - echo "===== 验证app.py语法正确性 ====="

      - python3 -m py_compile app.py # 编译检查语法,有错误则CI终止

      - echo "===== 开始构建Docker镜像 ====="

       # 构建Docker镜像,标签格式:镜像名:提交哈希(保证镜像唯一性,避免覆盖)

      - DOCKER_IMAGE_NAME="flask-app:${CI_COMMIT_SHA:0:8}" # 截取前8位提交哈希,简化标签

      - docker build -t ${DOCKER_IMAGE_NAME} .

      - echo "===== 为镜像添加latest标签,方便后续部署 ====="

      - docker tag ${DOCKER_IMAGE_NAME} flask-app:latest

      - echo "===== Docker镜像构建成功 ====="

      - docker images | grep flask-app # 打印镜像信息,确认构建结果

   artifacts:

   after_script:

# ==================== 阶段3:deploy(本地启动Docker镜像) ====================

deploy_flask_local:

   stage: deploy

   tags:

      - docker

   # 依赖build阶段执行成功,才会运行该阶段

   dependencies:

      - build_flask_docker

   # 仅在master/main分支执行部署(可选,可根据需求修改分支规则)

   only:

      - master

      - main

   script:

      - echo "===== 开始本地部署Flask应用 ====="

      - echo "===== 停止并删除已存在的同名容器(避免端口占用/冲突) ====="

      - CONTAINER_NAME="flask-container"

      - PORT_MAPPING="5000:5000" # 本地端口:容器端口,容器端口与Dockerfile一致

      # 容错处理:容器不存在时,停止/删除命令不报错

      - docker stop ${CONTAINER_NAME} || true

      - docker rm ${CONTAINER_NAME} || true

      - echo "===== 本地启动Docker容器 ====="

      # 后台启动容器,端口映射,使用latest镜像

      - docker run -d --name ${CONTAINER_NAME} -p ${PORT_MAPPING} flask-app:latest

      - echo "===== 验证容器运行状态 ====="

      - docker ps | grep ${CONTAINER_NAME} # 打印容器信息,确认启动成功

      - echo "===== 打印应用访问地址 ====="

      - LOCAL_IP=$(hostname -I | awk '{print $1}') # 获取本机局域网IP

      - echo "======================================"

      - echo "Flask应用本地部署成功!"

      - echo "本地访问地址:http://localhost:5000"

      - echo "局域网访问地址:http://${LOCAL_IP}:5000"

      - echo "容器名称:${CONTAINER_NAME}"

      - echo "镜像名称:flask-app:latest"

      - echo "======================================"

      - echo "===== 可选:查看容器实时日志(前20行) ====="

      - docker logs --tail 20 ${CONTAINER_NAME}

 

Dockerfile文件

# 基础镜像

FROM python:3.9-slim

# 工作目录

WORKDIR /app

# 复制依赖文件并安装

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

# 复制应用源码

COPY app.py .

# 暴露端口

EXPOSE 5000

# 启动命令

CMD ["python", "app.py"]

 

app.py 文件

from flask import Flask

app = Flask(__name__)

@app.route('/')

def hello():

       # 后续测试可修改此内容,验证流程闭环

      return "Hello Flask! 容器部署成功~"

if __name__ == '__main__':

       app.run(host='0.0.0.0', port=5000)

 

requirements.txt

flask==2.2.5

 

步骤2、修改app.py 文件后提交,则自动触发【构建-流水线】

CI构建部署结果:验证docker镜像正常生成并且启动完成;浏览器也正常访问到app.py的内容

构建的常见问题

1、Docker 命令权限错误(permission denied)

  1. # 若无docker权限组可以创建,按照如下方法给 gitlab-runner赋权限
  2. groupadd docker
  3. chown root:docker /var/run/docker.sock
  4. usermod -aG docker gitlab-runner
  5. systemctl restart gitlab-runner

 

2、相关python依赖要有执行命令权限,正常拉取到对应版本

3、访问端口避免被占用

4、镜像拉取过慢 / 超时:配置国内镜像加速器(如阿里云),修改/etc/docker/daemon.json后重启 Docker

四、GitLab CI是如何触发提交的?

GitLab CI 中 “提交代码触发构建” 的配置,是写在项目根目录的 .gitlab-ci.yml 文件 里的,默认情况下只要仓库里有这个文件,push 代码到仓库分支(比如 main/master)就会自动触发构建;如果需要自定义触发规则(比如只在特定分支提交时触发),可以通过配置only/except或rules来控制。

触发规则(only/except/rules)的配置位置,决定了它的作用范围,分两种情况:

1. 配置在文件最外层:全局生效(所有作业共用规则)

如果把触发规则写在.gitlab-ci.yml的最顶部(不属于任何作业),那这个规则会对所有阶段的所有作业生效。

示例(全局配置,所有作业只在main分支触发):

# 全局触发规则:所有作业共用

only:

   - main

stages:

   - install

   - build

   - deploy

2. 配置在某个作业内部:仅对该作业生效

如果不同阶段的作业需要不同的触发规则(比如deploy只在main分支触发,build在dev/main都触发),就把规则写在对应作业的配置块里,仅对这个作业生效。

示例(不同作业用不同规则):


stages:
   - install
   - build
   - deploy
# install阶段:dev/main分支都触发
install_flask_deps:
stage: install
tags:
   - docker
only:
   - dev
   - main
script:
   - pip3 install -r requirements.txt
# build阶段:dev/main分支都触发
build_flask_docker:
stage: build
tags:
   - docker
only:
   - dev
   - main
script:
   - docker build -t flask-app:${CI_COMMIT_SHA:0:8} .
# deploy阶段:仅main分支触发
deploy_flask_local:
stage: deploy
tags:
    - docker
only:
   - main
script:
   - docker run -d --name flask-container -p 5000:5000 flask-app:latest

若所有阶段的触发规则完全一致:配在文件最外层(全局)更简洁。

若不同作业需要不同触发逻辑(比如部署仅主分支触发):给对应作业单独配置规则。

五、总结

GitLab CI 与 Runner 的协作本质:GitLab CI 是流水线调度中心,Runner 是实际执行节点,二者通过以下流程实现自动化:

    1. 代码提交 / 合并请求触发流水线;
    2. GitLab 解析.gitlab-ci.yml配置,匹配带对应标签的 Runner;
    3. Runner 执行作业脚本(依赖安装、构建、部署等);
    4. 执行结果实时反馈至 GitLab,生成可视化报告。

GitLab Runner 是 GitLab CI/CD 落地的核心载体,从安装注册到流水线配置,关键在于「标签匹配准确、配置逻辑清晰、触发规则精准」。通过本文的实操步骤与避坑指南,可快速搭建自动化流水线,实现代码提交后的自动构建、测试、部署,有效提升开发效率与代码质量。实际应用中,可根据项目类型(多语言、多环境)灵活扩展配置,充分发挥 CI/CD 的自动化价值。

   
5   次浏览       1 次
相关文章

DevOps转型融入到企业文化
DevOps 能力模型、演进及案例剖析
基于 DevOps 理念的私有 PaaS 平台实践
微软开发团队的DevOps实践启示
相关文档

DevOps驱动应用运维变革与创新
运维管理规划
如何实现企业应用部署自动化
运维自动化实践之路
相关课程

自动化运维工具(基于DevOps)
互联网运维与DevOps
MySQL性能优化及运维培训
IT系统运维管理

最新活动计划
UAF架构体系与实践 7-23[北京]
SysML和EA系统设计与建模 7-16[深圳]
Spec 驱动开发(SDD)实战 7-28[北京]
AI辅助软件测试方法与实践 7-31[在线]
AI智能体开发技术实践 8-6[上海]
基于UML和EA系统分析设计 8-20[上海]
 
 
最新文章
DevOps 道法术器,立体化实施框架
DevOps 中高效测试基础架构的最佳实践
DevOps 在公司项目中的实践落地
如何基于 Kubernetes 构建完整的 DevOps 流水线
阿里云Kubernetes实战
最新课程
DevOps体系实践、工具与平台
基于Kubernetes的DevOps实践
互联网运维与DevOps
基于Kubernetes构建企业容器云
企业级DevOps工作体系与平台
更多...   
成功案例
北京 DevOps体系实践、工具与平台
神龙汽车 DevOps体系实践、工具与平台
中国移动通信 网络规划与管理
某航空公司 IT规划与企业架构
某金融公司 IT服务管理(ITIL V3)
更多...