企业官网建设流程全解析

说明

本文为真实服务器全流程部署、排错、优化、迭代实录，完整记录公司内部网络 Linux 服务器搭建 CI/CD AI 自动化代码审查平台的全过程。

涵盖基础环境初始化、依赖安装、GitLab-Runner 部署、Ollama 本地大模型部署、AI 审查服务部署、网络代理调试、服务自启配置、本地模型迭代切换远程阿里云大模型（Qwen3.6-Plus）、全链路问题踩坑与修复方案。

文档所有内容均为现场实操验证，包含完整命令、报错原因、解决方案、架构迭代记录，可作为项目长期运维、复盘、二次部署的标准手册。

一、服务器基础环境信息

1.1 硬件配置

• CPU：32 核高性能服务器
• 内存：125GiB 大内存
• 交换分区：无
• 显卡：无（原计划本地部署大模型，后改用远程模型，无需 GPU）
• 操作系统：Debian / Ubuntu 系列
• 默认 Python 版本：Python 3.13

1.2 网络与代理环境

服务器处于公司内部网络环境，通过企业网关统一访问互联网，所有互联网资源（软件包、依赖、远程大模型接口、工具插件等）必须通过全局 HTTP/HTTPS 代理访问；

同时严格配置no_proxy规则，保证本地回环地址、公司内部网络网段、内部服务地址不走代理，避免本地接口、公司内部网络服务请求、内部 GitLab 仓库被代理劫持、请求卡死、超时等问题。

业务需求特殊：服务需要双网络通路

1. 访问公司内部网络 GitLab：拉取 MR 代码、提交审查评论，禁止走代理
2. 访问互联网大模型：模型推理，必须走代理（初期尝试本地小模型效果不佳，后续切换为远程大模型）

1.3 最终上线服务清单

本次整套环境共部署三大核心服务，分工明确、链路串联：

1.4 架构迭代历程

┌─────────────────────────────────────────────────────────────────────┐ │ V1 版本架构（已弃用） │ ├─────────────────────────────────────────────────────────────────────┤ │ GitLab CI → Runner → AI审查服务 → 本地 Ollama(qwen2.5:7b) │ │ 痛点：纯 CPU 推理慢、审查效果差、占用大量资源 │ └─────────────────────────────────────────────────────────────────────┘ ↓ 升级迭代 ┌─────────────────────────────────────────────────────────────────────┐ │ V2 最终架构（生产可用） │ ├─────────────────────────────────────────────────────────────────────┤ │ GitLab CI → Runner → AI 审查服务(5001) → 阿里云 Qwen3.6-Plus │ │ 优势：释放本地算力、推理速度快、审查精度高、运维成本低 │ └─────────────────────────────────────────────────────────────────────┘

1.5 整体业务架构（改造后）

GitLab 代码仓库 MR/提交触发 CI/CD 流水线 ↓ GitLab Runner 接收任务、拉取项目代码 ↓ Runner 调用本地 AI 代码审查服务（5001 端口） ↓ AI-Review-Server 携带请求参数，转发至 远程 qwen3.6-plus 大模型接口 ↓ 远程大模型执行代码审查，返回审查结果 ↓ 结果原路回传：AI服务 → GitLab Runner → GitLab 流水线展示

二、服务器基础环境初始化（前置基础操作）

本节为部署所有服务前的通用环境准备，包含网络代理配置、系统更新、工具安装、基础依赖、常用运维插件安装，是整套环境运行的基础，所有操作按执行顺序记录。

2.1 全局网络代理配置（核心前置，重中之重）

服务器公司内部网络环境必须配置全局代理才能访问互联网，这是后续所有互联网下载操作的前提。同时强制本地/公司内部网络地址豁免代理，是解决接口卡死、请求超时的关键。

2.1.1 全局代理配置文件

配置文件路径：/etc/environment（系统级全局环境变量，所有用户、系统服务生效）

编辑文件：

vim/etc/environment

