Containers như một Dịch vụ cho Web Scraping với Scrapeless

TL;DR:

• Containers như một dịch vụ quản lý thời gian chạy cho các công nhân quét web. Ứng dụng của bạn vẫn xác định mục tiêu, xác thực phản hồi và quyết định nơi các bản ghi thuộc về.
• Scrapeless Web Unlocker xử lý yêu cầu truy cập web bên ngoài container công nhân. Container cần một khách hàng HTTP thay vì một trình duyệt cài đặt sẵn trên địa phương cho quy trình làm việc này.
• Một quy trình hoàn thành không chứng minh dữ liệu có ích. Kiểm tra nội dung mục tiêu trước khi ghi lại một bản ghi được chấp nhận.
• Bí mật thời gian chạy và lưu trữ bền bỉ thuộc bên ngoài hình ảnh. Một container thay thế nên bắt đầu từ cấu hình, không phục hồi thông tin xác thực từ một hệ thống tệp cũ.
• Miễn phí để bắt đầu. Tạo một tài khoản Scrapeless và sử dụng tín dụng miễn phí có sẵn để đánh giá một khối lượng công việc nhỏ.

Giới thiệu: Một Container Nên Làm Một Công Việc Dễ Dự Đoán

Một công nhân quét web dành phần lớn thời gian của nó để chờ đợi một hệ thống khác. Nó gửi một yêu cầu, chờ một trang, kiểm tra phản hồi và viết một kết quả. Đóng gói những bước đó trong một container giúp môi trường thực thi trở nên lặp lại. Nó không xác định xem trang đã trả có chứa thông tin mà ứng dụng cần hay không.

Containers như một dịch vụ, hay CaaS, cung cấp cho một nhóm hạ tầng được quản lý để triển khai và chạy những container đó. Câu hỏi thiết kế hữu ích là nơi đặt mỗi trách nhiệm. Thời gian chạy lên lịch cho công nhân. Công nhân sở hữu nhiệm vụ. Một dịch vụ truy cập web xử lý yêu cầu mục tiêu. Lưu trữ giữ lại bằng chứng sau khi công nhân thoát.

Hướng dẫn này phát triển một công nhân Python nhỏ xung quanh Scrapeless Web Unlocker và cho thấy cách đóng gói nó cho một nền tảng container. Sự tách biệt tương tự là hữu ích trong một pipeline giá cả cạnh tranh, nơi việc thu hồi trang chỉ là một giai đoạn trước khi chuẩn hóa và phân tích dữ liệu.

Những Gì Containers như Một Dịch Vụ Thực Sự Quản Lý

Containers như một dịch vụ quản lý việc thực thi container trong khi ứng dụng của bạn giữ trách nhiệm cho công việc và dữ liệu của nó. Tùy thuộc vào nền tảng, lớp quản lý có thể bao gồm lên lịch, phân bổ tài nguyên, kết nối mạng, kiểm tra sức khỏe và quy mô.

Một Dockerfile mô tả cách xây dựng một hình ảnh. Một hình ảnh là ứng dụng được đóng gói. Một container là một phiên bản đang chạy. Một bộ điều phối quyết định nơi và khi nào các phiên bản chạy. Những khái niệm này hoạt động cùng nhau, nhưng chỉ một Dockerfile không cung cấp một nền tảng quản lý. Mô hình xây dựng Dockerfile là điểm khởi đầu cho việc đóng gói công nhân bên dưới.

CaaS hữu ích khi cùng một công nhân phải chạy lặp đi lặp lại qua các môi trường hoặc khi khối lượng công việc yêu cầu nhiều công nhân. Một kịch bản cục bộ đơn lẻ có thể đủ cho một lần xuất định kỳ. Chọn một thời gian chạy quản lý khi các lợi ích hoạt động của nó biện minh cho việc triển khai và một công việc giám sát.

Pipeline Ngắn Gọn

Pipeline biến một URL được phê duyệt thành một phản hồi trang được lưu trữ với một quyết định xác thực rõ ràng. Bắt đầu với một nhiệm vụ mỗi quy trình, sau đó thêm một hàng đợi khi hợp đồng nhiệm vụ ổn định.

Chuỗi này là: đầu vào nhiệm vụ → yêu cầu Web Unlocker → thu nhận phản hồi → kiểm tra nội dung mong đợi → bản ghi được chấp nhận. Phần trình diễn ghi vào một thư mục đầu ra đã gắn kết. Một triển khai sản xuất nên thay thế thư mục đó bằng lưu trữ bền vững hoặc một khối lượng lưu trữ thích hợp với nền tảng đã chọn.

