Afinal, o que é essa sopa de letrinhas? Docker, dockerd / daemon, Docker Toolbox, Docker for Windows, Docker Desktop, céus, é tanto nome! Windows Containers, Linux Containers, Windows Subsystem for Linux (WSL), WSL2 e o Kernel linux embarcado no windows, lightweight virtual machines, docker machine. Isso tudo pode parecer confuso ao primeiro olhar, mas vou tentar entregar com o máximo de clareza os links e referências para posts que já publiquei ou posts de terceiros.

Esse é mais um post/vídeo da série Docker de A a Z, uma série gratuita que tem a missão de apresentar docker, do aspecto mais simples ao mais complexo, do básico ao intermediário, em soluções das mais básicas às mais avançadas. Essa série começa em 2016 quando descobri que tudo o que eu já falava, poderia ser facilmente demonstrado com poucos cliques.

Durante muito tempo, venho dedicando muito do meu tempo a ajudar profissionais a entender docker e containers. TUDO o que vou escrever nesse post é relevante para o entendimento de docker.

Containers nascem com Docker?

Definitivamente não, Docker chega em 2013. LXC (Linux Containers) nasce em agosto de 2008, 5 anos antes. Docker empacote LXC de uma forma fácil, humanamente usável. Se formos buscar essa história encontraremos muitas iniciativas desde o Jails do FreeBSD.

O que vem a ser um container?

O kernel do Linux é muito diferente do kernel do Windows, no Linux as coisas se comportam de forma muito diferente.

Mas explicar o que é container, é mais ou menos como explicar o modo de compatibilidade ou o Run As do Windows.

No Windows esses recursos criam processos que executam de forma especial, eles tem permissões especiais, acessos diferenciados, e conseguem usar inclusive outra conta de usuário para rodar.

Sendo muito superficial, container é mais ou menos isso, só que muito mais poderoso.

Então um container não é uma VM, é um único processo, seja ele seu banco de dados, ou sua aplicação, rodando com um isolamento tamanho que parece uma VM. Mas não é. Esse único processo está rodando em uma sandbox.

• 

• 

Esse kernel é capaz de isolar um file system para o processo (permitir que o container acredite que um path, obscuro dentro do teu disco é o disco inteiro), ou entregar uma Mac Address e um stack de rede como se ele tivesse uma placa de rede só dele, inclusive com IP, tudo igualzinho uma placa de rede. Isso tudo para um único mothefucker process!!!

Aliás, pela ênfase, espero que tenha deixado claro: Container não tem 2 “coisas”.

Se você tem uma aplicação em um redis, a aplicação fica em um container, o redis fica em outro.

Se essa mesma aplicação tiver banco em container, esse servidor de banco fica em outro container, o que quer que você imagine… fica em outro, em outro, em outro.

E não, isso não fica lento. Lembra que container não é uma máquina virtual? Estou usando uma feature do kernel, que de forma rasa, seria muito parecida com o Run As do Windows. É como se eu estivesse no Windows, clicasse em um executável com uma opção fictícia: Run as Windows 3.11, ou Run as Windows Server 2019.

A intenção aqui é dar clareza, sacrificando a precisão e profundidade.

Distribuições Linux

Para entender como o host trabalha com uma distribuição e o container consegue achar que está usando outra, você precisa compreender o que é uma distribuição. Dessa vez vou sacrificar apenas profundidade em função da clareza.

Distribuições Linux são compostas por:

Kernel – Não faz parte da distribuição, mas toda distribuição precisa embarcar um kernel para funcionar.

Binários (executáveis, programas e sistemas) – Quem é teu gerenciador de pacotes? Quem é teu terminal? Quais os comandos/binários que farão manutenção na tua rede ou gerenciarão seus serviços?

Configurações – Onde ficam as configurações de usuários, rede, processos, logs etc

Paths – Onde as configurações citadas acima estão?

As únicas diferenças entre as distribuições linux são essas. E estas diferenças, por sua vez, fazem com que o Sistema Operacional se comporte completamente diferente.

São esses elementos que diferem Ubuntu de CentOS, Fedora de Debian, são esses elementos que fazem cada distribuição ser única, melhor ou pior sob algum aspecto, sob alguma perspectiva.

O que tem de estar claro, é que, sob um mesmo kernel, se entregamos um file system para um container, com todos os binários de ubuntu, todos os paths de ubuntu, todas as configurações de ubuntu. Não importa se teu host é CentOS, sua aplicação dentro desse contexto do container acha que está sendo executada sob um ubuntu.

É essa simplicidade que permite a mágica dos containers.

OBS: Um ponto que não citei, é que há kernels modificados especialmente para algumas distribuições, isso precisa ser dito, mas não vem ao caso.

Esse tópico eu recorri ao pessoal do https://t.me/LinuxParaTodos para assegurar que não estava cometendo algum sacrilégio. Obrigado Iuri Gagarin e Charles.

Portabilidade de Containers

Outra dúvida recorrente que faz muita gente se perder é achar que um criando uma imagem Linux, fará essa imagem rodar no Kernel do Windows. Eu fiz um p

Eu criei a página Docker no Windows vs Docker no Linux na wiki do github justamente para sanar essas dúvidas. Por favor, leia.

WSL – Windows Subsystem for Linux

Na Wiki (tópico acima) você viu sobre portability de containers, e sendo prático: WSL não muda nada nisso.

No entanto na versão 2 do WSL a mudança na forma de trabalhar baseada que antes contava com a implementação de um proxy/adaptar entre o que seria um kernel do Linux e o Kernel do Windows, agora dá lugar a uma VM especial – As lightweight virtual machines.

Para o Docker Desktop, uma mudança é clara, de VM’s Comuns para VM’s com memória dinamicamente alocada. Na prática, para nós, isso se reflete em potencial para mais estabilidade. Mas só.

Docker Desktop

A propósito, se você não está rodando a última versão do Windows, lamento te informar, mas você foi e continuará sendo deixado para trás. Não sei se você prestou atenção, mas não tenho visto praticamente nenhuma nova feature chegando à versões antigas do windows. WSL 2 não chegará para Windows velhos. A propósito #ficaDica

No site docker.com há disclaimers muito grandes nas páginas dos 2 produtos: Docker Desktop e Docker Toolbox.

• 

• 

Docker Toolbox é LEGADO!!!

Sim, eu só não entendo como eles não tiraram do ar isso ainda. Deve ser pelo mesmo motivo que até hoje se fala em LINK em containers…

Se você está esperando eles descontinuarem o Docker Toolbox, para acreditar em mim, lamento. Muito menos importante LINK entre imagens já é anti-pattern e já está como deprecated há pelo menos 2 anos (a recomendação é o uso de networks) e ainda não foi removido.

Diferente da Google, a Docker é muito conservadora para remover seus produtos.

Não use Docker Toolbox

A primeira versão do Docker Toolbox aparece no github em 11/07/2015, era a versão 1.7.0. Em 12 de agosto, no blog do Docker temos o anúncio Announcing Docker Toolbox: The fastest way to get Docker running in development.

Parece excelente, mas não é isso que temos na verdade.

Temos uma integração que beira o eventualmente funciona, sempre dá pau. Sempre = Todo dia, mais de uma vez por dia.

Não obstante, em menos de 1 ano, 28/07/2016 sai a primeira release (1.12.0) do Docker for Windows.

Em menos de 1 ano, jogaram fora um produto e entregaram outro!

Ficou claro que Docker Toolbox não funciona?

Quem está apto a usar Docker For Windows?

Usuários de Windows 10 a partir do build 15063.

O vídeo tem algumas coisas a mais, como a explicação do que você consegue ou não rodar com Linux Containers. Semelhante ao que escrevi na Wiki.

Outra parte que é nebulosa para quem está começando, é que muita gente acha que Containers Linux poderiam rodar aplicações Windows, ou containers Windows poderiam rodar aplicações Linux.

O fato você de ter instalado Docker for Windows, não diz que você vai rodar aplicações windows no linux nem vice-versa. Docker for Windows agora rebatizado de Docker Desktop for Windows permite que você use Hyper-v para virtualizar um linux afim de rodar containers linux, com uma integração mais que razoável (mas não perfeita) no Windows.

Isso quer dizer que sua CLI DOCKER está no Windows mas o DOCKERD (Daemon) está no linux e se encontra em uma VM Linux.

Linux Containers rodam sobre o Kernel do Linux

Windows Containers rodam sobre o Kernel do Windows

“Nunca” Linux Containers rodarão sobre o Kernel do Windows, assim como nunca Windows Containers rodarão no kernel do Linux.

Pra se ter uma ideia, sequer aplicações Linux que rodam em servidores X86 rodam no Raspberry PI. Pois uma é AMD64 outra é ARM.

Você está dizendo o contrário de tudo que li!

Na real, eu não estou contradizendo ninguém. Muito provavelmente ao ler, você interpretou algo errado. Nem Microsoft nem Docker mentem em suas explicações, no entanto partem do pressuposto de que essas informações básicas são de conhecimento público. Por isso, fica tão confuso. As documentações são escritas por pessoas que estão imersas nessas tecnologias, isso faz com que o óbvio não seja dito.

A falta do óbvio é o que gera toda essa confusão.

Então o que pode ser feito, qual é o real ganho do Docker então, já que você só mostrou “defeitos” ou “limitações”?

Aplicações Windows

Se você tem aplicações dependentes do Windows, está à sua disposição os Windows Containers. Eles são baseados em apenas 2 imagens: Server Core e Nano Server. Aplicações baseadas em IIS, como ASP.NET Web forms quando containerizadas são hospedadas com Windows Containers rodando em Windows Server.

Aplicações Multiplataforma (Linux e Windows)

A maioria das linguagens e plataformas são baseadas em runtimes, mas vamos ao exemplo de GO, que não tem dependência de runtime. O binário já é um executável autônomo. Você deveria ter um build para cada arquitetura. Com builds arm64v8, amd64, windows-amd64 suas imagens podem rodar no Windows, Linux e Raspberry Pi (ou qualquer dispositivo arm v8).

Nos casos das aplicações que exigem runtime, como Node, .NET, Java, Erlang, para cada uma dessas 3 arquiteturas, seu dockerfile deve se basear em uma imagem diferente. Todos esses runtimes possuem versão para todas ou pelo menos as principais arquiteturas. Basta saber a tag correta.

Visite https://hub.docker.com/_/node/

Ao clicar em arm64v8 você é redirecionado para outra imagem https://hub.docker.com/r/arm64v8/node/ .

Parece complicado!

Não, definitivamente não é complicado, você em geral tem somente um build para AMD64, é o deploy mais comum. Em geral suas aplicações não estão disponíveis para esses tantos tipos de dispositivo. Uma vez com o build na arquitetura certa, você consegue usar em qualquer dispositivo, independente da distribuição que estiver usando.

Aplicações Windows podem usar serviços linux. Há um grande empenho para o Windows server hospedar lado-a-lado, aplicações Windows em composição com serviços linux. Seria o caso de uma aplicação ASP.NET Web Forms que use Redis, ou RabbitMQ por exemplo.

Conclusão

Há inúmeras oportunidades, mas não há mágica.

Esse post te ajudou a esclarecer algum aspecto do uso de Docker? Deixe seu comentário, com dúvidas ou sugestões.