Запуск chrome в docker

Обновлено: 07.07.2024

Есть несколько способов обезопасить себя и свою машину во время веб-серфинга и выполнения других сетевых задач. Наиболее простой — завести в системе специального юзера, от имени которого заходить на безопасные/опасные сайты. Другой способ — это поднять виртуальную машину, установив на нее, например, Hardened Gentoo. Еще можно установить Qubes OS, но все это слишком избыточные конфигурации, которые можно заменить контейнерной виртуализацией.

За 2011 год во всех популярных браузерах суммарно было найдено 594 уязвимости, из которых браузеру Chrome принадлежали 278, а Firefox — 89. 197 уязвимостей в Chrome относились к классу высокой степени опасности плюс одна критическая уязвимость, в то время как в Firefox уязвимостей с высокой степенью опасности оказалось 65. В следующем году в Chrome обнаружили 125 уязвимостей, из которых 68 имели высокую степень опасности, в Firefox соотношение уязвимостей стало 159/99.

Chrome 29, выпущенный 20 августа 2013 года, закрыл 25 уязвимостей, часть из которых имели высокий уровень опасности. 13 ноября того же года появился Chrome 30 с 12 закрытыми уязвимостями, отдельные из которых приводили к раскрытию личных данных пользователей. Выпущенный 2 декабря Chrome 31 закрывал 25 проблем безопасности, одна из которых носила критический статус, а 21 — высокий. Chrome 32, выпущенный 14 января 2014 года, избавился от 21 уязвимости, 16 из которых с высоким статусом опасности.

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

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

В свое время Иоанна Рутковская, получившая неофициально прозвище Руткитовская, наглядно показала, что веб-браузинг может быть достаточно безопасным только в том случае, если разные инстанции браузера для разных типов сайтов будут выполняться в обособленных виртуальных окружениях, неспособных к взаимодействию друг с другом. Идея легла в основу операционной системы Qubes OS, которая представляет собой своеобразный Linux-дистрибутив, построенный на базе технологий Xen.

К большому сожалению, в силу своей архитектуры Qubes OS оказалась мало пригодной для обычных пользователей, которым от машины нужны не только возможность запускать браузер и офисный пакет, но и возможность устанавливать проприетарные драйверы, большой репозиторий софта и куча других возможностей. Поэтому в рамках данной статьи я хочу показать, как идею разделения браузера и задач можно реализовать в любом Linux-дистрибутиве без каких-либо серьезных ограничений.

Та самая Qubes OS

В Qubes OS Рутковская использовала Xen, обосновав свой выбор логически более низким уровнем изоляции (ниже ядра Linux) и сравнительно небольшим объемом кода гипервизора, найти ошибку в котором по логике должно быть гораздо сложнее, чем в ядре Linux (если речь идет о KVM или, например, OpenVZ). Для нас же Xen не слишком удачное решение, которое создает слишком много ограничений. KVM также не очень удобен, а вот контейнерная виртуализация вроде OpenVZ или LXC подойдет очень даже хорошо.

Контейнерный тип виртуализации не так безопасен, как Xen и даже KVM, но его уровня изоляции будет более чем достаточно для решения нашей задачи. Я лично предпочитаю использовать LXC, но выбор инструмента и дистрибутива тут совсем не принципиален. Также я хотел бы обратить внимание на надстройку для LXC под названием Docker, которая существенно упрощает развертывание виртуальных окружений.

Разделив задачи между разными виртуальными окружениями, мы решим сразу несколько проблем:

Компрометация браузера во время серфинга по разным развлекательным сайтам не приведет к утечке рабочих и финансовых данных.
В случае получения контроля над одним из браузеров/окружений остальные два, а также основная система останутся в безопасности (по крайней мере до тех пор, пока взломщик не найдет способ выйти за пределы окружения).
Для разных типов сайтов мы сможем использовать разные браузеры и настройки (в «финансовом» окружении, например, нет смысла устанавливать расширения, а в некоторых случаях можно обойтись без JavaScript).
Мы сможем делать снимки окружений для быстрого восстановления или переноса на другую машину.

