GLPI 10.0.18实战5分钟搞定K8s部署与Ingress配置含避坑指南如果你正在寻找一个能打通IT资产管理、服务台工单和CMDB配置的开源解决方案GLPI大概率已经进入了你的视野。但当你兴冲冲地打开官方文档准备在Kubernetes里大展拳脚时可能会发现事情没那么简单官方没有提供容器镜像Helm Chart是社区维护的Ingress配置和持久化存储的选择也藏着不少“坑”。这篇文章就是为你准备的。我们不谈那些泛泛而谈的安装步骤而是聚焦于如何在生产级的K8s环境中用声明式的方式快速、稳定地部署GLPI 10.0.18并分享那些官方手册里不会告诉你的实战细节和优化技巧。目标很简单让你在喝杯咖啡的时间里就拥有一个可用的、配置得当的GLPI实例。1. 部署前奏理解架构与准备战场在动手敲下kubectl apply之前花几分钟理解GLPI在Kubernetes中的运行形态至关重要。这能帮你避开后续许多因“想当然”而导致的配置错误。GLPI本质上是一个经典的LAMPLinux, Apache, MySQL, PHP应用。在K8s世界里我们需要将其解耦并容器化Web层运行Apache和PHP的容器负责处理HTTP请求和运行业务逻辑。数据层MySQL或MariaDB数据库用于存储所有配置、资产数据和工单信息。强烈建议将其与Web层分离使用独立的、有状态的服务如云厂商的托管数据库服务或通过StatefulSet部署的数据库。存储层GLPI需要持久化存储来保存上传的文件如工单附件、会话数据以及可能生成的报告。这部分必须通过PersistentVolumePV和PersistentVolumeClaimPVC来保障。对于本次部署我们将采用一个广受社区认可的第三方Helm Chart。虽然它不是官方出品但经过了大量用户的实践检验并且其维护者积极跟进GLPI的版本更新。使用Helm能让我们通过一份values.yaml文件集中管理所有配置实现部署的版本化和可重复性。注意由于GLPI官方不提供容器镜像选择可靠的第三方镜像源是第一步。建议优先选择Docker Hub上星标Stars高、更新频繁的镜像并检查其Dockerfile是否基于安全的基础镜像如php:8.2-apache构建。在开始前请确保你的K8s集群环境已就绪# 检查集群节点状态 kubectl get nodes # 确保Helm已正确安装并添加了所需的仓库 helm version # 添加包含GLPI Chart的仓库这里以某个社区仓库为例实际操作时请替换为可靠的仓库地址 helm repo add glpi-repo https://charts.你的可靠源.com helm repo update2. 核心部署Helm Chart参数精讲与定制我们假设你已经找到了一个名为glpi的Helm Chart。直接helm install是最简单的但想要一个适合生产的部署必须深入定制values.yaml。下面我们拆解几个最关键的配置部分。镜像与版本控制这是最容易出错的地方。在values.yaml中你需要明确指定镜像仓库、标签以及拉取策略。image: repository: username/glpi # 替换为实际可用的镜像仓库 tag: 10.0.18 # 明确指定版本避免使用latest标签 pullPolicy: IfNotPresent为什么不用latest在生产环境中使用latest标签会导致版本不可控升级和回滚变得困难。明确指定版本号是运维的基本素养。资源请求与限制Resources不给容器设置资源限制就像在高速公路上开车不限速迟早会出问题。合理的资源配置能保证应用稳定并避免单个Pod耗尽节点资源。resources: requests: memory: 512Mi cpu: 250m limits: memory: 1Gi cpu: 500m这个配置为GLPI的Web容器申请了0.25核CPU和512MB内存的初始资源并设置了最高0.5核CPU和1GB内存的使用上限。你需要根据实际访问量和集群规模进行调整。环境变量配置GLPI的许多行为通过环境变量控制。以下是一些必备和推荐的设置env: - name: GLPI_DB_HOST value: glpi-mysql # 假设数据库Service名称为glpi-mysql - name: GLPI_DB_NAME value: glpi - name: GLPI_DB_USER valueFrom: secretKeyRef: name: glpi-secrets key: db-user - name: GLPI_DB_PASSWORD valueFrom: secretKeyRef: name: glpi-secrets key: db-password - name: GLPI_CRONJOBS_ENABLED value: true # 启用后台计划任务如邮件通知、自动发现等安全最佳实践像数据库密码这样的敏感信息绝对不要明文写在values.yaml里。务必使用Kubernetes Secret来管理。你可以通过kubectl create secret generic glpi-secrets --from-literaldb-passwordyour-strong-password来创建。持久化存储配置GLPI的files/_目录上传文件、config目录部分配置和会话数据需要持久化。在values.yaml中配置PVCpersistence: enabled: true accessMode: ReadWriteOnce size: 10Gi storageClass: standard # 指定你的StorageClass例如SSD、高性能云盘等storageClass的选择取决于你对磁盘性能和成本的要求。如果集群支持动态卷供应Dynamic Volume Provisioning上述配置会自动创建对应的PV和PVC。3. 网络暴露Ingress配置详解与TLS终结部署完成后Pod在集群内部。我们需要通过Ingress将其安全地暴露给外部用户。这里我们以最流行的Nginx Ingress Controller为例。基础Ingress配置首先在values.yaml中启用并配置Ingressingress: enabled: true className: nginx # 指定Ingress Class与你的Ingress Controller匹配 hosts: - host: glpi.your-company.com # 你的域名 paths: - path: / pathType: Prefix tls: - secretName: glpi-tls-secret # TLS证书的Secret名称 hosts: - glpi.your-company.com这段配置创建了一个Ingress规则将所有发送到glpi.your-company.com的HTTP/HTTPS流量路由到GLPI的Service。TLS证书管理生产环境必须使用HTTPS。你可以从证书颁发机构CA购买证书或使用Let‘s Encrypt免费自动签发。使用Cert-Manager是自动化管理证书的黄金标准。安装Cert-Manager如果尚未安装kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.2/cert-manager.yaml创建一个ClusterIssuer以Let‘s Encrypt为例apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: letsencrypt-prod spec: acme: server: https://acme-v02.api.letsencrypt.org/directory email: your-emailexample.com privateKeySecretRef: name: letsencrypt-prod-account-key solvers: - http01: ingress: class: nginx修改GLPI的Ingress配置添加注解以触发证书签发ingress: enabled: true className: nginx annotations: cert-manager.io/cluster-issuer: letsencrypt-prod # 指向刚才创建的Issuer hosts: - host: glpi.your-company.com paths: - path: / pathType: Prefix tls: - secretName: glpi-tls-secret # Cert-Manager将自动创建这个Secret hosts: - glpi.your-company.com应用配置后Cert-Manager会自动完成域名验证、申请并续签证书全程无需人工干预。高级Ingress调优对于高并发场景你可能需要调整Nginx Ingress的参数。这可以通过Ingress的注解Annotations实现ingress: enabled: true className: nginx annotations: nginx.ingress.kubernetes.io/proxy-body-size: 50m # 允许上传最大50MB的文件 nginx.ingress.kubernetes.io/proxy-read-timeout: 300 # 后端超时时间设为300秒 nginx.ingress.kubernetes.io/proxy-send-timeout: 300 nginx.ingress.kubernetes.io/configuration-snippet: | client_header_buffer_size 64k; large_client_header_buffers 4 128k; # 处理可能过大的Cookie或Header这些调整能更好地适配GLPI处理大文件上传或长时间操作如资产导入的需求。4. 避坑指南从部署到生产的常见问题即便按照最佳实践操作在实际部署中依然可能遇到一些“坑”。下面是我在多次部署中总结出的高频问题及其解决方案。坑一首次访问出现“无法连接到数据库”错误现象Pod运行正常Ingress配置无误但打开页面提示数据库连接失败。排查检查数据库Pod/Service是否正常运行kubectl get pods -l appmysql。检查GLPI Pod内的环境变量是否正确注入kubectl exec glpi-pod-name -- env | grep GLPI_DB。手动从GLPI Pod内测试数据库连通性kubectl exec -it glpi-pod-name -- bash apt-get update apt-get install -y mysql-client # 如果Pod内没有mysql客户端 mysql -h db-service-name -u username -ppassword db-name解决最常见的原因是数据库初始化未完成。MySQL容器首次启动时需要时间初始化数据。确保在部署GLPI Chart时通过initContainers或postStart钩子等待数据库就绪后再启动GLPI应用。许多成熟的Chart已经内置了此逻辑。坑二文件上传失败或附件无法查看现象工单可以创建但上传附件时报错或上传后无法显示。排查检查持久化存储卷PVC是否成功挂载且权限正确kubectl exec glpi-pod-name -- ls -la /var/www/html/files/_。该目录应对Apache用户通常是www-data可写。检查PHP配置中的上传文件大小限制upload_max_filesize和post_max_size。这需要在GLPI的PHP容器中调整php.ini或通过.htaccess文件设置。解决权限问题确保PV的存储类支持正确的文件权限。有时需要在Pod的securityContext中设置fsGroup让Pod以特定组ID运行从而拥有存储卷的写入权限。securityContext: fsGroup: 33 # 33通常是www-data用户的组IDPHP配置通过ConfigMap覆盖默认的PHP配置# 创建一个包含自定义php.ini片段的ConfigMap apiVersion: v1 kind: ConfigMap metadata: name: glpi-php-config data: custom-php.ini: | upload_max_filesize 50M post_max_size 55M max_execution_time 300然后在Deployment中将此ConfigMap挂载到容器的/usr/local/etc/php/conf.d/目录。坑三后台计划任务Cron不执行现象自动发现网络设备、发送邮件通知等依赖Cron的任务没有自动运行。原因GLPI容器内没有运行Cron守护进程或者Cron配置不正确。解决有两种主流方案。方案A在容器内运行Cron。修改Dockerfile安装并配置cron将GLPI的CLI命令添加到crontab。但这种方法违背了容器“单进程”的最佳实践且日志管理不便。方案B推荐使用Kubernetes CronJob。这是更云原生的方式。创建一个独立的CronJob资源定期启动一个执行GLPI CLI命令的临时Pod。apiVersion: batch/v1 kind: CronJob metadata: name: glpi-cron spec: schedule: */5 * * * * # 每5分钟执行一次 jobTemplate: spec: template: spec: containers: - name: glpi-cli image: username/glpi:10.0.18 # 使用与主应用相同的镜像 command: [php, /var/www/html/bin/console, glpi:task:watcher] envFrom: - secretRef: name: glpi-secrets # 复用数据库连接等环境变量 restartPolicy: OnFailure这个CronJob会每5分钟运行一次GLPI的任务监视器。你可以根据需要创建多个CronJob来执行不同的命令如glpi:inventory:xml处理资产清单。坑四性能缓慢页面加载时间长现象访问GLPI界面特别是报表或资产列表页面时响应很慢。排查与优化数据库索引GLPI的某些表在数据量增大后缺乏有效索引。需要连接数据库分析慢查询日志并为频繁查询的字段如glpi_tickets.dateglpi_computers.name添加索引。操作前务必在测试环境验证。PHP OPcache确保PHP的OPcache已启用并合理配置这能极大提升PHP脚本的执行速度。同样通过ConfigMap调整opcache.enable1等参数。K8s资源不足检查Pod的CPU和内存使用率kubectl top pods。如果持续接近限制limit考虑适当调高limits或优化应用本身。考虑读写分离对于超大规模部署可以考虑配置数据库的主从复制将报表类的读操作指向从库。5. 进阶运维监控、备份与客户端集成部署稳定只是第一步让GLPI在生产环境中持续、可靠地运行并发挥其最大价值还需要以下运维手段。监控与告警你需要知道GLPI是否健康。除了K8s自带的基础监控Pod状态、资源使用率还应关注应用层指标。应用健康检查在Deployment中配置livenessProbe和readinessProbe让K8s能自动判断应用状态并重启不健康的Pod。livenessProbe: httpGet: path: / port: http initialDelaySeconds: 120 # GLPI启动较慢延迟检查 periodSeconds: 10 readinessProbe: httpGet: path: / port: http initialDelaySeconds: 30 periodSeconds: 5业务指标监控在GLPI容器中部署一个Sidecar容器如Prometheus Node Exporter的特定变体或利用GLPI可能提供的健康检查端点将自定义指标如活动会话数、待处理工单数暴露给Prometheus再通过Grafana制作仪表盘。数据备份策略GLPI的核心是数据。备份必须覆盖数据库和持久化文件。数据库备份对于云托管数据库使用其自带的时间点恢复和备份功能。对于自建MySQL可以运行一个定期备份的CronJob将mysqldump的结果上传到对象存储如S3。# 一个简单的备份CronJob示例需配置S3访问密钥等 apiVersion: batch/v1 kind: CronJob metadata: name: glpi-db-backup spec: schedule: 0 2 * * * # 每天凌晨2点 jobTemplate: spec: template: spec: containers: - name: backup image: amazon/aws-cli # 或其他包含mysql-client和aws-cli的镜像 command: - /bin/sh - -c - | mysqldump -h $DB_HOST -u $DB_USER -p$DB_PASSWORD $DB_NAME | gzip /backup/glpi-$(date %Y%m%d).sql.gz aws s3 cp /backup/glpi-$(date %Y%m%d).sql.gz s3://your-backup-bucket/glpi/ env: - name: DB_HOST valueFrom: {...} # ... 其他环境变量和卷挂载 restartPolicy: OnFailure文件备份持久化卷PV中的文件同样重要。如果使用云存储可以配置存储卷的快照Snapshot功能。也可以使用类似rclone的工具在CronJob中将文件同步到远程存储。客户端自动部署与资产管理GLPI的强大之处在于其资产发现和管理能力。这依赖于在目标机器上安装GLPI Agent。大规模部署在Windows域环境中最优雅的方式是使用组策略GPO进行软件分发。你需要准备一个经过定制的MSI安装包将GLPI服务器的地址参数预先配置好。文中提到的使用Advanced Installer等工具修改MSI包属性如SERVER参数的方法是标准做法。无域环境可以考虑使用像Ansible、SaltStack这样的配置管理工具或者利用现有的终端管理系统如SCCM、Jamf来推送和安装Agent。Agent配置除了服务器地址Agent还支持配置扫描间隔、包含/排除的目录、代理服务器等。这些可以通过修改Agent的配置文件通常为.cfg或.ini格式来实现并随安装包一同分发。最后别忘了GLPI的插件生态。市场上有许多优秀的插件可以扩展功能如与监控系统Zabbix、Nagios的深度集成、增强的报表功能等。在K8s中部署插件通常意味着需要将插件文件放入GLPI的持久化存储卷的plugins目录并确保Web Pod有相应的读取权限然后在GLPI管理界面中启用它。整个过程可以通过一个初始化容器Init Container来完成插件的下载和放置实现自动化。