BT

Início Artigos .NET Core e DevOps

.NET Core e DevOps

This item in japanese

Favoritos

Pontos Principais

  • O DevOps é uma busca de valor e é recompensadora, não importa qual tecnologia utiliza atualmente
  • Software proprietário e processos de construção não funcionam bem com as práticas de DevOps
  • O .NET Core é open source e foi concebido e construído para o DevOps
  • O .NET Core CLI e a API Roslyn tornam todo o processo de entrega aberto e adaptável
  • A automação é uma grande parte do DevOps; O .NET Core foi construído a partir do zero para suportar automação de construção e implementação

Com o lançamento do .NET Core 2.0, a Microsoft atingiu a próxima versão principal da plataforma de propósito geral, modular, multiplataforma e de código aberto que foi lançada inicialmente em 2016. O .NET Core foi criado para ter muitas das APIs que estão disponíveis na versão atual do .NET Framework. Ele foi inicialmente criado para permitir a próxima geração de soluções ASP.NET, mas agora impulsiona e é a base para muitos outros cenários, incluindo IoT, nuvem e soluções móveis de próxima geração. Nesta segunda série, abrangendo o .NET Core, exploraremos mais alguns benefícios e como ele pode beneficiar não apenas desenvolvedores tradicionais de .NET, mas também todos àqueles que precisam levar soluções robustas, eficazes e econômicas ao mercado.

Tenho desenvolvido software há tempo suficiente desde que o .NET 1.0 estava em versão beta. Lembro-me de pensar que usar o .NET parecia trapaça. "Isso não era pra ser difícil?", me perguntei. "Cadê meu malloc? Não tenho que lançar nenhum feitiço aritmético de ponteiro? O que é essa Framework Class Library?". Passei os primeiros seis meses pensando que era algum truque elaborado.

Avançando para 2018, ainda estamos felizes escrevendo código no .NET Framework, sem nos preocuparmos com a alocação de memória. O threading foi tratado para nós pelo System.Thread, BackgroundWorker e agora pelo Task. Classes FCL são marcadas como thread-safe para nós, ou não, antecipadamente. Quer escrever um aplicativo da web? Aqui está um quadro completo, com as pilhas inclusas. Muitas das coisas que tivemos que fabricar manualmente são fornecidas pelo .NET, em uma bandeja de prata virtual. O resultado é que nós, desenvolvedores, passamos muito mais tempo escrevendo código que fornece valor comercial (ufa!). Os hipsters do Assembly/C/C++ podem reclamar, lamentando a falta de conhecimento hard-core de programação, agora precisam do desenvolvedor médio. Eu, por exemplo, não estou reclamando!

O .NET passou por muitas iterações, incluindo quatro versões principais, desde a primeira versão Beta. Sua iteração mais recente, o .NET Core, é a mais significativa até agora. Os recursos do .NET Core incluem a verdadeira segmentação de plataforma cruzada, um CLI moderno e um sistema de criação, além de uma biblioteca de código aberto, entre outros. Essas coisas são importantes, mas a promessa do .NET Core vai além. Essa promessa vai pela maneira como o software é produzido e entregue.

Tenho escrito software por mais de vinte anos, então eu também tenho idade suficiente para lembrar quando o source control era uma curiosidade reservada para equipes "grandes". "Automação" não estava realmente em nosso léxico - exceto na medida em que automatizamos processos de negócios para nossos clientes. Construir/compilar software era algo feito, ironicamente, por um ser humano. Um "gerente de criação" produzia binários em seu próprio computador (onde sempre funcionava em sua máquina!)

A implantação de software nos ambientes em que ele seria executado era (e com muita freqüência ainda é) um processo frágil e bizantino de unidades compartilhadas, FTP e cópia/colagem manual de arquivos. Integrar o trabalho das equipes de desenvolvimento era uma marcha miserável da morte, jogando whack-a-mole com uma regressão após a próxima. O software está pronto para produção? Quem sabe?

O software estava rapidamente construindo seu apetite pelo mundo, mas o processo de produzir, implantar e operar sistemas baseados em software estava preso nos dias de Turing e Hopper. Uma revolução estava no ar, que começou por volta de 2008, e seu nome era DevOps.

