ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

自托管无代码爬虫平台maxun部署实战:录制操作到数据提取

自托管无代码爬虫平台maxun部署实战:录制操作到数据提取 如果你做过一段时间的数据采集大概率经历过这么几个阶段先是requests一把梭遇到动态网页就改用 Selenium再到后来发现每次目标网站改版选择器全部作废改代码改到怀疑人生。maxun 爬虫机器人在这个背景下显得很特殊——它是一个开源、可自托管的无代码爬虫平台把“写爬虫”这件事变成了“录操作”。我这次在自己的服务器上把它完整部署了一遍从拉取仓库到跑通第一个采集任务包括中间踩过的坑全整理在下面。1. maxun 爬虫机器人到底是个什么东西1.1 它解决的是什么痛点传统爬虫开发有几个绕不过去的坎首先是门槛想爬得像样至少得会 Python、懂解析库、了解浏览器渲染机制其次是维护成本网站页面结构一变选择器失效脚本就废了最后是协作问题真正有数据需求的人往往是业务侧的同学他们不可能为了一张报表去啃两天爬虫代码。maxun 的解法是把“创建爬虫”这个动作彻底图形化你在浏览器里正常点击、输入、翻页扩展帮你把操作录制下来然后生成一个可反复运行的机器人。等到需要采集数据时你只需要框选页面里的目标元素告诉它“我要这块数据”剩下的任务调度、浏览器执行、数据导出全都在后台完成。从本质上看它属于无代码自动化数据提取工具对标的是 Browse AI 这类 SaaS但它是开源项目跑在你自己服务器上数据完全私有。github 上项目叫 getmaxun/maxun部署形态以 Docker 为主社区活跃度还不错。1.2 底层原理录制操作背后的逻辑用起来像魔法拆开看其实还是大家熟悉的那套东西。浏览器扩展负责记录用户的 DOM 操作比如点击了哪个按钮、在哪个输入框键入了什么文本、滚动到了什么位置然后把这些操作转换成可复现的自动化步骤。真正执行的时候后端会调度一个基于 Playwright 的浏览器实例按照录制好的步骤重新操作一遍页面。这里有一个关键设计它回放的不是录屏坐标而是元素定位。也就是说录制时你对某个按钮执行点击运行时它会通过选择器重新找到那个按钮再点击。这就要求录制和运行时页面结构尽量一致如果目标网站把按钮的 class 动态化那回放失败率就会上升这点后面我会展开说。数据提取机制也值得提一下。你在录制模式里高亮选中某个字段它会基于这个元素的路径和周围文本特征生成提取规则多条规则组合在一起就是一个结构化输出的字段集。所以 maxun 抓回来的数据不是一堆 HTML 源码而是类似表格的结构化数据可以直接导出 CSV、JSON。1.3 适合谁用不适合谁用先说说适合的场景。企业内部数据看板需要定期从公开网站抓取竞品价格这种需求非常适合业务人员不想每次手动复制粘贴网页数据想要一个可定时运行的机器人也适合独立开发者想快速验证某个数据采集想法不想一上来就写几百行解析代码同样适合。不适合的场景也很明显如果你需要每天百万级请求的采集量或者目标网站有强风控、频繁改动 DOM、需要登录复杂态验证那 maxun 这类通用录制型工具不是最优解还是老老实实用分布式采集框架更靠谱。另外它虽然支持登录态录制但会话过期后的重登录处理并不算智能采集需要认证的站点时要做好心理准备。2. 部署前想清楚再说maxun 的架构组件和部署形态2.1 拆开看跑一个 maxun 需要哪些零件虽然是“一键部署”但理解它由哪些组件组成后续排查问题会轻松很多。我之前没看架构就盲上结果出了问题翻日志找了大半天。maxun 的完整部署包含以下几个部分组件作用说明Web 前端用户操作界面创建机器人、查看任务状态、导出数据都在这API Server后端接口服务处理登录、机器人配置、调度请求Worker浏览器自动化执行单元核心执行层跑 Playwright 实例PostgreSQL元数据存储用户、机器人定义、任务记录、提取结果Redis队列与缓存支撑定时任务、异步队列、会话状态MinIO对象存储保存截图、录屏、导出文件等静态资源为什么不用 SQLite 一把梭因为爬虫任务天然是异步并发的你可能在网页上点了一个“运行”实际后台要把任务塞进队列然后 Worker 去抢任务、启动浏览器、执行操作、回传结果。这个链路需要可靠的队列和状态管理PostgreSQL 加 Redis 是最稳妥的组合。MinIO 则是为了让浏览器产生的录屏、截图这类大文件不落本地磁盘方便横向扩展也确实有用。2.2 Docker Compose 形态的工作方式官方主推的是 Docker Compose 编排一个docker-compose.yml把前端、API、Worker、PostgreSQL、Redis、MinIO 全拉起来。初次部署强烈建议走这条路原因很简单不用手动处理组件间的网络互通和依赖顺序。你要是对容器编排不熟可以先把它理解为“用一份配置把六个服务一起启动”。Compose 会创建内部网络服务之间通过容器名互相访问比如 API 要连数据库不需要填 localhost而是填postgres:5432这样的服务名。这个细节是录坑高发区后面我会单独说。如果你的服务器上已经有现成的 PostgreSQL、Redis 或 MinIO也可以只把 API、前端和 Worker 容器化其余组件连接外部实例。这种手动拆装的方式适合已有基础设施的团队但第一次部署不推荐因为环境变量要把连接串、端口、认证信息全部对齐调试成本略高。2.3 服务器选型与资源评估我在部署前习惯先对着资源需求表评估一下因为爬虫的瓶颈往往不是 API而是 Worker 要启动浏览器占 CPU 和内存都挺猛。拿我自己测试的参考数据来说最低配置2 核 4G 内存40G 磁盘能跑起来但并发执行 2 个以上任务时会明显卡顿推荐配置4 核 8G 内存60G 磁盘日常十几个定时任务毫无压力操作系统Ubuntu 22.04 或 Debian 12 最省心之所以内存要求偏高是因为 Chromium 渲染页面时单实例往往要占用几百 MB 内存再加上数据缓存和截图写入叠加起来并不轻松。磁盘方面尤其要注意的是 MinIO 数据目录录屏文件占用空间比你想象的大得多。网络方面如果你的服务器带宽只有 1Mbps抓纯文本数据还好但如果目标页面图片多、资源重任务耗时会显著拉长因为要等页面完全加载完才能执行后续操作。3. 本地部署全流程实录从克隆仓库到跑通第一个机器人3.1 准备环境我这次用的是一台 Ubuntu 22.04 的云服务器4 核 8G部署过程大约用了二十分钟。前置依赖就两个Docker 和 Docker Compose 插件。安装 Docker 这块网上一堆教程但有几个细节值得提醒Docker 版本最好 20.10 以上Compose 要用 v2 版本。验证方式很简单docker --version docker compose version如果你看到docker-compose带横杠的老命令提示找不到说明需要安装 compose 插件。这里不展开基础安装但务必确认这两条命令能正常输出 ok别到了启动那一步才发现环境没就绪浪费时间。还有一个容易被忽视的点云服务器的安全组策略。如果你要通过公网访问前端页面记得在安全组里放行前端端口以及测试用的 SSH 端口如果后续要暴露到公网再配置 nginx 和其他端口。我那次忘了放行端口docker 里服务全起来了页面就是打不开排查半天才发现是安全组没开属于自己给自己埋坑。3.2 .env 配置逐项解读仓库克隆下来之后最重要的一步是配置环境变量。git clone https://github.com/getmaxun/maxun.git cd maxun cp .env.example .envmaxun仓库包 root 后会出现.env文件里面每一项都要过一遍不能只改改就up。我挑几项最容易影响部署成败的说# 数据库配置 POSTGRES_USERmaxun POSTGRES_PASSWORD你的强密码 POSTGRES_DBmaxun # JWT 密钥登录态全靠它必须改 JWT_SECRET一串足够长的随机字符串 # MinIO 对象存储初始凭证 MINIO_ROOT_USERmaxunadmin MINIO_ROOT_PASSWORD你的另一个强密码 # 前端访问端口 # 具体端口名以你 clone 下来的 .env.example 为准注意:这个端口填的是宿主机上映射的对外端口容器内部端口不变。如果你本机端口被占可以改成别的值但要保持一致。另一个常见问题是时区TZ我建议直接设成Asia/Shanghai不然定时任务的执行时间和本地对不上。这是一个非常有实际影响的选项。提示JWT_SECRET或者对象存储密码太弱轻则功能异常重则被公网爆破。生成随机字符串用openssl rand -hex 32即可。3.3 启动与验证配置文件就绪后执行docker compose up -d第一次会把镜像拉取并构建时间取决于服务器到镜像仓库的网络耐心等。启动完成后重点看两个东西docker compose ps docker compose logs -fdocker compose ps会列出各个服务状态正常应该是running。如果哪个服务反复重启先docker compose logs 服务名看日志十有八九是环境变量没配对。全部就绪后浏览器访问http://服务器IP:前端端口第一步是注册管理员账号。这里要注意maxun是支持多用户的但管理员账号注册之后要记住密码角色管理在后端配置里别注册完一个号就去部署下一件事后面忘了账号很尴尬。3.4 安装浏览器扩展网页端跑通以后还有一块关键拼图录制机器人用的浏览器扩展。官方推荐的是 Chrome 系浏览器在应用商店搜索 maxun 或者根据项目文档里链接直接安装。装完之后扩展工具栏会出现 maxun 图标点击会提示登录输入你在自己服务器上注册的账号这样才能把录制的内容发送到你的后端进行处理。扩展和 Web 端登录的账号是同一套用户体系。这里有一个容易出问题的地方如果你后续用 nginx 反代并启用了 HTTPS那么录制页面上如果出现 http/https 混用扩展可能会拒绝发送数据。所以部署阶段就提前想好最终访问方式能省很多后续麻烦。4. 部署之后的重头戏配置爬虫、定时任务与数据提取4.1 录制第一个机器人部署只是起点真正体现价值的是用它干活。先说录制过程。打开目标网站点 maxun 扩展图标选择“New Robot”开始录制。此时对页面做的每一次点击、输入、翻页都会被记录下来。完成操作后点停止给机器人起个名字就完成了第一步。接着是配置数据提取在录制的流程里打开你要采集数据的页面框选目标字段比如标题、发布时间、价格每选一个就相当于定义一个输出字段。字段可以多个最后组成结构化表。这里分享一个实战心得录制时尽量选那些语义化稳定的元素。比如按钮有submit这种稳定 class优先点它如果目标网站用随机 hash 生成 class那录制完换台机器运行大概率失败。还有个细节是输入框内容不要录入带个性化的测试数据因为回放时会照着输入框的值原样键入比如你录了密码回放也会加密码这可能导致账号风控问题。4.2 定时任务怎么实现定时任务是数据采集机器人的灵魂。maxun 的 Web 界面里对每个机器人都可以配置 Schedule按一定时间间隔自动运行。这个调度机制我实测下来是这样工作的前端把定时规则写到任务表后台有个调度逻辑负责在时间点触发把任务推进 Redis 队列空闲的 Worker 从队列拉取任务启动浏览器执行。所以如果机器人的执行时间比你预期长要看是调度延迟还是执行耗时两条排查链路完全不一样。定时配置里有几个容易看错的细节timezone 的优先级是看环境变量TZ还是界面里的时区选择不同版本略有差异。建议部署完先用一个 5 分钟一次的小任务验证确认执行时刻和你的预期一致再设置日常频率避免“凌晨三点爬起来跑”这种尴尬。4.3 数据导出与 API 对接采集到的数据在页面上可以直接查看但真实场景里你可能想拿回本地或者发送给别的系统。maxun 支持把任务结果导出成 CSV、JSON 等常用格式表格类数据还有直接粘贴到电子表格的操作途径。对于开发者来说更关心 API 对接。项目本身有后端 API任务的运行结果也可以通过相关接口拉取这样你就可以把采集数据接进自己的自动化Pipeline。我在实际使用时是这样做的定时任务抓完数据写回数据库对外提供一个增量接口每次对比上次采集时间戳提取新增数据。这种方式比等待 maxun 自身的数据追溯功能更灵活也方便下游消费。唯一要提醒的是调用 API 要注意鉴权不要把登录凭证硬编码到业务脚本里。5. 从踩坑里爬出来的经验清单5.1 对象存储权限和图片加载不出来我部署完第一次运行任务任务状态显示成功但页面里图片列表全是裂图。查日志发现 worker 里的截图上传到了 MinIO但访问时返回 403。原因有两个一是 MinIO 的 bucket 访问权限默认是 private需要给对应 bucket 设置 policy二是环境变量里 MinIO 对外访问地址填的是localhost:9000浏览器从你的电脑访问时自然拿不到文件。解决办法把 MinIO 的对外 endpoint 换成服务器公网 IP 或域名并且给存储桶配置 ReadOnly 的匿名访问规则。如果只是内网使用可以用容器网络互通但浏览器客户端直接访问时仍然需要可达地址。注意改 MinIO 地址后旧的录制截图访问不到是正常的别慌新数据能正常展示就说明配置生效了。5.2 任务超时和选择器失效玩这种录制型爬虫最让人头疼的就是页面结构变动。我录好的机器人第二天跑失败日志里常见的错误是定位不到元素。通用的排查思路是在录制时选择目标网站里短期不会变的文字内容或稳定的结构属性不要选纯随机值或不稳定的样式类。另外如果任务整体超时去看 Worker 的日志和任务表里执行时间判断是哪一步耗时。很多情况下不是选择器问题而是目标网页加载了广告、弹窗导致响应延迟录制时要把这些弹窗关闭再继续操作。另一个实用习惯机器人跑完以后马上看任务记录里的截图这是最直观的排障材料。maxun 会保存执行过程中的截图出现定位失败时截图能告诉你当时的页面是什么状态、是否有遮挡或跳转到登录页很多时候看一张图比看十行日志都清楚。5.3 并发和资源占用如果你的服务器配置不高又想同时跑多个任务要注意 Worker 的并发控制。默认配置下 Worker 可能一次拉起多个浏览器实例一个 2 核 4G 的服务器跑两三个任务就会出现内存告急。我的经验是先从单 Worker、单任务开始验证稳定性确认目标网站的页面权重不重之后再逐步放开。还可以用 Compose 的deploy.resources.limits限制 Worker 的内存使用防止 OOM。观察命令很简单docker stats哪些容器占用高一目了然。如果你发现 Worker 内存一直居高不下优先检查是不是录制的流程里包含了不必要的页面跳转或者是数据提取范围太大导致页面资源反复加载。5.4 升级和迁移要注意什么开源项目迭代节奏快maxun 偶尔会出新版本。升级最稳的路径是先备份数据库、MinIO 存储目录、.env文件三样都别漏。备份数据库用pg_dump对象存储直接用cp -r同步整个数据目录。升级时先docker compose pull再docker compose up -d尽量选凌晨这种非业务时间操作。如果升级后出现旧任务跑不通大概率是数据结构变更需要根据 release notes 做迁移别盲目回滚回滚可能造成数据库版本不匹配。还有个细节.env文件建议纳入自己的版本管理私有仓库因为这些配置是你部署出的唯一“配方”丢了就得重新猜参数。6. 部署到公网反向代理、HTTPS 与数据备份6.1 用 Nginx 反代前端和后端本地部署玩出成就感之后你大概率会想让团队成员或者公网访问。这时用 IP 加端口访问既不优雅也不安全最好加一层 Nginx 反代。反向代理的核心逻辑是把一个域名路径映射到本机容器端口比如server { listen 80; server_name scrape.example.com; location / { proxy_pass http://127.0.0.1:前端端口; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /api/ { proxy_pass http://127.0.0.1:后端端口; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }要注意后端接口如果走的是/api前缀反代别漏。另外如果你的前端和后端部署在同一台机器上反代可以用127.0.0.1如果分开部署则填对应内网地址。6.2 HTTPS 要尽早配部署到公网HTTPS 不是可选项是必需品。原因很直白爬虫任务里可能涉及账号密码、目标系统的登录态这些信息走明文真的不靠谱。推荐用 Certbot 配合 Nginx 自动申请 Let’s Encrypt 证书安装之后改一下 server 配置即可这样数据链路是加密的。我这里省略详细证书安装步骤因为根据不同 Linux 版本会有差异但流程都是“安装 Certbot、验证域名、自动改 Nginx 配置、自动续期”半小时能搞定。还有一点容易被忽略HTTPS 配置好以后记得docker compose restart让前端应用感知到对外地址的变化否则有些静态资源还是按 http 生成浏览器会拦截。6.3 数据备份思路爬虫系统里最值钱的不是代码是任务定义和抓取结果。我在部署完稳定运行一周后写了一个简单的备份脚本思路很简单每天凌晨用pg_dump导出 PostgreSQL 数据库用rsync把 MinIO 数据目录同步到备份盘保留最近 7 天的备份更早的清理掉#!/bin/bash BACKUP_DIR/data/maxun-backup/$(date %F) mkdir -p $BACKUP_DIR docker exec -t postgres容器名 pg_dump -U maxun maxun $BACKUP_DIR/db.sql rsync -a /data/minio-data/ $BACKUP_DIR/minio/这个脚本虽糙但很实用。定时任务每周固定跑服务器硬盘 40G 就能放将近一个月的增量备份心里踏实很多。7. 部署完之后的延伸玩法与个人建议7.1 把它当成数据中台的“前哨”很多项目都有从外部站点拉取公开数据的需求过去我的做法是针对每个数据源单独写采集任务维护成本极高。部署 maxun 之后我把它定位成一个“半托管的数据录入员”业务侧自己录机器人技术侧只负责看板、调度稳定性、异常告警。这种分工其实很舒服。业务团队对数据的定义最清楚他们自己选择要采集的字段避免了我去猜“文章列表到底要不要抓摘要”这种需求细节。同时他们改采集规则不需要提工单等排期录一遍就完事。7.2 用 API 把采集结果接进现有系统如果你不是单人使用而是想让团队共享数据建议不要只把结果放在 maxun 页面里而是写一个轻量级的同步任务定时把产物导入到自己的数据库或表格。比如每 15 分钟调用一次任务列表接口把新结果写入目标表下游报表直接查这张表。这样即使某天 maxun 服务挂了你的下游系统仍然能基于最后一份同步数据继续工作不会因为爬虫源故障导致整个看板空白。7.3 最后说说我的整体感受如果让我重新部署一次我会提前把公网访问、HTTPS 和备份方案都想好而不是先把服务跑起来再补。部署本身不难难的是把它磨合进自己的日常工作流。maxun 爬虫机器人给我最大的感受是“低门槛但不上脑”它把创建爬虫的门槛降到了近乎零但该有的工程质量问题一个不少。部署它更像是给自己找了个靠谱的自动化助手而不是一个无所不能的黑盒。如果你正被各种“数据缺来缺去”的问题缠着又不想写一堆一次性脚本强烈建议挑一台小服务器试试自托管一套 maxun。先把最繁琐、最没有技术含量的复制粘贴任务交给它你会发现省出来的时间真的可以用来做点更有意思的事。
返回列表