Самый простой способ развернуть окружение на базе LXC — это воспользоваться Docker. В Ubuntu, Arch Linux и многих других дистрибутивах Docker есть в основном репозитории, поэтому для его установки достаточно набрать одну команду:

Далее запускаем docker-демон. В Arch/Fedora так:

В Debian/Ubuntu так:

Теперь мы готовы развернуть новое окружение. Сделать это не сложнее, чем установить сам Docker:

Эта команда загрузит базовый образ окружения Ubuntu с сайта проекта, создаст новый LXC-контейнер, поднимет виртуальный сетевой интерфейс и запустит команду top внутри него. Размер образа — около 650 Мб, внутри минимальная система. Для загрузки также доступны Fedora, Debian, минималистичный образ с BusyBox и множество других. Доступны также и неофициальные образы, наиболее примечательный из которых magglass1/docker-browser-over-ssh. Это уже готовая сборка Ubuntu с предустановленным Google Chrome, Firefox и форвардингом X11 через SSH.

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

Когда образ будет получен, запускаем контейнер:

После недолгой инициализации на экране появятся примерно такие строки:

Получаем образ контейнера с Firefox и Chrome внутри

Это IP-адрес окружения (он может изменяться между запусками), рандомно сгенерированный пароль и команды для запуска браузеров. Теперь достаточно открыть второй эмулятор терминала и набрать одну из них. Браузер будет открыт в отдельном окне. Не самый удобный способ, зато он имеет ряд преимуществ:

Благодаря особенностям Docker каждый новый запуск браузера будет происходить «в чистую». Другими словами, нам не потребуются разные варианты окружения для разных задач. Для того чтобы зайти на потенциально небезопасный сайт или интернет-банк, достаточно просто запустить новое окружение, выполнить работу и закрыть.
Такой сэндбокс легко развернуть на любой доступной Linux-машине. Главное — наличие интернета.
SSH-форвардинг позволяет полностью отрезать контейнер от основной системы.
Достаточно высокая производительность браузера.

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

Запускаем Firefox в контейнере через SSH

Теперь попробуем создать несколько однотипных окружений для разных целей. В этот раз воспользуемся Ubuntu, чистым LXC и X-сервером Xephyr, последний позволит нам создать виртуальный X-сервер в гостевой машине, картинка которого будет отображаться внутри десктопа хостовой системы. Этот вариант не многим лучше проброса по SSH, он просто другой.

LXC у нас уже установлен как зависимость Docker, поэтому доустанавливаем debootstrap и bridge-utils:

Теперь создаем новый контейнер. Назовем его web-browser:

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

Устанавливаем нужный софт в контейнер:

Теперь пишем небольшой скрипт, который поможет нам запустить Firefox внутри псевдодесктопа:

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

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

Чтобы иконка появилась на рабочем столе, ее следует положить в каталог

Запускаем контейнер в Docker

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

К сожалению, требуемая функциональность доступна только в разрабатываемой на момент написания статьи Ubuntu 14.4 и еще не вышедшем LXC 1.0. Зато инструкция, как это сделать, уже есть, и написана она Стефаном Грабером, тем самым человеком, который занимается поддержкой пакета LXC в Ubuntu. Ни в коем случае не претендуя на авторство метода, я приведу здесь суть его цикла статей, что будет интересно и пользователям Ubuntu 14.4, и всем тем, кто хочет узнать, на что способен LXC.

Способ создания контейнера из раздела «LXC и Xephyr» гарантированно работает только в Ubuntu. В других дистрибутивах, скорее всего, придется самостоятельно поднимать сетевой мост и формировать образ контейнера.

