Docker и серверное окружение

Запуск с флагами — это ExecAllocator, знакомый по второму уроку, и здесь самое важное место урока: читайте дефолты, прежде чем копировать чужие. Из исходников библиотеки видно, что DefaultExecAllocator уже включает Headless и disable-dev-shm-usage, а при каждом запуске процесса chromedp прикладывает --no-sandbox — то есть защита от трёх сюрпризов из коробки есть, и вручную перечислять их не нужно. Что остаётся вам. Первое: --disable-gpu — на сервере без видеокарты рендеринг через GPU даёт артефакты и лишние падения; добавьте chromedp.Flag("disable-gpu", true) в свой набор опций, это единственный из серверных флагов, которого в дефолтах нет. Второе: шрифты флагами не лечатся — только пакетами в образе. Третье: /dev/shm. Docker по умолчанию монтирует этому каталогу 64 МБ; Chrome складывает туда разделяемую память рендереров, и на тяжёлых страницах вкладки начинают падать с крэшами — флаг disable-dev-shm-usage переносит временные файлы на /tmp, а альтернатива — поднять shm_size в compose. Если браузер запускаете вручную через docker run, эти флаги прописываете сами в CMD. И привычка из практики: держите набор флагов в одном месте — рядом с аллокатором — и логируйте его при старте вместе с версией Chromium; когда через полгода повторится странный инцидент, вы сравните окружения за минуту, а не по памяти.

Схему запуска chrome в докере выбирают из двух вариантов, и оба опираются на одни и те же флаги — разница в том, кто их задаёт. Первый — всё в одном образе: Go-бинарник и Chromium рядом, chromedp запускает процесс сама, как локально. Плюсы: простой деплой и отладка, меньше движущихся частей; минус — большой образ и общий жизненный цикл: обновление браузера пересобирает и приложение. Второй — связка из двух образов: контейнер с Chrome и открытым портом отладки 9222 плюс тонкий Go-контейнер, который подключается через NewRemoteAllocator — механику удалённого подключения вы видели в пуле из девятнадцатого урока. Плюсы: браузер масштабируется и перезапускается независимо, один инстанс обслуживает несколько приложений, у него свои лимиты памяти. Минусы: общая docker-сеть, порт, health-check и чуть больше настройки. Начинайте с одного образа и переходите к связке, когда браузер станет общим ресурсом. Приятное свойство схемы: смена раскладки не меняет код — действия, ожидания и таймауты из первых уроков работают одинаково, меняется только аллокатор, то есть строка с адресом браузера.

compose-файл — самый удобный способ собрать связку: браузерный сервис с Chromium и Go-приложение рядом в одной сети. Для браузера задайте четыре вещи. Команду запуска с флагами — headless, no-sandbox, remote-debugging-port=9222 и disable-dev-shm-usage, если браузер стартует не из chromedp. Порты наружу не публикуйте без нужды: клиентам внутри сети compose хватает имени сервиса, а открытый вовне порт отладки — это консоль управления браузером, доступная любому. shm_size в мегабайтах, если оставляете разделяемую память вместо флага. restart: unless-stopped, чтобы упавший Chrome поднимался сам, и лимит памяти, посчитанный по вкладкам из предыдущего раздела. Приложению передайте один адрес — ws://chrome:9222 — через переменные окружения, и код из примера выше останется без изменений. Health-check по /json/version — хорошая привычка: он покажет живой порт отладки раньше, чем клиент словит connection refused, и оркестратор не отправит трафик в мёртвый контейнер.

Связка chromedp docker обязана считаться с лимитами контейнера: cgroup-ограничение на память режет не только ваше приложение, но и весь Chrome вместе с вкладками. Арифметика из пула здесь жёстче, чем кажется: вкладка лёгкой страницы — десятки мегабайт, тяжёлого SPA — сотни; четыре вкладки SPA уже держат гигабайт. Когда лимит контейнера выбран, ядро убивает самый прожорливый процесс — им будет Chrome, а не ваш парсер, и все горутины разом получат context canceled из пятнадцатого урока. Отсюда правило планирования: лимит контейнера равен памяти Go-приложения плюс число вкладок, умноженное на их тяжесть, плюс запас на пики. Запас обязателен: под давлением cgroup вкладки падают в крэш раньше формального лимита, и обход начинает терять страницы задолго до смерти браузера. Память инстанса смотрите метриками процесса, а не глазами в дашборде: тренд подскажет, когда пора поднимать лимит, уменьшать число вкладок или выносить браузер в отдельный контейнер со своей квотой.

Серверные ошибки читаются как маршрутная карта: текст жалобы почти всегда называет слой — процесс, окружение, сеть или память. Старт процесса с жалобой на песочницу или X server — слой флагов и пакетов. Вкладки падают пачками на тяжёлых страницах — слой /dev/shm или памяти контейнера. Клиент не достучался до ws://chrome:9222 — слой docker-сети и портов: сервисы в разных сетях, порт не опубликован, опечатка в имени. Квадраты на рендере — слой шрифтов, и никакой код это не починит. Логи контейнера читайте целиком: жалобы Chrome на память и песочницу пишутся в stderr и попадают в docker logs, а не в ваш Go-лог — связать их по времени с ошибками Run значит собрать половину диагноза. Общий приём тот же, что в отладке из двадцать второго урока: воспроизведите минимальным кодом — Navigate на простую страницу с русским текстом и скриншот, — и симптом локализуется за минуты, до чтения конфигов. Таблица ниже собирает типовые пары «симптом — лечение»; держите её под рукой при первой сборке образа: она экономит вечер блужданий по логам.