Авторский проект IT-специалиста Олега Барабанова Персональные публикации на тему IT и не только…

Использование Docker-OSX в VDS для тестирования веб-сайта в Safari

Некоторое время назад я стал озадачиваться вопросом удаленного тестирования разрабатываемых сайтов в браузере Safari. Суть в том, что в силу задач, я в основном веду разработку на удаленных машинах (зачастую VSCode + Remote Development) и тут встает типичная проблема тестирования работы сайта в Safari вне систем Apple.

Почему не подходит Playwright с Webkit?

Как известно, в основе Safari лежит открытый движок WebKit, который в отличие от самого Safari является вполне кроссбраузерным и его вполне можно собрать и под Linux и под Windows.

Одним из простейших способов получить скомпилированную сборку WebKit-движка является установка E2E-фреймворка Playwright, вместе с которым идут скомпилированные сборки основных движков Chromium, Firefox и многострадального WebKit.

И вот вроде бы кажется, какие там еще могут быть сложности, вот же готовый инструмент. Да вот только на деле, работа Webkit отличается и на Windows и на Linux и на Mac, т.е. по факту не всегда предоставляют реальную картину отображения в Safari на системах Apple.

Например, в недавно разрабатываемом мною проекте, при отображений его через Webkit под Windows, были множественные проблемы с отображением сложных SVG, а также куча мелких проблем с тенями, шрифтами и пр. при этом все отлично работало в Safari под OSX. И это вполне логично, поскольку Webkit опирается на какие-то системные библиотеки (для того-же рендеринга SVG) которые в разных операционных системах свои.

Поэтому в итоге всеравно крайне желательно проверять работу сайта именно в самом Safari, в его родном окружении.

Так как проверить работу сайта или веб-приложения в Safari вне систем Apple

В таком случае, у нас есть несколько вариантов, каждый из которых имеет свои плюсы и минусы:

  1. Купить или арендовать подходящую технику Apple (тот же Macbook) и проверять в ней. Ну тут все понятно.
  2. Использование сторонних сервисов, наподобие Browserstack и пр., что к сожалению не всегда доступно.
  3. Арендовать удаленный Mac-хостинг с удаленным рабочим столом. Впринципе это вполне отличное решение, но мне не попадались провайдеры с почасовой или посуточной оплатой, а при помесячной оплате нормальная машина стоит достаточно недешево.
  4. Также можно установить OSX в виртуальную машину, что в настоящее время становится все более нетривиальной задачей.
  5. Можно воспользоваться технологиями контейнеризации, таких как Docker, с использованием готовых контейнеров.

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

Что за проект Docker-OSX

Docker-OSX это свободный проект, представляющий собой возможность запуска OSX в Docker-контейнере, что вполне логично исходя из названия проекта. Фактически в контейнер засунули виртуальную машину (QEMU + KVM) в которую в свою очередь устанавливается OSX. Звучит это все очень просто, но в реальности внутри контейнера еще делается куча всякой сложной техномагии, благодаря которой OSX успешно запускается на ненативной платформе. При первом запуске контейнера, происходит скачивание образа OSX с последующей его установкой, что естественно небыстро, поэтому такие контейнеры лучше по авершению работы просто останавливать, вместо их удаления и пересоздания.

Для отображения графического интерфейса OSX, есть множество вариантов, как через проброс X11, так и через VNC, что в случае удаленного запуска намного удобнее. Т.е. все что надо, это запустить Docker-контейнер с нужными параметрами и в теории можно просто подключаться по VNC, благо все это описано в достаточно неплохой документации (см. README.md).

Нюанс запуска Docker-OSX в VDS

К сожалению, при запуске Docker-OSX в VDS есть одна сложность, заключающаяся в том, что он требует обязательного проброса /dev/kvm в контейнер, т.е. ему требуется обязательная поддержка вложенной виртаулизации.

Суть вложенной виртуализации (Nested Virtualization) состоит в поддержке вложенной аппаратной виртуализации внутри другой виртуальной машины. Т.е. проще говоря, запуск виртуалок внутри других виртуалок.

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

Изучая провайдеров, с которыми я работал, на предмет такой возможности, мне везде было отказано и предложено в таком случае взять в аренду выделенный сервер, что меня не устраивало. В итоге нашелся хостинг-провайдер Aeza, у которого на момент написания статьи была для VDS линейка тарифов "hi-cpu" с поддержкой вложенной виртуализации и при этом с почасовой оплатой. В моем случае, это было наиболее оптимальным решением, хотя я думаю, если покопаться в интернете, то можно найти и других провайдеров, предоставляющих вложенную виртуализацию с почасовой оплатой.

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

Заключение

В итоге весь процесс свелся к тому, что я взял у хостинг-провайдера на несколько часов VDS с вложенной виртуализацией, установил там Docker и запустил через него Docker-OSX с сервером VNC, к которому в свою очередь я подключился со своей локальной машины. И как ни странно, это очень даже неплохо работало, благодаря чему я смог вполне комфортно протестировать сайт в Safari, с последующим устранением некоторых багов в верстке. При этом результат рендеринга сайта в таком контейниризированном Safari был ощутимо более корректным по сравнению с тем, что мне отображал Webkit в Windows-среде.

Тем не менее, я считаю что тестирование верстки в Safari через Docker-OSX нельзя в полной мере считать надежным, поскольку при этом игнорируются аппаратные особенности систем Apple, на которые опирается браузер (например программный рендеринг вместо GPU и пр.), да и затруднительно корректно профилировать производительность веб-страницы. Я бы даже сказал что тестирование сайта в такой среде вполне допустимо, особенно в процессе разработки, но итоговый результат лучше закрепить контрольным тестированием на реальном устройстве, чтобы исключить аппаратно-зависимые баги.