企业官网建设流程全解析

干了这么多年网络运维，IP地址管理一直是个头疼事。子网越分越细，设备一多，Excel表格根本扛不住。后来接触了phpipam这个开源IPAM工具，算是彻底把这块理顺了。它不光能管IPv4/IPv6地址池，还能管VLAN、VRF、域和DNS，配合Docker部署，十来分钟就能跑起来一套可用的系统。这篇就是我把自己的部署流程重新整理了一遍，适合所有运维、网管和正在做网络自动化改造的朋友，跟着走一遍基本不会踩坑。

1. 为什么用Docker部署phpipam？先把方案想清楚

1.1 LNMP手搓部署的痛点

早年部署phpipam都是走LNMP路线，装Nginx、装PHP、装数据库、再手动改配置文件。听着不算难，真做起来全是坑。phpipam对PHP版本有要求，旧版跑在PHP 5.x上，新版需要PHP 7.4以上，不同版本之间的依赖还不太一样。数据库也一样，MySQL和MariaDB的兼容性差异会导致安装向导直接报错。

最难受的是迁移和升级。phpipam升级要替换代码文件、跑数据库更新脚本、改配置，中间哪一步没对齐，版本一升级就白屏。换一台机器更是要重新走一遍编译安装流程，耗时又容易出错。这种"能跑但不敢动"的状态，对需要长期维护的网络系统来说非常不友好。

1.2 容器化部署的收益

Docker化之后，phpipam的Apache+PHP环境全被打进镜像里，底层Web服务不用管了，我们只需要关心数据库容器和应用容器两个编排单元。第一次部署，从装依赖到页面打开，熟练的话十分钟以内。升级就更直接，拉一个新镜像、重建容器，数据和配置因为做了持久化不会丢，回滚也方便，保留旧镜像随时能退回去。

这个思路放到IPAM场景里特别合适。IPAM本身是基础设施工具，追求稳定和可复现，而不是天天折腾部署方式。Docker把环境差异全部封起来，开发环境、测试环境、生产环境跑的是同一个镜像组合，出问题的概率自然就低很多。

1.3 镜像选型：官方镜像、数据库版本怎么选

部署方案里最大的抉择就是用什么镜像。phpipam官方在镜像仓库维护了phpipam-www和phpipam-init两个镜像，前者是Web应用主体，后者负责初始化数据库。直接用官方镜像最省事，跟着官方版本走，补丁和修复都能第一时间同步到。

数据库这边，我的建议是选MariaDB而不是MySQL 8.x。phpipam对MySQL 8的兼容性虽然逐步在改善，但MySQL 8默认的caching_sha2_password认证插件和PHP旧版驱动之间经常出问题，需要额外指定认证插件才能连上，属于白踩坑。MariaDB完全兼容MySQL协议，轻量而且省心，容器化场景下性能差异也不明显。

2. 部署前的环境准备：目录、端口与依赖

2.1 宿主机要求和端口规划

phpipam对宿主机的要求不高，我拿2核4G的云主机跑过，带几百个C段地址消耗完全够。操作系统不限，Ubuntu和CentOS类的都可以，只要内核支持Docker就行。

端口方面，phpipam官方镜像默认监听80端口，宿主机如果已经有Nginx这类服务占用80，就把容器映射到8000或者别的端口。我的习惯是先用8000映射跑起来，验证完功能以后再在Nginx层做域名反代，统一走443入口。这样应用层环境和服务器的其他Web服务是隔离的，不用因为端口冲突折腾一通。

2.2 安装Docker与Compose

如果宿主机还没装Docker，直接装Docker Engine和Compose插件就可以。Ubuntu用apt装docker.io，一般会带docker compose命令；CentOS这边用dnf装docker-ce，再单独装docker-compose-plugin。装完确认一下版本：

docker --version docker compose version

这套流程里我用的是Compose来做编排。虽然也能用一行docker run把两个容器分别起起来，但Compose的好处是把数据库连接、环境变量、目录挂载、重启策略全部写在一个文件里，后续任何人拿到这份文件都能复现出一模一样的部署环境，这才是"快速部署"真正的含义。

