Olá pessoal, já faz algum tempo que não escrevo sobre .NET. Tenho me dedicado aos vídeos sobre Docker, mas escolhi um tema muito divertido para falar: Novas estratégias de deploy com .NET Core.

Quem vem acompanhando os novos rumos da Microsoft, deve estar compreendendo que estamos diante de uma magnífica e imensa mudança de paradigma, que trás consigo não apenas um novo framework, mas novas e infinitas possibilidades. Alinhada à estratégia open source, a Microsoft está mudando e transformando-se para ser mais competitiva e entenda: A proximidade com o Linux não é um tiro no pé, mas uma abordagem mais realista, que endereça o sonho de muitos, assim como eu.

[dt_quote type=”blockquote” font_size=”big” animation=”none” background=”plain”]Especulando: O resultado a longo prazo, é que poderemos ter a chance de ver o Windows sendo realmente competitivo em relação ao Linux, justificando talvez o esforço de migração e o custo licenciamento. [/dt_quote]

O anúncio do Microsoft vNext, mexeu com a comunidade, já que tudo que ha mais de uma década conhecíamos estava prestes a mudar. É admirável o esforço e a capacidade de coordenar toda essa transição que ao meu ver foi complexa, mas não foi caótica. A empresa começou com o ASP.NET MVC, que desde a versão 1 assustou muitos que estavam na inércia, e alguns que até hoje choram com a estagnação do ASP.NET Web Forms, julgando o Web Forms, mais eficiente, produtivo. Bom, quem não olhou para MVC de forma séria ainda, pode usar sem menor pudor a badge #Dino.NET.

O ASP.NET MVC trouxe de volta a necessidade por compreender a web como ela é, e isso trouxe vantagens para a comunidade como um todo. Com as mudanças nos times Microsoft, é possível ver que a chegada de sangue novo, ajudou muito nessa transição do lado de lá, favorecendo e impulsionando um refactoring completo da plataforma. Mais tarde, vemos a possibilidade de abandonarmos o System.Web, e isso trouxe um frio na barriga, mas para quem já estava usando OWIN e/ou NanxyFX, essa questão foi encarada com muito bons olhos. Como se não bastasse, temos um novo .NET Open Source, Cross Platform, rodando até em raspberry pi.

Na prática temos um reboot do .NET acontecendo a pleno vapor! O fantástico .NET Framework está dando lugar ao .NET Standard, nova plataforma unificada implementada por todos os runtimes oficiais. O .NET Framework, apelidado de Full Framework, embora nem de longe tenha oficialmente um planejamento para ser descontinuado, podemos entender, pela dinâmica do mercado que esse é seu destino. A Microsoft não está empenhando-se muito em novas versões do Full Framework, o .NET Framework Monthly Rollup está planejado para trazer melhorias de segurança e confiabilidade, nada mais. De outro lado, não vemos outros movimentos na direção para novas features no Full Framework.

O que nos resta? Aprender!

.NET Core e ASP.NET Core

Hoje já temos a opção de usarmos ASP.NET Core sobre o .NET Framework, ou sob o .NET Core. Possibilidades além do ASP.NET MVC que tínhamos no Full Framework. Além de aplicações web, podemos construir serviços e console applications sobre o .NET Core.

A confusão que a Microsoft vem fazendo nos nomes de seus produtos está deixando todo mundo louco. Então vai uma dica:

.NET Core is a cross-platform, open source, and modular .NET platform for creating modern web apps, microservices, libraries and console applications.

ASP.NET Core is an open source web framework for building modern web applications that can be developed and run on Windows, Linux and the Mac. It includes the MVC framework, which now combines the features of MVC and Web API into a single web programming framework. ASP.NET Core is built on the .NET Core runtime, but it can also be run on the full .NET Framework for maximum compatibility.

Então vamos lá:

.NET Core é o novo runtime e bibliotecas.

ASP.NET Core é o novo ASP.NET MVC, desenvolvido sob o .NET Core, e feito para o .NET Core, no entanto é também compatível com o .NET Framework!!!!

Assim:

.NET Core é cross-platform

.NET Framework roda exclusivamente no Windows (incluindo Server Core, tema que abordo daqui a pouco).

Containers e Docker

