ウェブスクレイピングのためのコンテナとしてのサービス - Scrapeless

TL;DR:

• サービスとしてのコンテナは、スクレイピングワーカーのランタイムを管理します。 あなたのアプリケーションは引き続きターゲットを定義し、レスポンスを検証し、レコードがどこに属するかを決定します。
• Scrapeless Web Unlockerは、ワーカーコンテナの外でウェブアクセスリクエストを処理します。 このワークフローには、ローカルにインストールされたブラウザではなくHTTPクライアントが必要です。
• 完了したプロセスは、役立つデータの証明ではありません。 受け入れられたレコードを書く前にターゲットコンテンツを確認してください。
• ランタイムの秘密と耐久性のあるストレージは、イメージの外に存在するべきです。 置き換えコンテナは、旧いファイルシステムから認証情報を回復するのではなく、構成から開始するべきです。
• 無料で始められます。 Scrapelessアカウントを作成し、利用可能な無料クレジットを使って小さなワークロードを評価します。

イントロダクション: コンテナは予測可能な仕事を1つ行うべきです

スクレイピングワーカーは、その生涯の多くを別のシステムを待ちながら過ごします。リクエストを送信し、ページを待ち、レスポンスを確認し、結果を書き込みます。これらのステップをコンテナにパッケージ化することで、実行環境が繰り返し可能になります。しかし、返されたページがアプリケーションに必要な情報を含んでいるかどうかは決定しません。

サービスとしてのコンテナ、つまりCaaSは、チームにこれらのコンテナをデプロイし実行するための管理されたインフラを提供します。重要な設計上の質問は、それぞれの責任をどこに置くかです。ランタイムはワーカーをスケジュールし、ワーカーはタスクを担当します。ウェブアクセスサービスはターゲットリクエストを処理し、ストレージはワーカーが終了した後の証拠を保持します。

このチュートリアルでは、Scrapeless Web Unlockerを使用して小さなPythonワーカーを開発し、それをコンテナプラットフォーム向けにパッケージ化する方法を示します。同じ分離は、競争価格パイプラインにおいても便利であり、データの正規化と分析の前にページの取得がただの1ステージであることを示しています。

サービスとしてのコンテナが実際に管理するもの

サービスとしてのコンテナは、コンテナの実行を管理し、あなたのアプリケーションがそのワークロードとデータの責任を保持します。プラットフォームに応じて、管理されるレイヤーはスケジューリング、リソース割り当て、ネットワーキング、ヘルスチェック、スケーリングをカバーできます。

Dockerfileは、イメージを構築する方法を記述します。イメージはパッケージ化されたアプリケーションです。コンテナは実行中のインスタンスです。オーケストレーターはインスタンスがどこでいつ実行されるかを決定します。これらの概念は連携しますが、Dockerfileだけでは管理されたプラットフォームを提供しません。Dockerfileビルドモデルは、以下のワーカーをパッケージ化するための出発点です。

CaaSは、同じワーカーを環境間で繰り返し実行する必要がある場合や、タスク量が複数のワーカーを必要とする場合に便利です。単一のローカルスクリプトが偶発的なエクスポートには十分かもしれません。運用の利点がデプロイメントと監視作業を正当化する場合は、管理されたランタイムを選択してください。

パイプラインの概観

パイプラインは、承認されたURLをストレージされたページレスポンスと明示的な検証決定に変換します。プロセスごとに1つのタスクから始め、タスク契約が安定した後にキューを追加します。

シーケンスは次の通りです：タスク入力 → Web Unlockerリクエスト → レスポンスキャプチャ → 期待コンテンツチェック → 受け入れられたレコード。デモでは、マウントされた出力ディレクトリに書き込みます。製品実装では、そのディレクトリを耐久性のあるストレージまたは選択したプラットフォームに適した永続ボリュームに置き換えるべきです。

Scrapeless Web Unlockerはアクセスステップに位置します。それはコンテナスケジューラー、キュー、またはデータベースではありません。この境界を明確に保つことで、抽出ポリシーを書き換えることなくデプロイメントプラットフォームを変更することが可能になります。

前提条件

