Docker і тестові середовища

Що таке образ (image) і контейнер (container) та чим вони відрізняються?

Образ — це запакований, тільки-для-читання шаблон: файлова система застосунку разом із метаданими про те, що і як усередині запускати. Контейнер — це вже піднятий екземпляр образу: той самий незмінний вміст плюс тонкий записуваний шар (writable layer) зверху й окремий ізольований процес. Якщо мислити категоріями ООП, образ грає роль класу, а контейнер — інстанс цього класу; з одного образу можна підняти хоч десяток контейнерів, і кожен житиме своїм життям. Практичний наслідок один: образ незмінний, а все, що контейнер устиг записати, живе в його короткочасному шарі й гине разом із ним. Тому базу, звіти й трейси свідомо виносять назовні — інакше після видалення контейнера їх просто не буде.

З чого складається образ і навіщо потрібні шари (layers)?

Образ зібраний зі стосу незмінних шарів, де кожен крок складання докладає ще один поверх попереднього. Ці шари кешуються й перевикористовуються: якщо два образи стартують з однакового базового node:20, спільний шар фізично лежить один раз. Саме тому послідовність кроків у рецепті так впливає на швидкість — перезбирається лише той шар, що змінився, і все, що йде за ним. Для тестувальника це не теорія, а хвилини на кожному прогоні CI: акуратно вибудуваний кеш перетворює двохвилинне складання на кількасекундне.

Чим контейнер відрізняється від віртуальної машини (virtual machine, VM)?

Різниця в тому, що саме ізолюється. VM піднімає через гіпервізор (hypervisor) повноцінну гостьову операційну систему з окремим ядром (guest OS kernel), тому важить гігабайти й прогрівається десятки секунд. Контейнер натомість спирається на ядро (kernel) хоста, а ізоляцію забезпечують вбудовані підсистеми Linux: namespaces розділяють видимість процесів, мережі й файлової системи, а cgroups нарізають ліміти на CPU та пам'ять. Виходить не окрема ОС, а лише відгороджений процес, який вважає, що машина належить йому одному. Звідси й вигоди: мегабайти замість гігабайтів, старт за секунди, майже непомітні накладні витрати; розплата — тонша межа безпеки, бо ядро одне на всіх.

Docker на macOS часто називають «не нативним». Що мають на увазі?

Контейнеризація виросла з ядра Linux, тож без Linux-ядра контейнерів не існує. На macOS чи Windows Docker Desktop нишком тримає компактну Linux-віртуалку й уже в ній ганяє контейнери. Тобто між кодом на вашому маку й контейнером завжди стоїть невидимий шар VM. На практиці це проявляється двома речами: пригальмованим вводом-виводом (файли перетинають межу віртуалки) і частиною відмінностей у поведінці проти Linux-агента CI. Повністю нативним Docker буває тільки під Linux.

Що описує Dockerfile і які інструкції треба знати напам'ять?

Dockerfile — це текстовий рецепт образу: набір директив, які складач читає й виконує по черзі, згори донизу. Обов'язковий мінімум, який питають: FROM вказує базовий образ, від якого відштовхуєтеся (з чистого аркуша будують украй рідко); WORKDIR призначає робочу теку всередині; COPY переносить файли з контексту складання в образ; RUN проганяє команду на етапі складання, і її результат осідає новим шаром; CMD задає команду, що піднімається вже при старті контейнера. Розуміння того, що робить кожна з цих п'яти й у який момент, і є та межа між знанням зі статті й реальним досвідом.

У чому принципова різниця між RUN і CMD?

Вони спрацьовують у різні фази життя образу. RUN відпрацьовує на етапі складання (docker build): ним ставлять залежності, компілюють, готують файлову систему, і кожен RUN фіксується окремим кешованим шаром. CMD під час складання не запускається зовсім — це стартова команда, що оживає, коли ви піднімаєте контейнер (docker run). Діючий CMD в образі рівно один: остання з таких інструкцій витісняє попередні. Проста перевірка розуміння: RUN npm ci покладе пакети в образ раз і назавжди, а CMD ["npx","playwright","test"] вистрелюватиме щоразу при старті контейнера з цього образу.

Чому в Dockerfile залежності копіюють і встановлюють до коду застосунку?

Це прямий висновок із кешування шарів. Спочатку в образ кладуть лише package.json із лок-файлом, ставлять залежності, і тільки після цього доливають решту коду. Логіка проста: залежності оновлюються нечасто, а код тесту — мало не при кожному коміті. Поставте COPY . . перед npm ci — і будь-яка дрібниця в тесті скине шар копіювання й усе за ним, тобто змусить наново тягнути весь node_modules. Правильна черга лишає важкий шар із залежностями в кеші, поки не зміниться сам лок-файл, і рятує хвилини на кожному складанні.

Які команди Docker найцінніші для QA під час дебагу?

Двома командами тестувальник орудує найчастіше. docker logs <container> віддає stdout/stderr контейнера — саме туди дивишся першим ділом, коли тести всередині впали, бо весь вивід ранера там. docker exec -it <container> sh закидає вас усередину живого контейнера, ніби по ssh: можна глянути, чи потрібний файл реально на місці, який набір шрифтів у системі, що застосунок бачить у своїх змінних середовища. Разом вони переводять розбір із «здогадуюся, чого впало» у «зайшов і подивився». Поряд стають у пригоді docker ps (що крутиться зараз, а з -a — і зупинене) та docker build/docker run для складання й запуску.

Що означає -p 8080:3000 у docker run і в якому порядку читати числа?

У контейнера окремий мережевий стек, тож слухаючий порт застосунку залишається невидимим іззовні, доки ви його не відкриєте явно прапорцем -p. Порядок аргументів регулярно плутають: зліва стоїть порт хост-машини, справа — порт усередині контейнера. Тобто -p 8080:3000 означає, що звернення на localhost:8080 вашого ноутбука перекидається на порт 3000 контейнера. Поміняєте місцями — і назовні відкриється не той порт, а застосунок здаватиметься «непідйомним», хоча всередині живий-здоровий.

Що таке volume і навіщо він тестувальнику?

Записуваний шар живе рівно стільки, скільки сам контейнер, тому дані, яким треба його пережити, кладуть у volume. Для QA головний різновид — bind mount (-v /шлях/на/хості:/шлях/у/контейнері): він прокидає конкретну теку хоста прямо всередину. Саме так забирають артефакти прогону: підключіть ./playwright-report і ./test-results, і після падіння звіт, скриншоти й трейси осядуть на диску, а не щезнуть із контейнером. Другий різновид — named volume, сховище під орудою самого Docker, яким тримають те, що має пережити перезапуск, наприклад файли бази. Класична помилка новачка без монтування: тест упав, ви тягнетеся за трейсом — а контейнера вже нема, разом із ним пропали й артефакти.

Що таке docker compose і яку проблему він розв'язує?

Справжній e2e-прогін рідко вкладається в один контейнер: потрібні щонайменше застосунок, його база й самі тести. Піднімати їх поодинці, вручну зшиваючи мережу й черговість старту, — суцільна морока. docker compose — це декларативний YAML, де перелічені сервіси разом з їхніми зв'язками, мережею та залежностями, і весь стенд встає однією командою docker compose up. Зиск для QA прямий: увесь стенд лежить одним файлом у репозиторії й піднімається однаково — що на машині розробника, що на агенті пайплайна, — тож «у мене працює» більше не аргумент.

Як сервіси в docker compose знаходять одне одного по мережі?