2.1.2 最终完整配置内容

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"# 互联网代理地址（根据现场实际代理IP、端口修改）http_proxy=http://your-proxy-ip:your-proxy-porthttps_proxy=http://your-proxy-ip:your-proxy-portall_proxy=socks5://your-proxy-ip:your-proxy-port# 兼容大写格式（部分软件/服务优先读取大写变量）HTTP_PROXY="$http_proxy"HTTPS_PROXY="$https_proxy"ALL_PROXY="$all_proxy"# 免代理规则：本地回环、IPv6、公司内部网络标准网段、公司内部网络GitLab地址# 禁止以上地址走互联网代理，防止本地服务请求被劫持no_proxy=localhost,127.0.0.1,::1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,your-gitlab-domain.comNO_PROXY="$no_proxy"

2.1.3 配置生效命令

修改/etc/environment后必须重载系统配置并重启服务器，否则代理不生效：

# 重载系统服务配置systemctl daemon-reload# 重启服务器（全局环境变量必须重启生效）reboot

2.1.4 代理临时测试命令

重启后验证代理与免代理规则是否正常：

1. 测试互联网连通（走代理）

curl-Ihttps://www.baidu.com

正常返回 HTTP 200 即为代理生效。

2. 测试本地地址（不走代理）

# 强制不走代理访问本地接口，避免代理劫持curl--noproxy"*"--connect-timeout5http://127.0.0.1:11434

可正常连接、无卡死即为no_proxy规则生效。

2.1.5 代理相关踩坑记录

2.2 系统更新与基础工具安装

代理配置完成并验证生效后，开始安装基础工具。

2.2.1 系统更新命令

# 更新软件源索引aptupdate# 升级系统已安装包（可选，生产环境按需执行）aptupgrade-y

2.2.2 安装运维必备工具

包含网络检测、端口监听、进程查询、文本编辑、解压工具等，后续排错、运维全程使用：

# 批量安装常用工具aptinstall-ycurlwgetgitvimnet-tools iproute2 procpsunziptarlsof

工具说明：

2.3 Python 基础环境与依赖前置处理

系统自带 Python 3.13，Debian/Ubuntu 高版本 Python 开启了系统环境保护机制，禁止直接在系统 Python 中安装第三方包，提前记录解决方案。

2.3.1 核心报错与通用解决方案

执行pip install时报错：externally-managed-environment

原因：系统 Python 受保护，防止破坏系统依赖。

统一解决方案：安装包时追加--break-system-packages参数，全局通用：

# 通用 pip 安装格式（后续所有Python依赖均使用此命令）pip3install包名 --break-system-packages# 示例：安装基础依赖pip3installflask requests python-dotenv openai --break-system-packages

三、历史服务：Ollama 本地大模型部署（原方案，现已弃用）

初期为实现本地代码审查，部署 Ollama 框架并运行qwen2.5:7b本地大模型，因纯 CPU 推理速度极慢、代码审查效果不佳，后续全面切换为远程qwen3.6-plus模型。

本节完整记录原部署流程、配置、自启、排错，作为环境历史留存。

3.1 Ollama 安装与本地模型拉取

3.1.1 官方一键安装命令

依托全局代理，执行官方安装脚本：

curl-fsSLhttps://ollama.com/install.sh|sh

3.1.2 拉取本地代码审查模型

# 拉取 qwen2.5:7b 模型ollama pull qwen2.5:7b

3.2 Ollama Systemd 开机自启配置

文件路径：/etc/systemd/system/ollama.service

作用：实现开机自启、进程异常自动重启、隔离代理影响。

3.2.1 完整服务配置文件

[Unit] Description=Ollama Local LLM Service After=network.target [Service] # 强制清空代理变量，彻底杜绝本地请求被代理劫持 Environment=no_proxy=127.0.0.1,localhost,0.0.0.0 Environment=NO_PROXY=127.0.0.1,localhost,0.0.0.0 Environment=HTTP_PROXY= Environment=HTTPS_PROXY= Environment=ALL_PROXY= # 监听所有网卡，允许公司内部网络访问 Environment=OLLAMA_HOST=0.0.0.0 ExecStart=/usr/local/bin/ollama serve User=root Group=root # 进程异常自动重启 Restart=always RestartSec=3 [Install] WantedBy=multi-user.target