Os anos intermediários entre então e agora trouxeram a ascensão de um movimento. O DevOps é uma grande coisa que abrange e, talvez, substitui o movimento Ágil que veio antes dele. Fui apresentado ao DevOps em 2014 quando recebi uma cópia do The Phoenix Project em uma conferência. Tomei a fatídica decisão de crackeá-lo de vez em quando, pensando que leria apenas algumas páginas. Que tolo eu fui. Meus planos de conferência naquele dia caíram no esquecimento enquanto devorava aquele livro. Ele falou comigo, como se tivesse cada vez mais a mostrar. Se já esteve no setor de TI, mesmo por um curto período, já um foi desses personagens. Pode confessar. O DevOps tem sido um foco de carreira para mim desde então.

O DevOps é frequentemente apresentado como tendo três grandes "pernas": Cultura, Processo e Tecnologia. Este artigo é sobre a tecnologia do DevOps. Especificamente, é sobre a tecnologia que o .NET Core traz para as modernas práticas de DevOps. O .NET Core foi concebido durante a ascensão do DevOps. A Microsoft claramente tem metas bem definidas para tornar o .NET Core uma plataforma da era DevOps. Este artigo abordará três tópicos principais do .NET Core e DevOps:

  • O .NET Core Framework e seu SDK
  • Automação de construção
  • Monitoramento de Aplicações

.NET Core Framework e o SDK

O DevOps não existe no vácuo. As tecnologias usadas para produzir e fornecer sistemas baseados em software podem oferecer suporte às práticas de DevOps ou impedi-las. DevOps é uma busca válida, independentemente da sua tecnologia. Dito isto, a tecnologia escolhida terá um impacto significativo na sua prática de DevOps.

Sistemas de compilação proprietária, de código fechado, não são compatíveis com o DevOps. O .NET Core é totalmente open source, e os formatos de arquivo usados para representar projetos e soluções são cuidadosamente documentados. Linguagens e estruturas modernas, como Node/Javascript, Ruby e Python, foram desenvolvidas com alguns recursos comuns:

  • Estruturas compactas e de código aberto
  • Interfaces de linha de comando (CLI)
  • Sistemas de construção abertos bem documentados
  • Suporte para todos os principais sistemas operacionais

Esses recursos e muito mais se tornaram populares na era DevOps porque são fáceis de adaptar e automatizar. O .NET Core CLI, dotnet, é o ponto de entrada singular para todos os processos de criação de um aplicativo .NET Core. A CLI de dotnet funciona em estações de trabalho de desenvolvedores e constrói agentes, independentemente da plataforma. A saber: todo o trabalho de desenvolvimento local que eu demonstrarei daqui em diante será realizado em um MacBook Pro. Tente imaginar isso há apenas três anos!

O primeiro passo com o .NET Core é baixá-lo. Se for acompanhar, acesse aqui e faça o download do SDK. Ele é pequeno, consumindo apenas 171MB no meu MBP. Depois de instalado, abra sua janela do Terminal favorita (prefiro o Powershell quando estou "Windando", mas uso o iTerm2 no meu Mac).

Se você já conhece o desenvolvimento do .NET, está acostumado a grandes instalações de framework. Você está acostumado a usar o Visual Studio para trabalhar. Se você é novo no .NET Core, isso vai parecer um pouco estranho, no bom sentido. Vamos fazer muito com esses 171 megabytes antes de tocarmos em um IDE.

Execute:

dotnet

Este é o novo comando da CLI que permite a interação com o .NET Core SDK em seu sistema. A saída aqui exibe as opções de CLI disponíveis. Vamos olhar mais fundo.

Execute:

dotnet help

Esta é uma lista de todos os comandos suportados pela CLI. Não é uma lista longa e não precisa ser. Você está procurando tudo o que precisa para interagir com o processo de criação da estrutura do .NET Core, de um projeto de "tela nova" a um aplicativo implantado.

O primeiro passo é criar um novo aplicativo. Vamos ver nossas opções.

Execute:

dotnet new

A saída listará os modelos disponíveis. Esta é a parte no Visual Studio onde você clica em Novo projeto de arquivo, porém aqui estamos trabalhando a partir da linha de comando. Temos alguns modelos para escolher. Eu gosto bastante do Angular, então vamos começar por aí.

Execute:

dotnet new angular -o dotnet-angular

Isso criará um novo projeto Angular em um novo diretório dotnet-angular. Você pode criar o diretório manualmente se preferir, mas não se esqueça de alterá-lo antes de executar o dotnet new ou o projeto será criado no diretório atual (aprendi da maneira mais difícil).

