- Kernel ist eine Serverless-Plattform, mit der Entwickler Browser-Automatisierung-Code ohne separate Infrastrukturüberlegungen sofort deployen und in großem Maßstab skalieren können
- Ohne Konfiguration oder Pipeline-Aufbau lässt sich Code mit nahezu derselben Geschwindigkeit wie bei der lokalen Entwicklung deployen und ausführen
- Bietet einen Chrome-Browser, der in einer Sandbox-Umgebung genutzt werden kann, und wandelt geschriebene Agenten automatisch in APIs um, die von überall aufgerufen werden können
- Unterstützt die Integration mit Frameworks auf Basis des Chrome DevTools Protocol wie Playwright und Puppeteer; mit Remote-GUI (Live-View) sind Echtzeit-Monitoring und -Steuerung möglich
- Unterstützt die Unikraft-Unikernel-Umgebung und bietet leistungsoptimierte Funktionen wie ultraschnelle Neustarts, Snapshot-Wiederherstellung und minimale Ressourcennutzung
- Unterstützt zwei Deployment-Methoden: Docker-Images und Unikraft-Unikernel, wodurch der Einsatz in verschiedenen Cloud-/Container-Umgebungen möglich ist
- Sämtlicher Code wird sicher in isolierten virtuellen Maschinen ausgeführt; außerdem werden Tools für Echtzeit-Beobachtung und Debugging bereitgestellt
What's Kernel?
- Kernel bietet eine sandboxed, sofort einsatzbereite Chrome-Browser-Umgebung; dieses Repository ist der Basiscode für den gehosteten Dienst von Kernel
- Eine einfache Verbindung ist über Browser-Frameworks auf Basis von Chrome DevTools wie Playwright und Puppeteer möglich
Why use Kernel?
- Von lokal bis Produktion in Sekunden deployen
- Ohne separate Konfiguration oder Produktions-Pipeline kann Code fast so schnell deployt und ausgeführt werden wie mit
bun run dev
- Jeden Agenten in eine API verwandeln
- Jeder auf die Plattform hochgeladene Agent wird automatisch als API bereitgestellt und kann extern aufgerufen werden
- Parallele Skalierbarkeit
- Tausende Browser-Instanzen lassen sich bei Bedarf sofort starten und skalieren
- Stärkere Isolation und Observability
- Der Code läuft in isolierten VMs, was die Sicherheit erhöht; außerdem stehen Monitoring- und Debugging-Tools zur Verfügung
- Vorhersehbares, einfaches Preismodell
- Ohne vorab definierte Infrastruktur fallen nur Kosten für tatsächlich genutzte Ressourcen an
Hauptfunktionen
- Integrierte Browser-Umgebung: Browser in der Cloud sofort erzeugen und steuern, optimal für die Automatisierung von Workloads
- Sandboxed Chrome-Browser kann über DevTools-basierte Automatisierungs-Frameworks verbunden und genutzt werden
- Integration mit Playwright, Puppeteer usw. über Port 9222
- Abruf eines CDP-WebSocket-Endpunkts und Verbindung von einem Remote-Client aus
- Trennen und erneutes Verbinden möglich
- Sitzungsstatus beibehalten: Browser-Sitzungen mit Cookies, Authentifizierungs-Token, Verlauf usw. bleiben auch zwischen Aufrufen erhalten
- Ultraschneller Neustart (Standby-Modus): Browser-Instanzen können sofort in unter 20 ms neu gestartet werden
- Mit Remote-GUI (Live-View-Streaming) lässt sich der Browser-Bildschirm in Echtzeit anzeigen und steuern
- noVNC: VNC-basiert, Lesen/Schreiben unterstützt, WebRTC muss deaktiviert sein
- WebRTC: Echtzeit, Lesen/Schreiben, Fenstergrößenanpassung, Kopieren/Einfügen, hohe Performance,
ENABLE_WEBRTC=true erforderlich
- Audio-Streaming wird nicht unterstützt; ein schreibgeschützter Modus kann per Umgebungsvariable gesetzt werden
- Video-Replay von Browser-Sitzungen: Vergangene Sitzungen zur Fehlersuche und Analyse erneut ansehen (geplant)
Implementierung und Deployment
-
Verwendung von Docker-Containern
- Headful Chromium kann in einem Docker-Container ausgeführt werden
- Nach
cd images/chromium-headful stehen Skripte zum Bauen und Ausführen bereit
- WebRTC und weitere Einstellungen lassen sich über Umgebungsvariablen aktivieren
-
Verwendung von Unikraft-Unikernel
- Bei Ausführung auf Basis von Unikraft-Unikernel werden schnellerer Start und Standby-Modus als mit Docker-basiertem Betrieb geboten
- Wenn kein Netzwerkverkehr vorhanden ist, wird automatisch in den Standby-Modus gewechselt; Snapshot von Zustand/Wiederherstellung wird unterstützt
- Cold Start unter 20 ms, Sitzungszustand (Cookies, Dateien, Browser-Einstellungen usw.) kann erhalten und wiederhergestellt werden
- Mindestens 8 GB Arbeitsspeicher erforderlich
-
Hinweise zum Deployment
- Für die Aktivierung von WebRTC-basiertem Streaming ist ein TURN-Server erforderlich
- Bei Unikernel-Deployment wird eine öffentliche URL ausgestellt und ist für jeden zugänglich; daher nicht für sensible Aufgaben verwenden und die Instanz nach der Nutzung löschen
Noch keine Kommentare.