BotBrowser headless sur serveurs Ubuntu

BotBrowser peut fournir un runtime contrôlé pour des charges headless autorisées, mais il ne sécurise pas l'hôte, n'accorde pas d'autorisation et ne prouve pas le résultat applicatif. Ce guide sépare la base Ubuntu et Xvfb du comportement du navigateur, des données sensibles du profil et de la santé applicative.

Résumé

Installez seulement les bibliothèques nécessaires, utilisez un affichage Xvfb fixe et un compte de service non privilégié, puis vérifiez une tâche visible. N'inscrivez pas les profils, identifiants, contenus de pages ni identifiants clients dans les journaux.

Sommaire

• Base de l'hôte et affichage virtuel
• Installation et lancement
• Vérification, santé et reprise
• Contrôle des changements et approbation de la version
• Questions sur les hôtes Ubuntu headless
• Décision de déploiement

Base de l'hôte et affichage virtuel

Exécuter BotBrowser sur un serveur Ubuntu headless est le socle de la plupart des déploiements de production. Les serveurs n'ont pas d'écran physique, les pilotes graphiques diffèrent de ceux d'un poste de travail et le navigateur dépend de bibliothèques système que les images de serveur minimales n'installent pas par défaut. Bien régler ces détails sépare un environnement stable de pannes intermittentes difficiles à diagnostiquer.

Un hôte Ubuntu de production a besoin des bibliothèques requises, d'une politique d'affichage stable, de services de navigateur supervisés et d'une responsabilité claire sur les profils et les données utilisateur. Ces exigences s'appliquent aux sessions BotBrowser sans surveillance pilotées par Playwright ou Puppeteer, et elles mènent à une routine d'approbation de la version pour chaque classe d'hôte.

Les environnements de bureau gèrent automatiquement l'affichage, l'initialisation graphique et le rendu des polices. Les images de serveur minimales omettent de nombreuses bibliothèques partagées et de nombreux paquets de polices utilisés par les charges de navigateur, et elles ne fournissent aucun affichage. La documentation de déploiement de BotBrowser indique que BotBrowser exige un affichage virtuel sur les serveurs headless, même en mode headless.

Une configuration incomplète peut produire des échecs évidents comme « cannot open display », mais aussi des signes plus discrets : captures vides, caractères manquants ou lecture multimédia instable. Considérez chacun de ces résultats comme un contrôle de version échoué et corrigez l'hôte avant la production.

Prévoyez un affichage virtuel sur chaque hôte. La documentation part d'un affichage Xvfb sur :10.0 et précise que DISPLAY=:10.0 doit être défini pour chaque processus BotBrowser. Lancez Xvfb sur cet affichage, définissez DISPLAY dans chaque service de navigateur et gardez la dépendance entre services explicite. L'affichage ne dispense pas de valider : vérifiez un rendu, des médias et des captures représentatifs sur chaque classe d'hôte avant l'approbation.

Xvfb (X Virtual Frame Buffer)

Xvfb est un serveur d'affichage virtuel qui implémente le protocole X11 sans matériel d'affichage. BotBrowser a besoin d'un affichage X11 même en mode headless, et Xvfb le fournit sur un serveur.

Paramètres de configuration principaux :

• Numéro d'affichage (:10) : un identifiant arbitraire. Utiliser :10 évite les conflits avec :0, que les installations de bureau peuvent utiliser.
• Spécification de l'écran (1920x1080x24) : largeur, hauteur et profondeur de couleur. Validez la profondeur choisie avec des captures et des charges de rendu représentatives.
• Variable d'environnement DISPLAY (DISPLAY=:10.0) : définissez-la pour chaque processus BotBrowser, y compris chaque unité de service et chaque test manuel.

Dépendances système du navigateur

BotBrowser utilise des bibliothèques partagées pour le rendu, l'audio, le réseau et l'accessibilité. Une installation de bureau Ubuntu en contient généralement la plupart. Sur une image de serveur minimale, installez-les explicitement.

Les catégories critiques sont :

• Graphisme : libdrm2, libgbm1, libxcomposite1, libxdamage1, libxrandr2 pour la composition de l'affichage
• Boîte à outils d'interface : libgtk-3-0, libatk-bridge2.0-0, libatk1.0-0 pour l'accessibilité et les widgets
• Sécurité : libnss3, libnspr4 pour TLS et la gestion des certificats
• Audio : libasound2 pour l'initialisation audio, même sans lecture de son
• Polices : fonts-liberation pour disposer de polices de base
• Intégration au bureau : xdg-utils pour la gestion des types MIME
• Bibliothèques complémentaires : libcups2, libdbus-1-3, libxkbcommon0, libpango-1.0-0, libpangocairo-1.0-0, libwayland-client0, libwayland-server0, libatspi2.0-0, libxss1

