4.2 部署方案

4.2 部署方案

4.2 部署方案

4.2.1 本地部署方案

本地部署方案，顾名思义，是将 Browser-use 代理网站访问器部署在用户自己的本地计算机或局域网服务器上。这种方案具有较高的灵活性和可控性，特别适合于开发测试、个人使用或对数据安全性有较高要求的场景。

4.2.1.1 概述

本地部署方案的核心是将 Browser-use 运行所需的所有组件，包括 Python 环境、依赖库、配置文件以及 Web UI 界面，全部安装和配置在本地计算资源上。用户可以直接通过本地网络访问和使用该访问器。

4.2.1.2 前提条件

在开始本地部署之前，需要确保本地环境满足以下前提条件：

• 操作系统: 兼容的操作系统，例如 Windows 10/11, macOS, 或 Linux 发行版。

• Python 环境: Python 3.11 或更高版本。推荐使用虚拟环境管理工具，如 venv 或 conda，以隔离项目依赖，避免版本冲突。

• Git: 用于从 GitHub 仓库克隆项目代码。

• Playwright: Browser-use 依赖 Playwright 进行浏览器自动化操作，需要预先安装。

• Node.js (可选): 如果需要构建前端资源或使用某些特定的 npm 包，则可能需要 Node.js 环境。

• API 密钥 (可选): 如果使用需要 API 密钥的大语言模型 (LLM)，例如 OpenAI, DeepSeek 等，则需要准备相应的 API 密钥。

4.2.1.3 部署步骤

本地部署 Browser-use 代理网站访问器通常包含以下步骤：

4.2.1.3.1 获取项目代码

首先，需要从 Browser-use 的 GitHub 仓库克隆项目代码到本地。打开终端或命令提示符，导航到希望存放项目代码的目录，并执行以下命令：

git clone https://github.com/browser-use/web-ui.git
cd web-ui
​

这将会在当前目录下创建一个名为 web-ui 的文件夹，并将项目代码下载到该文件夹中。

4.2.1.3.2 配置 Python 环境

进入项目目录后， рекомендуется создать 虚拟环境 чтобы изолировать зависимости проекта. 使用 venv 创建虚拟环境的步骤如下：

# 创建虚拟环境
python3.11 -m venv .venv
# 激活虚拟环境 (不同操作系统命令不同)
# Windows (CMD):
.venv\Scripts\activate
# Windows (PowerShell):
.\.venv\Scripts\Activate.ps1
# macOS/Linux:
source .venv/bin/activate
​

激活虚拟环境后，终端提示符前会显示虚拟环境名称，表示已成功进入虚拟环境。

4.2.1.3.3 安装项目依赖

在虚拟环境激活状态下，使用包管理工具安装项目所需的 Python 依赖包。Browser-use 项目通常会在 requirements.txt 文件中列出所有依赖包。执行以下命令安装依赖：

pip install -r requirements.txt
​

为了确保浏览器自动化功能正常运行，还需要安装 Playwright 及其浏览器驱动。执行以下命令安装 Chromium 浏览器及其依赖：

playwright install --with-deps chromium
​

根据需要，也可以选择安装其他浏览器，例如 Firefox 或 WebKit。

4.2.1.3.4 环境配置

Browser-use 项目通常使用 .env 文件来管理环境变量，例如 API 密钥、端口号等。项目根目录下通常会提供一个 .env.example 文件作为示例配置文件。

1. 复制配置文件: 将 .env.example 文件复制一份并重命名为 .env。

   # Windows
   copy .env.example .env
   # macOS/Linux
   cp .env.example .env
   ​

2. 编辑配置文件: 使用文本编辑器打开 .env 文件，根据需要配置环境变量。例如，如果使用 DeepSeek 模型，需要配置 DeepSeek API 密钥和 API Base URL：

   DEEPSEEK_API_KEY=your_deepseek_api_key
   DEEPSEEK_API_BASE=https://api.deepseek.com/v1
   ​

   还可以配置 Web UI 的 IP 地址和端口号：

   WEBUI_IP=127.0.0.1
   WEBUI_PORT=7788
   ​

   其他配置项，例如浏览器持久化会话设置等，也可以根据需要进行配置。

