Docker: запуск графических приложений в контейнерах
Строго говоря, Docker не был создан для подобного рода вещей, а именно запуска графических приложений. Однако, время от времени в темах про Docker звучат вопросы о том, нельзя ли запустить GUI-приложение в контейнере. Причины могут быть разные, но чаще всего, это желание сменить излишне громоздкую виртуальную машину на что-то полегче, не потеряв в удобстве и сохранив при этом достаточный уровень изоляции.Это небольшой обзор способов запуска графических приложений в контейнерах Docker.
Монтирование устройствОдин из самых простых способов заставить контейнер говорить и показывать — это дать ему доступ к нашему экрану и звуковым устройствам.Для того, чтобы приложения в контейнере могли подключиться к нашему экрану можно воспользоваться доменными сокетами Unix для X11, которые, обычно, лежать в директории /tmp/.X11-unix. Сокеты можно расшарить, смонтировав эту директорию с помощью параметра -v. Также необходимо настроить переменную окружения DISPLAY, которая указывает приложениям экран для вывода графики. Так как выводить мы будем на наш экран, то достаточно скопировать значение DISPLAY хостовой машины. Обычно, это :0.0 или просто :0. Пустое имя хоста (перед двоеточием) подразумевает локальное соединение с использованием самого эффективного транспорта, что в большинстве случаев означает доменные сокеты Unix — как раз то, что нам нужно:
$ docker run -e DISPLAY=unix$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix
$ DOCKER_CONTAINER_HOSTNAME=foobar
$ xauth list $DISPLAY | sed -e «s/$HOSTNAME/$DOCKER_CONTAINER_HOSTNAME/» | xargs xauth -f /tmp/.docker.Xauthority add
$ docker run -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix \
-v /tmp/.docker.Xauthority -e XAUTHORITY=/tmp/.docker.Xauthority -h $DOCKER_CONTAINER_HOSTNAME
FROM debian: wheezy
ENV DEBIAN_FRONTEND noninteractive
RUN apt-get update
RUN apt-get install -yq wget
# установка deadbeef RUN wget -P /tmp 'http://sourceforge.net/projects/deadbeef/files/debian/0.6.2/deadbeef-static_0.6.2–2_amd64.deb' \ && dpkg -i /tmp/deadbeef-static_0.6.2–2_amd64.deb || true \ && apt-get install -fyq --no-install-recommends \ && ln -s /opt/deadbeef/bin/deadbeef /usr/local/bin/deadbeef \ && rm /tmp/deadbeef-static_0.6.2–2_amd64.deb
# будем запускать проигрыватель вместе с контейнером
ENTRYPOINT [»/opt/deadbeef/bin/deadbeef»]
Соберем образ:
$ docker build -t deadbeef .
Теперь можно запустить его и послушать, например, радио (если решите попробовать — учтите, что плеер запустится на полной громкости):
$ docker run --rm -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=unix$DISPLAY \
--device=/dev/snd/controlC0 --device=/dev/snd/pcmC0D0p --device=/dev/snd/seq --device=/dev/snd/timer \
deadbeef http://94.25.53.133/ultra-128.mp3
Результатом должен стать работающий плеер
SSH -X
И это все, что вам нужно! Ну, почти. Параметр -X при создании ssh соединения включает перенаправление X11, что позволяет отображать на локальной машине графическое приложение, запущенное на удаленной. В данном случае под удаленной машиной можно понимать docker-контейнер.В контейнере при этом должен быть установлен и запущен ssh-сервер. Также следует удостовериться, что в настройках сервера разрешено перенаправление X11. Проверить это можно заглянув в /etc/ssh/sshd_config и поискав параметр X11Forwarding (или его синонимы: ForwardX11, AllowX11Forwarding), который должен быть установлен в yes:
X11Forwarding yes А звук? В ssh нет «волшебной» опции для перенаправления звука. Но настроить его все-таки возможно. Например, с помощью звукового сервера PulseAudio, для которого можно разрешить клиентский доступ «извне» (например, из контейнера). Проще всего это сделать через paprefs. Установив paprefs надо зайти в настройки PulseAudio и на вкладке «Network Settings» поставить галочку напротив «Enable network access to local sound devices» (включение сетевого доступа к локальным звуковым устройствам). Там же можно найти опцию «Don’t require authentication» (не требовать авторизации). Включение этой опции разрешит неавторизованный доступ к серверу, что может упростить настройку docker-контейнеров. Для авторизованного же доступа необходимо скопировать в контейнер файл ~/.pulse-cookie.После изменения настроек PulseAudio следует перезапустить:
$ sudo service pulseaudio restart
или $ pulseaudio -k && pulseaudio --start
В некоторых случаях может потребоваться перезагрузка. Проверить принялись ли настройки можно с помощью команды pax11publish, вывод которой должен выглядеть примерно так:
Server: <...>unix:/run/user/1000/pulse/native tcp:
$ PULSE_SERVER=tcp:172.17.42.1:4713 Здесь »172.17.42.1» — это адрес моего docker-хоста. Узнать этот адрес можно, например, так: $ ip route | awk '/docker/ { print $NF }' 172.17.42.1 То есть строка «tcp:172.17.42.1:4713» говорит, что подключиться к pulse-серверу можно по IP-адресу 172.17.42.1, где он слушает TCP-порт 4713.В общем случае такой настройки достаточно. Отмечу только, что при использовании вышеописанного метода весь звук будет передаваться в открытом виде (нешифрованном), что в случае использования контейнера на локальном компьютере не имеет особого значения. Но при желании этот трафик можно и зашифровать. Для этого PULSE_SERVER следует настроить на любой свободный порт на localhost (например: «tcp: localhost:64713»). В результате аудиопоток будет идти на локальный порт 64713, который в свою очередь можно пробросить на 4713-й порт хостовой машины с помощью ssh -R:
$ ssh -X -R 64713: localhost:4713
На этот раз кроме Dockerfile создадим еще один файл — entrypoint.sh. Это скрипт для «точки входа», т.е. он будет выполняться каждый раз при запуске контейнера. В нем мы будем создавать пользователя со случайным паролем, настраивать переменную окружения PULSE_SERVER и запускать ssh-сервер.
Dockerfile:
FROM debian: wheezy
ENV DEBIAN_FRONTEND noninteractive
RUN apt-get update
RUN apt-get install -yq wget
# установка deadbeef RUN wget -P /tmp 'http://sourceforge.net/projects/deadbeef/files/debian/0.6.2/deadbeef-static_0.6.2–2_amd64.deb' \ && dpkg -i /tmp/deadbeef-static_0.6.2–2_amd64.deb || true \ && apt-get install -fyq --no-install-recommends \ && ln -s /opt/deadbeef/bin/deadbeef /usr/local/bin/deadbeef \ && rm /tmp/deadbeef-static_0.6.2–2_amd64.deb
# минимальная установка pulseaudio RUN apt-get install -yq --no-install-recommends pulseaudio
RUN apt-get install -yq \ pwgen \ openssh-server
# создаем директорию необходимую для запуска ssh-сервера RUN mkdir -p /var/run/sshd
ADD entrypoint.sh /entrypoint.sh RUN chmod +x /entrypoint.sh
EXPOSE 22
ENTRYPOINT [»/entrypoint.sh»] Порт и адрес pulse-сервера будем передавать в качестве параметров при запуске контейнера, чтобы иметь возможность поменять их на нестандартные (не забыв о значениях по умолчанию).entrypoint.sh:
#!/bin/bash
# формируем переменную окружения PULSE_SERVER PA_PORT=${PA_PORT:-4713} PA_HOST=${PA_HOST:-localhost} PA_SERVER=«tcp:$PA_HOST:$PA_PORT»
# имя пользователя для подключения DOCKER_USER=dockerx
# генерируем пароль пользователя DOCKER_PASSWORD=$(pwgen -c -n -1 12) DOCKER_ENCRYPTED_PASSWORD=$(perl -e 'print crypt ('»$DOCKER_PASSWORD»', «aa»)')
# выводим имя и пароль пользователя, # чтобы их можно было увидеть с помощью docker logs echo User: $DOCKER_USER echo Password: $DOCKER_PASSWORD
# создаем пользователя useradd --create-home --home-dir /home/$DOCKER_USER --password $DOCKER_ENCRYPTED_PASSWORD \ --shell /bin/bash --user-group $DOCKER_USER
# добавляем инициализацию и экспорт PULSE_SERVER в ~/.profile для нового пользователя, # чтобы она была доступна во время его сессии echo «PULSE_SERVER=$PA_SERVER; export PULSE_SERVER» >> /home/$DOCKER_USER/.profile
# запускаем ssh-сервер exec /usr/sbin/sshd -D Соберем образ: $ docker build -t deadbeef: ssh . Запустим контейнер, не забыв указать хост PulseAudio (порт я опущу, так как у меня он стандартный), и назовем его «dead_player»: $ docker run -d -p 2222:22 -e PA_HOST=»172.17.42.1» --name=dead_player deadbeef: ssh Узнать пароль пользователя для подключения можно с помощью команды docker logs: $ docker logs dead_player User: dockerx Password: vai0ay7OuNga Для подключения по ssh можно использовать адрес как самого контейнера, так и адрес docker-хоста (при этом порт подключения будет отличаться от стандартного 22-го; в данном случае это будет 2222 — тот, который мы указали при запуске контейнера). Узнать IP контейнера можно с помощью команды docker inspect: $ docker inspect --format '{{ .NetworkSettings.IPAddress }}' dead_player 172.17.0.69 Подключение к контейнеру: $ ssh -X dockerx@172.17.0.69 Или через docker-шлюз: $ ssh -X -p 2222 dockerx@172.17.42.1 Наконец, после авторизации, можно расслабиться и послушать музыку: dockerx@5e3add235060:~$ deadbeef Subuser Subuser позволяет запускать программы в изолированных контейнерах docker, беря на себя всю работу, связанную с созданием и настройкой контейнеров, поэтому пользоваться им могут даже люди, ничего не знающие о docker. Во всяком случае, такова идея проекта. Для каждого приложения-контейнера при этом устанавливаются ограничения в зависимости от его назначения — ограниченный доступ к директориям хоста, к сети, звуковым устройствам и т.д. По сути, subuser реализует удобную обертку над описанным здесь первым способом запуска графических приложений, так как запуск осуществляется с помощью монтирования нужных директорий, устройств и т.д. К каждому создаваемому образу прилагается файл permissions.json, который определяет настройки доступа для приложения. Так, например, выглядит этот файл для образа vim:
{
«description» : «Simple universal text editor.»
, «maintainer» : «Timothy Hobbs
$ subuser run firefox-flash Кроме использования стандартного репозитория, можно создавать и добавлять свои собственные subuser-приложения.Проект довольно молодой и пока выглядит сыроватым, но свою задачу он выполняет. Код проекта можно найти на github: subuser-security/subuser
Пример №3 Создадим, subuser-приложение для все того же DeaDBeef. Для демонстрации создадим локальный репозиторий subuser (ни что иное как git-репозиторий). Директория ~/.subuser-repo сойдет. В ней следует инициализировать git-репозиторий: $ mkdir ~/.subuser-repo $ cd ~/.subuser-repo $ git init Здесь же создадим директорию для DeaDBeef: $ mkdir deadbeef Структура директории для subuser-образа выглядит следующим образом: image-name/ docker-image/ SubuserImagefile docker-build-context… permissions.json SubuserImagefile — это тот же Dockerfile. Разница лишь в возможности использовать инструкцию FROM-SUBUSER-IMAGE, которая принимает идентификатор существующего subuser-образа в качестве аргумента. Список доступных базовых образов можно посмотреть здесь: SubuserBaseImages.Итак, подготовив структуру каталога, остается создать два файла: SubuserImagefile и permissions.json.
SubuserImagefile практически ничем не будет отличаться от приведенного ранее Dockerfile:
FROM debian: wheezy
ENV DEBIAN_FRONTEND noninteractive
RUN apt-get update
RUN apt-get install -yq wget
# установка deadbeef RUN wget -P /tmp 'http://sourceforge.net/projects/deadbeef/files/debian/0.6.2/deadbeef-static_0.6.2–2_amd64.deb' \ && dpkg -i /tmp/deadbeef-static_0.6.2–2_amd64.deb || true \ && apt-get install -fyq --no-install-recommends \ && ln -s /opt/deadbeef/bin/deadbeef /usr/local/bin/deadbeef \ && rm /tmp/deadbeef-static_0.6.2–2_amd64.deb В permissions.json опишем параметры доступа для нашего плеера. Нам понадобиться экран, звук и интернет: { «description»: «Ultimate Music Player For GNU/Linux», «maintainer»: «Humble Me», «executable»:»/opt/deadbeef/bin/deadbeef», «sound-card»: true, «x11»: true, «user-dirs»: [ «Music» ], «allow-network-access»: true, «as-root»: true } Параметр as-root позволяет запускать приложения в контейнере от имени root. По умолчанию subuser запускает контейнер с параметром --user, присваивая ему идентификатор текущего пользователя. Но deadbeef при этом отказывается запускаться (не может создать сокет-файл в домашней директории, которой не существует).Закоммитим изменения в нашем импровизированном subuser-репозитории:
~/.subuser-repo $ git add. && git commit -m 'initial commit' Теперь можно установить плеер из локального репозитория: $ subuser subuser add deadbeef deadbeef@file:////home/silentvick/.subuser-repo Наконец, запустить его можно с помощью следующей команды: $ subuser run deadbeef Удаленный рабочий стол Раз уж контейнер так похож на виртуальную машину, а взаимодействие с ним происходит по сети, то в голову сразу приходит решение в виде систем удаленного доступа, таких как: TightVNC, Xpra, X2Go и т.п.Такой вариант выглядит более накладным, так как требует установки дополнительного софта — как в контейнере, так и на локальном компьютере. Но у него есть и преимущества, например:
высокая изоляция контейнера, что увеличивает безопасность при запуске подозрительных программ шифрование траффика оптимизация передачи данных по сети мультиплатформенность, а также возможность запуска полноценного графического окружения Пример №4 В качестве примера я воспользуюсь X2Go, т.к. из опробованных мною решений он приглянулся своей простотой в использовании, а также встроенной поддержкой трансляции звука. Для подключения к x2go-серверу специальная программа x2goclient. Подробнее об установке сервера и клиента можно найти на официальном сайте проекта.Что касается того, что мы будем ставить, то можно, конечно, в контейнер установить полноценную графическую оболочку вроде LXDE, XFCE, или даже Gnome с KDE. Но мне это показалось излишним для условий данного примера. Нам хватит и OpenBox.
В контейнере кроме x2go-сервера также понадобится ssh-сервер. Поэтому код будет во многом похож на приведенный в примере №2. В той части, где ставится плеер, openssh-сервер, и сервер pulseaudio. То есть останется только добавить x2go-сервер и openbox:
Dockerfile:
FROM debian: wheezy
ENV DEBIAN_FRONTEND noninteractive
RUN apt-get update
RUN apt-get install -yq wget
# установка deadbeef RUN wget -P /tmp 'http://sourceforge.net/projects/deadbeef/files/debian/0.6.2/deadbeef-static_0.6.2–2_amd64.deb' \ && dpkg -i /tmp/deadbeef-static_0.6.2–2_amd64.deb || true \ && apt-get install -fyq --no-install-recommends \ && ln -s /opt/deadbeef/bin/deadbeef /usr/local/bin/deadbeef \ && rm /tmp/deadbeef-static_0.6.2–2_amd64.deb
# минимальная установка pulseaudio RUN apt-get install -yq --no-install-recommends pulseaudio
# устанавливаем ssh-сервер и утилиту pwgen для генерации пароля RUN apt-get install -yq \ pwgen \ openssh-server
# создаем директорию, необходимую для запуска ssh-сервера RUN mkdir -p /var/run/sshd
# установка x2go-сервера RUN echo 'deb http://packages.x2go.org/debian wheezy main' >> /etc/apt/sources.list \ && echo 'deb-src http://packages.x2go.org/debian wheezy main' >> /etc/apt/sources.list \ && apt-key adv --recv-keys --keyserver keys.gnupg.net E1F958385BFE2B6E \ && apt-get update && apt-get install -yq x2go-keyring \ && apt-get update && apt-get install -yq \ x2goserver \ x2goserver-xsession
# установка openbox RUN apt-get install -yq openbox
# Добавляем пункт запуска DeaDBeeF в меню OpenBox.
#
# Для демонстрации сгодится и такой прямолинейный метод,
# но, в общем случае, лучше создать свой файл menu.xml и добавлять его через ADD
RUN sed -i '/<.*id="root-menu".*>/a
ADD entrypoint.sh /entrypoint.sh RUN chmod +x /entrypoint.sh
EXPOSE 22
ENTRYPOINT [»/entrypoint.sh»] Также немного изменим скрипт entrypoint.sh. Нам теперь нет необходимости настраивать переменную окружения PULSE_SERVER, поэтому от этого кода можно избавиться. Кроме того, пользователя для подключения следует добавить в группу x2gouser, иначе он не сможет запустить x2go-сессию: #!/bin/bash
# имя пользователя для подключения DOCKER_USER=dockerx X2GO_GROUP=x2gouser
# генерируем пароль пользователя DOCKER_PASSWORD=$(pwgen -c -n -1 12) DOCKER_ENCRYPTED_PASSWORD=$(perl -e 'print crypt ('»$DOCKER_PASSWORD»', «aa»)')
# выводим имя и пароль пользователя, # чтобы их можно было увидеть с помощью docker logs echo User: $DOCKER_USER echo Password: $DOCKER_PASSWORD
# создаем пользователя useradd --create-home --home-dir /home/$DOCKER_USER --password $DOCKER_ENCRYPTED_PASSWORD \ --shell /bin/bash --groups $X2GO_GROUP --user-group $DOCKER_USER
# запускаем ssh-сервер exec /usr/sbin/sshd -D Соберем образ: $ docker build -t deadbeef: x2go . Запустим контейнер в режиме демона: $ docker run -d -p 2222:22 --name=dead_player deadbeef: x2go Теперь, когда контейнер работает, к нему можно подключиться с помощью x2goclient, как мы подключались бы к любой удаленной машине. В настройках подключения в качестве хоста следует указать адрес либо самого контейнера, либо docker-хоста (в этом случае стоит также учесть нестандартный порт подключения ssh). Узнать логин и пароль для авторизации можно с помощью команды docker logs, как показано в примере №2. Для запуска openbox-сесcии в настройках «Session type» следует выбрать «Custom desktop» и в поле «Command» прописать «openbox-session».После подключения можно запустить плеер через меню openbox (правый клик мышью) и проверить его работоспособность:
скриншот
При желании можно добиться и более опрятного вида: скриншот
Но это уже совсем другая история.Ссылки по теме
Desktop integration examples — пара примеров образов для запуска с помощью монтирования устройств из официального репозитория Docker
jlund/docker-chrome-pulseaudio — образ Google Chrome, использующий pulseaudio для передачи звука
tomparys/skype — skype в контейнере (для звука используется pulseaudio)
dockerfile/ubuntu-desktop — образ Ubuntu LXDE с VNC-сервером на борту
rogaha/docker-desktop — Ubuntu+FluxBox с использованием Xpra
paimpozhil/DockerX2go — несколько образов с разными ОС, использующие X2go
thewtex/docker-opengl-nvidia — образ, позволяющий запускать приложения, использующие проприетарные драйвера Nvidia с поддержкой OpenGL
Can you run GUI apps in a docker container? — обсуждение вопроса на stackoverflow