L'étape 1 installe la liste complète. Après l'installation, exécutez le contrôle ldd de la section de vérification pour repérer toute bibliothèque encore manquante.

Pourquoi le mode headless a toujours besoin d'un affichage

La documentation de déploiement indique que BotBrowser exige un affichage X11 même en mode --headless ; un serveur sans affichage peut donc échouer avec des erreurs comme « cannot open display ». Considérez l'affichage virtuel comme un élément de la base de l'hôte et non comme un service facultatif.

Ne supprimez pas le service d'affichage pour économiser des ressources. Si une version ultérieure documente un autre chemin de démarrage pris en charge, relisez la documentation et validez ce chemin sur chaque classe d'hôte avant de modifier la base.

Paquets de polices manquants

Ce qui se passe réellement sans affichage

La section précédente explique pourquoi un affichage virtuel reste nécessaire dans un déploiement headless pris en charge. Il vaut la peine de séparer cette exigence de ce que fait le navigateur en l'absence d'affichage, car les deux produisent des résultats différents et la différence est mesurable. Les observations ci-dessous proviennent d'un seul hôte : une image basée sur Debian avec toutes les bibliothèques partagées de Chromium résolues, y compris celles de NSS, ATK, CUPS, GBM et ALSA, et une page de test fixe qui indique si un contexte WebGL a pu être créé.

Condition de lancement	Contexte WebGL	Moteur de rendu signalé	Socket d'affichage présent
Sans variable d'affichage	créé	SwiftShader (logiciel)	non
La variable vise un service d'affichage virtuel inactif	non créé	aucun	non
Sans variable, répété deux fois	créé les deux fois	SwiftShader (logiciel)	non

La ligne du milieu est celle qui surprend les opérateurs. Pointer le processus vers un numéro d'affichage où aucun serveur n'écoute ne bascule pas vers le rendu logiciel ; le contexte ne s'initialise simplement pas, et une page qui dépend de WebGL enregistre une fonctionnalité absente plutôt que plus lente. La première et la troisième ligne montrent qu'un lancement headless sans aucune variable d'affichage rend encore via le backend logiciel, ce qui explique qu'un conteneur sans service d'affichage virtuel puisse sembler sain pour les chargements de page tout en se comportant différemment de la configuration prise en charge.

Lisez le résultat, pas l'intention. Un contrôle de santé qui confirme seulement qu'une page s'est chargée passera aussi bien sur la première que sur la deuxième ligne, et ne peut donc pas dire quel chemin le déploiement a emprunté. Sondez la fonctionnalité dont vous dépendez réellement et notez quel moteur de rendu a répondu, puis comparez avec la configuration que vous vouliez exécuter.

Deux limites s'appliquent. La chaîne de moteur ci-dessus nomme le backend logiciel de cet hôte ; elle décrit donc cette image et non tous les serveurs, un hôte doté d'un pilote GPU pouvant signaler un autre adaptateur. Et rien de tout cela ne remplace la configuration prise en charge de la section précédente, qui associe un véritable affichage virtuel à l'ensemble de dépendances requis.

Ubuntu Server fournit une prise en charge minimale des polices. Installez les paquets documentés, puis examinez des pages représentatives pour détecter les caractères manquants, les libellés tronqués, les retours à la ligne modifiés et la pagination des documents. Conservez l'ensemble de paquets approuvé dans l'image du serveur afin que les workers comparables produisent des résultats visibles stables.

Profondeur d'affichage incorrecte

Commencez par un écran de 24 bits tel que Xvfb :10 -screen 0 1920x1080x24. Validez la profondeur choisie avec des parcours de rendu et de capture représentatifs avant d'approuver le déploiement.

Exécution en root et erreurs de sandbox

Le sandbox de Chromium peut ne pas démarrer lorsqu'un service s'exécute en root ou dans un conteneur. Exécutez le service avec un utilisateur non privilégié. Si un conteneur exige une option de sandbox, suivez le guide de déploiement et testez exactement cette combinaison au lieu de copier des options d'un environnement à l'autre.

Profils, hôtes et comportement de la version

BotBrowser prend en charge les déploiements headless sur serveur. Les propriétés d'empreinte, comme la taille d'écran, les polices et les informations GPU, proviennent du paquet de profil sélectionné et non du matériel du serveur, tandis que l'hôte fournit les bibliothèques système et un moteur graphique. Validez la configuration complète sur chaque classe d'hôte que vous prévoyez d'utiliser.

