Рабочая станция в Docker контейнере

    Для чего? Мне постоянно приходят всякие идеи и некоторые из них сразу хочется попробовать, но рабочая станция не всегда под рукой, поэтому я настраивал IDE на всем что попадется под руку. В итоге устройства начали захламляться, а поддерживать и обновлять их стало тяжело.

    Чтобы решить эту проблему я решил разместить такую «записную книжку» в облаке, и что бы ежедневно обновлялась и удаляла весь накопившийся мусор. А для работы подключаться к нему удаленно.

    image

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

    Для создания такого контейнера необходимо написать свой Dockerfile. А в статье опишу весь процесс его создания. Кто не хочет создавать сам, а хочет взять и попробовать, то внизу статьи будут ссылки на готовые образы.

    Операционная система


    Подойдет любой линукс. Лично я предпочитаю красивый OpenSuse, но сравнив его потребление памяти с CentOS решил выбрать последний. Ведь чем меньше памяти потребляет контейнер, тем больше можно сэкономить на его хостинге.

    Начнем создавать Dockerfile:

    FROM centos:7
    

    Удаленный доступ


    Для того что бы подключиться к контейнеру на нем необходимо настроить сервер удаленного доступа VNC. Для этого надо понимать два фактора:

    1. У системы нету монитора. Поэтому его придется эмулировать. Для этого существует специальный сервер x0vncserver.
    2. VNC Server должен быть не прихотлив к ресурсам. Ведь за них надо платить. А лаги в передачи сигнала должны быть минимальны, иначе они вызывают дискомфорт.

    Для решения обоих проблем я выбрал TigerVNC Server для сервера и TightVNC для клиента. TigerVNC Server входит в поставку любого линукса, легкий, быстрый, а также поддерживает работу без монитора через x0vncserver. TightVNC клиент обеспечивает настолько быструю передачу картинки, что создается ощущение что это не удаленное подключение, а программа запущенная на компьютере.

    Дополним Dockerfile:

    FROM centos:7
    
    RUN yum install -y epel-release dnf \
            && \
            dnf install -y \
                tigervnc-server \
            && \
            yum clean all && dnf clean all \
            && \
            rm -rf /var/cache/yum/* && rm -rf /var/cache/dnf/*
    

    После установки программ очищаем кеш для облегчения веса образа.

    Рабочий стол


    Я очень люблю KDE с темой Breeze, но KDE очень прожорливый рабочий стол. Gnome и его производные оказались еще более прожорливыми. Xfce, Ice слишком уж не красивые. К счастью решение есть — рабочий стол LXQT с темой Kde-Plasma.

    Доустанавливаем рабочий стол:

    FROM centos:7
    
    RUN yum install -y epel-release dnf \
            && \
            dnf install -y \
                tigervnc-server \
                openbox obconf-qt \
                lxqt-about lxqt-common lxqt-config lxqt-globalkeys lxqt-notificationd \
                lxqt-openssh-askpass lxqt-panel lxqt-policykit lxqt-qtplugin lxqt-runner \
                lxqt-session pcmanfm-qt \
                dejavu-sans-mono-fonts \
                xterm nano htop expect sudo \
            && \
            yum clean all && dnf clean all \
            && \
            rm -rf /var/cache/yum/* && rm -rf /var/cache/dnf/*
    

    Еще чуть чуть и можно запускать.

    Создание пользователя


    В контейнере необходимо работать от какого то пользователя. Для этого его надо создать и задать пароль, а так же задать пароль пользователю root:

    ... Dockerfile
    
    ENV HOME=/home/headless
    
    RUN /bin/dbus-uuidgen --ensure && \
            useradd headless && \
            echo "centos" | passwd --stdin root && \
            echo "centos" | passwd --stdin headless
    

    Здесь headless это пользователь которого мы создаем и от которого будем работать, «centos» это пароль заданный пользователю и руту. Его лучше передавать из внешних параметров при запуске контейнера, но даже в таком виде контейнер не будет уязвим, т.к. соединение будет запаролено в VNC через пароль в аргументах.

    Настройка запуска vnc сервера


    Для запуска понадобиться вспомогательный скрипт который настроит наш VNC Server:

    #!/usr/bin/expec
    
    spawn /usr/bin/vncserver :1 -fg -geometry 1820x960
    expect "Password:"
    send "$env(password)\r"
    expect "Verify:"
    send "$env(password)\r"
    expect "Would you like to enter a view-only password (y/n)?"
    send "n\r"
    
    set timeout -1
    expect eof
    

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

    Осталось скопировать этот файл в контейнер и дописать параметры его запуска:

    ... Dockerfile
    
    COPY ./startup.sh ${HOME}
    RUN mkdir -p ${HOME}/.vnc \
            && \
            echo '#!/bin/sh' > ${HOME}/.vnc/xstartup && \
            echo 'exec startlxqt' >> ${HOME}/.vnc/xstartup && \
            chmod 775 ${HOME}/.vnc/xstartup \
            && \
            chown headless:headless -R ${HOME}
    
    
    WORKDIR ${HOME}
    USER headless
    ENTRYPOINT ["expect", "./startup.sh"]
    

    Вообщем то и все, можно запускать. Если запутались в составлении Dockerfile, то его полную версию можно найти у меня в репозитории, а готовый контейнер в docker hub.

    Для запуска готового контейнера необходимо выполнить команду:

    docker run -it --rm -e password='YOUR_VNC_PASSWORD' -p5901:5901 labeg/centos-lxqt-vnc
    

    И подключиться используя клиент TightVNC.

    image

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

    Для включения красивого оформления как в скриншоте выше необходимо зайти в Пуск > Preferences > Appearance > LXQt Theme и выбрать тему Kde-plasma.

    Программы для работы


    Теперь можно создать второй образ с рабочими программами. Для этого достаточно взять за основу образ созданный выше и дополнить его скриптами для установки пакетов:

    FROM labeg/centos-lxqt-vnc:latest
    
    USER root
    
    # dotnet vscode monodevelop nodejs git2
    RUN rpm -Uvh https://packages.microsoft.com/config/rhel/7/packages-microsoft-prod.rpm \
            && \
            rpm --import https://packages.microsoft.com/keys/microsoft.asc && \
            sh -c 'echo -e "[code]\nname=Visual Studio Code\nbaseurl=https://packages.microsoft.com/yumrepos/vscode\nenabled=1\ngpgcheck=1\ngpgkey=https://packages.microsoft.com/keys/microsoft.asc" > /etc/yum.repos.d/vscode.repo' \
            && \
            rpm --import "http://keyserver.ubuntu.com/pks/lookup?op=get&search=0x3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF" && \
            su -c 'curl https://download.mono-project.com/repo/centos7-vs.repo | tee /etc/yum.repos.d/mono-centos7-vs.repo' \
            && \
            yum install -y https://centos7.iuscommunity.org/ius-release.rpm \
            && \
            curl -sL https://rpm.nodesource.com/setup_13.x | bash - \
            && \
            dnf install -y geany git2u git2u-gui code monodevelop firefox dotnet-sdk-3.1 nodejs gnome-terminal gnome-system-monitor \
            && \
            npm install -g gulp typescript npm-check-updates \
            && \
            chown headless:headless -R ${HOME}
    
    USER headless
    
    RUN code --install-extension ms-vscode.vscode-typescript-tslint-plugin && \
        code --install-extension dbaeumer.vscode-eslint && \
        code --install-extension mrmlnc.vscode-scss && \
        code --install-extension visualstudioexptteam.vscodeintellicode && \
        code --install-extension ms-dotnettools.csharp && \
        code --install-extension joelday.docthis && \
        code --install-extension mrmlnc.vscode-remark && \
        code --install-extension eamodio.gitlens
    

    В скрипте устанавливаются инструменты для Typescript и C# разработки под линуксом. Это NodeJS, VS Code с необходимым расширениями и Monodevelop (он же Visual Studio for Mac).

    Запускается так же просто как и предыдущий образ:

    docker run -it --rm -e password='YOUR_VNC_PASSWORD' -p5901:5901 labeg/devpc
    

    Теперь в считанные секунды можно разворачивать чистое рабочее окружение.

    image

    Репозитории и готовые образы


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

    Базовый образ с рабочим столом Gihub Dockerhub.

    Образ с инструментами Typescript и C# Gihub Dockerhub.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 61

      0

      Идеологически правильнее было бы запускать эти сервисы отдельно, и линковать через docker-compose.

        +2
        Идеологически правильнее было бы использовать lxd, портянка сервисов в docker-compose получилась бы слишком большой.
          +1

          Идеологически правильнее было бы не использовать lxd, это деградация и откат к временам монолитных серверов с мешаниной конфигов. "Портянка сервисов" обеспечивает инкапсуляцию зависимостей.

            +1
            "Портянка сервисов" обеспечивает инкапсуляцию зависимостей.

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


            А разработчиков я активно уговариваю на vagrant вместо того, чтобы докер пихать в каждую дырку. Как бы под каждую задачу — СВОЕ решение.


            На самом проблема статьи — это описание проблематики. Зачем так автор делает? Если речь про облако — я всегда могу затащить виртуалку в нужной конфигурации из шаблона (packer & terraform). Если какие-то vdsки на недохостингах… Ну, что ж — выше коллега советует справедливо lxc/lxd. Либо еще варианты.

              +2
              Разве механизма разделов (volumes) недостаточно для примитивной персистентности?
                0

                Отчасти, да, для примитивного персистенца хватит. Но там надо думать все равно — постоянные нюансы с правами на файлы (если нужно пошарить файлы между несколькими контейнерами или ходить с хоста не под рутом). Это не вжух и магия ( к сожалению.
                А по докеру — ну, там ещё отдельные приседания, чтобы systemd в нем завести. Вопрос зачем? А затем, чтобы не городить эти сумасшедшие скрипты запуска. Ну, и пользоваться всеми преимуществами этой инии-системы.

                  +2
                  А по докеру — ну, там ещё отдельные приседания, чтобы systemd в нем завести.

                  Если вам в докере нужен systemd — значит вы что-то делаете неправильно.
                  Одно приложение — один контейнер. И никакого systemd.
                    0
                    Если вам в докере нужен systemd — значит вы что-то делаете неправильно.

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


                    Одно приложение — один контейнер. И никакого systemd.

                    очередная догма, которая нарушается сплошь и рядом. Можете рассказать это, например, gitlab'у, который свой докер образ предоставляет со всем нужным (редис, пума, постгрес, гитлаб). Вопрос точки зрения и целей использования. В остальном соглашусь (опять же), что лучше такого сценария избегать.

                      +1
                      Понимаете, это не догма, это правило, которое потом, при разборках где что поехало — упрощает жизнь.
                      Мы видим что поехал контейнер, инстанцированный из образа x/y:z.
                      Мы знаем, что образ x/y:z содержит только приложение Q.
                      Таким образом мы будем разбираться с исходником приложения Q, а не Q, V, M, если в контейнер запихали именно их.

                      То, что гитлаб делает не так — оставим на совести гитлаба.
                      В конце концов, можно накостылить свой systemd/init-like, но это неизбежно влечет за собой борьбу с граблями, ради которых оные и были придуманы.
                        0

                        Вы разделяйте свою внутреннюю разработку, где необходимы правила, и в целом жизнь — тот же гитлаб в такой поставке прекрасно упрощает жизнь разработчику-тестировщику, которому поднять инстанс = docker pull && docker run, а не разбираться в 100500 компонентов и их взаимосвязях. Я сам это не очень люблю, но это подход "докер как пакетный менеджер" в каком-то смысле.


                        Мы знаем, что образ x/y:z содержит только приложение Q.

                        К сожалению, это так не работает. Как правило выясняется, что Q не написан Вами, то тянет за собой A, B и C, которые добавляются в образ. А потом еще и не факт, что не конфликтуют с каким-нибудь D, который был в x/y:z. Ах! Еще забыли, что если там внутри какой-нибудь компилируемый язык типа C++, то он запросто может привязаться к архитектуре проца или его фиче флагам. И потом этот докер образ перестает быть переносимым (это не то, чтобы прям ГИПЕР проблема, но это регулярно стреляет и это надо иметь в виду, например, если занимаешься ML). И самое главное из всей этой истории — что если ты делаешь from scratch и добавляешь минимальный набор файлов и свой сервис, то ты молодец. И используешь докер правильно. А если делаешь какой-нибудь from python:3.7, а потом pip install и куча дичи, то это просто попытка замести мусор под ковер со всеми вытекающими нюансами.


                        В конце концов, можно накостылить свой systemd/init-like, но это неизбежно влечет за собой борьбу с граблями, ради которых оные и были придуманы.

                        еще раз — если у бизнес-заказчика есть задача — тестировать некие окружения, в которых systemd используется — есть развилка — или использовать тяжелую виртуализацию типа kvm/vagrant, либо lxc/lxd, либо костылять вокруг докера. Каждый решает для себя сам во что стоит идти. Например, это может понадобиться для такого. Просто примите, что у всех задачи разные. Но сказать, что это прям невозможно нельзя. Вот, например, пацаны запилили https://www.hippolab.ru/zapuskaem-systemd-v-docker-konteynere

                          +1
                          которому поднять инстанс = docker pull && docker run, а не разбираться в 100500 компонентов и их взаимосвязях

                          извините, но нет.
                          docker-compose -f smthng.yml up


                          это регулярно стреляет и это надо иметь в виду, например, если занимаешься ML

                          да, но нет. nvcr.io/pytensorflow:* замечательно переносимы и не стреляют, если не заниматься отсебятиной, запускать на ubuntu 18.x, и не забывать про необходимость видеокарты.

                          Просто примите, что у всех задачи разные.

                          Так я ж не спорю. Можно и микроскопом гвозди забивать. Если надо тестировать окружение с systemd, где systemd прям обязан стрелять — да, kvm/vagrant/vbox/whatever из гипервизоров.
                            0
                            извините, но нет.

                            фу, еще и компоуз тащить. Со всеми его нюансами. Например, в последней версии они до сих пор ключ --gpu не реализовали. Ну, оно и понятно — компоуз не для прода, чисто разработческая штука, которую допиливают по мере возможности. А то что при этом python-docker страдает параллельно… Да всем пофиг.


                            да, но нет. nvcr.io/pytensorflow:* замечательно переносимы и не стреляют, если не заниматься отсебятиной, запускать на ubuntu 18.x, и не забывать про необходимость видеокарты.

                            фу, будто других целевых платформ нет, и одним единым tensorflow живы.

                              +1
                              фу, еще и компоуз тащить. Со всеми его нюансами. Например, в последней версии они до сих пор ключ --gpu не реализовали

                              Если вам нужен ключ --gpu — то вам нужен NGC, если вам нужен NGC — вы, очевидно, знаете, как его запустить и соркестрировать с другими контейнерами из консоли.
                              За этим исключением в проде замечательно живет. Несколько менее замечательно, чем k8s, но сильно проще.

                              фу, будто других целевых платформ нет, и одним единым tensorflow живы.

                              тут ключевое nvcr.io. а так-то хоть FROM nvcr.io/cuda:10.1 собираться можно, и компиляться прям внутри. RUN nvcc и погналити. люблю этих ребят.
        0

        Если пользоваться всё равно с Windows, не лучше ли RDP вместо VNC настроить?

          0
          Можно и RDP, но мне нравится скорость TightVNC. Лаги почти не заметны даже на слабом соединении.
            +5

            Учитывая, что речь про дистрибутивы gnu/linux — крайне рекомендую попробовать x2go, его обычно достаточно в электричке с lte для вещей использующих ускорение(например QtCreator, glxgears e.t.c.).

              0
              Даже не слышал о таком. Спасибо. Попробую.
                +1
                x2go очень крут, но как же не хватает мобильного клиента
                  0

                  О, точно, я даже не знал что его нет. Но, вообще можно накостылить по идее с тем же termux + x11sdl. Так же, мобильный клиент конечно есть, под kde mobile или ubports, вот устройств поддерживаемых этими ОС в полной мере практически нет:(

                  0
                  У меня не получается.
                  Через телефон в поездках пользуюсь, но боги, как это нудно…

                  Через LAN работает отлично.
              +1
              А где вы обычно запускаете эти контейнеры? Из первого абзаца создалось впечатление, что это какое-то облако, но затем приводите примеры командной строки для запуска на локальной машине.
                0
                Подключаемся через ssh к серверу и запускаем (чтобы постоянно работало добавляем -d). Само собой на сервере должен быть установлен докер)

                p/s Вкладки firefox постоянно там крашатся(
                  +3
                  Чтобы вкладки firefox не крашились — надо увеличить в докер контейнере /dev/shm или прокидывать его с хостовой системы. По умолчанию там 64mb, а электролизис (многопоточность firefox) активно этот /dev/shm юзает.
                  docs.docker.com/compose/compose-file/#shm_size
                  0
                  Да, я пользуюсь виртуалкой в облаке. Но запускать можно в любом месте где работает docker контейнер.
                  +3
                  После подключения необходимо ввести пароль от пользователя заданный ранее. Так же рекомендуется сразу же его сменить для большей безопасности.


                  Для большей безопасности следует подключаться по VNC только через SSH туннель. Иначе все пароли и VNC траффик передаются в открытом виде.
                  Однако при подключении через туннель задержка явно будет больше.
                    0
                    Задержка не должна хоть сколько-то заметно возрасти, если туннель идёт на ту же самую машину, где VNC сервер.
                    0

                    А у меня дома рабочая машина стоит на Debian 10 и KDE или i3, я бы хотел подключаться к существующей сессии (идеально вообще к display manager, чтобы можно было выбрать wm), но tightvncserver сразу новую неполноценную открывает.

                      0

                      Расшифруйте свое понимание полноценности. У vnc есть два режима. Условный Радмин/тимвьювер, когда он хватает текущую граф сессию. А так же vnc умеет на каждое входящее соединение создавать Вирт стол. Но это надо отдельно настраивать.

                        0

                        Вот мне как раз первое и нужно, а получается второе!

                          0

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

                        +4
                        Вас интересует x11vnc тогда, а не tightvncserver.
                        +2
                        Статья — прямо пример того, как не стоит использовать докер и писать докерфайлы
                          0
                          Месье, безусловно, знает толк в извращениях, но вместо поднятия Xorg на сервере можно воспользоваться code-server — тот же самый VS Code, но сразу в браузере. Его можно запускать как через sshcode, так и упаковать в Docker-контейнер со всем необходимым. Вот так, например:

                          github.com/squizduos/code-server-dev
                            +2
                            Опять докер натягивают на глобус? Если у вас есть облако с виртуальными машинами, не проще ли создать снапшот и откатываться к нему. Или создать клон и восстанавливать виртуалку из него?
                            Нет ну конечно, это займет не пару секунд, а пару минут, но во-первых в отличии от контейнеров виртуальный сервер не надо сбрасывать так же часто, во-вторых все удобства докера заканчиваются на его быстром запуске.
                            Всю мелкую кастомизацию Visual Code, которую вы делаете после запуска, например, в меню View, вы планируете делать каждый раз после сброса контейнера?
                            В ходе разработки понадобилось доустановить либу на php? yum install...; service httpd restart? Нет, мы не ищем легких путей, пересоберем контейнер еще разок, запуск же всего несколько секунд.
                            Решили поменять внешний порт/ip? Не вопрос, сейчас опять пересоберем контейнер, это же так удобно.

                            Но самая большая проблема — чистый докер уже не модно и не профессионально. Ждем статью «удаленный рабочий стол на кластере Kubernetes с распределенной файловой системой»
                              +1
                              Всю мелкую кастомизацию Visual Code, которую вы делаете после запуска, например, в меню View, вы планируете делать каждый раз после сброса контейнера?

                              Можно просто монтировать папку с хоста внутрь докера, и никаких проблем с сохранением настроек нет.
                                0

                                А можно просто запустить visual studio никуда её не монтируя ¯_(ツ)_/¯
                                И еще я забыл упомянуть, что докер-композ будет работать примерно пол года, потом версии пакетов и их источники в репах и интернете обновятся, и вам придется уделить ему романтический вечерок под чашечку кофе, и если вдруг, например, из-за несовместимостей с иной версией gcc что-то перестанет компилиться, то вас даже ждет ночь полная страстного секаса.


                                PS Понятное дело что всегда можно найти обходные пути и костыли, но ломать ноги, чтобы искать костыли… Мне кажется это работает не так.

                                  0
                                  Про композ не понял — у меня почти только позитивный опыт с ним. Пользую докер не для графических приложений правда, а в основном для jupyter + python + julia со всеми нужными пакетами. Получается очень удобно в плане воспроизводимости — например между разными компьютерами; также нет проблем что какая-то библиотека обновилась, а питоновский пакет который от неё зависит нет. В общем, стало существенно стабильнее работать по сравнению с установкой всего нужного в хостовую систему. При этом все нужные рабочие файлы примонтированы из обычной папки на хосте.
                              0
                              Пытаюсь повторить как написано, стартонул докер, подключил TightVNC, вроде показывает, но только черный экран. Right-click menu показывает пункты, но экран черный.
                              Что я сделал не так?
                                0
                                Это тема оформления по умолчанию, с черными обоями.
                                Для включения красивого оформления как в скриншоте выше необходимо зайти в Пуск > Preferences > Appearance > LXQt Theme и выбрать тему Kde-plasma.
                                  0
                                  Где это
                                  Пуск > Preferences > Appearance >
                                  не нахожу.

                                  На черном экране могу по правой клавише выбрать только Desktop Preferences.
                                    0
                                    Вопрос снят, но я еще отметил Override.
                                    Как сделать так, чтобы докер строился уже с выбранной темой?
                                      0
                                      lxqt к сожалению не предоставляет api для смены темы, но можно найти конфиг и поменять тему. Я к сожалению сходу не нашел.
                                  0
                                  На гитхабе опечатка:
                                  FAQ
                                  Defaul root

                                  И в комментах к файлам:
                                  add support reolution from paramter,
                                    0
                                    Спасибо! Поправил.
                                    0
                                    Можно ли и как стартонуть этот docker контейнер в андроиде?
                                    0
                                    А если использовать уже достаточно популярный Alpine Linux для образа?
                                    Если уж совсем ударятся в легковесность, то наверное оно будет точно лучше CentOS, не?
                                    Кстати, я посмотрел на образы OpenSUSE… и как то они меньше по объему, чем CentoS, в два раза почти. Точно оно потребляется больше ресурсов, чем CentOS?
                                      +1

                                      alpine — как правило — отдельный геморрой с зависимостями, а выгоды не очень
                                      https://habr.com/ru/post/486202/
                                      https://m.habr.com/ru/post/415513/
                                      И это только вершина айсберга.


                                      По suse в образах ничего не скажу. Сама система неплохая, но не очень популярная. Поэтому никто особо на ней собирает. Обычно — ubuntu, debian, alpine. С этой точки зрения — тоже, если что-то пойдет не так, то придется колдовать самостоятельно.

                                      0
                                      После поднятия контейнера, внесения изменений, создании нового образа или просто рестарта контейнера — не подымается VNC. Подскажите, пожалуйста, как обойти эту проблему?
                                        0
                                        Промазал. Ответ ниже.
                                        0
                                        Да, такая проблема есть. Но я с ней очень редко сталкиваюсь, по этому мне проще пересоздать чем разобраться. Точно причин не помню, то ли vncserver при остановке контейнера не отключается, то ли после перезапуска не запускается.

                                        Если кто то разберется и пришлет пул реквест или решение внедрение которого не займет много времени, буду премного благодарен.
                                          +1
                                          Проблема заключается в не правильном выходе VNC при закрытии контейнера. Точнее, не корректном варианте именно для Docker.

                                          VNC, при рестарте, смотрит в /tmp/ на наличие свободных дисплеев и видит там уже занятый порт первого дисплея. Создавай новый дисплей, VNC помещает его в порт 590* т.к. 5901 уже занят занят первым дисплеем. Таким образом, 5901 залочен дисплеем, для которого не существует VNC процесса, и присоединистя невозможно.

                                          Решение: $sudo rm -fr /tmp/.X11-unix/; rm -fr /tmp/X1-lock; rm -fr /home/headless/.Xauthority; rm -fr /home/headless/.vnc/*.log; rm -fr /home/headless/.vnc/*.pid с последующим рестартом контейнера. VNC должен работать после рестарта.
                                            0

                                            Извините, но это не решение, а костыль — мы как бы в XXI веке, а программы все еще не умеют полноценно в лок-файлы (facepalm). Я бы предложил разработчикам VNC подумать об использовании нормальной обертки для сервиса (вот здесь пригождается systemd с его возможностью мониторинга процессов, но, сорян, мы в докере), либо системные функции вроде flock()

                                              0
                                              Спасибо большое!
                                              Добавил
                                              system «rm -fr /tmp/.X11-unix/*; rm -fr /tmp/X1-lock; rm -fr /home/headless/.Xauthority; rm -fr /home/headless/.vnc/*.log; rm -fr /home/headless/.vnc/*.pid»
                                              без судо, до запуска vnc. Теперь контейнер можно перезапускать.
                                                0
                                                Поправка: Правильный вариант с указанием точки перед Х1-lock, т.к. лок файлы по умолчанию скрыты.
                                                $sudo rm -fr /tmp/.X11-unix/; rm -fr /tmp/.X1-lock; rm -fr /home/headless/.Xauthority; rm -fr /home/headless/.vnc/*.log; rm -fr /home/headless/.vnc/*
                                              0
                                              Что с графическим ускорением?
                                                0

                                                поясните свой вопрос, пожалуйста

                                                  0
                                                  На хосте можно запустить chromium с vaapi, или firefox с wayland и они будут декодировать видео аппаратно. Аналогично дело обстоит и с другими программами, например cinnamon без аппаратного ускорения тормозит. В докере как, я понимаю, все они переключатся на программный рендеринг, что будет медленние.
                                                    0

                                                    И да, и нет. Нет — в смысле — докер — это всего лишь изоляция процессов, а не виртуализация железа. Да — в смысле — могут понадобиться дополнительные телодвижения. Например, пока не прокинете устройство аудио в докер контейнер — аудио из него не вывести.

                                                      0
                                                      Да — в смысле — могут понадобиться дополнительные телодвижения. Например, пока не прокинете устройство аудио в докер контейнер — аудио из него не вывести
                                                      Имхо, но это одна из самых важных частей. LabEG привёл то, что можно относительно быстро найти, однако не упомянул насколько работоспособным получится результат.

                                                      Я некоторое время назад создавал lxd контейнеры, и выяснение подобных подробностей как раз и помешало полноценно этим пользоваться, поскольку из коробки оно не заработало, а времени на доведение до ума не хватило.
                                                        0
                                                        Я не ставил себе цели полностью переехать в контейнеры. Поэтому с gpu не заморачивался, тем более что на хосте его нет, даже в процессоре. Но судя по таким репозиториям github.com/NVIDIA/nvidia-docker использования gpu возможно.

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

                                              Самое читаемое