4.2.1.3.5 启动应用

完成以上配置后，即可启动 Browser-use Web UI。在终端中执行以下命令：

python webui.py --ip 127.0.0.1 --port 7788
​

或者，如果希望使用 .env 文件中配置的 IP 和端口，可以直接运行：

python webui.py
​

启动成功后，终端会显示 Web UI 的访问地址，通常为 http://127.0.0.1:7788。在浏览器中打开该地址，即可访问 Browser-use Web UI 界面，开始使用代理网站访问器。

4.2.1.4 本地部署架构图

图 4.2.1 本地部署架构图

该架构图展示了本地部署方案的关键组件和数据流。用户通过本地计算机访问 Browser-use Web UI，Web UI 基于 Python 环境和 Playwright 驱动浏览器实例进行网页操作，并可选择性地调用 LLM API 获取语言模型能力。所有组件都部署在本地计算机上。

4.2.1.5 优缺点分析

优点：

• 高灵活性和可控性: 用户完全掌控部署环境，可以根据自身需求进行定制化配置，例如选择特定的浏览器版本、调整系统参数等。

• 数据安全性: 数据存储和处理都在本地进行，敏感数据不会离开本地环境，对于注重数据隐私的用户来说更安全。

• 开发测试便捷: 本地部署方便开发人员进行快速迭代和调试，无需频繁部署到远程服务器。

• 离线使用 (部分): 对于不依赖在线 LLM 服务的任务，本地部署可以实现离线使用。

缺点：

• 资源限制: 本地计算机的计算资源、网络带宽等可能成为性能瓶颈，尤其是在处理复杂任务或高并发请求时。

• 可访问性受限: 本地部署的应用只能在本地网络或通过端口映射等方式对外提供服务，可访问性相对较差。

• 维护成本: 用户需要自行负责服务器的维护、监控和安全更新等工作，增加了维护成本。

• 环境配置复杂性: 对于不熟悉技术的用户，本地环境配置可能较为复杂，容易遇到各种环境问题。

4.2.1.6 适用场景

• 开发测试环境: 本地部署是开发人员进行功能开发、单元测试和集成测试的理想选择。

• 个人使用: 对于个人用户，本地部署可以满足日常的网页浏览自动化需求，例如信息收集、数据抓取等。

• 内部局域网应用: 如果 Browser-use 仅需要在企业或组织内部局域网中使用，本地部署可以简化部署流程，降低外部网络依赖。

• 数据敏感型应用: 对于需要处理敏感数据，且不允许数据离开本地环境的应用场景，本地部署是更安全的选择。

4.2.2 Docker 部署方案

Docker 部署方案利用 Docker 容器技术，将 Browser-use 及其所有依赖项打包到一个独立的容器镜像中。这种方案具有高度的可移植性和一致性，简化了部署流程，并提高了应用的可扩展性和可维护性。

4.2.2.1 概述

Docker 部署方案的核心是将 Browser-use 应用及其运行环境封装在 Docker 容器中。通过 Docker 镜像，用户可以在任何支持 Docker 的平台上快速部署和运行 Browser-use，无需担心环境依赖和配置问题。

4.2.2.2 前提条件

• Docker: 本地计算机或服务器需要安装 Docker 引擎。

• Docker Compose (可选): 如果需要管理多个 Docker 容器或定义复杂的容器编排，则需要安装 Docker Compose。

• Git (可选): 如果需要从 GitHub 仓库克隆包含 Dockerfile 的项目代码。

4.2.2.3 部署步骤

Docker 部署 Browser-use 代理网站访问器通常包含以下步骤：

4.2.2.3.1 获取 Dockerfile 和 docker-compose.yml

Browser-use 项目通常会提供 Dockerfile 和 docker-compose.yml 文件，用于构建 Docker 镜像和定义容器服务。