Utilisez le même profil approuvé, la même version du navigateur, les mêmes dépendances, le même moteur graphique et la même politique de lancement pour les exécutions comparables. Les différences de pilotes, de bibliothèques, de prise en charge multimédia et de charge peuvent encore modifier le rendu visible ou la capacité.

Les serveurs n'ont généralement pas de GPU physique, le rendu repose donc sur un moteur logiciel. La documentation compare Mesa llvmpipe via ANGLE GL, SwiftShader et Mesa lavapipe, et recommande llvmpipe pour la plupart des hôtes Ubuntu. Notez la classe d'hôte et le chemin graphique dans le dossier de la version, car une exécution approuvée sur une classe n'en approuve pas une autre.

Installation et lancement

Étape 1 : installer les dépendances système

sudo apt-get update && sudo apt-get install -y \
  fonts-liberation libasound2 libatk-bridge2.0-0 \
  libatk1.0-0 libatspi2.0-0 libcups2 libdbus-1-3 \
  libdrm2 libgbm1 libgtk-3-0 libnspr4 libnss3 \
  libpango-1.0-0 libpangocairo-1.0-0 libwayland-client0 \
  libwayland-server0 libxcomposite1 libxdamage1 \
  libxkbcommon0 libxrandr2 libxss1 xdg-utils xvfb

Sur Ubuntu 24.04, certains noms de paquets ont changé. Si apt signale un paquet inconnu, cherchez la variante renommée avec apt-cache search ou partez de cette liste réduite :

sudo apt-get install -y \
  libasound2t64 libatk-bridge2.0-0 libatk1.0-0 \
  libcups2t64 libgbm1 libgtk-3-0t64 \
  libnss3 libxcomposite1 libxdamage1 \
  libxrandr2 xvfb fonts-liberation xdg-utils

Étape 2 : démarrer Xvfb

Démarrez Xvfb sur l'affichage :10 avant tout processus BotBrowser et connectez-y tous les workers de navigateur.

Pour un test immédiat :

Xvfb :10 -screen 0 1920x1080x24 &
export DISPLAY=:10.0

Pour la production, créez un service systemd :

# /etc/systemd/system/xvfb.service
[Unit]
Description=X Virtual Frame Buffer
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/Xvfb :10 -screen 0 1920x1080x24
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Activez et démarrez le service :

sudo systemctl daemon-reload
sudo systemctl enable xvfb
sudo systemctl start xvfb

Étape 3 : installer BotBrowser

Téléchargez le paquet Linux correspondant à votre architecture depuis la page des versions de BotBrowser. La prise en charge des architectures dépend de chaque version, confirmez-la donc à cet endroit. Le guide d'installation indique que les binaires Ubuntu exigent un abonnement ENT Plan Tier 1 ou supérieur.

# Installez le paquet téléchargé
sudo dpkg -i botbrowser_<version>_amd64.deb

# Résolvez les dépendances que dpkg signale comme manquantes
sudo apt-get install -f

# Vérifiez l'installation
chromium-browser --version

Étape 4 : télécharger les profils

Utilisez le paquet de profil correspondant à la version du navigateur installée. Les profils de BotBrowser 150 et des versions ultérieures sont disponibles par abonnement ou via le support. Rendez le paquet lisible uniquement par le compte de service, appelé botbrowser dans les exemples.

sudo mkdir -p /var/lib/botbrowser
sudo install -o botbrowser -g botbrowser -m 600 \
  /path/to/<matching-profile>.enc /var/lib/botbrowser/profile.enc

Étape 5 : tester le lancement

Utilisez la tâche de test Playwright de l'étape 6 pour vérifier le chemin de lancement complet. Exécutez-la avec le compte de service, le paquet de profil, le répertoire de travail et le chemin graphique prévus pour la production, et avec DISPLAY=:10.0 défini. Un test réussi ouvre la page approuvée, termine sa petite action et se ferme normalement.

Étape 6 : intégrer Playwright

npm install playwright-core

const { chromium } = require('playwright-core');

(async () => {
  const browser = await chromium.launch({
    executablePath: '/usr/bin/chromium-browser',
    args: ['--bot-profile=/var/lib/botbrowser/profile.enc', '--proxy-server=socks5://user:[email protected]:1080'],
    headless: true,
  });

  const context = await browser.newContext();
  const page = await context.newPage();
  await page.goto('https://example.com');
  console.log('Title:', await page.title());
  await browser.close();
})();