Scrapeless Web Unlocker nằm trong bước truy cập. Nó không phải là một bộ lập lịch container, hàng đợi hoặc cơ sở dữ liệu. Giữ rõ ràng ranh giới đó làm cho có thể thay đổi nền tảng triển khai mà không cần viết lại chính sách trích xuất.

Điều Kiện Tiên Quyết

Bạn cần Python, gói Requests, một khóa API Scrapeless đang hoạt động và một mục tiêu công khai mà bạn được ủy quyền để thu thập. Thiết lập SCRAPELESS_API_KEY, TARGET_URL, và EXPECTED_TEXT trong môi trường thời gian chạy. Giá trị cuối cùng là một cụm từ nên xuất hiện trong trang dự kiến, không phải là một trình phát hiện thử thách toàn cầu.
Thực thi container cũng yêu cầu Docker hoặc một runtime biên dịch tương thích. Triển khai yêu cầu một registry container và một tài khoản hoặc cụm CaaS đã được cấu hình. Thực thi Scrapeless xác thực và việc xây dựng container là điều kiện tiên quyết phụ thuộc vào môi trường cho ví dụ; không có phản hồi dịch vụ thành công hoặc triển khai được quản lý nào được chứng minh ở đây.

Đối với phụ thuộc Python cục bộ, chạy python -m pip install requests. Hợp đồng yêu cầu Web Unlocker xác định diễn viên và phong bì yêu cầu được sử dụng bên dưới.

Giai đoạn 1: Viết một Worker Page Bị Giới Hạn

Worker gửi một yêu cầu và giữ lại phản hồi thô của nó trước khi quyết định xem trang có chấp nhận được hay không. Lưu lại đoạn sau đây dưới dạng worker.py.

Lưu ý: Khối này yêu cầu khóa API Scrapeless của bạn và một mục tiêu đã được phê duyệt. Yêu cầu xác thực chưa được thực hiện cho ví dụ này; xác minh phản hồi với tài khoản của bạn trước khi triển khai.

import hashlib
import json
import os
import time
from pathlib import Path

import requests

url = os.environ["TARGET_URL"]
expected = os.environ["EXPECTED_TEXT"]
output = Path(os.environ.get("OUTPUT_DIR", "/output"))
output.mkdir(parents=True, exist_ok=True)
response = requests.post(
    "https://api.scrapeless.com/api/v2/unlocker/request",
    headers={"x-api-token": os.environ["SCRAPELESS_API_KEY"]},
    json={
        "actor": "unlocker.webunlocker",
        "input": {"url": url, "method": "GET", "redirect": False},
        "proxy": {"country": "ANY"},
    },
    timeout=120,
)
response.raise_for_status()
body = response.content
capture_id = hashlib.sha256(body).hexdigest()
(output / f"{capture_id}.response").write_bytes(body)
if expected.casefold() not in response.text.casefold():
    raise RuntimeError("Expected page content was not found")
record = {
    "requested_url": url,
    "collected_at_unix": int(time.time()),
    "response_sha256": capture_id,
    "response_bytes": len(body),
    "http_status": response.status_code,
    "validation": "expected_text_present",
}
(output / f"{capture_id}.json").write_text(json.dumps(record, indent=2))
print(json.dumps(record))

Bản ghi là một đầu ra được định nghĩa bởi ứng dụng, không phải là một tuyên bố về các trường phản hồi của Scrapeless. Phản hồi thô được giữ lại mà không giả định rằng mọi mục tiêu đều sản xuất cùng một loại nội dung. Thời gian chờ được cấu hình giới hạn thời gian chờ của client; nó không định nghĩa một đảm bảo ở mức độ dịch vụ.

Một cụm từ được mong đợi là một kiểm tra tối thiểu. Đối với dữ liệu có cấu trúc, hãy thay thế nó bằng một bộ phân tích yêu cầu các trường cần thiết và xác minh loại của chúng. Một tiêu đề xuất hiện trong thông báo lỗi không nên đủ điều kiện là một bản ghi sản phẩm hợp lệ. ngữ nghĩa phản hồi HTTP mô tả các kết quả giao thức; sự xác thực kinh doanh thuộc về ứng dụng của bạn.

Bắt Đầu Cào Dữ Liệu với Scrapeless

Khởi động quy trình làm việc cào dữ liệu 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 cần thẻ tín dụng.

