Construir e liberar o pipeline

DevOps acredita na automação de construções e

implantações. Conceitualmente, um pipeline de lançamento é um processo
que determina como você entrega o software aos usuários finais. Na
prática, um pipeline de lançamento é uma implementação desse padrão. O
pipeline começa com o código no controle de versão e termina com o
código implantado na produção. No meio, muita coisa pode acontecer. O
código é compilado, os ambientes são configurados, muitos tipos de testes
são executados e, finalmente, o código é considerado concluído .

Por terminado, queremos dizer que o código está em produção. Para

algumas organizações, uma estrutura e estratégia de liberação de pipeline
precisa cobrir serviços, bancos de dados, Web e componentes de
aplicativos móveis e inclui:

 Consumo de pacote binário

 Integrações contínuas

 Publicação de pacotes

 Teste automatizado

 Entrega contínua

É importante reconhecer que as implantações móveis são diferentes das

implantações da Web e do servidor. A maneira como você obtém seu
aplicativo móvel para feedback é diferente do processo usado para obter
feedback sobre o aplicativo do servidor.

Consumo de pacote binário

O gerenciamento de pacotes permite reutilizar componentes

confiáveis. Um exemplo é os feeds do NuGet. Se você consome e reutiliza
pacotes de maneira consistente, pode manter seu aplicativo atualizado
conforme esses pacotes são atualizados. Isso é particularmente importante
para segurança e conformidade, pois os pacotes podem ser verificados,
identificados de forma exclusiva e, no caso de novas vulnerabilidades,
atualizados automaticamente.
Geralmente, os pacotes não devem ser incluídos no controle de versão,
pois podem aumentar significativamente o tamanho dos repositórios de
controle de versão. É melhor ter os pacotes armazenados no
gerenciamento de pacotes, como feeds internos do NuGet.

Integrações contínuas

Construções de integração contínua são construções que são acionadas a

cada check-in de código. Eles devem ser rápidos para concluir e incluir
testes automatizados (como testes de unidade). Eles podem ou não soltar
artefatos após a conclusão.

Publicação de pacotes
A publicação de pacotes pode ser vinculada ao consumo de pacotes
binários. Você deve usar uma versão que corresponda ao número de
compilação e implantação para obter total transparência (se uma
implantação quebrar, você poderá encontrar o pacote correspondente
rapidamente). O pacote deve ser hospedado em algum lugar acessível por
projetos, como os feeds do NuGet.

Teste automatizado
O teste pode incluir unidade, integração, interface do usuário
automatizada, desempenho da web e testes de carga. Os testes devem
poder ser executados de forma independente e com a maior frequência
possível, sem interrupções, como em construções de integração contínua
ou implantações automatizadas.

Entrega contínua

Entrega contínua significa que as implantações são acionadas

automaticamente após a conclusão de uma construção. O processo deve
incluir a escolha de um pacote de código compilado, a definição do
ambiente de destino no estado de configuração desejado e a implantação
automática nos ambientes. Pode incluir aprovações em ambientes de
controle de qualidade ou de produção.

Lista de pendências
 Uma das principais mudanças culturais necessárias para adotar as práticas
de DevOps está no nível do backlog. O romance The Phoenix Projectdesigna
os seguintes tipos de trabalho:

 Projetos de negócios . Trabalho que vem de iniciativas de negócios.

 Projetos internos de TI ou engenharia . Projetos de infraestrutura /

operações de um projeto de negócios ou projetos internos de
melhoria.Esses itens devem ser rastreados no mesmo backlog.

Nota: Para melhorar continuamente o sistema de trabalho e

adaptabilidade, recomenda-se que pelo menos 20% do tempo das equipes
de desenvolvimento e operações sejam alocados para requisitos não
funcionais, como segurança e infraestrutura, entre outros, para tornar o
processo significativamente melhor e mais estável . Se o tempo não for
alocado para este trabalho, a dívida técnica se acumulará e criará mais
trabalho não planejado.

 Trabalho não planejado / de recuperação . Os incidentes operacionais

foram direcionados para o trabalho planejado, o que pode causar gargalos
e confusão com as transferências. Esse trabalho também pode causar
longos prazos de execução com alta utilização, e muitas vezes é o resultado
de não remover a dívida técnica ou melhorar as práticas.

O lead time é o tempo de ciclo de quando uma equipe começa a escrever

código para sua primeira implementação bem-sucedida no ambiente de
produção. O lead time é considerado uma métrica mensurável que pode
ser melhorada com as práticas de DevOps.

Controle de versão
A maioria das organizações usa alguma forma de controle de versão para
gerenciar seu código-fonte. No entanto, nem todas as organizações usam o
controle de versão de forma eficaz. Duas estratégias de controle de versão
que às vezes são negligenciadas são:

 Configurando uma estratégia de ramificação apropriada.

 Ativando a transparência, vinculando itens de trabalho ao código.

Uma abordagem é ter uma única ramificação (como a ramificação principal

ou principal) que é construída em uma construção de integração contínua
automatizada e, em seguida, implementada em um ambiente de
desenvolvimento a cada confirmação ou check-in que ocorre na
ramificação. Dessa forma, é mais fácil saber quais alterações foram
liberadas no ambiente de desenvolvimento e, finalmente, na produção.

As alterações implantadas automaticamente no ambiente de

desenvolvimento serão então promovidas ou copiadas para o ambiente de
teste ou de preparação e, em seguida, para produção. O mesmo código
compilado será implantado na produção para que nunca haja uma situação
na qual o código não verificado seja promovido para produção. Antes de
implantar em qualquer ambiente, é importante garantir que as alterações
feitas estejam alinhadas à estratégia de negócios.

Conectando trabalho ao código

Uma maneira fácil de verificar se o código implantado tem valor e está
relacionado ao trabalho no backlog (em vez de código que não vincula a
nenhum item de trabalho) é vincular itens de trabalho a alterações de
código para que os metadados sejam mantidos com as alterações e depois,
com build e implantação. Ao conectar o trabalho em andamento ao código,
você pode validar o feedback dos usuários e as alterações feitas no código.

Algumas organizações usam diferentes estratégias de ramificação

dependendo do tipo de aplicativo que está sendo implantado, o grau de
acoplamento, a estrutura organizacional e a cadência de implantação. Uma
regra geral é promover a estratégia de ramificação mais simples possível
para manter a manutenção baixa e a sustentabilidade alta. Se você tem
filiais de vida longa que são raramente mescladas, você acumula uma
forma sutil de dívida técnica.

Se a sua organização não usa atualmente o controle de versão, é

importante começar a usá-lo para a versão do seu código. Uma boa
maneira de começar é aprender sobre repositórios Git, e distribuído vs.
controle de versão centralizado .

Nas organizações de DevOps, a infraestrutura é tratada da mesma maneira

que o código de software é tratado. Infraestrutura como Código (IaC) é o
gerenciamento e provisionamento de máquinas através de código. Esse
código é versionado em repositórios públicos ou privados e compartilhado
entre indivíduos e equipes para permitir mais colaboração enquanto
mantém um controle das alterações usando sistemas de controle de versão
como o Git.
Testando no DevOps
Testes contínuos
O teste contínuo é a execução de testes repetidamente em uma base de
código e em um ambiente de implementação. Na prática, o teste contínuo é
a parte mais difícil de um pipeline de entrega contínua para se manter
atualizado. O teste contínuo fornece portas de qualidade em todo o
pipeline e aumenta a confiança no código muito antes da produção.

Automação é a chave. Unidade automatizada, integração, interface do

usuário codificada e testes de carga são comuns em testes contínuos.

Use uma abordagem iterativa e incremental. A profundidade do teste

geralmente progride à medida que um ambiente se aproxima da produção.

Teste beta e exposição progressiva

O teste beta e a exposição progressiva são estratégias importantes no
DevOps para receber feedback crítico na produção.

Teste beta. Essa é uma forma de teste de aceitação de usuário externo em

que versões beta de um aplicativo são liberadas para um público-alvo
limitado, conhecido como testadores beta. As versões são liberadas para
grupos de pessoas para mais testes e, às vezes, disponibilizadas ao público
para mais comentários.

Exposição progressiva. Essa técnica envolve alternar um pequeno número

de usuários para uma nova versão de software para feedback e, em
seguida, expor progressivamente mais usuários aos recursos ao longo do
tempo.