3.2.2 Ollama 服务管理全套命令

# 重载Systemd配置（修改配置后必执行）systemctl daemon-reload# 启动服务 + 设置开机自启systemctl start ollama systemctlenableollama# 查看服务运行状态systemctl status ollama# 实时查看运行日志（排错核心命令）journalctl-uollama-f--no-pager# 查看11434端口监听状态（Ollama默认端口）ss-tuln|grep:11434# 停止/重启服务systemctl stop ollama systemctl restart ollama

3.3 Ollama 高频问题与解决方案

3.4 本地模型可用性验证

curl--noproxy"*"http://127.0.0.1:11434/api/tags

正常返回已下载模型列表，代表 Ollama 部署完成。

重要说明：当前业务已不再使用 Ollama 本地模型，该服务仅作为历史环境保留，可根据需求选择停止/保留。

四、AI 代码审查服务（ai-review-server）部署 + 改造对接远程 qwen3.6-plus

本服务为整套架构核心中转服务，基于 Flask 开发，原对接本地 Ollama，现已全面改造为对接远程 qwen3.6-plus 大模型。完整记录目录规划、依赖安装、配置文件修改、代码改造、自启配置、排错全流程。

4.1 服务基础信息

4.2 进入项目目录 & 安装 Python 全量依赖

4.2.1 进入工作目录

cd/path/to/your/ai-review-service

4.2.2 安装项目依赖

结合系统 Python 限制，统一使用--break-system-packages参数：

# 安装项目所需依赖：Flask、环境变量解析、OpenAI SDK、网络请求等pip3installflask python-dotenv requests openai --break-system-packages

4.2.3 OpenAI SDK 版本报错修复

报错：Client.__init__() got an unexpected keyword argument 'proxies'

原因：openai 2.x新版 SDK 已移除proxies初始化参数。

解决方案：删除代码中所有proxies=xxx相关配置，服务公司内部网络访问远程接口依赖系统全局代理，无需代码内单独配置代理。

4.3 环境变量配置文件.env（核心改造点：切换远程大模型）

文件路径：/path/to/your/ai-review-service/.env

原配置指向本地 Ollama，现修改为远程大模型接口，完整配置如下：

# ============ 远程大模型配置 ============ # 远程大模型鉴权密钥（根据实际密钥填写） OPENAI_API_KEY=your-llm-api-key # 核心改造：由本地127.0.0.1改为远程大模型接口地址 OPENAI_BASE_URL=https://your-llm-api-endpoint/v1 # 指定使用模型名称（根据实际模型填写） OPENAI_MODEL=qwen3.6-plus # ============ 业务配置 ============ # GitLab 鉴权Token（项目权限令牌，需赋予read_api权限） GITLAB_TOKEN=your-gitlab-access-token # GitLab 服务器地址 GITLAB_URL=https://your-gitlab-domain.com # 请求超时时间（秒） REQUEST_TIMEOUT=120

4.4 Systemd 开机自启配置

保证服务开机自动启动、异常自动重启，严格指定工作目录，避免启动失败。

4.4.1 服务配置文件

路径：/etc/systemd/system/ai-review.service

