Quay lại blog

Cách Chạy Playwright trong Docker: 3 Mô Hình Triển Khai

James Thompson
James Thompson

Scraping and Proxy Management Expert

20-Aug-2026

TL;DR:

  • Playwright trong Docker có ba mô hình triển khai thực tiễn. Sử dụng hình ảnh chính thức, xây dựng một hình ảnh trình duyệt có kiểm soát, hoặc giữ trình chạy thử nghiệm trong một container và di chuyển trình duyệt đến Scrapeless Scraping Browser.
  • Gói Playwright và hình ảnh trình duyệt phải đồng ý về một dòng phát hành. Một sự không phù hợp giữa gói/hình ảnh có thể khiến client tìm kiếm các executable trình duyệt mà hình ảnh không chứa.
  • Chromium cần xử lý quy trình và bộ nhớ rõ ràng trong một container. Chạy một quy trình khởi tạo, cung cấp bộ nhớ chia sẻ đầy đủ cho Chromium và bảo tồn sandbox cho các trang không tin cậy.
  • Một hình ảnh tùy chỉnh chỉ có giá trị bảo trì khi phông chữ, chứng chỉ, gói hệ thống, hoặc chính sách trình duyệt phải được sửa chữa trong artifact. Nếu không, hình ảnh chính thức là cơ sở đơn giản hơn.
  • Một trình duyệt đám mây từ xa loại bỏ các nhị phân trình duyệt khỏi hình ảnh ứng dụng. Mã Playwright vẫn ở trong CI trong khi Scrapeless vận hành trình duyệt đám mây và luồng ra khu vực.
  • Miễn phí để bắt đầu. Các tài khoản Scrapeless mới bao gồm thời gian chạy Scraping Browser miễn phí — đăng ký tại app.scrapeless.com.

Giới thiệu: Đóng gói Playwright có nghĩa là đóng gói một trình duyệt

Mã Playwright là một phụ thuộc Node.js nhỏ; các trình duyệt và thư viện Linux của chúng là phần nặng. Một container chỉ cài đặt gói có thể xây dựng thành công nhưng vẫn thất bại khi Chromium khởi động vì các executable, phông chữ, thư viện chia sẻ, quyền sandbox, hoặc bộ nhớ chia sẻ đang bị thiếu.

Lựa chọn triển khai vì vậy là kiến trúc. Hình ảnh chính thức kết hợp Playwright với một môi trường trình duyệt chuẩn bị. Một hình ảnh tùy chỉnh cho bạn quyền kiểm soát hệ điều hành. Một trình duyệt từ xa giữ cho container ứng dụng tập trung vào mã thử nghiệm hoặc trích xuất và di chuyển hoạt động trình duyệt sang một dịch vụ riêng biệt.

Hướng dẫn này so sánh cả ba mô hình với Playwright 1.62.0, phiên bản được ghim vào hình ảnh chính thức và được tải trong quá trình xác minh.

Tại sao Playwright bị lỗi trong các container

Playwright trong Docker thường thất bại ở một trong năm ranh giới.

Ranh giới Triệu chứng điển hình Phản ứng thiết kế
Executable trình duyệt “Executable không tồn tại” Ghim gói và hình ảnh lại với nhau
Thư viện Linux Trình duyệt thoát trong quá trình khởi động Bắt đầu từ một hình ảnh đã sẵn sàng trình duyệt hoặc cài đặt các phụ thuộc một cách rõ ràng
Bộ nhớ chia sẻ Trình render đóng khi tải trang Cung cấp cho Chromium cấu hình IPC/bộ nhớ chia sẻ thích hợp
Vòng đời quy trình Các quy trình con chết dồn lại Chạy một quy trình khởi tạo như PID 1
Sandbox/người dùng Trình duyệt chỉ khởi động với cách ly yếu đi Chạy như một người dùng không phải root với chính sách kernel cần thiết

Hướng dẫn Playwright Docker chính thức ghi lại các hình ảnh đã chuẩn bị, sự tương thích phiên bản, --init, bộ nhớ chia sẻ, và mô hình người dùng riêng biệt cho các trang không tin cậy.

Ba mô hình triển khai qua cái nhìn

Mô hình Vị trí trình duyệt Bảo trì hình ảnh Phù hợp nhất
Hình ảnh Playwright chính thức Cùng container với trình chạy Thấp CI và các mục tiêu thử nghiệm có kiểm soát
Hình ảnh trình duyệt tùy chỉnh Cùng container với trình chạy Cao Phông chữ, chứng chỉ, gói, hoặc chính sách cố định
Trình duyệt đám mây Scrapeless Bên ngoài container ứng dụng Lớp trình duyệt được quản lý riêng Các trang động, luồng ra khu vực, mở rộng trình duyệt độc lập