1. 查找 Dockerfile: 在项目根目录或指定目录下查找 Dockerfile。Dockerfile 定义了如何构建 Docker 镜像，包括基础镜像、依赖安装、文件复制、端口暴露等。

2. 查找 docker-compose.yml (可选): 如果项目提供了 docker-compose.yml 文件，则可以使用 Docker Compose 进行容器编排。docker-compose.yml 文件定义了多个容器服务、网络配置、卷挂载等。

如果项目仓库中没有提供 Dockerfile，用户需要自行创建。一个基本的 Dockerfile 示例可能如下所示：

FROM python:3.11-slim-buster
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
RUN playwright install --with-deps chromium
EXPOSE 7788
CMD ["python", "webui.py", "--ip", "0.0.0.0", "--port", "7788"]
​

4.2.2.3.2 构建 Docker 镜像

在包含 Dockerfile 的项目目录下，打开终端或命令提示符，执行以下命令构建 Docker 镜像：

docker build -t browser-use-webui .
​

其中，browser-use-webui 是镜像名称，. 表示 Dockerfile 所在的当前目录。Docker 将会根据 Dockerfile 的指令，从基础镜像开始，逐步构建 Browser-use 应用的 Docker 镜像。

4.2.2.3.3 运行 Docker 容器

镜像构建完成后，可以使用以下命令运行 Docker 容器：

docker run -d -p 7788:7788 browser-use-webui
​

• -d: 后台运行容器。

• -p 7788:7788: 将容器的 7788 端口映射到宿主机的 7788 端口。

• browser-use-webui: 要运行的镜像名称。

如果使用 Docker Compose，可以在包含 docker-compose.yml 文件的项目目录下，执行以下命令启动容器：

docker-compose up -d
​

Docker Compose 会根据 docker-compose.yml 文件中的定义，启动所有容器服务。

容器启动后，即可通过宿主机的 7788 端口访问 Browser-use Web UI，例如 http://localhost:7788 或 http://服务器IP:7788。

4.2.2.4 Docker 部署架构图

图 4.2.2 Docker 部署架构图

该架构图展示了 Docker 部署方案的核心组件。用户通过 Docker 主机访问运行在 Docker 容器内的 Browser-use Web UI。容器内部包含了 Python 环境、Playwright、浏览器实例等所有运行依赖。配置文件可以作为卷挂载到容器内部，实现配置的持久化和外部管理。

4.2.2.5 优缺点分析

优点：

• 高度可移植性: Docker 镜像可以在任何支持 Docker 的平台上运行，例如 Linux, Windows, macOS, 云服务器等，实现了 "一次构建，到处运行" 的目标，避免了环境差异带来的部署问题。

• 环境一致性: Docker 容器封装了应用及其所有依赖，确保了不同环境下的运行环境完全一致，消除了 "在我机器上可以运行" 的问题，提高了应用的可预测性和稳定性。

• 资源隔离: Docker 容器之间相互隔离，互不影响，可以有效避免应用之间的资源冲突和干扰，提高了系统的安全性。

• 快速部署和启动: Docker 镜像的构建和分发非常快速，容器的启动也只需几秒钟，大大缩短了部署时间，提高了部署效率。

• 易于扩展和伸缩: Docker 容器可以方便地进行水平扩展和伸缩，可以根据负载情况动态调整容器数量，满足高并发和高负载的应用需求。

• 简化管理和维护: Docker 提供了一套完善的容器管理工具，例如 Docker Compose, Docker Swarm, Kubernetes 等，可以方便地管理和维护容器化应用，降低了运维成本。

• 版本控制和回滚: Docker 镜像可以进行版本控制，方便进行应用的版本迭代和回滚，提高了应用的可靠性和可维护性。

缺点：

• 学习曲线: 对于初学者，Docker 的概念和操作可能存在一定的学习曲线，需要一定的学习成本。

• 资源开销: Docker 容器本身会占用一定的系统资源，例如 CPU, 内存, 磁盘空间等，相比于直接在宿主机上运行应用，会增加一定的资源开销。

• 网络配置: Docker 容器网络配置可能相对复杂，需要理解 Docker 网络模式、端口映射、容器互联等概念。