Ambas as técnicas envolvem um pequeno grupo de usuários que testam

novas versões de um aplicativo. O feedback rápido significa que você
saberá rapidamente quais recursos são relevantes e que terá as
informações necessárias para criar estratégias e implementar maneiras de
melhorar o aplicativo. Quaisquer problemas de desempenho afetarão
apenas o pequeno número de usuários que estão testando a nova
versão.Esses tópicos são abordados com mais detalhes na seção sobre
monitoramento de desempenho de aplicativos mais adiante neste curso.
Video: What is Continuous Testing?

Conformidade no DevOps
Se você trabalha em uma instituição financeira, empresa de assistência à
saúde, agência governamental ou em qualquer setor altamente
regulamentado, a conformidade geralmente é a primeira preocupação
quando você está pensando em mudar para o DevOps. Ao lidar com os
requisitos de conformidade associados à Lei Sarbanes-Oxley dos EUA, à Lei
de Portabilidade e Responsabilidade de Seguro Saúde (HIPAA) ou aos
Serviços de Informações sobre Justiça Criminal (CJIS), algumas organizações
devem ser mais cuidadosas do que outras quando tomam decisões de
processo.

Um benefício principal de muitas soluções de implantação agora é oferecer

gerenciamento de segredos, por exemplo, usando serviços como o
Microsoft Azure KeyVault . Um repositório de segredos oferece a
capacidade de abstrair senhas, informações de string de conexão e
quaisquer outras variáveis de todos os usuários, para que não haja acesso
direto a dados confidenciais em bancos de dados ou em máquinas. Os
administradores configuram o acesso da solução de implantação à
máquina e abstraem as senhas.

Um pipeline de lançamento automatizado garante versões consistentes em

assemblies, pacotes, builds e implantações, usando testes automatizados,
infraestrutura como código e releases frequentes. Isso também torna a
conformidade mais previsível e direta. Com ciclos de feedback rápidos, se
surgirem problemas de não conformidade, correções podem ser feitas mais
rapidamente e as alterações podem ser rastreadas automaticamente.

Ken Cheney, anteriormente com a empresa Chef e agora com a Qumulo,

Inc., oferece essa perspectiva:

"A chave para tornar a conformidade uma vantagem é especificar requisitos de

conformidade como código, permitindo que o código seja testado como
qualquer outro código no pipeline de desenvolvimento de software. Tarefas de
verificação anteriormente manuais - geralmente rastreadas por planilhas ou
outros métodos árduos - podem agora, sejam abordados de forma proativa
como testes incorporados em um fluxo de trabalho automatizado. Os riscos de
segurança são trazidos à tona mais cedo para uma correção mais rápida,
 portanto softwares desatualizados são identificados e atualizados rapidamente
”.

Cada organização trata a conformidade de maneira diferente, portanto,

ferramentas diferentes podem ser necessárias, dependendo dos requisitos
de sua organização. Quaisquer que sejam as ferramentas adotadas para
conformidade, as práticas de DevOps oferecem previsibilidade e
simplificação para a manutenção de práticas compatíveis.

Para mais informações, consulte http://devops.com/2016/03/18/devops-

help-hinder-compliance/ .

Video: Compliance in DevOps

Segurança no DevOps
Juntamente com a conformidade, a segurança é muitas vezes outra
preocupação quando as organizações pensam em adotar práticas de
DevOps. A perspectiva de mais automação e menos verificações manuais
de segurança é uma preocupação compreensível. Um artigo
na revistaWired oferece essa visão: “Em última análise, o DevOps
transformará o modelo de negócios de TI em sua cabeça com tempos de
ciclo mais curtos, automação e integração interfuncional profunda para
entregar a próxima grande ideia”.

Ao trazer processos como gerenciamento de configuração e testes

automatizados para foco no início do pipeline de implementação, são
possíveis lançamentos rápidos e previsíveis. A segurança pode ser
introduzida mais cedo no processo também.

O DevOps pode melhorar a segurança das seguintes maneiras:

1. Pacotes de componentes podem ser automaticamente verificados a partir

de um registro confiável.

2. Usando ferramentas operacionais e de automação, a segurança pode ser

tratada quando o desenvolvimento começa com a análise de código, e não
como uma reflexão tardia. Depois de corrigir o código, o código que entra
na produção certamente já passou por varreduras de segurança e
correção. Falhas podem quebrar a construção.
3. Se uma vulnerabilidade for descoberta, um pipeline automatizado poderá
remediar imediatamente implantando um novo pacote de componentes.

4. Usando a nuvem pública cria uma infraestrutura dinâmica. Ao contrário de

uma arquitetura de data center estática, na nuvem não há lugar para
ameaças persistentes se esconderem.

5. Outra opção é automatizar ataques simulados e estresse no sistema antes

de um produto ou aplicativo entrar em produção para validar as respostas
do código. Se esses ataques forem adicionados ao pipeline de construção
(como chamar um script e sair se houver falha), essas tarefas poderão
falhar automaticamente na compilação. Isso garante que a liberação não
seja implantada no próximo ambiente.

6. Uma vez no ambiente de produção, a automação de testes para segurança

e monitoramento contínuo garantirá que o aplicativo seja seguro.

É importante observar, no entanto, que os especialistas em segurança

ainda são necessários para monitorar e adicionar segurança no
desenvolvimento ao DevOps. Nunca há garantias, mas automatizando mais
processos e estabelecendo pipelines e processos previsíveis, boas práticas
de segurança podem ser ainda mais consistentes.

Video: Security in DevOps

DevOps na nuvem
Quando você implanta em diferentes ambientes em uma cultura de
DevOps, uma das primeiras perguntas que devem ser abordadas é: Em que
tipo de ambiente estamos implantando nosso código? A resposta depende
do tipo de aplicativo e do processo de implantação atual. Há muitas opções
para provedores de nuvem, sejam públicos ou privados (como para o
governo), e no local ainda é um cenário comum. Há vantagens e
desvantagens para cada opção, e algumas ações são mais fáceis de realizar
em um tipo e mais difíceis em outro.

Fácil na nuvem, difícil no local:

 Escala. Escale verticalmente ou horizontalmente para quantas máquinas
você precisar, limitadas apenas pelo valor que você deseja pagar pelas
máquinas. Isso nem sempre é possível no local, em que uma organização
 pode estar limitada pela memória física disponível para VMs ou ter que
passar por um processo difícil para adquirir novas máquinas.

 Armazenamento de dados. Embora varie entre os provedores de nuvem,

o preço das contas de armazenamento na nuvem pode ser mais barato do
que hospedar sua própria SAN com espaço suficiente.

 Confiabilidade. Muitos provedores de nuvem oferecem um contrato de

nível de serviço de quase 100% (potencialmente 99,9%), e esse
desempenho não é necessariamente uma garantia no local.

 Tempo e pessoas necessárias. Quando estiver no local, talvez você não

considere cuidadosamente o custo do tempo e das pessoas envolvidas na
configuração e manutenção de servidores. Pode levar alguns dias para que
uma máquina seja provisionada no local. na nuvem, pode levar apenas
alguns minutos. Em vez de atribuir funções para inicializar e manter
máquinas no local, o tempo pode ser usado para melhorar a infraestrutura
de nuvem ou inovar para tornar o processo de DevOps melhor.

 Segurança. Provedores de nuvem como a Microsoft, apesar de serem

grandes alvos de ataques, estão constantemente procurando violações na
segurança com hackers agressivos de chapéu branco. Isso pode significar
que uma nuvem é possivelmente mais segura que suas máquinas locais.

 Custo. O custo pode ser otimizado para cargas variáveis. Isso, obviamente,
depende da arquitetura e dos requisitos da sua aplicação. A nuvem torna
muito econômico a escala, não necessariamente para aumentar a escala.

Fácil no local, difícil na nuvem:

 Retrabalho. Se for necessário um grande retrabalho para colocar o
aplicativo na nuvem, pode ser um desafio demais justificar o tempo e os
recursos necessários.

 Cultura. Embora raramente considerada, a cultura de uma organização

afeta muito a mudança para a nuvem. Se uma cultura organizacional rígida
favorece as máquinas locais, pode ser um desafio migrar para a nuvem.

 Alterar Agentes para DevOps

 Fazer a mudança cultural para o DevOps é difícil. Você pode ser um