Exécutez-la avec la variable d'affichage définie :

DISPLAY=:10.0 node script.js

Étape 7 : créer un service systemd pour l'automatisation

Pour les workers d'automatisation persistants :

# /etc/systemd/system/botbrowser-worker.service
[Unit]
Description=BotBrowser Automation Worker
After=xvfb.service
Requires=xvfb.service

[Service]
Type=simple
Environment=DISPLAY=:10.0
WorkingDirectory=/opt/scripts
ExecStart=/usr/bin/node /opt/scripts/worker.js
Restart=on-failure
RestartSec=10
User=botbrowser
Group=botbrowser

[Install]
WantedBy=multi-user.target

Gérer une charge par service

Faites en sorte que chaque unité de service soit responsable d'une charge définie et d'un répertoire de données. L'application doit piloter le démarrage et l'arrêt du navigateur afin que le superviseur voie un état de processus clair. Cette organisation facilite aussi l'association des journaux, des limites de ressources et de la politique de redémarrage à la charge qui les a produits.

Créez des unités de service distinctes lorsque les applications ont des calendriers de versions, des besoins graphiques ou des limites de sécurité différents. Ne placez pas de boucle shell autour de plusieurs lancements de profil. Une boucle masque la tâche qui a échoué et peut laisser des processus enfants actifs après la fin du parent.

Utilisez le gestionnaire de services pour le comportement de redémarrage. Définissez un délai entre les tentatives et une limite de démarrages afin qu'un profil invalide ou une image endommagée ne crée pas un cycle de redémarrage continu. Une charge en échec doit rester visible pour la supervision jusqu'à la correction de la configuration sous-jacente.

Dans chaque unité, vérifiez les valeurs réellement définies pour Restart= et RestartSec= ainsi qu'une limite StartLimitBurst, afin de repérer une boucle de redémarrage rapide.

Vérification, santé et reprise

Une fois la configuration terminée, vérifiez l'affichage, les dépendances du navigateur et un lancement headless :

# Vérifiez que Xvfb est en cours d'exécution
systemctl status xvfb

# Vérifiez que l'affichage est accessible
DISPLAY=:10.0 xdpyinfo | head -5

\# Vérifiez que les dépendances du navigateur sont satisfaites
ldd /usr/bin/chromium-browser | grep "not found"

# Lancez et vérifiez la navigation en mode headless avec l'affichage défini
DISPLAY=:10.0 node -e "
const { chromium } = require('playwright-core');
(async () => {
  const b = await chromium.launch({
    executablePath: '/usr/bin/chromium-browser',
    args: ['--bot-profile=/var/lib/botbrowser/profile.enc'],
    headless: true,
  });
  const p = await (await b.newContext()).newPage();
  await p.goto('https://example.com');
  console.log('Navigation completed:', await p.title());
  await b.close();
})();
"

Le navigateur doit démarrer sans ouvrir de fenêtre d'aide visible, terminer la navigation et se fermer proprement. Conservez la sortie du terminal et le code de sortie du processus avec les journaux du déploiement.

Ordre de triage des pannes

Quand un hôte Ubuntu headless fonctionne mais renvoie un rendu incorrect, suivez un ordre fixe de contrôles pour que chaque résultat écarte une seule couche : service d'affichage, affichage lui-même, moteur de rendu graphique, paquet de profil, puis tâche applicative. Sauter directement à l'application masque une dérive de l'hôte derrière un rapport de bug sans rapport.

1. Lancez systemctl status xvfb. Un succès affiche active (running), une durée d'activité stable et un compteur de redémarrages qui ne grimpe pas.
2. Lancez DISPLAY=:10.0 xdpyinfo | head -5. Un succès indique les dimensions et la profondeur approuvées, par exemple dimensions: 1920x1080 pixels et depth of root window: 24 planes.
3. Lancez DISPLAY=:10.0 glxinfo -B. Un succès nomme le moteur de rendu logiciel approuvé dans OpenGL renderer string, par exemple llvmpipe (LLVM ...).
4. Lisez la chaîne du moteur de rendu dans la session du navigateur et comparez-la à l'étape 3. Une différence signifie que les options de lancement choisissent un autre chemin que celui par défaut de l'hôte.
5. Comparez sha256sum /var/lib/botbrowser/profile.enc avec la valeur approuvée. Une valeur différente signifie que le mauvais paquet est chargé, pas une panne de rendu.
6. Relancez la tâche de fumée de l'étape 6 avec le même affichage, le même profil et les mêmes options, puis comparez la capture à la référence approuvée.

Arrêtez-vous à la première étape en échec et réparez cette couche avant de répéter tout l'ordre. Un affichage qui échoue à l'étape 2 explique tous les symptômes visuels en dessous, et aucun réglage d'options ne répare une unité arrêtée.

Symptôme	Contrôle	Décision
Le lancement se termine par "cannot open display"	systemctl status xvfb et systemctl is-active xvfb	Réparez ou redémarrez l'unité d'affichage avant de toucher aux options du navigateur
La page charge mais des glyphes manquent	Comptage fc-list comparé à la liste de paquets de l'image approuvée	Traitez-le comme une dérive des paquets de polices et reconstruisez l'image
La zone canvas, WebGL ou média reste vide	Chaîne du moteur de rendu de glxinfo -B	Alignez les options sur le backend approuvé, puis relancez la tâche de fumée
Les captures sont rognées ou mises à l'échelle	Dimensions de xdpyinfo face à la taille d'écran du profil	Augmentez l'écran Xvfb ou corrigez le choix du profil
Le même profil rend différemment sur deux hôtes	Chaîne du moteur de rendu et sortie de sha256sum des deux hôtes	Séparez le groupe par classe d'hôte jusqu'à expliquer la différence

Même profil, deux hôtes, rendu différent

La panne la plus difficile est silencieuse. Deux hôtes renvoient une tâche réussie, mais le même profil approuvé rend le texte, le canvas ou la vidéo différemment. Le contrôle de processus juge les deux hôtes sains, donc la différence n'apparaît que dans une comparaison de pixels ou un rapport d'opérateur. Isolez la cause en trois passes, en changeant un seul facteur à la fois et en gardant les deux autres fixes.

Contrôlez d'abord l'affichage. Comparez DISPLAY=:10.0 xdpyinfo sur les deux hôtes : dimensions, profondeur et nombre d'écrans doivent correspondre à la configuration approuvée. Un hôte avec un écran 16 bits ou un framebuffer plus petit met à l'échelle ou rogne le contenu avant même que le navigateur ne dessine.

Contrôlez ensuite le backend GPU. Comparez glxinfo -B sur les deux hôtes et lisez OpenGL renderer string et OpenGL version string. Deux hôtes qui indiquent llvmpipe, ou l'un llvmpipe et l'autre SwiftShader, sont des classes de déploiement différentes même quand les deux passent la tâche de fumée. Notez le backend dans l'enregistrement de version pour que la comparaison reste reproductible.

Contrôlez le profil en dernier. Comparez sha256sum /var/lib/botbrowser/profile.enc et la version du profil sur les deux hôtes. Un hôte qui charge un paquet plus ancien, ou un paquet construit pour une autre version du navigateur, produit des polices, des valeurs d'écran ou un comportement média différents tout en renvoyant HTTP 200.

Quand deux des trois inputs correspondent, la différence restante désigne le troisième, et le groupe doit être séparé par classe d'hôte jusqu'à ce qu'un responsable l'explique. Ne moyennez pas les deux résultats et ne promeuvez pas l'hôte le plus rapide comme référence.

État prêt et contrôle de santé

Définissez la disponibilité à partir de la charge de travail, et non de la seule existence d'un processus de navigateur. Un contrôle de démarrage utile confirme que le service a accepté sa configuration, créé une session de navigateur, ouvert une page approuvée et terminé une petite action applicative. Le contrôle doit s'arrêter rapidement dès que l'une de ces étapes échoue.

Gardez le contrôle de santé séparé du trafic des clients. Utilisez un compte de test dédié ou une page publique sans données personnelles. Le résultat doit indiquer si l'application peut démarrer, naviguer et se fermer proprement.

Distinguez la santé au démarrage de la santé continue. La santé au démarrage protège les décisions de déploiement et de redémarrage. La santé continue doit couvrir l'avancement de la file, les tâches récemment terminées, l'état de sortie des processus, l'espace disque disponible, la pression sur la mémoire et l'état de tout service d'affichage requis. Un worker peut rester actif alors que son application ne progresse plus, la durée de fonctionnement du processus seule ne suffit donc pas.

Fixez un délai raisonnable pour chaque contrôle selon la charge normale. Traitez les délais d'attente répétés comme une panne du service et conservez la sortie de l'application qui explique la dernière étape terminée. Évitez un intervalle de contrôle agressif qui concurrence le travail de production ou relance sans cesse des sessions complètes du navigateur.

Lorsqu'un contrôle échoue, retirez le worker des nouvelles affectations avant de le redémarrer. Laissez la tâche active se terminer seulement si l'application peut le faire sans risque. Sinon, enregistrez la tâche interrompue, arrêtez le service et ramenez le répertoire de données à un état connu avant que le superviseur ne réessaie.

Un contrôle minimal peut exécuter systemctl is-active --quiet botbrowser-worker.service, ouvrir une URL de test et exiger le code de sortie 0 avant de rendre le worker disponible.

Journaux et reprise après échec

Envoyez la sortie de l'application et la sortie terminal du navigateur vers la destination de journalisation habituelle de la plateforme. Incluez la révision du service, la version de BotBrowser, la version du paquet de profil, l'image du serveur et l'identifiant de la tâche. Excluez le contenu des pages, les identifiants, les secrets de route et les données clients. L'objectif est d'expliquer un événement de service sans transformer le journal en copie de la session de navigation.

Faites tourner les journaux et les artefacts de plantage avant qu'ils ne saturent le disque du worker. Conservez assez d'historique pour comparer la version candidate à la dernière version approuvée, puis appliquez la politique de rétention habituelle de l'organisation. Une durée de rétention fixe est moins utile qu'une politique liée à la réponse aux incidents et aux exigences de confidentialité.

Classez les échecs selon l'action qu'un opérateur doit mener. Les échecs de configuration exigent de corriger le service ou le paquet de profil. Les échecs de dépendances exigent de réparer l'image du serveur. Les échecs de ressources exigent une revue de la charge ou de la capacité. Les échecs applicatifs relèvent du responsable de l'application. Ce modèle simple de responsabilité évite que des redémarrages répétés masquent un problème de déploiement persistant.

Testez la reprise en préproduction. Arrêtez le service pendant une tâche de test approuvée, redémarrez l'hôte et rendez temporairement indisponible une dépendance requise. Vérifiez que la supervision signale le bon service, que le superviseur respecte sa limite de redémarrages et que la tâche suivante part d'un état approuvé. Les preuves de reprise doivent faire partie de la revue de l'image.

Contrôle des changements et approbation de la version

Traitez l'image du système d'exploitation, la version du navigateur, le paquet de profil, l'unité de service et l'application comme une seule combinaison de déploiement enregistrée. Un changement dans n'importe quelle couche peut affecter le démarrage, le rendu, les médias ou l'usage des ressources. Enregistrez chaque combinaison candidate avant de la tester afin qu'un relecteur puisse la reproduire.

Appliquez les changements d'image par le même parcours de préproduction que les changements applicatifs. Les mises à jour de paquets, les paquets de polices, les bibliothèques graphiques, les changements d'environnement de conteneurs et les mises à jour de politique de sécurité méritent tous une tâche de navigateur représentative. Approuver l'image de base séparément de la charge du navigateur laisse une lacune importante.

Promouvez les changements par petits groupes. Quand plusieurs couches doivent changer ensemble, gardez la combinaison précédente disponible et documentez l'ordre du retour arrière. Le retour arrière doit restaurer une combinaison approuvée complète plutôt que mélanger un ancien navigateur avec un profil ou un fichier de service non revus.

Après la promotion, observez l'achèvement des tâches, la fréquence des redémarrages, la croissance du disque et la pression sur les ressources pendant la fenêtre de version habituelle. Comparez ces résultats avec l'exécution approuvée en préproduction. Un candidat qui démarre correctement mais se dégrade sous une charge ordinaire doit être retiré du groupe avant d'affecter d'autres tâches.

Conservez le digest du profil avec sha256sum profile.enc et la révision de l'unité systemd; ces deux entrées permettent de comparer précisément le profil et l'unité lors d'un rollback.

Démarrage headless et aide du profil

BotBrowser 150 n'ouvre pas de fenêtre visible d'aide du profil lors des lancements headless. Les paquets de profil manquants, expirés, invalides ou de version incompatible sont signalés dans la sortie du terminal, et le processus suit le chemin normal d'échec de démarrage. Les lancements avec interface conservent l'aide destinée à l'utilisateur.

Cela compte pour les flottes Playwright et les workers de CI, car un problème de démarrage ne doit pas créer de dépendance cachée au bureau ni de fenêtre inattendue. Capturez le stderr du navigateur avec les journaux de la tâche, traitez l'aide du profil comme un lancement échoué et remplacez le paquet de profil avant de réessayer.

Les journaux du conteneur peuvent encore mentionner des services de bureau ou graphiques indisponibles. Jugez la disponibilité d'après la création réussie de la session, l'achèvement de la tâche de test approuvée et le moteur graphique sélectionné. Les bibliothèques de l'hôte et le paquet de profil doivent toujours correspondre au guide de déploiement.