Se você já faz o desenvolvimento em Angular, provavelmente terá o Node instalado. Se não, tire um momento para baixar e instalar. Se você precisar instalar o Node, feche e reabra seu terminal após a instalação.

Execute:

dotnet run

Este comando irá compilar e executar o aplicativo (a compilação também pode ser feita sem executar o aplicativo executando o comando dotnet build.) Isso pode levar um ou dois minutos; então você terá alguma saída que inclua um URL:

** Content root path: /Users/dswersky/dotnet-angular Now listening on: https://localhost:5001 **

Copie o URL em um navegador da web e dê uma olhada. O que você deve ver agora é um aplicativo simples executando ASP.NET Core em segundo plano e Angular no front end. Vamos respirar por um momento e pensar em como essa experiência difere da experiência de desenvolvimento do .NET do passado.

Se você estivesse acompanhando, criou e executou um aplicativo .NET Core em poucos minutos (mesmo que tenha que instalar o .NET Core e o Node!) algumas perguntas podem surgir:

Onde está meu IDE?

Nós não precisamos de um para chegar a este ponto, não é? Obviamente, se você quiser editar esse código, precisará de algo para fazer isso. Você provavelmente desejará usar uma ferramenta que tenha algum conhecimento sobre .NET e Angular. "Não há problema", você pode pensar, "vou iniciar o Visual Studio Professional e começar a trabalhar." Você poderia fazer isso ... ou você pode baixar o Visual Studio Code, que é quase tão capaz e grátis. Você poderia usar o Visual Studio Community, que também é gratuito. O ponto aqui é que não é mais necessário investir centenas de dólares para começar a desenvolver com o .NET Core. Você pode começar pequeno e crescer organicamente.

Onde está o IIS?

Esta é uma grande diferença entre "legado" (cedo demais?) desenvolvimento de aplicações web .NET e ASP.NET Core. Você pode executar aplicativos ASP.NET Core no IIS, mas não é necessário. A necessidade de desmembrar ASP.NET Core do IIS é óbvia, considerando o fato de que o .NET Core é realmente multi-plataforma. Os comandos que listei aqui, incluindo o dotnet run, funcionam igualmente bem e precisamente da mesma maneira no Windows, Mac e Linux (existe até uma build ARM que rodará em um Raspberry Pi!) Esse aplicativo Angular é um dos muitos que você pode agora "escrever uma vez, rode em qualquer lugar".

Hospedar aplicativos .NET sem o IIS já é possível há algum tempo. A interface da Web aberta para .NET (OWIN) oferece suporte a aplicativos ASP.NET "auto-hospedados" por anos. Isso foi possível graças ao código e à infraestrutura, geralmente chamado de "Projeto Katana". O .NET Core usa um servidor HTTPS chamado Kestrel. O Kestrel é um servidor HTTPS de software livre rápido e de alto desempenho para aplicativos .NET. O Kestrel fornece HTTPS para sites ASP.NET Core e serviços RESTful sendo executados em qualquer lugar, incluindo Windows, Linux e orquestradores de contêineres. O Kestrel torna os aplicativos ASP.NET Core completamente autocontidos, sem dependências externas em um servidor HTTPS baseado no Windows.

O que isso tem a ver com o DevOps?

A automação é um princípio fundamental e uma prática do DevOps. A portabilidade, a CLI e o sistema de criação de código aberto oferecido pelo .NET Core são essenciais para as práticas de DevOps. Mais importante, eles facilitam a automação dos processos de criação e implantação. Essa automação pode ser realizada pelo script da CLI, ou programaticamente, automatizando o sistema de compilação diretamente. Esses recursos do .NET Core tornam isso possível, mas relativamente fácil de automatizar processos complexos de construção. Isso nos leva a construir automação e integração contínua.

Automação do .NET Core Build

Nos tempos do Visual SourceSafe ("nós entendemos Dave, você é um ancião"), ocorreu-me que o código que minha equipe estava enviando para esse repositório estava lá, disponível e pronto para ser compilado. Uma ideia fez a minha mente pensar "por que eu construo implantações do meu sistema quando isso pode ser feito a partir de lá?" Eu não fui o único a ter essa ideia, também não posso afirmar ser um dos únicos que fez algo sobre. Os poucos que fizeram algo com isso. Essa afirmação pertence às bravas almas que embarcaram no desenvolvimento de sistemas de Integração Contínua (CI).

