灯塔ARL V2.6.2 docker-compose部署实战：避坑指南与多环境隔离

简介：灯塔ARL资产侦察系统V2.6.2配套部署资料，面向安全团队成员、渗透测试人员及个人安全研究员，帮助其快速搭建一套可用的互联网资产侦察与监控平台。系统支持域名资产发现、IP/IP段整理、端口扫描与服务识别、站点指纹识别、资产分组管理、计划与周期任务，以及域名/IP监控、站点变化监控、文件泄漏检测，并可集成nuclei PoC与WebInfoHunter等工具。资源包共1个文件，为631KB的PDF文档，内容围绕Docker环境准备、镜像加速器配置、docker-compose一键部署与容器运行展开，并针对Docker Hub受限后的镜像源替换给出具体思路。目前已有2750人学习，适合希望低成本落地资产侦察能力、快速排查薄弱点与攻击面的读者参考。

1. 灯塔ARL V2.6.2 部署实录：为什么我放弃了裸机安装，改用 docker-compose

上周帮一个做企业内网巡检的朋友搭资产侦察环境，他之前用源码方式装灯塔ARL，光 Python 依赖冲突就折腾了一下午，最后卡在某个 C 扩展编译报错上。我直接甩给他一份 docker-compose 编排文件，十分钟后服务起来了。这就是今天要聊的主角——灯塔ARL资产侦察系统 V2.6.2，以及它最省心的落地方式：docker-compose 一键部署。

灯塔ARL 本质是一套面向企业资产发现与风险摸排的自动化侦察平台，核心能力覆盖子域名枚举、端口扫描、服务识别、指纹匹配、URL 爬取等环节，把原本散落在各个脚本里的侦察动作串成一条流水线。V2.6.2 这个版本在任务调度和插件稳定性上做了不少修补，适合安全工程师、渗透测试从业者、运维巡检人员拿来快速摸清一个网段的暴露面。如果你正在找一份能直接抄作业的 docker 灯塔ARL 保姆级部署教程，下面从环境准备到排错一条龙走完。

2. 部署前的地基：环境检查与镜像加速配置

2.1 硬件与系统的最低门槛

灯塔ARL 跑起来不算轻，因为它内部集成了多个扫描器和数据库。我实测下来，最低配置给 2 核 4G 内存能启动，但一旦并发任务超过三个，内存直接飙到 3.5G 以上，系统开始频繁触发 OOM Killer。所以生产环境建议 4 核 8G 起步，磁盘预留 50G 以上，因为扫描结果、截图、日志都会往本地存。

操作系统层面，Ubuntu 20.04/22.04 LTS 和 CentOS 7.9 是社区反馈最稳的两个选择。内核版本建议 4.x 以上，否则 docker 的 overlay2 存储驱动可能出问题。检查命令很简单：

# 查看内核版本 uname -r # 查看内存和磁盘 free -h df -h /var/lib/docker

逻辑说明：uname -r确认内核是否支持 overlay2；free -h看可用内存，注意要留出至少 1G 给系统本身；df -h确认 docker 数据目录所在分区有足够空间。如果/var/lib/docker分区小于 30G，建议提前挂载新盘或修改 docker 的># 卸载旧版本 sudo apt-get remove docker docker-engine docker.io containerd runc # 安装依赖 sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg lsb-release # 添加 docker 官方 GPG key sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # 添加源 echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null # 安装 docker 和 compose 插件 sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

参数说明：--dearmor把 ASCII 格式的 key 转成二进制，避免 apt 报NO_PUBKEY；docker-compose-plugin装完后命令是docker compose（中间有空格），不是老的docker-compose。如果你习惯用连字符版本，可以额外装docker-compose二进制，但灯塔ARL 的文档里两种写法都兼容。

2.3 镜像加速与 daemon 配置

国内拉取 docker hub 镜像的速度是玄学，有时候一个 800M 的镜像能卡二十分钟。配置镜像加速器是部署前必须做的一步，不然后面docker compose up会等到怀疑人生。

# 创建或修改 daemon.json sudo tee /etc/docker/daemon.json <<-'EOF' { "registry-mirrors": [ "https://docker.m.daocloud.io", "https://dockerproxy.com", "https://mirror.baidubce.com" ], "log-driver": "json-file", "log-opts": { "max-size": "100m", "max-file": "3" }, "data-root": "/var/lib/docker" } EOF # 重载配置并重启 sudo systemctl daemon-reload sudo systemctl restart docker sudo systemctl enable docker

逻辑说明：registry-mirrors数组里可以放多个加速地址，docker 会按顺序尝试；log-opts限制单个容器日志文件最大 100M、最多保留 3 个，防止灯塔ARL 跑久了把磁盘写满；>version: "3.8" services: mongodb: image: mongo:4.4 container_name: arl-mongodb restart: always volumes: - ./data/mongo:/data/db environment: - MONGO_INITDB_DATABASE=arl healthcheck: test: ["CMD", "mongo", "--eval", "db.adminCommand('ping')"] interval: 10s timeout: 5s retries: 5 networks: - arl-net worker: image: arl-worker:2.6.2 container_name: arl-worker restart: always depends_on: mongodb: condition: service_healthy volumes: - ./data/worker:/app/data environment: - MONGO_URI=mongodb://mongodb:27017/arl networks: - arl-net web: image: arl-web:2.6.2 container_name: arl-web restart: always depends_on: mongodb: condition: service_healthy worker: condition: service_started ports: - "5003:5003" volumes: - ./data/web:/app/data environment: - MONGO_URI=mongodb://mongodb:27017/arl networks: - arl-net networks: arl-net: driver: bridge

参数说明：condition: service_healthy让 worker 等到 mongodb 的 healthcheck 通过后再启动，避免连接被拒；restart: always保证容器异常退出后自动拉起；数据卷全部映射到宿主机./data下，方便备份和迁移。端口5003是灯塔ARL 默认的 web 端口，如果冲突可以改成5004:5003。

3.2 数据卷规划与备份策略

灯塔ARL 的数据分三块：mongodb 的数据库文件、worker 的扫描结果和截图、web 的配置和日志。这三块我都建议单独挂载，不要用匿名卷，否则容器重建后数据就丢了，那才是真的后悔药都没得吃。

备份直接用tar打包整个data目录即可，恢复时解压回原位再docker compose up -d。注意 mongodb 运行中直接拷贝文件可能不一致，稳妥做法是先docker compose stop mongodb再打包。

3.3 启动与初始化

编排文件准备好之后，启动命令就一行：

# 后台启动所有服务 docker compose up -d # 查看启动状态 docker compose ps # 跟踪日志 docker compose logs -f web

逻辑说明：-d是 detached 模式，服务在后台跑；docker compose ps看各容器是否都是Up状态，如果有Exit就要看日志；logs -f web实时跟踪 web 容器输出，首次启动时会打印初始化管理员账号和密码，这个信息只出现一次，记得截图保存。

注意：首次启动 mongodb 初始化需要 30 秒左右，如果 web 日志报MongoNetworkError，等一会儿再刷新，不要急着重启。

4. 避坑指南：部署灯塔ARL 时我踩过的五个坑

4.1 坑一：端口 5003 被占用导致 web 起不来

现象：docker compose ps显示 web 容器状态是Exit 1，日志里报bind: address already in use。

原因：宿主机上已经有其他服务占了 5003 端口，常见的是之前装过的旧版灯塔ARL 没清理干净，或者某个开发服务用了这个端口。

解决：先sudo lsof -i:5003或sudo netstat -tlnp | grep 5003找到占用进程，确认无用后 kill 掉；如果不想动那个服务，改 compose 文件里的端口映射为5004:5003，然后docker compose up -d重建 web 容器。

4.2 坑二：mongodb 健康检查一直不通过

现象：worker 容器一直处于Created状态不启动，docker compose ps显示 mongodb 是Up (health: starting)然后变成Up (unhealthy)。

原因：mongo:4.4 镜像里的mongo命令在某些架构（比如 ARM）上路径不对，或者 healthcheck 的interval设得太短，mongodb 还没启动完就被判定失败。

解决：把 healthcheck 的interval改成30s，retries改成10；如果是 ARM 架构，把镜像换成mongo:4.4-focal或者用mongosh替代mongo命令做健康检查。

4.3 坑三：扫描任务提交后一直排队不执行

现象：web 界面能正常登录，但新建任务后状态一直是「等待中」，worker 日志没有任何输出。

原因：worker 容器虽然起来了，但没有成功注册到 mongodb 的队列集合里，通常是MONGO_URI环境变量写错，或者 worker 镜像版本和 web 镜像版本不一致。

解决：进 worker 容器docker exec -it arl-worker bash，手动执行ping mongodb确认网络连通；然后检查MONGO_URI是否和 web 容器里完全一致。版本不一致的话，把两个镜像的 tag 都统一成2.6.2。

4.4 坑四：磁盘写满导致所有容器异常

现象：跑了一晚上扫描任务后，早上发现所有容器都挂了，docker compose ps全是Exit，宿主机df -h显示/var/lib/docker使用率 100%。

原因：灯塔ARL 的扫描结果和截图默认不清理，加上 docker 日志没限制大小，磁盘很快被撑爆。

解决：在 daemon.json 里加上日志限制（参考 2.3 节）；在 web 界面里设置任务保留天数，定期清理旧任务；或者写个 cron 脚本每周清理一次./data/worker下的过期截图。

4.5 坑五：升级 V2.6.2 后旧数据不兼容

现象：从旧版本升级上来，web 能启动但登录后资产列表为空，mongodb 日志报duplicate key error。

原因：V2.6.2 对 mongodb 的集合索引做了调整，旧数据里有些字段类型和新索引冲突。

解决：升级前先备份整个data/mongo目录；如果已经升级且数据异常，停掉服务，用mongodump导出旧数据，删掉data/mongo重新初始化，再用mongorestore导入，导入时加--drop参数让新索引重建。

5. 进阶技巧：用 docker compose 做多环境隔离与快速回滚

5.1 多环境隔离：测试与生产各跑一套

同一台宿主机上想同时跑测试环境和生产环境，最省事的做法是用 compose 的-p参数指定项目名，再配合不同的端口映射和数据目录。

# 生产环境 docker compose -p arl-prod -f docker-compose.yml up -d # 测试环境（端口和数据目录不同） docker compose -p arl-test -f docker-compose.test.yml up -d

逻辑说明：-p指定项目名后，docker 会把容器、网络、卷都加上项目名前缀，两套环境互不干扰。docker-compose.test.yml里把端口改成5004:5003，数据卷指向./data-test。这样测试环境随便折腾，生产环境稳如老狗。

5.2 快速回滚：镜像 tag 与数据快照

灯塔ARL 升级翻车的概率不低，所以每次升级前我都会做两件事：把当前镜像 tag 记下来，把data目录打个快照。

# 记录当前镜像版本 docker compose images > arl-images-backup.txt # 打包数据快照 tar -czvf arl-data-$(date +%Y%m%d).tar.gz ./data # 升级后如果出问题，回滚镜像 tag docker compose down docker compose up -d --force-recreate

参数说明：docker compose images列出当前使用的镜像和 tag，存成文件方便对照；tar打包时用日期做后缀，避免覆盖；回滚时如果 compose 文件里写的是latest，要手动改成旧版本号再up -d。

5.3 验证部署是否成功的三个检查点

部署完不要只看容器是不是Up，我一般会走一遍这三个检查：

三个都通过，说明部署基本没问题。如果 web 返回 502，检查 worker 是否注册成功；如果 mongodb 连不上，检查网络和MONGO_URI。

从那以后我每次部署灯塔ARL，都强制走一遍「备份数据 → 记录镜像 tag → 启动后三检查」的流程，再也没出现过升级后数据丢失或者回滚无门的情况。希望帮到你。

本文还有配套的精品资源，点击获取