Règles d'exploitation

Définissez DISPLAY=:10.0 dans chaque service BotBrowser. Conservez-le dans chaque fichier de service plutôt que de dépendre d'un shell de connexion, afin que les redémarrages du service et de l'hôte reprennent avec le même environnement.

Validez la configuration d'écran de Xvfb. Un écran de 24 bits est un point de départ pratique, mais l'approbation doit reposer sur des contrôles représentatifs de rendu et de capture. Augmentez la résolution de Xvfb lorsque les dimensions d'écran du profil la dépassent.

Surveillez l'usage du disque. Le navigateur écrit des rapports de plantage et des données de cache dans le répertoire défini par --user-data-dir. Mettez en place une rotation des journaux ou un nettoyage périodique pour éviter la saturation du disque.

Gardez les dépendances à jour. Exécutez apt-get upgrade périodiquement. Des écarts de version entre bibliothèques peuvent provoquer des problèmes de rendu subtils.

Définissez des limites de ressources. Utilisez les options systemd MemoryMax et CPUQuota pour empêcher un service incontrôlé de consommer toutes les ressources du serveur.

Approbation de la version

Approuvez l'image du serveur et la version de BotBrowser comme une seule combinaison de déploiement. Enregistrez la version d'Ubuntu, la version de BotBrowser, le paquet de profil, le chemin graphique, la configuration d'écran de Xvfb, la révision du fichier de service et la révision de l'application. Un résultat positif sur une autre image est un contexte utile, mais il ne remplace pas la validation sur l'image qui entrera en production.

Commencez par un démarrage à froid sur un worker propre. Confirmez que le service atteint l'état prêt, ouvre une page représentative, termine une tâche normale et s'arrête proprement. Répétez la même tâche après un redémarrage du service puis après un redémarrage de l'hôte. Ces exécutions révèlent les variables d'environnement manquantes, les permissions, le moment de montage et les problèmes d'ordre entre services qu'un shell interactif peut masquer.

Examinez ensuite le résultat visible par l'utilisateur. Incluez une page applicative normale, une page riche en texte, un parcours de capture ou de document et les médias lorsque le produit les utilise. Cherchez les caractères manquants, les commandes tronquées, les zones vides, les lectures en échec et les changements inattendus de taille de page. La règle d'acceptation doit venir du responsable de l'application plutôt que d'une tolérance universelle fixe.

L'approbation de capacité exige un mélange représentatif de tâches. Augmentez progressivement la concurrence en surveillant la mémoire, le processeur, la mémoire partagée, les descripteurs de fichiers, la croissance du disque et le temps d'achèvement des tâches. Gardez une marge suffisante pour le système d'exploitation, la journalisation et les pics brefs de charge. Notez la plage approuvée pour cette image précise et revoyez-la quand le mélange de pages ou la version du navigateur change.

La gestion des échecs fait partie de l'approbation. Arrêtez un worker pendant une tâche, fournissez un profil expiré ou incompatible lors d'une exécution de préproduction contrôlée et vérifiez que le superviseur enregistre l'échec et ramène le worker à un état connu. Les nouvelles tentatives ne doivent pas réutiliser un répertoire de données utilisateur endommagé. Les journaux doivent identifier la version et le worker sans contenir de secrets clients.

Ne promouvez l'image qu'après la réussite de la tâche représentative sur chaque classe d'hôte qui la recevra. Si un groupe avec GPU et un groupe à rendu logiciel sont utilisés, traitez-les comme des classes de déploiement distinctes. Gardez l'image approuvée précédente disponible pour le retour arrière jusqu'à ce que le candidat ait terminé la période d'observation habituelle de l'organisation.

Questions sur les hôtes Ubuntu headless

BotBrowser fonctionne-t-il sur Ubuntu 24.04 ?

La documentation indique Ubuntu 20.04 ou version ultérieure. Pour une image 24.04, vérifiez la variante audio disponible avec apt-cache policy libasound2t64 et conservez la sortie avec l'identifiant de l'image.

Puis-je utiliser une résolution Xvfb plus élevée ?

Oui. Vous pouvez démarrer Xvfb avec -screen 0 2560x1440x24 ou la taille dont votre charge a besoin. Augmentez-la lorsque les dimensions d'écran du profil dépassent la valeur par défaut, puis confirmez avec des captures représentatives.

Ai-je besoin d'un GPU sur le serveur ?

