Назад в Центр знаний
Развертывание

Настройка headless BotBrowser на серверах Ubuntu

Подготовьте сервер Ubuntu к автономным сессиям BotBrowser: системные библиотеки, дисплей Xvfb, службы systemd и ограниченные проверки состояния.

BotBrowser Team

Документация

Нужна поддерживаемая продуктовая документация?

У этой статьи есть соответствующая страница в центре документации. Используйте docs для каноничного сценария настройки, актуальных флагов и долгосрочной справки.

BotBrowser на Ubuntu с системными библиотеками и дисплеем Xvfb

BotBrowser может предоставлять контролируемую среду для разрешённых headless-нагрузок, но не защищает хост, не выдаёт разрешения и не доказывает результат приложения. В руководстве отдельно рассматриваются база Ubuntu и Xvfb, поведение браузера, чувствительные данные профиля и состояние приложения.

Кратко

Установите только нужные библиотеки, используйте фиксированный дисплей Xvfb и непривилегированную учётную запись службы, затем проверьте небольшую видимую пользователю задачу. Не записывайте в журналы профили, учётные данные, содержимое страниц и идентификаторы клиентов.

Содержание

Основа хоста и виртуальный дисплей

Запуск BotBrowser на headless-сервере Ubuntu лежит в основе большинства производственных развертываний. У серверов нет физического дисплея, графические драйверы отличаются от настольных, а браузер зависит от системных библиотек, которые минимальные серверные образы по умолчанию не устанавливают. Если учесть эти детали, среда остается стабильной, а иначе появляются эпизодические сбои, которые трудно диагностировать.

Производственному хосту Ubuntu нужны необходимые библиотеки, устойчивая политика дисплея, контролируемые службы браузера и понятная ответственность за профили и пользовательские данные. Эти требования относятся к автономным сессиям BotBrowser под управлением Playwright или Puppeteer и приводят к процедуре утверждения выпуска для каждого класса хостов.

BotBrowser с пакетом профиля работает на хосте Ubuntu с системными библиотеками и дисплеем Xvfb на :10.0.

Настольные среды автоматически управляют дисплеем, инициализацией графики и отображением шрифтов. В минимальных серверных образах нет многих общих библиотек и пакетов шрифтов, которые нужны браузеру, и нет никакого дисплея. В документации BotBrowser по развертыванию сказано, что BotBrowser требует виртуальный дисплей на headless-серверах, даже когда работает в режиме headless.

Неполная настройка приводит к явным ошибкам вроде "cannot open display", а также к менее заметным: пустым снимкам экрана, пропавшим символам или нестабильному воспроизведению медиа. Считайте каждый такой результат проваленной проверкой выпуска и исправьте хост до запуска в производство.

Предусмотрите виртуальный дисплей на каждом хосте. Документация исходит из дисплея Xvfb на :10.0 и указывает, что DISPLAY=:10.0 должен быть задан для каждого процесса BotBrowser. Запустите Xvfb на этом дисплее, задайте DISPLAY в каждой службе браузера и явно опишите зависимость между службами. Дисплей не отменяет проверку: до утверждения проверьте репрезентативные отрисовку, медиа и снимки экрана на каждом классе хостов.

Xvfb (X Virtual Frame Buffer)

Xvfb является виртуальным сервером дисплея, который реализует протокол X11 без дисплейного оборудования. BotBrowser нужен дисплей X11 даже в режиме headless, и на сервере его обеспечивает Xvfb.

Основные параметры конфигурации:

  • Номер дисплея (:10): произвольный идентификатор. Значение :10 позволяет избежать конфликтов с :0, который могут использовать настольные установки.
  • Параметры экрана (1920x1080x24): ширина, высота и глубина цвета. Проверьте выбранную глубину на репрезентативных снимках экрана и задачах отрисовки.
  • Переменная окружения DISPLAY (DISPLAY=:10.0): задавайте ее для каждого процесса BotBrowser, включая каждую службу и каждый ручной тест.

Системные зависимости браузера