Python、Requestsパッケージ、アクティブなScrapeless APIキー、および収集を許可されている公開ターゲットが必要です。ランタイム環境でSCRAPELESS_API_KEY、TARGET_URL、およびEXPECTED_TEXTを設定してください。最後の値は、意図されたページに出現するべきフレーズであり、ユニバーサルチャレンジディテクターではありません。
コンテナの実行には、Dockerまたは互換性のあるビルド実行環境が必要です。デプロイにはコンテナレジストリと構成されたCaaSアカウントまたはクラスターが必要です。認証されたScrapeless実行とコンテナビルドは、この例のための環境依存の前提条件です。ここでは、成功したサービスレスポンスや管理されたデプロイメントは主張されません。

ローカルPython依存関係については、python -m pip install requestsを実行してください。Web Unlockerリクエスト契約は、以下で使用されるアクターとリクエストエンベロープを定義します。

ステージ 1: 制限付きページワーカーを書く

ワーカーは1つのリクエストを送信し、ページが受け入れ可能かどうかを決定する前に、生のレスポンスを保持します。以下をworker.pyとして保存してください。

注: このブロックは、あなたのScrapeless APIキーと承認されたターゲットを必要とします。この例では、認証されたリクエストは実行されていません; デプロイ前にアカウントに対してレスポンスを検証してください。

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))

このレコードはアプリケーション定義の出力であり、Scrapelessレスポンスフィールドに関する主張ではありません。生のレスポンスは、すべてのターゲットが同じコンテンツタイプを生成するとは仮定せず保持されます。構成されたタイムアウトはクライアントの待機を制限しますが、サービスレベル保証を定義するものではありません。

期待されるフレーズは最小限のチェックです。構造化データの場合は、必要なフィールドを要求し、そのタイプを検証するパーサに置き換えてください。エラーメッセージに現れるタイトルは、有効な製品レコードとして資格を持つべきではありません。HTTPレスポンスセマンティクスはプロトコルの結果を説明します; ビジネスバリデーションはあなたのアプリケーションに属します。

Scrapelessでスクレイピングを開始

Scrapelessであなたのウェブスクレイピングとオートメーションワークフローを強化しましょう!
今日サインアップして**$5の無料クレジット**をゲット — クレジットカードは不要。

Scrapelessダッシュボードで今すぐ無料クレジットを請求してください。

ステージ 2: 資格情報なしでワーカーをパッケージ化する

イメージにはコードと依存関係が含まれているべきで、ランタイムが秘密を供給します。このDockerfileをworker.pyの隣に置いてください。

注: この構成をビルドするには、インストールされたコンテナランタイムとレジストリアクセスが必要です。イメージのビルドとコンテナの実行はデプロイメントの前提条件であり、この構成はキャプチャされたデプロイメント結果ではありません。

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"]

この最小イメージは、依存関係管理を明示的に保ったままです。リリースのためには、ビルド環境内で依存関係のバージョンを解決し、ロックし、生成されたイメージをスキャンし、承認されたイメージのダイジェストをデプロイしてください。Dockerfile、ビルド引数、またはコピーされた環境ファイルにAPIキーを配置しないでください。ランタイムシークレット構成は、資格情報の配信をイメージから分離します。

ローカルコンテナチェック用に、シェル内で環境変数を準備し、以下のコマンドを実行する前に書き込み可能なoutputディレクトリを作成してください。環境変数を名前で渡すと、その値をコマンドに書き込むことを避けられます。

注: これらのコマンドはDocker、上記のファイル、そして認証されたランタイム構成を必要とします。この例ではローカルDockerエンジンに対しては実行されていません。

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

ゼロの終了コードは、このワーカーが最終の印刷ステートメントに到達したことを意味します。生のキャプチャとメタデータファイルが両方存在することを確認し、ページの内容を検査し、構成されたターゲットが意図したソースと一致することを確認してから、この例を受け入れられたものとして扱ってください。

ステージ 3: ジョブとしてデプロイし、キューを導入する

ジョブは、制限された入力を処理して終了するワーカーの自然なデプロイメント形状です。Kubernetes Jobワークロードは、Kubernetesベースのプラットフォームでこの実行パターンを示します。他の管理されたコンテナシステムは、異なる構成で類似のタスクまたはジョブの概念を公開します。

