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

37. Grazi Bonizi
https://twitter.com/grazibonizi
https://github.com/grazibonizi
https://medium.com/@grazibonizi
https://www.linkedin.com/in/graziella-bonizi-b14835a0/
49