• 镜像管理: Docker 镜像需要进行管理，包括镜像的构建、存储、分发、更新等，需要一定的镜像管理成本。

• 持久化数据管理: Docker 容器默认是无状态的，容器重启后数据会丢失，需要使用卷 (Volume) 等机制来持久化数据，增加了数据管理的复杂性。

• 安全 considerations: Docker 容器安全需要重视，例如镜像安全扫描、容器权限控制、网络隔离等，需要采取相应的安全措施。

4.2.2.6 适用场景

• 生产环境部署: Docker 部署非常适合生产环境，可以保证应用在生产环境中的稳定性和可靠性，并方便进行扩展和维护。

• 云平台部署: 各大云平台 (例如 AWS, Azure, GCP) 都对 Docker 提供了良好的支持，Docker 部署可以方便地将 Browser-use 应用部署到云平台上，利用云平台的弹性计算和存储资源。

• 团队协作开发: Docker 可以为开发团队提供一致的开发环境，避免了 "环境不一致" 导致的问题，提高了团队协作效率。

• 微服务架构: 如果 Browser-use 应用采用微服务架构，Docker 部署可以方便地将每个微服务封装成独立的容器，并进行独立部署和管理。

• 持续集成/持续交付 (CI/CD): Docker 可以与 CI/CD 工具 (例如 Jenkins, GitLab CI, CircleCI) 集成，实现应用的自动化构建、测试和部署，加速软件交付流程。

• 需要快速部署和扩展的应用: 对于需要快速部署和扩展的应用，Docker 部署可以大大缩短部署时间，并方便进行水平扩展，满足业务快速发展的需求。

• 多环境部署: 对于需要在多个环境 (例如开发环境、测试环境、生产环境) 部署的应用，Docker 部署可以保证各个环境的一致性，减少环境差异带来的问题。

4.2.3 云平台部署方案

云平台部署方案是将 Browser-use 代理网站访问器部署在云服务提供商 (例如 AWS, Azure, GCP) 提供的云基础设施上。这种方案具有高可用性、弹性伸缩、按需付费等优势，特别适合于对性能、可靠性、可扩展性有较高要求的应用场景。

4.2.3.1 概述

云平台部署方案利用云服务提供商提供的计算、存储、网络等云资源，将 Browser-use 应用部署到云端。用户可以选择不同的云服务类型，例如虚拟机 (VM)、容器服务 (例如 Kubernetes, ECS)、Serverless 函数等，根据自身需求选择最合适的云平台部署方案。

4.2.3.2 前提条件

• 云平台账号: 需要拥有云服务提供商 (例如 AWS, Azure, GCP) 的账号。

• 云平台资源: 根据选择的云服务类型，需要准备相应的云资源，例如虚拟机实例、容器集群、云存储等。

• Docker 镜像 (可选): 如果选择容器服务或 Kubernetes 部署，需要预先构建 Browser-use 的 Docker 镜像。

• 域名和 SSL 证书 (可选): 如果需要通过域名访问 Browser-use Web UI，并启用 HTTPS 加密，则需要准备域名和 SSL 证书。

4.2.3.3 部署步骤

云平台部署 Browser-use 代理网站访问器，根据选择的云服务类型，部署步骤会有所不同。以下分别介绍几种常见的云平台部署方式：

4.2.3.3.1 基于虚拟机 (VM) 部署

基于虚拟机部署是最为传统的云平台部署方式，类似于本地部署在服务器上的方式，用户拥有对虚拟机的完全控制权。

1. 创建虚拟机实例: 在云平台控制台中创建虚拟机实例，选择合适的操作系统 (例如 Ubuntu, CentOS, Windows Server) 和实例规格 (CPU, 内存, 存储)。

2. 配置安全组/防火墙: 配置虚拟机实例的安全组或防火墙规则，开放 Web UI 访问端口 (例如 7788) 和 SSH 端口 (22)。

3. 远程连接虚拟机: 使用 SSH 客户端 (例如 PuTTY, Termius) 远程连接到虚拟机实例。