[Unit] Description=AI Code Review Service (Remote LLM) After=network.target [Service] # 智能代理分流：互联网模型走代理，公司内部网络GitLab不走代理 Environment=http_proxy=http://your-proxy-ip:your-proxy-port Environment=https_proxy=http://your-proxy-ip:your-proxy-port Environment=no_proxy=127.0.0.1,localhost,your-gitlab-domain.com,10.0.0.0/8,192.168.0.0/16 Environment=NO_PROXY=127.0.0.1,localhost,your-gitlab-domain.com,10.0.0.0/8,192.168.0.0/16 # 必须和项目实际目录一致，目录错误会直接启动失败 WorkingDirectory=/path/to/your/ai-review-service # 启动命令：调用系统Python3运行入口文件 ExecStart=/usr/bin/python3 app.py User=root Group=root # 关闭Python缓冲，日志实时输出 Environment=PYTHONUNBUFFERED=1 # 进程异常自动重启 Restart=always RestartSec=3 [Install] WantedBy=multi-user.target

4.4.2 AI 服务全套管理命令

# 修改配置后重载Systemdsystemctl daemon-reload# 启动服务 + 开机自启systemctl start ai-review systemctlenableai-review# 查看运行状态systemctl status ai-review# 实时查看服务日志（排错首选）journalctl-uai-review-f--no-pager# 停止/重启服务systemctl stop ai-review systemctl restart ai-review

4.5 AI 服务踩坑记录（实操问题）

4.6 服务连通性验证

# 本地测试接口连通性（忽略401鉴权，只要能通即服务正常）curlhttp://127.0.0.1:5001

五、核心架构迭代：本地模型升级为阿里云 Qwen3.6-Plus

5.1 迭代核心原因（真实业务痛点）

核心结论：本地qwen2.5:7b小模型能力不足，无法满足代码审查需求，具体表现如下：

本地小模型能力局限（模型本身能力不足，真实问题测试的效果不佳）：

• 无法检测硬编码密钥、密码泄露风险
• 无法识别 Token 传输安全漏洞
• 无法发现内存泄漏（监听未销毁）问题
• 无法预判空指针异常 NPE 风险
• 无法识别循环串行性能缺陷、代码重复异味

本质原因：7B 参数规模的小模型，在代码理解深度、推理能力、安全漏洞识别等方面存在天然局限性，纯粹是模型能力不足以支撑高质量代码审查需求。

5.2 远程模型核心信息

5.3 模型效果对比（真实实测）

┌──────────────────────────────────────────────────────────────────┐ │ 本地 qwen2.5:7b 效果（差） │ ├──────────────────────────────────────────────────────────────────┤ │ ❌ 仅检测基础语法、any类型、组件命名问题 │ │ ❌ 无安全漏洞、性能、内存、空指针检测能力 │ │ ❌ 推理速度慢，阻塞CI流程 │ └──────────────────────────────────────────────────────────────────┘ ↓ ┌──────────────────────────────────────────────────────────────────┐ │ 云端 qwen3.6-plus 效果（生产级） │ ├──────────────────────────────────────────────────────────────────┤ │ ✅ 拦截硬编码密钥、密码、Token泄露高危漏洞 │ │ ✅ 检测内存泄漏、事件监听未销毁问题 │ │ ✅ 检测空指针NPE风险、代码规范、类型安全 │ │ ✅ 识别代码异味、重复代码、性能缺陷 │ │ ✅ 区分P0阻塞级、P1优化级、P2建议级问题 │ │ ✅ 推理速度快，不阻塞CI流水线 │ └──────────────────────────────────────────────────────────────────┘

5.4 迭代后网络适配（终极智能分流）

最终实现完美双向通信：

AI服务调用互联网大模型 → 自动走代理 your-proxy-ip:your-proxy-port AI服务调用公司内部网络GitLab → 自动不走代理，直连访问，无劫持、无超时

六、GitLab Runner 部署与 CI/CD 流水线对接

GitLab Runner 作为 CI/CD 执行器，负责触发代码拉取、调用 AI 审查服务，是串联整个流程的入口，本节记录安装、注册、配置、排错全流程。

6.1 GitLab Runner 安装

依托全局代理，执行官方安装步骤：

# 1. 导入GitLab官方GPG密钥curl-L"https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh"|bash# 2. 安装 GitLab Runneraptinstall-ygitlab-runner

6.2 Runner 注册（关联公司内部网络 GitLab 项目）

注册命令需填写公司内部网络 GitLab 地址、注册令牌、Runner 标签、执行器等信息（信息从 GitLab 项目后台获取）：

gitlab-runner register

按交互式提示依次填写：

1. GitLab 实例 URL：公司内部网络 GitLab 地址
2. 注册令牌：项目/群组 Runner 令牌
3. Runner 描述：自定义名称（如：AI-Code-Review-Runner）
4. 标签（tags）：流水线匹配标签，用于任务调度
5. 执行器（executor）：选择shell（本地执行）

6.3 GitLab Runner 基础管理命令

# 查看Runner运行状态gitlab-runner status# 启停服务systemctl start gitlab-runner systemctl stop gitlab-runner systemctl restart gitlab-runner# 设置开机自启systemctlenablegitlab-runner# 查看Runner日志journalctl-ugitlab-runner-f--no-pager

6.4 流水线对接逻辑

1. GitLab 项目配置 .gitlab-ci.yml 流水线文件，配置触发规则、任务脚本 ↓ 2. 流水线任务触发后，Runner 拉取代码，调用 AI 审查服务接口 ↓ 3. AI 服务转发请求至远程 qwen3.6-plus 模型，获取结果后回传给 Runner ↓ 4. Runner 将审查结果展示在 GitLab 流水线日志中

6.5 GitLab Runner 核心踩坑记录

七、全服务日常运维检查手册（一键巡检命令）

整理日常维护、故障排查的全套巡检命令，按服务分类，运维人员可直接复制执行：

7.1 综合资源检查

# 查看CPU核心数nproc# 查看内存使用free-h# 实时进程资源监控top

7.2 Ollama 服务巡检（历史服务）

# 运行状态systemctl status ollama# 端口监听ss-tuln|grep11434# 最近20条日志journalctl-uollama-n20--no-pager# 实时日志journalctl-uollama-f--no-pager

7.3 AI 代码审查服务巡检（核心服务）

# 运行状态systemctl status ai-review# 实时日志（排错首选）journalctl-uai-review-f--no-pager# 端口监听ss-tuln|grep5001

7.4 GitLab Runner 巡检

# Runner状态gitlab-runner status# 服务状态systemctl status gitlab-runner# 实时日志journalctl-ugitlab-runner-f--no-pager

7.5 网络代理快速验证

# 互联网连通测试（走代理）curl-Ihttps://www.baidu.com# 本地接口免代理测试curl--noproxy"*"http://127.0.0.1:5001# 互联网模型连通性测试（替换为实际的大模型接口地址）curl-vhttps://your-llm-api-endpoint/v1

7.6 AI 服务接口测试

# 本地服务测试curl-XPOST http://127.0.0.1:5001/api/review\-H"Content-Type: application/json"\-H"token: test-token-123"\-d'{"content":"function test(){return 1;}"}'

八、全流程问题汇总表（核心踩坑清单）

九、架构总结、改造说明与运维优化建议

9.1 最终稳定架构

GitLab MR事件 → GitLab-Runner触发CI → AI审查服务(5001) → 远程 Qwen3.6-Plus 大模型 → 返回合规审查报告 → 合码门禁拦截/通过

9.2 当前整套架构优势

9.3 后续运维优化建议

9.4 整体结论

整套环境从服务器初始化、网络代理、基础工具、Python 依赖、Ollama 本地模型、AI 审查服务、GitLab Runner全流程部署完成，并完成本地模型 → 远程 qwen3.6-plus 模型的架构改造。

所有部署、改造过程中遇到的端口冲突、代理劫持、Python 依赖、服务自启、接口鉴权、模型性能、CI 超时等问题均已落地解决，整套服务运行稳定，可正式投入日常 GitLab 代码 MR/提交的自动化代码审查工作，本文可作为后续环境维护、复刻部署、问题排错的标准文档。

适用场景：Debian/Ubuntu 系列服务器部署 GitLab-Runner + AI 代码审查服务 + 远程大模型