Cela dépend de la charge et du moteur graphique Linux sélectionné. L'automatisation de base peut utiliser un chemin logiciel validé, tandis que les charges riches en médias, en WebGL ou en captures peuvent se comporter différemment sur d'autres chemins graphiques. Testez la configuration prévue de la version sur l'hôte cible.

Ai-je encore besoin de Xvfb en mode headless ?

Oui. La documentation indique que BotBrowser a besoin d'un affichage virtuel sur un serveur headless même en mode headless, avec DISPLAY=:10.0 pour chaque processus. Après un redémarrage, contrôlez l'environnement transmis avec systemctl show botbrowser-worker.service --property=Environment, puis testez l'accès à l'affichage avec DISPLAY=:10.0 xdpyinfo | head -5.

Pourquoi n'y a-t-il pas de fenêtre quand un lancement headless échoue ?

Le mode headless signale l'aide au démarrage dans la sortie du terminal au lieu d'ouvrir une fenêtre de bureau. Conservez cette sortie avec les journaux du worker et corrigez le problème de profil ou d'hôte avant de réessayer.

Combien d'instances puis-je exécuter par serveur ?

Cela dépend de l'hôte et de la charge de pages. Mesurez des pages représentatives avec le profil, le moteur graphique, les médias, les captures et l'activité de workers prévus. Gardez une marge pour le système d'exploitation, surveillez la pression sur la mémoire et le swap, et réduisez la concurrence avant que l'hôte ne devienne instable.

Comment vérifier les bibliothèques manquantes ?

Exécutez ldd /usr/bin/chromium-browser | grep "not found" pour repérer les bibliothèques manquantes. Utilisez apt-file search libname.so pour trouver le paquet qui fournit une bibliothèque précise; pour un paquet renvoyé, par exemple libnss3, dpkg -s libnss3 confirme son état d'installation.

Puis-je exécuter BotBrowser sur des serveurs Ubuntu ARM ?

Avant de prévoir un pool ARM, comparez uname -m avec les architectures publiées sur la page des versions GitHub et consignez le résultat.

Comment mettre à jour BotBrowser ?

Téléchargez la dernière version et préparez-la avec le paquet de profil correspondant. Revoyez la configuration du service, les dépendances, le chemin graphique et la charge représentative avant la promotion, car les changements de version peuvent affecter les hypothèses du déploiement. Gardez la combinaison approuvée précédente disponible jusqu'à ce que la mise à jour réussisse la période d'observation habituelle.

Décision de déploiement

Configurer BotBrowser sur un serveur Ubuntu headless exige les bonnes dépendances système, un moteur graphique testé et une configuration de service fiable. Lancez Xvfb sur l'affichage :10.0 et définissez DISPLAY dans chaque service BotBrowser. Mesurez des pages représentatives avant de fixer les limites de concurrence, conservez une marge de capacité et gardez les données privées hors des journaux. Téléchargez BotBrowser pour commencer.

BotBrowser prend en charge les flottes de serveurs headless de deux façons documentées. Il lit les propriétés d'empreinte comme la taille d'écran, les polices et les informations GPU dans le paquet de profil sélectionné plutôt que dans le matériel du serveur et, lors des lancements headless, il signale dans la sortie du terminal les états de profil manquant, invalide, expiré ou de version incompatible, de sorte qu'un worker échoue visiblement sans fenêtre cachée. Les propriétés restent ainsi cohérentes entre les hôtes approuvés et l'opérateur obtient un message lisible dans le journal de la tâche. BotBrowser ne peut pas installer les bibliothèques, les polices ni le moteur graphique de l'hôte, ne garantit pas un rendu, des médias ou une capacité identiques d'une classe d'hôte à l'autre et ne remplace pas la validation de chaque image et de chaque charge avant la production.

Pour les déploiements en conteneurs, consultez le guide de déploiement Docker. Pour planifier la capacité, consultez l'optimisation des performances de BotBrowser. Pour les combinaisons d'options de la CLI, consultez les recettes CLI.

Conclusion pratique

Traitez l'hôte, la version du navigateur, le profil, le chemin graphique et la charge comme une combinaison testée. BotBrowser peut rendre répétables les sessions autorisées, mais les dépendances, autorisations, résultats applicatifs et contrôles de confidentialité restent sous la responsabilité de l'opérateur.

Pour mesurer l'écart entre sessions avec interface et headless avant de vous fier à l'une, voyez la méthode de comparaison des signaux.

Sources publiques

• Documentation BotBrowser : configuration de serveurs headless
• Documentation BotBrowser : choix du moteur graphique Linux
• Versions de BotBrowser
• Manuel de systemd.service