Nhận tín dụng miễn phí của bạn ngay bây giờ trong Scrapeless Dashboard.

Giai đoạn 2: Đóng Gói Worker Không Có Thông Tin Đăng Nhập

Hình ảnh nên chứa mã và phụ thuộc trong khi runtime cung cấp các bí mật. Đặt Dockerfile này bên cạnh worker.py.

Lưu ý: Xây dựng cấu hình này yêu cầu một runtime container đã được cài đặt và truy cập registry. Việc xây dựng hình ảnh và thực thi container vẫn là các điều kiện tiên quyết cho triển khai; cấu hình không phải là kết quả triển khai được ghi lại.

FROM python:3.12-slim
WORKDIR /app
RUN pip install --no-cache-dir requests
COPY worker.py /app/worker.py
CMD ["python", "/app/worker.py"]

Hình ảnh tối thiểu này cố ý giữ việc quản lý phụ thuộc ở trạng thái rõ ràng. Để phát hành, hãy giải quyết và khóa các phiên bản phụ thuộc trong môi trường xây dựng của bạn, quét hình ảnh kết quả và triển khai bản tóm tắt hình ảnh mà bạn đã phê duyệt. Không để khóa API trong Dockerfile, đối số xây dựng, hoặc tệp môi trường đã sao chép. Một cấu hình bí mật trong runtime giữ việc giao nhận thông tin đăng nhập tách biệt khỏi hình ảnh.

Đối với kiểm tra container cục bộ, chuẩn bị các biến môi trường trong shell của bạn và tạo một thư mục output có thể ghi trước khi chạy các lệnh bên dưới. Việc truyền một biến môi trường bằng tên tránh việc ghi giá trị của nó vào lệnh.

Lưu ý: Những lệnh này yêu cầu Docker, các tệp ở trên, và cấu hình runtime xác thực. Chúng chưa được chạy trên một động cơ Docker cục bộ trong ví dụ này.

docker build -t scrapeless-page-worker .
mkdir -p output
docker run --rm \
  -e SCRAPELESS_API_KEY -e TARGET_URL -e EXPECTED_TEXT \
  -v "$PWD/output:/output" \
  scrapeless-page-worker

Mã thoát bằng không có nghĩa là worker này đã đạt được câu lệnh in cuối cùng của nó. Xác nhận rằng bản chụp thô và tệp metadata đều tồn tại, kiểm tra nội dung trang và kiểm tra rằng mục tiêu được cấu hình khớp với nguồn dự kiến trước khi coi ví dụ này là đã được chấp nhận.

Giai đoạn 3: Triển Khai Như Một Công Việc, Sau Đó Giới Thiệu Một Hàng Đợi

Một công việc là hình thức triển khai tự nhiên cho một worker xử lý một đầu vào bị giới hạn và thoát. Khối lượng công việc Kubernetes Job đại diện cho mẫu thực thi này trên các nền tảng dựa trên Kubernetes; các hệ thống container được quản lý khác tiết lộ các khái niệm tác vụ hoặc công việc tương tự với cấu hình khác nhau.

Chọn một nền tảng và cấu hình tham chiếu hình ảnh, lệnh, tiêm bí mật, đích đầu ra và thời hạn tác vụ của nó. Chạy cùng một tập hợp mục tiêu nhỏ đã sử dụng cục bộ. So sánh các bản ghi đã chấp nhận, phản hồi bị từ chối, và tổng sử dụng dịch vụ trước khi tăng số lượng worker.

Một hàng đợi trở nên hữu ích khi các công việc cần lập lịch chia sẻ. Định nghĩa một định danh tác vụ vẫn ổn định khi cùng một quan sát đã được lên lịch được truyền đi nhiều lần. Bao gồm cả khoảng thời gian quan sát trong định danh đó nếu mục đích là để thu thập các bức ảnh chụp theo thời gian. Nếu không, một khóa chỉ URL có thể làm sai lệch các quan sát khác nhau.
Ghi lại bản ghi đã được chấp nhận trước khi xác nhận hoàn thành. Sử dụng định danh nhiệm vụ để ngăn chặn việc ghi trùng lặp. Thay thế container không được chuyển đổi một thao tác lưu trữ không chắc chắn thành một bản ghi kinh doanh thứ hai.

Giai đoạn 4: Đo Lường Bản Ghi Được Chấp Nhận và Chi Phí Tài Nguyên

