Crawlee 浏览器爬虫部署到 GCP Cloud Run 实战指南【免费下载链接】crawleeCrawlee—A web scraping and browser automation library for Node.js to build reliable crawlers. In JavaScript and TypeScript. Extract data for AI, LLMs, RAG, or GPTs. Download HTML, PDF, JPG, PNG, and other files from websites. Works with Puppeteer, Playwright, Cheerio, JSDOM, and raw HTTP. Both headful and headless mode. With proxy rotation.项目地址: https://gitcode.com/GitHub_Trending/cr/crawlee导读本文基于 Crawlee 官方文档完整讲解如何在 Google Cloud PlatformGCP的Cloud Run上运行带真实浏览器的 Crawlee 爬虫如PlaywrightCrawler。你将掌握 Cloud Run 与 Cloud Functions/AWS Lambda 的差异、无状态 HTTP 包装模式、persistStorage配置原理以及从npx crawlee create初始化到gcloud run deploy一键部署的完整流程。为什么 GCP 上的浏览器爬虫需要 Cloud Run在 GCP 上运行完整尺寸的浏览器如 Chromium与在 AWS Lambda 上运行略有不同根据 Puppeteer 官方的排查文档Google Cloud Functions 的最新运行时缺少运行 Chromium 所必需的若干系统依赖如共享库导致浏览器无法正常启动。因此如果要在 GCP 上运行浏览器启用的 Crawlee 爬虫就需要转向Cloud Run。Cloud Run 是 GCP 的容器托管平台核心特点包括按需拉起容器GCP 会在收到请求时才启动你的容器因此只按容器返回 HTTP 响应给客户端所花费的时间计费空闲时零费用与 FaaS 高度相似除了运行载体是 Docker 容器而非函数运行时之外开发与部署模型与 Cloud Functions / AWS Lambda几乎一致本地可调试你可以在本地运行、调试 Docker 容器并确信云端环境与本地完全一致相比普通 FaaS 拥有更好的开发体验。从 Crawlee 仓库的部署文档结构也可以印证这一点docs/deployment/目录下同时提供了 gcp-browsers.md本文主题、aws-browsers.mdAWS Lambda 版与 gcp-cheerio.md无浏览器场景三份文档相互对照正好覆盖了有/无浏览器 × GCP/AWS四种常见部署组合。第一步关闭存储持久化在服务端Serverless/容器平台运行 Crawlee 爬虫时第一步永远是给爬虫构造函数传入一个新的Configuration实例并关闭存储持久化import { Configuration, PlaywrightCrawler } from crawlee; import { router } from ./routes.js; const startUrls [https://crawlee.dev]; const crawler new PlaywrightCrawler({ requestHandler: router, }, new Configuration({ persistStorage: false, })); await crawler.run(startUrls);persistStorage 背后的原理从源码看persistStorage是 Crawlee 配置体系中的一个标准字段定义在 packages/core/src/configuration.tspersistStorage: field(coerceBoolean.default(true), CRAWLEE_PERSIST_STORAGE),即默认值为true爬虫会把请求队列、数据集Dataset、键值存储Key-Value Store等状态持久化到本地磁盘默认目录为./storage对应storageDir字段可配置为false关闭磁盘持久化所有状态保存在内存中环境变量CRAWLEE_PERSIST_STORAGE支持字符串形式的false/0被解析为假值见同文件中的coerceBoolean预处理逻辑。Configuration实例的取值优先级为构造函数传入选项 环境变量 crawlee.json schema 默认值见 configuration.ts 中的文档注释。因此这里通过构造函数显式传入new Configuration({ persistStorage: false })优先级最高。为什么在容器/Serverless 中要关闭持久化原因有二每个请求/实例拥有独立存储每次请求都新建 crawler 实例并传入独立Configuration多个并发实例之间不会互相干扰这与 AWS Lambda 场景的推荐做法完全一致见 aws-browsers.md容器文件系统不可靠Cloud Run 的容器实例随时可能被回收磁盘不是持久化介质关闭持久化还能避免向只读/临时文件系统写入报错。第二步用 Express 包装为 HTTP 服务Cloud Run 平台只看到一个不透明的 Docker 容器它并不知道里面跑的是什么服务。因此我们需要自己用 HTTP 框架把爬虫包装成可被外部访问的 HTTP 接口。首先安装 Expressnpm i express关键点GCP 会通过环境变量PORT告诉你的容器应该监听哪个端口GCP 会把这个端口暴露给外网。你的 HTTP 服务器必须监听该端口。改造后的src/main.js最终形态如下import { Configuration, PlaywrightCrawler } from crawlee; import { router } from ./routes.js; import express from express; const app express(); const startUrls [https://crawlee.dev]; app.get(/, async (req, res) { const crawler new PlaywrightCrawler({ requestHandler: router, }, new Configuration({ persistStorage: false, })); await crawler.run(startUrls); return res.send(await crawler.getData()); }); app.listen(parseInt(process.env.PORT) || 3000);代码要点解读每次请求新建 crawler爬虫在app.get(/)的请求处理函数内部创建保证每个 HTTP 请求对应一次独立的爬取任务getData()读取结果crawler.getData()是 Crawlee 内置的快捷方法底层调用Dataset.getData()从默认数据集读取爬取结果并以 JSON 形式返回给客户端。其实现位于 packages/basic-crawler/src/internals/basic-crawler.tsasync getData(...args: ParametersDataset[getData]): ReturnTypeDataset[getData] { const dataset await this.getDataset(); return dataset.getData(...args); }端口兜底parseInt(process.env.PORT) || 3000在本地开发时没有PORT环境变量默认监听 3000 端口。无状态约束Stateless:::tip 重要提示 与所有 FaaS 服务一样必须把全部逻辑都放在请求处理函数内请求处理必须是**无状态stateless**的。不要在模块顶层创建并复用 crawler 实例、不要在模块作用域保存爬取状态或队列数据。Cloud Run 可能随时横向扩容出多个实例也可能回收闲置实例只有请求进来 → 新建 crawler → 爬取 → 返回结果这种纯无状态模式才能保证任意实例都能独立、正确地服务任意请求。 :::关于无状态模式仓库中的 running-in-web-server.mdx 指南还提到一个值得注意的细节如果把长驻 crawler 与 HTTP 服务结合在一起而非每次请求新建实例请求队列会持续增长——每个进来的 HTTP 请求都会获得独立uniqueKey而无法去重队列会保存每一个已处理过的请求记录。对于长时间运行的进程更合理的做法是直接回收进程。这从侧面印证了每次请求新建 crawler 实例这种模式在 Cloud Run 按需实例场景下的优势。第三步部署到 GCP准备 Dockerfile如果你是用以下命令初始化项目的npx crawlee create初始化脚本会自动为你生成Dockerfile。以仓库中的 Playwright 模板为例packages/templates/templates/playwright-ts/Dockerfile 展示了浏览器爬虫项目 Dockerfile 的标准结构# 基于预装 Playwright Chrome 的基础镜像多阶段构建 FROM apify/actor-node-playwright-chrome:24-1.58.2 AS builder # 先只拷贝 package 文件充分利用 Docker 层缓存加速构建 COPY --chownmyuser package*.json ./ RUN npm install --includedev --auditfalse # 拷贝源码并构建 COPY --chownmyuser . ./ RUN npm run build # 最终镜像只保留编译产物与生产依赖 FROM apify/actor-node-playwright-chrome:24-1.58.2 COPY --frombuilder --chownmyuser /home/myuser/dist ./dist COPY --chownmyuser package*.json ./ RUN npm --quiet set progressfalse \ npm install --omitdev \ echo Installed NPM packages: \ (npm list --omitdev --all || true) COPY --chownmyuser . ./ # 运行XVFB 脚本支持 headful 模式 CMD ./start_xvfb_and_run_cmd.sh npm run start:prod --silent关于基础镜像的选型可以参考仓库中的 docker_images.mdx 指南apify/actor-node-playwright-chrome预装 Playwright Chrome支持PlaywrightCrawler体积比全量浏览器镜像小适合大多数 Playwright 场景apify/actor-node-playwright预装 Chromium、Chrome、Firefox、WebKit 全部浏览器体积最大apify/actor-node最小镜像不含任何浏览器只适合CheerioCrawler生产环境建议同时锁定 Node.js 版本与自动化库版本标签如24-1.58.2并将package.json中的playwright版本与之对齐避免浏览器与库版本不匹配导致的兼容性问题。执行 gcloud 部署准备工作就绪后在包含Dockerfile的项目文件夹内执行gcloud run deploygcloudCLI 会以交互方式向你提问典型问题包括部署到哪个区域region选择离你的目标网站更近或符合合规要求的区域是否允许未认证调用public or private如果爬虫接口是内部服务选择 private如果需要对外暴露选择 public 并配置认证。回答完这些问题后gcloud会构建镜像、推送到 Artifact Registry 并创建 Cloud Run 服务。完成后你可以在 GCP 控制台的 Cloud Run 面板中看到你的应用并使用面板中提供的访问链接直接触发爬虫。首次运行失败的排查建议:::tip 常见坑 如果首次运行新创建的 Cloud Run 服务失败请编辑 Run 配置重点调整以下两项内存memory设置为1GiB 或更高。完整尺寸的 Chromium 需要数百 MB 内存默认的小内存配置很容易导致浏览器进程被 OOM 杀掉请求超时request timeout根据你抓取的目标网站规模调整。页面越大、请求越慢爬取一个完整任务所需的时间越长默认超时可能不够用。 :::同样的约束在 AWS Lambda 场景也存在——aws-browsers.md 明确建议将 Lambda 内存设置为 1024 MB 以上并据本地实测运行时间设置超时。Cloud Run 与 Lambda 在浏览器需要大内存、需要足够超时这一点上是完全一致的。与其他部署路径的对比为了帮助你在选型时做出判断下表对比了 GCP 上的两条部署路径维度Cloud Run本文Cloud Functions见 gcp-cheerio.md运行载体Docker 容器函数运行时浏览器支持完整支持Chromium 依赖齐全不支持缺少 Chromium 运行依赖适用爬虫PlaywrightCrawler/PuppeteerCrawler等浏览器爬虫CheerioCrawler等无浏览器爬虫代码包装方式Express 等 HTTP 框架 监听PORT导出handler(req, res)命名函数本地调试可本地运行同一 Docker 镜像依赖模拟器配置要点内存 ≥ 1GiB、调大请求超时设置入口函数Entry point与内存/超时如果你只需要抓取静态 HTML用CheerioCrawler走 Cloud Functions 更轻量、成本更低一旦需要执行 JavaScript、渲染页面或模拟真实浏览器行为就必须使用本文的 Cloud Run 方案。总结将 Crawlee 浏览器爬虫部署到 GCP Cloud Run核心只有三步关闭持久化给 crawler 传入new Configuration({ persistStorage: false })避免容器文件系统不可靠带来的问题HTTP 包装用 Express 监听 GCP 注入的PORT环境变量把爬取任务包装成无状态的 HTTP 请求处理函数容器化部署利用npx crawlee create生成的 Dockerfile执行gcloud run deploy交互式部署并保证内存 ≥ 1GiB、超时设置合理。这一模式同样适用于 AWS Lambdaaws-browsers.md等 Serverless 平台核心思想一致独立配置实例 无状态请求处理 按需计费。按此流程你可以在几分钟内拥有一个通过 HTTPS 调用即可触发完整浏览器爬取任务的生产级服务。【免费下载链接】crawleeCrawlee—A web scraping and browser automation library for Node.js to build reliable crawlers. In JavaScript and TypeScript. Extract data for AI, LLMs, RAG, or GPTs. Download HTML, PDF, JPG, PNG, and other files from websites. Works with Puppeteer, Playwright, Cheerio, JSDOM, and raw HTTP. Both headful and headless mode. With proxy rotation.项目地址: https://gitcode.com/GitHub_Trending/cr/crawlee创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考