Como executar o Chromium a partir de um contêiner docker

Question

Ambiente

• MacOS Sierra 10.12.6
• Versão do Docker 17.09.0-ce, construção afdb6d4
• Ubuntu 16.04
• XQuartz 2.7.9

Desejo abrir o navegador do Chromium a partir de um contêiner docker na minha área de trabalho do Mac.

docker run -i -t ubuntu:16.04 /bin/bash
apt-get update
apt-get install alsa-base chromium-browser xauth
adduser myuser

Commit

docker commit 2862a7bfcc2f  acme/mycontainer:0.1

Execução do navegador do cromo como myuser do contêiner FAIL

docker run --user myuser -i -t acme/mycontainer:0.1 /usr/bin/chromium-browser
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted

Aposto que há um pouco mais nisso

Algum apontador?

UDPATE - usando --privileged

Remove o erro Ver thread no serverfault , mas o A interface do usuário não aparece

docker run \
       --privileged \
       --user mysuer \
       -i -t acme/mycontainer:0.1 /usr/bin/chromium-browser

e este aqui

docker run \
   --privileged \
   --net host \
   -v /tmp/.X11-unix:/tmp/.X11-unix \
   -e DISPLAY=$DISPLAY \
   -e XAUTHORITY=/.Xauthority \
   -v ~/.Xauthority:/.Xauthority:ro \
   --name chromium \
   --user mysuser \
   -i -t acme/mycontainer:0.1 /usr/bin/chromium-browser

O Chromium não aparece

UPDATE 20171011

docker run \
   --privileged \
   --net host \
   -v /tmp/.X11-unix \
   -e DISPLAY \
   --name chromium \
   --user myuser \
   -i -t acme/mycontainer:0.1 \
   bash

Iniciando o Chromium Gtk: cannot open display: [...] org.macosforge.xquartz:0 error

$ chromium-browser --verbose
[37:37:1011/154632.348303:VERBOSE1:breakpad_linux.cc(1978)] Breakpad disabled
[1:1:1011/154632.378280:VERBOSE1:zygote_main_linux.cc(537)] ZygoteMain: initializing 0 fork delegates
[1:1:1011/154632.378653:INFO:cpu_info.cc(50)] Available number of cores: 4
[37:37:1011/154632.381303:WARNING:browser_main_loop.cc(275)] Gtk: cannot open display: \
      /private/tmp/com.apple.launchd.Y2wR3QWw57/org.macosforge.xquartz:0

No meu Mac editado sshd_config

sudo vim /etc/ssh/sshd_config
X11Forwarding yes
X11DisplayOffset 10
XAuthLocation /opt/X11/bin/xauth

No meu Mac DISPLAY

$ env | grep DISPLAY
DISPLAY=/private/tmp/com.apple.launchd.Y2wR3QWw57/org.macosforge.xquartz:0

No disco

ls -al /private/tmp/com.apple.launchd.gCYQToI4lb/*
srw-rw-rw-  1 joel  wheel     0B Oct 11 17:50 
/private/tmp/com.apple.launchd.gCYQToI4lb/org.macosforge.xquartz:0=

    

Answer 1

Não tenho um Mac para experimentar, mas eis algumas sugestões gerais:

O X11 é geralmente protegido por um arquivo de chave que só pode ser lido pelo usuário que possui o monitor, usando as permissões do sistema de arquivos para afirmar que apenas outros programas que podem ler esse arquivo podem se conectar. Os clientes lêem esse arquivo e depois repetem seu conteúdo para o servidor através do soquete. Então, acho que você estava no caminho certo com

-e XAUTHORITY=/.Xauthority \
-v ~/.Xauthority:/.Xauthority:ro \

Em seguida, você mostra as configurações de encaminhamento do SSH X11, mas não indica que o ssh esteja no contêiner do Docker. O encaminhamento de SSH é normalmente usado por:

ssh $HOST -X program-which-launches-gui

Para fazer isso, você precisa executar um servidor SSH dentro do contêiner docker, o que é um pouco de esforço ...

Em seguida, você mostra um DISPLAY=/path/to/socket que eu não usei antes. Se esta é uma invenção MacOS, então o Ubuntu dockerized pode não entender esse formato.

Por fim, você pode ver o que o chrome está realmente tentando fazer usando o comando 'strace' de dentro do contêiner docker.

strace chromium-browser 2>&1 | egrep "open|stat|connect|bind"

Isso pode ajudar você a descobrir quais operações específicas falham logo antes de desistir.

    

Answer 2

Sua necessidade me faz lembrar subutilizador . Ele foi projetado para executar a aplicação do usuário final em um contêiner docker, a fim de proteger a privacidade e aumentar a segurança.