胖厨胡学斌1. 容器化部署GLPI的必要性与优势
在当今IT资产管理领域，GLPI作为开源的IT服务管理(ITSM)解决方案已经获得了广泛应用。传统部署方式通常采用LAMP(Linux+Apache+MySQL+PHP)堆栈直接安装，但这种方式存在环境依赖复杂、迁移困难、版本隔离差等问题。容器化部署通过Docker技术将GLPI及其依赖环境打包成标准化单元，带来了革命性的部署体验提升。
从实际运维角度看，容器化部署GLPI最显著的优势体现在三个方面：
- 环境一致性：开发、测试、生产环境完全一致，避免"在我机器上能跑"的经典问题
- 快速部署：一条docker-compose命令即可完成全套环境搭建，部署时间从小时级降到分钟级
- 资源隔离：不同版本的GLPI可以并行运行，互不干扰，特别适合升级过渡期
重要提示：生产环境容器化部署前，务必做好数据备份。虽然容器本身是临时的，但应该通过volume持久化存储关键数据。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. GLPI 10到11的升级关键点解析
2.1 版本差异与兼容性检查
GLPI 11相比10系列在架构上做了重大改进，包括：
- 前端全面迁移到Twig模板引擎
- 移除对PHP 7.x的支持，最低要求PHP 8.0
- 数据库结构调整（新增了knowbase_item_types表等）
- 安全机制升级（CSP策略强化等）
升级前必须执行以下兼容性检查：
- 备份检查：确保有完整的数据库和文件系统备份
- 插件兼容性：使用
php bin/console glpi:plugin:list命令检查已安装插件 - 系统要求验证：
bash复制docker exec -it glpi php -v # 确认PHP版本≥8.0 docker exec -it glpi mysql --version # 确认MySQL≥5.7
2.2 容器化升级路径设计
推荐采用蓝绿部署策略完成升级：
- 保持GLPI 10容器继续运行（绿色环境）
- 并行部署GLPI 11容器（蓝色环境）
- 通过共享volume实现数据迁移
- 测试验证后切换流量
这种设计可以做到：
- 零停机升级
- 快速回滚能力
- 并行测试窗口
3. 详细升级操作指南
3.1 准备升级环境
首先准备docker-compose.yml文件，关键配置包括：
yaml复制version: '3.8'
services:
glpi11:
image: turgon37/glpi:11.0.0-1
ports:
- "8080:80"
volumes:
- glpi_data:/var/www/html
- glpi_plugins:/var/www/html/plugins
environment:
- GLPI_DB_HOST=db
- GLPI_DB_NAME=glpi
- GLPI_DB_USER=glpi
- GLPI_DB_PASSWORD=your_secure_password
db:
image: mysql:5.7
volumes:
- db_data:/var/lib/mysql
environment:
- MYSQL_ROOT_PASSWORD=root_password
- MYSQL_DATABASE=glpi
- MYSQL_USER=glpi
- MYSQL_PASSWORD=your_secure_password
volumes:
glpi_data:
glpi_plugins:
db_data:
3.2 数据迁移步骤
-
从GLPI 10导出数据：
bash复制docker exec -it glpi10_db mysqldump -u root -p glpi > glpi10_backup.sql -
导入到GLPI 11环境：
bash复制docker cp glpi10_backup.sql glpi11_db:/ docker exec -it glpi11_db mysql -u root -p glpi < /glpi10_backup.sql -
执行数据库升级脚本：
bash复制docker exec -it glpi11 php bin/console db:update
3.3 常见问题解决方案
问题1：升级后插件不工作
- 原因：插件未适配GLPI 11的Twig模板
- 解决：联系插件开发者获取兼容版本，或临时禁用插件
问题2：页面样式错乱
- 原因：浏览器缓存了旧版静态资源
- 解决：强制刷新缓存(Ctrl+F5)，或清理浏览器缓存
问题3：性能下降
- 原因：PHP OPcache未正确配置
- 解决：调整docker-compose中的PHP配置：
yaml复制environment: - PHP_OPCACHE_ENABLE=1 - PHP_OPCACHE_MEMORY_CONSUMPTION=128
4. 升级后验证与优化
4.1 基础功能验证清单
完成升级后，必须验证以下核心功能：
- 用户登录与权限系统
- 工单创建与流转
- 资产管理与关联
- 报表生成与导出
- 计划任务执行
建议创建测试用例表格：
| 功能模块 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 用户认证 | 使用不同权限账号登录 | 正确显示对应菜单 | ✅通过 |
| 工单系统 | 创建包含附件的工单 | 工单可被分配和解决 | ✅通过 |
4.2 性能调优建议
GLPI 11在容器环境中可通过以下配置提升性能：
-
PHP-FPM优化：
ini复制pm.max_children = 50 pm.start_servers = 5 pm.min_spare_servers = 2 pm.max_spare_servers = 10 -
MySQL优化：
sql复制SET GLOBAL innodb_buffer_pool_size=1G; SET GLOBAL query_cache_size=0; -
启用HTTP/2：
在Nginx反向代理配置中添加：nginx复制listen 443 ssl http2;
5. 生产环境运维实践
5.1 监控方案设计
推荐使用Prometheus+Grafana监控组合：
- 容器基础监控：cAdvisor收集容器指标
- 应用性能监控：PHP-FPM导出指标
- 业务监控：GLPI的API响应时间
示例告警规则：
yaml复制- alert: HighPHPErrorRate
expr: rate(php_fpm_errors_total[1m]) > 5
for: 5m
labels:
severity: critical
annotations:
summary: "High PHP error rate on {{ $labels.instance }}"
5.2 备份策略实施
必须建立完善的备份机制：
-
数据库每日全备：
bash复制docker exec -it glpi_db mysqldump -u root -p --single-transaction --routines --triggers glpi | gzip > glpi_$(date +%Y%m%d).sql.gz -
文件系统增量备份：
bash复制docker run --rm --volumes-from glpi -v /backup:/backup alpine tar cvfz /backup/glpi_files_$(date +%Y%m%d).tar.gz /var/www/html -
备份验证：定期执行恢复测试
6. 故障恢复与回滚方案
6.1 紧急回滚流程
当升级出现严重问题时，可按以下步骤回退：
-
停止GLPI 11容器：
bash复制
docker-compose stop glpi11 -
恢复数据库：
bash复制docker exec -i glpi10_db mysql -u root -p glpi < glpi_pre_upgrade.sql -
重启GLPI 10服务：
bash复制
docker-compose start glpi10
6.2 典型故障处理
案例1：升级后数据库连接失败
- 现象：GLPI页面显示"数据库连接错误"
- 诊断：
bash复制docker logs glpi11_db # 查看MySQL日志 docker exec -it glpi11_db mysql -u glpi -p # 测试连接 - 解决：检查环境变量中的数据库密码是否正确
案例2：页面部分功能缺失
- 现象：某些菜单项不显示
- 诊断：
bash复制docker exec -it glpi11 php bin/console glpi:diagnostic - 解决：重新运行数据库更新脚本
在实际操作中，我强烈建议先在测试环境完整演练整个升级过程。特别是对于大型部署（超过500个用户），应该进行负载测试，确保升级后系统性能满足要求。一个实用的技巧是：使用Apache Bench模拟用户请求，对比升级前后的性能指标：
bash复制ab -n 1000 -c 50 http://glpi11.example.com/
对于有定制开发的企业，需要特别注意检查所有自定义模板和插件是否兼容新版本。我们曾经遇到过一个案例：某企业自定义的报表插件因为调用了废弃的API，导致升级后整个报表模块不可用。这种情况下，最好的做法是在升级前与插件开发者确认兼容性，或者准备替代方案。