Usando Docker para encapsular qualquer aplicação no GNU/Linux

Quer rodar uma aplicação GUI/CLI mas não quer instalar no seu sistema? Docker é a solução!

[ Hits: 7.525 ]

Por: Perfil removido em 04/08/2020


Exemplo de uso: GIMP



Antes de partir para a prática, é necessário entender o que é uma "imagem" e o que é um "contêiner" para não haver confusão:
  • imagem: no Docker, imagens são semelhantes aos arquivos ISOs, porém modificadas propositalmente para diversos fins. Podemos criar uma imagem com Ubuntu 20.04 LTS preparada para rodar determinados aplicativos e/ou serviços.
  • contêiner: são sandbox criadas através da imagem. Eu posso criar diversos contêineres de uma mesma imagem. Por exemplo, tenho uma imagem com Ubuntu 20.04 LTS com um aplicativo X instalado. Então eu posso criar diversos contêineres para rodar essa aplicação em minha máquina. Para um uso comum - que é a proposta desse artigo - não será necessário criar diversos contêineres.

Agora vejamos um exemplo de uso:

Problema:

"Uso o Debian versão X e quero usar a versão mais recente do GIMP, mas a versão dos repositórios é a X.Y.Z."
Solução:

Criar um contêiner com Arch Linux para instalar o GIMP e rodar no meu Debian.
Como fazer:

xhost +
docker run --name gimp -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix -v $HOME/Imagens:/exports -it archlinux /bin/bash

Explicando cada comando e parâmetro:
  • run: esse comando cria um novo contêiner a cada execução. Ou seja, eu posso criar vários contêineres com Arch Linux em meu sistema para rodar aplicações específicas;
  • --name: atribui um nome para o novo contêiner criado. Se não passar essa opção, seu contêiner vai receber um nome aleatório de difícil memorização;
  • -e DISPLAY=$DISPLAY: aqui passamos uma variável para o novo contêiner, e nesse caso estamos especificando a variável DISPLAY, pois precisamos executar uma aplicação gráfica;
  • -v /tmp/.X11-unix:/tmp/.X11-unix: aqui montamos o diretório /tmp/.X11-unix para dentro do contêiner para podermos rodar aplicações gráficas;
  • -v $HOME/Imagens:/exports: precisamos montar algum diretório da nossa máquina no contêiner para trocarmos arquivos entre o sistema e o contêiner. Selecionei a pasta ~/Imagens para termos acesso aos arquivos de imagens (JPEG/PNG) para o gimp;
  • -it: o -i ativa o modo interativo e o -t aloca um pseudo terminal tty. Precisamos disso pois iremos executar o bash de dentro do contêiner para instalar o gimp e rodá-lo;
  • archlinux: aqui especificamos a imagem do sistema que queremos trabalhar. Podemos especificar aqui outras imagens, como o Ubuntu, CentOS, Fedora, Gentoo, Slackware, Kali Linux etc.
  • /bin/bash: o comando a ser executado no contêiner.

Após a execução do comando acima, um novo shell vai ser criado para trabalharmos com o contêiner com Arch Linux. Aqui podemos usar os utilitários do Arch Linux, como o pacman.

Para rodar o gimp através do Arch Linux podemos instalá-lo direto da seguinte forma:

pacman -Syu
pacman -S gimp sdl2 --noconfirm
gimp

Após o último comando, uma janela do gimp abrirá:
E está feito! Podemos instalar qualquer aplicação gráfica nesse contêiner, mas o ideal é manter um contêiner para cada aplicação! Lembre-se que você pode criar quantos contêineres quiser através do comando "run"!

E para sair do contêiner? Basta rodar o comando "exit".

Mas se eu quiser rodá-lo novamente? Vou precisar fazer tudo isso de novo? Não!

Ao criar o contêiner você especificou o nome "gimp" para o parâmetro --name. Nesse caso, ao dar exit o contêiner foi apenas paralisado, mas você pode voltá-lo a executar novamente.

Nesse caso, você pode usar o comando abaixo para subir o contêiner e executar o gimp diretamente:

docker exec gimp gimp

O comando "exec" executa alguma coisa no contêiner criado pelo comando "run". Nesse caso, estamos executando o comando "gimp" no contêiner que criamos com o nome de gimp.

Mas se quiser entrar novamente no contêiner para instalar mais coisas, basta usar o comando abaixo:

docker exec -it gimp /bin/bash

Você pode também conferir os contêineres em execução com o comando "ps":

docker ps

O comando "ps" lista os contêineres em execução. Se você quiser conferir os contêineres criados mas que não estão em execução, pode passar o parâmetro "-a":

docker ps -a

E por fim, para subir ou parar um contêiner, pode usar os comandos "start" e "stop":

docker start gimp
docker stop gimp

Obs.: para o comando "exec" funcionar, é necessário subir o contêiner antes com o comando "start".

Página anterior     Próxima página

Páginas do artigo
   1. Introdução
   2. Exemplo de uso: GIMP
   3. Exemplo de uso: IRPF
Outros artigos deste autor

Compilando e otimizando KDE 3.x

Transparência de janelas no KDE

Os segredos dos modems

Formatando fontes no openoffice

Shell Script para WEB

Leitura recomendada

Configurando Docker Swarm no Rocky Linux

Docker Swarm no CentOS 8

Introdução e Utilização do Docker

Instalando Openshift Origin 3.11 com Ansible

Pods com Podman

  
Comentários
[1] Comentário enviado por fabio em 04/08/2020 - 14:51h

Artigo muito bem explicado! Docker para IRPF é novidade pra mim, galera não perde tempo rsrs

[2] Comentário enviado por removido em 04/08/2020 - 15:12h


[1] Comentário enviado por fabio em 04/08/2020 - 14:51h

Artigo muito bem explicado! Docker para IRPF é novidade pra mim, galera não perde tempo rsrs


Tem que manter o leão enjaulado! haha

[3] Comentário enviado por maurixnovatrento em 04/08/2020 - 19:18h


E eu querendo rodar o kazam no Slackware. Quero ver se agora eu não consigo. Vai ver só se eu não vou postar um screen do kazam no Slackware. É só sair a versão 15, que ta demorando pra variar.

___________________________________
Conhecimento não se Leva para o Túmulo.

[4] Comentário enviado por CapitainKurn em 05/08/2020 - 04:23h

Docker é muito versátil.
Recentemente fiz um trabalho para rodar uma aplicação legada em um novo hardware e o Docker foi o que salvou a pátria pois como tratava-ssse de uma solução Gentoo de 2006 foi muito problemático porta-la para distros novas, problemas com retrocompatibilidade de libs, problemas com módulos e hardware novo e por aí vai.
Vou escrever em breve um artigo sobre o assunto.
Dê uma olhada!
https://www.youtube.com/watch?v=yMdoYftPjXQ
https://www.youtube.com/watch?v=sL8iJEUNR60


[5] Comentário enviado por mcnd2 em 05/08/2020 - 04:28h


Muito bom artigo, simples e fácil de entender. Parabéns!!!
__________________
Linux User #606334 -- Open your mind!

[6] Comentário enviado por removido em 05/08/2020 - 08:12h


[4] Comentário enviado por CapitainKurn em 05/08/2020 - 04:23h

Docker é muito versátil.
Recentemente fiz um trabalho para rodar uma aplicação legada em um novo hardware e o Docker foi o que salvou a pátria pois como tratava-ssse de uma solução Gentoo de 2006 foi muito problemático porta-la para distros novas, problemas com retrocompatibilidade de libs, problemas com módulos e hardware novo e por aí vai.
Vou escrever em breve um artigo sobre o assunto.
Dê uma olhada!
https://www.youtube.com/watch?v=yMdoYftPjXQ
https://www.youtube.com/watch?v=sL8iJEUNR60




Linux precisa de retrocompatibilidade, é por isso que eu acredito em soluções como os pacotes Snaps.

[7] Comentário enviado por removido em 05/08/2020 - 08:37h


[4] Comentário enviado por CapitainKurn em 05/08/2020 - 04:23h

Docker é muito versátil.
Recentemente fiz um trabalho para rodar uma aplicação legada em um novo hardware e o Docker foi o que salvou a pátria pois como tratava-ssse de uma solução Gentoo de 2006 foi muito problemático porta-la para distros novas, problemas com retrocompatibilidade de libs, problemas com módulos e hardware novo e por aí vai.
Vou escrever em breve um artigo sobre o assunto.
Dê uma olhada!
https://www.youtube.com/watch?v=yMdoYftPjXQ
https://www.youtube.com/watch?v=sL8iJEUNR60




Exatamente! Eu chuto que o Docker foi a melhor invenção dos últimos tempos em se tratando de Linux. Apesar da ideia de contêineres já existir desde 2000 com o Jail do FreeBSD (pretendo escrever um artigo sobre isso futuramente), o Docker alavancou essa ideia para outro patamar por oferecer mais possibilidades e por ser mais optimizado.

Vou dar uma olhada nos vídeos!

[8] Comentário enviado por removido em 05/08/2020 - 08:40h


[5] Comentário enviado por mcnd2 em 05/08/2020 - 04:28h


Muito bom artigo, simples e fácil de entender. Parabéns!!!
__________________
Linux User #606334 -- Open your mind!


Valeu!

[9] Comentário enviado por zezaocapoeira em 05/08/2020 - 13:20h

Salve galera.

Parabéns pelo trabalho.

Algum tempo atrás fiz alguns testes:

docker rodando steam.

- https://www.youtube.com/watch?v=YFOEj-5b890

docker rodando wine

- https://www.youtube.com/watch?v=HvX5tvhIgs4

- O desempenho é basicamente o mesmo do que rodando sem o docker.

- Ainda está nos meus planos migrar steam e wine para docker ou lxc.


OBS:

Para quem tiver curiosidade:

Aqui tem diversas opções.

- https://github.com/jessfraz/dockerfiles

Obrigado pela atenção, salve!!!

[10] Comentário enviado por removido em 05/08/2020 - 15:13h


[9] Comentário enviado por zezaocapoeira em 05/08/2020 - 13:20h

Salve galera.

Parabéns pelo trabalho.

Algum tempo atrás fiz alguns testes:

docker rodando steam.

- https://www.youtube.com/watch?v=YFOEj-5b890

docker rodando wine

- https://www.youtube.com/watch?v=HvX5tvhIgs4

- O desempenho é basicamente o mesmo do que rodando sem o docker.

- Ainda está nos meus planos migrar steam e wine para docker ou lxc.


OBS:

Para quem tiver curiosidade:

Aqui tem diversas opções.

- https://github.com/jessfraz/dockerfiles

Obrigado pela atenção, salve!!!


Fala zé!

Interessante... nunca pensei em rodar jogos pelo docker...
Nesse caso é possível manter um sistema 100% 64-bits (sem multi-arch/multilib)?

[11] Comentário enviado por zezaocapoeira em 06/08/2020 - 03:56h


[10] Comentário enviado por ruankl em 05/08/2020 - 15:13h
Fala zé!

Interessante... nunca pensei em rodar jogos pelo docker...
Nesse caso é possível manter um sistema 100% 64-bits (sem multi-arch/multilib)?



Salve @ruankl.

Acredito que seja possível.

Na epoca que testei tava com o sistema Slackware64-14.2_multilib, por isso não posso afirmar 100%.

Nos meus testes:

- uso o steam-guard para login , no caso do container não dava para deixar o login automático pois não funcionava.

Caso fosse subir o mesmo container não funcionava.

Sem usar o login automático funciona normalmente , só que vai ter que validar o login toda vez usando o steam guard.

- Dá uma olhada no meu comentário número 3.

https://www.vivaolinux.com.br/screenshot/Tiling-window-manager-Docker-container-Steam/

No caso audio no Slackware64 current acho que tá mais suave resolver, bastando habilitar o pulseaudio para multi-user.

https://wiki.archlinux.org/index.php/PulseAudio/Examples#Allowing_multiple_users_to_use_PulseAudio_a...

Estou testando esse modo multi-user aqui na minha instalação.

Basicamente setei as configurações referentes do link da wiki acima, e coloquei para iniciar o pulseaudio somente pelo daemon "pulseaudio -D". No meu caso coloquei esse comando no meu ~/.xinitrc.


OBS:
- Minha dúvida nessa migração é na questão dos driver de vídeo, nvidia no meu caso, com suporte a 32 bits.

Atualmente instalo o driver completo com suporte a 32 bits.

No caso do docker fico na dúvida:

Mantendo o sistema full 64 bits e apenas o container docker com multilib e com driver de vídeo com suporte 32 bits.
Pois os devices serão compartilhados:

(exemplo)
--device /dev/nvidia-modeset:/dev/nvidia-modeset \
--device /dev/nvidia-uvm:/dev/nvidia-uvm \
--device /dev/nvidia0:/dev/nvidia0 \
--device /dev/nvidiactl:/dev/nvidiactl \
--device /dev/dri/card0:/dev/dri/card0 \
--device /dev/dri/renderD128:/dev/dri/renderD128 \

Mas em breve vou testar isso.

Obrigado pela atenção, salve!!!

[12] Comentário enviado por maurixnovatrento em 06/08/2020 - 11:00h


Bem útil esses comentários.

___________________________________
Conhecimento não se Leva para o Túmulo.

[13] Comentário enviado por albfneto em 06/08/2020 - 20:47h

Se usa bastante docker em sabayon e gentoo. Gostei, ótimo Artigo. Favoritei.

¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
Albfneto,
Ribeirão Preto, S.P., Brasil.
Usuário Linux, Linux Counter: #479903.
Distros Favoritas: [i] Sabayon, Gentoo, OpenSUSE, Mageia e OpenMandriva[/i].

[14] Comentário enviado por zezaocapoeira em 07/08/2020 - 04:01h


[11] Comentário enviado por zezaocapoeira em 06/08/2020 - 03:56h


[10] Comentário enviado por ruankl em 05/08/2020 - 15:13h
Fala zé!

Interessante... nunca pensei em rodar jogos pelo docker...
Nesse caso é possível manter um sistema 100% 64-bits (sem multi-arch/multilib)?



Salve @ruankl.

Acredito que seja possível.

Na epoca que testei tava com o sistema Slackware64-14.2_multilib, por isso não posso afirmar 100%.

Nos meus testes:

- uso o steam-guard para login , no caso do container não dava para deixar o login automático pois não funcionava.

Caso fosse subir o mesmo container não funcionava.

Sem usar o login automático funciona normalmente , só que vai ter que validar o login toda vez usando o steam guard.

- Dá uma olhada no meu comentário número 3.

https://www.vivaolinux.com.br/screenshot/Tiling-window-manager-Docker-container-Steam/

No caso audio no Slackware64 current acho que tá mais suave resolver, bastando habilitar o pulseaudio para multi-user.

https://wiki.archlinux.org/index.php/PulseAudio/Examples#Allowing_multiple_users_to_use_PulseAudio_a....

Estou testando esse modo multi-user aqui na minha instalação.

Basicamente setei as configurações referentes do link da wiki acima, e coloquei para iniciar o pulseaudio somente pelo daemon "pulseaudio -D". No meu caso coloquei esse comando no meu ~/.xinitrc.


OBS:
- Minha dúvida nessa migração é na questão dos driver de vídeo, nvidia no meu caso, com suporte a 32 bits.

Atualmente instalo o driver completo com suporte a 32 bits.

No caso do docker fico na dúvida:

Mantendo o sistema full 64 bits e apenas o container docker com multilib e com driver de vídeo com suporte 32 bits.
Pois os devices serão compartilhados:

(exemplo)
--device /dev/nvidia-modeset:/dev/nvidia-modeset \
--device /dev/nvidia-uvm:/dev/nvidia-uvm \
--device /dev/nvidia0:/dev/nvidia0 \
--device /dev/nvidiactl:/dev/nvidiactl \
--device /dev/dri/card0:/dev/dri/card0 \
--device /dev/dri/renderD128:/dev/dri/renderD128 \

Mas em breve vou testar isso.

Obrigado pela atenção, salve!!!


Salve galera.

Complementando

docker steam:

O Funtoo tem algo relacionado a isso:

- https://www.funtoo.org/Steam
- https://github.com/funtoo/steam-launcher


Obrigado pela atenção, salve!!!

[15] Comentário enviado por maurixnovatrento em 07/08/2020 - 13:42h


Legal, esse negócio de docker steam

___________________________________
Conhecimento não se Leva para o Túmulo.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts