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 завдань із concurrency 1 і зафіксуйте p50 та p95
2. повторіть серію з concurrency 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 для виявлення браузерів, робота яких не завершилася

Не записуйте повний CDP URL, cookies або API key у логи. Endpoint часто містить credential у query string або дає прямий доступ до локального браузера. Маскуйте секрети до того, як помилка потрапить у централізовану систему спостереження.

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

Для керованого хмарного браузера зазвичай достатньо endpoint, який надає провайдер. Наприклад, у 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('Не знайдено default browser context');
  const page = await context.newPage();
  await page.goto('https://example.com', { waitUntil: 'domcontentloaded' });
  console.log(await page.title());
} finally {
  // Це закриває підключення Playwright, але не гарантує зупинки віддаленої сесії.
  await browser.close();
}

Це загальна схема, а не універсальний інтерфейс для всіх провайдерів. Формат endpoint, автентифікація, правила створення контекстів і поведінка browser.close() залежать від сервісу. Завершення клієнтського підключення не завжди означає зупинку віддаленого браузера. Для завершення сесії використовуйте передбачений провайдером механізм і перевіряйте підтвердження звільнення ресурсів.

Як підключати Playwright до профілю Afina через підтверджений API

Afina запускає локальний HTTP API разом із десктопним застосунком і повертає wsEndpoint після старту профілю. Цей приклад показує, як підключити Playwright до керованого профілю через той самий CDP-механізм, який використовують і деякі хмарні сервіси. Проте це локальна модель, а не віддалений Browser as a Service: Chromium і дані профілю працюють на інфраструктурі користувача, а Playwright під'єднується через CDP.

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

Не відкривайте локальний API назовні через простий port forwarding. Якщо клієнт Playwright працює на іншому сервері, використовуйте:

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

Локальний endpoint задуманий для localhost, а CDP дає дуже широкі права над запущеним браузером.

Для віддаленого доступу використовуйте:

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

Сам CDP endpoint не слід вважати безпечним публічним API.

Перед основним сценарієм додайте:

• health check API
• перевірку структури відповіді

Якщо застосунок не запущений або порт змінився, помилку потрібно виявити ще до резервування профілю.

Так само фіксуйте сумісну версію Playwright у lockfile й повторно перевіряйте підтримку потрібних можливостей (capability probe) після оновлення Chromium. Автоматичне оновлення без контрольної серії здатне зламати завантаження, trace або роботу локаторів у момент, коли черга вже приймає production-завдання.

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

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

• HTTP status
• назву endpoint
• correlation ID

Заголовки запиту записувати не потрібно.

Наведений нижче код є демонстраційним прикладом, а не готовим до безпосереднього запуску сценарієм. Функція 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('Не знайдено default browser context');

  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 доречна в цій архітектурі, коли потрібні ізольовані профілі, локальний REST API та пряме CDP-підключення для Playwright. Інфраструктура не звільняє від дотримання правил цільової платформи, обмеження автоматизації або потребу в обробці помилок. Матеріал надано виключно в ознайомчих та освітніх цілях.

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