Você pode executar aplicativos da GUI em um contêiner do Docker?


409

Como você pode executar aplicativos da GUI em um contêiner do Docker ?

Existem imagens configuradas vncserverou algo assim para que você possa, por exemplo, adicionar uma caixa de proteção de velocidade extra ao redor do Firefox, por exemplo?


Essa pergunta parece pertencer apenas ao Linux (com base na idade e no conteúdo das respostas) e não no Windows. Em caso afirmativo, podemos editar o título para esclarecer isso? Obrigado
UuDdLrLrSs


Consulte o Guia do usuário dos recipientes de visualização HPC para obter algumas idéias.
kenorb

Respostas:


238

Você pode simplesmente instalar um vncserver junto com o Firefox :)

Eu empurrei uma imagem, vnc / firefox, aqui: docker pull creack/firefox-vnc

A imagem foi criada com este Dockerfile:

# Firefox over VNC
#
# VERSION               0.1
# DOCKER-VERSION        0.2

FROM    ubuntu:12.04
# Make sure the package repository is up to date
RUN     echo "deb http://archive.ubuntu.com/ubuntu precise main universe" > /etc/apt/sources.list
RUN     apt-get update

# Install vnc, xvfb in order to create a 'fake' display and firefox
RUN     apt-get install -y x11vnc xvfb firefox
RUN     mkdir ~/.vnc
# Setup a password
RUN     x11vnc -storepasswd 1234 ~/.vnc/passwd
# Autostart firefox (might not be the best way to do it, but it does the trick)
RUN     bash -c 'echo "firefox" >> /.bashrc'

Isso criará um contêiner Docker executando o VNC com a senha 1234:

Para o Docker versão 18 ou mais recente:

docker run -p 5900:5900 -e HOME=/ creack/firefox-vnc x11vnc -forever -usepw -create

Para o Docker versão 1.3 ou mais recente:

docker run -p 5900 -e HOME=/ creack/firefox-vnc x11vnc -forever -usepw -create

Para o Docker anterior à versão 1.3:

docker run -p 5900 creack/firefox-vnc x11vnc -forever -usepw -create

2
Como eu usaria um cliente VNC para visualizá-lo remotamente? Digitar a porta IP + não parece estar funcionando.
user94154

17
Primeiro, você precisa verificar a porta alocada (fazendo docker inspect <container id>ou simplesmente docker ps, em seguida, conecta-se ao ip do host com a porta que acabou de encontrar.
creack

9
a imagem creackfirefox-vnc falha com erro: Digite a senha do VNC: stty: entrada padrão: ioctl inadequado para dispositivos do dispositivo: nenhum arquivo ou diretório stty: entrada padrão: ioctl inadequado para o dispositivo x11vnc -usepw: não foi possível encontrar uma senha para usar.
Alfonsodev

6
Use o docker bem> Executando aplicativos da GUI com o Docker fabiorehm.com/blog/2014/09/11/running-gui-apps-with-docker
Dennis C

7
Não há nome de usuário, a senha está claramente indicada na resposta e qualquer cliente vnc fará. No meu caso, eu gosto do nativo osx. (a partir do localizador, pressione o comando + K e conecte-se ao vnc: // <docker ip>: <porta exposta do contêiner>)
creack

195

Xauthority se torna um problema com sistemas mais novos. Posso descartar qualquer proteção com o xhost + antes de executar meus contêineres do docker ou posso passar um arquivo Xauthority bem preparado. Arquivos Xauthority típicos são específicos do nome do host. Com o docker, cada contêiner pode ter um nome de host diferente (definido com o docker run -h), mas mesmo definir o nome do host do contêiner idêntico ao sistema host não ajudou no meu caso. xeyes (eu gosto deste exemplo) simplesmente ignoraria o cookie mágico e não passaria credenciais para o servidor. Portanto, recebemos uma mensagem de erro 'Nenhum protocolo especificado Não é possível abrir a tela'

O arquivo Xauthority pode ser gravado de forma que o nome do host não importe. Precisamos definir a Família de autenticação como 'FamilyWild'. Não tenho certeza, se o xauth tem uma linha de comando adequada para isso, então aqui está um exemplo que combina xauth e sed para fazer isso. Precisamos mudar os primeiros 16 bits da saída nlist. O valor de FamilyWild é 65535 ou 0xffff.

docker build -t xeyes - << __EOF__
FROM debian
RUN apt-get update
RUN apt-get install -qqy x11-apps
ENV DISPLAY :0
CMD xeyes
__EOF__
XSOCK=/tmp/.X11-unix
XAUTH=/tmp/.docker.xauth
xauth nlist :0 | sed -e 's/^..../ffff/' | xauth -f $XAUTH nmerge -
docker run -ti -v $XSOCK:$XSOCK -v $XAUTH:$XAUTH -e XAUTHORITY=$XAUTH xeyes

8
Apenas uma nota, -v $XSOCK:$XSOCK -v $XAUTH:$XAUTHpode ser abreviada para #-v $XSOCK -v $XAUTH
Piotr Aleksander Chmielowski 13/04

2
@PiotrAleksanderChmielowski que não funcionou para mim, Docker versão 1.12.0, construção 8eab29e
tbc0

14
@Dirk: Você pode querer substituir :0por $DISPLAY. Isso significa xauth nlist $DISPLAY | ...e docker run -ti -e DISPLAY=$DISPLAY .... Normalmente, o X DISPLAY é :0, mas nem sempre (e especialmente não se você estiver se conectando via ssh -X).
Johndodo

4
No Ubuntu 16.04, o xauth cria o /tmp/.docker.xautharquivo com 600permissões. Isso faz com que o xauth dentro do contêiner do docker não consiga ler o arquivo. Você pode verificar executando xauth listno contêiner do docker. Eu adicionei chmod 755 $XAUTHapós o xauth nlist :0 | ...comando para resolver isso.
Abai 28/09

2
@Abai Por que usar 755, se 444 ou 644 é suficiente?
Daniel Alder

68

Acabei de encontrar esta entrada do blog e quero compartilhá-la aqui com você, porque acho que é a melhor maneira de fazê-lo e é tão fácil.

http://fabiorehm.com/blog/2014/09/11/running-gui-apps-with-docker/

PROS:
+ nenhum material do servidor x no contêiner do docker
+ nenhum cliente / servidor vnc necessário
+ nenhum ssh com encaminhamento x
+ contêineres do docker muito menores

CONTRAS:
- usando x no host (não destinado a sandbox seguro)

caso o link falhe algum dia, coloquei a parte mais importante aqui:
dockerfile:

FROM ubuntu:14.04

RUN apt-get update && apt-get install -y firefox

# Replace 1000 with your user / group id
RUN export uid=1000 gid=1000 && \
    mkdir -p /home/developer && \
    echo "developer:x:${uid}:${gid}:Developer,,,:/home/developer:/bin/bash" >> /etc/passwd && \
    echo "developer:x:${uid}:" >> /etc/group && \
    echo "developer ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/developer && \
    chmod 0440 /etc/sudoers.d/developer && \
    chown ${uid}:${gid} -R /home/developer

USER developer
ENV HOME /home/developer
CMD /usr/bin/firefox

construa a imagem:

docker build -t firefox .

e o comando run:

docker run -ti --rm \
   -e DISPLAY=$DISPLAY \
   -v /tmp/.X11-unix:/tmp/.X11-unix \
   firefox

é claro que você também pode fazer isso no comando run com sh -c "echo script-here"

DICA: para áudio, consulte: https://stackoverflow.com/a/28985715/2835523


Como posso fazer isso no windows 7? Preciso instalar um servidor X?
Caminhandoignon

3
Como a maioria das respostas aqui, isso se aplica apenas ao unix, eu acho - até o Windows suportar o sistema de janelas do servidor X.
A. Binzxxxxxx

Você acha que poderia funcionar se eu instalasse o servidor X no Windows ou até empacotasse um servidor X no meu contêiner Docker?
walksignison

11
Eu acho que você também precisa instalar no Dockerfile apt-get -y install sudopara criar a /etc/sudoers.dpasta.
mulg0r

11
também pode ser necessário permitir conexões ao X de qualquer host com$ xhost +
Bandoos 15/02

52

Com os volumes de dados do docker, é muito fácil expor o soquete de domínio unix do xorg dentro do contêiner.

Por exemplo, com um Dockerfile como este:

FROM debian
RUN apt-get update
RUN apt-get install -qqy x11-apps
ENV DISPLAY :0
CMD xeyes

Você pode fazer o seguinte:

$ docker build -t xeyes - < Dockerfile
$ XSOCK=/tmp/.X11-unix/X0
$ docker run -v $XSOCK:$XSOCK xeyes

É claro que isso é essencialmente o mesmo que o encaminhamento X. Ele concede ao contêiner acesso total ao xserver no host, portanto, é recomendado apenas se você confiar no que está dentro.

Nota: Se você estiver preocupado com segurança, uma solução melhor seria confinar o aplicativo com controle de acesso obrigatório ou baseado em função . O Docker atinge um bom isolamento, mas foi projetado com um objetivo diferente em mente. Use AppArmor , SELinux ou GrSecurity , que foram projetados para atender às suas preocupações.


5
Você também precisa permitir o acesso ao X Server de outros hosts usando uma ferramenta como xhost. Para abri-lo completamente, use xhost +no host.
Tully,

3
@Totalmente xhost +localé necessário. No ~/.Xauthorityentanto, seria melhor disponibilizar o arquivo no contêiner para que ele possa se autenticar.
Aryeh Leib Taurog

3
você conseguiu fazê-lo funcionar em um Mac (usando o boot2docker)?
precisa

4
Isso estava funcionando muito bem para mim em um laptop Ubuntu 14.04 com docker 1.5 anterior; mas agora está falhando para mim no Ubuntu 15.04, docker 1.6.2, com o erro Can't open display: :0. Alguma ideia?
cboettig

6
Eu costumava xhost +si:localuser:$USERautorizar apenas o usuário iniciando o contêiner.
precisa saber é o seguinte

26

Você também pode usar o subusuário: https://github.com/timthelion/subuser

Isso permite que você empacote muitos aplicativos de interface gráfica no docker. Firefox e emacs foram testados até agora. Com o Firefox, o webGL não funciona. O Chromium não funciona.

EDIT: O som funciona!

EDIT2: Desde que publiquei isso pela primeira vez, o subusuário avançou bastante. Agora, tenho um site no subuser.org e um novo modelo de segurança para conectar-se ao X11 via ponte XPRA .


3
Observe que o subusuário ainda é muito novo e relativamente não testado. Se você tiver algum problema, envie relatórios de erros!
timthelion

Eu evitaria o X11, se puder. Seu aplicativo matador estaria executando o proxy tor na janela de encaixe e executando um navegador completo com plug-ins em uma janela de encaixe infantil, de modo que o firewall etc force toda a rede a sair através da janela de encaixe tor. Isso rodaria em torno do pacote atual do navegador tor para usabilidade na Web, porque você deixaria o conteúdo rico passar.
Será

11
O problema é para você com segurança X11? Ou é que você deseja que isso funcione com o Windows? Ou você deseja que isso funcione remotamente? Tudo acima? Eu acho que fazer isso funcionar com o vnc é bem possível (embora eu não o torne o método padrão porque adiciona uma dependência do vnc). Fazer o subusuário funcionar remotamente não é realmente possível / significativo. Também existe o seguinte: github.com/rogaha/docker-desktop, mas a partir dos relatórios de erros, parece que o xpra pode ser inutilizável na vida real.
timthelion

24

OSX

Jürgen Weigert tem a melhor resposta que funcionou para mim no Ubuntu, no entanto, no OSX, o docker é executado dentro do VirtualBox e, portanto, a solução não funciona sem mais trabalho.

Eu tenho que trabalhar com estes ingredientes adicionais:

  1. Xquartz (OSX não é mais fornecido com o servidor X11)
  2. encaminhamento de soquete com socat (brew install socat)
  3. script bash para iniciar o contêiner

Eu gostaria dos comentários dos usuários para melhorar esta resposta para o OSX, não tenho certeza se o encaminhamento de soquete para o X é seguro, mas meu uso pretendido é apenas para executar o contêiner do docker localmente.

Além disso, o script é um pouco frágil, pois não é fácil obter o endereço IP da máquina, pois está em nossa rede local sem fio, portanto, sempre há um IP aleatório.

O script BASH que eu uso para iniciar o contêiner:

#!/usr/bin/env bash

CONTAINER=py3:2016-03-23-rc3
COMMAND=/bin/bash
NIC=en0

# Grab the ip address of this box
IPADDR=$(ifconfig $NIC | grep "inet " | awk '{print $2}')

DISP_NUM=$(jot -r 1 100 200)  # random display number between 100 and 200

PORT_NUM=$((6000 + DISP_NUM)) # so multiple instances of the container won't interfer with eachother

socat TCP-LISTEN:${PORT_NUM},reuseaddr,fork UNIX-CLIENT:\"$DISPLAY\" 2>&1 > /dev/null &

XSOCK=/tmp/.X11-unix
XAUTH=/tmp/.docker.xauth.$USER.$$
touch $XAUTH
xauth nlist $DISPLAY | sed -e 's/^..../ffff/' | xauth -f $XAUTH nmerge -

docker run \
    -it \
    --rm \
    --user=$USER \
    --workdir="/Users/$USER" \
    -v "/Users/$USER:/home/$USER:rw" \
    -v $XSOCK:$XSOCK:rw \
    -v $XAUTH:$XAUTH:rw \
    -e DISPLAY=$IPADDR:$DISP_NUM \
    -e XAUTHORITY=$XAUTH \
    $CONTAINER \
    $COMMAND

rm -f $XAUTH
kill %1       # kill the socat job launched above

Sou capaz de obter xeyes e matplotlib trabalhando com essa abordagem.

Windows 7 ou superior

É um pouco mais fácil no Windows 7 ou superior com o MobaXterm:

  1. Instale o MobaXterm para Windows
  2. Iniciar o MobaXterm
  3. Configurar servidor X: Configurações -> X11 (guia) -> set X11 acesso remoto a plena
  4. Use este script BASH para iniciar o contêiner

run_docker.bash:

#!/usr/bin/env bash

CONTAINER=py3:2016-03-23-rc3
COMMAND=/bin/bash
DISPLAY="$(hostname):0"
USER=$(whoami)

docker run \
    -it \
    --rm \
    --user=$USER \
    --workdir="/home/$USER" \
    -v "/c/Users/$USER:/home/$USER:rw" \
    -e DISPLAY \
    $CONTAINER \
    $COMMAND

xeyes rodando no PC


Eu não entendi o que você quis dizer com o script bash - como eu o executo no Windows?
deller

@ deller Eu desenvolvo software no Windows usando GIT, então tenho o shell GIT-bash disponível para mim.
Nick

Eu segui os passos. No entanto, eu recebo error: XDG_RUNTIME_DIR not set in the environment.e Error: cannot open display: VAIO:0.0. Você encontrou algo assim?
user3275095

11
Eu recebo um erro referente ao usuário não ser encontrado, ou seja, "nenhuma entrada correspondente no arquivo passwd".
walksignison

19

O compartilhamento de exibição do host: 0, conforme declarado em outras respostas, tem duas desvantagens:

  • Ele quebra o isolamento do contêiner devido a alguns vazamentos de segurança do X. Por exemplo, registro de chaves com xevou xinputé possível e controle remoto de aplicativos host com xdotool.
  • Os aplicativos podem ter falhas de renderização e erros de acesso à RAM devido à falta de memória compartilhada para a extensão X MIT-SHM. (Também pode ser corrigido com a opção de degradação do isolamento --ipc=host).

Abaixo um exemplo de script para executar uma imagem do Docker no Xephyr que soluciona esses problemas.

  • Evita vazamentos de segurança do X enquanto os aplicativos docker são executados em um servidor X aninhado.
  • O MIT-SHM está desativado para evitar falhas no acesso à RAM.
  • A segurança do contêiner é aprimorada com --cap-drop ALL --security-opt no-new-privileges . Além disso, o usuário do contêiner não é root.
  • Um cookie X é criado para restringir o acesso à exibição do Xephyr.

O script espera alguns argumentos, primeiro um gerenciador de janelas host para executar no Xephyr, depois uma imagem do docker, opcionalmente um terceiro comando de imagem a ser executado. Para executar um ambiente de área de trabalho na janela de encaixe, use ":" em vez de um gerenciador de janelas host.

Fechar a janela do Xephyr encerra os aplicativos de contêiner do docker. O encerramento dos aplicativos acoplados fecha a janela do Xephyr.

Exemplos:

  • xephyrdocker "openbox --sm-disable" x11docker/lxde pcmanfm
  • xephyrdocker : x11docker/lxde
  • xephyrdocker xfwm4 --device /dev/snd jess/nes /games/zelda.rom

Script xephyrdocker:

#! /bin/bash
#
# Xephyrdocker:     Example script to run docker GUI applications in Xephyr.
#
# Usage:
#   Xephyrdocker WINDOWMANAGER DOCKERIMAGE [IMAGECOMMAND [ARGS]]
#
# WINDOWMANAGER     host window manager for use with single GUI applications.
#                   To run without window manager from host, use ":"
# DOCKERIMAGE       docker image containing GUI applications or a desktop
# IMAGECOMMAND      command to run in image
#
Windowmanager="$1" && shift
Dockerimage="$*"

# Container user
Useruid=$(id -u)
Usergid=$(id -g)
Username="$(id -un)"
[ "$Useruid" = "0" ] && Useruid=1000 && Usergid=1000 && Username="user$Useruid"

# Find free display number
for ((Newdisplaynumber=1 ; Newdisplaynumber <= 100 ; Newdisplaynumber++)) ; do
  [ -e /tmp/.X11-unix/X$Newdisplaynumber ] || break
done
Newxsocket=/tmp/.X11-unix/X$Newdisplaynumber

# cache folder and files
Cachefolder=/tmp/Xephyrdocker_X$Newdisplaynumber
[ -e "$Cachefolder" ] && rm -R "$Cachefolder"
mkdir -p $Cachefolder
Xclientcookie=$Cachefolder/Xcookie.client
Xservercookie=$Cachefolder/Xcookie.server
Xinitrc=$Cachefolder/xinitrc
Etcpasswd=$Cachefolder/passwd

# command to run docker
# --rm                               created container will be discarded.
# -e DISPLAY=$Newdisplay             set environment variable to new display
# -e XAUTHORITY=/Xcookie             set environment variable XAUTHORITY to provided cookie
# -v $Xclientcookie:/Xcookie:ro      provide cookie file to container
# -v $NewXsocket:$NewXsocket:ro      Share new X socket of Xephyr
# --user $Useruid:$Usergid           Security: avoid root in container
# -v $Etcpasswd:/etc/passwd:ro       /etc/passwd file with user entry
# --group-add audio                  Allow access to /dev/snd if shared with '--device /dev/snd' 
# --cap-drop ALL                     Security: disable needless capabilities
# --security-opt no-new-privileges   Security: forbid new privileges
Dockercommand="docker run --rm \
  -e DISPLAY=:$Newdisplaynumber \
  -e XAUTHORITY=/Xcookie \
  -v $Xclientcookie:/Xcookie:ro \
  -v $Newxsocket:$Newxsocket:rw \
  --user $Useruid:$Usergid \
  -v $Etcpasswd:/etc/passwd:ro \
  --group-add audio \
  --env HOME=/tmp \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  $(command -v docker-init >/dev/null && echo --init) \
  $Dockerimage"

echo "docker command: 
$Dockercommand
"

# command to run Xorg or Xephyr
# /usr/bin/Xephyr                an absolute path to X server executable must be given for xinit
# :$Newdisplaynumber             first argument has to be new display
# -auth $Xservercookie           path to cookie file for X server. Must be different from cookie file of client, not sure why
# -extension MIT-SHM             disable MIT-SHM to avoid rendering glitches and bad RAM access (+ instead of - enables it)
# -nolisten tcp                  disable tcp connections for security reasons
# -retro                         nice retro look
Xcommand="/usr/bin/Xephyr :$Newdisplaynumber \
  -auth $Xservercookie \
  -extension MIT-SHM \
  -nolisten tcp \
  -screen 1000x750x24 \
  -retro"

echo "X server command:
$Xcommand
"

# create /etc/passwd with unprivileged user
echo "root:x:0:0:root:/root:/bin/sh" >$Etcpasswd
echo "$Username:x:$Useruid:$Usergid:$Username,,,:/tmp:/bin/sh" >> $Etcpasswd

# create xinitrc
{ echo "#! /bin/bash"

  echo "# set environment variables to new display and new cookie"
  echo "export DISPLAY=:$Newdisplaynumber"
  echo "export XAUTHORITY=$Xclientcookie"

  echo "# same keyboard layout as on host"
  echo "echo '$(setxkbmap -display $DISPLAY -print)' | xkbcomp - :$Newdisplaynumber"

  echo "# create new XAUTHORITY cookie file" 
  echo ":> $Xclientcookie"
  echo "xauth add :$Newdisplaynumber . $(mcookie)"
  echo "# create prepared cookie with localhost identification disabled by ffff,"
  echo "# needed if X socket is shared instead connecting over tcp. ffff means 'familiy wild'"
  echo 'Cookie=$(xauth nlist '":$Newdisplaynumber | sed -e 's/^..../ffff/')" 
  echo 'echo $Cookie | xauth -f '$Xclientcookie' nmerge -'
  echo "cp $Xclientcookie $Xservercookie"
  echo "chmod 644 $Xclientcookie"

  echo "# run window manager in Xephyr"
  echo $Windowmanager' & Windowmanagerpid=$!'

  echo "# show docker log"
  echo 'tail --retry -n +1 -F '$Dockerlogfile' 2>/dev/null & Tailpid=$!'

  echo "# run docker"
  echo "$Dockercommand"
} > $Xinitrc

xinit  $Xinitrc -- $Xcommand
rm -Rf $Cachefolder

Este script é mantido no wiki do x11docker . Um script mais avançado é o x11docker, que também suporta recursos como aceleração de GPU, compartilhamento de webcam e impressora e assim por diante.


18

Aqui está uma solução leve que evita a instalação de qualquer Xservidor, vncservidor ou sshddaemon no contêiner. O que ganha na simplicidade perde em segurança e isolamento.

Ele pressupõe que você se conecte à máquina host usando sshcomX11 encaminhamento.

Na sshdconfiguração do host, adicione a linha

X11UseLocalhost no

Para que a porta do servidor X encaminhado no host seja aberta em todas as interfaces (não apenas lo) e, em particular, na interface virtual do Docker docker0.

O contêiner, quando executado, precisa acessar o .Xauthorityarquivo para que ele possa se conectar ao servidor. Para fazer isso, definimos um volume somente leitura apontando para o diretório inicial no host (talvez não seja uma boa idéia!) E também configuramos a XAUTHORITYvariável de acordo.

docker run -v $HOME:/hosthome:ro -e XAUTHORITY=/hosthome/.Xauthority

Isso não é suficiente, também temos que passar a variável DISPLAY do host, mas substituindo o nome do host pelo ip:

-e DISPLAY=$(echo $DISPLAY | sed "s/^.*:/$(hostname -i):/")

Podemos definir um alias:

 alias dockerX11run='docker run -v $HOME:/hosthome:ro -e XAUTHORITY=/hosthome/.Xauthority -e DISPLAY=$(echo $DISPLAY | sed "s/^.*:/$(hostname -i):/")'

E teste assim:

dockerX11run centos xeyes

2
(Isso é ótimo para aplicativos confiáveis. No entanto, para qualquer tipo de sandbox, você deseja evitar o encaminhamento de X.) #
306 /

11
Se você prefere não montar todo o diretório home para o contentor que pode simplesmente montar o .Xauthorityarquivo em si: -v $HOME/.Xauthority:/root/.Xauthority -e XAUTHORITY=/root/.Xauthority.
Robert Haines

2
Em vez de alterar X11UseLocalhost, você também pode usar a opção adicional --net=hostpara o docker runcomando (encontrada aqui ).
ingomueller.net

--net=hosté uma má idéia, como agora, se você abrir uma porta no contêiner, ela também será aberta no host ...
MrR

16

Embora a resposta de Jürgen Weigert cubra essencialmente essa solução, a princípio não estava claro para mim o que estava sendo descrito lá. Então, adicionarei minha opinião, caso alguém precise de esclarecimentos.

Primeiro, a documentação relevante é a página de manual de segurança X .

Inúmeras fontes online sugerem apenas montar o soquete X11 unix e o ~/.Xauthority arquivo no contêiner. Essas soluções geralmente funcionam por sorte, sem realmente entender o porquê, por exemplo, o usuário do contêiner acaba com o mesmo UID do usuário, portanto, não há necessidade de autorização de chave mágica.

Primeiro, o arquivo Xauthority possui o modo 0600, para que o usuário do contêiner não possa lê-lo, a menos que tenha o mesmo UID.

Mesmo se você copiar o arquivo no contêiner e alterar a propriedade, ainda haverá outro problema. Se você executar xauth listno host e no contêiner, com o mesmo Xauthorityarquivo, verá diferentes entradas listadas. Isso ocorre porque xauthfiltra as entradas dependendo de onde elas são executadas.

O cliente X no contêiner (por exemplo, aplicativo GUI) se comportará da mesma forma que xauth. Em outras palavras, ele não vê o cookie mágico da sessão X em execução na área de trabalho do usuário. Em vez disso, ele vê as entradas para todas as sessões X "remotas" que você abriu anteriormente (explicadas abaixo).

Portanto, o que você precisa fazer é adicionar uma nova entrada com o nome do host do contêiner e a mesma chave hexadecimal do cookie do host (por exemplo, a sessão X em execução na área de trabalho), por exemplo:

containerhostname/unix:0   MIT-MAGIC-COOKIE-1   <shared hex key>

O problema é que o cookie deve ser adicionado xauth adddentro do contêiner:

touch ~/.Xauthority
xauth add containerhostname/unix:0 . <shared hex key>

Caso contrário, xauthmarque-o de uma maneira que só seja vista fora do contêiner.

O formato para este comando é:

xauth add hostname/$DISPLAY protocol hexkey

Onde .representa o MIT-MAGIC-COOKIE-1protocolo.

Nota: Não há necessidade de copiar ou montar de montagem .Xauthorityno contêiner. Basta criar um arquivo em branco, como mostrado, e adicionar o cookie.

A resposta de Jürgen Weigert contorna isso usando o FamilyWildtipo de conexão para criar um novo arquivo de autoridade no host e copiá-lo no contêiner. Observe que primeiro extrai a chave hexadecimal da sessão X atual do ~/.Xauthorityusoxauth nlist .

Portanto, as etapas essenciais são:

  • Extraia a chave hexadecimal do cookie para a sessão X atual do usuário.
  • Crie um novo arquivo Xauthority no contêiner, com o nome do host do contêiner e a chave hexadecimal compartilhada (ou crie um cookie com o FamilyWildtipo de conexão).

Admito que não entendo muito bem como FamilyWildfunciona, ou como xauthou os clientes X filtram as entradas do arquivo Xauthority, dependendo de onde são executadas. Informações adicionais sobre isso são bem-vindas.

Se você deseja distribuir seu aplicativo Docker, precisará de um script de início para executar o contêiner que obtém a chave hexadecimal para a sessão X do usuário e a importa para o contêiner de uma das duas maneiras explicadas anteriormente.

Também ajuda a entender a mecânica do processo de autorização:

  • Um cliente X (ou seja, aplicativo GUI) em execução no contêiner procura no arquivo Xauthority uma entrada de cookie que corresponda ao nome do host do contêiner e ao valor de $DISPLAY.
  • Se uma entrada correspondente for encontrada, o cliente X a transmitirá com sua solicitação de autorização ao servidor X, através do soquete apropriado no /tmp/.X11-unixdiretório montado no contêiner.

Nota: O soquete X11 Unix ainda precisa ser montado no contêiner, ou o contêiner não terá rota para o servidor X. A maioria das distribuições desabilita o acesso TCP ao servidor X por padrão por razões de segurança.

Para obter informações adicionais e para entender melhor como o relacionamento cliente / servidor X funciona, também é útil examinar o caso de exemplo do encaminhamento do SSH X:

  • O servidor SSH em execução em uma máquina remota emula seu próprio servidor X.
  • Ele define o valor de $DISPLAYna sessão SSH para apontar para seu próprio servidor X.
  • Ele é usado xauthpara criar um novo cookie para o host remoto e o adiciona aos Xauthorityarquivos para usuários locais e remotos.
  • Quando os aplicativos GUI são iniciados, eles conversam com o servidor X emulado do SSH.
  • O servidor SSH encaminha esses dados de volta ao cliente SSH na área de trabalho local.
  • O cliente SSH local envia os dados para a sessão do servidor X em execução na área de trabalho, como se o cliente SSH fosse realmente um cliente X (ou seja, aplicativo GUI).
  • O servidor X usa os dados recebidos para renderizar a GUI na área de trabalho.
  • No início dessa troca, o cliente X remoto também envia uma solicitação de autorização, usando o cookie que acabou de ser criado. O servidor X local o compara com sua cópia local.

12

Isso não é leve, mas é uma boa solução que fornece paridade de recursos do docker com virtualização completa da área de trabalho. O Xfce4 ou o IceWM para Ubuntu e o CentOS funcionam, e a noVNCopção facilita o acesso por meio de um navegador.

https://github.com/ConSol/docker-headless-vnc-container

Ele roda noVNCtão bem quanto tigerVNCo vncserver. Em seguida, solicita o startxGerenciador de Janelas fornecido. Além disso, libnss_wrapper.soé usado para emular o gerenciamento de senhas para os usuários.


alguém já testou isso?
guilhermecgs

3
@guilhermecgs sim, e funciona bem. Desde então, eu também tentei xprano docker, que é o X sem raiz. xpraEra o IMO mais adequado e é mais eficiente que o VNC.
218178 $ $ $ $ $ $ $ $ $ $ $ $

Só para esclarecer ... Posso ter uma experiência completa da área de trabalho (GNOME, KDE) com esta imagem?
guilhermecgs

Eu tentei apenas o Xfce4 e IceWM (que está nesse repositório). Obviamente, a experiência será limitada, por exemplo, os dispositivos de montagem não aparecerão na área de trabalho (gvfs), a menos que você passe --device /dev/...para a janela de encaixe e defina os --capprivilégios necessários . Isso anula o objetivo da contenção, mas você pode passar pelos dispositivos. Com alguns ajustes, seria possível, creio, rodar o GNOME / KDE no VNC. Executei vários X no docker com placas nvidia (sem VNC ou Xpra), o que é certamente possível.
218808 $ $ $ $ $ $ $ $ $ $ $

Nós não tentamos isso até agora. O maior desafio disso seria abrir um daemon D-Bus em funcionamento. A maioria dos desktops gnome ou KDE precisará deles. Que o projeto ubuntu-desktop-lxde-vnc o ajude lá.
#

11

A solução fornecida em http://fabiorehm.com/blog/2014/09/11/running-gui-apps-with-docker/ parece ser uma maneira fácil de iniciar aplicativos GUI de dentro dos contêineres (tentei o firefox no ubuntu 14.04), mas descobri que é necessária uma pequena alteração adicional na solução postada pelo autor.

Especificamente, para executar o contêiner, o autor mencionou:

    docker run -ti --rm \
    -e DISPLAY=$DISPLAY \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    firefox

Mas descobri que (com base em um comentário específico no mesmo site) que duas opções adicionais

    -v $HOME/.Xauthority:$HOME/.Xauthority

e

    -net=host 

precisa ser especificado durante a execução do contêiner para o firefox funcionar corretamente:

    docker run -ti --rm \
    -e DISPLAY=$DISPLAY \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -v $HOME/.Xauthority:$HOME/.Xauthority \
    -net=host \
    firefox

Eu criei uma imagem do docker com as informações nessa página e essas descobertas adicionais: https://hub.docker.com/r/amanral/ubuntu-firefox/


3
Eu descobri que você nem precisa passar pelo /tmp/.X11-unixsoquete. Funciona apenas com montagem .Xauthoritye --net=host.
CMCDragonkai

2
Esta é realmente a única solução que funciona atualmente. O uso /tmp/.X11-unixcomo volume não funciona mais, pois o docker recusa silenciosamente montagens de volume de diretórios fixos.
Christian Hujer

11
Eu acho que depende da distro que você está usando. Você definitivamente pode montar o soquete X11 Unix no CentOS. Também é importante entender o que --network=hostfaz. Isso dá ao seu contêiner acesso total à pilha de rede do host, o que pode ser indesejável, dependendo do que você está tentando fazer. Se você está apenas mexendo na execução de GUIs em contêineres na área de trabalho, isso não deve importar.
orodbhen

7

Existe outra solução do lord.garbage para executar aplicativos da GUI em um contêiner sem usar o encaminhamento VNC, SSH e X11. Também é mencionado aqui .


11
Isso é ótimo se a segurança não for uma preocupação. Se o objetivo de atrelar algo for isolá-lo, é melhor evitar a entrada e saída de X11 do contêiner.
Vai

7

Se você deseja executar um aplicativo GUI sem cabeça, leia aqui . O que você precisa fazer é criar um monitor virtual com xvfbou outro software similar. Isso é muito útil se você deseja executar testes do Selenium, por exemplo, com navegadores.

Algo que não foi mencionado em nenhum lugar é que alguns softwares usam sandbox com contêineres Linux. Por exemplo, o Chrome nunca funcionará normalmente se você não usar o sinalizador apropriado --privilegedao executar o contêiner.


6

Estou atrasado para a festa, mas para usuários de Mac que não querem seguir o caminho do XQuartz, aqui está um exemplo prático que cria uma imagem do Fedora, com um ambiente de área de trabalho (xfce) usando Xvfbe VNC. É simples e funciona:

Em um Mac, você pode simplesmente acessá-lo usando o aplicativo Screen Sharing (padrão), conectado a localhost:5901.

Dockerfile:

FROM fedora

USER root

# Set root password, so I know it for the future
RUN echo "root:password123" | chpasswd

# Install Java, Open SSL, etc.
RUN dnf update -y --setopt=deltarpm=false  \
 && dnf install -y --setopt=deltarpm=false \
                openssl.x86_64             \
                java-1.8.0-openjdk.x86_64  \
                xorg-x11-server-Xvfb       \
                x11vnc                     \
                firefox                    \
                @xfce-desktop-environment  \
 && dnf clean all

# Create developer user (password: password123, uid: 11111)
RUN useradd -u 11111 -g users -d /home/developer -s /bin/bash -p $(echo password123 | openssl passwd -1 -stdin) developer

# Copy startup script over to the developer home
COPY start-vnc.sh /home/developer/start-vnc.sh
RUN chmod 700 /home/developer/start-vnc.sh
RUN chown developer.users /home/developer/start-vnc.sh

# Expose VNC, SSH
EXPOSE 5901 22

# Set up VNC Password and DisplayEnvVar to point to Display1Screen0
USER developer
ENV  DISPLAY :1.0
RUN  mkdir ~/.x11vnc
RUN  x11vnc -storepasswd letmein ~/.x11vnc/passwd

WORKDIR /home/developer
CMD ["/home/developer/start-vnc.sh"]

start-vnc.sh

#!/bin/sh

Xvfb :1 -screen 0 1024x768x24 &
sleep 5
x11vnc -noxdamage -many -display :1 -rfbport 5901 -rfbauth ~/.x11vnc/passwd -bg
sleep 2
xfce4-session &

bash
# while true; do sleep 1000; done

Verifique o leia-me vinculado para obter comandos de construção e execução, se desejar / precisar.


5

Com base na resposta de Jürgen Weigert , tenho algumas melhorias:

docker build -t xeyes - << __EOF__
FROM debian
RUN apt-get update
RUN apt-get install -qqy x11-apps
ENV DISPLAY :0
CMD xeyes
__EOF__
XSOCK=/tmp/.X11-unix
XAUTH_DIR=/tmp/.docker.xauth
XAUTH=$XAUTH_DIR/.xauth
mkdir -p $XAUTH_DIR && touch $XAUTH
xauth nlist $DISPLAY | sed -e 's/^..../ffff/' | xauth -f $XAUTH nmerge -
docker run -ti -v $XSOCK:$XSOCK -v $XAUTH_DIR:$XAUTH_DIR -e XAUTHORITY=$XAUTH xeyes

A única diferença é que ele cria um diretório $ XAUTH_DIR que é usado para colocar o arquivo $ XAUTH e montar o diretório $ XAUTH_DIR em vez do arquivo $ XAUTH no contêiner do docker.

O benefício desse método é que você pode escrever um comando em /etc/rc.local que é criar uma pasta vazia chamada $ XAUTH_DIR em / tmp e alterar seu modo para 777.

tr '\n' '\000' < /etc/rc.local | sudo tee /etc/rc.local >/dev/null
sudo sed -i 's|\x00XAUTH_DIR=.*\x00\x00|\x00|' /etc/rc.local >/dev/null
tr '\000' '\n' < /etc/rc.local | sudo tee /etc/rc.local >/dev/null
sudo sed -i 's|^exit 0.*$|XAUTH_DIR=/tmp/.docker.xauth; rm -rf $XAUTH_DIR; install -m 777 -d $XAUTH_DIR\n\nexit 0|' /etc/rc.local

Quando o sistema reiniciar, antes do login do usuário, o docker montará o diretório $ XAUTH_DIR automaticamente se a política de reinicialização do contêiner for "sempre". Após o login do usuário, você pode escrever um comando em ~ / .profile, que deve criar o arquivo $ XAUTH, e o contêiner utilizará automaticamente esse arquivo $ XAUTH.

tr '\n' '\000' < ~/.profile | sudo tee ~/.profile >/dev/null
sed -i 's|\x00XAUTH_DIR=.*-\x00|\x00|' ~/.profile
tr '\000' '\n' < ~/.profile | sudo tee ~/.profile >/dev/null
echo "XAUTH_DIR=/tmp/.docker.xauth; XAUTH=\$XAUTH_DIR/.xauth; touch \$XAUTH; xauth nlist \$DISPLAY | sed -e 's/^..../ffff/' | xauth -f \$XAUTH nmerge -" >> ~/.profile

Afinal, o contêiner obterá automaticamente o arquivo Xauthority sempre que o sistema reiniciar e o login do usuário.


4

As outras soluções devem funcionar, mas aqui está uma solução para docker-compose.

Para corrigir esse erro, você precisa passar $ DISPLAY e .X11-unix para o docker, além de conceder ao usuário que iniciou o docker o acesso ao xhost.

Dentro do docker-compose.ymlarquivo:

version: '2'
services:
    node:
        build: .
        container_name: node
        environment:
            - DISPLAY
        volumes:
            - /tmp/.X11-unix:/tmp/.X11-unix

No terminal ou script:

  • xhost +si:localuser:$USER
  • xhost +local:docker
  • export DISPLAY=$DISPLAY
  • docker-compose up


3

Você pode permitir que o usuário do Docker (aqui: root) acesse a exibição do X11:

XSOCK=/tmp/.X11-unix
xhost +SI:localuser:root 
docker run -t -i --rm -v $XSOCK:$XSOCK:ro -e DISPLAY=unix$(DISPLAY) image 
xhost -SI:localuser:root

2

OSX (10.13.6, serra alta)

Semelhante à resposta de @Nick , mas sua solução não funcionou para mim.

Primeiro instale o socat fazendo brew install socate instale o XQuartz ( https://www.xquartz.org/ )

Em seguida, siga estas etapas aqui ( http://fabiorehm.com/blog/2014/09/11/running-gui-apps-with-docker/ ) na seção de comentários:

1. in one mac terminal i started:

socat TCP-LISTEN:6000,reuseaddr,fork UNIX-CLIENT:\"$DISPLAY\"

2. and in another mac terminal I ran:

docker run -ti --rm \
-e DISPLAY=$(ipconfig getifaddr en0):0 \
-v /tmp/.X11-unix:/tmp/.X11-unix \
firefox

Também pude iniciar o CLion a partir do meu contêiner docker debian.


1

Docker com rede BRIDGE. para Ubuntu 16.04 com gerenciador de exibição lightdm:

cd /etc/lightdm/lightdm.conf.d
sudo nano user.conf

[Seat:*]
xserver-allow-tcp=true
xserver-command=X -listen tcp

você pode usar mais permissões privadas

xhost +

docker run --volume="$HOME/.Xauthority:/root/.Xauthority:rw" --env="DISPLAY=$HOST_IP_IN_BRIDGE_NETWORK:0" --net=bridge $container_name

1

Mais uma resposta, caso você já tenha construído a imagem:

  1. chamar docker sem o sudo ( Como corrigir o docker: problema com permissão negada )

  2. compartilhe o mesmo USER & home & passwd entre o host e o compartilhamento de contêiner (dicas: use o ID do usuário em vez do nome do usuário)

  3. a pasta dev para bibliotecas dependentes de driver para funcionar bem

  4. mais X11 para a frente.

    docker run --name=CONTAINER_NAME --network=host --privileged \
      -v /dev:/dev \
      -v `echo ~`:/home/${USER} \
      -p 8080:80 \
      --user=`id -u ${USER}` \
      --env="DISPLAY" \
      --volume="/etc/group:/etc/group:ro" \
      --volume="/etc/passwd:/etc/passwd:ro" \
      --volume="/etc/shadow:/etc/shadow:ro" \
      --volume="/etc/sudoers.d:/etc/sudoers.d:ro" \
      --volume="/tmp/.X11-unix:/tmp/.X11-unix:rw" \
      -it REPO:TAG /bin/bash

você pode perguntar: qual é o sentido de usar o docker se tantas coisas são iguais? bem, uma razão pela qual consigo pensar é superar o inferno da dependência de pacotes ( https://en.wikipedia.org/wiki/Dependency_hell ).

Portanto, esse tipo de uso é mais adequado para o desenvolvedor, eu acho.


Este é o único que funcionaria para mim. Para meus propósitos, consegui minimizá-lo: docker run --network = host --volume = echo ~: / home / $ {USER} --user = id -u ${USER}--env = "DISPLAY" --volume = "/ etc / passwd: / etc / passwd: ro "-it REPO: TAG / bin / bash
user1145922

1

Eu consegui executar um fluxo de vídeo de uma câmera USB usando opencvem docker, seguindo estes passos:

  1. Deixe a janela de encaixe acessar o servidor X

    xhost +local:docker
    
  2. Crie o soquete X11 Unix e o arquivo de autenticação X

    XSOCK=/tmp/.X11-unix
    XAUTH=/tmp/.docker.xauth
    
  3. Adicione permissões apropriadas

    xauth nlist $DISPLAY | sed -e 's/^..../ffff/' | xauth -f $XAUTH nmerge -
    
  4. Defina a velocidade de renderização Qt como "nativa", para que não ignore o mecanismo de renderização X11

    export QT_GRAPHICSSYSTEM=native
    
  5. Diga ao Qt para não usar o MIT-SHM (memória compartilhada) - para que também seja mais seguro em termos de segurança

    export QT_X11_NO_MITSHM=1
    
  6. Atualize o comando docker run

    docker run -it \
               -e DISPLAY=$DISPLAY \
               -e XAUTHORITY=$XAUTH \
               -v $XSOCK:$XSOCK \
               -v $XAUTH:$XAUTH \
               --runtime=nvidia \
               --device=/dev/video0:/dev/video0 \
               nvcr.io/nvidia/pytorch:19.10-py3
    

Nota: Ao concluir o projeto, retorne os controles de acesso com o valor padrão - xhost -local:docker

Mais detalhes: Usando GUI's com Docker

Crédito: Detecção de objetos de processamento de vídeo e em tempo real usando Tensorflow, OpenCV e Docker


"Criar o soquete X11 Unix e o arquivo de autenticação X" não cria nenhum arquivo, apenas define variáveis?
MrR
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.