agente de mudança eficaz para a sua organização para orientar com
 sucesso essa mudança, compreendendo os problemas de negócios e
conectando as medidas técnicas que os resolverão, e rastreando as
métricas para se alinhar aos resultados de negócios adequados.
 Por exemplo, ao tentar convencer as partes interessadas do seu
negócio a automatizar implantações, em vez de iniciar a conversa
dizendo "Queremos automatizar nosso canal de lançamento", tente
liderar com o seguinte:
 "Ao nos focarmos em nossa velocidade de implantação, teremos tempo
mais rápido para mitigar problemas e reduzir o tempo de retorno. Isso
permite que trabalhemos em pequenos lotes para que possamos testar o
uso e obter aprendizados validados de cada implementação. É típico os
requisitos aumentam o valor do negócio em cerca de um terço do tempo,
diminuem o valor do negócio em cerca de um terço do tempo e não
fazem diferença em um terço do tempo.Queremos falhar rapidamente
nos ineficazes dois terços, e fazer mais do um terço disso gera melhorias.
Com o DevOps, podemos trabalhar mais rápido para saber se estamos
desenvolvendo os recursos certos ou se necessário, em última análise,
podemos melhorar e nos adaptar com base na constante informação
dos dados. "
 Traçar a conexão entre o modo como a sua organização realiza
alguma ação e por que, em primeiro lugar, deve ajudar a conseguir o
buy-in. Se você conseguir vincular a estratégia de negócios com
implementações técnicas, provavelmente será capaz de superar a
maioria das objeções ao DevOps.

Video: Change Agents for DevOps

Alterar Agentes para DevOps

Fazer a mudança cultural para o DevOps é difícil. Você pode ser um agente
de mudança eficaz para a sua organização para orientar com sucesso essa
mudança, compreendendo os problemas de negócios e conectando as
medidas técnicas que os resolverão, e rastreando as métricas para se
alinhar aos resultados de negócios adequados.

Por exemplo, ao tentar convencer as partes interessadas do seu negócio a

automatizar implantações, em vez de iniciar a conversa dizendo "Queremos
automatizar nosso canal de lançamento", tente liderar com o seguinte:
"Ao nos focarmos em nossa velocidade de implantação, teremos tempo mais
rápido para mitigar problemas e reduzir o tempo de retorno. Isso permite que
trabalhemos em pequenos lotes para que possamos testar o uso e obter
aprendizados validados de cada implementação. É típico os requisitos
aumentam o valor do negócio em cerca de um terço do tempo, diminuem o
valor do negócio em cerca de um terço do tempo e não fazem diferença em um
terço do tempo.Queremos falhar rapidamente nos ineficazes dois terços, e fazer
mais do um terço disso gera melhorias. Com o DevOps, podemos trabalhar
mais rápido para saber se estamos desenvolvendo os recursos certos ou se
necessário, em última análise, podemos melhorar e nos adaptar com base na
constante informação dos dados. "

Traçar a conexão entre o modo como a sua organização realiza alguma

ação e por que, em primeiro lugar, deve ajudar a conseguir o buy-in. Se
você conseguir vincular a estratégia de negócios com implementações
técnicas, provavelmente será capaz de superar a maioria das objeções ao
DevOps.

Video: Change Agents for DevOps

Estudo de caso: a divisão de
desenvolvedores da Microsoft passa para
o DevOps
Em sete anos, a divisão de desenvolvedores da Microsoft (DevDiv) adotou
as práticas do Agile. A divisão alcançou uma redução de 15 vezes na dívida
técnica por meio de práticas de engenharia sólidas, tiradas pesadamente
do XP. Eles treinaram todos no Scrum, equipes multidisciplinares e
propriedade do produto em toda a divisão. Eles se concentraram
significativamente no fluxo de valor para os clientes. No momento em que
enviaram o Visual Studio 2010, a linha de produtos alcançou um nível de
reconhecimento do cliente inigualável.

Depois que eles lançaram o Microsoft Visual Studio 2010, a equipe sabia
que precisava começar a converter o Team Foundation Server em uma
oferta de software como serviço (SaaS). A versão SaaS, agora chamada de
Visual Studio Online (VSO), seria hospedada no Microsoft Azure e, para
obter êxito, precisava adotar as práticas de DevOps.

Isso significava que a divisão precisava expandir suas práticas de Agile para
DevOps. Uma suposição tácita do Agile era que o Product Owner era
onisciente e poderia preparar o backlog corretamente. Em contraste,
quando você executa um serviço de alta confiabilidade, é possível observar
como os clientes estão realmente usando seus recursos quase em tempo
real. Você pode lançar com frequência, experimentar melhorias, avaliar e
perguntar aos clientes como eles percebem as alterações. Os dados que
você coleta se tornam a base para o próximo conjunto de melhorias que
você faz.

Dessa forma, um backlog de produto do DevOps é realmente um conjunto

de hipóteses que se tornam experimentos no software em execução e
permitem um ciclo de feedback contínuo. O DevOps cresceu do Agile com
base em quatro tendências:

Ao contrário de muitas empresas “nascidas na nuvem”, a Microsoft não

começou com uma oferta de SaaS. A maioria dos clientes estava usando a
versão local de seu software (Team Foundation Server). Quando a VSO
iniciou o VSO, a divisão determinou que eles manteriam uma única base de
código para as versões SaaS e “box” do produto, desenvolvendo a nuvem
primeiro.

Quando um engenheiro envia código, ele aciona um pipeline de integração

contínua. No final de cada sprint de três semanas, eles são liberados para a
nuvem e, após quatro a cinco sprints, eles lançam uma atualização
trimestral para o produto no local, conforme ilustrado abaixo:
 Para saber mais sobre aspectos específicos dessa jornada, do controle de
origem à cultura de site ao vivo, da ramificação ao código aberto, ao
alinhamento, consulte Nossa jornada para o Cloud Cadence: lições
aprendidas na Microsoft Developer Division , um e-book gratuito de Sam
Guckenheimer.

Video: Reflecting on the DevOps Journey

Saber mais
 Faça a autoavaliação DevOps , da Microsoft, que pode ajudá-lo a entender
melhor suas práticas de desenvolvimento atuais e onde focar em seguida.

 Assista a uma entrevista com Sam Guckenheimer para saber mais sobre o
DevOps robusto e os antipadrões DevOps.

 Leia The Phoenix Project: Uma Novela sobre TI, DevOps e Ajudando Sua
Empresa a Ganhar por Gene Kim, Kevin Behr e George Spafford. (© 2013 IT
Revolution Press LLC, Portland, OR)

 Veja a apresentação Velocity 2009 “ 10+ Implanta por Dia ”, de John Allspaw
e Paul Hammond.

 Veja a apresentação no Build 2016 por Brian Keller e Lori Lamkin da

Microsoft: DevOps em escala: uma verdadeira história .
DevOps201.01.002_CB
DevOps201.01.005_MC
0.0/1.0 point (ungraded)
What does tooling provide in DevOps? The answer could vary depending on
your approach but think of it in terms of what has been outlined in the
course up to this point

structure

autonomous coding

configuration

automation

não respondida

Enviar
You have used 0 of 2 attemptsSome problems have options such as save, reset,
hints, or show answer. These options follow the Submit button.
SalvarSave Your Answer

DevOps201.01.010_MC
0.0/1.0 point (ungraded)
In a DevOps implementation, which process must be certified to ensure
compliance with regulatory requirements?

tests

deployment binary

pipeline

build

não respondida

Enviar
You have used 0 of 2 attemptsSome problems have options such as save, reset,
hints, or show answer. These options follow the Submit button.
SalvarSave Your Answer
DevOps201.01.011_MC
0.0/1.0 point (ungraded)
How does DevOps impact security of an application or machine? (Choose 2)

Security is increased by including it earlier in the process.

Security is increased because of the automation process.

Security is reduced because of the automation process.

Security is reduced because of the development process.

não respondida

Enviar
You have used 0 of 2 attemptsSome problems have options such as save, reset,
hints, or show answer. These options follow the Submit button.
SalvarSave Your Answer

DevOps201.01.009_CB
0.0/1.0 point (ungraded)
Which three data items must be managed as part of a secrets management
system?

binary packages

connection strings

localized tokens

passwords

personally identifiable information

não respondida