O objetivo da CI é simples de dizer, não tão simples de alcançar:

Sempre tenha uma construção pronta para implantação.

O desenvolvimento de software é um esporte coletivo. A equipe média de Agile/Scrum tem de três a cinco desenvolvedores em tempo integral contribuindo ativamente com código. O trabalho que eles fazem é dividido entre eles por uma questão de eficiência. O código que eles produzem deve ser combinado, construído e testado em conjunto como uma unidade. Esse teste deve ser automatizado, usando um sistema que não tenha ferramentas de desenvolvedor instaladas. Idealmente, o build e o teste devem ocorrer toda vez que um novo código for mesclado a uma ramificação designada (isso seria mestre no desenvolvimento baseado em trunk). Os sistemas de CI geralmente são integrados diretamente aos sistemas de controle de código fonte, acionando uma nova compilação sempre que a ramificação de CI mudou.

O Roslyn é um compilador de código aberto para .NET, com uma riqueza de APIs que você pode acessar diretamente. Os desenvolvedores de sistemas de CI usam as APIs do compilador para construir plug-ins, que por sua vez automatizam os processos de criação do .NET. As ferramentas de criação do .NET Core, como a Roslyn, fornecem um controle refinado sobre o processo de criação. Os desenvolvedores podem usá-los para adaptar e estender os recursos existentes do sistema de CI para cobrir praticamente qualquer caso de uso de pipeline de construção concebível. A melhor parte é que você não precisa ser um desenvolvedor do sistema de CI para criar um plug-in. Mantenedores e fornecedores de sistemas de CI fazem todo o possível para tornar seus sistemas fáceis de estender.

Existem vários sistemas de CI por aí. Veja uma breve lista de exemplos, que não está completa:

  • Jenkins
  • TFS/Visual Studio Team Services
  • CircleCI
  • TeamCity
  • GitLab

A flexibilidade oferecida pelo .NET Core permite que ele trabalhe com qualquer sistema de CI. Isso pode ser tão simples quanto um script trabalhando com a CLI, ou plugins que usam as APIs do compilador para automatizar a construção diretamente.

Se você tem atualmente um sistema de CI favorito, pode experimentá-lo com meu projeto de exemplo. Este é o mesmo projeto que criamos com o CLI anteriormente, com um pouco mais. O repositório inclui um Dockerfile. Demorei cerca de dez minutos para criar um pipeline de criação do VSTS que extraia o código do Github, cria uma imagem e o envia para um Azure Container Registry. Isso funcionaria tão bem com um pipeline Jenkinsfile ou GitLab, na AWS ou no Google Cloud. As possibilidades são, como dizem, quase infinitas.

Monitoramento de aplicativos com o .NET Core

O "cuidado e a alimentação" dos sistemas de software é um trabalho em tempo integral; pergunte aos seus colegas da equipe de operações. Esses sistemas são como um bebê irritado e com cólica, constantemente precisando de algum tipo de atenção. A equipe de operações são muitas vezes como o novo pai confuso, sem entender por que o sistema está gritando por essa atenção. Como os sistemas gritam por atenção? Isso depende de como você os assiste ou não!

A pior maneira de monitorar sistemas é não monitorá-los. Independentemente de você monitorar ou não, de uma forma ou de outra, acabará descobrindo quando eles quebram. Quando seus clientes ficarem com raiva ou simplesmente desistirem de seus serviços, você descobrirá que é tarde demais. O objetivo do Monitoramento de Aplicativos é detectar problemas antes de seus clientes ou usuários finais (realmente não há diferença prática). Muitas empresas avaliam a falsa economia que o monitoramento de aplicativos é muito caro ou que "sistemas bem feitos não precisam de monitoramento. Não caia nessa.

Mesmo o sistema mais estável é apenas um fracasso ou uma mudança de catástrofe. As práticas de DevOps tentam equilibrar a segurança com a velocidade, permitindo que as empresas inovem, movendo-se com rapidez e segurança ao mesmo tempo. Esse equilíbrio é mantido, observando atentamente os parâmetros operacionais do sistema.