Итак, контейнеры пространства пользователя используют так называемые user namespaces, появившиеся в ядре Linux 3.0.12. Они позволяют отображать определенные диапазоны UID и GID из хост-системы в произвольные диапазоны UID:GID внутри контейнера, благодаря чему непривилегированного юзера хост-системы можно сделать root’ом внутри контейнера. Вся эта функциональность контролируется ядром плюс несколькими модифицированными утилитами вроде нового loginuid и утилит пакета shadow. Также появилась утилита lxc-user-nic с setuid-битом, которая позволяет управлять ограниченным набором сетевых настроек от имени непривилегированного пользователя. В основном она используется для изменения настроек сетевого моста.

Специально для создания userspace-контейнеров разработчики LXC подготовили шаблон download, который автоматически выкачивает из Сети регулярно обновляемую сборку Debian или Ubuntu и создает на ее основе новое виртуальное окружение. Чтобы получить эту сборку (в данном случае речь идет об Ubuntu 12.04) и создать новый контейнер (назовем его опять же web-browser), достаточно выполнить одну простую команду:

Далее необходимо сделать так, чтобы в контейнер были проброшены необходимые для вывода картинки файлы устройств, а также сокет X11. Для этого открываем конфиг контейнера

/.local/share/lxc/web-browser/config и пишем в него следующее:

Далее находим в конфиге следующие строки:

И заменяем их на такие, поставив вместо 1000 собственные UID и GID в системе:

Все это означает, что UID/GID от 0 до 65535 в гостевой системе будут равны хостовым 100000– 165535. Исключением будет только UID:GID 1000 (то есть наш UID в хост-системе), он должен быть одинаковым в обеих системах, что позволит гостю работать с иксами, видео и аудиодрайвером. Проще говоря, хост-система будет воспринимать запущенный в контейнере браузер как «родное» приложение.

Далее исправляем владельца домашнего каталога внутри контейнера на наш UID:GID:

Устанавливаем Chrome внутрь контейнера:

Пишем скрипт для запуска хрома в контейнере:

Скрипт проверяет, запущен ли контейнер, если нет, то запускает и стартует внутри него Chrome. Основная суть всех этих действий состоит в том, чтобы не запускать уже работающий контейнер дважды, а также получить возможность создания и запуска нескольких разных контейнеров. Для этого достаточно клонировать уже готовый контейнер так, как описано в предыдущем разделе, и заменить имя web-browser на имя нового контейнера в начале скрипта.

Как и в случае со способом из предыдущего раздела, создаем десктоп-файл для запуска браузера по клику иконки:

На этом все. Такой контейнер будет лучшим решением из всех возможных. Он позволяет открывать несколько копий браузера в разных окружениях без всяких ограничений, с возможностью 3D-ускорения, выводом звука, плавным проигрыванием видео и без лишних виртуальных рабочих столов. Кстати, в оригинальном решении Стефана Грабера была также предусмотрена возможность записи звука с помощью PulseAudio, но я ее убрал для сохранения простоты.

Chrome внутри userspace-контейнера

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

Полезные ссылки

Оригинал статьи Стефана Грабера: goo.gl/qOa9F3

Евгений Зобнин

Редактор рубрики X-Mobile. По совместительству сисадмин. Большой фанат Linux, Plan 9, гаджетов и древних видеоигр.

Строго говоря, Docker не был создан для подобного рода вещей, а именно запуска графических приложений. Однако, время от времени в темах про Docker звучат вопросы о том, нельзя ли запустить GUI-приложение в контейнере. Причины могут быть разные, но чаще всего, это желание сменить излишне громоздкую виртуальную машину на что-то полегче, не потеряв в удобстве и сохранив при этом достаточный уровень изоляции.

Это небольшой обзор способов запуска графических приложений в контейнерах Docker.

Монтирование устройств

Один из самых простых способов заставить контейнер говорить и показывать — это дать ему доступ к нашему экрану и звуковым устройствам.