Đừng chọn chỉ dựa vào kích thước hình ảnh. Tính đến bảo mật trình duyệt, quyền nâng cấp, độ đồng thời, độ tin cậy trang, khả năng tái tạo artifact, và liệu trình duyệt có cần truy cập mạng khác với trình chạy thử nghiệm hay không.

Điều kiện tiên quyết

  • Node.js 20 trong dự án ứng dụng.
  • Playwright 1.62.0 trong package.json.
  • Docker cho hai mô hình đầu tiên.
  • Một tài khoản Scrapeless và khóa API cho mô hình trình duyệt từ xa.
  • Một mục tiêu thử nghiệm đã được chấp thuận hoặc trang công cộng.

Lưu ý: Docker không được cài đặt trong môi trường xác minh, vì vậy các lệnh xây dựng Docker và container bên dưới là các khoảng cách điều kiện tiên quyết. Các gói Playwright và Scrapeless SDK chính xác đã được cài đặt; một trang Chromium cục bộ đã tải thành công, và xuất Playwright.connect của SDK đã được xác nhận là có thể gọi được.

Lựa chọn 1 — Sử dụng Hình ảnh Playwright Chính thức

Hình ảnh chính thức là cơ sở tốt nhất khi container chạy các thử nghiệm đầu cuối đáng tin cậy và bạn không cần tùy chỉnh hệ điều hành.

Ghim gói và hình ảnh vào cùng một dòng phát hành Playwright:

dockerfile Copy
FROM mcr.microsoft.com/playwright:v1.62.0-noble

WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .

USER pwuser
CMD ["node", "check.mjs"]

Xây dựng và chạy nó với một quy trình khởi tạo và chính sách IPC rõ ràng:

bash Copy
docker build -t playwright-check:1.62.0 .
docker run --rm --init --ipc=host playwright-check:1.62.0

Giữ mô hình tin cậy của mục tiêu rõ ràng. Một trình duyệt chạy với quyền root mà không có sandbox của nó có thể được chấp nhận cho các thử nghiệm nội bộ có kiểm soát, nhưng nó không phải là mặc định cho các trang tùy ý. Hướng dẫn hướng dẫn bảo mật container ứng dụng NIST xem xét nguồn gốc hình ảnh, cấu hình thời gian chạy, kiểm soát máy chủ và cách ly khối lượng công việc như các lớp riêng biệt.

Lựa chọn 2 — Xây dựng một Hình ảnh Trình duyệt Có Kiểm Soát

Một hình ảnh tùy chỉnh hữu ích khi trình duyệt cần chứng chỉ tổ chức, phông chữ ngôn ngữ, thư viện phương tiện, hoặc một phân phối cơ sở phù hợp với phần còn lại của nền tảng.

Dockerfile nhỏ nhất bắt đầu từ một cơ sở Debian được hỗ trợ và yêu cầu Playwright cài đặt trình duyệt và các phụ thuộc hệ điều hành của nó:

dockerfile Copy
FROM node:20-bookworm

WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
RUN npx playwright install --with-deps chromium

RUN useradd --create-home --shell /usr/sbin/nologin runner \
    && chown -R runner:runner /app
USER runner

COPY --chown=runner:runner . .
CMD ["node", "check.mjs"]

Ghim phiên bản Node bằng cách sử dụng digest trong môi trường sản xuất và xây dựng lại khi gói trình duyệt thay đổi. Hình ảnh bây giờ thuộc về nhóm của bạn: quét lỗ hổng, chứng chỉ, phông chữ, cập nhật trình duyệt, và làm mới hình ảnh cơ sở đều chuyển vào quy trình phát hành của bạn.

Bộ nhớ chia sẻ, Sandbox, Phông chữ, và PID 1

Sự ổn định của container phụ thuộc vào hợp đồng thời gian chạy xung quanh Chromium.

Bộ nhớ chia sẻ. Chromium sử dụng bộ nhớ chia sẻ cho các quy trình trình diễn. Quyết định chính sách IPC hoặc /dev/shm trong cấu hình triển khai thay vì phát hiện nó sau khi một trình diễn đóng lại dưới tải.

Sandbox. Chạy các trang không tin cậy như một người dùng không phải gốc và duy trì sandbox của trình duyệt. Linux seccomp có thể giới hạn các lệnh gọi hệ thống mà một quy trình có thể truy cập; tài liệu về seccomp của Linux mô tả ranh giới kernel đó.

Phông chữ và địa phương. Một trình duyệt có thể hoạt động chức năng tốt trong khi tạo ra lỗi trong việc ngắt dòng, thiếu glyph, hoặc sự khác biệt trong ảnh chụp màn hình. Chỉ cài đặt các gói ngôn ngữ mà hợp đồng thử nghiệm yêu cầu và xác nhận một glyph đại diện trong quá trình xác thực hình ảnh.