Compose збирає всі сервіси в одну спільну мережу, де кожен доступний за назвою сервісу, наче за доменом. Тому застосунок стукає в базу не за IP, а за db:5432, а тести в застосунок — за http://app:3000, де db і app — просто імена сервісів із YAML. Прописувати адреси вручну не доводиться. Головна засідка: localhost усередині мережі compose для будь-якого сервіса означає його самого, а не сусіда — тож тести, що ломляться на localhost:3000, застосунку в сусідньому контейнері не побачать.

У compose тести падають з «connection refused» на старті. Що не так?

Майже завжди винне те, що depends_on регулює лише черговість старту, а не готовність. Контейнер бази може «стартувати» за півсекунди, але сама СУБД усередині ще кілька секунд розкручується, і тести, що вискочили одразу за ним, ловлять «connection refused». Ліки — не роздутий випадковий sleep, а healthcheck на сервісі бази плюс condition: service_healthy у залежному сервісі: тоді застосунок і тести терпляче дочекаються, поки база справді почне відповідати. На співбесіді про це питають саме тому, що тут спотикаються постійно, змішуючи «контейнер піднявся» з «сервіс готовий».

Навіщо потрібен офіційний образ Playwright і чому його версія має збігатися з бібліотекою?

Браузери тягнуть за собою десятки системних бібліотек для рендерингу, звуку й шрифтів, і зводити їх докупи на порожньому Linux — заняття невдячне. Офіційний образ Playwright уже несе Chromium, Firefox і WebKit з усіма залежностями та стартовим набором шрифтів, підігнаними під конкретну версію. Критичне правило: тег образу (скажімо, v1.49.0-jammy, де jammy — це Ubuntu 22.04) має відповідати версії @playwright/test у вашому package.json. Кожен випуск зав'язаний на конкретні збірки браузерів, тож розбіжність бібліотеки й образу обертається то химерними падіннями, то повною відмовою запуститися. З того ж міркування в CI прибивають точну версію, а не тег latest, бо latest сьогодні одне, а завтра інше — чиста недетермінованість.

Навіщо взагалі ганяти тести в Docker усередині CI?

Docker знімає невизначеність оточення — головного винуватця «локально зелене, у CI червоне». Один образ замикає в собі геть усе: таймзону й локаль, шрифти та системні бібліотеки, збірки браузерів і саму версію Node; на будь-якій машині він відтворює той самий результат (відтворюваність). Кожен запуск починається з чистого незмінного образу, без залишків минулих ранів (ізоляція). Підняти Postgres чи Redis під інтеграційні тести — рядок у конфізі (інфраструктура на льоту). Один і той самий образ проходить dev, CI і staging, тож поведінка не розповзається (паритет середовищ). А кеш шарів помітно вкорочує пайплайн. Формулювання, яке чекають на інтерв'ю: Docker усуває розбіжність оточень, через яку тест червоніє виключно в CI.

Скриншотний тест червоніє лише в CI, а локально зелений. Чому?

Скриншотні (візуальні) тести звіряють знімок сторінки з еталоном (baseline) попіксельно, а те, як намальовано текст, залежить від наявних у системі шрифтів і від алгоритму згладжування гліфів (антиаліасинг). У macOS свій комплект шрифтів і власна логіка згладжування, у Linux-контейнері CI — геть інші, а деякого шрифту може не знайтися взагалі. Тому еталон, знятий на маку, майже гарантовано «попливе» в контейнері: інша ширина рядків, інші обриси літер, інші краї. Це не дефект застосунку й не флак у звичному розумінні — це відмінність середовищ рендерингу. Вихід один: народжувати й оновлювати baseline у тому самому Docker-образі, що й CI (проганяючи --update-snapshots усередині контейнера), і ніколи не комітити знімок, зроблений на власному маку чи Windows.

Тест зелений локально, але червоний у CI. З чого починати діагностику, перш ніж заводити баг на продукт?