Enviar
You have used 0 of 2 attemptsSome problems have options such as save, reset,
hints, or show answer. These options follow the Submit button.
SalvarSave Your Answer
DevOps201.01.003_MC
0.0/1.0 point (ungraded)
Which of the following is an example of a binary package consumption
package management approach?

SourceSafe

NuGet feeds

RSS feeds

GitHub

não respondida

Enviar
You have used 0 of 2 attemptsSome problems have options such as save, reset,
hints, or show answer. These options follow the Submit button.
SalvarSave Your Answer

DevOps201.01.012_CB
0.0/1.0 point (ungraded)
Which two aspects of DevOps are easier to implement using cloud services
rather than on-premises?

culture changes

project rework

reliability

scalability

não respondida

Enviar
You have used 0 of 2 attemptsSome problems have options such as save, reset,
hints, or show answer. These options follow the Submit button.
SalvarSave Your Answer

DevOps201.01.006_DR
 0.0/1.0 point (ungraded)
When optimizing processes for speed, what is one of the main end goals?

não respondida

Enviar
You have used 0 of 2 attemptsSome problems have options such as save, reset,
hints, or show answer. These options follow the Submit button.
SalvarSave Your Answer

DevOps201.01.001_MC
0.0/1.0 point (ungraded)
What is the end goal of DevOps?

Provide project management during development.

Provide operational management.

Deliver applications to end users.

Deliver value to end users.

objetivos de aprendizado
Depois de concluir este módulo, você será capaz de:

 Descreva porque o gerenciamento de configuração deve ser usado em uma

cultura de DevOps e como isso pode melhorar a entrega de valor aos
clientes.

 Identifique uma estratégia de infraestrutura como código (IaC) e uma

configuração como estratégia de código.

 Explicar como usar a infraestrutura como código para padronizar as

implantações de seu ambiente e como usar a configuração como código
para padronizar a configuração do ambiente.

 Diferencie como os ambientes diferem em infraestrutura como um serviço

(IaaS), plataforma como um serviço (PaaS) e contêineres.
 Identifique as ferramentas da Microsoft que você pode usar para oferecer
suporte ao gerenciamento de configuração.

Gerenciamento de configurações
Gerenciamento de configuração é o gerenciamento da configuração de
todos os ambientes para um aplicativo. Normalmente, o gerenciamento de
configuração é feito na forma de scripts controlados por versão. Aqui estão
algumas características principais:

 O gerenciamento de configuração no mundo do DevOps é menos formal

que o gerenciamento de configuração tradicional.

 Ele enfatiza o encapsulamento da configuração no código sobre a

documentação formal.

 Isso significa configurações mais leves e executáveis que nos permitem ter
configuração e ambientes como código.

Tanto Infraestrutura como Código (IaC) e configuração como código estão

sob gerenciamento de configuração, e ambos estão relacionados à
definição ou criação de scripts para ambientes:

 Infraestrutura como Código. O IaC envolve ambientes de definição,

incluindo redes, servidores e outros recursos de computação, como um
arquivo de texto (script ou definição) que é verificado no controle de versão
e usado como a fonte base para criar ou atualizar esses ambientes. Por
exemplo, adicionar um novo servidor deve ser feito editando um arquivo de
texto e executando o pipeline de lançamento, não remotamente no
ambiente e girando um manualmente.

 Configuração como código. Nesta abordagem, você define a configuração

de seus servidores, códigos e outros recursos como um arquivo de texto
(script ou definição) que é verificado no controle de versão e usado como a
origem base para criar ou atualizar essas configurações. Por exemplo,
adicionar uma nova porta a um firewall deve ser feito editando um arquivo
de texto e executando o pipeline de lançamento, não remotamente no
ambiente e girando um manualmente.
Usar ferramentas como SaltStack ou Ansible em CI / CD significa capitalizar
o conhecimento de uma equipe em uma única ferramenta e acelerar alguns
processos, como gerenciamento e implantação de configurações.

Gerenciamento de Configuração com

Ansible
Ansible é uma ferramenta de gerenciamento e automação de
configuração. É uma ferramenta de código aberto baseada em Python.

Ele usa arquivos de configuração YAML declarativos, chamados

de playbooks, para descrever um estado ou uma política que você deseja
que seus sistemas remotos apliquem ou executem. Playbooks são a
linguagem de configuração, implantação e orquestração da Ansible.

O Ansible usa o Secure Shell (SSH) para executar comandos em máquinas

remotas, o que o torna sem agente. Ele vem com vários módulos que
podem ser executados diretamente, remotamente ou através de
Playbooks. Esses módulos são componentes reutilizáveis que podem ser
usados pela Ansible API ou por programas Ansible ou Ansible Playbook. Os
desenvolvedores também podem criar seus próprios módulos.

Os módulos de nuvem anônimos são usados para automatizar tarefas

diferentes, como provisionamento de nuvem e automação de cargas de
trabalho. Ansible suporta diferentes nuvens públicas como o Azure.

Usando esses módulos e a linguagem Playbook, você pode provisionar e

gerenciar o ciclo de vida de uma máquina virtual no Microsoft Azure,
gerenciar serviços e recursos diferentes, como conjuntos de
disponibilidade, políticas de escalonamento automático, Azure Container
Service, DNS do Azure e aplicativos de função do Azure. , Balanceadores de
carga, discos e interfaces de rede do Azure.

Veja abaixo um exemplo de um manual que cria uma VM do Azure e

configura as credenciais do SSH.

- name: Create Azure VM

hosts: localhost
 connection: local

tasks:

- name: Create VM

azure_rm_virtualmachine:

resource_group: myResourceGroup

name: myVM

vm_size: Standard_GS5-8

admin_username: azureuser

ssh_password_enabled: false

ssh_public_keys:

- path: /home/azureuser/.ssh/authorized_keys

key_data: "ssh-rsa CCDDV2aZ...WXhad10h"

image:

offer: UbuntuServer

publisher: Canonical

sku: '16.04-LTS'

version: latest

Você pode adicionar outras configurações para sua VM no mesmo manual,

por exemplo: criar um grupo de segurança de rede que permita SSH, criar
uma placa de interface de rede virtual que use esse grupo de segurança e
conectar essa interface de rede à sua VM.

Saber mais

 Criar uma máquina virtual básica no Azure com Ansible

 Instalar e configurar o Ansible para gerenciar máquinas virtuais no Azure

 Gerenciamento de Configuração com
SaltStack
Salt (ou SaltStack) é um projeto de código aberto, e você pode ler e
modificar seu código-fonte sob a licença Apache. Seu código-fonte está
disponível no GitHub .

O Salt melhora a maneira como administradores, integradores e

desenvolvedores de sistemas configuram e gerenciam vários aspectos de
uma infraestrutura de datacenter, além de oferecer uma abordagem
diferente para algumas alternativas existentes.

O Salt é construído em uma plataforma que roda de forma relativamente

rápida, permitindo o controle remoto de infra-estruturas, códigos e dados
distribuídos. Uma camada de segurança é estabelecida ao ter comunicação
bidirecional entre os diferentes componentes da plataforma (Masters e
Minions, entre outros).

A infraestrutura que você pode gerenciar usando essa ferramenta pode ser
máquinas virtuais locais, infraestrutura de nuvem (como o Microsoft Azure),
contêineres (Docker, por exemplo) ou máquinas bare-metal. Você também
pode usar o Salt para gerenciar aplicativos hospedados e plataformas que
dependem de arquivos de configuração.

Você pode usar o Salt como uma ferramenta para gerenciar a

infraestrutura e a configuração como código e para automatizar as
ferramentas DevOps, pois ele automatiza o gerenciamento de código e
configuração de origem, tarefas orientadas por eventos e tarefas de
agendamento, bem como provisionamento de nuvem e contêineres.

Automatizar uma infraestrutura de nuvem, como o Azure, pode ser feito

conectando o Salt ao Azure, permitindo que os ambientes de teste e
produção sejam gerenciados usando o Salt CLI.

SaltStack tem quatro eixos principais:

 Execução remota

 Automação de configuração

 Controle da nuvem
 Orquestração orientada a eventos

A plataforma Salt vem com componentes diferentes, como Salt Masters,

Salt Minions, Top Files e Salt Cloud.

Usando Salt Cloud, você pode orquestrar sua infraestrutura do Azure

gerenciando serviços, como contas de armazenamento ou grupos de
afinidade, ou o Azure Resource Manager e recursos, incluindo VMs, discos,
redes virtuais de armazenamento de Blob ou certificados de serviço.