1つのプラットフォームを選択し、そのイメージ参照、コマンド、シークレット注入、出力先、およびタスクの締切を構成してください。ローカルで使用したのと同じ小さなターゲットセットを実行します。受け入れられたレコード、拒否されたレスポンス、および総サービス使用量を比較し、ワーカーの数を増やす前に確認してください。

ジョブが共有スケジューリングを必要とする場合、キューは有用になります。同じスケジュールされた観察が複数回届けられるときに安定したタスク識別子を定義してください。その識別子に観察期間を含めると、時間をかけてスナップショットを収集することが目的である場合に役立ちます。そうでなければ、URLのみのキーが異なる観察を不正に圧縮する可能性があります。
記録が受け入れられる前に、確認を完了したことを認識します。重複した書き込みを防ぐためにタスク識別子を使用します。コンテナの置き換えは、不確実なストレージ操作を二次ビジネス記録に変えるべきではありません。

ステージ 4: 受け入れられた記録とリソースコストの測定

ワーカーの監視は、プロセスの健康状態とデータの品質を区別するべきです。受け入れられた記録、拒否された応答、キューの年齢、サービスの待機時間を追跡します。CPU使用率のみでは、主にネットワーク応答を待つアプリケーションにとってはスケーリングの信号として不十分かもしれません。

最初の同時実行性は小さく保ちながら、ターゲットごとに作業を制限します。1ホストあたり最大3ワーカーの内部開始制限は保守的な例示設定であり、普遍的なウェブサイトの許可ではありません。サイトポリシーとアカウントの制限により、より低い値が要求されることがあります。

コンテナの実行コストを、実際のScrapeless利用と価格ページで比較します。ワーカーのアップタイムからAPI消費を推測しないでください: 実行中のコンテナはアイドル状態である可能性があり、短いジョブが複数の請求可能な操作を実行できることがあります。

生の応答はその内容に応じて保護します。リクエストヘッダー、クッキー、および承認されたセッションの資料は、公開ページのテキストよりも厳密な取り扱いが必要です。抽出タスクに必要な証拠のみを保持します。

結論: 検証可能な契約を展開する

有用なCaaSスクレイピングワークフローは、小さなタスク契約、出力をチェックするワーカー、プロセス終了に耐えるストレージを持っています。シングルページのワーカーから始めて、アカウントでの応答処理を検証し、オーケストレーションを追加する前にコンテナ内で同じコードを実行します。

次のデプロイメントマイルストーンは、ソースとキャプチャ証拠を持つ受け入れられた記録です。ワーカーの数はその結果が再現可能になった後に決定されます。

ウェブデータパイプラインの構築の準備はできましたか？

DiscordおよびTelegramでウェブデータ収集に取り組む開発者に参加しましょう。

自分自身で承認されたデータソースに合わせてワークフローを適応させ、Scrapelessアカウントを作成します。

FAQ

Q: コンテナからのスクレイピングは、ローカルスクリプトの実行と法的に異なりますか？

コンテナのデプロイは、ターゲットに対するアクセス権限やデータ使用義務を変更しません。関連する条件とルールを確認してください。

Q: CaaSプラットフォームはこのワーカーのプロキシを提供しますか？

このワーカーは、ターゲットリクエストをWeb Unlockerに委任し、そのリクエスト内で文書化されたプロキシ設定を使用します。コンテナ自身の外向きIPは自動的に住宅プロキシではありません。

Q: 応答がアクセス拒否ページのときはどうすればよいですか？

ページをタスクデータとして拒否し、最小限の診断記録を保持します。他のコレクションジョブを承認する前に、ターゲットスコープとサポートされているアクセスパスを確認してください。

Q: ウェブサイトのHTMLが変更された場合は何が変わりますか？

抽出契約を更新し、検証します。コンテナ内のパッケージコードは、セレクターや期待されるコンテンツをページ変更から免疫させるものではありません。

Q: 一度に何人のワーカーを実行すべきですか？

小さな制限された作業負荷から始めて、ターゲットごとの受け入れられた出力を測定します。例の最大である1ホストあたり3ワーカーは、厳しいターゲットおよびアカウント制限の対象となるアプリケーション設定です。

Q: このワークフローにはAIエージェントが必要ですか？

いいえ。Pythonワーカーおよびコンテナコマンドは、言語モデルなしで実行されます。エージェントはタスクを作成できますが、ワーカーの決定的なコンテンツチェックを置き換えるべきではありません。