Найперше — припустити не поломку застосунку, а розбіжність оточень: це найчастіша причина. Звіртеся, чи однакові версія браузера, локаль, таймзона й набір шрифтів між локальним запуском і контейнером CI; часто-густо ваш прогін і контейнер — просто різні планети. Далі корисно залізти в контейнер через docker exec і подивитися зсередини очима застосунку: змінні середовища, наявність файлів, встановлені шрифти. І лише переконавшись, що середовища тотожні, а поведінка все одно різниться, є сенс говорити про дефект продукту. Дисципліна та сама, що й усюди в діагностиці: не називати причину, поки під нею немає доказу.

Три кейси з робочого життя AQA, де Docker вирішує, чи буде прогін відтворюваним: складання образу з тестами так, щоб кеш шарів не перебудовувався щоразу; повний e2e-стенд у compose, де тести не стартують раніше за готовність бази; і скриншотний тест, що зелений локально й червоний у CI. Скрізь — що робити і чому саме так.

Кейс 1. Dockerfile для Playwright-тестів: порядок інструкцій вирішує швидкість

Задача проста: зібрати образ, який ганяє наш набір тестів, і забрати звіт на хост після падіння. Різниця між «наївним» і «правильним» Dockerfile — не в результаті складання, а в тому, скільки триває кожне наступне складання після дрібної правки тесту.

Спершу як роблять на автоматі — і чому це коштує хвилин:

FROM mcr.microsoft.com/playwright:v1.49.0-jammy
WORKDIR /app
COPY . .
RUN npm ci
CMD ["npx", "playwright", "test"]

Тут COPY . . кладе в образ увесь код разом із package.json одним шаром. Правите один рядок у будь-якому тесті — цей шар інвалідується, а разом із ним і всі наступні, включно з важким RUN npm ci. Docker чесно перевстановлює весь node_modules з нуля, хоча залежності не змінилися.

Тепер правильний порядок — залежності окремим шаром до коду:

FROM mcr.microsoft.com/playwright:v1.49.0-jammy
WORKDIR /app

# спершу тільки маніфести — цей шар кешується, поки не зміняться залежності
COPY package.json package-lock.json ./
RUN npm ci

# і лише потім решта коду — правки тестів не чіпають шар із npm ci
COPY . .
CMD ["npx", "playwright", "test"]

Складаємо й запускаємо, монтуючи звіт назовні:

# крапка в кінці — це контекст складання (поточна директорія)
docker build -t my-tests:1.0 .

# --rm приберемо контейнер після зупинки; -v витягне звіт на хост
docker run --rm -v $(pwd)/playwright-report:/app/playwright-report my-tests:1.0

Що дивитися і чому:

• Порядок COPY — це не косметика, а кеш. Залежності міняються рідко, код тесту — щокоміта. Тримаючи RUN npm ci вище за COPY . ., ви лишаєте важкий шар недоторканим, поки не зміниться сам package-lock.json. Складання падає з двох хвилин до кількох секунд на кожному прогоні CI.
• Версія образу мусить збігатися з бібліотекою. Тут образ v1.49.0, тож і @playwright/test у package.json має бути 1.49.x. Не зійдуться версії — браузер і бібліотека не узгодяться, і ви дістанете або химерні падіння, або відмову запуститися взагалі. І ніякого :latest у CI: сьогодні це одна збірка, завтра інша.
• Без -v артефакти помруть із контейнером. Записуваний шар ефемерний: --rm прибере контейнер, і разом із ним зникнуть звіт, скриншоти й трейси, якщо їх не змонтувати назовні ще до запуску. Змонтований ./playwright-report лишиться на диску навіть після падіння.

Кейс 2. docker compose: застосунок, база і тести, які дочекалися готовності

Один контейнер — рідко вся картина. Для e2e потрібні щонайменше троє: сам застосунок, його база й тести. Опишемо стенд одним файлом, який однаково підніметься локально й на агенті CI.

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: test
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 2s
      retries: 10

  app:
    build: .
    environment:
      DATABASE_URL: postgres://postgres:test@db:5432/postgres
    depends_on:
      db:
        condition: service_healthy
    ports:
      - "3000:3000"

  tests:
    image: mcr.microsoft.com/playwright:v1.49.0-jammy
    command: npx playwright test
    environment:
      BASE_URL: http://app:3000
    depends_on:
      - app