BotBrowser использует общие библиотеки для отрисовки, звука, сети и специальных возможностей. В настольной установке Ubuntu большинство из них обычно уже есть. В минимальном серверном образе установите их явно.

Ключевые категории:

  • Графика: libdrm2, libgbm1, libxcomposite1, libxdamage1, libxrandr2 для композиции изображения
  • Интерфейсный набор: libgtk-3-0, libatk-bridge2.0-0, libatk1.0-0 для специальных возможностей и виджетов
  • Безопасность: libnss3, libnspr4 для TLS и работы с сертификатами
  • Звук: libasound2 для инициализации звука, даже если звук не воспроизводится
  • Шрифты: fonts-liberation для базового набора шрифтов
  • Интеграция с рабочим столом: xdg-utils для обработки типов MIME
  • Вспомогательные библиотеки: libcups2, libdbus-1-3, libxkbcommon0, libpango-1.0-0, libpangocairo-1.0-0, libwayland-client0, libwayland-server0, libatspi2.0-0, libxss1

Шаг 1 устанавливает полный список. После установки выполните проверку ldd из раздела проверки, чтобы найти библиотеки, которых по-прежнему не хватает.

Почему headless-режиму по-прежнему нужен дисплей

Документация по развертыванию указывает, что BotBrowser требует дисплей X11 даже в режиме --headless, поэтому сервер без дисплея может завершаться с ошибками вроде "cannot open display". Считайте виртуальный дисплей частью базовой конфигурации хоста, а не необязательной службой.

Не отключайте службу дисплея ради экономии ресурсов. Если в более поздней версии задокументирован другой поддерживаемый путь запуска, перечитайте документацию и проверьте этот путь на каждом классе хостов, прежде чем менять базовую конфигурацию.

Отсутствующие пакеты шрифтов

Что на самом деле происходит без дисплея

Раздел выше объясняет, почему виртуальный дисплей остаётся частью поддерживаемого headless-развёртывания. Это требование стоит отделить от того, что браузер делает при отсутствии дисплея, потому что результаты различаются и разницу можно измерить. Приведённые наблюдения получены на одном хосте: образ на базе Debian со всеми разрешёнными разделяемыми библиотеками Chromium, включая NSS, ATK, CUPS, GBM и ALSA, и фиксированной пробной страницей, сообщающей, удалось ли создать контекст WebGL.

Условие запускаКонтекст WebGLСообщённый рендерерСокет дисплея присутствует
Переменная дисплея не заданасозданSwiftShader (программный)нет
Переменная указывает на неактивную службу виртуального дисплеяне созданотсутствуетнет
Переменная не задана, повторено дваждысоздан оба разаSwiftShader (программный)нет

Средняя строка удивляет операторов. Указание процессу номера дисплея, где никто не слушает, не приводит к переходу на программный рендеринг: контекст просто не инициализируется, и страница, зависящая от WebGL, фиксирует отсутствующую возможность вместо более медленной. Первая и третья строки показывают, что headless-запуск вообще без переменной дисплея всё равно рендерит через программный бэкенд, поэтому контейнер без службы виртуального дисплея может выглядеть здоровым для загрузки страниц и при этом вести себя иначе, чем поддерживаемая конфигурация.

Читайте результат, а не намерение. Проверка здоровья, подтверждающая лишь загрузку страницы, пройдёт и в первой, и во второй строке, поэтому не покажет, какой путь выбрало развёртывание. Проверяйте ту возможность, от которой действительно зависите, и записывайте, какой рендерер ответил, затем сравнивайте с конфигурацией, которую собирались запускать.

Действуют два ограничения. Строка рендерера выше называет программный бэкенд на этом хосте, то есть описывает этот образ, а не все серверы: хост с драйвером GPU может сообщить другой адаптер. И ничто из этого не заменяет поддерживаемую конфигурацию из раздела выше, где реальный виртуальный дисплей сочетается с нужным набором зависимостей.

