![FROM microsoft/dotnet:sdk AS build-env
WORKDIR /app
# Copy csproj and restore as distinct layers
COPY *.csproj ./
RUN dotnet restore
# Copy everything else and build
COPY . ./
RUN dotnet publish -c Release -o out
# Build runtime image
FROM microsoft/dotnet:aspnetcore-runtime
WORKDIR /app
COPY --from=build-env /app/out .
ENTRYPOINT ["dotnet", "aspnetapp.dll"]
37
Exemplo de um dockerfile](https://image.slidesharecdn.com/devopscomastackmicrosoft-181123195329/85/DevOps-Docker-com-a-stack-Microsoft-29-320.jpg)
DevOps & Docker com a stack Microsoft
- 1. DevOps & Docker Com a stack Microsoft Grazi Bonizi Sou Consultora DevOps e auxilio empresas durante seu processo de transformação digital. Coordeno a trilha de Arquitetura .Net no The Developers Conference, compartilho código no GitHub, escrevo no Medium, e participo de Meetups e PodCasts sobre DevOps, Azure, .Net, Docker e DDD https://twitter.com/grazibonizi https://github.com/grazibonizi https://medium.com/@grazibonizi https://www.linkedin.com/in/graziella-bonizi-b14835a0/ 1 2
- 2. Conteúdo Fundamentos do DevOps Introdução ao Docker Introdução ao Kubernetes Apresentando o Azure DevOps 3 DevOps é um assunto amplo, e envolve tanto um lado mais humano e cultural, quanto um lado técnico e mais prático. O conteúdo desta palestra é voltado para o lado prático, portando, além dos conceitos do DevOps, apresentarei os fundamentos de Docker e Kubernetes, relacionados à containerização e microsserviços, e também apresentarei a plataforma de DevOps da Microsoft, o Azure DevOps, antigo VSTS.
- 3. Por que DevOps? 4 • DevOps consiste em um conjunto de práticas para entregar software melhor e mais rápido. • Um dos pilares é a aproximação entre as áreas Desenvolvimento e Operações, tanto culturalmente, quanto por meio de tecnologias e ferramentas que atravessem ou reduzam esses limites. • Reduzindo o tempo entre o desenvolvimento e a entrega, é possível ter ciclos que favoreçam a aprendizagem validada, viabilizando maior integridade, segurança e eficiência nas entregas.
- 4. Disciplinas DevOps Agile Planning Version Control Continuous Integration Continuous Delivery Public & Hybrid Clouds Monitoring & Logging Containers Microservices Infrastructure as a Code 5 • As disciplinas DevOps são as principais áreas que uma organização pode focar para entregar e sustentar uma solução com maior agilidade e eficiência. • Algumas envolvem uma quebra de paradigma, como Planejamento Ágil e Nuvens Híbridas, outras não necessariamente, como Infraestrutura como Código. • Algumas são mais subjetivas e podem surtir efeito a longo prazo, outras são mais práticas e de resultado concreto – com a implementação de integração e entrega contínuas (CI/CD), por exemplo, é possível reduzir deploys que demoravam horas a dias para serem executados manualmente a apenas alguns minutos. • Algumas afetam mais a área de Desenvolvimento, outras a de Operações.
- 5. Agile Planning Agile Planning Version Control Continuous Integration Continuous Delivery Public & Hybrid Clouds Monitoring & Logging Containers Microservices Infrastructure as a Code 6 • Planejamento Ágil, ou Práticas Lean, envolvem um conjunto de processos e mudança de mindset para reduzir o ciclo de entregas e permitir a aprendizagem validada. Kaban, Scrum, CMMI ou outras frameworks de trabalho podem ser utilizadas. • Essa disciplina se torna bem desafiadora por trazer um impacto direto na cultura da empresa, inclusive na forma em que a contratação de desenvolvimento de software é realizada – por escopo e/ou por prazo. • É importante abordar esta disciplina, porém insistir nela quando há uma resistência muito forte pode trazer o efeito oposto ao que se busca, causando desgaste entre as pessoas, impactando os prazos e diminuindo a qualidade das entregas. Jeff Ries fala sobre isso em seu artigo “Developers should abandom Agile”, disponível no link https://ronjeffries.com/articles/018-01ff/abandon-1/
- 6. Agile Planning 7 Independente de usar ou não alguma framework Ágil, o planejamento, distribuição e acompanhamento de atividades deve ser realizado. A ferramenta de apoio deve permitir • Organizar e distribuir tarefas • Garantir a visibilidade do andamento do projeto • Trazer indicadores para viabilizar a aprendizagem validada das entregas
- 7. Version Control Agile Planning Version Control Continuous Integration Continuous Delivery Public & Hybrid Clouds Monitoring & Logging Containers Microservices Infrastructure as a Code 9 Versionamento de código é uma disciplina que a maioria das empresas já atua em algum nível. É muito claro que o código precisa ser versionado, porém alguns pontos muitas vezes não são abordados com os devidos cuidados: • Mesmo que haja apenas um desenvolvedor trabalhando no código, ele precisa ser versionado, desde suas primeiras linhas • Demos, samples e scripts utilitários também deveriam ser versionados em um repositório apropriado – você nunca sabe quando irá precisar deles • Scripts de banco e de automação de infraestrutura também são código, portanto deveriam ser versionados • O time deve conseguir recuperar determinada versão de código facilmente – por exemplo, o que está em produção, ou a versão anterior
- 8. Version Control 10 • Hoje, a ferramenta mais sólida e aceita no mercado para versionamento é o Git • Controle de Versão não se trata apenas de armazenamento e histórico – afeta diretamente como a equipe trabalha • Para isso, defina estratégias de branches, ou ramificações de código, para que o time possa trabalhar isoladamente sem sobreescrever o trabalho um do outro • Permita que o time revise o código antes de disponibilizá-lo, com estratégias de pull requests e branch policies • É importante utilizar ferramentas que permitam vincular o código desenvolvido à tarefas planejadas para permitir o rastreamento (ex: vincular o ID de um commit com o ID de uma tarefa)
- 9. Continuous Integration Agile Planning Version Control Continuous Integration Continuous Delivery Public & Hybrid Clouds Monitoring & Logging Containers Microservices Infrastructure as a Code 12 Continuous Integration é uma disciplina chave para o DevOps. Com ela são implementadas ferramentas e automações para garantir que o código no servidor esteja sempre íntegro e pronto para ser obtido por alguém da equipe ou deployado em algum ambiente.
- 10. Continuous Integration 13 As ferramentas de CI fornecem o feedback rápido se o código que está sendo enviado manteve os critérios definidos pela equipe em relação à integridade, por exemplo • Compila? • Atende a padronização especificada? • Os testes unitários / integração / aceitação foram bem sucedidos? • Os testes unitários atendem a taxa mínima de cobertura de código? • Está protegido contra vulnerabilidades conhecidas?
- 11. Continuous Integration 14 A esteira, ou pipeline de build / CI, consiste normalmente nos seguintes passos • Obtenção do código em um local “limpo”, sem configurações prévias de dependências de aplicação (ex: se um programador novo clonar o repositório e executar algum script de inicialização, será o suficiente para que o código compile? Ou será necessária alguma operação manual?) • Compilação • Execução das etapas de validação de integridade (testes, análise estática de código) • Geração do artefato (também chamado de “Build” ou “Pacote”) • Publicação do artefato em um repositório centralizado
- 12. Continuous Integration 15 • Uma das premissas do processo de Integração Contínua é a geração de um artefato imutável. O artefato, que pode ser por exemplo um executável, um conjunto de dll’s, páginas web ou scripts, quando combinado com as configurações de um ambiente, é um release em potencial neste ambiente • Se o artefato permitir alterações, não há a garantia de que o que foi validado em um ambiente será o mesmo conteúdo a ser publicado no próximo ambiente • Mais informações sobre como lidar com artefatos e arquivos de configuração podem ser vistas no • https://12factor.net/build-release-run • https://12factor.net/config
- 13. Continuous Delivery Agile Planning Version Control Continuous Integration Continuous Delivery Public & Hybrid Clouds Monitoring & Logging Containers Microservices Infrastructure as a Code 17 • Continuous Delivery é o conjunto de processos e ferramentas que permitem que o produto seja entregue no ambiente de destino automaticamente, isto é, sem necessidade de intervenção manual. • Essa disciplina traz efeitos imediatos na velocidade de entrega da empresa ou organização. Aproxima as áreas de Desenvolvimento e Operações, permitindo que os desenvolvedores se foquem na entrega das soluções de ponta a ponta, e operadores foquem na sustentação e crescimento dos ambientes e plataforma.
- 14. Continuous Delivery 18 • As ferramentas de automação de esteira de deploy devem permitir configurar fluxo de aprovação, deploy em horários agendados, pré e pós condições • Continuous Delivery significa que toda versão estável de código é um release em potencial • Continuous Deployment significa que toda versão estável será disponibilizada
- 15. Continuous Delivery 19 Exemplo de pipelines de Build e Release combinadas: • Determinado commit dispara um processo de build, gerando um artefato. • A cada estágio da esteira (DEV, BETA e PROD) o artefato é combinado com a configuração deste ambiente e entregue • As entregas ficam mais velozes, menos sujeitas a falhas humanas, e o fluxo de aprovação tem mais credibilidade
- 16. Public & Hybrid Clouds Agile Planning Version Control Continuous Integration Continuous Delivery Public & Hybrid Clouds Monitoring & Logging Containers Microservices Infrastructure as a Code 21 O uso de nuvens públicas ou híbridas está para a área de Infraestrutura como o CI/CD para a área de Desenvolvimento. Enquanto com o CI/CD é possível reduzir o tempo de deploy de aplicações de dias para minutos, com os grandes provedores de nuvens públicas, como a Azure, AWS e Google Cloud Platform, é possível reduzir o tempo de provisionamento de recursos de semanas para horas ou minutos.
- 17. Public & Hybrid Clouds 22 Para ilustrar o impacto da utilização de nuvens públicas em uma organização, pense no seguinte cenário: uma empresa fornece uma solução que foi muito bem aceita no mercado, e passou a ter um crescimento exponencial de usuários, exigindo uma expansão de recursos. • Datacenter On Premises: Caso a infraestrutura da solução esteja em um datacenter local, será necessário adquirir mais hardware. Em um processo tradicional, o responsável pela infra fará uma requisição de compra, que passará por uma série de etapas até ser aprovada. O hardware será entregue no estabelecimento, e precisará ser configurado para ficar disponível. Isso supondo que o datacenter suporte fisicamente a expansão de hardware. Caso contrário, será necessário montar um outro datacenter ou migrar para uma área maior, com resfriamento, no-breaks, e talvez implique até na contratação de mais pessoas para suportá-lo 24/7. Isso pode demorar semanas ou até meses. • Nuvem Privada: Esse processo é reduzido a abrir um chamado com o fornecedor e aguardar o cumprimento do SLA, que pode durar horas ou poucos dias. • Nuvem Híbrida: Provedores como o Azure fornecem portais e ferramentas em que é possível solicitar diretamente o recurso e tê-lo disponível em minutos.
- 18. Public & Hybrid Clouds 23 • Utilizar nuvens públicas pode implicar em uma quebra de paradigma, principalmente se a organização lida com dados altamente confidenciais, como financeiros ou judiciais. Porém as nuvens públicas possuem mais certificados de segurança, alta disponibilidade e eficiência no atendimento do que a maioria das nuvens privadas, quanto mais em relação à datacenters on premisses. • Conheça mais sobre os Azure Datacenters com esta curta demonstração: https://channel9.msdn.com/Blogs/Azure/Azure-Datacenter-Video
- 19. Monitoring & Logging Agile Planning Version Control Continuous Integration Continuous Delivery Public & Hybrid Clouds Monitoring & Logging Containers Microservices Infrastructure as a Code 25 • DevOps não diz respeito apenas ao desenvolvimento e deploy de software, e sim a práticas que permitem o crescimento sustentável da solução em todo o seu ciclo de vida. Isso inclui ferramentas de logging e monitoramento em diversos níveis. • Informação consistente, atual e disponível é um pilar para a aprendizagem validada.
- 20. Monitoring & Logging 26 O monitoramento pode ser aplicado em vários níveis: • Infraestrutura: Acompanhe o uso de CPU, disco e memória do servidores e rede, identifique falhas e faça projeções para o aumento de capacidade de acordo com o uso • Aplicação: Acompanhe o consumo dos serviços, identifique falhas e tenha acesso aos logs para maior agilidade no troubleshoot • Comportamento de usuários: Obtenha feedback sobre as features da solução, e identifique quais áreas são mais utilizadas e o grau de satisfação
- 21. Infrastructure as a Code Agile Planning Version Control Continuous Integration Continuous Delivery Public & Hybrid Clouds Monitoring & Logging Containers Microservices Infrastructure as a Code 28 Infrastrutura como código é transformar o provisionamento e/ou configuração de recursos em scripts que podem ser versionados e até testados.
- 22. Infrastructure as a Code 29 • Com a infraestrutura como código, é possível guardar os pré requisitos de determinado ambiente para que seja possível recriá-lo sempre que necessário. • Isso aumenta a velocidade no provisionamento de recursos e diminui as chances de falha humana. Aliando essa prática à utilização de nuvens públicas, é possível criar múltiplos recursos com a mesma configuração, em um intervalo de minutos. • “Servers are not pets” – essa frase mostra uma quebra de paradigma ao se considerar um servidor On Premises configurado manualmente, em que há a preocupação em mantê-lo operacional, e servidores criados via script na nuvem, que podem ser descartados e recriados facilmente.
- 23. Containers Agile Planning Version Control Continuous Integration Continuous Delivery Public & Hybrid Clouds Monitoring & Logging Containers Microservices Infrastructure as a Code 31 A utilização de containers abstrai claramente alguns princípios do DevOps de aproximação entre as áreas de Desenvolvimento e Infraestrutura. Com containers, o que é entregue é todo um ambiente, desde o sistema operacional até a aplicação pronta para ser executada, ao invés de apenas os binários e arquivos da aplicação.
- 24. Containers 32 • O problema mais clássico que a utilização de containers reduz é o famoso “funciona na minha máquina”. O ambiente de produção é diferente do ambiente de homologação, por sua vez, diferente do ambiente de desenvolvimento. Até a máquina de um desenvolvedor é diferente da máquina do outro. Sem algum nível de isolamento, a aplicação pode depender de recursos que estão pré-configurados na máquina, que podem não ser compatíveis em outros ambientes. • O container provém esse isolamento. A aplicação fica dentro de uma estrutura semelhante à uma máquina virtual, porém muito mais leve, possibilitando que todos os pré-requisitos de software e dependências da aplicação estejam contidas dentro dessa estrutura, independente da configuração do ambiente em que o container está rodando.
- 25. • Em 2020, mais de 50% das empresas irão rodar aplicações críticas, conteinerizadas e nativas para a nuvem em produção, comparando com os menos de 5% de hoje. – Gartner • Docker é a plataforma mais bem sucedida e aceita de containers no Mercado • Suporte a containers Windows e Linux Por que Docker? 33 Docker é uma plataforma open source de containers, a mais aceita no mercado. Já deixou de ser uma novidade e é hoje uma solução consolidada
- 26. Dockerfile Imagem Container Elementos 34 Para entender mais sobre Docker, é importante estar familiarizado com os seguintes termos: • Dockerfile: conjunto de instruções de criação e configuração do ambiente • Imagem: binários compactados de forma a serem armazenados e transportados • Container: imagem em execução
- 27. Dockerfile Imagem Container Elementos 35 Uma analogia que pode ajudar a compreender o que representam esses termos: • Dockerfile: receita de bolo • Imagem: mistura para bolo • Container: o próprio bolo
- 28. Sistema Operacional Middleware Dependências de aplicação Web Server Aplicação Comando de inicialização Debian DotnetCore Runtime Pacotes Nuget Kestrel Binários e arquivos estáticos dotnet app.dll Estrutura comum de um Dockerfile 36 Um exemplo de aplicação containerizada na estrutura de um Dockerfile, desde o SO até o comando que será executado quando o container for inicializado. Atenção para o ponto em destaque – em um contexto tradicional, o que é entregue é um pacote com os binários e arquivos estáticos da aplicação. No contexto de aplicações containerizadas, todo o restante também é fornecido
- 29. FROM microsoft/dotnet:sdk AS build-env WORKDIR /app # Copy csproj and restore as distinct layers COPY *.csproj ./ RUN dotnet restore # Copy everything else and build COPY . ./ RUN dotnet publish -c Release -o out # Build runtime image FROM microsoft/dotnet:aspnetcore-runtime WORKDIR /app COPY --from=build-env /app/out . ENTRYPOINT ["dotnet", "aspnetapp.dll"] 37 Exemplo de um dockerfile
- 30. Microservices Agile Planning Version Control Continuous Integration Continuous Delivery Public & Hybrid Clouds Monitoring & Logging Containers Microservices Infrastructure as a Code 40 Microsserviços é um conceito muito atual no mercado. Quando aplicado de maneira adequada, permite o crescimento sustentável e maior escalabilidade de soluções complexas, porém aumenta o grau de complexidade do gerenciamento da solução como um todo. Antes de mais nada, é importante frisar: uma aplicação monolítica ou um conjunto pequeno de serviços normalmente é o suficiente para atender um produto. Não aplique o conceito de microsserviços sem haver a real necessidade disso.
- 31. Microservices 41 • A principal diferença entre uma aplicação monolítica de uma solução em microsserviços é que o desenvolvimento não é apenas distribuído, mas independente. Pense ainda que é uma única solução, mas com componentes cujo ciclo de vida é individual. • Isso adiciona a complexidade técnica de gerenciar dezenas ou centenas de repositórios e esteiras de deploy, além da complexidade de versionamento/ compatibilidade e dificuldade de realizar testes integrados. • Porém é possível lidar com serviços mais críticos de maneira diferenciada. Para um e- commerce durante a Black Friday, é necessário escalar os serviços de autenticação e carrinho de compras, mas não o de cadastro de produtos novos, por exemplo. Não só em relação à escalabilidade, é possível utilizar tecnologias mais adequadas em aplicações de alta performance, definir os times de desenvolvimento de maneira coerente à complexidade do serviço e outras práticas que o desenvolvimento distribuído permite.
- 32. • Plataforma completa para publicação e gerenciamento de serviços, oferecendo alta disponibilidade, autocura • Gerenciamento de comunicação externa e interna dos containers • Gerenciamento de configurações e senhas • Coleta e centraliza logs • Facilida a gestão de elasticidade e escalabilidade das aplicações Por que Kubernetes? 42 • Quando se fala em Microsserviços, podem haver dezenas ou centenas de serviços se comunicando para atender uma solução de negócio. Alguns deles podem ser acessados externamente, como o frontend de um e-commerce ou uma API de produto, e outros se comunicam apenas internamente. O grau de criticidade e disponibilidade pode ser diferente, alguns podem exigir mais processamento que outros… • O Kubernetes é uma plataforma desenhada para o gerenciamento de containers em um cenário de Microsserviços. • A plataforma permite gerenciar cenários complexos de uma maneira muito mais simples, comparando com configurações.
- 33. 43 • Um cluster Kubernetes normalmente é composto por um ou mais servidores master e dois ou mais nodes. O master é responsável pela orquestração e gerenciamento, e os containers e outros recursos são executados dentro dos nodes. É possível dividir de maneira lógica o cluster em ambientes – (DEV, HML e PROD), mas sem se preocupar necessariamente com a divisão física, isto é, que nodes atendem DEV, HML ou PROD. • Isso por padrão não importa para a plataforma – a divisão lógica, também chamada de Namespace, é isolada por natureza. • O mesmo namespace utilizar recursos de nodes distintos permite que, caso um node fique indisponível, os recursos dele sejam realocados nos outros sem comprometer a disponibilidade da solução.
- 34. Secrets Config Maps App 1 Registry App 2 Storage 44 • Em um namespace há tudo que é necessário para a execução das aplicações – repositório de imagens docker, configurações, segredos, armazenamento, permissões, logs, e as aplicações em si. • É possível criar ambientes para representarem o fluxo de validação tradicional (ex: DEV / HML / PRD), ou criá-los sob demanda. • Em resumo, quando se trata de containers e microsserviços, o Kubernetes é uma das plataformas mais consolidadas no Mercado para o gerenciamento de aplicações.
- 35. MS Outros Git source control Azure DevOps Bitbucket, GitLab Agile Planning Azure DevOps Jira, Trello CI/CD Azure DevOps Bamboo, Jenkins Wiki Azure DevOps Confluence Package Management Azure DevOps Nexus Monitoring Application Insights Kibana, New Relic Tests Azure DevOps ALM Container Registry Azure Container Registry Docker Hub Kubernetes Platform Azure Kubernetes Service Openshift Comparativo de ferramentas 47 O Azure DevOps reúne os principais recursos para viabilizar a implementação do DevOps em uma organização. Combinado com outros recursos do Azure, como o Application Insights, Container Registry e o AKS, é possível contemplar todas as práticas mencionadas nesta apresentação, de forma moderna, intuitiva e integrada.
- 36. • Introdução ao DevOps: https://docs.microsoft.com/en-us/azure/devops/what-is-devops • Podcast sobre Kubernetes: https://www.lambda3.com.br/2018/04/lambda3-podcast-94- kubernetes/ • 12-Factor App: https://12factor.net/ • Developers should abandom Agile: https://ronjeffries.com/articles/018-01ff/abandon-1/ Aprofunde seus conhecimentos 48