Bester Weg, Puppeteer online auszuführen: Lösungen im Vergleich

Hat noch niemand von Puppeteer gehört? Es ist ein leistungsstarkes Tool zur Browserautomatisierung, das menschliche Interaktionen mit Webseiten simulieren kann, um verschiedene komplexe Anforderungen zu erfüllen. Zum Beispiel: Erstellung von Website-Screenshots, Generierung von PDFs, automatisierte Tests, Web-Scraping und Überwachung von Änderungen am Webinhalt.

In vielen Fällen müssen wir Puppeteer online ausführen. Zum Beispiel:

• In einer CI/CD-Pipeline, Aufruf eines Online-Puppeteer zur Ausführung automatisierter Tests.
• Verwendung von Cron zur regelmäßigen Überprüfung der Verfügbarkeit von Websites.
• Ausführung von groß angelegten, verteilten Webcrawlern.

Da Puppeteer-Aufgaben normalerweise kurzlebig sind und nicht kontinuierlich ausgelöst werden, ist das Hosting auf einem vollständigen Server (wie DigitalOcean) nicht kostengünstig, da der Server ständig abgerechnet wird, unabhängig davon, ob Puppeteer ausgeführt wird.

Der ideale Ansatz ist die Bereitstellung von Puppeteer mithilfe eines Serverless-Modells. Da Serverless-Dienste basierend auf tatsächlichen Aufrufen abgerechnet werden, ist dies in verschiedenen Szenarien in der Regel viel günstiger.

Derzeit unterstützen nur wenige Plattformen die Ausführung von Puppeteer im Serverless-Modus: Leapcell, AWS Lambda und Cloudflare Browser Rendering.

Dieser Artikel wird diese Plattformen untersuchen: wie sie verwendet werden können, um eine typische Puppeteer-Aufgabe zu erfüllen, und ihre Vor- und Nachteile.

Die Aufgabe

Wir verwenden als Beispiel einen gängigen Anwendungsfall für Puppeteer: die Erfassung eines Screenshots einer Webseite.

Die Aufgabe umfasst die folgenden Schritte:

1. Besuch einer angegebenen URL
2. Erstellung eines Screenshots der Seite
3. Rückgabe des Bildes

Leapcell

Code-Beispiel:

const puppeteer = require('puppeteer');
const { Hono } = require('hono');
const { serve } = require('@hono/node-server');

const screenshot = async (url) => {
  const browser = await puppeteer.launch({ args: ['--single-process', '--no-sandbox'] });
  const page = await browser.newPage();
  await page.goto(url);
  const img = await page.screenshot();
  await browser.close();
  
  return img;
};

const app = new Hono();

app.get('/', async (c) => {
  const url = c.req.query('url');
  
  if (url) {
    const img = await screenshot(url);
    return c.body(img, { headers: { 'Content-Type': 'image/png' } });
  } else {
    return c.text('Please add a ?url=https://example.com/ parameter');
  }
});

const port = 8080;
serve({ fetch: app.fetch, port }).on('listening', () => {
  console.log(`Server is running on port ${port}`);
});

Da Leapcell die Bereitstellung in verschiedenen Sprachen unterstützt, wird diese Anforderung leicht erfüllt.

Lokale Entwicklung und Debugging

Lokales Debugging ist sehr einfach. Genau wie jede andere Node.js-Anwendung: node index.js, und fertig!

Bereitstellung

Die Bereitstellung erfordert die Angabe des Build-Befehls, des Ausführungsbefehls und des Service-Ports (wie in der Abbildung unten gezeigt).

Spezifische Bereitstellungsparameter und -verfahren sind in der offiziellen Dokumentation detailliert beschrieben.

Nach der Bereitstellung ist Ihre Anwendung online verfügbar.

Zusammenfassung

✅ Pros:

• Konsistente lokale und Cloud-Umgebungen, die das Debugging erleichtern.
• Unterstützt die offizielle Puppeteer-Bibliothek.

❌ Cons:

• Etwas komplexere Einrichtung: Sie müssen Ihren eigenen HTTP-Handler schreiben.

AWS Lambda

Code-Beispiel:

const chromium = require('chrome-aws-lambda');

exports.handler = async (event) => {
  let browser = null;
  
  try {
    browser = await chromium.puppeteer.launch({
      args: chromium.args,
      defaultViewport: chromium.defaultViewport,
      executablePath: await chromium.executablePath,
      headless: chromium.headless,
    });
    
    const page = await browser.newPage();
    await page.goto(event.url);
    
    const screenshot = await page.screenshot();
    
    return {
      statusCode: 200,
      headers: { 'Content-Type': 'image/jpeg' },
      body: screenshot.toString('base64'),
      isBase64Encoded: true,
    };
  } catch (error) {
    return {
      statusCode: 500,
      body: 'Failed to capture screenshot.',
    };
  } finally {
    if (browser !== null) {
      await browser.close();
    }
  }
};