Quando você cria uma VM do Azure usando Salt, geralmente faz isso em
uma máquina remota em que o Salt Master está instalado. Para adicionar
uma nova VM do Azure com Minions instalados por padrão e gerenciada
pelo Salt Master, a maneira mais fácil é usar Salt Cloud.

Usando uma máquina virtual pré-configurada do VM Depot do Azure

ou do Azure Marketplace, você pode inscrever facilmente um Salt
Master no Azure e usar o Salt Cloud para criar VMs com configurações
predefinidas.
 Também é possível usar o Salt Formulas para reproduzir qualquer
configuração de VM, mantendo a documentação do que está instalado nas
suas VMs.

As fórmulas são estados de salt pré-gravados que você usa para várias
tarefas, como instalar, configurar e gerenciar um ciclo de vida de
serviço;gerenciamento de instalação de pacotes; administrar as contas dos
usuários e suas permissões; e muitas outras tarefas comuns.

Para orquestrar sua nuvem do Azure usando o Salt, você precisará do

Microsoft Azure SDK para Python, do Microsoft Azure Storage SDK para
Python e da biblioteca Solicitações do Python. Obviamente, você também
precisará ter o Salt instalado e uma conta do Azure.

Saber mais

 Provisione e configure sua infra-estrutura no Azure usando o SaltStack

Benefícios do Gerenciamento de
Configuração
Aqui estão cinco razões para gerenciar variações de configuração e
configurações de aplicativos por ambiente em uma ferramenta de
implantação:

1. Mais sustentável: você pode gerenciar variáveis e segredos em vários

níveis. As variáveis necessárias em muitas definições de liberação podem
ser armazenadas em um projeto. Você também pode definir variáveis de
configuração com escopo para uma definição de release específica ou para
um ambiente específico em uma definição de release.

2. Menos locais a serem atualizados: ao armazenar suas configurações de

configuração e aplicativo em uma ferramenta de implantação, se as
configurações forem alteradas em um determinado momento, você só
precisará atualizar as configurações na ferramenta de implantação e não
em todos os arquivos possíveis em que a configuração está
codificada . Além disso, ao armazená-los no escopo correto, você não
precisa atualizar todas as definições de release ou ambientes nos quais elas
são usadas.
3. Menos erros: Quando você armazena as configurações apropriadas para
cada ambiente no próprio ambiente na ferramenta de implantação, você
não apontará acidentalmente para a cadeia de conexão de
desenvolvimento quando estiver em produção. Os valores das
configurações são separados por ambiente, dificultando a mixagem ativa se
você estiver usando uma ferramenta de implantação.

4. Mais seguro: quando você tem strings de conexão, senhas ou quaisquer

outras configurações armazenadas em texto sem formatação em um
arquivo de configurações (como um arquivo web.config), qualquer pessoa
que tenha acesso ao código pode acessar um banco de dados ou uma
máquina. Uma ferramenta de implantação, como o Visual Studio Team
Services, fornece um modelo rico de permissões que controla quem pode
gerenciar e usar segredos em cada escopo.

5. Mais confiável: automatizando o processo de transformação de

configurações por meio de uma ferramenta de implantação, você poderá
contar com as transformações sempre ocorrendo durante uma
implantação e definindo os valores apropriados.

Se você já recebeu uma chamada de suporte de emergência no meio da

noite devido a um servidor com falha, você sabe a dificuldade de pesquisar
em várias planilhas ou até mesmo em sua memória para acessar as etapas
manuais de configuração de uma nova máquina. coçar, arranhão. Há
também uma dificuldade antiga: manter os ambientes de desenvolvimento
e produção consistentes. Uma maneira mais fácil de remover a
possibilidade de erro humano ao inicializar máquinas e tratar ambientes
como código, de modo que elas se mantenham a partir de uma única
definição consistente, é usar a infraestrutura como código.

Uma analogia comum para usar Infraestrutura como Código é a distinção

entre ter animais de estimação e gado. Quando você possui animais de
estimação, você lhes dá nomes, você os trata individualmente, e se algo de
ruim lhes acontece, você se importa muito. Se você tem um rebanho de
gado, você ainda pode nomeá-los, mas você os trata como um rebanho. Em
termos de infraestrutura, sem tratar os ambientes como código, pode
haver implicações graves se uma máquina falhar e você precisar substituí-la
(animais de estimação). Se você usar Infraestrutura como Código, se uma
máquina cair, você pode simplesmente rodar outra máquina sem
problemas (gado).
 Ao projetar scripts ou definições para Infraestrutura como Código (IaC), é
importante certificar-se de que o código e as ferramentas estejam
configurados para serem idempotentes ou capazes de executar várias vezes
sem erros e com consistência.

Infraestrutura como Código também pode ser configurada com a ajuda dos
desenvolvedores, pois muitas ferramentas oferecem a capacidade de
escrever código em linguagens de programação familiares, mesmo aquelas
tão simples quanto definições de JavaScript Object Notification
(JSON). Alguns exemplos de ferramentas comuns que você pode usar para
trabalhar com Infraestrutura como Código são Vagrant, Ansible, Puppet,
Chef, Docker, DSC do Microsoft Windows PowerShell e ferramentas
fornecidas pela nuvem, como modelos do Azure Resource Management.

A tabela a seguir lista as principais diferenças entre a implantação manual e

a infraestrutura como código:

Infraestrutura como Código com

Terraform
Terraform é uma ferramenta de código aberto como ferramenta de
código. Você pode usá-lo para definir um datacenter através da construção,
alteração e infra-estrutura de versionamento.

Terraform tem quatro características principais:

 Infraestrutura como Código

 Planos de Execução

 Gráfico de Recursos

 Automação de Mudanças

A ferramenta usa uma configuração de alto nível a partir da qual gera um

plano de execução descrevendo o que ele fará para atingir o estado
desejado e, em seguida, executa-o para criar a infraestrutura descrita.

Se esta configuração mudar, o Terraform é capaz de verificar o que mudou

e cria planos de execução incremental que podem ser aplicados.

Terraform constrói um gráfico de seus recursos e paraleliza a criação e

modificação de quaisquer recursos não dependentes. Ele suporta
infraestruturas internas personalizadas e provedores de nuvem populares,
como o Microsoft Azure. O Terraform pode gerenciar componentes de
baixo nível do Azure, como Armazenamento e Compute, e também
componentes de alto nível, como Grupos de Segurança ou Grupos de
Recursos.

Vamos dar o exemplo da criação de um grupo de recursos do Azure. Para

fazer isso, você deve começar criando um novo template Terraform
(main.tf):

resource "azurerm_resource_group" "my-terraform-group" {

name = "my-resource-group-name"

location = "West US"

Isto deve ser seguido pela inicialização de um diretório de trabalho

contendo arquivos de configuração do Terraform.

terraform init

Visualize os recursos a serem criados pelo modelo Terraform com:

terraform plan

Por fim, provisione os recursos do Azure com:

 terraform apply

Depois de aplicar essa alteração mais recente à sua infraestrutura do Azure,

o estado real da nova infraestrutura é armazenado em
um arquivoterraform.tfstate que foi criado após a primeira execução do
Terraform. Por padrão, o Terraform armazena o estado localmente em um
arquivo chamado terraform.tfstate .

O fato de esse arquivo estar armazenado localmente torna a colaboração

em um complexo de infraestrutura compartilhado, dados os conflitos de
mesclagem que podem resultar. Para permitir que uma equipe colabore
em uma infraestrutura compartilhada, um estado deve ser usado, e é por
isso que o Terraform permite o recurso de estado remoto. Isso é feito
configurando o Terraform para usar o Azure como back-end e o
Armazenamento de Blobs do Azure como uma ferramenta de
armazenamento.

Saber mais

 Instalar e configurar o Terraform para provisionar VMs e outras

infraestruturas no Azure

 Crie uma infraestrutura completa de máquinas virtuais do Linux no Azure

com o Terraform

Video: Environment Deployment

Usando efetivamente a infraestrutura

como código e configuração como código
Infraestrutura como Código (IaC) e configuração como código não são
processos mutuamente exclusivos. Em vez disso, os dois processos se
complementam e podem ser usados em conjunto. O termo configuração
como código não é usado amplamente e, em alguns casos, o IaC é usado
para descrever tanto o provisionamento quanto a configuração de
máquinas. Infraestrutura como Código também pode ser configuração
como código, mas geralmente não vice-versa.

Se você usar os dois processos separadamente, um princípio simples a ser

lembrado é que a Infraestrutura de Código se refere à criação e
fornecimento de máquinas, enquanto a configuração como código se refere
à configuração de componentes e software nas máquinas (como abertura
de portas e instalação de software).

Existem dois tipos de abordagens para Infraestrutura como

Código: declarativa (funcional) e imperativa (processual). A abordagem
declarativa declara qual deveria ser o estado final. Quando executado, o
script ou definição inicializará ou configurará a máquina para ter o estado
final que foi declarado. Na abordagem imperativa, o script afirma o ho w
para o estado final da máquina executando as etapas, a fim de chegar ao
estado acabado.

Existem dois métodos de configuração no IaC: push e pull . No método

pull, as máquinas configuradas puxarão a configuração de um servidor de
controle, como um servidor mestre. No método push, o servidor mestre ou
de controle enviará a configuração para as máquinas de destino.Algumas
organizações podem se beneficiar da infra-estrutura como estruturas de
código, como a Configuração de estado desejado do Windows PowerShell
(DSC).

Video: Database as Code

Video: IaaS/PaaS/Containers

Ambientes de Infraestrutura como

Serviço

Infraestrutura como serviço (IaaS) refere-se a uma infraestrutura de

computação instantânea que é provisionada e gerenciada pela Internet. O
IaaS ajuda você a evitar as despesas e a complexidade de comprar e
gerenciar seus próprios servidores físicos e outras infraestruturas de
datacenter. Cada recurso é oferecido como um componente de serviço
 separado e você só precisa alugar um por quanto tempo precisar. Um
provedor de serviços de computação em nuvem, como o Microsoft Azure,
gerencia a infraestrutura, enquanto você compra, instala, configura e
gerencia seu próprio software - sistemas operacionais, middleware e
aplicativos.

Decidir se escolher ambientes IaaS sobre a plataforma como um serviço

(PaaS) dependerá do tipo de aplicativo, dependências e arquitetura. É fácil
executar um levantamento e mudança (mover aplicativo de uma VM local
para uma VM hospedada) para seu aplicativo no IASS, e é muito provável
que seja a maneira mais rápida de colocar seu aplicativo na nuvem ou
hospedado em outro lugar. No entanto, embora seja fácil aumentar a
escala adicionando capacidade à máquina host, não é fácil dimensionar
para executar seu aplicativo em várias máquinas com IaaS.Os aplicativos
também ficam emaranhados com o sistema operacional, tornando a tarefa
de migrar aplicativos entre versões do sistema operacional (SO) muito
arriscada, sem testar completamente em uma nova versão do sistema
operacional.

Uma maneira de pensar em usar os ambientes de infraestrutura como

código e IaaS é considerar o dimensionamento de máquinas. Se você
precisar adicionar máquinas dimensionando para x , provavelmente
desejará usar a infraestrutura como código com ambientes IaaS.

O Azure IaaS fornece uma gama de opções para desenvolvedores que

desejam criar diretamente no sistema operacional:

 Máquinas virtuais. O Azure fornece uma ampla variedade de imagens do

sistema operacional Windows Server e Linux.

 Conjunto de Escala de Máquina Virtual . Os Conjuntos de Escala de

Máquina Virtual fornecem um mecanismo fácil de usar com base em sliders
para escalar grupos idênticos de máquinas virtuais sem estado.

 Serviço de Contêiner Azure. O Container Service é um serviço baseado em

código aberto que fornece implantação, orquestração e failover para
imagens baseadas no Docker em um cluster de máquinas virtuais, usando o
Apache Mesos, o Mesosphere's Marathon ou o Docker Swarm.

 Mercado do Azure . O Azure Marketplace inclui muitas plataformas de

aplicativos populares ou plataformas PaaS em imagens de máquinas
virtuais que você pode operar e gerenciar para você mesmo, incluindo o
Pivotal Cloud Foundry.
Para mais informações, consulte O que é IaaS?

Ambientes de plataforma como serviço

Plataforma como serviço (PaaS) refere-se a um ambiente completo de

desenvolvimento e implementação na nuvem, com recursos que permitem
que você forneça tudo, desde simples aplicativos baseados em nuvem até
aplicativos corporativos sofisticados habilitados para nuvem. Você compra
os recursos necessários de um provedor de serviços em nuvem, como o
Microsoft Azure, com base em repartição, e os acessa por meio de uma
conexão segura com a Internet.

Como o IaaS, o PaaS inclui infraestrutura - servidores, armazenamento e

rede -, mas também middleware, ferramentas de desenvolvimento, serviços
de business intelligence (BI), sistemas de gerenciamento de banco de dados
e muito mais. A PaaS foi projetada para suportar o ciclo de vida completo
do aplicativo da web: criar, testar, implementar, gerenciar e atualizar. Você
gerencia os aplicativos e serviços desenvolvidos e o provedor de serviços de
nuvem gerencia normalmente tudo o mais.

Decidir se escolher ambientes de PaaS sobre IaaS e contêineres depende

do tipo de aplicativo, dependências e arquitetura. Normalmente, se o
aplicativo é gravado em código mais recente, não depende da configuração
na máquina virtual ou é um aplicativo da Web, a PaaS é uma opção mais
viável. Com relação aos bancos de dados, a PaaS também pode ser possível
dependendo de como os bancos de dados são configurados no local.

Para alguns aplicativos, você ainda pode precisar executar o retrabalho

para que o aplicativo funcione com as soluções de PaaS (como
 armazenamento ou armazenamento em cache). A PaaS torna muito viável a
escalabilidade para várias máquinas, o que lhe dá vantagem sobre a IaaS.

Uma maneira de considerar o uso de ambientes de infraestrutura como

código e PaaS é identificar os requisitos de dimensionamento. Se você
precisar dimensionar sob demanda e o número de máquinas for menos
importante, use os ambientes de PaaS.

Os serviços da plataforma do Azure incluem as seguintes ofertas:

 Serviço de Aplicativo do Azure . Esse serviço permite que você crie os

seguintes tipos de aplicativos a partir de uma única experiência de
desenvolvimento: aplicativos da Web, aplicativos para dispositivos móveis,
aplicativos de API e aplicativos lógicos.

 Tecido de Serviço do Azure . Essa é uma plataforma de aplicativos de micro-

serviços madura e repleta de recursos com suporte embutido para
gerenciamento do ciclo de vida, desempenho com economia de estado e
sem estado em escala, implantações híbridas, disponibilidade 24x7 e
eficiência de custos.

 Serviços de nuvem do Azure . Este serviço é projetado para suportar

aplicativos escalonáveis, confiáveis e baratos de operar.

 Funções do Azure. Essa é uma experiência sem servidor, orientada a

eventos, que estende a plataforma existente do Azure PaaS com recursos
para implementar código acionado por eventos que ocorrem em outros
serviços do Azure, produtos SaaS e sistemas locais.

Para mais informações, consulte O que é PaaS?

PaaS vs. IaaS

O e-book O Guia do Desenvolvedor do Microsoft Azure usa uma analogia de
carro para diferenciar uma plataforma de desenvolvedor de uma
plataforma de infraestrutura.
Se você possui um carro, você tem que passar pelo processo de compra,
comprar seguro, manter e reparar o veículo por um longo período de
tempo, e fornecer estacionamento ou garagem. Se você está alugando um
carro, você obtém o benefício de um carro à sua disposição por um período
de tempo sem nenhuma sobrecarga de propriedade. E, é claro, usar um
serviço de compartilhamento de viagens como o Uber ou um táxi
provavelmente será a opção mais acessível, mas essas opções podem
limitar a flexibilidade. Você pode ter que esperar cinco minutos, ou
possivelmente se destacar na chuva esperando por uma carona.

Da mesma forma, você pode obter mais do seu escasso tempo de

desenvolvedor usando uma plataforma de aplicativos que elimina a
complexidade e a responsabilidade pela manutenção. Pode haver algumas
considerações de tradeoff em torno da flexibilidade, mas, no geral, você
pode fazer mais rapidamente e com menor custo total de propriedade
criando uma plataforma como serviço (PaaS).

Ambientes de contêiner
A computação mudou significativamente desde os dias em que apenas
máquinas físicas podiam ser usadas. Máquinas virtuais (VMs) abriram a
possibilidade de executar várias instâncias em uma máquina com
ambientes e aplicativos separados. Embora as VMs revolucionaram a
computação tradicional e a computação em nuvem, aplicativos ou
processos que exigem grandes quantidades de memória desafiam a ideia
de escalabilidade para máquinas.

Os contêineres também ajudam você a criar recursos isolados e

alocados. Ambas as tecnologias têm semelhanças, pois criam ambientes
isolados com controle de recursos separado (memória e CPU, por
exemplo). No entanto, os contêineres, ao contrário das VMs, não executam
um sistema operacional inteiro. Enquanto as VMs utilizam uma tecnologia
de virtualização de hardware, os contêineres virtualizam o sistema
operacional e compartilham o kernel da máquina host.

Usando contêineres, você pode empacotar um aplicativo com suas

dependências e configurações para executá-lo em diferentes ambientes
sem se preocupar com as camadas subjacentes do sistema operacional e
da infraestrutura. Isso permite a criação mais rápida de ambientes isolados,
bem como a flexibilidade de implantar e liberar instâncias do mesmo
contêiner.

Benefícios múltiplos

Os contêineres de aplicativos são ideais para o desenvolvimento e o teste

de aplicativos, pois têm a combinação de inicialização instantânea, que vem
da virtualização do SO e da execução confiável, que vem do isolamento e da
governança de recursos.

Os contêineres também permitem que os desenvolvedores façam iterações

rapidamente em um projeto de desenvolvimento, porque o uso de recursos
e ambiente é consistente em todos os sistemas. Um aplicativo em contêiner
que funciona na máquina de um desenvolvedor funcionará da mesma
maneira em um sistema de produção.

O início instantâneo e um pequeno espaço também beneficiam cenários de

nuvem; os aplicativos podem ser dimensionados rapidamente e muitas
outras instâncias de aplicativos podem caber em uma máquina do que se
estivessem em uma máquina virtual. Isso maximiza a utilização de recursos.

Com a Infraestrutura como Código e processos e ferramentas de

gerenciamento de configuração, você pode provisionar seu ambiente de
produção para um contêiner e implantá-lo em qualquer lugar.

O Docker é uma tecnologia de contêiner de aplicativo que você pode usar

para criar e montar uma imagem fornecendo instruções e comandos em
um Dockerfile (um arquivo de texto simples).

Assista a um tutorial sobre contêineres: Containers 101 com Microsoft e

Docker .
Orquestração de Contêineres
Um contêiner de aplicativos é o pacote que inclui o aplicativo, suas
dependências, ferramentas / bibliotecas do sistema e o tempo de
execução.Para automatizar a implantação, dimensionar e gerenciar seus
contêineres em escala, no entanto, você precisa de uma ferramenta de
orquestração.

As tecnologias de orquestração ajudam você a gerenciar recursos

agrupados e cargas de trabalho de vários contêineres, dimensionando um
aplicativo como se estivesse sendo executado em um único e enorme
computador. Por exemplo, o Docker Swarm possui recursos de clustering
que transformam um grupo de Docker Engines em um único Docker Engine
virtual.

Algumas das tecnologias de orquestração mais conhecidas são o

Kubernetes, o Docker Swarm e o Marathon. Essas tecnologias têm recursos
comuns, como provisionamento, descoberta de serviço, verificações de
integridade e configurações declarativas. Cada uma dessas tecnologias
também tem diferenças porque cada uma delas tem sua própria filosofia,
casos de uso e arquitetura.

Orquestração de contêineres - Enxame Docker

O Docker Swarm é uma tecnologia de orquestração nativa do Docker criada

pelo Docker. Ele usa a API Docker padrão e a rede, e tem uma abordagem
direta para a configuração. Gerentes e trabalhadores são os dois principais
componentes de um cluster Swarm. O gerente orquestrará os contêineres
nos hosts que formam o cluster.

O Docker Swarm é centrado no Docker e não funciona com outras

tecnologias de conteinerização (por exemplo, rkt). Usuários que já
trabalham com o Docker acharão simples configurar e gerenciar.

Orquestração de contêineres - Kubernetes

O Kubernetes é descrito como um sistema de código aberto para

automatizar a implantação, o dimensionamento e o gerenciamento de
aplicativos em contêiner. Ele agrupa contêineres que compõem um
aplicativo em unidades lógicas para facilitar o gerenciamento e a
descoberta.O Kubernetes se baseia em 15 anos de experiência com a
execução de cargas de trabalho de produção no Google.

O Kubernetes suporta Docker e rkt e consiste em Pods, Controladores de

Replicação, Conjuntos de Réplicas, Serviços e Implantações. Ele possui
recursos avançados, como interface com provedores externos de
balanceamento de carga (como o Microsoft Azure Load Balancer), ajuste
automático de escala e autorrecuperação.

Orquestração de contêineres - Maratona de Mesos

O Apache Mesos é um gerenciador de cluster de código aberto descrito

como um kernel de sistemas distribuídos. Ele é construído usando os
mesmos princípios do kernel do Linux, em um nível diferente de
abstração. Essa tecnologia abstrai os recursos de computação (CPU e
memória, armazenamento) das máquinas físicas e virtuais, permitindo,
assim, sistemas distribuídos tolerantes a falhas e elásticos.

O Marathon é uma plataforma de orquestração de contêineres para o

sistema operacional Datacenter da Mesosphere (DC / OS) e o Apache
Mesos. Ele possui recursos avançados, como suporte a implantações de
tempo de inatividade zero, incluindo padrões de rolagem, azul-verde e
canário

Serviço de Contêiner Azure

O Microsoft Azure Container Service torna mais simples a criação,
configuração e gerenciamento de um cluster de máquinas virtuais pré-
configuradas para executar aplicativos em contêiner. Ele usa uma
configuração otimizada de ferramentas populares de agendamento e
orquestração de código aberto. Isso permite que você use suas habilidades
existentes ou conte com um grande e crescente corpo de conhecimento da
comunidade para implantar e gerenciar aplicativos baseados em contêiner
no Microsoft Azure.
O Serviço de Contêiner do Azure aproveita o formato do contêiner do
Docker para garantir que seus contêineres de aplicativos sejam totalmente
portáteis. Ele também suporta sua escolha de Marathon e DC / OS, Docker
Swarm ou Kubernetes para que você possa dimensionar esses aplicativos
para milhares de contêineres ou até mesmo dezenas de milhares.

Usando o Azure Container Service, você pode aproveitar os recursos de

nível corporativo do Azure, mantendo a portabilidade do aplicativo,
incluindo a portabilidade nas camadas de orquestração.

O Azure Container Service pode se integrar a diferentes registros de

contêiner, incluindo o Azure Container Registry. Esse serviço permite que
você armazene imagens para diferentes tipos de implantações de
contêiner, como Swarm, DC / OS e Kubernetes e serviços do Azure, como
App Service, Batch e Service Fabric.

O AKS, ou Serviço de Contêiner do Azure, é um novo serviço gerenciado do

Kubernetes que fornece recursos adicionais, como autenticação baseada
no Azure Active Directory, suporte a webhook e operações de exclusão.
 A criação de um cluster gerenciado do Kubernetes poderia ser feita usando
o CLI:

az aks create --resource-group myResourceGroup --name

myCluster --node-count <number_of_nodes> --generate-ssh-
keys

Os contêineres agora são suportados no Azure Service Fabric .

Saber mais
Para obter mais informações, consulte Visão geral do Service Fabric e
Containers .

Veja também:

 Introdução ao Azure Container Service (AKS)

 Implantar um cluster do Serviço de Contêiner do Azure (AKS)

 Episódio 198 do Cloud Cover: Serviço de Contêiner Azure com Ross Gardler

Gerenciador de recursos do Azure

O Microsoft Azure Resource Manager permite implantar, atualizar ou

excluir recursos para sua solução em nuvem em uma única operação
coordenada. Os recursos podem incluir máquinas virtuais, contas de
armazenamento, redes virtuais, serviços ou qualquer componente que você
esteja gerenciando.

Por que usar o Azure Resource Manager?

 Você pode implantar, gerenciar e monitorar todos os recursos da sua
solução como um grupo, conhecido como grupo de recursos , em vez de
manipular esses recursos individualmente.

 Você pode implantar sua solução repetidamente durante todo o ciclo de

vida de desenvolvimento e ter certeza de que seus recursos são
implementados em um estado consistente.

 Você pode usar modelos declarativos para definir sua implantação.

 Você pode definir as dependências entre os recursos para que eles sejam
implementados na ordem correta.

 Você pode aplicar o controle de acesso a todos os serviços em seu grupo de

recursos porque o RBAC (Role-Based Access Control) é integrado
nativamente à plataforma de gerenciamento.

 Você pode aplicar tags a recursos para organizar logicamente todos os

recursos da sua assinatura.

 Você pode esclarecer o faturamento da sua organização visualizando os

custos acumulados de todo o grupo ou de um grupo de recursos que
compartilham a mesma tag.

Observação: o modelo de implantação do Azure Resource Manager

contém diferenças importantes do modelo de implantação clássico e os
dois modelos não são totalmente compatíveis entre si. Para simplificar a
implantação e o gerenciamento de recursos, a Microsoft recomenda o uso
do Gerenciador de recursos para novos recursos.

Gerenciador de recursos do Azure

O Microsoft Azure Resource Manager permite implantar, atualizar ou

excluir recursos para sua solução em nuvem em uma única operação
coordenada. Os recursos podem incluir máquinas virtuais, contas de
armazenamento, redes virtuais, serviços ou qualquer componente que você
esteja gerenciando.
 Por que usar o Azure Resource Manager?

 Você pode implantar, gerenciar e monitorar todos os recursos da sua

solução como um grupo, conhecido como grupo de recursos , em vez de
manipular esses recursos individualmente.

 Você pode implantar sua solução repetidamente durante todo o ciclo de

vida de desenvolvimento e ter certeza de que seus recursos são
implementados em um estado consistente.

 Você pode usar modelos declarativos para definir sua implantação.

 Você pode definir as dependências entre os recursos para que eles sejam
implementados na ordem correta.

 Você pode aplicar o controle de acesso a todos os serviços em seu grupo de

recursos porque o RBAC (Role-Based Access Control) é integrado
nativamente à plataforma de gerenciamento.

 Você pode aplicar tags a recursos para organizar logicamente todos os

recursos da sua assinatura.

 Você pode esclarecer o faturamento da sua organização visualizando os

custos acumulados de todo o grupo ou de um grupo de recursos que
compartilham a mesma tag.

Observação: o modelo de implantação do Azure Resource Manager

contém diferenças importantes do modelo de implantação clássico e os
dois modelos não são totalmente compatíveis entre si. Para simplificar a
implantação e o gerenciamento de recursos, a Microsoft recomenda o uso
do Gerenciador de recursos para novos recursos.

Grupos de Recursos do Azure

O que são grupos de recursos?

Um grupo de recursos do Microsoft Azure é um contêiner que contém
recursos relacionados para um aplicativo. O grupo de recursos pode incluir
todos os recursos de um aplicativo ou apenas os recursos agrupados
logicamente. Você pode decidir como deseja alocar recursos para grupos
de recursos com base no que faz mais sentido para sua organização.
 Existem alguns fatores importantes a serem considerados ao definir seu
grupo de recursos:

 Todos os recursos do seu grupo devem compartilhar o mesmo ciclo de

vida. Você implantará, atualizará e excluirá os dois juntos. Se um recurso,
como um servidor de banco de dados, precisar existir em um ciclo de
implementação diferente, ele deverá estar em outro grupo de recursos.

 Cada recurso pode existir apenas em um grupo de recursos por vez.

 Você pode adicionar ou remover um recurso a um grupo de recursos a

qualquer momento.

 Você pode mover um recurso de um grupo de recursos para outro grupo.

 Um grupo de recursos pode conter recursos que residem em diferentes

regiões.

 Um grupo de recursos pode ser usado para controlar o controle de acesso

para ações administrativas.

 Um recurso pode ser vinculado a um recurso em outro grupo de recursos

quando os dois recursos precisam interagir entre si, mas eles não
compartilham o mesmo ciclo de vida (por exemplo, vários aplicativos se
conectando a um banco de dados).
Tags

O que são tags?

As tags permitem que você organize logicamente seus recursos. Somente

recursos criados por meio de tags de suporte do Microsoft Azure Resource
Manager. Você não pode aplicar tags a recursos clássicos.

O Resource Manager permite organizar logicamente recursos aplicando

tags. As tags consistem em pares de chave / valor que identificam recursos
com propriedades que você define. Exemplos de pares de chave / valor
incluem:

departamento: Contabilidade

ambiente: teste
Quando você visualiza recursos com uma tag específica, você vê recursos
de todos os seus grupos de recursos. Você não está limitado apenas aos
recursos que estão no mesmo grupo de recursos. Isso permite organizar
seus recursos de maneira independente dos relacionamentos de
implantação. As tags podem ser particularmente úteis quando você precisa
organizar recursos para faturamento ou gerenciamento.

Cada recurso ou grupo de recursos pode ter no máximo 15 tags. O nome

da tag está limitado a 512 caracteres e o valor da tag está limitado a 256
caracteres. Para marcar recursos como pertencentes à mesma categoria,
aplique a mesma tag a esses recursos.

Para obter mais informações sobre como usar tags, consulte Usar tags para
organizar seus recursos do Azure .

Controle de acesso
O Gerenciador de recursos permite controlar quem tem acesso a ações
específicas para sua organização. Ele integra nativamente o controle de
acesso baseado em função (RBAC) na plataforma de gerenciamento e aplica
esse controle de acesso a todos os serviços em seu grupo de recursos. Você
pode adicionar usuários a funções predefinidas específicas de plataforma e
recurso e aplicar essas funções a uma assinatura, grupo de recursos ou
outro recurso para limitar o acesso. Por exemplo, você pode aproveitar a
função predefinida denominada Leitor, que permite aos usuários visualizar
recursos, mas não editá-los. Você adiciona usuários em sua organização
que exigem acesso à função de Leitor e aplica a função à assinatura, ao
grupo de recursos ou ao recurso. Outras funções de plataforma
incluem Proprietário , ColaboradoreAdministrador de acesso do
usuário .

Saber mais
Para obter a lista completa de funções e ações permitidas, consulte RBAC:
Funções internas . Para obter mais informações sobre o Controle de Acesso
Baseado em Função, consulte Controle de Acesso Baseado em Função do
Azure .

Estrutura de modelo do Azure Resource

Manager
Um modelo do Azure Resource Manager consiste em JSON e expressões
que você pode usar para construir valores para sua implantação. Você deve
limitar o tamanho do modelo a 1 megabyte (MB) e cada arquivo de
parâmetro a 64 kilobytes (KB.) O limite de 1 MB aplica-se ao estado final do
modelo após ter sido expandido com definições de recursos iterativas e
valores para variáveis e parâmetros.

Em sua estrutura mais simples, um modelo contém os seguintes

elementos:
 {

"$schema":
"http://schema.management.azure.com/schemas/2015-01-01/depl
oymentTemplate.json#",

"contentVersion": "",

"parameters": { },

"variables": { },

"resources": [ ],

"outputs": { }

 $schema:O local do arquivo de esquema JSON que descreve a versão do

idioma do modelo.

 contentVersion: A versão do modelo (como 1.0.0.0).

 parameters:Os valores opcionais fornecidos quando a implementação é

executada para personalizar a implantação de recursos.

 variables: Os valores usados como fragmentos JSON no modelo para

simplificar expressões de linguagem de modelo.

 resources: Um item gerenciável que está disponível no Azure. Alguns

recursos comuns são uma máquina virtual, uma conta de armazenamento,
um aplicativo da Web, um banco de dados e uma rede virtual, mas há
muitos mais.

 outputs: Os valores retornados após a implantação

 Modelos de início rápido do Azure no

GitHub
 Você pode usar o GitHub como outro recurso para criar e implantar
soluções no Azure. Este repositório contém todos
os modelos disponíveis atualmente do Azure Resource
Manager contribuídos pela comunidade. Há um índice de modelo
pesquisável, um guia de contribuição, uma lista de práticas
recomendadas de modelo e um tutorial de uso do Git.
 

 Para obter mais informações, consulte Modelos de início rápido do

Azure .

Video: Azure Resource Manager Templates

Video: Automation DSC

Demo: Automation DSC