Ubuntu Server поставляется с минимальной поддержкой шрифтов. Установите документированные пакеты, затем проверьте репрезентативные страницы на пропавшие символы, обрезанные подписи, изменившиеся переносы строк и разбиение документов на страницы. Храните утвержденный набор пакетов в образе сервера, чтобы сопоставимые воркеры давали стабильный видимый результат.

Неверная глубина дисплея

Начните с 24-битного экрана, например Xvfb :10 -screen 0 1920x1080x24. Перед утверждением развертывания проверьте выбранную глубину на репрезентативных сценариях отрисовки и снимков экрана.

Запуск от root и ошибки sandbox

Sandbox Chromium может не запуститься, когда служба работает от root или внутри контейнера. Запускайте службу от непривилегированного пользователя. Если контейнеру нужен флаг sandbox, следуйте руководству по развертыванию и проверьте именно эту комбинацию, а не копируйте флаги между средами.

Профили, хосты и поведение выпуска

BotBrowser поддерживает headless-развертывания на серверах. Свойства отпечатка, такие как размер экрана, шрифты и сведения о GPU, берутся из выбранного пакета профиля, а не из оборудования сервера, тогда как хост предоставляет системные библиотеки и графический бэкенд. Проверьте полную конфигурацию на каждом классе хостов, который вы планируете использовать.

Для сопоставимых запусков используйте один и тот же утвержденный профиль, выпуск браузера, набор зависимостей, графический бэкенд и политику запуска. Различия в драйверах, библиотеках, поддержке медиа и нагрузке по-прежнему могут менять видимый результат или производительность.

У серверов обычно нет физического GPU, поэтому отрисовка опирается на программный бэкенд. В документации сравниваются Mesa llvmpipe через ANGLE GL, SwiftShader и Mesa lavapipe, а для большинства хостов Ubuntu рекомендуется llvmpipe. Запишите класс хоста и графический путь в запись о выпуске, потому что запуск, утвержденный для одного класса, не утверждает другой.

Установка и запуск

Шаг 1: установка системных зависимостей

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

В Ubuntu 24.04 часть названий пакетов изменилась. Если apt сообщает о неизвестном пакете, найдите переименованный вариант через apt-cache search или начните с этого сокращенного списка:

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

Шаг 2: запуск Xvfb

Запустите Xvfb на дисплее :10 до любого процесса BotBrowser и подключите к нему всех воркеров браузера.

Для быстрой проверки:

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

Для производства создайте службу 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

Включите и запустите службу:

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

Шаг 3: установка BotBrowser

Скачайте пакет Linux для вашей архитектуры со страницы выпусков BotBrowser. Поддержка архитектур зависит от конкретного выпуска, поэтому проверьте ее там. В руководстве по установке сказано, что бинарные файлы для Ubuntu требуют подписки ENT Plan Tier 1 или выше.

# Установите скачанный пакет
sudo dpkg -i botbrowser_<version>_amd64.deb

# Устраните недостающие зависимости, о которых сообщит dpkg
sudo apt-get install -f

# Проверьте установку
chromium-browser --version

Шаг 4: загрузка профилей

Используйте пакет профиля, который соответствует установленному выпуску браузера. Профили BotBrowser 150 и новее доступны по подписке или через поддержку. Сделайте пакет доступным для чтения только учетной записи службы, в примерах она называется botbrowser.

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

Шаг 5: тестовый запуск

Используйте тестовую задачу Playwright из шага 6, чтобы проверить весь путь запуска. Выполните ее с учетной записью службы, пакетом профиля, рабочим каталогом и графическим путем, предназначенными для производства, и с заданным DISPLAY=:10.0. Успешный тест открывает утвержденную страницу, выполняет небольшое действие и штатно завершается.

Шаг 6: интеграция с 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();
})();

Запускайте ее с заданной переменной дисплея:

DISPLAY=:10.0 node script.js

Шаг 7: служба systemd для автоматизации

Для постоянных воркеров автоматизации:

# /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

Одна рабочая нагрузка на службу

Поручите каждому файлу службы одну определенную нагрузку и один каталог данных. Приложение должно само управлять запуском и остановкой браузера, чтобы супервизор видел понятное состояние процесса. Так журналы, лимиты ресурсов и политику перезапуска проще связать с нагрузкой, которая их создала.

Создавайте отдельные службы, когда у приложений разные графики выпусков, графические требования или границы безопасности. Не оборачивайте несколько запусков профилей в цикл оболочки. Цикл скрывает, какая задача завершилась ошибкой, и может оставить дочерние процессы работающими после завершения родительского.

Используйте для перезапусков менеджер служб. Задайте паузу между попытками и предел запусков, чтобы неверный профиль или поврежденный образ не создавали бесконечный цикл перезапусков. Неисправная нагрузка должна оставаться видимой для мониторинга, пока не исправлена базовая конфигурация.

Проверка, состояние и восстановление

После завершения настройки проверьте дисплей, зависимости браузера и запуск в режиме headless:

# Проверьте, что Xvfb запущен
systemctl status xvfb

# Проверьте, что дисплей доступен
DISPLAY=:10.0 xdpyinfo | head -5

# Проверьте, что зависимости браузера удовлетворены
ldd /usr/bin/chromium-browser | grep "not found"

# Запустите и проверьте навигацию в режиме headless с заданным дисплеем
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();
})();
"

Браузер должен запуститься без видимого окна с подсказкой, завершить навигацию и штатно выйти. Сохраняйте вывод терминала и код завершения процесса вместе с журналами развертывания.

Порядок диагностики сбоев

Когда headless-хост Ubuntu работает, но возвращает неверный рендеринг, используйте фиксированный порядок проверок, чтобы каждый результат исключал ровно один слой: службу дисплея, сам дисплей, графический рендерер, пакет профиля и затем задачу приложения. Прыжок сразу к приложению скрывает дрейф хоста за посторонним отчетом об ошибке.

  1. Запустите systemctl status xvfb. Успех показывает active (running), стабильное время работы и счетчик перезапусков, который не растет.
  2. Запустите DISPLAY=:10.0 xdpyinfo | head -5. Успех сообщает утвержденные размеры и глубину, например dimensions: 1920x1080 pixels и depth of root window: 24 planes.
  3. Запустите DISPLAY=:10.0 glxinfo -B. Успех называет утвержденный программный рендерер в OpenGL renderer string, например llvmpipe (LLVM ...).
  4. Прочитайте строку рендерера внутри сессии браузера и сравните с шагом 3. Расхождение означает, что параметры запуска выбирают другой путь, чем путь хоста по умолчанию.
  5. Сравните sha256sum /var/lib/botbrowser/profile.enc с утвержденным значением. Другое значение означает, что загружен не тот пакет, а не сбой рендеринга.
  6. Повторите дымовую задачу из шага 6 с тем же дисплеем, профилем и параметрами и сравните снимок с утвержденной базой.

Остановитесь на первом неудачном шаге и исправьте этот слой до повторения всего порядка. Дисплей, проваливший шаг 2, объясняет все визуальные симптомы ниже, и никакая настройка параметров не оживит остановленную службу.

СимптомПроверкаРешение
Запуск завершается с "cannot open display"systemctl status xvfb и systemctl is-active xvfbИсправьте или перезапустите службу дисплея до правки параметров браузера
Страница загружается, но глифы отсутствуютСчетчик fc-list против списка пакетов утвержденного образаСчитайте это дрейфом пакетов шрифтов и пересоберите образ
Область canvas, WebGL или медиа остается пустойСтрока рендерера из glxinfo -BПриведите параметры к утвержденному бэкенду и повторите дымовую задачу
Снимки обрезаны или масштабированыРазмеры xdpyinfo против размера экрана профиляУвеличьте экран Xvfb или исправьте выбор профиля
Один профиль рендерится по-разному на двух хостахСтрока рендерера и вывод sha256sum с обоих хостовРазделите пул по классу хоста, пока разница не объяснена

Один профиль, два хоста, разный рендеринг

Самый трудный сбой тихий. Два хоста возвращают успешную задачу, но один и тот же утвержденный профиль рендерит текст, canvas или видео по-разному. Проверка процессов считает оба хоста здоровыми, поэтому разница проявляется только в сравнении пикселей или в отчете оператора. Изолируйте причину за три прохода, меняя один вход за раз и фиксируя два других.

Сначала проверьте дисплей. Сравните DISPLAY=:10.0 xdpyinfo на обоих хостах: размеры, глубина и число экранов должны совпадать с утвержденной конфигурацией. Хост с 16-битным экраном или меньшим фреймбуфером масштабирует или обрезает контент еще до того, как браузер что-то нарисует.

Затем проверьте бэкенд GPU. Сравните glxinfo -B на обоих хостах и прочитайте OpenGL renderer string и OpenGL version string. Два хоста с llvmpipe, или один с llvmpipe и другой с SwiftShader, относятся к разным классам развертывания, даже если оба прошли дымовую задачу. Запишите бэкенд в запись выпуска, чтобы сравнение можно было повторить.

В конце проверьте профиль. Сравните sha256sum /var/lib/botbrowser/profile.enc и версию профиля на обоих хостах. Хост с более старым пакетом или пакетом для другого выпуска браузера дает другие шрифты, значения экрана или поведение медиа, но все равно возвращает HTTP 200.

Когда два из трех входов совпадают, оставшаяся разница указывает на третий, и пул следует разделить по классу хоста, пока владелец не объяснит причину. Не усредняйте два результата и не делайте более быстрый хост эталоном.

Готовность службы и контроль состояния

Определяйте готовность по рабочей нагрузке, а не только по наличию процесса браузера. Полезная проверка запуска подтверждает, что служба приняла конфигурацию, создала сессию браузера, открыла одну утвержденную страницу и выполнила небольшое действие приложения. Проверка должна быстро останавливаться, если любой из этих шагов не удался.

Отделяйте проверку состояния от клиентского трафика. Используйте выделенную тестовую учетную запись или публичную страницу без персональных данных. Результат должен показывать, может ли приложение запуститься, перейти на страницу и штатно закрыться.

Различайте состояние при запуске и постоянное состояние. Проверка при запуске защищает решения о развертывании и перезапуске. Постоянная проверка должна охватывать движение очереди, недавно выполненные задачи, статус завершения процессов, свободное место на диске, нагрузку на память и состояние любой нужной службы дисплея. Воркер может оставаться живым, когда приложение уже не продвигается, поэтому одного времени работы процесса недостаточно.

Задайте разумный срок для каждой проверки с учетом обычной нагрузки. Повторные тайм-ауты считайте отказом службы и сохраняйте вывод приложения, который объясняет последний выполненный шаг. Избегайте агрессивного интервала проверок, который конкурирует с производственной работой или раз за разом запускает полные сессии браузера.

Когда проверка не проходит, выведите воркер из новых назначений до перезапуска. Позвольте активной задаче завершиться, только если приложение может сделать это безопасно. В остальных случаях зафиксируйте прерванную задачу, остановите службу и верните каталог данных в известное состояние до новой попытки супервизора.

Минимальная проверка может выполнить systemctl is-active --quiet botbrowser-worker.service, открыть тестовый URL и требовать код выхода 0 до перевода воркера в готовое состояние.

Журналы и восстановление после сбоев

Отправляйте вывод приложения и вывод терминала браузера в обычное место журналирования платформы. Указывайте ревизию службы, выпуск BotBrowser, версию пакета профиля, образ сервера и идентификатор задачи. Не включайте содержимое страниц, учетные данные, секреты маршрута и данные клиентов. Цель в том, чтобы объяснить событие службы, не превращая журнал в копию сессии просмотра.

Ротируйте журналы и артефакты сбоев, пока они не заполнили диск воркера. Храните достаточно истории, чтобы сравнить кандидата с последним утвержденным выпуском, а затем применяйте обычную политику хранения организации. Фиксированный срок хранения менее полезен, чем политика, связанная с реагированием на инциденты и требованиями к конфиденциальности.

Классифицируйте сбои по действию, которое должен выполнить оператор. Сбои конфигурации требуют исправления службы или пакета профиля. Сбои зависимостей требуют ремонта образа сервера. Сбои ресурсов требуют пересмотра нагрузки или емкости. Сбои приложения относятся к его владельцу. Такая простая модель ответственности не дает повторным перезапускам скрыть устойчивую проблему развертывания.

Проверяйте восстановление в предпроизводственной среде. Остановите службу во время утвержденной тестовой задачи, перезапустите хост и временно сделайте недоступной нужную зависимость. Убедитесь, что мониторинг сообщает о правильной службе, супервизор соблюдает предел перезапусков, а следующая задача начинается из утвержденного состояния. Подтверждения восстановления должны входить в проверку образа.

Контроль изменений и утверждение выпуска

Рассматривайте образ операционной системы, выпуск браузера, пакет профиля, файл службы и приложение как одно записанное сочетание развертывания. Изменение любого слоя может повлиять на запуск, отрисовку, медиа или расход ресурсов. Записывайте каждое сочетание-кандидат до тестирования, чтобы проверяющий мог его воспроизвести.

Пропускайте изменения образа через тот же предпроизводственный путь, что и изменения приложения. Обновления пакетов, пакеты шрифтов, графические библиотеки, изменения среды контейнеров и обновления политики безопасности заслуживают репрезентативной задачи браузера. Если утверждать базовый образ отдельно от нагрузки браузера, остается серьезный пробел.

Переводите изменения в производство небольшими группами. Когда несколько слоев должны меняться вместе, сохраняйте предыдущее сочетание и документируйте порядок отката. Откат должен восстанавливать полное утвержденное сочетание, а не смешивать старый браузер с непроверенным профилем или файлом службы.

После перевода наблюдайте за завершением задач, частотой перезапусков, ростом диска и нагрузкой на ресурсы в течение обычного окна выпуска. Сравнивайте результаты с утвержденным предпроизводственным запуском. Кандидата, который стартует правильно, но деградирует при обычной работе, нужно вывести из пула, пока он не затронул другие задачи.

Храните digest профиля из sha256sum profile.enc рядом с ревизией systemd-unit, чтобы при откате точно сравнить эти два входа развертывания.

Запуск headless и подсказки профиля

BotBrowser 150 не открывает видимые окна с подсказками профиля при запуске headless. Отсутствующие, просроченные, недействительные пакеты профиля и пакеты несовместимой версии сообщаются в выводе терминала, а процесс идет по обычному пути ошибки запуска. Запуски с интерфейсом сохраняют подсказки для пользователя.

Это важно для парков Playwright и воркеров CI, потому что проблема запуска не должна создавать скрытую зависимость от рабочего стола или неожиданное окно. Сохраняйте stderr браузера вместе с журналами задачи, считайте подсказку профиля неудачным запуском и заменяйте пакет профиля перед повтором.

Журналы контейнера могут по-прежнему упоминать недоступные службы рабочего стола или графики. Оценивайте готовность по успешному созданию сессии, выполнению утвержденной тестовой задачи и выбранному графическому бэкенду. Библиотеки хоста и пакет профиля по-прежнему должны соответствовать руководству по развертыванию.

Правила эксплуатации

Задавайте DISPLAY=:10.0 в каждой службе BotBrowser. Держите его в каждом файле службы, а не полагайтесь на оболочку входа, чтобы перезапуски службы и хоста начинались с одним и тем же окружением.

Проверяйте конфигурацию экрана Xvfb. 24-битный экран подходит как практичная отправная точка, но утверждение должно опираться на репрезентативные проверки отрисовки и снимков экрана. Увеличьте разрешение Xvfb, если размеры экрана профиля его превышают.

Следите за использованием диска. Браузер пишет дампы сбоев и данные кеша в каталог, заданный через --user-data-dir. Настройте ротацию журналов или периодическую очистку, чтобы не допустить переполнения диска.