AWS Lambda erfordert die Verwendung von puppeteer-core zusammen mit einer Chromium-Bibliothek von Drittanbietern, wie z.B. alixaxel/chrome-aws-lambda.

Dies liegt daran, dass AWS ein Beschränkung von 250 MB für die Größe von Lambda-Funktionen auferlegt. Das mit Puppeteer gebündelte Chromium kann dieses Limit leicht überschreiten (etwa 170 MB unter macOS, 282 MB unter Linux und 280 MB unter Windows), sodass eine abgespeckte Version von Chromium verwendet werden muss.

Lokale Entwicklung und Debugging

Lokales Debugging erfordert eine komplexe Konfiguration aufgrund von Unterschieden in der Laufzeitumgebung, wie Sie in der Dokumentation für alixaxel/chrome-aws-lambda sehen können.

Bereitstellung

Zur Bereitstellung müssen Sie Ihre node_modules als ZIP-Datei hochladen. Abhängig von Ihrem Anwendungsfall müssen Sie möglicherweise auch Lambda Layers konfigurieren. Die Hauptgeschäftslogik kann direkt in der AWS-Konsole geschrieben und nach dem Speichern ausgeführt werden.

Zusammenfassung

✅ Pros:

• Der Implementierungscode ist relativ einfacher.

❌ Cons:

• Verlässt sich auf eine Chromium-Bibliothek eines Drittanbieters, was potenzielle Risiken mit sich bringen kann.
• Komplexe lokale Debugging.
• Der Bereitstellungsprozess ist umständlich und erfordert das Packen und Hochladen einer ZIP-Datei und möglicherweise Lambda Layers.

Cloudflare Browser Rendering

Code-Beispiel:

import puppeteer from '@cloudflare/puppeteer';

export default {
  async fetch(request, env) {
    const { searchParams } = new URL(request.url);
    let url = searchParams.get('url');
    if (url) {
      url = new URL(url).toString(); // normalisieren
      
      const browser = await puppeteer.launch(env.MYBROWSER);
      const page = await browser.newPage();
      await page.goto(url);
      const img = await page.screenshot();
      await browser.close();
      
      return new Response(img, {
        headers: {
          'content-type': 'image/png',
        },
      });
    }
    else {
      return new Response('Please add a ?url=https://example.com/ parameter');
    }
  },
};

Cloudflare Browser Rendering ist eine relativ neue Serverless Puppeteer-Lösung. Ähnlich wie AWS Lambda unterstützt es nicht die offizielle Puppeteer-Bibliothek. Stattdessen verwendet es eine von Cloudflare bereitgestellte Version von Puppeteer.

Während die Bibliothek von Cloudflare sicherer ist als jede Drittanbieteroption, kann ihr langsamer Aktualisierungszyklus frustrierend sein – zum Beispiel ging sie einst mehr als fünf Monate ohne Update!

Darüber hinaus hat Cloudflare Browser Rendering einige Einschränkungen:

• Nur für Worker Pro-Benutzer verfügbar.
• Jedes Cloudflare-Konto kann maximal 2 Browser pro Minute erstellen, wobei nicht mehr als 2 Browser gleichzeitig ausgeführt werden.

Lokale Entwicklung und Debugging

Lokales Debugging erfordert komplexe Konfiguration.

Bereitstellung

Um die Funktion bereitzustellen, schreiben Sie sie einfach online, speichern Sie sie und führen Sie sie aus.

Zusammenfassung

✅ Pros:

• Der Implementierungscode ist relativ einfacher.

❌ Cons:

• Abhängigkeit von der Puppeteer-Bibliothek von Cloudflare, die einen instabilen Aktualisierungszyklus aufweist.
• Komplexe lokale Debugging.
• Es gibt eine Paywall und andere Einschränkungen, die eine flexible Nutzung verhindern.

Fazit

Dieser Artikel verglich drei große Serverless-Plattformen für die Bereitstellung von Puppeteer: Leapcell, AWS Lambda und Cloudflare Browser Rendering. Jede Plattform hat ihre eigenen Vor- und Nachteile.

Doch alles in allem ist Leapcell eine ausgezeichnete Wahl, wenn Sie Ihr Puppeteer-Projekt online bereitstellen möchten.