4. 安装和配置环境: 在虚拟机实例中安装 Python 环境、Git、Playwright 等依赖，并按照本地部署方案的步骤配置 Browser-use 应用。

5. 启动应用: 在虚拟机实例中启动 Browser-use Web UI。

6. 配置域名和 SSL (可选): 如果需要通过域名访问，可以将域名解析到虚拟机实例的公网 IP 地址，并配置 Web 服务器 (例如 Nginx, Apache) 反向代理到 Browser-use Web UI，并配置 SSL 证书启用 HTTPS。

4.2.3.3.2 基于容器服务 (例如 Kubernetes, ECS) 部署

基于容器服务部署是更现代化的云平台部署方式，利用容器编排技术，可以实现应用的自动化部署、弹性伸缩、负载均衡和高可用性。

1. 构建 Docker 镜像: 按照 Docker 部署方案的步骤构建 Browser-use 的 Docker 镜像，并将镜像推送到云平台的容器镜像仓库 (例如 AWS ECR, Azure ACR, GCP GCR)。

2. 创建容器集群: 在云平台控制台中创建容器集群 (例如 Kubernetes 集群, ECS 集群)。

3. 部署应用: 在容器集群中部署 Browser-use 应用，可以通过 Kubernetes Deployment, Service, Ingress 等资源对象来定义应用的部署配置、服务暴露和路由规则。

4. 配置弹性伸缩: 配置容器集群的弹性伸缩策略，例如基于 CPU 使用率或请求数量自动调整容器副本数。

5. 配置负载均衡: 配置云平台的负载均衡器 (例如 AWS ELB, Azure Load Balancer, GCP Load Balancer) 将外部流量分发到容器集群中的 Browser-use 应用实例。

6. 配置域名和 SSL (可选): 将域名解析到负载均衡器的公网 IP 地址，并在负载均衡器上配置 SSL 证书启用 HTTPS。

4.2.3.3.3 基于 Serverless 函数部署 (适用性较低)

基于 Serverless 函数部署，例如 AWS Lambda, Azure Functions, GCP Cloud Functions，理论上也可以部署 Browser-use 应用，但由于 Serverless 函数的执行环境限制 (例如执行时间限制、资源限制、无状态性)，以及 Browser-use 应用的特性 (例如需要长时间运行的浏览器实例、状态保持)，Serverless 函数可能并非 Browser-use 的最佳部署选择，适用性较低。

如果选择 Serverless 函数部署，需要将 Browser-use 应用及其依赖打包成 Serverless 函数的部署包，并配置函数触发器、资源限制、环境变量等。由于 Browser-use 涉及到浏览器自动化，可能需要考虑使用 Headless Chrome 或 Playwright 的 Serverless 版本，并处理好函数的并发和状态管理问题。

4.2.3.4 云平台部署架构图 (以容器服务 Kubernetes 为例)

图 4.2.3 云平台容器服务 (Kubernetes) 部署架构图

该架构图展示了基于云平台容器服务 Kubernetes 的部署方案。用户请求首先到达云平台负载均衡器，负载均衡器将请求分发到 Kubernetes Service，Service 通过服务发现机制将请求路由到后端的 Kubernetes Pod (运行 Browser-use Web UI 容器)。Kubernetes 负责容器的编排、管理、弹性伸缩和滚动更新。

4.2.3.5 优缺点分析

优点：

• 高可用性: 云平台通常提供多可用区部署、自动故障转移、健康检查等机制，可以保证 Browser-use 应用的高可用性，避免单点故障。

• 弹性伸缩: 云平台可以根据应用负载情况自动进行弹性伸缩，动态调整计算资源，应对流量高峰和低谷，提高了资源利用率和成本效益。

• 按需付费: 云平台采用按需付费模式，用户只需为实际使用的资源付费，无需预先购买大量硬件资源，降低了初期投入成本。

• 全球覆盖: 云平台在全球各地都部署了数据中心，用户可以选择就近的数据中心部署应用，降低网络延迟，提高用户体验。