Піднімаємо весь стенд однією командою:

docker compose up --abort-on-container-exit

Тепер типова помилка, на якій «горять» постійно. Приберіть у сервісу app блок condition: service_healthy, лишивши голий depends_on: [db], — і на старті прогону тести отримають:

Error: connect ECONNREFUSED db:5432

Що дивитися і чому:

• Сервіси знаходять одне одного за іменем, не за IP. У DATABASE_URL стоїть db:5432, у BASE_URL — http://app:3000. Compose кладе всіх у спільну мережу, де ім'я сервісу працює як домен. Жодних IP прописувати не треба, а localhost усередині кожного контейнера означав би сам контейнер, а не сусіда.
• depends_on — це порядок старту, а не готовність. Контейнер postgres «піднімається» за півсекунди, але сама СУБД ще ініціалізується кілька секунд. Без healthcheck тести стартують у цю щілину й ловлять connection refused. Лікує саме healthcheck (тут pg_isready) плюс condition: service_healthy, а не випадковий sleep 5.
• Той самий файл — і локально, і в CI. Стенд лежить у репозиторії, тож розробник і пайплайн піднімають ідентичне оточення. Аргумент «у мене працює» тут просто нема куди подіти — середовище одне.

Кейс 3. Скриншотний тест зелений локально, червоний у CI: винні шрифти

Улюблене питання співбесіди і водночас реальна ситуація. Візуальний тест звіряє рендер сторінки з еталоном (baseline) піксель-у-піксель:

import { test, expect } from '@playwright/test';

test('картка товару збігається з еталоном', async ({ page }) => {
  await page.goto('/product/42');
  await expect(page.getByTestId('product-card')).toHaveScreenshot('card.png');
});

Локально на маку тест зелений. Той самий код у контейнері CI дає діф на кожному рядку тексту, хоча застосунок ніхто не чіпав. У звіті видно, що контури літер і ширина рядків «поплили».

Причина не в коді, а в середовищі рендерингу. Baseline знімали на macOS з її набором шрифтів і власною логікою згладжування гліфів (антиаліасинг). Linux-контейнер CI малює тими самими гліфами інакше, бо шрифти й згладжування в нього свої, а потрібного шрифту може й зовсім не виявитися — тоді замість літер вилазять «квадратики». Playwright знає про це й дописує до імені еталона суфікс платформи, тож знімки не змішуються:

card-darwin.png   ← знято локально на macOS
card-linux.png    ← потрібно для контейнера CI

Правильний фікс — оновити еталон у тому ж образі, що й CI, а не на своєму ноутбуці:

# оновлюємо baseline усередині Docker-образу CI, а не на macOS
docker run --rm \
  -v $(pwd)/tests:/app/tests \
  my-tests:1.0 \
  npx playwright test --update-snapshots

Що дивитися і чому:

• Це не баг застосунку і не звичайний флак. Діф стабільний і відтворюваний — він завжди з'являється в Linux і ніколи локально. Заводити дефект на продукт тут неправильно: різниця в тому, чим ОС малює текст, а не в тому, що показує застосунок.
• Суфікс платформи — запобіжник, а не розв'язання. -linux.png проти -darwin.png лише не дає знімкам змішатися. Сам по собі він не робить порівняння детермінованим — для цього еталон має народитися в тому ж середовищі, де перевіряється.
• Локальний baseline не комітять. Правило просте: --update-snapshots запускають усередині контейнера CI, а знімок, знятий на власному маку чи Windows, у репозиторій не потрапляє. Тут Docker — не зручність, а єдиний спосіб зробити скриншот-порівняння відтворюваним.

