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.523 ]

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

Como prevenir o Buffer Overflow

Funtoo Linux - Arquivo /etc/boot.conf

Trabalhando com permutações em ordem lexicográfica crescente

Rodando o macOS com Docker, qemu, e KVM

Balanceamento de link + redundância

Leitura recomendada

Docker - Combatento o COVID-19

Configurando Docker Swarm no Rocky Linux

Docker Swarm no CentOS 8

Subindo o Zabbix e Grafana no Podman com Pod

Kubespray - Kubernetes Multi Master

  
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