Playwright в облаке: CDP-подключение, постоянные сессии и управление параллельными задачами

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

Сам Playwright остается клиентской библиотекой: он открывает страницы, работает с локаторами, ожидает готовности элементов и собирает артефакты. Если сначала нужно выбрать фреймворк, посмотрите сравнение Playwright, Puppeteer и Selenium. Здесь рассмотрим более конкретные вопросы: где запускать Chromium, как подключиться к нему через CDP и как разграничить состояние параллельных задач.

В архитектуре важно отделить исполнение сценария от сохранения состояния. Контейнер со сценарием можно создать заново, а cookies, localStorage и IndexedDB часто нужно сохранить после перезапуска, а настройки прокси и параметры запуска браузера восстановить отдельно. Если эти два слоя не разделены, сбой одного из узлов может привести к потере авторизации или повторному выполнению бизнес-операции.

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

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

Для локального режима основным ограничением стают CPU, RAM и количество действий браузера. Четыре параллельных задания могут стабильно работать на странице каталога и внезапно исчерпать память на ресурсоемком SPA. Перед переноской в облако проверьте как сайты обнаруживают headless-автоматизацию, потому что другой сервер не исправляет признаки браузерной автоматизации, неудачное поведение сценария или нестабильные локаторы.

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

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

Практическое правило просто:

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

Прежде чем принять решение, опишите типичный рабочий сценарий. К примеру, команда имеет следующие условия:

• каждые десять минут проверяет 200 кабинетов
• одна проверка длится 40 секунд
• одновременный вход в один профиль запрещен

Средняя нагрузка здесь обманчива: все задачи поступают одновременно, поэтому архитектура определяет пиковую нагрузку на очередь.

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

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

Также учтите, где размещены данные:

• если страница работает с внутренней staging-средой, удаленный браузер должен иметь маршрут к нему
• если результат содержит персональные данные, согласуйте регион браузерного узла, срок хранения трассировок (trace) и доступ к видеозаписям

Облако изменяет не только масштаб, но и пределы доступа к данным.

Как отличаются CDP-подключение и протокол Playwright

CDP-подключение подсоединяет Playwright к уже запущенному Chromium, а нативный протокол Playwright подключается к браузеру, запущенному через BrowserType.launchServer. Эти способы подключения не взаимозаменяемы. Официальная документация прямо указывает, что connectOverCDP() обеспечивает менее полную интеграцию и поддерживает только браузеры на базе Chromium.

Из-за browserType.connect() клиент и сервер Playwright должны иметь одинаковую основную (major) и минорную (minor) версии. Такой вариант обеспечивает более полную поддержку возможностей Playwright, но требует Playwright-сервера на удаленной стороне. CDP гибче для уже запущенного Chrome или антидетект-профиля: достаточно HTTP или WebSocket endpoint.

В connectOverCDP() берите имеющийся default context через browser.contexts()[0]. Создание нового контекста может привести к использованию пустого хранилища без авторизации. Это типичная ошибка: соединение успешно, страница открывается, но cookies постоянного профиля оказываются недоступными в новом контексте.

После подключения проверьте поддержку нужных возможностей (capability probe): откройте тестовую страницу, прочтите текст локатором, создайте скриншот, проверьте доступ к имеющимся вкладкам и корректное завершение подключения.

Если сценарий этого требует, отдельно протестируйте перехват и маршрутизацию запросов, загрузку файлов и запись трассировки (trace). Для каждой проверки зафиксируйте результат или ошибку: успешного page.goto() недостаточно для оценки всех возможностей подключения.

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

Сетевая задержка влияет на время выполнения каждой отдельной команды. Локатор, чтение текста и получение атрибута могут сделать несколько циклов обмена данными меж клиентом и браузером. При большом RTT часто выгоднее собрать данные одним вызовом page.evaluate() или locator.evaluateAll(), чем выполнять десятки независимых чтений

Для простой сборки текста также проверьте locator.allTextContents(). Но не переносите в браузер всю бизнес-логику: код в page context сложнее типизировать, тестировать и диагностировать.

Проверьте разницу на странице, с которой вы работаете. Сравните два способа:

• первый читает 20 карточек отдельными локаторами
• второй возвращает массив из одного evaluate()

Произведите серию тестов с локальным и удаленным подключением. Если локальное время почти одинаковое, а удаленное отличается в разы, вероятная причина замедления заключается в количестве сетевых обменов (round trips), а не в вычислении страницы.

Не путайте работу CDP-соединения с реакцией сайта. Ответ 403, CAPTCHA или пустой список может быть ожидаемой реакцией сайта, хотя WebSocket и все команды Playwright работают без ошибок.