2.3 规划数据和配置文件目录

持久化是Docker部署里最容易被忽略的点。phpipam有两部分数据必须保存：数据库文件，以及Web应用生成的配置文件。数据库文件由数据库容器管理，配置文件则是安装向导结束后写入Web容器里的config.php。如果只是把数据库目录做持久化而不管Web配置目录，数据库还在，配置丢了，容器重建以后照样要重新跑安装向导，等于白干。

我的目录规划是这样：

/opt/phpipam/ ├── www/ # Web配置目录 └── db/ # 数据库数据目录

两个目录都映射到宿主机，权限不用额外改，容器启动时会自己处理。这个规划的好处是备份太方便了，把整个/opt/phpipam目录打包，走到哪儿都能还原。

2.4 版本选择说明

镜像tag建议直接用latest，官方latest指向当前稳定版本。数据库镜像我用mariadb:10.8，这个版本比较稳，兼容性也好。如果你非要上MySQL，建议指定mysql:5.7而不是mysql:8.0，原因前面已经说过了，MySQL 8的认证方式对phpipam的PHP环境不太友好，没必要给自己找麻烦。

3. 完整部署流程：从docker-compose到首次登录

3.1 编写docker-compose.yml

我直接贴一份完整可用的编排文件，这个文件是我在实际环境中验证过的，可以直接抄作业：

services: phpipam-db: image: mariadb:10.8 container_name: phpipam-db environment: MYSQL_ROOT_PASSWORD: "your-strong-password" MYSQL_DATABASE: phpipam volumes: - /opt/phpipam/db:/var/lib/mysql restart: unless-stopped phpipam-web: image: phpipam/phpipam-www:latest container_name: phpipam-web ports: - "8000:80" environment: TZ: "Asia/Shanghai" IPAM_DB_HOST: phpipam-db IPAM_DB_PASS: "your-strong-password" IPAM_DB_NAME: phpipam volumes: - /opt/phpipam/www:/app depends_on: - phpipam-db restart: unless-stopped

几个关键点解释一下：IPAM_DB_HOST要填phpipam-db，这是Compose网络里的服务名，不要填localhost。填localhost的话，Web容器会去连自己容器内部的数据库，结果就是连接失败。IPAM_DB_PASS要和数据库容器的MYSQL_ROOT_PASSWORD保持一致，这是整个配置最要命的地方，两个值对不上，安装向导一步都走不下去。

Web容器的工作目录新版是/app，所以我把/opt/phpipam/www映射到/app。如果你用的是老版本镜像，内部路径可能是/var/www/html，映射目标要跟着改，否则配置文件写不进宿主机目录，重建容器就丢配置。

3.2 启动、检查、日志观察

文件保存为docker-compose.yml后，在同一个目录下执行：

docker compose up -d

参数-d是后台运行。第一次启动会拉取镜像，Mariadb镜像大概一两百兆，phpipam镜像两三百兆，网速正常的话两三分钟就能拉完。启动完先看容器状态：

docker compose ps

两个容器的状态都显示Up，基本上就成功了一半。然后再看一眼Web容器的日志：

docker compose logs phpipam-web -f

正常日志里能看到Apache和PHP-FPM启动的相关信息。如果这里报数据库连接错误，不用急，多半是环境变量的问题，先去把两个密码对上，再重启Web容器。

3.3 Web安装向导填写说明

容器起来以后，打开浏览器访问http://宿主机IP:8000。第一次访问会自动跳转到install目录，进入安装界面。这个步骤虽然简单，但有几个字段很容易填错：

数据库主机填phpipam-db，不是localhost也不是宿主机IP，因为Web容器和数据库容器在同一张Docker网络里，服务名才是正确的寻址方式。MySQL管理用户名默认是root，密码就是compose文件里MYSQL_ROOT_PASSWORD设置的密码。MySQL主机名和数据库名保持phpipam。填完点安装，页面会跑一堆数据库初始化动作，几十秒后显示安装完成。

注意：安装完成之后，一定要到Web容器里把/var/www/html/install目录删掉或者改个名。这个目录是安装向导程序的入口，不处理掉的话，系统会保留二次运行的入口，存在安全隐患，也容易误触发重新初始化。

3.4 首次登录与初始化配置

安装完成后返回到登录页，phpipam默认管理员账号是Admin，默认密码是ipamadmin。进去以后第一件事就是改管理员密码，这没什么好说的，基础设施类工具永远不要沿用默认口令。

然后建议做两件初始化配置：第一，把界面语言切换成中文，在用户设置里改掉，日常使用效率会高很多；第二，把时区确认一下，虽然容器已经设置了TZ环境变量，但phpipam应用层也会读自己的时区配置，因为我们的环境变量已经控制住了，基本不会再出现时间差8小时的问题。

接下来创建一个日常使用的管理员账号，不要所有人都拿Admin干活。Admin账号作为维护入口留在那里，普通运维账号按需分配权限，这样审计日志里才能分清谁做了什么操作。

4. 部署后的维护实战：备份恢复、升级与安全加固

4.1 备份恢复：数据库和配置文件同样重要

phpipam的所有数据都放在数据库里，IP段信息、子网划分、地址分配记录、VLAN配置全在里面。所以备份的核心就是数据库备份。我在宿主机上是这样做的：

docker compose exec phpipam-db mysqldump -uroot -p密码 phpipam > /opt/phpipam/backup/phpipam_$(date +%F).sql

加了Linux的crontab，每天凌晨跑一次，保留最近30天的备份文件。别光备份数据库，/opt/phpipam/www目录里的config.php也得一起备份。数据库恢复了但配置文件丢了，phpipam也不知道该连哪个数据库，还得重新走一遍安装向导，麻烦得很。所以我把整个/opt/phpipam目录作为备份单元，一张tar包解决：

tar czf phpipam_backup_$(date +%F).tar.gz -C /opt phpipam

恢复的时候更简单，先把容器停掉，把备份的数据库文件导回到数据目录，再恢复配置文件，然后重新启动容器，整个服务状态就和备份时一模一样。

4.2 镜像升级：先备份再重建

phpipam官方更新频率在活跃期不算低，功能迭代和安全修复都有。升级流程是稳妥第一：先做一次完整备份，然后拉新镜像：

docker compose pull docker compose up -d

Compose会对比镜像是否变化，有更新就重建对应容器。重建过程中数据库容器如果没换镜像，一般不会重启，数据不受影响；Web容器重建后配合挂载的配置文件，服务会自动恢复。升级完之后去后台跑一次系统检查，看看有没有需要执行的数据库更新脚本，有就点一下升级，整个升级过程就结束了。

如果升级完发现有问题，回滚也简单，把compose文件里Web镜像的tag指回旧版本，或者干脆用之前跑着的镜像tag重新up，数据不受影响，服务就回去了。这套机制就是容器化最大的好处，放在以前，想回滚一次LNMP升级，工程量巨大。

4.3 安全加固：三个必做动作

第一件，强制修改所有账号的初始密码，包括数据库root密码和phpipam管理账号密码。数据库root密码在生产环境尤其重要，因为web容器是拿root连数据库的，密码一旦泄露，整个地址池数据就会被拖走。

第二件，把Web端口收回到内部。现在是8000直接暴露在宿主机上，如果你有边缘防火墙，把8000限制成只允许内网访问，外部用户通过Nginx反代统一走443。Nginx里把代理请求转发给容器的8000端口，再配一套证书就好了。这样既不用改容器配置，又实现了HTTPS加密访问。

第三件，禁用install目录。前面说过安装完成后要删掉，这里再强调一次：有些人在容器里删了，但容器一重建，install目录又从镜像里恢复了，所以最佳方式是在挂载目录里确认install目录不存在，因为挂载目录会覆盖镜像原始目录，这样重建多少次都不会再出现。

4.4 常用维护命令速查

日常巡检最常用的命令就这几个：

# 查看服务状态 docker compose ps # 查看Web容器日志 docker compose logs -f phpipam-web # 重启Web容器 docker compose restart phpipam-web # 进入容器调试 docker compose exec phpipam-web sh # 查看数据库数据目录大小 du -sh /opt/phpipam/db

注意restart命令只是重启容器，不会重新读取compose文件的配置修改。要是改了端口、环境变量这类配置，得用up -d重建容器才能生效。这个坑我踩过一次，改完端口重启半天不生效，最后才发现是没用对命令。

5. 常见问题排查与避坑实录

5.1 页面打不开或一直转圈

容器状态明明正常，但浏览器访问8000端口就是打不开，先确认防火墙和安全组是不是放通了端口。云主机的话要去控制台看安全组规则，本地机器要检查firewalld或者iptables。还有一种情况是端口被占用了，docker compose启动时报错会提示端口冲突，把映射端口换一个就行。

如果页面能打开但一直是加载状态，多半是容器内PHP执行卡住了，看Web容器日志，如果有内存不足类的错误，就检查宿主机可用内存。phpipam本身不占资源，但有几十万条IP记录时页面查询会吃一点内存，给容器加上内存限制反而会触发异常，建议让容器默认调度即可。

5.2 数据库连接失败的四类原因

数据库连接失败是部署中最常见的问题，飞出的报错基本是"Unable to connect to database"或类似的提示。我总结了一下，四类原因最常见：

第一类，IPAM_DB_HOST写错，填了localhost。在容器场景里，localhost只指向容器自己，必须填Compose服务名phpipam-db。

第二类，密码不对。IPAM_DB_PASS和MYSQL_ROOT_PASSWORD不一致，把两个值改成一样就能解决。改完以后要重新跑Compose配置，纯restart不生效。

第三类，数据库容器没起来。查看phpipam-db容器日志，如果MYSQL_ROOT_PASSWORD为空或者初始化的数据目录已经有残留数据但密码不匹配，数据库会拒绝启动。把挂载的/opt/phpipam/db目录清空再重建，就能重新初始化。

第四类，数据库版本认证方式问题。如果你用了MySQL 8.0，PHP驱动连不上caching_sha2_password认证，要么换MariaDB，要么给MySQL容器加启动参数指定mysql_native_password。

5.3 容器重建后数据丢失

这是典型的持久化没做全。很多教程只让挂载数据库目录，却忽略了Web配置目录。数据库好了，配置丢了，重新进install目录，向导又让你从头填一遍，不知道的话还以为数据没了。

正确做法就是前面说的，两个目录都挂载出来。检查一下当前挂载配置，如果Web容器没挂/opt/phpipam/www，改完compose文件重建一下容器，以后就不会再发生这种事了。

5.4 时区显示异常

部署完打开phpipam，发现时间记录和本地时间差了几个小时，十有八九是TZ环境变量没设置。容器默认时区是UTC，直接加TZ: "Asia/Shanghai"到Web容器的environment里，然后重建容器。phpipam的Web界面时区设置也最好配合改成Asia/Shanghai，两层一致才不会有跳变。

5.5 问题排查速查表

6. 一点使用心得

这套部署方式我用了很长时间，最大的体会就是：快速部署的底气不是命令背得熟，而是方案里把该存的数据都存住了，把会变的配置都写清楚了。phpipam+Docker这套组合，真正让我省心的是可复现性，一份compose文件加上两个目录，走到哪儿都能把环境拉起来，再也不用担心哪台机器上的PHP包改了导致系统跑不动。

最后分享一个小技巧：phpipam容器跑起来以后，建议顺手把登录页上显示"默认密码"的提示关掉。这个提示在系统设置里能关，关掉之后就不会每次登录都提醒一遍，也更安全。另外一个容易被忽略的点，是phpipam支持API接口，部署完成以后可以去后台把API模块启用，后面做CMDB同步、设备自动发现，都有现成通道，不用再手工导来导去。如果你正在搭建网络自动化体系，这套Docker化的phpipam可以当作一个很好的起点。