Giám sát người lao động nên phân biệt sức khỏe quy trình với chất lượng dữ liệu. Theo dõi các bản ghi được chấp nhận, phản hồi bị từ chối, tuổi hàng đợi và thời gian chờ đợi dịch vụ. Việc sử dụng CPU một mình có thể là một tín hiệu mở rộng kém cho một ứng dụng chủ yếu chờ phản hồi từ mạng.

Giữ cho độ đồng thời ban đầu nhỏ và gắn công việc theo từng mục tiêu. Một giới hạn khởi động nội bộ tối đa ba người lao động mỗi máy chủ là một ví dụ cẩn thận, không phải một quy định chung cho trang web. Chính sách trang web và giới hạn tài khoản có thể yêu cầu một giá trị thấp hơn.

So sánh chi phí thời gian chạy container với việc sử dụng Scrapeless thực tế trên trang định giá. Không suy luận việc tiêu thụ API từ thời gian hoạt động của người lao động: một container đang chạy có thể không hoạt động, trong khi một công việc ngắn có thể thực hiện nhiều thao tác tính phí.

Bảo vệ phản hồi thô theo nội dung của chúng. Các tiêu đề yêu cầu, cookie và bất kỳ tài liệu phiên được ủy quyền nào cần xử lý chặt chẽ hơn so với văn bản trang công khai. Chỉ giữ lại các bằng chứng cần thiết cho nhiệm vụ khai thác.

Kết luận: Triển khai Hợp đồng Bạn Có Thể Xác Thực

Một quy trình làm việc CaaS khai thác hữu ích có một hợp đồng nhiệm vụ nhỏ, một người lao động kiểm tra đầu ra của nó và lưu trữ tồn tại sau khi quy trình kết thúc. Bắt đầu với người lao động trên một trang, xác minh việc xử lý phản hồi của nó với tài khoản của bạn, và chạy cùng một mã bên trong một container trước khi thêm sự phối hợp.

Cột mốc triển khai tiếp theo là một bản ghi được chấp nhận với nguồn gốc và bằng chứng thu thập. Số lượng người lao động sẽ đến sau khi kết quả đó có thể tái tạo.

Sẵn Sàng Xây Dựng Đường Ống Dữ Liệu Web Của Bạn?

Tham gia cùng các nhà phát triển đang làm việc trên việc thu thập dữ liệu web trong Discord và Telegram.

Tạo một tài khoản Scrapeless và điều chỉnh quy trình làm việc cho các nguồn dữ liệu của riêng bạn được phê duyệt.

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

Q: Việc khai thác từ một container có khác về pháp lý so với chạy một script cục bộ không?

Việc triển khai container không thay đổi quyền truy cập hoặc nghĩa vụ sử dụng dữ liệu cho mục tiêu. Xem xét các điều khoản và quy định áp dụng cho các nguồn và dữ liệu liên quan.

Q: Một nền tảng CaaS có cung cấp proxy cho người lao động này không?

Người lao động này ủy quyền yêu cầu mục tiêu của nó cho Web Unlocker và sử dụng cấu hình proxy đã được tài liệu hóa trong yêu cầu đó. IP outbound của một container không tự động là một proxy cư dân.

Q: Điều gì sẽ xảy ra khi phản hồi là một trang từ chối truy cập?

Từ chối trang đó như dữ liệu nhiệm vụ và giữ lại một bản ghi chẩn đoán tối thiểu. Kiểm tra phạm vi mục tiêu và đường dẫn truy cập được hỗ trợ trước khi ủy quyền công việc thu thập khác.

Q: Điều gì thay đổi khi HTML của trang web thay đổi?

Cập nhật và xác thực hợp đồng khai thác. Đóng gói mã trong một container không làm cho các bộ chọn hoặc nội dung dự kiến miễn dịch với sự thay đổi của trang.

Q: Có bao nhiêu người lao động nên chạy cùng một lúc?

Bắt đầu với một khối lượng công việc nhỏ và đo lường đầu ra được chấp nhận theo từng mục tiêu. Giới hạn ba người lao động mỗi máy chủ của ví dụ là một cài đặt ứng dụng, phải tuân thủ các giới hạn mục tiêu và tài khoản nghiêm ngặt hơn.

Q: Quy trình làm việc này có yêu cầu một tác nhân AI không?

Không. Người lao động Python và các lệnh container chạy mà không cần mô hình ngôn ngữ. Một tác nhân có thể tạo nhiệm vụ, nhưng nó không nên thay thế các kiểm tra nội dung xác định của người lao động.