Обновляйте зависимости. Периодически выполняйте apt-get upgrade. Расхождения версий библиотек могут вызывать малозаметные проблемы отрисовки.

Задайте лимиты ресурсов. Используйте параметры systemd MemoryMax и CPUQuota, чтобы неконтролируемая служба не израсходовала все ресурсы сервера.

Утверждение выпуска

Утверждайте образ сервера и выпуск BotBrowser как одно сочетание развертывания. Записывайте версию Ubuntu, выпуск BotBrowser, пакет профиля, графический путь, конфигурацию экрана Xvfb, ревизию файла службы и ревизию приложения. Успешный результат на другом образе дает полезный контекст, но не заменяет проверку на образе, который попадет в производство.

Начните с холодного запуска на чистом воркере. Убедитесь, что служба доходит до состояния готовности, открывает репрезентативную страницу, выполняет одну обычную задачу и штатно останавливается. Повторите ту же задачу после перезапуска службы и после перезагрузки хоста. Эти запуски выявляют недостающие переменные окружения, проблемы с правами, моментом монтирования и порядком служб, которые интерактивная оболочка может скрыть.

Затем проверьте видимый пользователю результат. Включите обычную страницу приложения, страницу с большим объемом текста, сценарий со снимками экрана или документами и медиа, если продукт их использует. Ищите пропавшие символы, обрезанные элементы, пустые области, неудачное воспроизведение и неожиданные изменения размера страницы. Правило приемки должно исходить от владельца приложения, а не от фиксированного универсального допуска.

Утверждение емкости требует репрезентативного набора задач. Увеличивайте параллелизм постепенно, наблюдая за памятью, процессором, разделяемой памятью, файловыми дескрипторами, ростом диска и временем выполнения задач. Оставляйте запас для операционной системы, журналирования и коротких пиков нагрузки. Запишите утвержденный диапазон для именно этого образа и пересматривайте его при изменении набора страниц или выпуска браузера.

Обработка сбоев входит в утверждение выпуска. Остановите один воркер во время задачи, подайте просроченный или несовместимый профиль в контролируемом предпроизводственном запуске и убедитесь, что супервизор фиксирует сбой и возвращает воркер в известное состояние. Повторные попытки не должны использовать поврежденный пользовательский каталог данных. Журналы должны указывать выпуск и воркер, не содержа секретов клиентов.

Переводите образ в производство только после того, как репрезентативная задача пройдет на каждом классе хостов, который его получит. Если используются пул с GPU и пул с программной отрисовкой, считайте их отдельными классами развертывания. Сохраняйте предыдущий утвержденный образ для отката, пока кандидат не пройдет обычный период наблюдения организации.

Вопросы о headless-хостах Ubuntu

Работает ли BotBrowser в Ubuntu 24.04?

В документации указана Ubuntu 20.04 или новее. В Ubuntu 24.04 некоторые имена пакетов изменились, например libasound2 стал libasound2t64; проверьте доступный пакет через apt-cache policy libasound2t64 и сохраните вывод вместе с идентификатором образа.

Можно ли использовать более высокое разрешение Xvfb?

Да. Можно запустить Xvfb с -screen 0 2560x1440x24 или с любым размером, который нужен вашей нагрузке. Увеличьте его, когда размеры экрана профиля превышают значение по умолчанию, и подтвердите результат репрезентативными снимками экрана.

Нужен ли GPU на сервере?

Зависит от нагрузки и выбранного графического бэкенда Linux. Базовая автоматизация может использовать проверенный программный путь, а нагрузки с медиа, WebGL или множеством снимков экрана могут вести себя иначе на других графических путях. Проверьте предполагаемую конфигурацию выпуска на целевом хосте.

Нужен ли Xvfb в режиме headless?

Да. Документация указывает, что BotBrowser требует виртуальный дисплей на headless-серверах даже в режиме headless и что DISPLAY=:10.0 должен быть задан для каждого процесса BotBrowser. После перезапуска выполните DISPLAY=:10.0 xdpyinfo | head -5, затем проверяйте отрисовку и медиа.

