O post é simples, rápido mas ajuda a entender o que significa esse tumulto a respeito do suporte nativo a Docker e Linux Containers no Windows 2016 Server.

Complexidade do Docker

Primeiro, é importante ressaltar que se fosse de fato possível rodar Linux Containers no Windows, sem virtualização, deveríamos ter um anúncio do tamanho do anúncio da chegada do homem à lua. Ok, estou exagerando, mas é importante compreender a dimensão do que seria, definitivamente seria algo incrivelmente fantástico. E por que? Porque mesmo com os esforços no desenvolvimento do Windows Subsystem for Linux, as features do Kernel do Linux exigidas pelo Docker estão a anos de distância na timeline de desenvolvimento do Windows Subsystem for Linux.

Hoje conseguimos rodar muita coisa, mas definitivamente Docker é um projeto que não conseguimos rodar no Windows, ainda, sem nenhum tipo de virtualização. Detalhando melhor o produto e seus componentes vemos o Docker como CLI e DockerD seu daemon. No passado o problema morava no DockerD, mas com as diversas quebras e abstrações que o DockerD veio sofrendo ao longo dos últimos 2 anos, emergindo do código fonte do dockerd, containerd, e runC.  A cada evolução no docker, vemos o dockerd ficando cada vez mais agnóstico, e outros elementos vão assumindo papéis que outrora eram do dockerd. Reside no runC a incapacidade de executar Linux Containers no kernel do windows. Esse problema ocorre em virtude das features do kernel dos quais ele depende.

Ainda é possível ver posts que apelam para o sensacionalismo como “Setting Up Docker for Windows and WSL to Work Flawlessly” (link) ou “[Cross Post] WSL Interoperability with Docker” (link). Na verdade estamos falando de rodar Docker no WSL enquanto o DockerD e suas dependências estão no Docker for Windows (e por sua vez no Hyper-v).

Então, o que vem a ser esse suporte Nativo a Linux Containers?

A resposta é simples e é muito interessante:

Trata-se de uma revisão sobre o Hyper-v, criando uma camada mais thin do que virtualização tradicional, algo parecido com uma virtualização de kernel, permitindo continuar usando a infraestrutura do hyper-v, mas com um stack infinitamente mais enxuto, mais rápido, mais eficiente, feito para rodar apenas o kernel em uma lightweight virtual machine, da forma mais enxuta possível.

Conclusão

A imagem abaixo apresenta novos elementos como HCS e GCS eles são responsáveis por colaborar com o hyper-v a ponto de viabilizar a criação de um stack reduzido de virtualização. Isso significa que ao invés de um stack completo, complexo e com provisionamento lento, milhares de camadas de abstração e isolamento, temos algo enxuto e instantâneo:

A forma adequada de usar Docker e Linux Containers no Windows Server é instalando um pacote powershell ou ou realizar uma instalação via DSC, não necessitando do Docker for Windows.

Update 10/03/2018

Fiz algumas revisões no texto para tirar a conotação de máquina virtual no que diz respeito às lightweight virtual machines. Na prática há uma discussão paralela e filosófica sobre lightweight virtual machine. Afinal, é uma VM ou não? Deixe seu comentário e conte o que você acha!

Um ponto bem relevante que precisamos ponderar é que: Docker já está se desprendendo de features do kernel, abstraindo muito quebrando-se em camadas, como containerd, runc, etc.  No passado DockerD tinha muita responsabilidade, mas na medida que o projeto é desmembrado em abstrações, se torna cada vez mais fácil ser multiplataforma. Ao mesmo tempo notamos que para a Microsoft foi mais estratégico criar o LCOW e combinar algumas abstrações com a Docker CO do que completar o mapeamento de syscalls do Kernel do Linux no WSL, demonstrando mais uma vez o hiato entre expectativa e realidade sobre o WSL.

No Windows 10

Aproveitei para buscar alguns posts sobre Docker no Windows 10, esclarecendo como você pode tirar proveito do LCOW e Docker native no windows.

https://blog.docker.com/2018/02/docker-for-windows-18-02-with-windows-10-fall-creators-update/

https://blog.docker.com/2017/11/docker-for-windows-17-11/

Opinião

Na minha opinião, a Microsoft não precisava adotar esse nome. Chamar de nativo é uma estratégia mais agressiva do que realista. Não entendo o motivo, talvez influencias no market share do Windows Server, talvez pressão do mercado, não sei. Mas de qualquer forma é notório que ajuda seu sistema operacional para servidores se sustentar e de quebra ganha elementos como Kubernetes e outros que originalmente foram desenhados para trabalhar exclusivamente com Linux Containers.