Na era do DevOps vencedor, os desenvolvedores são simplesmente obrigados a saber sobre os contêineres do Docker, por que eles são necessários e como trabalhar com eles. Isso facilita muito o trabalho. Além disso, mesmo aqueles que trabalham com o .Net Core no ambiente de desenvolvimento do Visual Studio 2017 podem sentir todo o poder da conteinerização.Pavel Skiba, chefe do departamento de desenvolvimento de aplicativos para servidor, na reunião
C # .Net do
Panda-Meetup , falou sobre as ferramentas disponíveis e a configuração do Docker for VS.
O que um desenvolvedor deve ser capaz de fazer? "Programa", você responde e ... Adivinha. Porém, se antes a lista de conhecimentos necessários terminava com isso, agora na era do DevOps está apenas começando. Quando escrevemos código, definitivamente precisamos conhecer a estrutura da rede: o que interage com o que. É necessário suporte para várias linguagens de programação ao mesmo tempo, e diferentes partes de código em um projeto podem ser escritas em qualquer coisa.
Precisamos saber como reverter o software se um erro for detectado. Precisamos gerenciar configurações para diferentes ambientes usados na empresa - esses são pelo menos vários ambientes de desenvolvimento, ambientes de teste e combate. Ah, sim, você ainda precisa entender scripts em diferentes servidores / sistemas operacionais, porque nem tudo pode ser feito usando código, às vezes você precisa escrever scripts.
Precisamos conhecer os requisitos de segurança, e eles estão se tornando mais difíceis e gastam muito tempo com o desenvolvedor. Não se esqueça do suporte e desenvolvimento de software relacionado: Git, Jenkins e assim por diante. Como resultado, o desenvolvedor pode simplesmente não ter tempo suficiente para o desenvolvimento puro.
O que fazer? Existe uma saída e ela está nos contêineres do Docker e em seu sistema de gerenciamento. Depois de implantar todo esse complexo colosso, e você, como nos velhos tempos, só escreverá código novamente. Todo o resto será controlado por outras pessoas ou pelo próprio sistema.
Entendemos contêineres
O que é um contêiner de docker? Esta é uma estrutura que consiste em várias camadas. A camada superior é a camada binária do seu aplicativo. A segunda e a terceira camada agora estão integradas no .Net Core, o contêiner já é SDK-shny. A próxima camada depende do sistema operacional no qual o contêiner está implantado. E a camada inferior é o próprio sistema operacional.
No nível inferior, o Windows Nanoserver é implantado. Este é um aperto mega-aparado do Windows Server, que não pode fazer nada além de manter um programa utilitário implantado. Mas o volume dela é 12 vezes menor.
Se compararmos os servidores e contêineres físicos e virtuais, os benefícios destes serão óbvios.
Quando tudo funcionava em servidores físicos, nos deparamos com vários problemas. Não havia isolamento nos códigos da biblioteca; alguns aplicativos poderiam interferir um no outro. Por exemplo: um aplicativo funcionou no .Net 1.1 e outro no .Net 2.0. Na maioria das vezes, isso levou à tragédia. Depois de algum tempo, os servidores virtuais apareceram, o problema do isolamento foi resolvido, não havia bibliotecas compartilhadas. É verdade que, ao mesmo tempo, ficou muito caro em termos de recursos e mão-de-obra: era necessário acompanhar quantas máquinas virtuais giravam em uma máquina virtual, no Hyper-V e em um pedaço de ferro.
Os contêineres foram projetados para serem uma solução barata e conveniente, minimamente dependente do sistema operacional. Vamos ver como eles diferem. Servidores virtuais dentro do sistema estão localizados aproximadamente assim.
A camada inferior é o servidor host. Pode ser físico ou virtual. A próxima camada é qualquer sistema operacional com virtualização, acima é um hipervisor. No topo, estão servidores virtuais que podem ser divididos em SO e aplicativos convidados. Ou seja, em cada servidor virtual, um sistema operacional convidado é implantado no sistema operacional, e isso é um desperdício extra de recursos.
Vamos ver como os contêineres do Linux estão localizados no sistema.
Como você pode ver, os binários com aplicativos são imediatamente localizados acima do servidor host e do SO. O SO convidado não é necessário, os recursos são liberados, as licenças do SO convidado não são necessárias.
Os contêineres do Windows são um pouco diferentes do Linux.
As camadas básicas são as mesmas: infraestrutura, SO host (mas agora Windows). Porém, os contêineres podem trabalhar diretamente com o sistema operacional ou ser implantados no topo do hipervisor. No primeiro caso, há isolamento de processos e espaços, mas eles usam o mesmo núcleo com outros contêineres, que do ponto de vista da segurança não são gelo. Se você usar contêineres através do Hyper-V, tudo será isolado.
Learning Docker for VS
Vamos para o próprio Docker. Suponha que você tenha o Visual Studio e esteja instalando o cliente Docker para Windows pela primeira vez. Nesse caso, o Docker implantará o servidor demo do Docker, a interface no Rest para acesso a ele e o próprio cliente - a linha de comando do Docker. Isso nos permitirá gerenciar tudo relacionado a contêineres: rede, imagens, contêineres, camadas.
O slide mostra os comandos mais simples: puxe o contêiner do Docker, inicie-o, colete, confirme, envie de volta.
O Docker é muito emparelhado organicamente com o Visual Studio. A captura de tela mostra um menu do painel do Visual Studio 2017. O suporte à composição do Docker é integrado diretamente ao Intellisense, o Dockerfile é suportado e todos os artefatos funcionam na linha de comando.
O interessante é que podemos depurar contêineres do Docker diretamente em tempo real. E se seus contêineres estiverem conectados entre si, eles serão imediatamente eliminados de uma só vez, e você não precisará executar vários ambientes.
Como são montados os contêineres? O elemento principal aqui é o dockerfile, que contém instruções para a construção da imagem. Cada dockerfile é criado para cada projeto. Indica: de onde obtemos a imagem básica, quais argumentos passamos, qual é o nome do diretório de trabalho com arquivos, portas.
Este argumento de origem tem dois parâmetros. O segundo parâmetro é o caminho no qual o resultado da montagem será colocado no projeto; o valor é definido por padrão. Na minha opinião, esta não é uma opção muito boa. Geralmente, há muito lixo nessa pasta, ela precisa ser limpa periodicamente e, quando limpamos essa pasta, podemos esfregar a montagem. Portanto, se desejar, você pode alterá-lo, ele é definido pelo parâmetro do sistema Docker_build_source, que também pode ser martelado.
A instrução Entrypoint permite configurar o contêiner como um arquivo executável. Essa linha é necessária para o .Net Core, para que, depois que o contêiner seja iniciado com êxito, ele envie uma mensagem "Seu aplicativo está sendo executado" para a linha de comando.
Agora, sobre depuração de contêineres. Tudo aqui é como um .net regular, você quase não perceberá a diferença. Na maioria das vezes, eu executo o .Net Core como auto-hospedado em dotnet.exe. Ele usa o depurador CLRDBG, o cache de pacotes NuGet e o código fonte.
O ASP.Net 4.5+ é hospedado pelo IIS ou IIS Express, usa o Microsoft Visual Studio Debugger e a origem da raiz do site no IIS.
Existem dois ambientes para depuração: Debug e Release. A tag da imagem de depuração é marcada como dev e a versão mais recente. Ao depurar, o argumento Source é melhor definido como obj / Docker / empty, para não ficar confuso, mas quando você libera obj / Docker / publish. Aqui você pode usar todos os mesmos binários, visualizações, pasta wwwroot e todas as dependências existentes.
Dominando o Docker Compose
Vamos para a parte divertida: a ferramenta de orquestração de composição do Docker. Vejamos um exemplo: você tem algum tipo de serviço comercial que afeta 5-6 contêineres. E você precisa, de alguma forma, corrigir como eles devem ser montados, em que ordem. É aqui que o Docker-compor é útil, o que fornecerá toda a montagem, lançamento e dimensionamento de contêineres. É gerenciado de forma simples, tudo é coletado por uma equipe.
O Docker-compose usa arquivos YAML que armazenam a configuração de como os contêineres devem ser montados. Eles descrevem quais configurações você precisa usar para as próprias imagens, montagens, serviços, volumes, redes, ambientes. A sintaxe é idêntica para publicação em clusters. Ou seja, depois que eles escrevem esse arquivo e, no futuro, for necessário implantar um serviço de negócios em um cluster, você não precisará adicionar mais nada.
Considere a estrutura de um arquivo YAML. Imagem é uma imagem do Docker. Uma imagem é um contêiner sem uma camada de aplicação e é imutável.
Build indica como construir, onde construir e onde implantar.
Depends_on - Dependência de quais serviços é dependente.
Meio ambiente - aqui definimos o meio ambiente.
Portas - mapeamento de portas em que porta seu contêiner estará disponível.
Considere um exemplo. Temos apenas uma API sem serviço, essencialmente três contêineres: existe SQL.data no Linux, existe um aplicativo em si, depende da webapi e a webapi depende do SQL.data.
Não importa em que ordem os componentes são gravados no arquivo. Se tudo estiver descrito corretamente, o Compose criará automaticamente essas informações corretamente com base nas dependências do projeto. Esse arquivo é suficiente para coletar todos os contêineres de uma só vez; a saída será uma versão finalizada.
Existe uma espécie de “contêiner de contêiner”, um docker de contêiner especial-compose.ci.build.yml, no qual toda a composição é montada. Você pode executar esse contêiner especial na linha de comando do Visual Studio e ele poderá concluir a montagem em um servidor de compilação, por exemplo, no Jenkins.
Dê uma olhada dentro do arquivo. O exemplo contém o diretório de trabalho e de onde ele vem. Ele restaura o projeto do GIT, publica ele próprio essa solução, configura o Release e carrega o resultado. Essa é toda a equipe a construir, nada mais precisa ser escrito. Basta registrá-lo uma vez e iniciar a publicação com um botão.
No que mais vale a pena prestar atenção. A composição do Docker para cada ambiente coleta imagens, para cada configuração um arquivo separado. Para cada configuração no Visual Studio, há um arquivo com as configurações necessárias para o ambiente.
Diretamente do VS, você pode iniciar remotamente a depuração de toda a composição.
Orquestradores de Cluster
Por fim, abordamos tópicos como orquestradores de cluster. Não devemos pensar em como os contêineres continuam a existir, quais pessoas ou sistemas são gerenciados. Para isso, existem quatro dos sistemas de gerenciamento de contêiner mais populares: Google Kubernetes, Mesos DC / OS, Docker Swarm e Azure Service Fabric. Eles permitem gerenciar o armazenamento em cluster e a composição de contêineres.
Esses sistemas são capazes de lidar com uma enorme camada de microsserviços, fornecendo tudo o que é necessário. O desenvolvedor precisará configurar essa camada apenas uma vez.
A versão completa da performance no Panda Meetup está disponível abaixo.
Para aqueles que desejam se aprofundar no assunto, aconselho que você estude os seguintes materiais:
Http://dot.net
Http://docs.docker.com
Http://hub.docker.com/microsoft
Http://docs.microsoft.com
Http://visualstudio.com
E, finalmente, um conselho importante da prática: o mais difícil é lembrar onde está o que está.
A documentação ao trabalhar com contêineres de encaixe cairá sobre seus ombros. Sem documentação, você esquecerá onde em qual contêiner o que está conectado com o que e o que funciona. Quanto mais serviços, maior a rede total de conexões.