• 丰富的云服务: 云平台提供了丰富的云服务，例如数据库、缓存、消息队列、监控告警等，可以方便地构建和扩展 Browser-use 应用的功能。

• 简化运维: 云平台负责基础设施的运维和管理，用户只需关注应用自身的开发和维护，降低了运维负担。

• 安全性: 云平台通常提供完善的安全机制，例如网络隔离、安全审计、DDoS 防护等，可以提高 Browser-use 应用的安全性。

缺点：

• 成本较高 (长期运行): 长期运行的云平台部署方案，总成本可能会高于本地部署，尤其是在资源使用率较低的情况下。

• 复杂性: 云平台部署涉及到较多的云服务和配置，例如虚拟机、容器服务、负载均衡器、网络配置、安全组等，对于不熟悉云平台的用户，可能存在一定的复杂性。

• 依赖云平台: 云平台部署方案依赖于特定的云服务提供商，一旦选择云平台，迁移到其他云平台或本地环境可能会比较困难，存在一定的厂商锁定风险。

• 网络延迟 (跨境访问): 如果用户和云平台数据中心地理位置较远，可能会存在一定的网络延迟，影响用户体验。

• 数据安全和隐私 (合规性): 将数据存储在云平台上，需要考虑数据安全和隐私问题，例如数据加密、访问控制、合规性要求 (例如 GDPR, CCPA)。

4.2.3.6 适用场景

• 高流量、高并发应用: 云平台部署非常适合高流量、高并发的应用，可以利用云平台的弹性伸缩和负载均衡能力，应对高负载场景。

• 需要高可用性和可靠性的应用: 对于需要 24/7 稳定运行的应用，云平台部署可以提供高可用性和可靠性保障。

• 面向全球用户的应用: 如果 Browser-use 应用需要面向全球用户提供服务，云平台全球数据中心部署可以降低网络延迟，提高用户体验。

• 快速增长型应用: 对于业务快速增长的应用，云平台部署可以方便地进行弹性伸缩，快速扩展计算资源，满足业务增长需求。

• 需要集成云服务的应用: 如果 Browser-use 应用需要与其他云服务 (例如云数据库、云存储、云 AI 服务) 集成，云平台部署可以提供更便捷的集成方式。

• 缺乏运维能力的企业或个人: 对于缺乏专业运维团队的企业或个人，云平台部署可以降低运维负担，将运维工作交给云平台服务商。

4.2.4 部署方案选择建议

选择哪种部署方案取决于用户的具体需求、技术能力、预算以及对性能、安全性、可扩展性等方面的考量。以下是一些选择建议：

• 开发测试阶段: 本地部署 或 Docker 部署 是较为合适的选择。本地部署简单快捷，适合快速验证功能；Docker 部署可以提供一致的开发测试环境，方便团队协作。

• 个人使用或小规模应用: 本地部署 或 Docker 部署 可以满足需求。本地部署成本最低，但资源受限；Docker 部署更易于管理和迁移。

• 中大规模应用或生产环境: Docker 部署 或 云平台部署 更为推荐。Docker 部署提高了可移植性和一致性；云平台部署提供了高可用性、弹性伸缩和更强的性能。

• 高流量、高并发、高可用性应用: 云平台部署 是最佳选择。云平台能够提供强大的计算资源、负载均衡、弹性伸缩和高可用性保障，满足大规模应用的需求。

• 数据敏感型应用: 如果对数据安全性要求极高，且不允许数据离开本地环境，本地部署 是更安全的选择。但如果选择云平台部署，需要采取严格的数据加密、访问控制和合规性措施。

• 预算有限: 本地部署 成本最低，但需自行承担硬件和维护成本；Docker 部署 成本适中，但需要一定的 Docker 技术能力；云平台部署 成本较高，但可以按需付费，并享受云平台的各种优势。

• 技术能力: 如果用户技术能力较强，熟悉 Docker 和云平台技术，可以选择 Docker 部署 或 云平台部署；如果技术能力有限，本地部署 可能更易于上手。