Для того, чтобы приложения в контейнере могли подключиться к нашему экрану можно воспользоваться доменными сокетами Unix для X11, которые, обычно, лежать в директории /tmp/.X11-unix . Сокеты можно расшарить, смонтировав эту директорию с помощью параметра -v . Также необходимо настроить переменную окружения DISPLAY, которая указывает приложениям экран для вывода графики. Так как выводить мы будем на наш экран, то достаточно скопировать значение DISPLAY хостовой машины. Обычно, это :0.0 или просто :0 . Пустое имя хоста (перед двоеточием) подразумевает локальное соединение с использованием самого эффективного транспорта, что в большинстве случаев означает доменные сокеты Unix — как раз то, что нам нужно:

Приставка «unix» к DISPLAY здесь для явного указания использования unix-сокетов, но чаще всего в этом нет необходимости.

Ошибка авторизации

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

Такое происходит, когда расширение Xsecurity блокирует неавторизованные подключения к X-серверу. Решить эту проблему можно, например, разрешив все локальные несетевые подключения:

Или ограничиться разрешением только для root-пользователя:

В большинстве случаев этого должно быть достаточно.

Другим вариантом будет дать контейнеру возможность самостоятельно авторизовываться на X-сервере с помощью заранее подготовленного и смонтированного Xauthority-файла. Создать такой можно с помощью утилиты xauth, которая способна извлекать и экспортировать данные для авторизации. Загвоздка, однако, в том, что такая авторизационная запись содержит в себе имя хоста, на котором запущен X-сервер. Просто скопировать ее в контейнер бесполезно — запись будет проигнорирована при попытке локального подключения к серверу. Решить эту проблему можно по-разному. Опишу пару способов.

Подмена имени хоста. Идея проста. Извлекаем авторизационную запись с помощью xauth list , меняем имя хоста на другое (нужно придумать заранее) и экспортируем получившийся ключ в Xauthority-файл, который затем монтируем в контейнер:

Подмена кода соединения. Первые два байта в каждой записи из Xauthority-файла содержат код соответствия семейству соединений (TCP/IP, DECnet, локальные соединения). Если этому параметру присвоить специальное значение FamilyWild (код 65535 или 0xffff), то запись будет соответствовать любому экрану и может быть использована для любого соединения (то есть имя хоста не будет иметь значения):

А что со звуком?

Подключение звуковых устройств также не составляет большого труда. В версиях Docker до 1.2 их можно смонтировать с помощью параметра -v , при этом контейнер должен быть запущен в привилегированном режиме:

В Docker 1.2 был добавлен специальный параметр --device для подключения устройств. К сожалению, на данный момент (версия 1.2), --device в качестве значения может принимать только одно устройство за раз, а значит придется явно перечислять их все. Например:

Возможно, функция обработки всех устройств в директории через --device будет добавлена в будущих релизах (на github есть соответствующий запрос).

В итоге

Суммируя, команда для запуска контейнера с графическим приложением выглядит примерно так:

Или, для Docker версии ниже 1.2:

Пример №1

Я подумал, что для проверки графики и звука подойдет какой-нибудь аудиоплеер с графическим интерфейсом и выбрал DeaDBeeF в качестве подопытного. Для запуска нам не понадобиться ничего, кроме образа с установленным плеером.

Теперь можно запустить его и послушать, например, радио (если решите попробовать — учтите, что плеер запустится на полной громкости):

Результатом должен стать работающий плеер

SSH -X

И это все, что вам нужно! Ну, почти. Параметр -X при создании ssh соединения включает перенаправление X11, что позволяет отображать на локальной машине графическое приложение, запущенное на удаленной. В данном случае под удаленной машиной можно понимать docker-контейнер.

В контейнере при этом должен быть установлен и запущен ssh-сервер. Также следует удостовериться, что в настройках сервера разрешено перенаправление X11. Проверить это можно заглянув в /etc/ssh/sshd_config и поискав параметр X11Forwarding (или его синонимы: ForwardX11 , AllowX11Forwarding ), который должен быть установлен в yes :

А звук?