Почему нет окна, когда запуск headless завершается ошибкой?

В режиме headless подсказки при запуске выводятся в терминал, а не в окне рабочего стола. Сохраняйте этот вывод вместе с журналами воркера и исправляйте проблему профиля или хоста перед повтором.

Сколько экземпляров можно запускать на одном сервере?

Это зависит от хоста и нагрузки страниц. Измеряйте репрезентативные страницы с предполагаемым профилем, графическим бэкендом, медиа, снимками экрана и активностью воркеров. Оставляйте запас для операционной системы, следите за нагрузкой на память и swap и снижайте параллелизм до того, как хост станет нестабильным.

Как проверить недостающие библиотеки?

Выполните ldd /usr/bin/chromium-browser | grep "not found", чтобы найти отсутствующие библиотеки. Команда apt-file search libname.so находит пакет для конкретной библиотеки; для найденного пакета, например libnss3, dpkg -s libnss3 подтверждает состояние установки.

Можно ли запускать BotBrowser на серверах Ubuntu с ARM?

Поддержка архитектур зависит от конкретного выпуска. Прежде чем планировать пул ARM, откройте страницу выпусков GitHub и посмотрите перечисленные там архитектуры.

Как обновить BotBrowser?

Скачайте последний выпуск и подготовьте его вместе с соответствующим пакетом профиля. Перед переводом в производство проверьте конфигурацию службы, зависимости, графический путь и репрезентативную нагрузку, потому что изменения выпуска могут затронуть допущения развертывания. Сохраняйте предыдущее утвержденное сочетание, пока обновление не пройдет обычный период наблюдения.

Решение о развертывании

Настройка BotBrowser на headless-сервере Ubuntu требует правильных системных зависимостей, проверенного графического бэкенда и надежной конфигурации службы. Запустите Xvfb на дисплее :10.0 и задайте DISPLAY в каждой службе BotBrowser. Измеряйте репрезентативные страницы, прежде чем задавать пределы параллелизма, сохраняйте запас емкости и не помещайте частные данные в журналы. Скачайте BotBrowser, чтобы начать.

BotBrowser поддерживает парки headless-серверов двумя документированными способами. Он берет свойства отпечатка, такие как размер экрана, шрифты и сведения о GPU, из выбранного пакета профиля, а не из оборудования сервера, а при запуске headless сообщает в выводе терминала об отсутствующем, недействительном, просроченном или несовместимом по версии профиле, так что воркер завершается с видимой ошибкой и без скрытого окна. Благодаря этому свойства остаются согласованными на утвержденных хостах, а оператор получает понятное сообщение в журнале задачи. BotBrowser не может установить библиотеки, шрифты или графический бэкенд хоста, не гарантирует одинаковые отрисовку, медиа и емкость на разных классах хостов и не заменяет проверку каждого образа и каждой нагрузки перед производством.

Для контейнерных развертываний см. руководство по развертыванию в Docker. Для планирования емкости см. оптимизацию производительности BotBrowser. Для сочетаний параметров CLI см. рецепты CLI.

Практический итог

Рассматривайте хост, версию браузера, профиль, графический путь и рабочую нагрузку как одну проверенную комбинацию. BotBrowser может сделать разрешённые сессии браузера повторяемыми, но зависимости, разрешения, результаты приложения и меры конфиденциальности остаются ответственностью оператора.

Чтобы измерить разницу между обычной и безголовой сессиями до того, как полагаться на одну из них, прочитайте метод сравнения сигналов.

Открытые источники

#headless#Ubuntu#сервер#развертывание#Linux

Эта статья входит в руководство: Развёртывание и выпуск браузера: операционная карта

Переведите BotBrowser из исследований в продакшн

Используйте эти руководства, чтобы понять модель, а затем перейти к кроссплатформенной валидации, изолированным контекстам и масштабируемому браузерному развертыванию.