Отдельно отслеживайте состояние соединения, состояние браузера и результат выполнения задания. Успешная проверка доступности соединения (heartbeat) еще не означает, что задача завершилась с ожидаемым результатом.

Как сохранять состояние сессии и разделять браузерные профили

Постоянная сессия возникает благодаря профилю или сохраненному browser state, а не благодаря самому CDP. WebSocket только дает канал управления. После его разрыва браузер может продолжить работу, завершиться или ждать повторного подключения в зависимости от инфраструктуры.

Для E2E-тестов часто достаточно storageState: Playwright сохраняет cookies, localStorage и, по отдельному параметру, IndexedDB. sessionStorage стандартный storageState не охватывает, поэтому для возлагаемых на него сайтов нужен отдельный механизм восстановления. Файл авторизации содержит чувствительные данные, поэтому добавьте каталог в .gitignore, ограничьте доступ к CI и регулярно обновляйте тестовые учетные записи. Не вставляйте такой JSON в Docker image.

Для длительной сессии, в которой требуется сохранять полное состояние браузера, используйте постоянный user data directory или профиль, управляемый браузерной платформой. Если достаточно cookies, localStorage и, при необходимости, IndexedDB, можно периодически хранить и восстанавливать storageState.

В каталоге постоянного профиля хранятся cookies, настройки сайтов и другие данные Chromium. Один каталог профиля нельзя одновременно открывать несколькими независимыми процессами без надлежащей координации: блокировка файлов и конкурентная запись быстро портят состояние.

Следуйте принципу single writer: одна активная задача владеет профилем, пока не завершит работу или не передаст право доступа (lease). Остальные задачи ждут в очереди. Для чтения разных страниц одного сайта лучше создать отдельные профили или тестовые аккаунты, чем запускать конкурентные переходы в одной вкладке.

Разделяйте три уровня состояния. Это поможет избежать путаницы:

• состояние задачи сохраняет jobId, текущий шаг, число попыток и бизнес-результат
• состояние подключения сохраняет endpoint, время последнего heartbeat и причину разрыва
• состояние профиля охватывает cookies и браузерные хранилища; настройки прокси и параметры запуска сохраняйте в отдельной конфигурации сессии, если платформа не управляет ими самостоятельно

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

Не повторяйте всю бизнес-операцию автоматически. Сначала проверьте checkpoint: создан ли заказ, отправлена ​​ли форма, или записан результат. Для действий с изменением данных используйте idempotency key там, где он поддерживается API, или собственный журнал выполненных шагов. Иначе безопасный с виду retry создаст дубль.

Срок жизни профиля также следует фиксировать явно:

• одноразовый профиль удаляется после задания
• тестовый может жить до конца CI-прогона
• авторизованный рабочий профиль требует резервной процедуры входа

Сохранившиеся cookies не отменяют срок действия серверного токена, MFA и решения сайта завершить сессию. Наличие cookies или IndexedDB в хранилище не гарантирует, что сервер примет их для авторизации.

Отслеживайте версии состояния профиля. Процедура выглядит так:

1. перед запуском запишите state_version
2. после штатного завершения увеличьте ее вместе с контрольным хэшем нужных данных
3. если две задачи пытаются завершить тот же lease, вторая задача обнаружит смену версии и не перезапишет актуальные cookies устаревшим снимком

Это пример optimistic locking для браузерного профиля. Если lease имеет срок действия, добавьте проверку действующего владельца и монотонный fencing token: потерявшая lease задача не должна иметь возможности записать состояние даже после восстановления соединения.

Для ручного вмешательства предусмотрите отдельный режим управления профилем (ownership):

1. оператор получает временный доступ к профилю
2. автоматическая очередь перестает назначать ему задачу
3. все действия обозначаются одним incident ID
4. по возвращении профиля проверяют авторизацию и сетевые параметры

Без такого протокола человек и робот легко начинают управлять одной вкладкой одновременно.

Проверка постоянства должна быть измерена. Запишите контрольную cookie, значения localStorage и URL, отключите клиент, подключитесь повторно и сверьте все три значения. Затем перезапустите браузер и повторите тест. Так вы отдельно проверите reconnect и подлинное восстановление профиля.

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

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

Параллелизм и нагрузочные тесты

Эффективность параллельного выполнения в Playwright следует оценивать количеством успешных задач в минуту, а не числом открытых браузеров. Десять одновременных сессий не приносят пользы, если половина завершается через таймаут, а остальные ждут CPU. Начните с малого лимита и увеличивайте постепенно.

В Playwright Test каждый worker представляет собой отдельный процесс, который может выполнять несколько тестов. Браузер и контексты создаются в соответствии с конфигурацией и жизненным циклом тестов: worker не следует отождествлять с отдельным browser context. Для независимых тестов такая модель удобна. Для прикладной автоматизации чаще нужна собственная очередь, семафор и явная связь jobId -> profileId -> browser session. Не смешивайте worker раннера с квотой облачного провайдера: четыре workers могут упереться в тариф с двумя параллельными сессиями.