PID 1. Chromium tạo ra các quy trình con. Một quy trình khởi tạo nên nhận tín hiệu và thu hoạch trẻ em. tài liệu cấu hình thời gian thực Open Container Initiative định nghĩa các trường quy trình và thời gian thực của Linux mà một thời gian chạy container phù hợp sẽ tiêu thụ.

Bắt đầu thu thập dữ liệu với Scrapeless

Nâng cao quy trình thu thập dữ liệu web và tự động hóa của bạn với Scrapeless!
Đăng ký ngay hôm nay và nhận $5 tín dụng miễn phíkhông yêu cầu thẻ tín dụng.

Nhận tín dụng miễn phí của bạn ngay bây giờ trong Bảng điều khiển Scrapeless.
Bảng điều khiển Scrapeless hiển thị $5.00 trong Tín dụng Đội

Tùy chọn 3 — Di chuyển Trình duyệt ra khỏi Container

Một trình duyệt đám mây từ xa tách biệt khách hàng Playwright khỏi quy trình trình duyệt. Hình ảnh CI giữ Node.js, mã thử nghiệm, và thư viện khách hàng; trình duyệt được quản lý sở hữu Chromium, các phụ thuộc của trình duyệt, vòng đời phiên, và đường thoát trình duyệt khu vực.

Cài đặt các gói giống nhau đã được sử dụng trong xác minh giao diện:

bash Copy
npm install playwright@1.62.0 @scrapeless-ai/sdk@1.11.0

Lưu ý: Mã bên dưới yêu cầu khóa API Scrapeless của bạn. Các gói nhập và Playwright.connect giao diện đã được thực thi cục bộ, nhưng môi trường không có thông tin xác thực không thể tạo phiên đám mây.

javascript Copy
import { Playwright } from "@scrapeless-ai/sdk";

const browser = await Playwright.connect({
  sessionName: "container-runner",
  sessionTTL: 300,
  proxyCountry: "US",
});

const context = browser.contexts()[0];
const page = await context.newPage();
await page.goto("https://example.com", { waitUntil: "domcontentloaded" });
console.log(await page.title());
await browser.close();

Hình ảnh ứng dụng không còn cần một nhị phân trình duyệt hoặc các thư viện Linux của nó. Điều đó giảm bớt sự gắn kết, nhưng nó giới thiệu một ranh giới mạng: giữ khóa API trong kho bí mật CI, hạn chế quyền truy cập ra ngoài, chọn khu vực được phê duyệt, và đóng mọi phiên một cách rõ ràng.

Đọc hướng dẫn bắt đầu thu thập dữ liệu trình duyệt, trang sản phẩm, và giá cả trước khi di chuyển khối lượng công việc sản xuất.

Kiểm tra Danh sách CI/CD và Mở rộng

  • Ghim gói Playwright, hình ảnh trình duyệt, và file khóa lại với nhau.
  • Thất bại trong quá trình xây dựng khi các dòng phát hành gói/hình ảnh khác nhau.
  • Chạy một lần điều hướng thử trước khi đầy đủ bộ.
  • Sử dụng người dùng trình duyệt không phải gốc cho các trang không tin cậy.
  • Cấu hình các trường init, IPC, CPU, bộ nhớ, và lưu trữ tạm thời một cách có chủ đích.
  • Giữ thông tin xác thực trong kho bí mật CI và ra ngoài các lớp hoặc nhật ký xây dựng.
  • Giới hạn công việc song song ở ba công nhân cho mỗi máy chủ mục tiêu trừ khi chủ sở hữu phê duyệt một trần khác.
  • Ghi lại trình duyệt, gói, hình ảnh, khu vực, và bản sửa đổi thử nghiệm với kết quả công việc.

Hướng dẫn proxy Playwright và trình duyệt đám mây mở rộng sự tách biệt tương tự cho chính sách proxy và thực thi từ xa.

Cách chọn

Sử dụng hình ảnh chính thức khi bạn muốn con đường ngắn nhất để có CI có thể tái tạo và các trang mục tiêu được kiểm soát. Xây dựng hình ảnh tùy chỉnh khi các phụ thuộc của trình duyệt là một phần của sản phẩm được kiểm tra của ứng dụng của bạn. Sử dụng Scrapeless Scraping Browser khi các tệp nhị phân của trình duyệt không nên sống trong hình ảnh của ứng dụng hoặc khi lớp trình duyệt cần được kiểm soát độc lập về khu vực và khả năng.