В ssh нет «волшебной» опции для перенаправления звука. Но настроить его все-таки возможно. Например, с помощью звукового сервера PulseAudio, для которого можно разрешить клиентский доступ «извне» (например, из контейнера). Проще всего это сделать через paprefs. Установив paprefs надо зайти в настройки PulseAudio и на вкладке «Network Settings» поставить галочку напротив «Enable network access to local sound devices» (включение сетевого доступа к локальным звуковым устройствам). Там же можно найти опцию «Don't require authentication» (не требовать авторизации). Включение этой опции разрешит неавторизованный доступ к серверу, что может упростить настройку docker-контейнеров. Для авторизованного же доступа необходимо скопировать в контейнер файл

После изменения настроек PulseAudio следует перезапустить:

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

Здесь можно увидеть, что аудиосервер «слушает» на unix-сокете (unix:/run/user/1000/pulse/native), 4713-м TCP и TCP6 портах (стандартный порт для PulseAudio).

Для того, чтобы X-приложения в контейнере подключались к нашему pulse-серверу нужно указать его адрес в переменной окружения PULSE_SERVER:

Здесь «172.17.42.1» — это адрес моего docker-хоста. Узнать этот адрес можно, например, так:

То есть строка «tcp:172.17.42.1:4713» говорит, что подключиться к pulse-серверу можно по IP-адресу 172.17.42.1, где он слушает TCP-порт 4713.

В общем случае такой настройки достаточно. Отмечу только, что при использовании вышеописанного метода весь звук будет передаваться в открытом виде (нешифрованном), что в случае использования контейнера на локальном компьютере не имеет особого значения. Но при желании этот трафик можно и зашифровать. Для этого PULSE_SERVER следует настроить на любой свободный порт на localhost (например: «tcp:localhost:64713»). В результате аудиопоток будет идти на локальный порт 64713, который в свою очередь можно пробросить на 4713-й порт хостовой машины с помощью ssh -R :

Аудиоданные при этом будут передаваться по зашифрованному каналу.

Пример №2

Как и в предыдущем примере опишем образ плеера DeaDBeF c ssh-сервером. Я буду исходить из того, что все описанные выше предварительные настройки PulseAudio проведены, а значит остается только приступить к созданию docker-образа.

Код установки плеера будет повторят код из примера ранее. Нам лишь остается добавить установку openssh-сервера.

На этот раз кроме Dockerfile создадим еще один файл — entrypoint.sh. Это скрипт для «точки входа», т.е. он будет выполняться каждый раз при запуске контейнера. В нем мы будем создавать пользователя со случайным паролем, настраивать переменную окружения PULSE_SERVER и запускать ssh-сервер.

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

Запустим контейнер, не забыв указать хост PulseAudio (порт я опущу, так как у меня он стандартный), и назовем его «dead_player»:

Узнать пароль пользователя для подключения можно с помощью команды docker logs :

Для подключения по ssh можно использовать адрес как самого контейнера, так и адрес docker-хоста (при этом порт подключения будет отличаться от стандартного 22-го; в данном случае это будет 2222 — тот, который мы указали при запуске контейнера). Узнать IP контейнера можно с помощью команды docker inspect :

Подключение к контейнеру:

Или через docker-шлюз:

Наконец, после авторизации, можно расслабиться и послушать музыку:

Subuser

Subuser позволяет запускать программы в изолированных контейнерах docker, беря на себя всю работу, связанную с созданием и настройкой контейнеров, поэтому пользоваться им могут даже люди, ничего не знающие о docker. Во всяком случае, такова идея проекта. Для каждого приложения-контейнера при этом устанавливаются ограничения в зависимости от его назначения — ограниченный доступ к директориям хоста, к сети, звуковым устройствам и т.д. По сути, subuser реализует удобную обертку над описанным здесь первым способом запуска графических приложений, так как запуск осуществляется с помощью монтирования нужных директорий, устройств и т.д.

К каждому создаваемому образу прилагается файл permissions.json, который определяет настройки доступа для приложения. Так, например, выглядит этот файл для образа vim:

Subuser имеет репозиторий (на данный момент — небольшой) готовых приложений, список которых можно увидеть с помощью команды:

Добавить приложение из репозитория можно так:

Эта команда установит приложение, назвав его firefox-flash, основанное на одноименном образе из репозитория по умолчанию.

Запуск приложения выглядит так:

Кроме использования стандартного репозитория, можно создавать и добавлять свои собственные subuser-приложения.

Проект довольно молодой и пока выглядит сыроватым, но свою задачу он выполняет. Код проекта можно найти на github: subuser-security/subuser

Пример №3

Создадим, subuser-приложение для все того же DeaDBeef. Для демонстрации создадим локальный репозиторий subuser (ни что иное как git-репозиторий). Директория

/.subuser-repo сойдет. В ней следует инициализировать git-репозиторий:

Здесь же создадим директорию для DeaDBeef:

Структура директории для subuser-образа выглядит следующим образом:

SubuserImagefile — это тот же Dockerfile. Разница лишь в возможности использовать инструкцию FROM-SUBUSER-IMAGE , которая принимает идентификатор существующего subuser-образа в качестве аргумента. Список доступных базовых образов можно посмотреть здесь: SubuserBaseImages.

Итак, подготовив структуру каталога, остается создать два файла: SubuserImagefile и permissions.json.

SubuserImagefile практически ничем не будет отличаться от приведенного ранее Dockerfile:

В permissions.json опишем параметры доступа для нашего плеера. Нам понадобиться экран, звук и интернет:

Параметр as-root позволяет запускать приложения в контейнере от имени root. По умолчанию subuser запускает контейнер с параметром --user , присваивая ему идентификатор текущего пользователя. Но deadbeef при этом отказывается запускаться (не может создать сокет-файл в домашней директории, которой не существует).

Закоммитим изменения в нашем импровизированном subuser-репозитории:

Теперь можно установить плеер из локального репозитория:

Наконец, запустить его можно с помощью следующей команды:

Удаленный рабочий стол

Раз уж контейнер так похож на виртуальную машину, а взаимодействие с ним напоминает сетевое, то в голову сразу приходит решение в виде систем удаленного доступа, таких как: TightVNC, Xpra, X2Go и т.п.

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

Пример №4

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

Что касается того, что мы будем ставить, то можно, конечно, в контейнер установить полноценную графическую оболочку вроде LXDE, XFCE, или даже Gnome с KDE. Но мне это показалось излишним для условий данного примера. Нам хватит и OpenBox.

В контейнере кроме x2go-сервера также понадобится ssh-сервер. Поэтому код будет во многом похож на приведенный в примере №2. В той части, где ставится плеер, openssh-сервер, и сервер pulseaudio. То есть останется только добавить x2go-сервер и openbox:

Также немного изменим скрипт entrypoint.sh. Нам теперь нет необходимости настраивать переменную окружения PULSE_SERVER, поэтому от этого кода можно избавиться. Кроме того, пользователя для подключения следует добавить в группу x2gouser, иначе он не сможет запустить x2go-сессию:

Запустим контейнер в режиме демона:

Теперь, когда контейнер работает, к нему можно подключиться с помощью x2goclient, как мы подключались бы к любой удаленной машине. В настройках подключения в качестве хоста следует указать адрес либо самого контейнера, либо docker-хоста (в этом случае стоит также учесть нестандартный порт подключения ssh). Узнать логин и пароль для авторизации можно с помощью команды docker logs , как показано в примере №2. Для запуска openbox-сесcии в настройках «Session type» следует выбрать «Custom desktop» и в поле «Command» прописать «openbox-session».

После подключения можно запустить плеер через меню openbox (правый клик мышью) и проверить его работоспособность:

Но это уже совсем другая история.