Произведите базовое тестирование производительности на одном и том же сценарии. Процесс должен быть воспроизводимым:

1. запустите 20 заданий с параллелизмом 1 и зафиксируйте p50 и p95
2. повторите серию с параллелизмом 2, 4 и 8
3. измерьте время создания браузера, CDP connect, навигации и бизнес-шага отдельно
4. запишите peak RSS клиента и браузерных узлов
5. вычислите долю успешных исполнений без повторных попыток и после допустимых повторных попыток
6. остановитесь, когда p95 резко возрастает или ошибки превышают согласованный порог

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

Таймауты и повторные попытки

Таймауты разделите по классам:

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

Устанавливайте общий срок выполнения (deadline) с учетом времени на отдельные шаги. Если все задание должно уложиться в 120 секунд, не задавайте каждое из десяти действий по 30 секунд независимо.

Перед каждым шагом:

1. вычисляйте остаток бюджета
2. сравните локальный timeout с оставшимся временем
3. выбирайте меньшее из двух значений

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

Для повторов отметьте ошибки как retryable и terminal:

Используйте exponential backoff из jitter для временных ошибок, когда повтор разрешен и безопасен: например, после разрыва соединения, перегрузки сервиса или ответа HTTP 429 с учетом Retry-After. Перед повторным выполнением операции с изменением данных проверяйте ее результат и идемпотентность.

Стоимость, надежность и телеметрия

Стоимость также оценивайте по результату. Формула общие затраты / успешные задачи включает:

• часы работы браузера
• прокси-трафик
• выполнение клиентского кода
• хранение артефактов
• повтори

Дешевый тариф с низким процентом успешных исполнений может стоить дороже собственного узла.

Укажите допустимый уровень ошибок (error budget) для инфраструктуры. Например:

• transport failure может составлять не более 0,5% запусков
• p95 CDP connect должен оставаться ниже пяти секунд в рабочем регионе

Это не универсальные нормы, а пример контракта. Пороги определяйте после базового теста и просматривайте после смены версии Chromium, образа контейнера или маршрута прокси.

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

Для базовой телеметрии достаточно таких показателей:

• job_id и profile_id для связи событий
• session_create_ms и cdp_connect_ms для инфраструктурной задержки
• navigation_ms и business_step_ms для сценария
• attempt и error_class для повторного анализа
• bytes_in, bytes_out и artifact_bytes за сетевые расходы
• session_stop_status для обнаружения браузеров, которые не завершили свою работу

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

Универсальный пример удаленного подключения CDP

Для управляемого облачного браузера обычно достаточно конечной точки, предоставленной поставщиком. Например, в Node.js соединение может выглядеть так:

import { chromium } from 'playwright';

const endpoint = process.env.REMOTE_CDP_ENDPOINT;
if (!endpoint) throw new Error('Требуется REMOTE_CDP_ENDPOINT');

const browser = await chromium.connectOverCDP(endpoint, { timeout: 30_000 });
try {
  const context = browser.contexts()[0];
  if (!context) throw new Error('Контекст браузера по умолчанию не найден');
  const page = await context.newPage();
  await page.goto('https://example.com', { waitUntil: 'domcontentloaded' });
  console.log(await page.title());
} finally {
  // Это закрывает подключение Playwright, но не гарантирует остановку удаленной сессии.
  await browser.close();
}

Это общая схема, а не универсальный интерфейс для всех провайдеров. Формат конечной точки, аутентификация, правила и поведение создания контекста browser.close() зависит от сервиса. Прекращение клиентского соединения не всегда означает остановку удаленного браузера. Для завершения сеанса используйте механизм, предоставленный провайдером, и проверьте подтверждение освобождения ресурсов.

Как подключить Playwright к профилю Afina через проверенный API

Afina запускает локальный HTTP API вместе с настольным приложением и возвращает wsEndpoint после запуска профиля. В этом примере показано, как подключить Playwright к управляемому профилю с помощью того же механизма CDP, который используют некоторые облачные службы. Однако это локальная модель, а не удаленный браузер как услуга: Chromium и данные профиля размещаются в инфраструктуре пользователя, а Playwright подключается через CDP.

Базовый адрес API, подтвержденный официальной страницей продукта: http://127.0.0.1:50778. Ключ необходимо передавать в заголовке x-api-key. Эндпоинт POST /api/profiles/start принимает profileId и возвращает wsEndpoint вида ws://127.0.0.1:9223/devtools/browser/.... Перед интеграцией прочитайте полную статью об Afina API и автоматизации через REST.

Не раскрывайте свой локальный API извне посредством простой переадресации портов. Если клиент Playwright работает на другом сервере, используйте:

• контролируемый частный канал
• ограничения доступа
• отдельная модель угроз

Локальная конечная точка предназначена для локального хоста, и CDP предоставляет очень широкие права над работающим браузером.

Для удаленного доступа используйте:

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

Конечную точку CDP не следует рассматривать как безопасный общедоступный API.

Перед основным скриптом добавьте:

• API проверки работоспособности
• проверка структуры ответа

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

Кроме того, зафиксируйте совместимую версию Playwright в файле блокировки и повторно проверьте поддержку необходимых возможностей (проверка возможностей) после обновления Chromium. Автоматическое обновление без контрольной серии может нарушить загрузку, трассировку или работу локаторов в тот момент, когда очередь уже принимает производственные задачи.

Храните свой ключ API в секретном менеджере или в безопасной локальной среде. Не передавайте его как аргумент командной строки: такие значения могут быть видны в списке процессов и журналах CI.

Для диагностики достаточно записать:

• Статус HTTP
• имя конечной точки
• идентификатор корреляции

Вам не нужно записывать заголовки запроса.

Нижеследующий код является демонстрационным примером, а не готовым к непосредственному запуску сценарием. Функция stopProfileUsingDocumentedApi() намеренно содержит throw new Error() и при завершении работы приведет к ошибке. Перед практическим использованием реализуйте ее по документации именно вашей версии Afina и проверьте фактическую остановку профиля.

Неподтвержденный endpoint для остановки здесь не приведен. Сценарий состоит из двух частей: старт профиля через REST и подключение к полученному endpoint. Идентификатор профиля и ключ извлекайте из переменных среды, а не записывайте непосредственно в коде.

import { chromium } from 'playwright';

const apiKey = process.env.AFINA_API_KEY;
const profileId = process.env.AFINA_PROFILE_ID;

if (!apiKey || !profileId) {
  throw new Error('Требуются AFINA_API_KEY и AFINA_PROFILE_ID');
}

// Реализуйте штатную остановку по документации для вашей версии Afina.
// Не используйте непроверенный путь API для остановки профиля.
async function stopProfileUsingDocumentedApi(profileId) {
  throw new Error('Настройте проверенный метод остановки профиля Afina');
}

let profileStarted = false;
let browser;
try {
  const response = await fetch('http://127.0.0.1:50778/api/profiles/start', {
    method: 'POST',
    headers: {
      'content-type': 'application/json',
      'x-api-key': apiKey,
    },
    body: JSON.stringify({ profileId }),
  });

  if (!response.ok) {
    throw new Error(`Не удалось запустить профиль, HTTP ${response.status}`);
  }
  profileStarted = true;
  const payload = await response.json();
  if (typeof payload?.wsEndpoint !== 'string' || !payload.wsEndpoint) {
    throw new Error('API не вернул корректный wsEndpoint');
  }

  browser = await chromium.connectOverCDP(payload.wsEndpoint, {
    timeout: 30_000,
  });
  const context = browser.contexts()[0];
  if (!context) throw new Error('Контекст браузера по умолчанию не найден');

  const page = context.pages()[0] ?? await context.newPage();
  await page.goto('https://example.com', {
    waitUntil: 'domcontentloaded',
    timeout: 45_000,
  });
  console.log(await page.title());
} finally {
  // Закрытие CDP-подключения не гарантирует остановку профиля.
  try {
    if (browser) await browser.close();
  } finally {
    if (profileStarted) await stopProfileUsingDocumentedApi(profileId);
  }
}

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

В зависимости от способа подключения и реализации сервиса закрытия объекта браузера, отсоединения клиента и завершения процесса Chromium могут иметь разные последствия. Проверьте поведение своей версии Afina и по завершении работы вызовите предусмотренный документацией метод остановки профиля через API.

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

Для параллельного запуска назначайте отдельный профиль каждой активной задаче и ограничивайте количество одновременных запусков (concurrency) семафором. Практическая последовательность такова:

1. получите lease на свободный профиль
2. запустите профиль через локальный API
3. подключите Playwright к CDP endpoint
4. проверьте поддержку нужных возможностей (capability probe) и выполните основной сценарий
5. запишите checkpoint и статус бизнес-операции
6. отключите клиент и штатно остановите профиль
7. освободите lease только после подтверждения остановки

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

Когда уместна Afina

Afina уместна в этой архитектуре, когда нужны изолированные профили, локальный API REST и прямое CDP-подключение для Playwright. Инфраструктура не освобождает от соблюдения правил целевой платформы, ограничения автоматизации или необходимости обработки ошибок. Материал предоставлен исключительно в ознакомительных и образовательных целях.

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