O design e a arquitetura do .NET Core são adequados para o monitoramento de aplicativos. O ASP.NET Core é um excelente exemplo. É possível personalizar o comportamento interno de solicitação/resposta de aplicativos ASP.NET 3.x/4.x, em execução no IIS, usando Módulos HTTP. O ASP.NET Core melhora esse modelo com o middleware, que é semelhante no conceito aos Módulos HTTP, mas é bem diferente na implementação. As classes de middleware são integradas por meio de código e são muito mais simples de configurar. Eles formam uma cadeia de pipelines de solicitação/resposta de modificadores para a resposta a uma solicitação.

Injetar middleware em um aplicativo ASP.NET Core que executa o monitoramento é quase trivialmente fácil. Demonstrarei um exemplo com o Azure Application Insights. Eu criei um recurso do Application Insights em meu portal do Azure e editei exatamente três arquivos no meu repositório para habilitar o monitoramento do Application Insights:

dotnet-angular.csproj

Foi adicionada uma linha para referenciar a montagem do Application Insights (essa etapa manual só foi necessária porque eu estava usando o Visual Studio para Mac, detalhes aqui.)

appsettings.json

Adicionado minha chave de instrumentação do Application Insights.

Startup.cs

Startup.cs é onde o middleware é configurado. Eu adicionei o middleware do Application Insights aqui.

Depois que essas coisas foram concluídas, comecei a depurar localmente e coletar dados de monitoramento do Application Insights. Você pode experimentá-lo, basta substituir a chave de amostra em appsettings.json com a sua chave.

O Application Insights não é sua única opção para o monitoramento de aplicativos. O AppMetrics é uma biblioteca de monitoramento de código aberto que se integra a ferramentas de visualização, como o Grafana. Há também opções pagas de fornecedores que oferecem recursos corporativos.

Todas essas opções de monitoramento fornecem transparência; a capacidade de visualizar o comportamento de seu aplicativo em seus ambientes de execução (especialmente Produção!) Isso é essencial para a prática de DevOps, pois permite verificar, com números concretos, que as alterações que você está fazendo em seu sistema não estão prejudicando seu desempenho. Você pode então adicionar novos recursos com a confiança de que mover-se rapidamente não precisa quebrar as coisas.

Conclusão

O .NET Core foi concebido e desenvolvido com as práticas de DevOps em mente. O CLI e o sistema de construção aberta e as bibliotecas permitem automatizar e adaptar o processo de entrega de software a praticamente qualquer conjunto imaginável de requisitos. Crie automação e integração contínua por meio de scripts CLI ou integração programática mais profunda, se preferir. O monitoramento de aplicativos com ferramentas corporativas de código aberto ou pagas está disponível para transformar seu sistema de uma caixa preta em um painel de vidro limpo. O .NET Core, fornecido usando as práticas de DevOps, é uma plataforma atraente para sistemas de software modernos.

Sobre o autor

Dave Swersky trabalha com TI há mais de 20 anos, desempenhando funções de engenheiro de suporte, desenvolvedor de software e Enterprise Architect. Ele é um aspirante a poliglota e apaixonado por tudo relacionado a DevOps. Ele falou sobre DevOps em conferências, incluindo o DevOps Enterprise Summit, o CodeMash, o Stir Trek e em encontros locais no KC. Dave também escreveu um livro sobre DevOps: DevOps Katas: Hands-On DevOps. Dave pode ser encontrado no Twitter @dswersky.

 

Com o lançamento do .NET Core 2.0, a Microsoft atingiu a próxima versão principal da plataforma de propósito geral, modular, multiplataforma e de código aberto que foi lançada inicialmente em 2016. O .NET Core foi criado para ter muitas das APIs que estão disponíveis na versão atual do .NET Framework. Ele foi inicialmente criado para permitir a próxima geração de soluções ASP.NET, mas agora impulsiona e é a base para muitos outros cenários, incluindo IoT, nuvem e soluções móveis de próxima geração. Nesta segunda série, abrangendo o .NET Core, exploraremos mais alguns benefícios e como ele pode beneficiar não apenas desenvolvedores tradicionais de .NET, mas também todos àqueles que precisam levar soluções robustas, eficazes e econômicas ao mercado.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Seu cadastro no InfoQ está atualizado? Poderia rever suas informações?

Nota: se você alterar seu email, receberá uma mensagem de confirmação

Nome da empresa:
Cargo/papel na empresa:
Tamanho da empresa:
País:
Estado:
Você vai receber um email para validação do novo endereço. Esta janela pop-up fechará em instantes.