Образ, контейнер, шари

• Можу пояснити різницю образ vs контейнер: образ — незмінний тільки-для-читання шаблон, контейнер — його запущений екземпляр із записуваним шаром (аналогія клас/об'єкт), і з одного образу піднімають скільки завгодно контейнерів.
• Розумію, що записуваний шар контейнера ефемерний: усе записане зникає при видаленні контейнера, тож цінне треба виносити у volume.
• Знаю, що образ складається з кешованих шарів (layers), однакові шари перевикористовуються, а перебудовується лише змінений шар і все за ним.

Контейнер проти віртуальної машини

• Можу пояснити, чому контейнер легший за VM: він ділить ядро хоста, а VM несе повну гостьову ОС із власним ядром — звідси мегабайти замість гігабайтів і старт за секунди.
• Знаю, що ізоляцію контейнера дають механізми ядра Linux — namespaces (окремий погляд на процеси/мережу/ФС) і cgroups (ліміти CPU/пам'яті), а платою за спільне ядро є слабша межа безпеки.
• Можу пояснити, чому Docker на macOS/Windows «не нативний»: під капотом крутиться прихована Linux-VM, звідси повільніший I/O і частина розбіжностей із Linux-CI.

Dockerfile і кеш шарів

• Знаю п'ять базових інструкцій: FROM, WORKDIR, COPY, RUN, CMD — і що кожна робить.
• Можу пояснити різницю RUN vs CMD: RUN виконується під час складання й стає шаром, CMD — команда за замовчуванням при запуску контейнера (і діючий CMD один — остання інструкція перемагає).
• Розумію, чому залежності копіюють і ставлять до коду: інакше будь-яка правка тесту інвалідує кеш і змушує перевстановлювати node_modules.

Команди й дебаг

• Знаю мінімальний набір (docker build, run, ps, logs, exec) і ключові прапорці docker run: -d (фон), -e (змінна), --name, --rm, -p (порт).
• Можу пояснити, чому docker logs — перше місце для дебагу впалих тестів, а docker exec -it <container> sh — спосіб зазирнути всередину живого контейнера.

Порти і volume

• Можу пояснити порядок у -p host:container (ліворуч порт хоста, праворуч порт контейнера) і що порт застосунку ззовні не видно, поки його явно не опублікувати.
• Знаю різницю bind mount vs named volume: перший прокидає директорію хоста (так витягують артефакти тестів), другий — сховище під керуванням Docker (так тримають дані бази).
• Розумію, чому артефакти (звіт, скриншоти, трейси) треба монтувати ще до запуску, інакше вони помруть разом із контейнером.

docker compose

• Знаю, що сервіси в compose бачать одне одного за іменем сервісу (db:5432, http://app:3000), а не за IP, і що localhost усередині мережі compose — це сам сервіс, а не сусід.
• Можу пояснити, чому depends_on не гарантує готовності: він керує лише порядком старту, а справжню готовність (проти connection refused на старті) дає healthcheck + condition: service_healthy.

Готові образи й Docker у CI

• Знаю правило збігу версій: версія образу Playwright мусить дорівнювати версії @playwright/test, інакше — від дивних падінь до відмови стартувати; у CI фіксують точну версію, а не latest.
• Можу перелічити, навіщо Docker у CI: відтворюваність, ізоляція, інфраструктура на льоту, паритет середовищ, швидкість через кеш.

Скриншотні тести і шрифти

• Можу пояснити, чому візуальний baseline з macOS «розсипається» в Linux-контейнері (інші шрифти й згладжування гліфів) і що це різниця середовищ рендерингу, а не баг застосунку чи флак.
• Знаю правильний підхід: генерувати й оновлювати еталони (--update-snapshots) у тому ж образі, що й CI, не комітити локальні знімки, а суфікс платформи (-linux.png/-darwin.png) — лише запобіжник від змішування.