Một mô hình kết hợp là phổ biến: giữ một công việc hình ảnh chính thức nhỏ cho các thử nghiệm nội bộ xác định và gửi các hành trình web công khai được phê duyệt đến một trình duyệt đám mây được quản lý. Lựa chọn quan trọng là ai sở hữu vòng đời của trình duyệt cho từng loại công việc.

Kết luận: Đặt Trình Duyệt Vào Một Ranh Giới Rõ Ràng

Playwright trong Docker trở nên dự đoán được khi gói, trình duyệt, hệ điều hành và chính sách thời gian chạy được coi như một hợp đồng. Hình ảnh chính thức cung cấp hợp đồng đó. Hình ảnh tùy chỉnh cho phép bạn sở hữu nó. Trình duyệt đám mây từ xa chuyển nó ra ngoài bộ chứa ứng dụng.

Chọn ranh giới phù hợp với độ tin cậy của trang, khả năng bảo trì và nhu cầu mở rộng, sau đó gán và kiểm tra ranh giới như một phần của mỗi lần phát hành.


Sẵn sàng Đơn Giản Hóa Hạ Tầng Playwright?

Tham gia cộng đồng của chúng tôi để nhận một kế hoạch miễn phí và kết nối với các nhà phát triển điều hành tự động hóa trình duyệt trong CI: Discord · Telegram.

Đăng ký tại app.scrapeless.com để nhận thời gian chạy Scraping Browser miễn phí và thử nghiệm mẫu trình duyệt từ xa từ một trình chạy CI nhỏ.


Câu hỏi thường gặp

H: Hình ảnh Playwright chính thức có đủ cho CI sản xuất không?

Hình ảnh Playwright chính thức là một cơ sở mạnh mẽ khi dòng phát hành của nó khớp với gói dự án và chính sách thời gian chạy phù hợp với mức độ tin cậy của mục tiêu. Sản xuất vẫn cần quét hình ảnh, quản lý bí mật, giới hạn tài nguyên và chứng cứ cấp job.

H: Tại sao Playwright hoạt động cục bộ nhưng thất bại trong Docker?

Bộ chứa có thể thiếu tệp thực thi trình duyệt mong đợi, thư viện chia sẻ, phông chữ, chính sách bộ nhớ chia sẻ, quyền cát và xử lý tiến trình con. Kiểm tra những ranh giới đó trước khi thay đổi bộ chọn hoặc chờ đợi.

H: Có nên vô hiệu hóa cát trong container Playwright không?

Một bộ chứa truy cập các trang không đáng tin cậy nên bảo tồn cát của trình duyệt và chạy như một người dùng không root phù hợp. Sử dụng cát yếu chỉ cho một mô hình tin cậy được đội ngũ an ninh của bạn phê duyệt.

H: Liệu Playwright từ xa vẫn cần một proxy không?

Lớp trình duyệt vẫn cần một chính sách egress được phê duyệt. Scrapeless Scraping Browser có thể gắn các proxy dân cư ở 195+ quốc gia; gán quốc gia yêu cầu bởi thử nghiệm hoặc hợp đồng dữ liệu.

H: Điều gì xảy ra khi DOM mục tiêu thay đổi?

Chạy lại hành trình khói và kiểm tra các bộ định vị dựa trên vai trò, trạng thái trang và đầu ra đã được dựng. Sức khỏe của container không đảm bảo tính ổn định của bộ chọn.

H: Có bao nhiêu công nhân Playwright nên chạy trên một máy chủ?

Giữ không quá ba công nhân trên mỗi máy chủ trừ khi chủ sở hữu trang phê duyệt giới hạn khác. Mở rộng khả năng trình duyệt độc lập với độ đồng thuận của máy chủ mục tiêu.

H: Liệu triển khai này có thể chạy mà không cần một tác nhân AI không?

Có. Tất cả ba mẫu chạy mã Playwright tiêu chuẩn trực tiếp. Một tác nhân AI là tùy chọn và không thay đổi gói, container, trình duyệt hoặc các ranh giới ủy quyền.

Tại Scrapless, chúng tôi chỉ truy cập dữ liệu có sẵn công khai trong khi tuân thủ nghiêm ngặt các luật, quy định và chính sách bảo mật trang web hiện hành. Nội dung trong blog này chỉ nhằm mục đích trình diễn và không liên quan đến bất kỳ hoạt động bất hợp pháp hoặc vi phạm nào. Chúng tôi không đảm bảo và từ chối mọi trách nhiệm đối với việc sử dụng thông tin từ blog này hoặc các liên kết của bên thứ ba. Trước khi tham gia vào bất kỳ hoạt động cạo nào, hãy tham khảo ý kiến ​​cố vấn pháp lý của bạn và xem xét các điều khoản dịch vụ của trang web mục tiêu hoặc có được các quyền cần thiết.

Bài viết phổ biến nhất

Danh mục