Запуск GUI-приложений в Docker-контейнере.
1. На машине с
#Wayland и без #XOrg
2. Rootless-контейнер
#Docker
3. Тяжёлое мультимедиа
#Chromium

Запуск контейнера:

docker run --rm -it \ -e XDG_RUNTIME_DIR="/run/user/$(id -u)" \ -e DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus \ -e WAYLAND_DISPLAY=$WAYLAND_DISPLAY \ -v $XDG_RUNTIME_DIR/pipewire-0:$XDG_RUNTIME_DIR/pipewire-0 \ -v $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY:$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY \ -v $XDG_RUNTIME_DIR/bus:$XDG_RUNTIME_DIR/bus \ -v $XDG_RUNTIME_DIR/pulse/native:$XDG_RUNTIME_DIR/pulse/native \ --device /dev/dri \ --device /dev/snd \ имя-образа-для-контейнера \ chromium --no-sandbox --ozone-platform=waylandНе обязательно с --rm (даёт автоматическое удаление контейнера после остановки\выхода из браузера).
Можно и оставлять контейнера в остановленном состоянии. Однако, если это делается ради сохранения данных, то это некорректно. Данные лучше хранить в монтирующихся каталогах основной системы, нежели в volumes контейнерной среды.

Где взять контейнер?
Создать пустой каталог и поместить в него вот такой
chromium-debian.Dockerfile файл:FROM debian:12 RUN apt-get update && \ apt-get install -y chromium --no-install-recommends && \ rm -rf /var/lib/apt/lists/*Зайдя в это каталог, через cd, собрать образ:docker build . \ --file chromium-debian.Dockerfile \ -t имя-образа-для-контейнера
Rootless?
Обычные rootful-контейнеры Docker уже не модно и не профессионально (запускают процессы из под root'а системы).
Годный экскурс как сделать на машине rootless-контейнеры —
https://rootlesscontaine.rs/ -> «Getting Started».
Официальная документация —
https://docs.docker.com/engine/security/rootless/
И даже пакет для разворачивания
есть.

Как это работает
Внутри контейнера учётная запись пользователя как бы является root-ом, но это локально, а на самом деле запуск им процессов в основной системе происходит из под обычного пользователя. Того самого, который создал контейнер (то самое
$(id -u) в параметрах).
За счёт файлов
/etc/subuid и /etc/subgid, которые содержат проецирование идентификаторов:$ cat /etc/subuid username:100000:65536
Зачем?
Некоторый серьёзный софт встречается лишь для определённых дистрибутивов
#linux'а, а на компьютере у человека может быть экзотичный дистрибутив.
Если в контейнере с другим линухом спокойно работает такая тяжёлая вещь как Chromium с онлайновой аудио-видео мультимедией, то значит высока вероятность, что и остальной софт будет успешно вращаться.

И не всем разработчикам подходит
запуск серверной части VSCode внутри контейнера с toolchain'ом, чтобы подключаться потом через веб-интерфейс. Иногда надо запускать и обычную GUI-тулзы или другое IDE-подобное. Причём, работая сразу с несколькими дистрибутивами, в разных контейнерах, на одной машине.

#containerization #контейнеризация #rootless @Russia @rur

Rootless Containers | Rootless Containers

Rootless Containers

@grumb
А без --no-sandbox слабо?

@max

А смысл?
Библиотека sandbox в проекте Chromium используется для понижения пермисий у запускаемых процессов. В то время как контейнеризация в rootless варианте — это уже песочница и получше использования такой библиотеки.

Если что:

Running as root without --no-sandbox is not supported.Потому что:Внутри контейнера учётная запись пользователя как бы является root-ом, но это локально, а на самом деле запуск им процессов в основной системе происходит из под обычного пользователя. Того самого, который создал контейнер (то самое $(id -u) в параметрах).

@grumb
Я и не требую запуска из-под root в контейнере, там можно запускать и от имени простого пользователя )
@max

Вот только суета чего ради? Нет задачи сделать контейнер под запуск именно Chromium, приводится этот браузер лишь как пример тяжёлого прикладного софта, активно использующегося для мультимедиа — аудио и видео, включая GPU для ускорения рендеринга.

0. Смысл и ценность поста о запуске GUI-шного софта в контейнерах — это показать максимально простой и незатейливый способ. Не отталкивающий суетой или танцами вокруг сложности, а упрощённый по максимуму вариант запуска софта под разные линуксы в rootless-контейнерах с учётом тотального перехода на wayland.

1. Сама по себе контейнеризация в rootless варианте — это уже песочница, получше той, которую может предложить использование библиотеки sandbox (для понижения пермисий у запускаемых процессов).

2. Можно запускать и Chromium без
--no-sandbox.
Однако, это частный случай решения отдельной задачи: «
запустить софтину Х определённы образом». Перегруженное деталями неактуальными для сценариев с другим прикладным софтом.
Если интересует как это реализуется, то да, знакомо. Добавляется в Docker-файл создание локальной для контейнера учётной записи (с группами, домашней директорией) и можно выставить этот аккаунт к использованию по умолчанию. При запуске контейнера можно пробрасывать в контейнер текущие uid & gid учётной записи пользовательской на хостовой машине
--user=$(id -u):$(id -g). Внутри контейнера выставлять права доступа на одно из проброшенных устройств в sysfs, чтобы запускать софтину из под локальной учётной записи, а не локального root'а.
Смотря как делать сценарии, внутри контейнера можно в
/etc/sudoers добавить группу (локальной учётной записи).
Чего точно не требуется, так это понижать меры безопасности на хостовой системе, сродни добавления
allow_anonymous в том же busconfig через файлик /etc/dbus-1/session-local.conf.

@grumb
Смысл в том, что я тоже баловался запуском GUI в контейнере.

И после игр с "пробрось иксы через SSH" перешел на использование разных RDP/VNC протоколов для отображения экрана (и соответственно до запуска DE в контейнере).

И там все далеко не так просто - подводных камней достаточно встречается.

@max

Очередной любитель смузи? И винегретов?
И не тащи этот экспириенс, драгоценно-выстраданный и ненаглядный в тему, которая абсолютно про другое.

Это три разные темы:
• запуск софта в контейнере
• аналог RemoteApp (виндового) в линухах
• доступ к DE на машине (контейнеру)

Сказанное тобой про X11 через SSH или же суету с VNC/RDP к делу (треду) не относится. Никак не касаются вопроса запуска GUI-приложений в контейнерах.

Для доступа к DE на удалённых машинах бери
#X2Go, который и работает на базе SSH и #NoMachine решение (ненаглядный NX-протокол) — уделывая капризный и упоротый #VNC, а так же любые #RDP -вариации (даже если они через udp, а не поверх традиционного tcp-соединения).

@grumb
К слову, на X2Go в итоге и остановился - как раз простота запуска через SSH очень понравилась.

Но это не очень кросс-платформенное решение оказалось - под маки клиент есть, но работает очень "не очень"...

@max Это реализация NoMachine решения, т.е. это NX-протокол, потому и следует смотреть проприетарные решения от NoMachine под маки, чтобы использовать вместо X2Go в качестве клиента :)