E continuamos falando das novidades, que já não são poucas, vem esse tal de Docker e containers pra complicar mais ainda! Não é? Não! Containers simplificam o processo de desenvolvimento, teste, implantação e gestão. Docker aparece com principal vendor para a implantação de containers em qualquer plataforma, oferecendo uma gigantesca gama de recursos em um universo consistente e diversificado de soluções de suporte ao dia-a-dia de quem quer usar containers.

A melhor analogia que encontrei para explicar containers vem de um dos posts do blog do Docker.

Casas (VMs) são totalmente auto-suficientes e oferecem proteção contra visitantes indesejados. Cada uma delas também possui a sua própria infra-estrutura – encanamento, aquecimento, eletricidade, etc. Além disso, na grande maioria dos casos, casas terão que ter, no mínimo, um quarto, sala de estar, banheiro e cozinha. Mesmo se eu comprar a menor casa, posso acabar comprando mais do que preciso, porque é assim que as casas são construídas. (Para o pedante aí, sim, eu estou ignorando a nova tendência em casas micro, porque eles quebram minha analogia).

Apartamentos (os recipientes) também oferecem proteção contra visitantes indesejados, mas eles são construídos em torno da infra-estrutura compartilhada. O prédio (Docker host) compartilha encanamento, aquecimento, eletricidade, etc. Além disso apartamentos são oferecidos de todos os tipos e tamanhos diferentes – estúdio de multi-quarto penthouse. Você só está alugando exatamente o que você precisa. Finalmente, assim como casas, apartamentos têm portas que fecham-se para evitar os hóspedes indesejados.

Com containers, você compartilha os recursos subjacentes do Docker Host e construir uma imagem que é exatamente o que você precisa para executar o aplicativo. Você começar com o básico e você adiciona o que necessita. VMs são construídas na direção oposta. Você vai começar com um sistema operacional completo e, dependendo da aplicação, pode ser necessário retirar as coisas que você não quer.

Como se não bastasse, temos ainda Windows Containers e Linux Containers. E esse assunto está muito mal explicado, as pessoas estão entrando em parafuso achando que as imagens do IIS, ou .NET Framework 3.5 rodarão no Linux. Não, não irão!!

A imagem abaixo será usada no decorrer desse post para explicar cada tópico.

Linux Containers

No Windows (1), linux containers (8) são suportados com Hyper-V (4), usando máquinas virtuais (MobyLinuxVM) (9). Nela você encontra o Dockerd que fará a mágica dos containers. Já no Windows (1) você terá o Docker.exe (docker no linux), CLI, é o que você usa no dia-a-dia para interagir com o dockerd. No linux, docker e dockerd estão juntos, no Windows (1), quando falamos de Linux Containers (8), o docker.exe está no Windows (1) enquanto o dockerd está no linux da vm MobyLinuxVM (9). Nos Linux Containers (8) com Docker usamos todas as velhas imagens, como centos, ubuntu, busybox, alpine, etc. Os binários serão executados dentro da infraestrutura Linux, pois são binários compilados para linux.

Windows Containers

Aqui começa a confusão! Os Windows Containers (2 e 5) são containers que usam a infraestrutura do Docker para rodar processos x86 e x64 sob o Windows (1).

Windows Server Containers x Hyper-V Containers

O Windows Server 2016 oferece ainda Windows Server containers (2) e Hyper-V containers (5) , como é possível ver no link, não há diferença na gestão, no entanto ao usar o parâmetro “–isolation=hyperv” ao executar o docker run/create, o Hyper-V (4) entrará em ação para prover o isolamento do Kernel com utilização de máquinas virtuais (6). Acha que está complicando? Que tal uma lida nesse link aqui.

Nano Server x Server Core

Nano Server e Server Core são duas distribuições thin do Windows. Ambas estão disponíveis como imagens para máquinas (físicas ou virtuais) (Nano Server / Deploy Nano Server / Nano Server Quick Start, Server Core), quanto OS Images, disponíveis para a utilização em containers, disponíveis no Docker Hub (Nano Server, Server Core). Note que os links das imagens do Docker Hub apontam para as tags, justamente para que possam ter ideia da diferença em tamanho, de cada imagem. Nano Server 305 MB, Server Core 4GB.

Uma boa notícia: Optar por uma das duas imagem é extremamente simples: Use Nano Server sempre que puder, quando não, use Server Core. A má notícia é que nem tudo irá funcionar no Nano Server, portanto, em algum momento terá de conviver com a imagem Server Core.

Agora que estamos contextualizados, podemos seguir para a parte 2.