SahadhammikaARL（Asset Reconnaissance Lighthouse，资产灯塔）是我个人很常用的一套资产测绘与巡检系统。前阵子重装服务器后又要把它从零部署一遍，正好借着这次完整流程，把从 Docker 环境准备、项目拉取、镜像获取、配置调整到最终启动验证的每一步都整理成复习笔记。这套流程无论你是第一次上手，还是部署过几次但怕手生，照着走都能把 ARL 跑起来。
为什么这套工具值得单独写一篇部署复习？因为 ARL 本身不是一个单一程序，而是由 Web 服务、任务执行器、MongoDB、RabbitMQ 四个核心角色组成的系统。哪怕只是忘了一个环境变量、一条初始化命令，都可能导致页面能打开但任务一直不执行。这篇笔记重点不是重复官方文档，而是把"为什么会这样配置""启动后怎么确认真的没问题""哪些坑经常踩"讲透，帮你建立完整的部署心智模型。
1. 部署前必须搞清楚的几个问题
1.1 ARL 到底由什么组件组成
ARL 虽然对外只暴露一个 5003 端口，但内部是典型的前后端分离加消息队列架构。简单说：
- arl_web：Web 入口，提供后台管理界面和 API 接口，用户在这里创建任务、查看结果。
- arl_worker：真正干活的部分，负责子域名收集、端口扫描、指纹识别等任务执行。
- MongoDB：存储任务配置、资产结果、用户信息等数据。
- RabbitMQ：充当 Web 和 Worker 之间的消息管道。Web 收到任务后把任务消息丢进队列，Worker 从中取出并执行。
理解这个架构非常重要。很多同学部署完打开页面正常，但添加任务后一直卡在"等待执行"，就是因为只关注了 Web 容器，没排查 Worker 或 RabbitMQ 的连接状态。这也是我在第 4 节和第 5 节反复强调的核心排查思路。
1.2 为什么用 Docker 部署最省心
ARL 依赖的组件版本和系统环境耦合度不低。直接用源码跑，你要手动装 Python 依赖、MongoDB、RabbitMQ，还要配 Celery 和定时任务。一旦服务器系统版本变了，或者某个依赖版本冲突，排查起来特别浪费时间。
用 Docker 之后，所有依赖都封装进镜像，部署只需完成两件事：拉镜像、起容器。数据通过 volume 映射到宿主机，容器删了数据还在，升级也不需要动数据库。这也是官方推荐 Docker 部署的根本原因。对复习部署流程的人来说，Docker 方案应该作为默认选择。
1.3 本次部署的目标拓扑
我在这次复习部署中采用的拓扑如下：
- 宿主机：CentOS 7.9 / 或 Ubuntu 22.04（两套系统我都验证过，命令略有差异，下文会单独标注）
- Docker：20.10 以上版本，自带 compose 插件
- 网络模式：以 docker-compose.yml 实际配置为准（有的是端口映射，有的是 host 模式）
- 数据目录：项目目录下的 mongo_data 和 arl_data，用于持久化
如果是在 Windows 上复习部署，我会建议优先走 Docker Desktop + WSL2 路线，原理和 Linux 一致，只是多了虚拟化和 WSL2 环境的前置准备。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境准备：Docker 全家桶安装与核验
2.1 Linux 环境安装 Docker（含 compose 插件）
在 Ubuntu/Debian 系统上，推荐直接用官方 apt 源安装。这里有个容易忽略的点：新版 Docker 已经把 compose 独立成了 docker-compose-plugin 插件包，所以必须把 docker-compose-plugin 一并装上，否则你敲 docker compose 命令会提示找不到。
bash复制sudo apt update
sudo apt install -y ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /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
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
CentOS/RHEL 系统则用 yum-config-manager 添加官方 repo：
bash复制sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
sudo yum install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo systemctl enable --now docker
装完后先设个开机自启，避免服务器重启后 Docker 服务没起来，ARL 容器全部失联。
bash复制sudo systemctl enable docker
sudo systemctl start docker
2.2 Windows 环境：Docker Desktop 与 WSL2 的前置准备
如果你是用 Windows 做 ARL 的复习环境，基本上绕不开 Docker Desktop。安装本身不复杂，但最容易卡在两个地方：
一是 WSL2 没有启用或没有设置为默认版本。装 Docker Desktop 之前，先用管理员 PowerShell 执行两条命令：
powershell复制wsl --install
wsl --set-default-version 2
二是启动 Docker Desktop 时提示 virtualization support not detected。这类问题九成是主板 BIOS 里的虚拟化开关没打开。重启进 BIOS，找到 Intel VT-x 或 AMD-V 对应选项，设为 Enabled。部分笔记本的虚拟化开关藏在安全设置里，需要先关闭 Hyper-V 相关隔离项，视具体机型而定。
WSL2 装好、BIOS 虚拟化打开后，Docker Desktop 一般就能正常启动了。你可以在设置里确认是否启用了"Use the WSL 2 based engine"选项。
2.3 验证 Docker 与 compose 是否可用
无论哪种平台，装完都要做一次快速核验：
bash复制docker version
docker compose version
docker run --rm hello-world
前两条确认客户端和插件版本，第三条确认 Docker 守护进程真的能拉取并运行容器。我见过不少环境 docker version 能显示，但 docker run 直接报权限问题，十有八九是用户没加入 docker 用户组。可以通过把当前账号加入 docker 组来解决：
bash复制sudo usermod -aG docker $USER
newgrp docker
注意，加入 docker 组后要重新登录终端会话才生效。这一点在复习时非常容易漏掉，导致后面 docker compose 命令大量 sudo 报错。
3. ARL 镜像获取与配置检查
3.1 获取项目代码并理解目录结构
ARL 的部署文件都在 GitHub 仓库里，第一步是克隆代码到服务器本地：
bash复制git clone https://github.com/TophantTechnology/ARL.git
cd ARL
克隆完成后，建议先看一眼目录结构，重点注意 docker 目录和 config-docker.yaml 文件。ARL 的 Docker 编排文件位于 docker 目录下，而配置模板在项目根目录。实际操作中，ARL 的 docker-compose.yml 里通常已经写好了默认配置，不需要频繁改动，但你得先确认几个关键点。
如果在某些环境中克隆速度很慢或失败，可以考虑使用 Gitee 上的同步镜像仓库，拉取后再自行比对文件完整性。clone 操作只需要执行一次，之后的升级和复查都在同一目录内完成。
3.2 docker-compose.yml 关键配置解读
进入 docker 目录后，先查看编排文件内容：
bash复制cd docker
cat docker-compose.yml
不同版本的 compose 文件格式会略有差异，但核心概念不变。你需要重点关注以下几个方面：
第一，服务定义。文件里通常包含 mongo、rabbitmq、arl_web、arl_worker 这几个服务。有些版本还包含 nginx。注意看每个服务使用的镜像名称和容器名，后面查日志、进容器全靠这个容器名。
第二，端口映射。常见写法有两种。一种是直接把宿主机端口映射到容器端口，形如 5003:5003；另一种是整个 compose 使用 host 网络模式，此时容器直接复用宿主机网络，5003 端口就是宿主机的 5003 端口。这两种方式各有适用场景：端口映射适合 Windows/Mac 的 Docker Desktop，host 模式适合 Linux 服务器且网络环境简单的情况。无论哪种，最终访问地址都是 http://宿主机IP:5003。
第三，数据持久化。看 compose 文件里的 volumes 字段。mongo 的数据目录通常映射为当前目录下的 mongo_data，ARL 自身数据映射为 arl_data。这两个目录务必保留，它们分别保存数据库记录和扫描结果文件。容器重建不影响数据，但目录被误删就什么都找不回来了。
第四，依赖关系。arl_web 和 arl_worker 通常 depends_on mongo 和 rabbitmq，意思是要求后两者先启动。但 depends_on 只能保证启动顺序，不能保证数据库和队列已经完全就绪。因此第一次 docker compose up 后如果 Web 启动失败，大概率是依赖组件还没 Ready，等待几秒后重启 web 服务即可。
3.3 启动前的预检清单
正式 up 之前，我习惯按顺序做一遍预检，能省掉后面一半的排查时间：
- 检查 5003 端口是否被占用：
bash复制ss -lntp | grep 5003
如果被占用，要么释放端口，要么修改 compose 文件中的映射关系。ARL 的默认端口就是 5003，改端口会影响后续访问习惯，建议直接释放原占用。
- 检查磁盘剩余空间：
bash复制df -h
ARL 的镜像本身不大，但 MongoDB 数据文件和扫描报告会持续增长，尤其做全端口扫描时报告目录膨胀速度很快。建议保留至少 20GB 空闲空间。
- 确认 Docker 守护进程状态正常：
bash复制sudo systemctl status docker
如果看到 active (running) 就没问题。
- 检查项目目录写权限。compose 启动时会创建 mongo_data 和 arl_data，如果目录不存在或不可写，容器会直接失败。
4. 启动与验证全流程
4.1 首次启动：docker compose up -d
在 docker 目录下执行：
bash复制docker compose up -d
首次启动会拉取 mongo、rabbitmq、tophant/arl 等镜像，耐心等待。如果环境之前配置过镜像加速器，拉取速度会明显改善。拉取完成后，compose 会依次创建并启动各个容器。
启动后马上查看容器状态：
bash复制docker compose ps
正常情况下，mongo、rabbitmq、arl_web、arl_worker 的 STATUS 都会显示 Up。如果某个容器反复重启，用 docker logs 查看具体原因：
bash复制docker logs --tail 50 arl_web
docker logs --tail 50 arl_worker
这里要特别提醒：Web 容器和 Worker 容器的启动脚本会做初始化工作，比如写入数据库配置、设置 RabbitMQ 账号等。如果 MongoDB 还没有完全初始化完成，Web 容器可能在启动后几十秒内异常退出，然后 by restart unless-stopped 策略自动重启。这种"反复重启后最终恢复"的情况，在慢速磁盘机器上非常常见，不要一看到 Exited 就急着重装，先看日志再判断。
4.2 服务自检：页面、连通性、任务链路
容器全部 Up 之后，还有几个验证步骤不能省，否则你根本不知道服务到底是不是真的能用。
第一，访问后台页面：
bash复制curl -I http://127.0.0.1:5003
看到 HTTP/1.1 200 或 302 响应说明 Web 服务已经响应。浏览器访问 http://服务器IP:5003，应该能跳出 ARL 登录页。
第二，验证 MondoDB 数据可写。正常启动后，ARL 会在 MongoDB 中自动创建 arl 数据库。进入容器确认：
bash复制docker exec -it arl_mongo mongo --quiet --eval "show dbs"
如果能看到 arl（或类似名称）数据库，说明 Web 启动脚本已经成功连库。
第三，验证 RabbitMQ 的队列状态。ARL 的任务依赖 RabbitMQ 传递消息。进入 RabbitMQ 容器查看队列：
bash复制docker exec -it arl_rabbitmq rabbitmqctl list_queues
如果能看到 arl 相关队列，并且 arl_worker 容器日志没有报连接错误，说明消息链路基本贯通。
第四，尝试在后台添加一个最简单的任务。登录 ARL 后，在"任务管理"里新建任务，目标填一个自己拥有或有授权资产备案的域名，任务类型选"子域名收集"或"安全巡检"。提交后观察任务状态从"等待中"变为"执行中"，再变为"已完成"。整个过程走通，才真正说明部署成功。
4.3 登录后台与初始化账号处理
ARL 的默认账号密码是 admin / arlpass。注意新版镜像在首次登录后会强制要求修改默认密码，所以看到重定向到修改密码页面是正常现象，不要以为是报错。
修改密码后建议立刻绑定一个可用邮箱，后续忘记密码可以通过邮箱找回。这一步虽小，但我在实操中见过太多人改完密码就忘，最后只能进 MongoDB 手动重置用户密码，绕了很大一圈。
bash复制docker exec -it arl_mongo mongo arl --eval "db.user.find().pretty()"
这条命令可以查看当前已注册的用户信息，确认账号数据正常写入。平时不要没事去改数据库里的密码字段，除非你确定自己在做什么。
4.4 数据备份与恢复策略
ARL 跑起来之后，最值钱的不是代码，而是 MongoDB 里积累的资产数据和任务结果。我的习惯是每天凌晨对 arl 库做一次 mongodump，并保留近一周的备份文件。
在宿主机上写一个简单的备份脚本，内容大致如下：
bash复制#!/bin/bash
BACKUP_DIR=/data/arl_backup
DATE=$(date +%Y%m%d%H%M)
docker exec arl_mongo mongodump --db arl --gzip --archive=/tmp/arl_$DATE.gz
docker cp arl_mongo:/tmp/arl_$DATE.gz $BACKUP_DIR/
docker exec arl_mongo rm -f /tmp/arl_$DATE.gz
find $BACKUP_DIR -name "*.gz" -mtime +7 -exec rm -f {} \;
恢复时，把备份文件复制回容器内，再用 mongorestore：
bash复制docker cp ./arl_202501011200.gz arl_mongo:/tmp/
docker exec arl_mongo mongorestore --gzip --archive=/tmp/arl_202501011200.gz
这套备份恢复流程不需要停服务，实测在线执行不影响正在跑的任务。
5. 踩过的坑与排查手册
5.1 常见报错速查表
部署和日常使用中，我整理过一张高频问题对照表，复习时直接按图索骥：
| 现象 | 可能原因 | 排查思路 |
|---|---|---|
| docker compose up 报 5003 端口已占用 | 宿主机已有进程监听 | ss -lntp | grep 5003，释放端口 |
| arl_web 容器反复重启 | MongoDB 未就绪或数据目录权限异常 | 查看 arl_web 日志，检查 mongo_data 属主 |
| 后台页面能开，任务一直等待 | Worker 未消费消息或 RabbitMQ 连接失败 | docker logs 查看 arl_worker 日志 |
| 任务执行一半卡死 | 内存不足或扫描目标响应慢 | free -h 查看内存，检查任务目标配置 |
| 登录后强制改密失败 | 浏览器缓存了旧会话 | 清理浏览器缓存或换无痕窗口 |
| Docker Desktop 无法启动 | 虚拟化未开启或 WSL2 未更新 | 检查 BIOS 虚拟化开关，wsl --update |
| 拉取镜像超时 | 网络到镜像仓库不稳定 | 配置 registry-mirrors 加速器，稍后重试 |
这张表里的前四条，是 ARL 部署最常遇到的情况。尤其是第二条和第三条，本质都是"依赖组件没有先就绪"，解决思路是完全一致的：依次确认 mongo、rabbitmq 两个基础服务是否健康，然后再看 web 和 worker 是否成功连上它们。
5.2 资源占用与配置调优
ARL 的资源消耗大头在 Worker 执行扫描任务时。默认情况下，celery worker 的并发数和每个任务的 namp 进程数都按通用配置设置。如果宿主机内存只有 4GB，同时跑多个大任务很容易触发 OOM，表现为容器被系统杀掉或任务异常中断。
我在这台复习服务器上做的最重要的一个调优，是给 Docker 守护进程设置内存限制，并在 compose 文件里给 worker 服务添加了 mem_limit 配置。对于只有 4GB 内存的宿主机，建议把 worker 限制在 2GB 以内，Web 限制在 1GB，剩余留给系统和其他镜像。
此外，ARL 的扫描结果默认保存在 alr_data 目录。跑过一次大规模 IP 段扫描后，这个目录大小可能轻松超过几个 GB。建议定期清理过期任务报告，避免磁盘写满。磁盘满的典型症状是页面能打开，但新增任务保存失败。
5.3 日常维护、升级与回滚
ARL 项目会不定期更新，修复漏洞和增加功能。升级操作本身不复杂：
bash复制cd ARL
git pull
cd docker
docker compose pull
docker compose up -d
但升级前一定要先做 MongoDB 备份。原因很简单：新版脚本可能会改动数据库结构或初始化逻辑，如果升级到一半失败，至少还能回滚到旧版本恢复数据。
回滚的方法也很直接。如果 git pull 之后发现问题，先用 git log 找到上一个正常提交的 commit id，然后：
bash复制git checkout <commit_id>
docker compose down
docker compose up -d
旧代码配合旧镜像，配合之前备份的数据，基本能回到升级前的可用状态。我自己就遇到过新版本中间加了一个配置项，导致旧数据目录下配置文件不匹配的情况，最后靠回滚解决。所以"升级前备份"这句话，我说多少次都不嫌多。
5.4 关于主机网络模式和端口映射的选择心得
最后聊一个部署时容易纠结的点。ARL 的 compose 文件有的版本直接用 host 网络模式，有的版本用端口映射。我在 Linux 服务器上两种都试过，实际差别不大，但迁移性和可维护性差别明显。
host 网络模式的好处是没有端口映射配置，容器之间通过 localhost 直接互访，性能损耗小，适合专用服务器。缺点是如果一台机器上同时跑多个用到 27017、5672 端口的系统，端口冲突会非常麻烦，而且 Docker Desktop 对 host 模式支持很差，跨平台迁移困难。
端口映射模式则更通用，尤其适合 Windows 或 Mac 的 Docker Desktop，以及一台服务器部署多个容器应用的情况。你只需要把 5003 映射出来，MongoDB 和 RabbitMQ 不对外暴露反而更安全。ARL 的 Web 和 Worker 在同一套 compose 内可以通过容器名互通，不依赖 host 网络也能正常工作。
我的建议是：如果你是在云服务器上长期使用 ARL，优先采用端口映射模式，把 Mongo 和 RabbitMQ 的端口仅绑定到 127.0.0.1，避免数据库暴露到公网。如果你只是本机测试，host 模式更快。这个选择不影响 ARL 本身的功能，但决定了你后续运维的省心程度。
写在复习最后
整套流程复习下来，你会发现 ARL 的部署其实不复杂，核心就是三点：Docker 环境干净可用、compose 文件几个关键配置理解到位、启动后按"页面-数据库-队列-任务链路"的顺序逐层验证。我在实际操作中最大的体会是，不要跳过预检和验证环节。部署脚本只是第一步，真正的排障能力都体现在对组件关系和日志信息的理解上。
下次如果你也遇到"页面能开但任务不跑"这类问题，记住先从 arl_worker 的日志入手，沿着 MondoDB、RabbitMQ、Worker 这条链路往下查，基本都能定位。这套复习流程我前后走了三遍，现在从裸机到 ARL 跑通大概只需要十五分钟。希望这篇笔记也能帮你把整个过程沉淀成自己的肌肉记忆。