Добавлю еще, что X2Go позволяет запускать одиночные приложения, так, как если бы они запускались на локальной машине. Для этого надо в клиенте в настройках «Session type» выбрать «Single application» и в «Command» прописать путь к исполняемому файлу. При этом в контейнере даже нет необходимости устанавливать графическую среду — достаточно иметь X2Go-сервер и желаемое приложение.

Вы, конечно, прекрасно знаете, что такое docker и контейнеры и даже как развернуть модель машинного обучения в docker? Но есть еще один интересный вопрос: как запустить и открыть любое приложение с графическим интерфейсом в docker? Похоже, это не так просто. Но сейчас мы со всем разберемся…

В статье мы пройдем этот процесс, выполнив несколько этапов.

Запуск контейнера в docker в режиме графического интерфейса.

Запуск любого ПО с графическим интерфейсом в контейнере.

Первым делом установим docker в компьютере, используя такую команду:

yum install docker

Затем нужно запустить и включить службу «Docker». Делается это следующими командами:

systemctl start docker

systemctl enable docker

Теперь добавляем образ:

docker pull centos:8

Теперь запустим контейнер Docker…

Здесь с помощью параметра -it в интерактивном терминале задается название контейнера, в нашем случае это «vedantos».

docker container run -it — name=<any name> centos:8

Теперь нужно установить firefox в контейнере:

Для этого используем команду

yum install firefox -y

Как думаете, будет работать наш firefox или нет? Правильно! Конечно же, нет.

Видите здесь ошибку с переменной окружения DISPLAY? Нужно задать эту переменную окружения.

Переходим на localhost и выполняем следующие команды (чтобы продолжить, нам нужно создать каталог, а затем Dockerfile):

Здесь мы создали каталог doraemon и внутри него Dockerfile.

Внутри Dockerfile нужно ввести следующие команды:

docker build -t firefox .

Эта точка в конце тоже важна для выполнения всех команд, так что не забываем ставить ее:

Образ firefox находится среди образов docker в списке отображения:

Теперь для доступа к firefox вводим:

docker container run -it — env=”DISPLAY” — net=host firefox

и после выполнения этой команды вот что у нас получится:

Вот и все, теперь firefox запускается в контейнере Docker.

Короткая инструкция как быстро поднять кластер для Selenium-тестов при помощи Docker.

Введение

Когда тест отправляет запрос в Selenoid, в этот момент он поднимает контейнер с запрашиваемым браузером и проксирует дальнейшие запросы внутрь. Поднятие браузера занимает несколько секунд (в зависимости от браузера). Схематично это выглядит вот так:

Здесь расскажу как организовать Selenium кластер на основе Selenoid.

Установка

Буду использовать Linux, но это будет работать и для MacOS/Windows и везде где работает Docker.

Запустить демон Selenoid можно одной командой с помощью утилиты cm. Качаем ее:

По дефолту она скачивает образы докер-контейнеров для двух последних версий Firefox, Chrome, Opera. Мы указали флаг --vnc , чтобы скачать образы к которым потом можно будет подключиться по VNC и прогонять ручные тесты. Если ручных тестов нет, то можно запускать без этого флага, тогда он скачает образы без VNC.

Когда образы скачаются, запустится Selenoid и повесится на порт 4444. Можно туда нацеливать свои тесты.

Доступные браузеры и сколько сейчас запущено можно смотреть по урлу /status :

Пример Python теста

Вот у меня есть пример теста на python:

8 секунд - хороший результат. Рядом с тестом появился скриншот:

Web-интерфейс

У selenoid есть и web-UI, он устанавливается отдельно. Это отдельный контейнер. Запустить можно так же с помощью cm :

На вкладке Capabilites есть примеры кода для разных языков, и можно запустить браузер вручную. Ручной запуск будет работать только если при старте selenoid был указан флаг --vnc .

Когда нажимаем Create Session , Selenoid запускает докер контейнер с настоящим браузером и с помощью novnc клиента на веб-морде можно подключиться внутрь и посмотреть на браузер в контейнере. Он полностью рабочий и им можно манипулировать

Читайте также: