DockerでアプリにChromeを搭載せずにPuppeteerを実行する方法
Expert Network Defense Engineer
TL;DR:
- Puppeteer Dockerのデプロイメントは、Nodeパッケージ、Chrome実行可能ファイル、Linuxランタイムが1つの見えない依存関係として扱われると失敗します。 各境界を明示的にします。
- 公式イメージは最速の完全なベースラインです。 Puppeteer、Chrome for Testing、必要なライブラリを既知のリリースタグの下にパッケージ化します。
- システムChromeのイメージはオペレーティングシステムの制御を提供しますが、Chromeのインストールと互換性はあなたの責任となります。 両方の側面を固定し、ビルド中に起動スモークチェックを実行します。
puppeteer-coreはChromeをダウンロードせずにクライアントを含みます。 アプリケーションイメージがブラウザフリーである必要があるときは、別に操作されるブラウザとペアにします。- Scrapeless Scraping Browserはアプリコンテナが管理されたクラウドブラウザに接続できるようにします。 Chromeライフサイクル、ブラウザ依存関係、およびブラウザエグレスはNode.jsイメージから外れます。
- 開始するのは無料です。 新しいScrapelessアカウントには無料のScraping Browserランタイムが含まれています— app.scrapeless.comでサインアップしてください。
はじめに:Puppeteerにはブラウザ契約が必要
npm install puppeteer は全体のデプロイメントではありません。Puppeteerは互換性のあるChrome実行可能ファイル、Linux共有ライブラリ、フォント、書き込み可能なプロファイルディレクトリ、十分なメモリ、および子プロセスをクリーンに終了させるプロセスモデルが必要です。
Dockerは、依存関係が文書化されているときにのみそれらを再現可能にします。公式イメージはそれらをあなたのために文書化します。カスタムイメージは契約をDockerfileに移動させます。リモートブラウザデザインは契約をアプリケーションイメージの外に保ち、puppeteer-coreをクライアントとして残します。
このガイドは、検証中に両方インストールされるPuppeteer Core 25.8.0 と Scrapeless SDK 1.11.0 を使用しています。ローカルパッケージはnpmパッケージの外部に供給されたChrome実行可能ファイルを起動し、期待されるページタイトルを返しました。
PuppeteerがDockerでnpmインストール以上を必要とする理由
PuppeteerとPuppeteer Coreは異なるパッケージングの問題を解決します。
| パッケージ | ブラウザダウンロード | 使用目的 |
|---|---|---|
puppeteer |
インストール中に互換性のあるChrome for Testingを管理 | バンドルされたブラウザでのローカルまたはコンテナ起動 |
puppeteer-core |
ブラウザをダウンロードしない | 既存の実行可能ファイルまたはリモートブラウザエンドポイントに接続 |
パッケージの選択はPID 1、共有メモリ、ブラウザサンドボックス、フォント、証明書、またはコンテナのリソース制限を設定しません。それらはデプロイメントの責任として残ります。
前提条件
- アプリケーションコンテナ用のNode.js 20。
- 公式イメージとシステムChromeパターン用のDocker。
- ブラウザフリーアプリケーションパターン用のPuppeteer Core
25.8.0。 - 管理されたクラウドブラウザ用のScrapelessアカウントとAPIキー。
- 公開または明示的に承認されたターゲット。
注: Dockerは検証環境では利用できないため、イメージのビルドと
docker runコマンドは前提条件のギャップとしてラベル付けされています。Puppeteer Core25.8.0はパッケージの外部にあるChrome実行可能ファイルに対してインストールされ起動されました。Scrapeless SDKはそのPuppeteer接続機能を読み込み、露出しましたが、クラウドセッションのためのキーは利用できませんでした。
オプション1 — 公式Puppeteerイメージから開始
公式イメージには、Chrome for Testing、そのシステム依存関係、および一致するPuppeteerリリースが含まれています。 Puppeteer Dockerガイド はイメージとそのサンドボックス指向のランタイム要件を文書化しています。
latestを使用する代わりに、イメージを固定します:
dockerfile
FROM ghcr.io/puppeteer/puppeteer:25.8.0
WORKDIR /home/pptruser/app
COPY --chown=pptruser:pptruser package.json package-lock.json ./
RUN npm ci
COPY --chown=pptruser:pptruser . .
CMD ["node", "capture.mjs"]
文書化されたイメージはそのサンドボックスでChromeを実行するため、コンテナランタイムは必要な能力を提供する必要があります。また、ブラウザ子プロセスを管理するためのinitプロセスも必要です:
bash
docker build -t puppeteer-job:25.8.0 .
docker run --rm --init --cap-add=SYS_ADMIN puppeteer-job:25.8.0
ワークロードとランタイムをレビューした後にのみ能力を付与します。 NISTコンテナセキュリティガイダンス はイメージリスク、レジストリリスク、オーケストレーターコントロール、ランタイムコントロール、およびホストコントロールを分けます。
オプション2 — 自分でシステムChromeをインストール
組織がすでにブラウザリポジトリ、証明書チェーン、フォント、またはベースイメージを管理しているときにカスタムシステムChromeイメージが適しています。
アプリケーションはPuppeteer Coreをインストールされた実行可能ファイルに向ける必要があります:
javascript
import puppeteer from "puppeteer-core";
const browser = await puppeteer.launch({
executablePath: process.env.PUPPETEER_EXECUTABLE_PATH,
headless: true,
});
const page = await browser.newPage();
await page.setContent("<title>Chrome outside the npm package</title>");
console.log(await page.title());
await browser.close();
実行された検証は外部のChrome実行可能ファイルを使用し、Chrome outside the npm packageを印刷しました。それはpuppeteer-coreが制御していたブラウザを配信する必要がなかったことを確認します。
あなたのDockerfileは今やChromeのインストールと互換性を所有します。ブラウザパッケージを固定し、イメージビルド中にそのバージョンを確認し、イメージを公開する前に起動スクリプトを実行します。
別々に診断する5つのコンテナの失敗
Puppeteerコンテナの失敗は、エラーが1つの境界にマッピングされると解決が容易になります。
| 失敗 | 調査する証拠 | 修正 |
|---|---|---|
| 実行可能ファイルがない | executablePath とイメージパッケージリスト |
Chromeをインストールするか、リモートブラウザに接続する |
| 共有ライブラリが欠落 | ブラウザの標準エラー出力とリンクされたライブラリのチェック | 特定のオペレーティングシステム依存関係を追加 |
| サンドボックス起動エラー | ユーザー、カーネルポリシー、およびコンテナの能力 | サポートされている非ルートサンドボックス契約を復元 |
| 負荷下でレンダラーが閉じる | メモリ、IPC、および/dev/shmの設定 |
明示的なコンテナリソースと共有メモリを設定 |
| 子プロセスが残る | PID 1およびシャットダウンシグナルの処理 | --initを使用し、finallyでブラウザを閉じる |
Linuxの名前空間はプロセスのビュー、マウント、ユーザー、およびネットワークリソースを隔離します。 Linux名前空間マニュアルは、これらの隔離原則について説明しています。ブラウザサンドボックスとコンテナ境界は互いに補完し合い、一方が他方を置き換えることはありません。
Scrapelessでスクレイピングを開始
Scrapelessでウェブスクレイピングと自動化ワークフローを強化しましょう!
今日はサインアップして**$5の無料クレジット**をゲット — クレジットカード不要です。Scrapelessダッシュボードで今すぐ無料クレジットを取得しましょう。
Chromeをアプリケーションコンテナから移動
ブラウザフリーのアプリケーションイメージはpuppeteer-coreをインストールし、リモートブラウザセッションを開き、承認されたページ作業を実行し、接続を閉じます。ブラウザサービスは独立してスケールおよびアップグレードします。
検証プロジェクトで使用された正確なパッケージをインストール:
bash
npm install puppeteer-core@25.8.0 @scrapeless-ai/sdk@1.11.0
注意:次の接続にはあなたのScrapeless APIキーが必要です。インストールされたSDKのエクスポートはローカルでチェックされましたが、資格のない環境ではクラウドブラウザを開くことができませんでした。
javascript
import { Puppeteer } from "@scrapeless-ai/sdk";
const browser = await Puppeteer.connect({
sessionName: "browser-free-app",
sessionTTL: 300,
proxyCountry: "US",
defaultViewport: null,
});
const page = await browser.newPage();
await page.goto("https://example.com", { waitUntil: "domcontentloaded" });
console.log(await page.title());
await browser.close();
Scrapeless Scraping Browserはこのパターンにおけるブラウザレイヤーです。スクレイピングブラウザクイックスタート、プロダクトページ、および価格を確認してからCIで採用してください。
リモート境界を中心にアプリケーションを構成
アプリケーションコンテナはもう同じComposeプロジェクト内にChromeサービスを必要としません。必要なのは、Node.jsコード、そのロックファイル、Puppeteer Coreクライアント、および実行時に供給されるシークレットのみです。
yaml
services:
worker:
build: .
init: true
environment:
SCRAPELESS_API_KEY: ${SCRAPELESS_API_KEY}
read_only: true
tmpfs:
- /tmp:size=64m
このComposeファイルはアプリケーションの境界を表現しており、クラウドブラウザではありません。APIキーはデプロイメントシークレットストアから取得されます。ワーカーは読み取り専用のルートファイルシステムと制限された一時ディレクトリを持っています。
Open Container Initiativeのランタイム構成は、ランタイムがコンテナプロセスに変換するプロセス、環境、マウント、およびLinuxリソースを定義します。
正しいパターンを選択
完全なPuppeteerおよびChromeアーティファクトが小さなイメージよりも価値がある場合は、公式イメージを使用します。プラットフォームチームがすでにブラウザのディストリビューションとオペレーティングシステムポリシーを所有している場合、システムChromeをインストールします。アプリケーションがChromeを出荷または運用しないべきである場合は、Scrapeless Scraping BrowserとともにPuppeteer Coreを使用します。
決定はジョブによって異なる場合があります。内部テンプレートのPDFレンダリングはピン留めされたローカルイメージに留まる可能性があります。地域のブラウザエグレスが必要な公的ウェブ抽出は、管理されたクラウドブラウザに属するかもしれません。両方を同じジョブ契約の背後に置き、呼び出し元がブラウザの場所に依存しないようにします。
ScrapelessクラウドブラウザPuppeteerの例は、より広範な自動化ワークフローにおける管理された接続を示しています。
操作チェックリスト
- Puppeteer、Chrome、ベースイメージ、およびロックファイルのバージョンを固定します。
- イメージを公開する前にブラウザを立ち上げ、タイトルアサーションを実行します。
finallyで初期プロセスを使用し、ブラウザセッションを閉じます。- 信頼できないページのためにブラウザサンドボックスを保持します。
- CPU、メモリ、IPC、および一時ストレージの制限を明示的に設定します。
- APIキーはランタイムシークレットストアに格納し、イメージレイヤーには置かないでください。
- オーナーが別の制限を承認しない限り、ターゲットホストあたりの同時ワーカーは3つを超えないようにします。
- 出力とともにパッケージ、ブラウザ、イメージ、リージョン、ジョブのリビジョンを記録します。
結論:クライアントをChromeから切り離す
Puppeteerは、クライアントパッケージとブラウザランタイムを別々の、可視的な決定にすることで、操作が容易になります。公式イメージはそれらをバンドルしています。カスタムイメージを使用すると、チームが両方を所有できます。Puppeteer CoreとScrapeless Scraping Browserは、それらを管理された接続の上に分割します。
ジョブタイプごとに1つの契約を選択し、それを固定し、アプリケーションワークロードが始まる前にブラウザの境界をテストしてください。
ChromeなしでアプリイメージでPuppeteerを実行する準備はできましたか?
私たちのコミュニティに参加して、無料プランを取得し、Node.jsサービスからブラウザワークロードを分離する開発者とつながりましょう: Discord · Telegram。
app.scrapeless.comにサインアップして、無料のScraping Browserランタイムを取得し、ブラウザなしのワーカーパターンをテストしてください。
FAQ
Q: Puppeteer CoreにChromeは含まれていますか?
Puppeteer CoreはChromeをダウンロードしたり管理したりしません。明示的な実行可能パスまたはリモートブラウザ接続が必要です。
Q: 公式のPuppeteerイメージはカスタムイメージより安全ですか?
公式イメージは文書化されたブラウザおよび依存関係のベースラインを提供しますが、安全性はイメージの出所、ランタイム機能、ユーザーの身元、サンドボックスポリシー、ホストコントロール、開いているページに依存します。
Q: なぜChromeはDocker内部だけで失敗するのですか?
コンテナは実行可能ファイル、リンクライブラリ、サンドボックスサポート、共有メモリ、フォント、または適切なinitプロセスが欠けている可能性があります。ナビゲーションコードを変更する前に、失敗した境界を検査してください。
Q: リモートPuppeteerブラウザはプロキシを必要としますか?
リモートブラウザには、ジョブと一致する出口ポリシーが必要です。Scrapeless Scraping Browserは195以上の国で住宅用プロキシをサポートしており、一貫した実行のために承認された国を固定してください。
Q: セレクターが変更された場合、何が起こるべきですか?
レンダリングされたページを再チェックし、安定したロール、属性、またはデータ構造に対してセレクターを更新します。ChromeをDockerの外に移動しても、ターゲットDOMは凍結されません。
Q: Puppeteerワーカーはどのくらいの同時実行を使用すべきですか?
オーナーが別の制限を承認しない限り、ターゲットホストごとに3人以上のワーカーを保持しないでください。ブラウザフリートの容量とターゲットホストの同時実行は別々の制御です。
Q: Puppeteer CoreはAIエージェントなしで接続できますか?
はい。Puppeteer CoreとScrapeless SDKは直接のNode.jsインターフェースです。AIエージェントはオプションであり、アクセス、同時実行、または秘密保持ルールを変更するべきではありません。
Scrapelessでは、適用される法律、規制、およびWebサイトのプライバシーポリシーを厳密に遵守しながら、公開されているデータのみにアクセスします。 このブログのコンテンツは、デモンストレーションのみを目的としており、違法または侵害の活動は含まれません。 このブログまたはサードパーティのリンクからの情報の使用に対するすべての責任を保証せず、放棄します。 スクレイピング活動に従事する前に、法律顧問に相談し、ターゲットウェブサイトの利用規約を確認するか、必要な許可を取得してください。




