Original

Segunda Edição
Iain Foulds
CONHECER O
AZURE NUM MÊS
DE ALMOÇOS
<br /> }*
///////// #
Obtenha ajuda para
o seu projeto.
Fale com um especial-
ista de vendas >
startHere(Azure);
Aprofunde 21 Obtenha uma base sólida em Azure com as lições

neste e-book. Inscreva-se para uma conta gratuita
lições do Azure do Azure e use o seu crédito de 200 USD para

concluir os exercícios. Continue com a sua conta
e obtenha 12 meses de serviços gratuitos populares
e + de 25 serviços sempre gratuitos.
Comece gratuitamente
POUPE 40% EM LIVROS E VÍDEOS DA MANNING!
A Manning publica livros e vídeos de alta qualidade para profissionais de tecnologia como você. Utilize este código de
desconto especial para poupar 40% em todos os cursos de e-books, p-books, MEAPs e liveVideo em manning.com, ,
incluindo estes títulos selecionados. Basta introduzir azuremsft2 na caixa Código Promocional quando concluir a compra.
Conhecer o Windows PowerShell num mês de almoços Conhecer Docker num mês de almoços
Por Don Jones e Jeffery Hicks Elton Stoneman
dezembro de 2016, 384 páginas Verão 2020, 530 páginas
Mais livros com aprendizagem durante os almoços de um mês

Conhecer o Windows PowerShell num mês de almoços, Terceira Edição
Conhecer Docker num mês de almoços
Conhecer dbatools num mês de almoços
Conhecer o PowerShell num mês de almoços, Edição Linux e macOS
Aprenda a utilizar o PowerShell Scripting durante os almoços de um mês
Aprenda a utilizar o Linux durante os almoços de um mês
Aprenda a utilizar o Amazon Web Services durante os almoços de um mês
Aprenda a utilizar o Cisco Network Administration durante os almoços de um mês
Livros para programadores e profissionais de TI da Microsoft
Engenharia de Dados do Azure ASP.NET Core em Ação Core Kubernetes
Princípios, Práticas e Padrões de Entity Framework Core em ação GitOps e Kubernetes
Injeção de Dependência C# em Detalhe, Quarta Edição Docker em Ação, Segunda Edição
Microsserviços no .NET Core Programação Funcional em C# Docker na Prática,
.NET Core em Ação Kubernetes em Ação Segunda Edição
Segurança de microsserviços Knative em ação Docker em Movimento
em ação Bootstrapping Microservices OpenShift em Ação
Simultaneidade no .NET com Docker, Kubernetes
Aplicações reativas com o Akka.NET Padrões nativos da cloud
e Terraform
Ler livros da Manning GRATUITAMENTE no liveBook

A plataforma liveBook da Manning oferece uma experiência de leitura online confortável e flexível.
Tem acesso total GRATUITO durante cinco minutos por dia a cada livro da Manning. No liveBook pode:
• Fazer perguntas, partilhar código e exemplos e interagir com outros leitores no fórum do liveBook.
• Fazer pesquisas de texto completo em todos os livros da Manning, até mesmo nos que não possui.
• Registe-se para obter uma conta GRATUITA no LiveBook em livebook.manning.com.

Pode utilizar os seus cinco minutos GRATUITOS da forma que quiser – iniciar e parar o temporizador,
alternar entre livros e tentar os exercícios interativos. Basta iniciar sessão e explorar sem riscos.
Elogios à primeira edição
Da primeira edição do Conhecer o Azure num mês de almoços de Iain Foulds:
"Um livro incrível e repleto de informações para aprender conceitos core e avançados do Azure num mês!"
—Sushil Sharma, Galvanize
"O Microsoft Azure está rapidamente a tornar-se líder no espaço público da cloud. Seguir os exercícios
neste livro vai rapidamente pô-lo a par desta tecnologia."
—Michael Bright, Developer Advocate, consultor freelancer
"Excelente introdução ao Azure com muitos exemplos práticos. Abrange uma ampla gama de tópicos
atuais."
—Sven Stumpf, ING-DiBa AG
"O Azure é como um oceano. Este livro mantém-no à tona, proporcionando a melhor forma de aprender
em forma de almoços ricos em exercícios e exemplos práticos."
—Roman Levchenko, Microsoft MVP
"Qualquer programador ocupado precisa de conhecer o Azure."

—Rob Loranger, programador freelancer
"Uma ótima forma de entender a amplitude das ofertas do Azure, seguindo uma abordagem concisa
e focada em atividades."
—Dave Corun, Avanade
"O livro mais abrangente sobre o Azure que encontrei para começar a desenvolver os meus projetos
académicos!"
—Marco Giuseppe Salafia, estudante de doutoramento, Università degli Studi di Catania
"Este é o livro para a plataforma Azure. Está muito bem organizado, é minucioso e abrangente. A partir
de conceitos básicos, orienta o leitor através da criação de configurações cada vez mais complexas com
a plataforma do Azure para proporcionar escalabilidade, alto desempenho e redundância para
aplicações e serviços alojados. Este livro serve tanto como tutorial para o principiante e como uma referên-
cia para o utilizador mais experiente."
—Robert Walsh, Excalibur Solutions
Conhecer o Azure
num mês de almoços
Segunda Edição
IAIN FOULDS
MANNING
Shelter Island
Para obter informações online e fazer pedidos desse e de outros livros da Manning, aceda a
www.manning.com. A editora oferece desconto neste livro quando pedido em quantidade.
Para obter mais informações, contacte
Departamento de vendas especiais
Manning Publications Co.
20 Baldwin Road
PO Box 761
Shelter Island, NY 11964
E-mail: orders@manning.com
©2020 pela Manning Publications Co. Todos os direitos reservados.
Nenhuma parte desta publicação pode ser reproduzida, armazenada num sistema de recuperação ou
transmitida, de qualquer forma ou por meio eletrónico, mecânico, fotocópia ou outro, sem permissão
prévia por escrito da editora.
Muitas das designações utilizadas pelos fabricantes e vendedores para distinguir os seus produtos são
reivindicadas como marcas registadas. Quando essas designações aparecerem no livro, e a Manning
Publications estiver ciente de uma reivindicação de marca registada, as designações serão impressas
com as iniciais em letras maiúsculas ou totalmente em letras maiúsculas.
Reconhecendo a importância de preservação do que foi escrito, é política da Manning imprimir os

livros que publicamos em papel alcalino e empenhamos todos os nossos esforços nisso. Reconhecendo
também a nossa responsabilidade de conservação dos recursos do nosso planeta, os livros da Manning
são impressos num tipo de papel que é pelo menos 15% reciclado e processado sem a utilização de
cloro elementar.
Manning Publications Co. Editor de aquisições: Mike Stephens

20 Baldwin Road Editor de desenvolvimento: Frances Lefkowitz
PO Box 761 Editor de desenvolvimento técnico: Karsten Strøbaek
Shelter Island, NY 11964 Editor de revisão: Aleksandar Dragosavljevic
Produção editorial: António Calcara
Editor gráfico: Jennifer Houle
Editores de cópia: Kathy Simpson
Revisor: Katie Tennant
Revisor técnico: Karsten Strøbaek
Tipógrafo: Marija Tudor
Designer de capa: Leslie Haimes
ISBN 9781617297625
Impresso nos Estados Unidos da América
Para as pessoas mais importantes da minha vida:
Abigail, Bethany e Charlotte
índice
prefácio xv
agradecimentos xvi
sobre este livro xvii
sobre o autor xxi
Parte 1 Serviços core do Azure..................................1

1 Antes de começar 3
1.1 Este livro é para si? 3
1.2 Como utilizar este livro 4
Os principais capítulos 4 Experimente agora 5 Laboratórios
■ ■
práticos 5 Código fonte e materiais suplementares 5

■
1.3 Criar o seu ambiente de laboratório 5

Criar uma conta Azure gratuita 5 Exercício de laboratório
■
bónus: criação de uma conta do GitHub gratuita 7

1.4 Uma pequena ajuda 7
1.5 Compreender a plataforma do Azure 8
Virtualização em Azure 10 Ferramentas de gestão 11
■
2 Criar uma virtual machine 14

2.1 Noções básicas das configurações de virtual machine 15
Regiões e opções de disponibilidade 15 Imagens de VM 16
■
Tamanhos de VM 17 Azure Storage 18 Redes virtuais 19

■ ■
vii
viii índice
2.2 Criação de um par de chaves SSH para autenticação 20

2.3 Criar uma VM a partir do seu browser 22
2.4 Ligação à VM e instalação do servidor Web 24
Ligar à VM com SSH 24 Instalar o servidor Web 26
■
2.5 Permitir que o tráfego Web chegue à VM 27

Criar uma regra para permitir o tráfego Web 28
Ver o servidor Web em ação 28
■
2.6 Laboratório: criar uma VM Windows 29

2.7 Limpar os recursos 30
2.8 Houston, temos um problema 31
3 Azure Web Apps 33

3.1 Descrição geral e conceitos do Azure Web Apps 34
Linguagens e ambientes suportados 34 Testes de diferentes
■
versões com blocos de implementação 35 Planos de serviço de

■
aplicações 35
3.2 Criar uma aplicação Web 37
Criar uma aplicação Web básica 37 Implementar um site
■
HTML de exemplo 39
3.3 Ver registos de diagnóstico 42
3.4 Laboratório: criar e utilizar um bloco de implementação 44
4 Introdução ao Azure Storage

4.1 Discos Geridos 47
47
Discos do SO 48 Discos temporários e discos de dados 49

■
Opções de colocação de discos em cache 50

■
4.2 Adicionar discos a uma VM 50

4.3 Azure Storage 52
Armazenamento de tabelas 53 Armazenamento de filas 55
■
Disponibilidade e redundância de armazenamento 56

■
4.4 Laboratório: Explorar o Azure Storage 57

Focado na VM 57 Focado no programador 57
■
5 Noções básicas do Azure Networking 58

5.1 Componentes de rede virtual 58
Redes virtuais e sub-redes 59 Placas de interface de rede
■
virtual 61 Endereço IP público e resolução de DNS 62

■
5.2 Proteger e controlar o tráfego com grupos de segurança

de rede 64
índice ix
Criar um grupo de segurança de rede 64 Associar um grupo de

■
segurança de rede a uma sub-rede 66 Criar regras de filtragem de

■
grupos de segurança de rede 67

5.3 Criar uma aplicação Web de exemplo com tráfego seguro 68
Criar ligações de rede de acesso remoto 68 Criar ■
VMs 69 Utilizar o agente SSH para se ligar às suas VMs 71

■
5.4 Laboratório: instalar e testar o servidor Web LAMP 72
Parte 2 Elevada disponibilidade

e dimensionamento........................................73
6 Azure Resource Manager 75
6.1 A abordagem do Azure Resource Manager 75
Conceber em torno do ciclo de vida da aplicação 76 Proteger ■
e controlar recursos 78 Proteger recursos com bloqueios 79

■
■
Gerir e agrupar recursos com etiquetas 80
6.2 Modelos do Azure Resource Manager 81
Criar e utilizar modelos 82 Criar múltiplos de um tipo
■
de recurso 84 Ferramentas para criar os seus próprios

■
modelos 85 Armazenar e utilizar modelos 87

■
6.3 Laboratório: implementar recursos do Azure a partir de

um modelo 87
7
Elevada disponibilidade e redundância
7.1 A necessidade da redundância 90
90
7.2 Redundância de infraestrutura com Zonas de

Disponibilidade 92
Criar recursos de rede numa Zona de Disponibilidade 94
■
Criar VMs numa Zona de Disponibilidade 95
7.3 Redundância de VMs com Conjuntos de Disponibilidade 96
Domínios de falha 96 Domínios de atualização 97 Distribuir
■ ■
VMs por um Conjunto de Disponibilidade 97 Ver a distribuição de

■
VMs por um Conjunto de Disponibilidade 100

7.4 Laboratório: implementar VMs altamente disponíveis a
partir de um modelo 102
8 Aplicações de balanceamento de carga 106

8.1 Componentes do balanceador de carga do Azure 106
Criar um conjunto IP de front-end 108 Criar e configurar sondagens
■
do estado de funcionamento 110 Definir a distribuição de tráfego com

■
regras do balanceador de carga 112 Encaminhar o tráfego direto com

■
regras de Tradução de Endereços de Rede 114 Atribuir grupos de VMs

■
a conjuntos de back-end 116

x índice
8.2 Criar e configurar VMs com o balanceador de carga 119

8.3 Laboratório: ver modelos de implementações
existentes 122
9 Aplicações dimensionáveis 124

9.1 Por que criar aplicações dimensionáveis e fiáveis? 124
Dimensionar VMs verticalmente 125 Dimensionar
■
aplicações Web verticalmente 127 Dimensionar recursos

■
horizontalmente 128
9.2 Conjuntos de dimensionamento de virtual machines 129
Criar um conjunto de dimensionamento de virtual machines 131
Criar regras de dimensionamento automático 133
■
9.3 Dimensionar uma aplicação Web 137

9.4 Laboratório: instalar aplicações no seu conjunto de
dimensionamento ou aplicação Web 139
Conjuntos de dimensionamento de virtual machines 139
Aplicações Web 140
■
10 Bases de dados globais com Cosmos DB

10.1 O que é o Cosmos DB? 141
141
Bases de dados estruturadas (SQL) 142 Bases de dados

■
não estruturadas (NoSQL) 142 Dimensionar bases de

■
dados 143 Como reunir tudo com o Cosmos DB 144

■
10.2 Criar uma conta e uma base de dados Cosmos DB 145
Criar e preencher uma base de dados Cosmos DB 145 Adicionar
■
redundância global a uma base de dados Cosmos DB 149

0.3 Aceder aos dados distribuídos globalmente 152
1
10.4 Laboratório: implementar uma aplicação Web que utiliza
o Cosmos DB 156
11 Gerir o tráfego e o encaminhamento de rede

11.1 O que é o DNS do Azure? 158
158
1.2 Delegar um domínio real ao DNS do Azure 160

1
11.3 Encaminhamento global e resolução com o Traffic
Manager 162
Criar perfis do Traffic Manager 164 Distribuição global de
■
tráfego para a instância mais próxima 167

11.4 Laboratório: implementar aplicações Web para ver
o Traffic Manager em ação 174
índice xi
12 Monitorizção e resolução de problemas 175

12.1 Diagnóstico de arranque de VMs 175
12.2 Métricas de desempenho e alertas 178
Ver métricas de desempenho com a extensão de diagnóstico da
VM 178 Criar alertas para condições de desempenho 181
■
12.3 Observador de Rede do Azure 182

Verificar os fluxos de IP 183 Ver regras do NSG efetivas 184
■
Capturar pacotes de rede 186

■
12.4 Laboratório: criar alertas de desempenho 188
Parte 3 Seguro por predefinição............................ 189
13 Cópia de segurança, recuperação e replicação

13.1 Azure Backup 191
191
Políticas e retenção 193 Agendas de cópia de segurança 196

■
Restaurar uma VM 198

■
3.2 Azure Site Recovery 201

1
13.3 Laboratório: configurar uma VM para Site Recovery 204
14 Encriptação de dados 206

14.1 O que é a encriptação de dados? 206
4.2 Encriptação inativa 208
1
14.3 Encriptação do Serviço de Armazenamento 209
14.4 Encriptação de VMs 211
Armazenar chaves de encriptação no Azure Key
Vault 211 Encriptar uma VM do Azure 213
■
14.5 Laboratório: encriptar uma VM 214
15 Proteger informações com o Azure Key Vault

15.1 Proteger informações na cloud 216
216
Cofres de software e módulos de segurança de hardware 217

Criar um cofre de chaves e segredo 219
■
5.2
1 Identidades geridas para recursos do Azure 221
15.3 Obter um segredo de uma VM com identidade gerida 224
15.4 Criar e injetar certificados 230
15.5 Laboratório: configurar um servidor Web seguro 233
xii índice
16 Centro de Segurança do Azure e atualizações

16.1 Centro de Segurança do Azure 234
234
6.2 Acesso just-in-time 237

1
16.3 Gestão de Atualizações do Azure 241
Serviços de gestão do Azure combinados 243 Analisar e aplicar
■
atualizações 245
16.4 Laboratório: ativar o JIT e atualizações para uma VM
Windows 249
Parte 4 O fantástico................................................ 251
17 Machine learning e inteligência artificial 253

17.1 Descrição geral e relação entre IA e ML 254
Inteligência artificial 254 Machine learning 255
■
■
União da IA e do ML 256 Ferramentas de ML do Azure para
■
cientistas de dados 257

7.2 Azure Cognitive Services 259
1
17.3 Criar um bot inteligente para ajudar com pedidos de
pizza 260
Criar um bot da aplicação Web no Azure 260 Linguagem
■
e compreensão de intenções com LUIS 261 Criar e executar

■
um bot da aplicação Web com LUIS 264

17.4 Laboratório: adicionar canais para comunicação com
o bot 267
18 Azure Automation 269

18.1 O que é o Azure Automation? 269
Criar uma conta de Automation do Azure 271 Ativos e runbooks
■
de Automation do Azure 272

18.2 Runbook de exemplo de Automation do Azure 274
Executar e ver a saída de um runbook de exemplo 276
18.3 PowerShell Desired State Configuration (DSC) 278
Definir e utilizar o PowerShell DSC, bem como um servidor pull de
Automation do Azure 280
18.4 Laboratório: utilizar o DSC com Linux 282

índice xiii
19 Containers do Azure 284

19.1 O que são containers? 284
19.2 A abordagem de microsserviços para aplicações 287
9.3 Azure Container Instances 289
1
19.4 Azure Kubernetes Service 293
Criar um cluster com o Azure Kubernetes Services 294
Executar um site básico no Kubernetes 295
■
19.5 Laboratório: dimensionar as suas implementações do

Kubernetes 298
20 O 2Azure e a Internet of Things 300

0.1 O que é a Internet of Things? 300
0.2 Gerir centralmente os dispositivos com o Azure IoT Hub 303
2
20.3 Criar um dispositivo Raspberry Pi simulado 306
20.4 Transmitir dados do Azure IoT Hub às aplicações Web do
Azure 309
20.5 Análise dos componentes IoT do Azure 315
20.6 Laboratório: explorar casos práticos para IoT 316
21 Computação sem servidor 317

21.1 O que é a computação sem servidor? 317
21.2 Plataformas de mensagens do Azure 319
Grelha de Eventos do Azure 320 Event Hubs do Azure e Service
■
Bus 321 Criar um service bus e integrá-lo num IoT Hub 322

■
1.3 Criação de uma aplicação lógica do Azure 325

2
21.4 Criação de uma aplicação de função do Azure para
analisar dados do dispositivo IoT 328
21.5 Não pare de aprender 332
Materiais de aprendizagem adicionais 333 Recursos do
■
GitHub 333 Uma reflexão final 333

■
índice 335
prefácio
Esta segunda edição do Conhecer o Azure num mês de almoços lembra-me que tudo
muda rapidamente e que tens de continuar sempre a aprender. Longe vai o tempo em
que se podia fazer um curso de uma semana no Windows Server e executá-lo confor-
tavelmente durante anos sem grandes mudanças. Isto não significa que o mundo das
TI seja um lugar mais assustador, mas é preciso abordar o cloud computing com uma
mente aberta e estar disposto a ajustar-se constantemente.
Quando comecei a trabalhar com o Azure, o número de serviços disponíveis era
quase assustador. Eu sabia que devia prestar atenção à segurança, ao desempenho, à
redundância e ao dimensionamento, mas não sabia como adaptar mais de uma década
de administração de servidores em larga escala ao mundo de cloud computing. Com o
tempo, comecei a aprender sobre os vários serviços Azure que fornecem esses compo-
nentes-chave. Estes serviços raramente funcionam isoladamente, mas eu não sabia qual
era a melhor maneira de os integrar ou como decidir que serviço usar para cada tarefa.
Este livro é uma forma de explicar ao meu antigo eu, e a muitos outros que seguiram
um percurso semelhante, como entender rapidamente os serviços core do Azure e fazê-
los funcionar em conjunto.
Este livro tem mais de 350 páginas, mas aborda apenas o básico do que é possível
fazer em Azure! Para ajudar a fornecer uma compreensão sólida dos conceitos
necessários para obter êxito enquanto cria soluções no Azure, tive de escolher quais
tópicos escrever a respeito. O livro não aborda todos os 100 ou mais serviços do Azure e
não detalha de forma abrangente os serviços incluídos. Em vez disso, foca-se nas áreas
core de alguns dos serviços principais e mostra exemplos de como ligar tudo em segu-
rança e apresenta as possibilidades do que pode criar em Azure.
O cloud computing está em constante mudança. Não há ciclos de lançamento de
três ou quatro anos nem grandes implementações de atualização. Acho que hoje é o
momento perfeito para criar soluções e escrever códigos; há sempre uma oportuni-
dade de aprendermos algo novo e de aperfeiçoarmos as nossas competências. Espero
que aprenda a executar excelentes aplicações em Azure e aproveite para explorar todos
os serviços disponíveis.
xv
agradecimentos
Muitas pessoas nos bastidores da Manning Publications ajudaram a publicar este livro.
Um agradecimento especial ao Mike Stephens por ter tido a visão de iniciar este pro-
jeto. Agradeço à minha editora Marjan Bace e a toda a gente da equipa editorial e de
produção.OmeuagradecimentoaosrevisorestécnicoslideradosporAleksandarDragosav-
ljevic´—Ariel Gamino, Charles Lam, Ernesto Cardenas Cangahuala, George Onofrei,
Glen Thompson, Jose Apablaza, Juraj Borza, Michael Langdon, Michael Wall, Peter
Kreyenhop, Rick Oller, Rob Ruetsch, Robert Walsh e Vishal Singh. E finalmente, na
parte técnica, agradeço a Karsten Strøbaek, que trabalhou tanto como editor técnico,
como revisor do livro.
Nesta segunda edição, dirijo um enorme agradecimento a Phil Evans e Davanand
Bahall pelo seu apoio e liberdade para atualizar este livro. Este era um projeto fora do
meu trabalho na Microsoft, mas entusiasmava e afetava muitas pessoas. Agra-
deço também a David Tolkov e Tim Teebken, que me deram a oportunidade de me tor-
nar alguém capaz de escrever este livro. E olha, Jean-Paul Connock, ganhámos uma
Taça Stanley desde a última vez! Força Blues!
Agradeço a Rick Claus por ajudar na necessidade de uma documentação técnica
sólida em Azure e a Marsh Macy e Neil Peterson pelo apoio e orientação pessoais na
criação da versão original deste livro. Ainda temos de começar o autocarro escolar.
xvi
sobre este livro
Este livro foi criado para fornecer uma base sólida para o sucesso enquanto programa-
dor ou engenheiro de TI em Azure. Vai aprender sobre as soluções de Infraestrutura
como Serviço (IaaS) e de Plat-aforma como Serviço (PaaS), bem como sobre o
momento de utilizar cada abordagem. Ao analisar os capítulos, irá aprender a planear
adequadamente a disponibilidade e o dimensionamento, manter a segurança em
mente e considerar o custo e o desempenho. No final do livro, deverá ser capaz de
integrar as próximas tecnologias, como containers e Kubernetes, inteligência artificial
e machine learning (IA + ML) e a Internet of Things (IoT).
Quando se trata da criação e execução das suas aplicações e serviços, o Azure permite
escolher o sistema operativo, as ferramentas de aplicações e a plataforma com a qual se
sente mais à vontade. Este livro discute principalmente tecnologias que não são da Micro-
soft, como Linux, Python e Node.js. Os exemplos de comando utilizam a CLI do Azure,
não o Azure PowerShell. Estas foram decisões conscientes para mostrar que utilizar o
Azure não significa que precisa de utilizar o Windows Server, o IIS ou o ASP.NET.
Como trabalha na cloud, isso geralmente significa trabalhar em várias plataformas e
aprender novos tópicos, que é outro motivo para mostrar tecnologias e plataformas que
não são da Microsoft. Gostaria de apresentar algumas dessas novas áreas, antes de se
deparar com as mesmas no mundo real. Ao longo do livro, irei ensinar os conceitos e os
passos necessários para integrar os serviços do Azure, para que possa alternar entre
plataformas ou linguagens conforme pretender e ter o mesmo conhecimento
aplicado.
xvii
xviii livro
sobre este
Plano
O livro está organizado em 4 partes e 21 capítulos:
¡ A parte 1 aborda alguns dos serviços core de infraestrutura e plataforma do Azure:
virtual machines, aplicações Web, armazenamento e redes.
¡ A parte 2 aprofunda a forma como fornecer elevada disponibilidade e redundân-
cia: modelos, conjuntos de disponibilidade e zonas, balanceadores de carga,
dimensionamento automático, bases de dados distribuídas e encaminhamento
de tráfego. No final do capítulo 12, deverá ter um sólido conhecimento de como
criar aplicações distribuídas de alto desempenho em Azure.
¡ A parte 3 aborda aspetos de segurança, como cópia de segurança e recuperação,
encriptação, gestão de chaves digitais e atualizações. No momento em que concluir
o capítulo 16, estará preparado para criar aplicações seguras e estáveis em Azure.
¡ Para terminar o livro, a parte 4 introduz um pouco de diversão, explorando novas
áreas de computação, como a computação sem servidor e aplicações baseadas em
containers. Estes capítulos apresentam áreas do Azure que oferecem um resumo
de como seria o futuro das aplicações de produção.
Exceto na parte 4, que é adequadamente chamada de "As coisas fantásticas", deve ten-
tar analisar os capítulos do livro por ordem. Não deve trabalhar no mesmo projeto em
capítulos sucessivos, mas cada capítulo baseia-se nos exemplos anteriores de teoria e
de laboratório prático.
O capítulo 1 orienta-o na criação de uma conta trial gratuita em Azure, que é
suficiente para concluir os exercícios de laboratório prático em cada capítulo.
Também forneço um pouco mais de conhecimento sobre o Azure e como encontrar
ajuda adicional ao longo do processo. Menciono esta página web algumas vezes no
livro (talvez seja um pouco tendencioso!), mas http://docs.microsoft.com/azure é
o melhor sítio para obter documentação e suporte adicionais em quaisquer áreas
do Azure que lhe interessem.
Sobre os exemplos e o código fonte

Este livro contém muitos exemplos de código fonte, tanto em listagens numeradas
como em linha com o texto normal. Nos dois casos, o código fonte é formatado numa
fonte de largura fixa como esta para o separar do texto comum.
Em muitos casos, o código fonte original foi reformatado, com a adição de quebras
de linha e avanço reformulado para acomodar o espaço de página disponível no livro.
Em casos raros, nem isso foi suficiente, e as listas incluem marcadores de continuação
de linha (➥). Além disso, os comentários no código fonte são removidos das listagens
quando o código é descrito no texto. As anotações de código acompanham muitas das
listagens, destacando conceitos importantes.
O código fonte deste livro, juntamente com os scripts, modelos e recursos de sup
orte, encontra-se disponível em https://www.manning.com/books/learn-azure-in-a-
month-of-lunches-second-edition e no repositório GitHub repo do livro
(https://github.com/fouldsy/azure-mol-samples-2nd-ed).
livro
sobre este xix
Todos os exercícios práticos podem ser concluídos no portal Azure e com o Azure
Cloud Shell, um shell interativo baseado no browser para a CLI do Azure e o Azure Pow-
erShell. Não há qualquer instalação de ferramentas na sua máquina e pode utilizar
qualquer computador e sistema operativo que pretender, desde que suporte um
browser moderno.
Geralmente, o portal Azure implementa pequenas alterações. Parte do desafio de
usar qualquer serviço na cloud é que as coisas podem ser um pouco diferentes do que
eram no dia anterior.
Esta segunda edição do livro tenta minimizar o número de capturas de ecrã do por-
tal, mas não se preocupe se o que vê for ainda um pouco diferente do que é mostrado
no livro. Os parâmetros necessários são geralmente os mesmos, mas o layout pode ser
diferente. Se houver novas opções no portal que não tenha informado especificamente
num exercício ou laboratório, geralmente é seguro aceitar as predefinições
fornecidas.
Se trabalha fora do Azure Cloud Shell, tenha cuidado com os exemplos de comando.
Os shells baseados no Windows, como o PowerShell e o CMD, tratam as quebras de li
nha e as continuações de forma diferente dos shells baseados em *nix, como o Azure
Cloud Shell. Muitos dos exemplos de comando são executados em várias linhas. Os
comandos são apresentados com um caráter de barra invertida (\) para indicar que o
comando continua na próxima linha, como no exemplo a seguir:
az resource group create \
--name azuremol \
--location eastus
Não precisa de introduzir esses carateres de barra invertida, mas isso pode tornar os
comandos longos mais legíveis no ecrã. Se optar por trabalhar localmente no seu com-
putador com um shell do Windows, poderá utilizar um acento grave (`) em vez de uma
barra invertida. Num shell do PowerShell ou do CMD com o Python para Windows
instalado, por exemplo, altere o comando anterior da seguinte maneira:
az resource group create `
--name azuremol `
--location eastus
Esta convenção pode ser confusa no início, mas sigo-a no livro porque a documen-
tação oficial em https://docs.microsoft.com/azure utiliza este formato. Os comandos
da CLI do Azure, que são os mais utilizados neste livro, assumem um shell baseado em
*nix e, portanto, utilizam um caráter de barra invertida. Os comandos do Azure Pow-
erShell assumem um shell baseado no Windows e, portanto, utilizam um sinal de
acento grave. Esta diferença de comportamento vai fazer sentido rapidamente e vai
perceber que é fácil fazer a transição entre shells. Se nunca tiver trabalhado em plata-
formas, esta diferença pode ser uma armadilha divertida!
Recomendo que verifique o Subsistema Windows para Linux (WSL) se executar o
Windows 10 e quiser mergulhar nos sistemas CLI do Azure e baseados em *nix no
geral; pode encontrar mais detalhes em https://docs.microsoft.com/windows/wsl. O
xx livro
sobre este
WSL e as mais recentes melhorias na WSL2 dão-lhe uma experiência nativa do kernel
Linux enquanto executa o Windows . Não tente complicar esta ideia em demasia! Saiba
apenas que pode executar comandos e aplicações nativas Linux sem se preocupar com que-
bras de linha diferentes ou definições variáveis. Para o surpreender realmente, o Pow-
erShell está disponível para .NET Core, que também funciona em Linux. Pode execu-
tar o PowerShell no Linux enquanto estiver no Windows.
Fórum de discussão liveBook

A compra do livro Conhecer o Azure num mês de almoços inclui o acesso gratuito a um
fórum da Web privado administrado pela Manning Publications, onde pode fazer
comentários sobre o livro, fazer perguntas técnicas e receber ajuda do autor e de out-
ros utilizadores. Para aceder ao fórum, vá a https://livebook.manning.com/book/
learn-azure-in-a-month-of-lunches-second-edition/discussion. Também pode saber
mais sobre os fóruns da Manning e as regras de conduta em https://livebook.man-
ning.com/discussion.
O compromisso da Manning para com os nossos leitores é fornecer um local onde
possa ocorrer um diálogo significativo entre os diferentes leitores e entre os leitores e o
autor. Não é um comprometimento com um grau de participação específico por parte
do autor, cuja contribuição para o fórum permanece voluntária (e não remunerada).
Sugerimos que tente colocar-lhe algumas perguntas desafiadoras, para que ele não
perca o interesse! O fórum e os arquivos das discussões anteriores estarão acessíveis no
site da editora, contanto que o livro ainda esteja a ser comercializado.
sobre o autor
IAIN FOULDS é um programador sénior de conteúdos na Microsoft e atualmente
escreve documentação técnica para o Azure Active Directory. Anteriormente, foi
engenheiro de campo de primeira linha na Microsoft direcionado para as tecnologias
de virtualização, como Azure, Hyper-V e System Center Virtual Machine Manager.
Com mais de 15 anos de experiência em TI, a maioria em operações e serviços, ele ade-
riu à virtualização inicialmente com a VMware e ajudou a desenvolver e ensinar cloud
computing durante anos.
Nascido na Inglaterra, Ian vive nos Estados Unidos há mais de uma década e mora
atualmente nos arredores de Seattle com a sua esposa e as suas duas filhas pequenas, às
quais dedica este livro. É fã de futebol e também gosta de hóquei no gelo e quase
qualquer tipo de automobilismo. Além da computação, os seus interesses incluem
automóveis de performance e clássicos, fo-tografia de aviação e também refere tocar
guitarra. É, também, um grande nerd em miniaturas de comboios, participa e trabalha
regularmente como voluntário em programas e eventos em todo o noroeste
do Pacífico.
xxi
Parte 1
Serviços core do Azure
P ara criar a próxima grande aplicação, precisa de uma compreensão sólida

dos recursos básicos em Azure. Coisas como armazenamento e rede podem não
ser os aspetos mais agradáveis para analisar, mas são fundamentais para o que exe-
cuta no Azure. Antes de começar a abordar virtual machines redundantes de
várias instâncias ou em aplicações Web do Azure, irá servir-lhe de ajuda consultar
as opções e as tarefas de gestão disponíveis para uma única instância. Esta aborda-
gem permite que aprenda sobre as diferenças e semelhanças entre a abordagem
IaaS de VM e a abordagem PaaS de aplicações Web. Os capítulos 1 a 5 exploram
VM, aplicações Web, armazenamento core e funcionalidades de rede virtual.
Antes de começar
1
O Azure é um dos maiores fornecedores de cloud computing público no que diz
respeito a serviços como virtual machines (VM), containers, computação sem servi-
dor e machine learning. Não iremos abordar os 100 ou mais serviços do Azure neste
livro, mas vai saber mais sobre os serviços e funcionalidades core que abrangem a
maior parte do que precisa para iniciar a criação e execução de soluções em Azure.
Vamos examinar um exemplo comum de como criar e executar uma aplicação Web,
e verá como utilizar alguns dos serviços core de infraestrutura e plataforma que
podem facilitar o seu trabalho.
Com o Azure, não precisa de uma varinha mágica para prever quantos servidores
ou o armazenamento de que necessita nos próximos três anos. Chega de atrasos até
obter a aprovação do orçamento; aguardar a receção de novo hardware e, depois,
colocar no bastidor, instalar e configurar tudo. Não precisa de se preocupar sobre as
versões de software ou bibliotecas instaladas enquanto escreve o código.
Em vez disso, selecione um botão e crie os recursos necessários. Só paga por cada
minuto em que os recursos estão em execução ou pela quantidade de espaço de
armazenamento ou largura de banda da rede utilizada. Quando já não precisar dos
recursos, pode desativá-los ou eliminá-los. Se de repente precisar aumentar a quanti-
dade de poder de computação num fator de 10, selecione um botão, aguarde alguns
minutos e está feito. A gestão é feita por outra pessoa, permitindo-lhe ficar mais livre
para se concentrar nas suas aplicações e clientes.
1.1 Este livro é para si?

A indústria de TI encontra-se num período de transição quando se trata de atribuir
cargos. Pode referir-se a si mesmo como um profissional de TI, um programador de
software, um administrador de sistema ou um engenheiro de DevOps. Independen-
temente da forme como se refere a si próprio, se pretender saber mais sobre as
3
4 Capítulo 1 Antes de começar
competências core necessárias para criar e executar aplicações protegidas e altamente

disponíveis na cloud, está no lugar certo. Em termos genéricos, vai provavelmente cair
nas operações de TI ou no desenvolvimento das coisas. A verdade é que há muita
sobreposição, especialmente em cloud computing. Quer esteja no desenvolvimento ou
nas operações, é importante compreender os serviços core de infraestrutura e plata-
forma para criar e executar as aplicações mais adequadas aos seus clientes.
Esta segunda edição do livro apresenta alguns destes conceitos core em Azure e ensi-
na-lhe as competências de que necessita para tomar decisões informadas. Quando
começa a ler este livro, deve ter alguma experiência com VM e saber as noções básicas
do funcionamento em rede e armazenamento. Deve, também, ser capaz de criar um
site básico e entender o que é um certificado SSL e uma base de dados. Depois de abor-
darmos os processos core, vamos ver as novas e futuras tecnologias rapidamente. Quer
estar a par do nível a que o seu trabalho o pode levar, para aprender sobre containers,
Internet of Things, machine learning, inteligência artificial e computação sem servi-
dor. Tanto os programadores, como os profissionais de TI devem encontrar áreas novas
de aprendizagem!
1,2 Como utilizar este livro

Como gosto de sanduíches, o almoço pode ser um ótimo momento para explorar tec-
nologia nova e interessante. Pode ser um notívago que tem algum tempo extra à noite
ou uma pessoa que gosta de acordar cedo (o que se passa consigo?!) que pode ler um
capítulo durante o pequeno-almoço. Não há hora certa ou errada para aprender, mas
se reservar cerca de 45 minutos, conseguirá ler um capítulo e fazer os exercícios. Cada
capítulo abrange algo novo, por isso dê a si mesmo tempo para absorver a lição de
cada dia.
1.2.1 Os principais capítulos

O livro é dividido em quatro partes, o que é conveniente se pensarmos que um mês
tem quatro semanas:
¡ A Parte 1 (capítulos 1 a 5) aborda alguns dos recursos core do Azure. Tente, pelo
menos, seguir estes capítulos para ter uma compreensão sólida. Pode, então,
concentrar-se nos outros capítulos que mais lhe interessam.
¡ A Parte 2 (capítulos 6 a 12) fala sobre a disponibilidade e o dimensionamento. Irá
aprender a dimensionar automaticamente os recursos, o tráfego de balancea-
mento de carga e a manipular eventos de manutenção sem tempo de inatividade.
Se quiser saber mais sobre a execução de aplicações altamente disponíveis à
escala global, esta parte é para si.
¡ A parte 3 (capítulos 13 a 16) é para os geeks de segurança. Aborda coisas como
encriptar VM, armazenar certificados SSL num cofre protegido e fazer cópias de
segurança e restaurar os seus dados.
¡ A Parte 4 (capítulos 17 a 21) abrange uma mistura de áreas interessantes para
lhe mostrar um pouco do que o Azure pode fazer por si e os seus clientes. Vamos
falar sobre automatização, containers, a Internet of Things e computação sem
servidor. Escolha algo que lhe interesse, e divirta-se!
Criar o seu ambiente de laboratório 5
1.2.2 Experimente agora

Quer apenas ler ou quer arregaçar as mangas e brincar com o Azure? Ao longo do
livro, pequenas tarefas permitem-lhe experimentar algo novo rapidamente. Se tiver
tempo, experimente. A maior parte da prática vem num exercício de laboratório no
fim do capítulo, mas é muito importante dividir a leitura, experimentando novos con-
ceitos à medida que vai avançando. Alguns destes exercícios guiam-no passo a passo;
outros vão fazê-lo pensar um pouco mais e aprender a construir soluções sozinho,
como faria no mundo real.
1.2.3 Laboratórios práticos

Cada capítulo termina com um exercício de laboratório prático. Alguns capítulos,
como este, têm um exercício de laboratório no meio do capítulo. Nestes exercícios de
laboratório, vai aprender como todas as peças do Azure se encaixam e pode começar
a construir alguma memória muscular mental. Pegue no teclado e no rato e comece
a criar algo incrível!
1.2.4 Código fonte e materiais suplementares

O código fonte deste livro, juntamente com os scripts, modelos e recursos de suporte,
encontra-se disponível em https://www.manning.com/books/learn-azure-in-a-month-
-of-lunches-second-edition e no repositório GitHub do livro em https://github.com/
fouldsy/azure-mol-samples-2nd-ed. Além disso, pode participar no fórum do livro em
https://livebook.manning.com/book/learn-azure-in-a-month-of-lunches-second-edi-
tion/discussion.
1.3 Criar o seu ambiente de laboratório

Este livro não exagera nos conceitos ou na arquitetura; centra-se mais em exercícios
práticos com a plataforma do Azure. Para praticar, precisa de uma conta Azure.
1.3.1 Criar uma conta Azure gratuita

O Azure oferece uma conta trial gratuita que pode ser utilizada durante 30 dias e for-
nece até 200 USD de crédito gratuito. Este crédito gratuito deve ser suficiente para ler
todos os capítulos e exercícios, com espaço para explorar um pouco e divertir-se à
medida que vai avançando! Muitos serviços e funcionalidades do Azure permanecem
gratuitos, mesmo após o término do período de trial.
Experimente agora
Siga os passos desta secção para criar a sua conta Azure gratuita:
1 Abra o seu browser web em https://azure.microsoft.com/free e escolha a opção

para começar com uma conta Azure gratuita.
2 Quando solicitado, inicie sessão na sua conta Microsoft. Se precisar de uma conta
Microsoft ou quiser criar uma nova, escolha a ligação Criar uma Nova Conta
Microsoft.
3 Depois de iniciar sessão numa conta Microsoft, preencha as informações pedidas

para criar uma conta do Azure gratuita:
¡ Insira os seus dados pessoais, conforme solicitado.
¡ Para ajudar a minimizar o abuso e a fraude, forneça um número de telefone
para confirmar a sua identidade por mensagem de texto ou chamada
telefónica.
¡ Também é necessário um cartão de crédito para verificação de identidade,
mas não é retirado nenhum valor. A sua conta só começa a ser cobrada após os
30 dias ou quando usar o seu crédito de 200 USD. Não realizada automatica-
mente a sua transição para uma subscrição pay as you go no fim do trial. Pode
ver 1 pequeno USD (ou moeda local equivalente) que lhe é reembolsado em
poucos dias.
4 Analise e aceite o contrato de subscrição do Azure e a política de privacidade
e selecione Registe-se. Pode demorar alguns minutos até que a sua subscrição do
Azure fique concluída.
5 Quando o processo de registo terminar e o portal Azure carregar, faça uma visita
guiada para se familiarizar.
O seu dashboard, a página inicial do portal, parece estar vazio neste momento. Mas,
no capítulo 2, irá mergulhar na criação da sua primeira VM, que começa a ficar como
a figura 1.1!
Figura 1.1 O portal Azure, pronto para criar as suas próprias aplicações e soluções
Uma pequena ajuda 7
É realmente gratuito?
O Azure tem um Marketplace que contém centenas de imagens pré-criadas
(a base de VM) e soluções que pode implementar. Vamos utilizar algumas destas ofertas
do Marketplace em todo o livro, pois são excelente formas de implementar rapidamente
um conjunto de aplicações inteiro.
Nem todas as ofertas do Azure Marketplace são gratuitas; alguns editores de terceiros
combinam os custos de licenciamento ou de suporte na solução implementada. Uma
VM que tenha implementado da Red Hat, por exemplo, pode incorrer numa taxa adicio-
nal que cobre o contrato de suporte e a licença da Red Hat. Estes encargos não são
cobertos pelo seu crédito de trial gratuito; apenas está incluída a utilização da VM base.
Os exercícios neste livro utilizam apenas recursos que permanecem dentro do trial gra-
tuito. Mas se for explorar outras ofertas incríveis do Marketplace em Azure, preste aten-
ção ao que cria. Qualquer solução que inclua taxas adicionais, deve explicitar claramente
as taxas antes da implementação!
1.3.2 Exercício de laboratório bónus: criação de uma conta do GitHub gratuita

O GitHub é um serviço Web gratuito que muitas organizações e indivíduos utilizam
para gerir projetos como código, modelos e documentação. O Azure tem centenas de
modelos gratuitos e exemplos de script que pode utilizar e com os quais pode contri-
buir. Este é um dos pontos fortes da comunidade de open source: partilhar e retribuir.
Alguns dos exercícios neste livro utilizam recursos do GitHub. Não precisa de uma
conta do GitHub para o fazer. No entanto, se não tiver uma conta, não poderá guardar
nenhuma alteração, nem começar a criar a sua própria coleção de modelos e scripts.
A criação de uma conta do GitHub é opcional, mas altamente recomendada na criação
do seu ambiente de laboratório:
1 Abra o seu browser web em https://github.com.

2 Para criar uma conta do GitHub gratuita, forneça um nome de utilizador, ende-
reço de e-mail e palavra-passe. Irá receber uma mensagem de validação
do GitHub.
3 Selecione a ligação no e-mail de validação para ativar a sua conta.
4 Confira alguns dos repositórios do Azure que fornecem recursos de exemplo:
¡ Modelos de Início Rápido do Azure:https://github.com/Azure/
azure-quickstart-templates
¡ CLI do Azure:https://github.com/Azure/azure-cli
¡ Utilitários do Azure DevOps:https://github.com/Azure/azure-devops-utils
¡ Recursos do livro Conheça o Azure num mês de almoços: https://github.com/fou-
ldsy/azure-mol-samples-2nd-ed
1.4 Uma pequena ajuda

Este livro não cobre tudo o que o Azure oferece. Mesmo se tentasse, no momento em
que ler este capítulo, aposto que haverá algo novo no Azure! O cloud computing move-
-se rapidamente, e estão sempre a ser lançados novos serviços e funcionalidades. Posso
ser um pouco suspeito, mas quando começar a explorar o Azure e pretender aprender
sobre serviços adicionais, o incrível site https://docs.microsoft.com/azure é o melhor

lugar para começar. Cada serviço do Azure está documentado com exemplos de início
rápido, tutoriais, exemplos de código, referências para programadores e guias de
arquitetura. Também pode aceder a opções de suporte gratuitas e pagas se precisar de
ajuda à medida que vá avançando.
1.5 Compreender a plataforma do Azure

Antes de abordar as restantes partes deste livro, vamos dar um passo atrás e falar sobre
o que é o Azure e os serviços que estão disponíveis. Como mencionei anteriormente, o
Azure é um fornecedor de cloud computing à escala global. No momento em que este
documento foi redigido, existem 54 regiões com Azure. Cada região contém um ou
mais datacenters. Por comparação, os outros dois grandes fornecedores de cloud ope-
ram em 23 regiões (Amazon Web Services [AWS]) e 20 regiões (Google Cloud).
O cloud computing fornece mais do que apenas recursos de computação. O azure
tem mais de 100 serviços, agrupados em famílias de serviços relacionados, como com-
putação, Web + rede móvel, containers e identidade. Com todos estes serviços, o Azure
abrange muitos modelos de serviço. Vamos imaginar que estamos à frente de uma fatia
de pizza para o almoço para entender o que isso significa (figura 1.2.).
Caseira Comprar e cozinhar Entrega ao domicílio Restaurante
Mesa de jantar Mesa de jantar Mesa de jantar Mesa de jantar
Bebidas Bebidas Bebidas Bebidas
Forno Forno Forno Forno
Fogo Fogo Fogo Fogo
Massa da pizza Massa da pizza Massa da pizza Massa da pizza
Molho de tomate Molho de tomate Molho de tomate Molho de tomate
Ingredientes Ingredientes Ingredientes Ingredientes
Molho Molho Molho Molho
Você gere O fornecedor gere
Figura 1.2 Modelo de pizza como um serviço. À medida que passa do modelo de pizza caseira, onde
fornece tudo, para o modelo de restaurante, onde acabou de aparecer, as responsabilidades e as
exigências de gestão mudam conforme necessário.
No modelo de pizza como um serviço, tem quatro opções de entre as quais pode esco-
lher. Ao explorar os modelos, preocupa-se cada vez menos com o processo de comer
uma fatia de pizza:
¡ Caseira: faz a massa, adiciona o molho, os ingredientes e o queijo, coloca
a pizza no seu forno, compra as bebidas e senta-se à mesa para a comer.
Compreender a plataforma do Azure 9
¡ Comprar + cozinhar: compra uma pizza pronta. Só precisa de a assar no forno, com-
prar as bebidas e sentar-se à mesa para a comer.
¡ Entrega em casa: pede uma pizza para entregar em casa. Só precisa de comprar as
bebidas e sentar-se à mesa para a comer.
¡ Restaurante: quer sair e comer pizza com o mínimo de esforço!
Agora que está com fome, vamos olhar para o modelo mais tradicional que envolve
alguns recursos de computação (figura 1.3.). Este modelo é um pouco mais parecido
com o que vê em Azure.
Infraestrutura Plataforma Soware

On-premises
como Serviço como Serviço como Serviço
tradicional
(IaaS) (PaaS) (SaaS)
Aplicações Aplicações Aplicações Aplicações
Dados Dados Dados Dados
Middleware Middleware Middleware Middleware
SO SO SO SO
Virtualização Virtualização Virtualização Virtualização
Servidores Servidores Servidores Servidores
Storage Storage Storage Storage
Rede Rede Rede Rede
Você gere O fornecedor gere
Figura 1.3 Modelo de serviço de cloud computing
À medida que explora os modelos, gere menos os recursos subjacentes e pode concen-
trar mais tempo e energia nos seus clientes:
¡ On-premises: configura e gere todo o datacenter, como os cabos de rede, o armaze-
namento e os servidores. É responsável por todas as partes do ambiente de aplica-
ção, suporte e redundância. Esta abordagem fornece controlo máximo, mas com
muitas despesas de gestão.
¡ Infraestrutura como Serviço (IaaS): adquire os recursos de computação básicos de
um fornecedor que gere a infraestrutura core. Cria e gere as VMs, os dados e as
aplicações. O fornecedor de cloud é responsável pela infraestrutura física, pela
gestão de host e pela resiliência. Ainda pode ter uma equipa de infraestrutura
para ajudar a oferecer suporte e implementar VM, mas a equipa não vai ter de
dedicar tempo nem custos à gestão do equipamento físico.
Esta abordagem é boa quando começa a mover aplicações para fora do seu
próprio ambiente na infraestrutura on-premises. A gestão e as operações são
geralmente semelhantes a um ambiente na infraestrutura on-premises, de modo
que a IaaS fornece uma progressão natural para os proprietários de negócios, TI
e aplicações se sentirem confortáveis com a cloud.
¡ Plataforma como um Serviço (PaaS): adquire a pilha de plataforma subjacente de um
fornecedor que gere o sistema operativo e os patches e traz as suas aplicações e
dados. Não se preocupa com VM ou com a rede virtual, e a sua equipa de opera-
ções pode concentrar mais tempo na fiabilidade e no desempenho da aplicação.
Em geral, esta abordagem começa a tornar a organização de TI e a empresa
confortáveis com a execução de aplicações na cloud. O seu foco está nas aplica-
ções e nos seus clientes, com menos preocupações sobre a infraestrutura necessá-
ria para executar essas aplicações.
¡ Software como Serviço (SaaS): só precisa de acesso ao software, com um fornecedor
que fornece todo o resto. Os programadores podem criar com uma plataforma
existente para fornecer personalizações ou funcionalidades exclusivas, sem ter de
manter uma base de código de grande dimensão.
Em geral, esta abordagem é assustadora no início, mas provavelmente já
conhece e utiliza ofertas de SaaS bem-sucedidas, como o Salesforce, o Office 365
ou a suite de aplicações Mail ou Docs do Google. Utiliza o e-mail, cria documen-
tos ou apresentações ou gere informações de contacto do cliente e informações
de vendas. O seu foco está no conteúdo que cria e gere, não em como fazer a exe-
cução da aplicação.
A maior parte do que cria em Azure enquadra-se nas áreas de IaaS e PaaS. Os princi-
pais casos práticos incluem VM e redes virtuais (IaaS) ou o Azure Web Apps, Functions
e os serviços Cosmos DB (PaaS). Se for programador, provavelmente as soluções de
PaaS são as áreas que mais lhe interessam, pois a Microsoft abrange as partes de infraes-
trutura para permitir que se concentre no seu código. Os profissionais de TI podem
inclinar-se mais para as soluções de IaaS para criar e controlar a infraestrutura
do Azure.
Nunca pare de aprender

Não se esqueça que, mesmo quando um negócio migra de IaaS para o modelo
PaaS, o profissional de TI continua a ser relevante! É importante entender o que se passa
em segundo plano na camada de PaaS quando concebe ou resolve problemas de uma
solução. Se for profissional de TI, não ignore os capítulos sobre as soluções de PaaS em
Azure: pode adicionar imenso valor à sua empresa e aos clientes se entender a transi-
ção para esse modelo de implementação.
1.5.1 Virtualização em Azure

A virtualização é a verdadeira magia por trás do Azure. Os modelos IaaS, PaaS e SaaS
utilizam a virtualização para capacitar os seus serviços. O conceito de virtualização não
é novo, remontando aos dias de mainframe dos anos 60. Em meados da década de
2000, a virtualização de servidores no datacenter começou a ganhar impulso e, agora,
apenas alguns workloads são implementados em servidores bare metal em vez de
serem virtualizados.
São dedicados livros inteiros à virtualização, mas aqui fica uma descrição geral
rápida: a virtualização divide logicamente os recursos físicos num servidor em recursos
virtuais que podem ser acedidos com segurança por workloads individuais. Uma VM é
um dos recursos mais comuns de cloud computing. Uma VM contém uma CPU virtual
(vCPU), memória (vRAM), armazenamento (vDisk) e conectividade de rede (vNIC),
como apresentado na figura 1.4.
Host sico no Azure

VM 1 VM 2
Web App IIS + .NET Aplicação web node.js
Windows Server 2019 Ubuntu 18.04 LTS
vCPU vRAM vDisk vNIC vCPU vRAM vDisk vNIC
vCPU vCPU vRAM vRAM vDisk vDisk vNIC vNIC
Hipervisor de Hyper-V
CPU Memória Storage NIC
Figura 1.4 Virtualização em funcionamento num host físico em Azure
Além dos servidores físicos, o armazenamento e a rede são frequentemente virtualiza-

dos, o que permite que a plataforma do Azure defina rapidamente tudo o que precisa
no software. Não é necessária nenhuma interação física ou configuração manual de
dispositivos. Não é necessário aguardar que outra equipa forneça um endereço IP,
abra uma porta de rede ou adicione armazenamento para si.
Como é core, o Azure é executado num tipo de Windows. Uma versão modificada do
hipervisor de Hyper-V capacita os servidores de computação. O Hyper-V é um hipervi-
sor tipo 1 (bare metal) que está disponível no Windows Server há uma década. E não se
preocupe, ainda pode executar o Linux como um workload totalmente suportado de
primeira classe. A Microsoft contribui grandemente para a comunidade Linux e ker-
nel. Algumas das redes core definidas por software em Azure são acionadas por uma
solução personalizada baseada no Debian Linux — Software for Open Networking in
the Cloud (SONiC) — que a Microsoft criou como open source. Pode fazer uma visita
virtual aos datacenters da Microsoft em https://azure.microsoft.com/
global-infrastructure.
1.5.2 Ferramentas de gestão

Com tantos serviços do Azure, como é que os utiliza? Como quiser! Se quiser selecio-
nar tudo num browser, há um portal incrível baseado na Web. Sente-se confortável
com o PowerShell? Como seria de esperar, há um módulo do Azure PowerShell. Há
também uma ferramenta de interface de linha de comandos (CLI) multiplataforma
que é ótima se estiver no macOS ou Linux. E os programadores podem interagir com

o Azure por meio de API REST, utilizando uma variedade de linguagens comuns,
como .NET, Python e Node.js.
Portal Azure
O portal Azure deve funcionar em qualquer browser moderno e é uma maneira
conveniente de utilizar o Azure sem instalar nada no seu computador. O portal tam-
bém é uma ótima maneira de aprender a criar e gerir recursos vendo rapidamente
uma representação visual de tudo.
Estão a ser continuamente adicionados novos serviços e funcionalidades ao Azure,
portanto, é possível que o portal tenha mudado ligeiramente relativamente ao que apa-
rece nas capturas de ecrã neste livro ou na documentação online e nos blogues. O texto
de um botão pode mudar um pouco, ou pode ser adicionada uma nova opção, mas
todas as operações core permanecem todas iguais. Bem-vindo ao admirável mundo
novo do cloud computing!
Azure Cloud Shell
Se pretender usar o teclado e escrever os comandos, o portal também inclui o Azure
Cloud Shell, como apresentado na Figura 1.5. Esta shell é uma consola interativa
baseada na Web que fornece uma shell do Bash, a CLI do Azure, e algumas ferramen-
tas de desenvolvimento de aplicações pré-instaladas, como Git e Maven. Há também
uma versão do PowerShell do Cloud Shell que, como o nome indica, fornece acesso
aos cmdlets mais recentes do Azure PowerShell.
Figura 1.5 O Azure Cloud Shell no portal baseado na Web

Pode aceder ao Azure Cloud Shell num browser em qualquer computador sem preci-
sar de instalar nenhuma ferramenta em https://shell.azure.com. Editores como o
Visual Studio Code (https://code.visualstudio.com) fornecem acesso ao Cloud Shell
dentro da aplicação. Há até mesmo uma aplicação do Azure disponível para iOS e
Android que lhe permite utilizar o Azure Cloud Shell diretamente do seu
smartphone.
Com o Azure Cloud Shell, tem sempre acesso à versão mais recente das ferramentas
da CLI ou do PowerShell. O armazenamento persistente permite-lhe criar e guardar
scripts, modelos e ficheiros de configuração.
Ferramentas locais do PowerShell e da CLI do Azure
Embora existam vantagens para o Azure Cloud Shell, em geral, precisa de acesso ao
seu sistema de ficheiros e ferramentas locais. Pode instalar a CLI do Azure ou o Azure
PowerShell localmente para que possa trabalhar com recursos locais e recursos
do Azure.
Neste livro, vamos utilizar principalmente a CLI do Azure (tecnicamente, a CLI do
Azure 2.0). Pode parecer estranho escolhê-la em vez do PowerShell nativo da Microsoft;
a vantagem é que os exemplos e exercícios podem funcionar tanto no Azure Cloud
Shell como localmente no seu computador, independentemente do sistema operativo
que utiliza. Embora esta informação não faça parte da configuração do ambiente de
laboratório, os seguintes guias detalham como instalar as ferramentas de gestão do
Azure no seu computador:
¡ Introdução ao Azure PowerShell: https://docs.microsoft.com/powershell/azure/
get-started-azureps
¡ Instalar o Azure CLI:https://docs.microsoft.com/cli/azure/install-azure-cli
Criar uma virtual machine
2
Pronto para ver a rapidez com que pode configurar um servidor Web em Azure?
Neste capítulo, vamos analisar um dos pedidos mais comuns quando se trata de VM:
criar um servidor Web básico. Este workload é um ótimo exemplo dos componentes
core de Infraestrutura como Serviço (IaaS) em Azure.
Suponha que trabalha para uma pizzaria que quer expandir as suas operações e
aceitar pedidos online para entrega de pizzas ou para entrega ao domicílio. Para
criar uma presença online, precisa de um site. Nas primeiras partes deste livro, vamos
explorar as diferentes funcionalidades e serviços em Azure que lhe permitem criar e
executar aplicações Web IaaS e Plataforma como um Serviço (PaaS). Pode começar
a tomar decisões informadas sobre quando criar e executar uma VM para acionar
um site e quando pode utilizar PaaS para fazer isso. Mas o primeiro passo é construir
um servidor web.
Neste capítulo, vai criar uma VM do Ubuntu Linux e instalar um servidor Web
básico. Não se preocupe em utilizar o Linux; vai criar uma VM Windows no fim do
capítulo
Abra a porta 80
para permir que
os clientes Cliente no PC
naveguem no site.
Crie num VM Linux Inicie sessão e VM Linux
browser web. instale pacotes.
Cliente no
Servidor Web
smartphone
básico
Cliente no
tablet
Figura 2.1 Neste capítulo, cria uma VM básica, inicia sessão para instalar um servidor Web e, em
seguida, abre uma porta de rede para permitir que os clientes naveguem para o site de exemplo.
14
Noções básicas das configurações de virtual machine 15
exercício de laboratório! Ubuntu é uma plataforma de servidor Web comum, e é uma

ótima maneira de aprender sobre a autenticação de chave pública SSH. Em seguida,
vai ver como abrir uma porta de rede para que os clientes acedam ao seu site na Inter-
net. Na figura 2.1 é apresentada uma descrição geral de alto nível deste ambiente básico.
2.1 Noções básicas das configurações de virtual machine

As VM estão entre os blocos de construção mais comuns que vai usar quando começar
a executar aplicações na cloud. Porquê? Normalmente são territórios familiares. A
maioria dos departamentos de TI executa muitos workloads com Hyper-V ou VMware
num ambiente on-premises, então provavelmente já tem alguma experiência em cons-
truir e executar VM. As organizações costumam dar os primeiros passos em Azure com
VM, uma vez que os workloads do IaaS não requerem o grande ajuste mental que pre-
cisa de fazer quando começa a executar workloads PaaS.
Existem soluções para migrar VM de um ambiente on-premises, como o Hyper-V ou
o VMware para o Azure, mas antes que se entusiasme demasiado com o que é possível em
Azure (alguns dos quais vamos explorar em capítulos posteriores), vamos olhar para
algumas noções básicas. Estas próximas páginas podem parecer considerações e opções
familiares que tem com VM on-premises. Se sim, ótimo! Se isto é novo, não se preo-
cupe; uma grande parte da gestão é resumida em Azure e coisas como redes virtuais são
tipicamente criadas e configuradas uma vez e depois deixadas em paz. Vamos abordar
cada área mais profundamente nos próximos capítulos, portanto respire fundo e dê
um passo de cada vez.
2.1.1 Regiões e opções de disponibilidade

O Azure está dividido em regiões em todo o mundo, com cada região a ter um ou mais
datacenters. Estes datacenters fornecem os recursos core de computação, armazena-
mento e rede para executar as suas aplicações e workloads. O Azure corre em mais de
50 regiões, com a lista a crescer em poucos meses. Com tantas regiões, a ideia é que
possa implementar aplicações próximas dos seus colaboradores ou clientes. Esta dispo-
nibilidade regional reduz a latência e melhora a experiência do utilizador final.
Uma região de Azure pode não oferecer todos os serviços disponíveis em Azure.
Com centenas de serviços disponíveis, o conjunto mais comum de serviços core cos-
tuma estar em todo o lado, mas os serviços novos ou de nicho desenrolam-se, normal-
mente, ao longo do tempo. Enquanto planeia as suas aplicações em Azure, verifique a
disponibilidade do produto por região em https://azure.microsoft.com/global-infras-
tructure/services.
No capítulo 8, vamos analisar algumas das opções de alta disponibilidade, tais como
Conjuntos de Disponibilidade e Zonas de Disponibilidade. Estas opções de redundân-
cia permitem ao Azure distribuir várias instâncias das suas VM ou aplicações dentro de
um único datacenter ou em toda uma região. Esta capacidade permite-lhe definir a sua
tolerância a atualizações de manutenção ou falha de hardware. Nos primeiros capítulos
deste livro, vai criar apenas uma ou duas VM, por isso não se preocupe com estas opções
de disponibilidade ainda.
16 Capítulo 2 Criar uma virtual machine
2.1.2 Imagens de VM
Para criar uma VM, precisa de um ponto de partida. Normalmente, este ponto de par-
tida resume-se à escolha do sistema operativo: Windows ou Linux. De seguida, vem a
escolha da versão do Windows a usar (como o Windows Server 2016 ou 2019) ou que
distribuição Linux usar (como Ubuntu, Red Hat Enterprise Linux ou SUSE).
Uma imagem — um pacote de SO pré-configurado com opções básicas de configura-
ção aplicadas: este é o ponto de partida. O Azure contém centenas destas imagens pré-
-construídas no Marketplace do Azure para usar quando criar VM. Pode aplicar
frequentemente as licenças do Windows existentes, dependendo do seu modelo de
licenciamento atual, ou pode optar por suporte adicional da Canonical para executar
Ubuntu Linux ou atualizações da Red Hat, por exemplo.
Para manter as coisas simples e curtas o suficiente para que possa completar estas
lições numa hora de almoço, vai usar estas imagens pré-construídas em Azure ao longo
do livro. No mundo real, provavelmente vai querer personalizar as coisas de acordo
com as necessidades e requisitos do seu negócio. Para isso, vai ter de criar muitas vezes
as suas próprias imagens de VM. O workflow para criar e gerir as VM é o mesmo que
com as imagens do Marketplace do Azure, mas muitas vezes, construir as suas próprias
imagens requer muito planeamento e, em seguida, horas de configuração, generaliza-
ção e captura prévia das suas próprias imagens.
Experimente agora
Aqui ficam algumas ideias para pensar, enquanto planeia aplicações em Azure. Parecem
básicas e na maior parte do tempo, pode tomar estas decisões automaticamente, sem
pensar muito. Mas ainda é importante entender as necessidades da sua aplicação
antes de começar a construir e executar aplicações!
¡ Em que regiões deve ser executada a sua candidatura? Tem uma grande concen-
tração de utilizadores numa região específica? Como vai providenciar
redundância?
Se estiver a construir aplicações internas, execute-as na região de Azure
mais próxima dos seus utilizadores. Se tem um escritório importante em Hous-
ton, Texas, por exemplo (pode gostar de foguetes!), execute as suas aplicações e
VM Azure na Central Sul dos Estados Unidos .
Se está a criar aplicações externas, prevê ter clientes de certas regiões? Esta
configuração pode exigir a implementação de várias instâncias em regiões dife-
rentes (e também fornecer alta disponibilidade). Vamos chegar à sua configura-
ção no capítulo 12.
¡ Precisa de fornecer muitas personalizações na VM? Quanto tempo demora a
testar e validar todas essas alterações? Que necessidades de negócios as
impulsionam?
Num ambiente tradicional on-premises, muitas vezes gasta-se muito tempo a
criar imagens pré-configuradas para implementações. Desta vez, na cloud, tente
minimizar. As imagens Azure pré-construídas incluem as mais recentes atualiza-
ções de segurança; são testadas para si e, em seguida, replicadas geograficamente
para os tempos de implementação mais rápidos.
Se criar as suas próprias imagens, use funcionalidades como Azure Shared

Image Gallery para distribuir e replicar essas imagens conforme necessário
(https://docs.microsoft.com/azure/virtual-machines/windows/
shared-image-galleries).
2.1.3 Tamanhos de VM
Há várias famílias de tamanhos de VM em Azure. Estas famílias contêm grupos de tipos
de hardware virtuais semelhantes que são direcionados para determinados workloads.
Por vezes, os tamanhos são atualizados à medida que novas ofertas de hardware e
workload se tornam disponíveis, mas as famílias core permanecem constantes. Os tipos
de família são os seguintes:
¡ Propósitos gerais: ótimo para desenvolvimento e teste ou bases de dados de produ-
ção de baixa utilização e servidores Web
¡ Computação otimizada: CPUs de alto desempenho, como para servidores de
aplicações de produção
¡ Memória otimizada: opções de memória maior, como quando precisa de executar
bases de dados de grande dimensão ou tarefas que requerem muito processa-
mento de dados em memória
¡ Armazenamento otimizado: desempenho de baixa latência e alto disco para aplica-
ções que exijam uma utilização intensiva do disco
¡ GPU: VM especializadas em gráficos baseados em NVIDIA, se precisar de compo-
sição de gráficos ou processamento de vídeo
¡ Computação de alto desempenho: muito de tudo - grande quantidade de CPU, memó-
ria e débito de rede para os workloads mais exigentes
Que tamanho de VM pode ser criado em Azure? As coisas estão a melhorar constante-
mente, mas no momento de escrever a maior VM, pode criar uma série Mv2 (parte da
família de memória otimizada) com 208 CPUs virtuais e 5,7 TiB de memória. Isso deve
tornar um servidor Minecraft decente, não acha?!
A principal coisa a aprender aqui é que o número de VMs e a quantidade de CPU
e memória que pode pedir no Azure são limitados apenas pelo seu orçamento. Prova-
velmente teria dificuldades em criar VM deste tamanho no mundo on-premises
tradicional.
Quando criar uma VM no portal Azure ou através da CLI ou do PowerShell, deve
escolher o tamanho de VM a utilizar. Um tamanho de VM comum, como o D2s_v3,
é frequentemente usado como predefinição para começar. É provável que seja dema-
siada potência para um servidor Web básico, neste capítulo, mas é rápido para criar a
VM e instalar os pacotes necessários!
O portal Azure permite filtrar com base num tamanho duro (como pequeno, médio
ou grande) ou numa família específica (como VM para propósitos gerais ou otimizadas
pela memória). Uma estimativa do custo mensal é também apresentada para lhe dar
uma ideia do quão cara cada VM é. Preste atenção aos custos, pois podem aumentar
rapidamente! De forma razoável, pode habitualmente mudar o tamanho da VM depois
de estar em funcionamento, mas a VM deve encerrar e reiniciar para completar
o processo.
Redução de custos de VM
As VM criadas por predefinição são muitas vezes dominadas pelo que precisa, mas
são rápidas na implementação e na utilização, o que ajuda a reduzir o tempo que gasta
na instalação de pacotes na sua pausa para almoço.
No mundo real, preste atenção à memória, CPU e exigências de armazenamento das
suas VM. Crie VM com dimensões adequadas. Esta abordagem é a mesma que no
mundo on-premises, onde pode acabar com VM que têm muito mais memória ou mui-
tas CPU virtuais atribuídas mais do que o necessário.
Há também um tipo especial de VM em Azure: a série B. Estes tamanhos de VM utilizam
recursos de CPU e memória inicializáveis e pode utilizar créditos bancários para
recursos de computação não utilizados. Se pretender poupar os seus créditos do Azure,
escolha esta série de VM para os exercícios do livro. Possuem um preço mais baixo e são
ótimas para cenários em que nem sempre precisa de muitos recursos de CPU e memó-
ria. Contudo, tenhacuidado: dependendo do tamanho da série B da VM que cria, pode
ter menos CPU e memória do que algo como a série D2s_v3, por isso vai ser mais lenta.
2.1.4 Azure storage

O armazenamento para VM em Azure é simples. Quantos discos quer, de que tamanho
e de que tipo? Os dois primeiros não são específicos do Azure, por isso vamos saltar
esta parte. Estes são os tipos de armazenamento disponíveis:
¡ Discos Premium SSD (unidade de estado sólido)— Use SSD de baixa latência e de
alto desempenho e que são perfeitos para workloads de produção. Deve utilizar
maioritariamente este tipo para ter melhor desempenho para as suas aplicações.
¡ Discos SSD padrão— Utilize SSD padrão e ofereça um desempenho consistente
comparativamente com as unidades de disco rígido (HDD). Este tipo é excelente
para workloads de desenvolvimento e teste ou para utilizações em ambientes de
produção com orçamento limitado e pouca procura, como os servidores web.
¡ Discos HDD padrão—Utilize discos giratórios normais e que são ideias para
acesso a dados mais raros, como arquivos de dados ou cópias de segurança. Este
tipo não é recomendado para executar workloads de aplicações.
Não precisa de aprofundar muito mais as especificidades do armazenamento para
criar um servidor Web rápido. Vai aprender mais no capítulo 4, incluindo sobre discos
Ultra que são apenas para discos de dados anexados. Por enquanto, é suficiente saber
que, quando escolhe um tamanho de VM, esse tamanho ajuda a definir o tipo de arma-
zenamento utilizado.
Os discos virtuais que utiliza, independentemente do tipo, são chamados discos geri-
dos Azure . Estes discos geridos permitem-lhe criar uma VM e anexar discos de dados
adicionais sem se preocupar com contas de armazenamento subjacentes, limites de
recursos ou quotas de desempenho. Os discos geridos também são encriptados auto-
maticamente de forma inativa; não precisa de configurar nada para proteger os seus
dados! Mais uma vez, o capítulo 4 aborda isto tudo e muito mais. Por enquanto, pode
deixar normalmente o Azure criar o disco mais adequado com base no tamanho de VM
que seleciona.
Experimente agora
Para verificar os seus conhecimentos, trabalhe as seguintes questões:
¡ Para a maioria dos workloads de produção, que tipo de disco fornece o me-
lhor desempenho?
Um disco SSD premium é normalmente o que deve executar para
workloads de produção. Este tipo é muitas vezes a escolha padrão quando se cria
uma VM. Os discos SSD standard são uma boa segunda escolha e os SSD Ultra só
devem ser usados em aplicações intensivas em disco que requerem baixa latência.
Embora haja menos gastos com os HDD padrão, o desempenho é muitas vezes
excelente, assim como em ambientes virtuais on-premises.
¡ Que família VM é uma boa escolha para um servidor de base de dados?
Uma VM otimizada pela memória é uma boa opção, uma vez que, muitas
vezes, as bases de dados precisam de mais memória do que recursos da CPU.
Tente sempre estimar as necessidades dos recursos e, em seguida, monitorizar
o desempenho após a implementação. Não tenha medo de mudar para um tama-
nho de VM diferente para fornecer o desempenho desejado.
2.1.5 Redes virtuais

Parece óbvio, mas uma VM precisa de conectividade de rede se quiser que alguém
aceda às suas aplicações. Para um servidor web básico, precisa de uma rede virtual e de
conectividade externa. O capítulo 5 aborda a rede core do Azure em detalhe e o capí-
tulo 9 explica como distribuir o tráfego a várias VM, utilizando balanceadores de carga.
As coisas ficam realmente interessantes no capítulo 11, com o DNS Azure e o encami-
nhamento global de utilizadores finais com o Traffic Manager. Não vou fazer de si um
engenheiro de rede, mas vai aprender muito sobre a rede Azure neste livro!
Para começar com o básico necessário para este capítulo, uma rede virtual em Azure
é composta pelas mesmas características core que uma rede física normal:
¡ Um espaço de endereçamento e uma máscara de sub-rede, como 10.0.0.0/16
¡ Uma ou mais sub-redes, que pode utilizar para dividir o tráfego externo, de bases
de dados ou de aplicações, por exemplo
¡ Placas de interface de rede virtual (NICs) que ligam VMs a uma determinada
sub-rede
¡ Endereços IP virtuais que são atribuídos a recursos como uma NIC virtual ou um
balanceador de carga
Pode criar uma VM que só esteja ligada a uma rede virtual sem fornecer conectividade
externa, o que pode acontecer nos servidores aplicacionais ou em bases de dados de
back-end. Para se ligar a essas VM para administração e manutenção, pode criar uma
ligação de rede virtual privada (VPN) ou utilizar uma ligação privada e dedicada ao
Azure a partir do seu equipamento de rede on-premises. Em Azure, esta ligação dedi-
cada é denominada ExpressRoute.
O servidor web básico que vai construir neste capítulo requer um tipo específico
de endereço IP virtual: um endereço IP público. Este endereço IP público é atribuído à
NIC virtual e permite que o tráfego externo chegue à sua VM. Em seguida, pode contro-
lar o fluxo do tráfego para a sua VM com NSG (grupos de segurança de rede). Pense
numa firewall normal que utiliza para abrir ou fechar várias portas e protocolos. Em
Azure, os grupos de segurança de rede bloqueiam o tráfego por predefinição e permi-
tem apenas o tráfego específico que definiu. O tráfego comum a permitir seria HTTP
ou HTTPS nas portas TCP 80 e 443. A gestão remota através da utilização do protocolo
de ambiente de trabalho remoto (RDP) ou Secure Shell (SSH) também pode ser
aberta, com cuidado, o que fará mais tarde neste capítulo para ver como ligar e instalar
alguns pacotes.
2.2 Criação de um par de chaves SSH para autenticação

No exercício de laboratório no fim do capítulo, vai criar aquilo com que provavel-
mente já está familiarizado: uma VM do Windows Server. Este tipo de VM utiliza auten-
ticação baseada em palavras-passe. Muitas aplicações na cloud funcionam em Linux;
na verdade, mais de metade das VM em Azure correm em Linux. Normalmente não se
utiliza a autenticação baseada em palavras-passe com o Linux; em vez disso, usa-se SSH
e um par de chaves públicas. Para começar a expandir as suas competências, o servidor
web básico neste capítulo corre em Linux, por isso precisa de se sentir confortável com
a forma de criar e usar SSH. Não precisa de experiência em Linux para trabalhar na
cloud, mas recomendo vivamente que aprenda alguns dos princípios básicos!
Pares de chaves SSH

SSH é um protocolo utilizado para comunicar com segurança com computadores
remotos e é a forma mais comum de iniciar sessão em VM Linux. É semelhante ao uso
de uma ligação RDP a uma VM Windows, à exceção de que em Linux, toda a sessão SSH
é habitualmente baseada na consola. Com encriptação de chave pública, pode usar um
par de chaves digital para se autenticar numa VM Linux remota.
Um par de chaves SSH tem duas partes: uma chave pública e uma chave privada.
A chave pública é armazenada na sua VM Linux em Azure. Mantém uma cópia da chave
privada. Quando precisar de iniciar sessão na sua VM Linux, a chave pública na VM
remota é associada à chave privada mantida localmente. Se os pares de chaves corres-
ponderem, significa que iniciou sessão na VM. Há um pouco mais a saber sobre o pro-
cesso, mas, basicamente, a encriptação de chave pública é uma excelente forma de
verificar a identidade.
Gostaria que tivesse o hábito de utilizar chaves SSH para iniciar sessão em VM Linux.
As chaves SSH são muito mais seguras do que as palavras-passe porque, entre outras
coisas, não são suscetíveis a ataques de palavra-passe por força bruta. Deve sempre
concentrar-se na segurança como conceito central, especialmente na cloud.
Experimente agora
Criar um par de chaves públicas SSH, através do Azure Cloud Shell:
Criação de um par de chaves SSH para autenticação 21
1 Abra um browser web em https://portal.azure.com. Inicie sessão na conta Azure

que criou no capítulo 1 e, em seguida, selecione o ícone Cloud Shell na parte
superior do dashboard, como mostra a figura 2.2. Também pode abrir o Cloud
Shell diretamente em https://shell.azure.com.
Figura 2.2 Selecione e inicie o Cloud Shell no portal Azure selecionando o ícone do Shell.
2 Quando abrir o Cloud Shell pela primeira vez, vai demorar alguns instantes para
criar um armazenamento persistente que está sempre ligado às suas sessões. Este
armazenamento permite-lhe guardar e obter scripts, ficheiros de configuração e
pares de chaves SSH. Aceite todos os avisos para permitir a criação do
armazenamento.
3 Se necessário, escolha Bash no menu suspenso no canto superior esquerdo do
Cloud Shell. Está também disponível o suporte PowerShell, embora nos concen-
tremos principalmente na Bash e no CLI do Azure ao longo do livro.
4 Para criar um par de chaves, introduza o seguinte comando:
ssh-keygen
5 Aceite os avisos predefinidos premindo a tecla Enter. Em alguns segundos, tem

um par de chaves públicas SSH que pode utilizar com todas as suas VM. O
comando ssh-keygen assume-se como predefinição de uma chave de 2048 bits
de comprimento e utiliza o protocolo RSA versão 2. É um bom equilíbrio de
segurança e é recomendado para a maioria dos casos práticos. A figura 2.3 mos-
tra um exemplo de um par de chaves SSH concluído no Cloud Shell.
Figura 2.3 Um par de chaves SSH criado no Azure Cloud Shell com o comando ssh-keygen
6 Para ver a sua chave pública e utilizá-la com uma VM, introduza o seguinte
comando:
cat .ssh/id_rsa.pub
7 Selecione a saída e copie-a para um ficheiro de texto simples no seu computador.

Vai usar esta chave pública para criar uma VM na secção 2.3; esta VM é referen-
ciada a partir do CLI do Azure ao longo do livro. Normalmente, não é preciso
copiar e colar a chave toda de cada vez, mas é bom ver o que acontece no início.
Esta informação não é secreta, por isso usar o Notepad ou o TextEdit para criar e
guardar uma cópia da chave é suficiente. Tenha cuidado ao copiar a saída da
chave pública, pois é sensível a espaços em branco adicionais ou à ausência de
carateres. Abaixo apresenta-se um exemplo de uma chave pública SSH
completa:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDPGaOBsfhJJOHAWAv+RLLR/vdUTzS9HOIj
➥JyzWWLsnu0ESH2M6R+YYPPNXv9X7dmVyM1zCXXEaLucpnyFjevbwPedxTgifyxgCFTgylr1
➥kg7o4EyCTGBGhTA+hSHuhXGXa12KPdKWehsPwHMa6Hs8fbt/in9Z1k2ZAwvbT+LWPcmJgNO
➥FuolIHOsOEeoQQqdXLrGa7NU/3fzSXdT9Y2BT1KLINc4KnwdOuONddLw3iANvK+Gkwax8iK
➥7IicKMoammwvJUCRf+MTEK9pZ84tfsc9qOIAdhrCCLbQhtoWjZpIwYnFk+SNBE8bZZtB8b2
➥vkDFNZlA5jcAd6pUR3tPuL0D iain@cc-a444-9fdee8b2-2014310619-v5cl5
DICA O Cloud Shell é baseado no browser, portanto, os atalhos de teclado

para copiar e colar podem funcionar de forma um pouco diferente da que está
habituado. Ctrl-Insert e Shift-Insert devem copiar e colar, em vez dos habituais
comandos Ctrl-C e Ctrl-V.
2.3 Criar uma VM a partir do seu browser

Agora que conhece um pouco da teoria das VM do Azure e criou um par de chaves
SSH, está pronto para entrar e criar uma VM. Vou começar e depois vou deixá-lo
configurar a VM com base no que acabou de aprender, por isso vai precisar de pres-
tar atenção!
As ferramentas do CLI do Azure e do Azure PowerShell são incrivelmente podero-
sas, mas uma grande vantagem do Azure é quanto tempo levou para criar uma exce-
lente experiência de portal. O portal Azure é uma ferramenta gráfica baseada na Web
que lhe permite ver como todos os diferentes componentes se unem e efetuar uma
verificação visual rápida para garantir que tudo está bem. O portal inclui alguns ele-
mentos únicos que as outras ferramentas não fornecem, e é rápido de utilizar, pois não
precisa de instalar nada.
Experimente agora
Criar uma VM em Azure dá-lhe várias predefinições que pode usar para reduzir o número
de escolhas que tem que fazer. Para este exercício, veja os recursos que o Azure vai criar
com base no que aprendeu na secção 2.2 para questões de rede e armazenamento:
1 No portal Azure (https://portal.azure.com), selecione Criar um Recurso no

canto superior esquerdo do dashboard. Os recursos populares devem ser lista-
dos, incluindo a mais recente versão de Suporte a Longo Prazo (LTS) de Ubuntu
(a partir daqui, Ubuntu Server 18.04 LTS).
Criar uma VM a partir do seu browser 23
2 Selecione a versão LTS.

Também pode pesquisar no mercado no topo da janela ou procurar a lista
de serviços de alto nível (como Cálculo e Rede) para ter uma ideia do que mais
está disponível para as suas necessidades futuras. Tente manter o Ubuntu Ser-
ver 18.04 LTS para que possa seguir um dos próximos exercícios para instalar os
componentes do servidor web.
3 Crie um grupo de recursos para o seu servidor web.
Quando cria recursos em Azure, eles estão logicamente contidos num
grupo de recursos que vai definir. Estes grupos normalmente contêm recursos
semelhantes para as suas aplicações. O Capítulo 7 aborda as formas de planear
e gerir aplicações utilizando grupos de recursos.
Por enquanto, sugiro que nomeie os grupos de recursos por capítulo para
o ajudar a organizar as coisas à medida que avança. Nomeie o grupo de recursos
neste exercício como capítulo-azuremol2, por exemplo.
4 Dê um nome à sua VM, como webvm, e depois escolha uma região próxima de si.
Não se preocupe com a redundância da infraestrutura, para já.
Veja as opções da imagem da VM, apenas para ter uma ideia das outras opções,
mas para este exercício, mantenha o Ubuntu Server 18.04 LTS. O tamanho
padrão da VM é adequado para este exercício, mas, mais uma vez, procure ver
o que está disponível e como consulta tamanhos diferentes e que hardware exe-
cutam. Veja como os tamanhos se alinham com as famílias de VM que viu no iní-
cio deste capítulo.
5 Certifique-se de que está a utilizar autenticação SSH com chave pública e depois
forneça um nome de utilizador, tal como azuremol. Vai usar este nome de utiliza-
dor para iniciar sessão na VM no próximo exercício.
6 Copie e cole a chave pública SSH que criou na secção anterior. Mais uma vez,
certifique-se de que não há espaços em branco ou formatação adicionais quando
copiar e colar a chave pública. A chave SSH deve estar numa linha. Até mesmo
a mudança de linha no Notepad pode criar problemas! O portal Azure valida a
chave antes de poder prosseguir.
7 Para se ligar à VM no próximo exercício e instalar os componentes do servi-
dor web, abra a SSH na porta 22.
Abrir a SSH numa VM pública não é uma boa prática de segurança. O capítulo
16 analisa a forma como abrir e restringir automaticamente o acesso, utilizando
o acesso à VM just-in-time.
Veja algumas das outras portas que pode abrir aqui. HTTP e HTTPS são portas
comuns para abrir, e a sua função é a criação de um servidor web neste capítulo,
certo? Não faça batota e não abra as portas, para já; quero apresentar-lhe o CLI do
Azure no próximo exercício, onde permite tráfego HTTP.
Conecte-se de forma segura usando um host bastião

Em cenários reais, não deve abrir portas de gestão remota para SSH ou RDP para
a internet pública. Não deve mesmo! Siga as melhores práticas que deve usar no mundo
fora da cloud, no mundo on-premises, como ligar-se apenas quando é necessário e limi-
tar o acesso remoto a um conjunto específico de endereços de gestão.
(continuação)
Uma forma comum de fornecer acesso remoto é usar um host bastião, ou uma caixa de
salto. Neste tipo de configuração, não se liga diretamente aos servidores de aplicações
do seu computador. Em vez disso, liga-se a um host bastião dedicado e, em seguida,
liga-se ao servidor que precisa de gerir. Esta abordagem bloqueia o acesso a um con-
junto limitado de endereços e proporciona uma forma segura de permitir a
gestão remota.
O Azure Bastion (https://docs.microsoft.com/azure/bastion) fornece uma abordagem
gerida para esta necessidade de ligação remota segura. Pode criar um host Azure Bas-
tion numa sub-rede dedicada e, em seguida, use este host para se ligar às VM que cor-
rem as suas aplicações. Essas VM não precisam de ser acessíveis ao público. Pode fazer
tudo através do portal Azure sem abrir portas de rede para SSH ou RDP. O próprio
host bastião é gerido para si em termos de atualizações de segurança e regras de
grupos de segurança de rede.
8 Veja algumas das outras opções de configuração de VM para armazena-

mento e rede para se familiarizar com as opções, embora possa deixar tudo com
predefinições, por enquanto.
9 Existem também algumas opções de gestão incríveis, tais como permitir
o encerramento automático, Cópias de segurança e Diagnósticos, que são abor-
dados nos capítulos 12 e 13. Por enquanto, desligue coisas como diagnósticos de
reinício e diagnósticos de guests do SO, pois precisa de criar e configurar uma
conta de armazenamento para que funcionem.
10 Quando estiver pronto, reveja e crie a sua VM básica.
2.4 Ligação à VM e instalação do servidor Web

Quando a sua VM estiver a funcionar, pode utilizar a chave SSH que criou anterior-
mente para iniciar sessão na VM. Nessa altura, pode então começar a instalar e confi-
gurar o servidor Web, e pode fazer isso com o Cloud Shell.
2.4.1 Ligar à VM com SSH

Esta secção vê como pode obter rapidamente os detalhes da ligação para a sua VM.
Experimente agora
Se o Linux for algo novo para si, não se preocupe! Siga os próximos passos para iniciar
sessão na sua VM:
1 No portal Azure, navegue para as Virtual Machines e selecione-as na barra de nave-

gação no lado esquerdo do ecrã. No exercício anterior, a criação da VM demora
alguns minutos, por isso selecione o botão Atualizar até que o estado da VM seja
Em execução. Quando estiver pronto, escolha a sua VM e selecione Ligar, como
mostra a figura 2.4.
Ligação à VM e instalação do servidor Web 25
Figura 2.4 Selecione a sua VM no portal Azure e selecione Ligar para gerar as informações de ligação SSH.
Com uma VM Linux, vê o comando SSH que inclui o seu nome endereço IP
público. Copie este comando de ligação SSH, tal como o ssh
azuremol@104.209.208.158.
Numa VM Windows, o botão Ligar faz download de um ficheiro de liga-
ção RDP para o computador que está pré-povoado com o endereço IP público
da VM.
2 Se necessário, abra o Cloud Shell novamente. Se estiver a alternar entre o Cloud
Shell e o portal, poderá minimizar o Cloud Shell para o manter disponível em
segundo plano.
3 Cole o comando SSH no Cloud Shell e, em seguida, prima Enter. A chave SSH
que criou anteriormente é utilizada automaticamente para o autenticar.
Quando se liga a uma VM com SSH pela primeira vez, esta pede a adicio-
nar a uma lista de hosts fidedignos. Esta é mais uma camada de segurança que a
SSH fornece. Se alguém tentar intercetar o tráfego e direcioná-lo para uma VM
remota diferente, o cliente SSH local sabe que algo mudou e vai avisá-lo antes
de se ligar.
Aceite o aviso para armazenar a ligação à VM remota. A figura 2.5 mostra o pro-
cesso de ligação SSH no Azure Cloud Shell.
Figura 2.5 Utilize a cadeia de ligação mostrada no portal Azure para criar uma ligação SSH à VM a
partir do Cloud Shell.
Neste ponto,onde quer que se encontre, o aviso do Linux é-lhe totalmente estranho.
Não se preocupe. Não precisa de conhecer um grande número de comandos do Linux
e cada comando é explicado ao longo do livro. Dito isto, recomendo que aprenda pelo
menos algumas competências básicas de administração do Linux. Grande parte da
cloud é baseada em sistemas Linux, e há uma grande movimentação em direção a con-
tainers e microsserviços para desenvolvimento e gestão de aplicações. Se for um admi-
nistrador do Windows à antiga, seja bem-vindo! Há uma surpresa preparada para si no
fim do capítulo, por isso, seja paciente.
2.4.2 Instalar o servidor Web

Criar uma VM? Feito. Ligar-se à VM com SSH? Já está. Agora pode instalar os pacotes
para um servidor Web e preparar-se para o ver em ação.
O Azure suporta muitas distribuições Linux (distros). As ferramentas de gestão de
pacotes e as localizações dos ficheiros de configuração variam um pouco entre distros.
Vai utilizar o Ubuntu neste livro porque é uma das distros Linux mais populares e bem
documentadas para o cloud computing. Se ficar bloqueado durante o processo, deve
conseguir encontrar muita documentação para o ajudar, começando em
https://help.ubuntu.com. Se quiser usar uma distribuição diferente com a qual já está
familiarizado, esteja à vontade. Caso contrário, utilize o Ubuntu.
Permitir que o tráfego Web chegue à VM 27
Experimente agora
Na sessão SSH para a VM, instale os pacotes do servidor Web com a APT:
1 No Ubuntu, instala pacotes com uma Ferramenta de Embalagem Avançada

(APT) — uma ferramenta de gestão de pacotes super potente que instala auto-
maticamente quaisquer pacotes adicionais de que necessita. Tudo o que precisa
de fazer é dizer "Instalar um servidor Web", e a APT instala todos os componen-
tes necessários.
Neste exemplo, instale o LAMP Web stack. Este é provavelmente o conjunto
mais comum de componentes Web: Linux, Apache (um servidor Web), MySQL
(um servidor de base de dados) e PHP (uma linguagem de programação Web):
sudo apt update && sudo apt install -y lamp-server^
O primeiro comando atualiza os pacotes disponíveis, o que é uma boa prática

para garantir a instalação dos pacotes mais recentes e maiores. Quando
o comando termina, execute o próximo comando com &&. Por que não começar
uma nova linha para o próximo comando? O && executa o próximo comando
apenas se o comando anterior tiver sido bem-sucedido. Se não houver conectivi-
dade de rede para a APT obter os pacotes mais recentes (pode-se rir, eu sei que
deve ter conectividade de rede para se ligar!), não haveria necessidade de execu-
tar o comando install.
Se o comando update for bem-sucedido, a APT determina de que pacotes
adicionais precisa e começa a instalar o lamp-server. Porque aparece o símbolo
de acento circunflexo no final (^)? Esse símbolo diz à APT para instalar todo
o conjunto de pacotes que compõem o servidor AMP, não apenas um único
pacote chamado lamp-server.
2 O instalador pode pedir uma palavra-passe ou utilizar por predefinição uma
palavra-passe MySQL vazia. Não é muito seguro, e precisa de especificar uma
palavra-passe forte para utilizar em ambientes de produção real. No capítulo 15,
vai ficar incrível e armazenar uma palavra-passe forte e segura no Azure Key Vault
que é automaticamente injetada neste assistente de instalação do MySQL.
Demora pouco mais de um minuto a instalar todos os pacotes para a sua
pilha web do LAMP; e já está.
3 Escreva exit para sair da VM e regressar ao aviso do Cloud Shell.
Pronto! O seu servidor Web está a funcionar, mas ainda não pode aceder ao mesmo
num browser. Para tal, é necessário permitir que o tráfego web chegue à VM.
2.5 Permitir que o tráfego Web chegue à VM

O seu servidor Web está a funcionar, mas se introduzir o endereço IP público da VM
num browser, a página Web não será carregada. Porquê? Lembra-se dos grupos de
segurança da rede discutidos brevemente na secção 2.1.5? Quando criou a VM, foi
criado um grupo de segurança de rede para si. E foi adicionada uma regra para permi-
tir a gestão remota - neste caso, SSH.O resto da VM está bloqueada. Para permitir que
os visitantes acedam ao seu servidor Web através da Internet, precisa de criar uma
regra no grupo de segurança de rede que permita o tráfego Web. Caso contrário, nin-
guém pode encomendar pizzas!
2.5.1 Criar uma regra para permitir o tráfego Web

Esta secção mistura um pouco as coisas e utiliza o CLI do Azure para criar uma regra
para o tráfego Web. Podia ter aberto esta porta HTTP no portal quando criou a VM,
mas depois teria perdido metade da diversão!
O CLI do Azure está disponível no Cloud Shell. Não precisa de instalar nada. O capí-
tulo 5 abrange as redes virtuais e grupos de segurança de rede mais detalhadamente;
por enquanto, pode verificar como o CLI do Azure é rápido e poderoso com apenas
um comando.
Experimente agora
Abra o Azure Cloud Shell e siga estes passos para ver o CLI do Azure em ação:
1 Se tiver fechado a janela do Cloud Shell, abra-a novamente no portal Azure.

Certifique-se de que a shell do Bash carrega, não o PowerShell. Se necessário,
mude para a versão Bash.
2 Para ver o CLI do Azure e os módulos instalados, escreva az --version. É apre-
sentada uma lista de módulos e números de versão. O que é ótimo sobre o Cloud
Shell é que tem sempre a versão melhor e mais recente disponível.
NOTA Se é atento, pode ter reparado que o comando gerou informações sobre
a versão do Python. Por que esta informação é importante? O Python é uma
linguagem de programação poderosa e popular. O CLI do Azure é escrito em
Python, o que em parte a converte numa multiplataforma e está disponível
para que a instale localmente em qualquer computador se não quiser utilizar
sempre o Cloud Shell. Para acompanhar as ações da Microsoft em termos de
contribuição para a comunidade de código aberto, o CLI do Azure está dispo-
nível no GitHub para que qualquer pessoa faça contribuições, sugestões ou
reporte problemas (https://github.com/Azure/azure-cli).
3 Para abrir uma porta, especifique o nome da VM e o seu grupo de recursos,

juntamente com o número da porta. Para o tráfego Web, precisa de abrir a porta
80. Introduza o grupo de recursos (-g) e o nome da VM (-n) que especificou ao
criar a sua VM:
az vm open-port -g azuremolchapter2 -n webvm --port 80
2.5.2 Ver o servidor Web em ação

Agora que tem uma porta aberta para a sua VM, veja o que acontece quando tenta ace-
der à mesma num browser.
1 No portal Azure, selecione a sua VM, caso tenha saído dela. O endereço IP
público encontra-se listado no canto superior direito da página de descrição
geral da VM.
Laboratório: criar uma VM Windows 29
2 Selecione o endereço e copie-o.

3 No browser, abra um novo separador ou janela e cole o endereço IP público.
O site predefinido do Apache é carregado, como mostra a figura 2.6. Ok, não
parece com uma pizzaria, mas tem as bases para trazer o seu código e come-
çar a criar a sua aplicação.
Figura 2.6 Para ver o servidor Web em ação e ver a página predefinida do Apache 2, introduza
o endereço IP público num browser.
2.6 Laboratório: criar uma VM Windows

As secções anteriores fizeram uma demonstração passo a passo pela instala-
ção da LAMP stack numa VM Ubuntu Linux. Esta plataforma é comum para sites, mas
talvez queira um pouco de afeto e atenção se tiver experiência no Windows. A suas
equipas de desenvolvimento ou decisores empresariais podem querer utilizar .NET,
por exemplo. Mesmo assim, pode executar .NET Core em VMs Linux, portanto, não
deixe que a linguagem conduza a sua decisão.
Pelo que aprendeu no exemplo passo a passo, tente criar uma VM que execute Servi-
ços de Informação Internet (IIS). Veja algumas sugestões:
¡ Precisa de uma VM que execute o Windows Server 2019.
¡ Como utiliza RDP, não SSH, a experiência de ligação será ligeiramente
diferente.
¡ No Gestor de Servidor, procure a opção Adicionar Funções e Funcionalidades.
¡ Precisa de instalar o servidor Web (IIS).

¡ Não se esqueça de abrir uma porta de rede para tráfego HTTP na porta TCP 80.
Se quiser, pode usar o portal.
2.7 Limpar os recursos

À medida que cria recursos em Azure, o medidor de faturação começa a girar.
A cobrança é realizada ao minuto, por isso o ideal é criar bons hábitos e não deixar
recursos como a VM em execução quando deixar de os utilizar. Tem duas formas de
parar os encargos de faturação para executar uma VM:
¡ Desalocar uma VM. Pode selecionar o botão Parar no portal para interromper
e desalocar uma VM, libertando todos os recursos de computação e de rede
retidos.
¡ Eliminar uma VM. Esta opção é bastante óbvia. Se não restar nada em Azure, não
há nada para pagar. Certifique-se de que encerrou a VM antes de a eliminar. Não
há nenhum botão Anular em Azure!
Recomendo que crie um grupo de recursos para cada implementação de aplicações à
medida que começa a criar coisas em Azure. Ao percorrer os exercícios neste livro, é
basicamente isso que vai fazer. Se nomear os seus grupos de recursos por capítulo,
como azuremolchapter2, é mais fácil manter o controlo dos seus recursos e do que
eliminar. Esta prática torna a limpeza um pouco mais fácil, pois pode eliminar todo
o grupo de recursos no final de cada capítulo. Escolha Grupos de Recursos a partir do
menu de navegação do lado esquerdo do ecrã, abra cada grupo de recursos que criou
neste capítulo e selecione Eliminar Grupo de Recursos, como mostra a figura 2.7. Para
confirmar, ser-lhe-á pedido que introduza o nome do grupo de recursos.
Figura 2.7 Para poupança de custos, elimine grupos de recursos quando já não precisar deles.
Se tiver o hábito de eliminar recursos quando deixar de os utilizar, pode fazer isso con-
fortavelmente neste livro com os créditos gratuitos do Azure. No mínimo, tente desalo-
car a sua VM no final de cada lição para que possa retomar no dia seguinte e controlar
o tempo de faturação.
Houston, temos um problema 31
2.8 Houston, temos um problema

Às vezes, vai ter problemas em Azure. Pronto, está dito! Normalmente, a plataforma do
Azure é boa a lidar com problemas que surgem à medida que cria recursos:
¡ O CLI do Azure ou o Azure PowerShell gera um relatório à medida que executa
comandos, portanto, é óbvio quando algo corre mal. Normalmente, o Azure
PowerShell utiliza um texto vermelho agradável e calmo para chamar a sua
atenção,
¡ O CLI do Azure pode ser um pouco mais enigmática porque geralmente inclui as
respostas reais para as chamadas de API REST subjacentes do servidor. Se isto
é tudo novo, pode passar por alguns sucessos e falhas para entender o que está a
acontecer de errado. A parte útil de obter as respostas REST é que pode copiar e
colar as mensagens de erro no seu motor de busca favorito e obter resultados
geralmente sólidos para o ajudar a resolver problemas.
Quer descansar? Acabámos de começar!

Quando abre uma página Web no browser, o seu computador está a comunicar com
um servidor Web, utilizando HTTP. Quase que posso garantir que já viu uma mensagem
de erro 404 num site. Essa mensagem significa que a página Web não foi encontrada.
Outros erros comuns que pode ter visto são o 403 (não tem permissões para ver
a página) e o 500 (o servidor encontrou um erro).
Mesmo quando as coisas estão a correr bem, o seu browser recebe mensagens de
código 200 quando a página é carregada sem problemas ou mensagens de código 301
se uma página foi redirecionada para uma nova localização. Não precisa de entender e
manter o controlo de todos estes códigos; são apenas formas padrão que o HTTP utiliza
para facilitar a comunicação entre computadores.
Anteriormente neste capítulo abordámos a forma de criar e gerir recursos do
Azure através do portal Web, CLI ou PowerShell. Todos os serviços do Azure são acedi-
dos por interfaces de programação de aplicações (API) de Transferência de Estado
Representativo (REST).
Se isto for uma novidade para si, as API REST são uma forma (algo) padronizada de
expor serviços via TTP. Utiliza pedidos HTTP padrão como GET e POST para pedir informa-
ções ou fazer uma alteração e, quando a plataforma aceita e processa o pedido, recebe
uma mensagem de estado. O Azure tem um conjunto bem definido de APIs REST.
Não precisa de entender o que isso significa. Basta estar ciente de que, quando
vê uma mensagem de erro, nem sempre está no formato mais legível e útil. Às vezes,
recebe a resposta HTTP não processada da API REST que deve decifrar. Mais uma vez,
cole este erro no seu motor de busca favorito. Há uma boa hipótese de alguém já ter
encontrado o problema e ter fornecido uma razão mais humana para o que correu mal
e o que precisa de corrigir.
Os problemas mais comuns com VM ocorrem quando se liga à sua VM. Pode
estar a ligar-se a administração remota com SSH ou RDP, ou a tentar aceder às suas
aplicações através de um browser Web ou cliente de ambiente de trabalho. Estes pro-
blemas estão frequentemente relacionados com a rede. Não culpo totalmente os res-
ponsáveis pela rede até ao capítulo 5, por isso veja algumas coisas que pode verificar:
¡ Pode ligar-se a outras VM ou aplicações do Azure em execução em Azure?

Se não, é provável que exista algum fator local na sua rede que esteja a impedir
o acesso.
Se puder ligar-se a outros recursos do Azure, garanta que abriu as regras de
grupo de segurança de rede (secção 2.5). O capítulo 5 aprofunda estas regras.
¡ Para problemas de autenticação, tente o seguinte:
– Confirme se tem as chaves SSH corretas. Quando cria a VM, o Azure deve
informá-lo se a chave pública é válida. Se tiver mais do que uma chave privada,
certifique-se de que está a utilizar a correta.
– Para problemas de RDP, tente ligar-se a localhost\<username> e introduza a sua
palavra-passe. Por predefinição, a maioria dos clientes RDP tenta apresentar
credenciais locais ou credenciais de rede, que a sua VM não entende.
Azure Web Apps
3
No capítulo 2, criou uma virtual machine (VM) e instalou pacotes manualmente para
executar um servidor Web básico. Poderia criar uma pizzaria online com esta VM se
estivesse ansioso para começar. Um dos maiores casos práticos das VMs do Azure con-
siste em executar aplicações Web, normalmente à escala. As aplicações Web são um
workload confortável para as VMs. É bom sentirmo-nos confortáveis, se também gos-
tar da manutenção que acompanha a gestão de todas as VM, como por exemplo, coi-
sas divertidas como atualizações de software, patches de segurança, registo
centralizado e relatórios de conformidade. E se pudesse obter todo o poder de um
servidor Web seguro para executar as suas aplicações Web, incluindo a capacidade de
dimensionamento automático para satisfazer as exigências, sem a necessidade de
criar e gerir todas essas VM? Deixe-me apresentá-lo ao serviço Azure Web Apps.
Neste capítulo, comparamos a abordagem de VM e servidores Web da Infraestru-
tura como Serviço (IaaS) com a abordagem da Plataforma como Serviço (PaaS). Vai
conhecer as vantagens do Azure Web Apps ao criar uma aplicação Web e descobrir
como trabalhar com as suas versões de desenvolvimento e produção. Em seguida, vai
aprender a implementar a sua aplicação Web automaticamente a partir de um con-
trolo de origem, como o GitHub. Este workflow é mostrado na figura 3.1. Azure Web
Apps permitem-lhe implementar e executar a sua pizzaria online numa questão de
minutos, sem a necessidade de instalar e configurar um pacote de VM e servidor web.
Criar Serviço de Implementar Serviço de

Criar serviço aplicação aplicações aplicação de aplicações
de aplicações. Web. exemplo do GitHub. Web App
Plano do App Web
Service aplicação
Site
Figura 3.1 Neste capítulo, vai criar um plano do serviço de aplicações e uma aplicação Web básica
e, em seguida, implementar um site do GitHub.
33
34 Capítulo 3 Azure Web Apps
3.1 Descrição geral e conceitos do Azure Web Apps

Com o Azure Web Apps, começa a mergulhar no maravilhoso mundo das soluções
PaaS. Se acha que o cloud computing envolve VMs, provavelmente deve reajustar essa
ideia um pouco. No início deste livro, falei sobre a aquisição de capacidade de proces-
samento e o foco nas suas aplicações e clientes. À medida que substitui as soluções
IaaS, como as VM, pelas soluções PaaS, como as Web Apps, as suas aplicações e clientes
tornam-se o foco.
Executar aplicações Web em VM IaaS requer a gestão do sistema operativo, das atua-
lizações de aplicações, das regras de segurança e tráfego e da configuração de todo o
sistema. Com as Web Apps, carrega a sua aplicação Web e todas essas tarefas de gestão
são realizadas automaticamente. Agora pode focar-se em melhorar a experiência das
aplicações para os seus clientes ou melhorar a disponibilidade com opções de dimen-
sionamento e gestão de tráfego.
Isso significa que nunca deve executar VMs para alojar uma aplicação Web? Provavel-
mente não. Existem razões válidas para executar toda a pilha de aplicações e configurá-
-la por si mesmo, como se precisasse de um suporte de aplicações muito específico ou
tempo de execução da linguagem. Mas nas Web Apps pode fornecer muitos dos casos
práticos para executar aplicações Web.
3.1.1 Linguagens e ambientes suportados

Que tipo de flexibilidade oferecem as Web Apps em termos de linguagens de progra-
mação que pode utilizar para criar a sua aplicação Web? Muita! Há duas plataformas
primárias para a execução das Web Apps: Windows e Linux. Pode executar aplicações
Web .NET Core, Node.js, Python, Java, Ruby e PHP nativamente tanto em instâncias de
aplicações web Windows e Linux. No Windows, também pode executar a estrutura
completa .NET. Se quiser ser realmente incrível e executar a sua aplicação Web em
containers, também há Web Apps para Containers, que lhe permitem executar contai-
ners nativos do Docker para Linux. Falaremos mais sobre containers e Docker no capí-
tulo 19. Por enquanto, entenda que opções são abrangidas pelas Web Apps!
Em que casos é o que as Web Apps podem não ser úteis? Nem todos as linguagens de
aplicações são suportados pelas Web Apps. Digamos que realmente quer torturar-se
com uma aplicação Web escrita em Perl. Nesse cenário, provavelmente irá voltar a exe-
cutar VMs IaaS geridas por si, pois não há suporte para Perl no Web Apps. Porém, é
provável que o Web Apps suporte as linguagens de programação da Web mais comuns
que pretende utilizar. Também deve utilizar uma versão mais recente da sua aplicação
do que uma escrita em Perl.
As Web Apps não só fornecem suporte a várias linguagens, como também a várias
versões dessas linguagens. A PHP, por exemplo. Normalmente, pode selecionar
três ou quatro versões de PHP para suportar melhor a sua aplicação. E, o melhor de
tudo, é que não precisa de se preocupar com as dependências do servidor Web subja-
cente para dar suporte a tudo, como faria se tivesse gerido uma VM IaaS. O Python é
outro exemplo de diferenças entre as versões estáveis 2.7 e 3.6 (e posteriores), como
mostra a figura 3.2.
Descrição geral e conceitos do Azure Web Apps 35
Figura 3.2 Selecione uma versão específica

de uma linguagem nas definições da aplicação
das Web Apps.
As Web Apps também permanecem atualizadas em termos de correções de segurança.

Mas não espere que uma versão mais antiga do PHP ou Python continue a ser supor-
tada indefinidamente. Haverá um limite nas versões anteriores que são suportadas
num dado momento. Novamente, isso pode acontecer quando voltar a executar VM
IaaS se a sua aplicação precisar de uma versão de linguagem mais antiga. Mas se preci-
sar de executar uma versão mais antiga de uma determinada linguagem para oferecer
suporte a uma aplicação legada, não se deixe levar por uma abordagem de manuten-
ção constante. Procure sempre mover essas aplicações legadas para plataformas com-
patíveis mais modernas.
3.1.2 Testes de diferentes versões com blocos de implementação

Os blocos de implementação fornecem um ambiente de teste à sua aplicação Web. Pode
emitir novas versões da sua aplicação via push para um bloco de implementação e exe-
cutá-las utilizando variáveis ambientais ou ligações de base de dados, sem afetar o site
lançado. Quando estiver satisfeito com o aspeto e a funcionalidade de um bloco de
implementação, pode mudar esta versão para o site lançado num instante. Assim, o site
anteriormente lançado muda para um bloco de implementação próprio, fornecendo
uma versão arquivada ou, se necessário, pode reenviar a aplicação para produção.
O número de blocos de implementação disponíveis varia de acordo com o escalão
da aplicação Web selecionada. Um número maior de blocos de implementação per-
mite que diferentes programadores usem várias versões de teste à medida que prepa-
ram e testam as suas próprias atualizações.
3.1.3 Planos de serviço de aplicações

As Web Apps fazem parte da família mais ampla do App Service no Azure. O Azure
App Service também inclui os serviços Mobile Apps, API Apps e Logic Apps. Todas as
aplicações, exceto as Logic Apps, estão disponíveis em todas as regiões em que o Azure
é executado. Aqui fica um ótimo recurso para verificar a disponibilidade do serviço do
Azure por região: https://azure.microsoft.com/regions/services. Muitos serviços
estão disponíveis globalmente.
Quando precisa de criar um recurso do App Service, como uma aplicação Web, cria
ou utiliza um plano de serviço existente. O plano de serviço define a quantidade de
recursos disponíveis para si, a quantidade de automatização disponível para escalar e
apoiar a sua aplicação web, e quão altamente disponível se encontra para disponibilizar
o seu site com blocos de paragem e Traffic Manager (uma forma de encaminhar geo-
graficamente o tráfego para a instância mais próxima para um utilizador, que vamos ver
no capítulo 11). Como em qualquer coisa, recebe pelo que paga. A sua aplicação e
necessidades de negócio devem guiá-lo quanto à quantidade de recursos necessários e
quais as funcionalidades adicionais necessárias. Cada escalão de serviço baseia-se nas
funcionalidades dos escalões inferiores, geralmente adicionando mais armazenamento
e recursos disponíveis.
Os quatro escalões principais do plano de serviço são os seguintes:
¡ Gratuito/Partilhado—Utiliza uma infraestrutura partilhada; oferece armazena-
mento mínimo e não tem opções para implementar diferentes versões de teste,
encaminhamento de tráfego ou cópias de segurança. O escalão Partilhado permi-
te-lhe utilizar um domínio personalizado e cobra por esse domínio.
¡ Básico— Fornece recursos de cálculo dedicados para a sua aplicação web, e per-
mite-lhe utilizar o SSL e escalar manualmente o número de instâncias de aplica-
ções web que executou. Os escalões gratuitos/partilhados e básicos fornecem um
bom ambiente para testar o serviço de Web Apps, mas não recomendaria execu-
tar qualquer workload de produção ou desenvolvimento reais. O desempenho
não é um fator limitativo, mas perde algumas das funcionalidades automatizadas,
como cópias de segurança e escalas.
¡ Padrão—Adiciona cópias de segurança diárias, dimensionamento automático de
instâncias de aplicações Web e blocos de implementação, e permite encaminhar
utilizadores com o Traffic Manager. Este escalão pode ser adequado para aplica-
ções de baixa procura ou ambientes de desenvolvimento em que não precisa de
um grande número de cópias de segurança ou blocos de implementação.
¡ Premium—Fornece cópias de segurança mais frequentes, maior armazenamento
e um maior número de blocos de implementação e opções de dimensionamento
de instâncias. Este escalão é ideal para a maioria dos workloads de produção.
O caso do isolamento
Com soluções PaaS tais como as Web Apps, a infraestrutura é intencionalmente
reduzida. Como os nomes de alguns escalões do plano de serviço implicam, as apli-
cações Web são executadas numa plataforma partilhada de recursos disponíveis.
Isso não significa que as aplicações Web são inseguras e que outros podem ver os
seus dados privados! Mas por motivos de conformidade ou regulamentares podem
exigir que execute as suas aplicações num ambiente controlado e isolado. Introduza
App Service Environments: ambientes isolados que lhe permitem executar instâncias
do App Service como as aplicações Web numa parte segmentada de um datacenter
do Azure. Controla o tráfego de rede de entrada e saída e pode implementar firewalls
e criar ligações de rede privada virtual (VPN) nos recursos on-premises.
Todos estes componentes da infraestrutura ainda são amplamente abstraídos com
ambientes do App Service, mas esta abordagem fornece um excelente equilíbrio
quando pretende a flexibilidade das soluções PaaS, mas também pretende reter
alguns dos controlos mais refinados sobre o fluxo de tráfego das ligações de rede.
Criar uma aplicação Web 37
Pode fazer muito com os escalões Gratuito e Básico, embora para os workloads de pro-
dução deva provavelmente utilizar o escalão Padrão ou Premium. O exemplo deste
capítulo utiliza o escalão Padrão para que possa ver todas as funcionalidades disponí-
veis. Ao utilizar as Web Apps com as suas próprias aplicações, pode decidir quantas
destas funcionalidades são necessárias e selecionar o escalão do plano de serviço mais
apropriado em conformidade.
3.2 Criar uma aplicação Web

Com a teoria que acabámos de abordar, vamos ver uma aplicação web em ação. Há
alguns passos para chegar à execução de uma aplicação. Primeiro, crie a aplicação Web
básica e veja o site predefinido no seu browser. Em seguida, utilize uma página Web de
exemplo do GitHub e efetue a emissão da mesma via push para o Azure. Talvez os seus
programadores Web tenham começado a criar uma interface para a sua pizzaria
online, por isso tem um site básico pronto para carregamento.
NOTA Se nunca tiver utilizado o Git, não se preocupe. Não precisa de entender
o que faz o Git neste momento, e tem tempo para brincar e explorar um
pouco no fim do capítulo. Conhecer o Git num mês de almoços, de Rick Umali
(https://www.manning.com/books/learn-git-in-a-month-of-lunches), é uma
excelente introdução para usar o Git se quiser aprender um pouco mais, e está
disponível para ler gratuitamente na plataforma Manning liveBook.
3.2.1 Criar uma aplicação Web básica

Tal como fiz no capítulo 2, vou dar-lhe algumas orientações breves ao longo do
caminho, mas veja onde pode aplicar alguma teoria nos tempos de execução da aplica-
ção e nos planos de serviço de aplicações para criar uma aplicação Web. Se não tem a
certeza sobre algumas opções, por enquanto pode aceitar as predefinições.
PaaS, não IaaS

Esta aplicação web é um recurso novo e está separada de VM como a que criou
no capítulo 2, que é uma abordagem IaaS para construir e executar aplicações web.
A abordagem PaaS é as Web Apps. Não há nenhuma relação real entre os dois tipos. Na
verdade, se seguiu o conselho no capítulo 2 e eliminou a sua VM, esta aplicação Web
é executada sem uma VM na sua subscrição do Azure!
Experimente agora
Para criar uma aplicação Web, conclua os passos que se seguem:
1 Abra um navegador web em https://portal.azure.com e faça login na sua conta

Azure.
2 No portal, selecione Criar um Recurso no topo superior esquerdo do dashboard.
3 Escolha Web na lista de recursos que pode criar e selecione Web App.
4 Para que tudo fique claro e organizado como fez no capítulo 2, sugiro que
crie um grupo de recursos dedicado para a sua aplicação Web, como
azuremolchapter3.
5 Para o nome da aplicação web, insira um nome globalmente exclusivo. Este

nome deve ser exclusivo e global, pois cria o URL para a sua aplicação Web com
o formato http://<name>.azurewebsite.net. Caso se esteja a questionar, sim, pode
aplicar um nome de domínio personalizado. Por enquanto, utilize o endereço
azurewebsites.net predefinido.
6 Vai emitir código HTML básico via push, não um container Docker, mas atente
nas diferentes pilhas de tempo de execução que estão disponíveis. Pode alterar
esta definição depois de ter criado a aplicação web, mas por enquanto, escolha
um tempo de execução ASP.NET que é executado no Windows.
7 Deixe o Azure criar um plano de serviço de aplicações automaticamente, mas
mude o tamanho para S1 Standard. Este escalão fornece todas as funcionalida-
des core sem fornecer muitos recursos para o seu site básico demonstrativo. Em
implementações no mundo real, é neste passo que pode criar e configurar
manualmente os seus próprios planos de serviço de aplicações ou selecionar um
plano existente.
8 Quando estiver pronto, reveja e crie a sua primeira aplicação web.
A criação do seu serviço de aplicações demora alguns segundos. Quando estiver
pronto, navegue e selecione App Services na barra de navegação do lado esquerdo do
ecrã; em seguida, escolha a sua aplicação web a partir da lista. Na janela Descrição
Geral da sua aplicação Web, veja e selecione o URL da aplicação Web, como
https://azuremol.azurewebsites.net.
Quando seleciona o URL para a sua aplicação Web, é aberta uma nova janela ou
separador do browser. A página predefinida da aplicação Web é carregada, como mos-
tra a figura 3.3 Ainda não parece uma pizza. . . .
Figura 3.3 Para ver a página predefinida da aplicação Web em ação, abra um browser com o URL do seu site.
3.2.2 Implementar um site HTML de exemplo

Tem uma aplicação Web em Azure, mas é um site predefinido inútil. Como pode con-
seguir o seu próprio site em Azure? Uma das formas multiplataforma mais comuns é
utilizar o Git. A maioria dos programadores de aplicações e equipas utiliza um sistema
de controlo de origem. Em vez de armazenar ficheiros no seu computador e guardar
as alterações gradualmente, os sistemas de controlo de origem controlam as alterações
e permitem que trabalhe com outras pessoas. Pode criar versões de teste que não irão
afetar o seu código de produção e reverter para versões anteriores se surgirem proble-
mas. O Git é um dos sistemas de controlo de origem mais comuns. O GitHub é um
serviço baseado na cloud que permite partilhar e fornecer código ao resto do mundo.
A Microsoft adquiriu o GitHub em junho de 2018, mas não há nada que o obrigue a
utilizar o GitHub com o Azure ou vice-versa. Todos os exemplos neste livro estão dispo-
níveis no GitHub.
Neste exemplo, cria uma cópia local do site de exemplo HTML estático e, em
seguida, emite os ficheiros via push para a sua aplicação Web do Azure. Este workflow
é mostrado na figura 3.4.
Copiar ficheiros
Ficheiros HTML
git clone Criar local git push para a
de exemplo no
Criar local aplicação Web
GitHub.
do Azure.
Figura 3.4 Cria uma cópia local dos ficheiros de exemplo do GitHub com o comando git clone. Para
emitir estes ficheiros locais via push para a sua aplicação Web do Azure, utilize git push
Experimente agora
Para obter uma cópia da página HTML de exemplo do GitHub e efetuar a emissão da
mesma via push para a sua aplicação Web, conclua os passos seguintes:
1 Abra o Cloud Shell no portal Azure e aguarde alguns segundos até que a sua ses-
são se ligue. Para começar, precisa do site de amostra HTML do GitHub.
Para clonar ou copiar o site HTML de exemplo do GitHub, introduza o seguinte
comando:
git clone https://github.com/fouldsy/azure-mol-samples-2nd-ed.git
Se for a sua primeira vez a usar o Git no Cloud Shell, vai precisar de definir algu-
mas definições para que o Git entenda quem você é. Para a maioria dos exercícios
neste livro, o Git não se importa realmente com o utilizador, mas para a utilização
com os seus próprios projetos e aplicações, é uma ótima forma de realizar o con-
trolo de quem executa certas ações num sistema de controlo de origem. Só pre-
cisa de definir estas definições uma vez. Introduza o seu próprio endereço de
e-mail e nome completo nas config do Git da seguinte forma:
git config --global user.email "iain@azuremol.com"

git config --global user.name "Iain Foulds"
2 Mude para o diretório azure-mol-samples-2nd-ed que foi criado quando clonou

o repositório Git:
cd azure-mol-samples-2nd-ed/03/prod
3 Para se preparar para carregar a página HTML de exemplo, deve iniciar o Git e,
em seguida, adicionar e confirmar os seus ficheiros. Não se preocupe muito com
os comandos do Git por agora! Precisa de dizer ao Git que ficheiros devem ser
controlados e adicionados e deve ter uma maneira de controlar essas alterações
mais tarde, se necessário:
git init && git add . && git commit -m "Pizza"
4 Agora pode preparar-se para emitir este site HTML de exemplo via push para a
sua aplicação Web. Primeiro, defina as credenciais de implementação. Para pro-
teger as Web Apps quando utilizar um método de implementação como o Git ou
FTP, tem de fornecer um nome de utilizador e uma palavra-passe. As Web Apps
podem usar um conjunto de credenciais que são válidas em todos os planos de
serviço de aplicações em Azure ou credenciais de nível de aplicação que se apli-
cam apenas a uma única aplicação.
No mundo real, recomendo que use credenciais de nível de aplicação para
minimizar o alcance de um ataque caso uma das credenciais seja exposta. O Azure
gera automaticamente as credenciais de nível de aplicação, mas tem de recuperar
e atribuir essas credenciais de cada vez. Para manter as coisas simples, use uma
credencial definida que pode reutilizar nos próximos capítulos.
Crie as credenciais de implementação e especifique o seu próprio nome de
utilizadores e palavra-passe seguros. O nome de utilizador deve ser globalmente
exclusivo. Se ajudar, adicione as suas iniciais ao nome de utilizador ou a uma con-
venção de nomeação que faça sentido para o seu ambiente.
az webapp deployment user set --user-name azuremol --password @azurem0l!
5 Em seguida, precisa de obter o URL para o repositório Git da sua aplicação web.
Introduza o nome da aplicação web (não o nome de utilizador que criou no
passo 4) e o grupo de recursos que especificou quando a aplicação web foi criada
para ver o URL do repo do Git.
Como utilizar a barra invertida

No exemplo a seguir e capítulos posteriores, a barra invertida (\) significa que o comando
continua na próxima linha. É uma maneira de encurtar linhas longas, e esta abordagem é
utilizada em muitos exemplos online, nos quais pode copiar e colar os comandos. Não
precisa de escrever as barras invertidas nos exemplos deste livro se não quiser! Basta
continuar a escrever os parâmetros adicionais como parte de uma grande linha.
Se estiver a utilizar a linha de comandos do Windows em vez de uma shell do Bash,
não inclua as barras invertidas. Se o fizer, não vai efetivamente ter o resultado
desejado!
az webapp deployment source config-local-git \

--name azuremol \
--resource-group azuremolchapter3 -o tsv
6 A sua aplicação Web está configurada para funcionar com os repositórios Git,
por isso precisa de indicar ao Cloud Shell qual é o repositório. No Git, definem-
-se estas localizações como remotas.
Copie o URL de clonagem do Git no passo 5 e, em seguida, defina este URL
como um destino para o site HTML de exemplo no Cloud Shell com o seguinte
comando:
git remote add azure your-git-clone-url
7 Para carregar ou copiar ficheiros com o Git, deve emiti-los via push. Para onde é
que o Git os emite via push? Um local remoto como o que configurou no passo 6,
como azure. A parte final do comando é um ramo, normalmente master. Um
ramo no Git é o meio para manter os modelos trabalhos em curso sob controlo.
Uma prática recomendada em ambientes de produção consiste em emitir via
push para os ramos de lançamento que pode nomear como pretender, como dev
ou staging. Estes ramos adicionais permitem que o seu código de produção seja
executado normalmente. Depois, pode, trabalhar em novas funcionalidades ou
atualizações com segurança e sem afetar os workloads reais que os seus clientes
utilizam.
Emita o site HTML de exemplo via push para a sua aplicação Web:
git push azure master
8 Quando lhe for pedido, introduza a palavra-passe que criou para as credenciais
de implementação. Pode copiar e colar a palavra-passe para minimizar erros aqui.
Pode ver na saída que a página predefinida do site da aplicação Web existente é remo-
vida e o site HTML de exemplo é carregado e configurado para ser executado. Veja um
exemplo de saída:
Counting objects: 3, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 510 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: Updating branch 'master'. remote: Updating submodules.
remote: Preparing deployment for commit id 'dda01e9d86'.
remote: Generating deployment script.
remote: Generating deployment script for Web Site
remote: Running deployment command...
remote: Handling Basic Web Site deployment.
remote: Creating app_offline.htm
remote: KuduSync.NET from: 'D:\home\site\repository' to:
'D:\home\site\wwwroot'
remote: Deleting file: 'hostingstart.html'
remote: Copying file: 'index.html'
remote: Deleting app_offline.htm
remote: Finished successfully.
remote: Running post deployment command(s)...
remote: Deployment successful.
To https://azuremolikf@azuremol.scm.azurewebsites.net/azuremol.git
* [new branch] master -> master
Para ver a sua aplicação Web atualizada, atualize o seu site num browser ou abra-o
novamente na janela Descrição Geral no portal Azure. Deve parecer-se como o exem-
plo maravilhoso na figura 3.5. Sim, o site é básico, mas o workflow para implementar o
site HTML estático mais básico numa complexa aplicação Web .NET ou Node.js é o
mesmo!
Figura 3.5 Atualize o

seu browser para ver a
página predefinida da
aplicação Web
substituída pelo site
HTML estático básico
do GitHub.
3.3 Ver registos de diagnóstico

Agora que já viu como criar uma aplicação Web básica e implementar um site HTML
simples, o que acontece com a gestão geral? Se tiver problemas, seria útil ver os registos
da aplicação ou do servidor Web. Para ajudar a resolver problemas relacionados com
as suas aplicações, pode escrever a saída da sua aplicação nestes ficheiros de registo. Os
ficheiros de registo podem ser vistos em tempo real ou escritos em ficheiros de registo,
e ser analisados posteriormente.
A sua aplicação Web é, em grande parte, executada por si só. Não há muito que possa
fazer do ponto de vista de manutenção no host Web subjacente. Se a sua aplicação tiver
problemas, convém examinar os registos para ver o que está a acontecer e resolver o
problema. Com as Azure Web Apps, configura aspetos como o nível de mensagens de
registo a analisar, onde armazenar os registos e quanto tempo devem ser mantidos. A
figura 3.6 descreve como gerar e ver ficheiros de registo com as Web Apps.
Os eventos da aplicação
são transmitidos para
os registos
Registos de
aplicações
Acesso via
Registos
Azure agrupados em FTP ou
Web App tempo real para transmissão
análise
em direto
Registos de
Os eventos do servidor
são transmitidos para servidor Web
os registos
Figura 3.6 A sua aplicação pode gerar registos de aplicações e registos de servidores. Para o ajudar
a analisar ou resolver problemas, pode fazer download destes registos por FTP ou visualizá-los em
tempo real.
Ver registos de diagnóstico 43
Experimente agora
Para configurar a sua aplicação Web para registos de diagnóstico, conclua os passos
seguintes:
1 No portal Azure, selecione a aplicação Web que criou no exercício anterior.

2 Na janela Descrição Geral, desloque-se para baixo até à secção Monitorização e
selecione Registos do App Service.
3 Analise as opções de registo disponíveis, como a verbosidade e se pretende ativar
a monitorização de pedidos falhados. Se lidar com o lado da infraestrutura do
Azure, talvez seja necessário trabalhar com os programadores de aplicações para
determinar quais registos são necessários para ajudar a resolver problemas.
Depois, pode ativar o registo relevante aqui. Os registos podem ser armazenados
no sistema de ficheiros local da aplicação web ou emitidos via push para o Azure
Storage para processamento com outra aplicação.
4 Por enquanto, ligue o Registo de Aplicações (Sistema de Ficheiros). Ligue tam-
bém o servidor Web a iniciar sessão no sistema de ficheiros com um período de
retenção de sete dias. O nível de erro padrão pode não mostrar nada se tudo
funcionar bem, mas tenha cuidado com a mudança para Debug ou Trace, pois os
seus registos podem encher-se rapidamente e dificultar a visualização do que está
a acontecer! Se tiver algum problema, aumente gradualmente o nível de registo
até capturar informações suficientes para resolver problemas sem ser esmagado
pelos dados do registo.
Se realmente quiser pesquisar os dados, pode aceder aos registos armazenados no sis-
tema de ficheiros utilizando FTP. Os endereços FTP são mostrados na secção Registos
de Download ou na janela Vista Geral para a aplicação web. Pode estar a pensar: "O
FTP é uma forma complicada de obter registos de diagnóstico. Não há uma maneira
mais fácil?" Sim, há! No portal Azure, exatamente onde configurou os seus registos de
diagnóstico, há uma opção Fluxo de Registo. Consegue adivinhar o que essa opção
faz? Vou dar uma dica: tem a ver com o streaming dos seus ficheiros de registo.
Se selecionar este botão no portal Azure, poderá escolher entre Registos de Aplica-
ções e Registos de Servidor Web. Estes registos são lidos a partir dos mesmos registos de
diagnóstico que são escritos no ficheiro. Pode levar alguns minutos para os dados do
registo sejam apresentados no fluxo, e o que é apresentado depende dos níveis de
registo que especificar e se a sua aplicação Web gera eventos de aplicações. Para o site
HTML básico, o fluxo é bastante aborrecido, mas é uma ótima funcionalidade para ter
no browser. A figura 3.7 mostra um exemplo de um streaming de registos de servidor
Web no portal Azure.
Experimente agora
Veja os ficheiros de registo de streaming no portal Azure. Talvez seja necessário atualizar
a página no seu browser algumas vezes para gerar atividade nos registos.
Figura 3.7 Pode ver os fluxos de registo do servidor Web das Web Apps de registos em direto a partir da
sua aplicação para ajudar a verificar e depurar o desempenho da aplicação. A caixa da consola no lado
direito do ecrã mostra os registos de streaming em tempo real da sua aplicação Web.
À medida que ficar mais familiarizado com o Azure e utilizar o módulo do CLI do
Azure ou do Azure PowerShell, pode transmitir registos em fluxo com estas ferramen-
tas. Os programadores também podem ativar a depuração remota com o Visual Studio
ou configurar o Application Insights para permitir que a aplicação Web forneça tele-
metria a serviços adicionais para monitorização e diagnóstico. A solução aqui é que, à
medida que migra para soluções PaaS como as aplicações Web, ainda pode obter regis-
tos de diagnóstico cruciais e dados de aplicações para resolver problemas e monitori-
zar o desempenho da sua aplicação Web.
3.4 Laboratório: criar e utilizar um bloco de implementação

Viu como criar um site HTML simples e emitir a página via push para o Azure Web
Apps com o Git. E se agora quiser adicionar alguns novos estilos de pizza e vê-los antes
de publicar o site para os clientes pedirem? Veja como utilizar um bloco de implemen-
tação para fornecer algum lugar para carregar as suas alterações, analisá-las e, em
seguida, trocá-las para produção:
1 Na sua aplicação Web, escolha Blocos de Implementação. Adicione um bloco de

implementação denominado Dev, mas não clone qualquer definição do bloco de
implementação existente.
Laboratório: criar e utilizar um bloco de implementação 45
2 Quando estiver pronto, selecione o bloco de teste a partir da lista. O portal mos-
tra as mesmas opções de configuração e de registo que o bloco de produção, o
que mostra como pode alterar as definições neste bloco de implementação sem
afetar o site ativo.
3 Desta vez, explore as opções no portal Azure para o Centro de Implementação.
Pretende utilizar o Git Local para o controlo de origem que utiliza o serviço de
compilação do App Service para o bloco de teste. Isto aconteceu em segundo
plano quando utilizou o Azure CLI no exercício anterior, mas tem outras opções
em termos de onde pode implementar o código e que serviço compila e cria essa
implementação.
4 Quando terminar, copie o Uri do Git Clone, tal como https://azuremol-dev.
scm.azurewebsites.net:443/azuremol.git. Veja como o repositório Git inclui
o -dev para o bloco de teste.
Está incluído um site de desenvolvimento de exemplo nos exemplos do GitHub
que clonou anteriormente.
5 No Azure Cloud Shell, mude para o diretório de desenvolvimento da seguinte
maneira:
cd ~/azure-mol-samples-2nd-ed/03/dev
6 Como antes, inicialize, adicione e confirme as suas alterações no Git com

os seguintes comandos:
7 Crie uma ligação para o novo repositório Git no bloco de teste com git remote
add dev, seguido pelo URL de implementação do Git do bloco de teste.
8 Utilize git push dev master para emitir as suas alterações via push para o bloco
de implementação.
9 Selecione o URL para o bloco de teste na janela Descrição Geral do portal Azure.
Não se nota uma grande alteração, claro, mas o título da página permite-lhe
saber que está a ver a versão de desenvolvimento.
10 No portal Azure para a aplicação Web, o
que acha que acontece se selecio-
nar o botão Trocar, como mostra a
figura 3.8? Experimente e, em seguida,
atualize a página principal, como por
exemplo https://azure-mol.azurewebsites.
net, no seu browser.
Figura 3.8 Ao trocar os blocos por uma aplicação Web,

escolhe as instâncias de origem e destino a alterar. Pode
também pré-visualizar o novo aspeto antes de ativar as
alterações.
Blocos de implementação, em segundo plano

Quando troca de blocos, o que estava ativo no bloco de produção está agora no bloco de
desenvolvimento, e o que estava em desenvolvimento está agora ativo em produção.
Nem todas as definições podem ser trocadas, como as definições de SSL e os domínios
personalizados. Mas, na maior parte, os blocos de implementação são uma ótima
maneira de preparar e validar o conteúdo antes de ser publicado para os clientes. Tam-
bém pode executar uma troca com pré-visualização, o que lhe dá a oportunidade de ter
a certeza de que o conteúdo trocado funciona corretamente antes de ser colocado em
produção.
Para utilização em ambientes de produção em workflows DevOps, também pode confi-
gurar a Troca Automática. Aqui, quando uma confirmação do código é observada no con-
trolo de origem, como o GitHub, ela pode acionar uma compilação
num bloco de implementação do Azure Web Apps. Assim que essa compilação é con-
cluída e a aplicação está pronta para processar conteúdo, os blocos de implementação
são trocados automaticamente para ativar o código em produção. Normalmente, este
workflow é utilizado com um ambiente de teste para analisar primeiro
as alterações ao código, e não para publicá-las diretamente na produção!
Introdução ao Azure Storage
4
Podemos ter a certeza de uma coisa no mundo das TI: quando as coisas correm mal,
o armazenamento e a rede são, inevitavelmente, os culpados. Digo isto como alguém
que já foi administrador de SAN numa das minhas vidas passadas! Era muito amigo
da equipa de rede. Estou a brincar (sobre ser o melhor amigo), mas não importa
o quão bem uma aplicação foi concebida e escrita: os componentes fundamentais
da infraestrutura devem estar a funcionar para suportá-la. Fique comigo nos próxi-
mos capítulos enquanto exploro o Azure Storage e o Azure Networking. Pode sentir
a tentação de passar por cima destes serviços chegar ao material fantástico nos capí-
tulos posteriores, mas é válido passar algum tempo a explorar e a aprender estes
serviços core. Isso não vai fazer com que a sua comida saiba melhor, mas pode aju-
dar os seus clientes ao pedirem deliciosas pizzas para entrega!
Este capítulo analisa os diferentes tipos de armazenamento no Azure e quando
utilizá-los. Também falo sobre as opções de redundância e replicação do serviço
Azure Storage e como obter o melhor desempenho para as suas aplicações.
4.1 Discos Geridos

Há alguns anos, o armazenamento de servidores era caro, lento e excessivamente
complicado. Não era incomum para um fornecedor de armazenamento vender um
hardware que custa centenas de milhares de dólares e levava dias, ou mesmo sema-
nas, para um exército de consultores e engenheiros configurar. À medida que a vir-
tualização começou a enraizar-se no datacenter e a VMware e o Hyper-V se tornaram
mais aceites, o armazenamento tornou-se frequentemente o fator de restrição de
desempenho. E isso sem falar nas incompatibilidades de firmware entre os adapta-
dores de armazenamento no servidor e na matriz de armazenamento, caminhos de
rede redundantes que falham e os discos de estado sólido (SSDs) considerados
como o único meio de obter desempenho.
O Azure corrigiu magicamente todos estes problemas de armazenamento? Claro
que não! Mas afasta 95% dessas preocupações e permite que possa concentrar-se em
desenvolver e criar experiências impressionantes para os seus clientes. Este capítulo
abrange os últimos 5% de que precisa de ter em conta.
47
48 Capítulo 4 Introdução ao Azure Storage
O serviço Azure Managed Disks simplifica a abordagem ao armazenamento de VMs.

Os discos geridos retiram, em grande parte, a abstração do trabalho em segundo plano
para lhe proporcionar. . . bem, um disco. No fundo, em relação às VMs, basta preocu-
par-se com isto: quão grandes e rápidas são, e ao que estão ligadas. Ao longo do livro, e
em todas as suas próprias implementações no mundo real, deverá sempre utilizar dis-
cos geridos para VMs. Os discos geridos são a opção predefinida, e não há muitos bons
motivos para mudar isso.
Antes dos discos geridos, precisava de criar uma conta de armazenamento nomeada
com exclusividade, limitar o número de discos virtuais criados em cada uma e mover
manualmente as imagens de disco personalizadas para criar VMs em diferentes regiões.
Estes tipos de discos são conhecidos como discos não geridos ou discos clássicos. O serviço
Managed Disks (Discos Geridos) elimina a necessidade de uma conta de armaze-
namento, limita a “apenas” 50.000 discos por subscrição e permite criar VMs a
partir de uma imagem personalizada entre regiões. Também ganha a capacidade de
criar e utilizar instantâneos de discos, encriptar automaticamente dados inativos e utili-
zar discos de até 64 TiB.
Por que é isso importante? Se consultar documentação ou publicações de blogues
antigas, talvez precise de criar uma conta de armazenamento para as suas VMs. Pare aí
mesmo! Sim, pode converter VMs de discos não geridos em discos geridos, mas se possí-
vel, procure começar cada projeto com discos geridos desde o início. O caso prático para
discos não geridos é mais para manter a retrocompatibilidade com as implementações
existentes, embora eu recomendaria converter esses workloads em discos geridos!
4.1.1 Discos do SO
Lembra-se que, se quisesse o melhor desempenho, tinha de comprar SSDs? Não há
nenhuma forma mágica para contornar esse requisito no Azure. Sinto muito. A ver-
dade é que os SSDs superam muito os discos giratórios normais. Há limites físicos para
a rapidez com que os discos giratórios podem. . . bem, girar. Os engenheiros da Micro-
soft ainda não conseguiram desafiar as leis da física! Ainda há casos práticos para dis-
cos giratórios normais (como o armazenamento de arquivos de baixo custo) e, assim
como em matrizes de armazenamento normais, as tecnologias mais recentes podem
fornecer um bom desempenho num conjunto de discos giratórios.
A primeira e principal escolha que precisa de fazer para uma VM do Azure é o tipo
de armazenamento que deve ser utilizado:
¡ Discos SSD premium — Utilize discos SSD de alto desempenho para obter um
desempenho ideal, maior IOPS e baixa latência. Tipo de armazenamento reco-
mendado para a maioria dos workloads de produção.
¡ Discos SSD padrão— Utilize SSD padrão e ofereça um desempenho consistente
comparativamente com as unidades de disco rígido (HDD). Estes discos são exce-
lentes para workloads de desenvolvimento e teste ou para utilização em ambien-
tes de produção com orçamento limitado e pouca procura.
¡ Discos HDD padrão — Utilize discos giratórios normais para obter
acesso a dados mais raros, como arquivos e cópias de segurança.
O tamanho da VM que escolher ajuda a determinar o tipo de armazenamento que
pode ser selecionado. De volta ao capítulo 2, quando criou uma VM, escolheu um
tamanho para obter rapidamente uma VM. A predefinição era provavelmente algo
como uma VM Série D2S_v3, que lhe dava acesso a discos SSD premium. Como pode
Discos Geridos 49
saber quais VMs podem aceder a discos SSD premium? Procure um s, no tamanho da
VM, para SSD. Existem algumas exceções à regra, mas esse é um bom padrão a seguir.
Os exemplos seguintes ajudam a identificar quais as VMs que podem aceder a discos
premium e quais as VMs que podem aceder a SSDs ou HDDs padrão:
¡ As VMs Série D2S_v3, Fs, GS e Ls podem aceder a discos SSD premium.
¡ As VMs série D, A, F e M só podem aceder a discos SSD ou HDD padrão.
Se selecionar um tamanho de VM que possa utilizar discos SSD premium, não tem qual-
quer obrigação de fazer isso. Pode criar e utilizar discos SSD ou HDD padrão. Ao escolher
discos SSD premium, prepara a aplicação para o futuro e tem a opção de utilizar SSDs de
alto desempenho, pois precisa deles sem redimensionar as suas VMs nem sofrer interrup-
ções no processo. Todos os tamanhos de VM podem utilizar discos SSD padrão.
Disco do SO efémero
Há um tipo especial de disco do SO denominado disco efémero. Continua a ser um disco
gerido, de certa forma, mas é local para o host do Azure subjacente. Este facto faz com
que um disco efémero seja realmente rápido, com baixa latência.
Como os dados não são escritos para uma matriz de armazenamento remoto, os dados
podem não persistir durante a reinicialização da VM se mudar para um host subjacente
diferente. Os discos efémeros são ótimos para workloads sem estado que podem lidar
com o arranque com uma imagem limpa de cada vez e não precisam de armazenar
dados localmente para aceder em reinicializações.
Apenas certos tamanhos de VM suportam discos efémeros, mas não há custos adicio-
nais para a sua utilização e estão disponíveis em todas as regiões. Perde-se alguma fun-
cionalidade para coisas como o Azure Site Recovery e o Azure Disk Encryption (capítulos
13 e 14, respetivamente), mas se quiser um armazenamento de alta velocidade e baixa
latência, consulte os discos efémeros.
Experimente agora
Como pode dizer quais tamanhos de VM estão disponíveis para si? No portal Azure, abra
o Cloud Shell. Introduza o seguinte comando (sinta-se livre para utilizar a sua própria
região):
az vm list-sizes --location eastus --output table
Lembre-se que qualquer tamanho com um s fornece acesso a discos SSD premium.
4.1.2 Discos temporários e discos de dados

Agora que já descobriu o nível de desempenho necessário para as suas aplicações, vou falar
sobre mais algumas peças do puzzle. Os discos são ligados de duas maneiras:
¡ Discos temporários — Cada VM tem automaticamente o armazenamento SSD local
anexado do host subjacente que oferece uma pequena quantidade de armazena-
mento de alto desempenho. Tenha muito cuidado ao utilizar este disco temporá-
rio! Como o nome indica, este disco pode não persistir com a VM. Se a VM for
movida para um novo host num evento de manutenção, um novo disco temporá-
rio será anexado e todos os dados armazenados serão perdidos. O disco temporá-
rio foi concebido como um espaço de rascunho ou cache de aplicações.
¡ Discos de dados — Todos os discos criados especificamente e anexados à VM atuam

como esperado em termos de partições, sistemas de ficheiros e pontos de montagem
persistentes. Os discos de dados são reanexados à medida que a VM se move pelo
datacenter do Azure, e estão onde a maioria das suas aplicações e dados deve ser
armazenada. Ainda pode utilizar espaços de armazenamento ou RAID de software
para agrupar discos de dados no nível da VM para ter um desempenho ainda maior.
Há um tipo específico de disco de dados que pode anexar a uma VM se necessitar de
desempenho máximo e baixa latência: discos ultra. Estes discos estão um passo acima
dos discos SSD premium e estão disponíveis apenas para discos de dados. Os discos
ultra são concebidos para bases de dados grandes e workloads com uso intensivo de
dados como SAP HANA. De que velocidade estamos a falar? No momento da escrita,
os discos ultra podem ter até 64 TiB de tamanho e fornecer até 160.000 IOPS por disco
com um débito máximo de 2000 MBps.
4.1.3 Opções de colocação de discos em cache

Também é importante considerar o disco do SO que vem com a VM. Quando cria uma
VM, obtém, pelo menos, um disco: o disco onde o SO está instalado. É tentador utilizar
esse disco para instalar as suas aplicações ou escrever ficheiros de registo. A menos que
execute uma pequena implementação de prova de conceito, não execute as suas apli-
cações no disco do SO! Há uma boa probabilidade de não vir a obter o desempenho
desejado.
Os discos no Azure podem ter uma política de colocação em cache definida. Por pre-
definição, o disco do SO tem uma colocação em cache de leitura/escrita aplicada. Nor-
malmente, este tipo de colocação em cache não é ideal para workloads de aplicações
que escrevem ficheiros de registo ou bases de dados, por exemplo. Os discos de dados,
por outro lado, não têm nenhuma política de cache predefinida. Esta é uma boa política
para workloads que executam muitas escritas. Também pode aplicar uma política de
cache só de leitura, que é mais adequada para workloads de aplicações que leem princi-
palmente os dados dos discos.
Em geral, anexe e utilize sempre discos de dados para instalar e executar as suas apli-
cações. Mesmo a ausência de uma política de cache predefinida oferece provavelmente
melhor desempenho do que a política de cache de leitura/escrita do disco do SO.
4.2 Adicionar discos a uma VM

Nesta secção, verá como adicionar discos a uma VM ao criá-la. No capítulo 2, criou
uma VM com o portal Azure. Desta vez, utilize o Azure CLI para criar uma VM. O Azure
CLI fornece uma maneira rápida de criar uma VM e anexar um disco de dados ao
mesmo tempo.
Experimente agora
Para criar uma VM e ver os discos de dados em ação, conclua os passos a seguir:
1 No Azure Cloud Shell, crie um grupo de recursos com az group create, forne-
cendo um nome para o grupo de recursos juntamente com uma localização:
az group create --name azuremolchapter4 --location eastus
Adicionar discos a uma VM 51
2 Crie uma VM com o comando az vm create. O parâmetro final, --data-disk-

-sizes-gb, permite criar um disco de dados juntamente com a VM. No laborató-
rio de fim de capítulo, pode ligar-se a esta VM e inicializar os discos.
¡ Pode criar uma VM Linux ou Windows para este exercício. Se estiver fami-
liarizado com o Linux ou quiser aprender a inicializar e preparar um disco
para Linux, utilize o seguinte comando para criar uma VM Ubuntu LTS:
az vm create \
--resource-group azuremolchapter4 \
--name storagevm \
--image UbuntuLTS \
--size Standard_B1ms \
--admin-username azuremol \
--generate-ssh-keys \
--data-disk-sizes-gb 64
¡ Se estiver mais familiarizado com o Windows, utilize o seguinte comando para

criar uma VM Windows Server 2019. Em seguida, pode usar o RDP para ligar à
VM para configurar os discos mais tarde:
az vm create \
--name storagevm \
--image Win2019Datacenter \
--admin-password P@ssw0rd! \
--data-disk-sizes-gb 64
¡ A criação da VM irá demorar alguns minutos. A VM já tem um disco de dados

anexado e pronto para utilização.
E se quiser adicionar outro disco de dados após algumas semanas ou meses? Utilize
o Azure CLI novamente para ver como adicionar um disco rapidamente. O processo é
o mesmo para uma VM Linux ou Windows. Tudo o que faz é dizer ao Azure para criar
um novo disco e anexá-lo à sua VM.
Experimente agora
Adicione um disco de dados adicional à sua VM, conforme mostrado a seguir.
Crie um novo disco com o comando az vm disk attach. Forneça um nome e tama-
nho para o disco. Lembra-se do tema anteriormente debatido sobre discos padrão e
premium? No exemplo a seguir, cria um disco SSD premium:
az vm disk attach \
--vm-name storagevm \
--name datadisk \
--size-gb 64 \
--sku Premium_LRS \
--new
Reconhece a última parte desse tipo de armazenamento? LRS significa armazenamento

localmente redundante. Vamos analisar as opções de redundância na secção 4.3.3.
Em dois comandos, criou uma VM com o Azure CLI que incluía um disco de dados e
simulou como anexar um disco de dados adicional mais tarde. Mas só porque
anexou estes discos, isso não significa que é possível escrever dados nos mesmos imedia-
tamente. Como em qualquer disco, seja um disco físico anexado a um servidor on-pre-
mises ou um disco virtual anexado a uma VM, precisa de inicializar o disco e, em
seguida, criar uma partição e um sistema de ficheiros. Pode fazê-lo no exercício opcio-
nal no laboratório de fim de capítulo.
4.3 Azure Storage

O Armazenamento pode não parecer o tópico óbvio a ser examinado para criar e exe-
cutar aplicações, mas é um serviço amplo que abrange muito mais do que pode espe-
rar. O serviço Azure Storage fornece muito mais do que apenas um lugar para
armazenar ficheiros ou discos virtuais para as suas VMs.
Veja o que a sua pizzaria fictícia pode precisar para criar uma aplicação que processa
pedidos para levar ou entregar aos clientes. A aplicação precisa de um armazenamento
de dados que contém as pizzas disponíveis, a lista de ingredientes e os preços. Con-
forme os pedidos são recebidos e processados, a aplicação precisa de uma maneira de
enviar mensagens entre os componentes da aplicação. Em seguida, o site principal pre-
cisa de imagens que dão água na boca para mostrar aos clientes como são as pizzas.
Como se pode ver na figura 4.1, o Azure Storage tem diversas funcionalidades de arma-
zenamento e pode abranger estas três necessidades.
Conta Azure Storage

Blob Tabela Fila Ficheiro Disco
Dados não Armazenamento Mensagens entre Partilhas de ficheiros Discos geridos,
estruturados, como de dados NoSQL componentes da SMB tradicionais para a base para todos
imagens das pizzas não estruturado, aplicação, para VMs, como armazenar os SO de VM
que a sua loja vende como a lista de processar pedidos registos de aplicações e discos de dados
pizzas da sua loja de pizza da pizzaria
Figura 4.1 Uma conta do Azure Storage permite-lhe criar e utilizar uma grande variedade de
funcionalidades de armazenamento, muito além de apenas um lugar para armazenar ficheiros.
¡ Armazenamento de blobs — Para dados não estruturados, como ficheiros de multi-

média e documentos. As aplicações podem armazenar dados no armazenamento
de blobs, como imagens, e compô-los. Pode armazenar imagens das suas pizzas
no armazenamento de blobs.
¡ Armazenamento de tabelas — Para dados não estruturados num armazenamento de
dados NoSQL. Como acontece em qualquer debate sobre armazenamentos de
dados SQL versus NoSQL, planeie a sua aplicação e estime os requisitos de desem-
penho para o processamento de grandes quantidades de dados. Pode arma-
zenar a lista de pizzas no seu menu no armazenamento de tabelas. A Secção 4.3.1
explora o NoSQL com mais detalhe.
Azure Storage 53
¡ Armazenamento de filas — Para as aplicações de cloud comunicarem entre vários

escalões e componentes de uma forma fiável e consistente. Pode criar, ler e elimi-
nar mensagens que passam entre os componentes da aplicação. Pode utilizar o
armazenamento de filas para passar mensagens entre o front-end na Web quando
um cliente faz um pedido e o back-end para processar e assar as pizzas.
¡ Armazenamento de ficheiros — Para uma boa partilha de ficheiros SMB (Server Mes-
sage Block) à moda antiga, acessível por ambas as plataformas Windows e Linux/
macOS. Muitas vezes utilizado para centralizar a coleção de registos de VMs.
O Azure Storage para VMs é simples. Cria e utiliza o Azure Managed Disks, um tipo de
disco rígido virtual (VHD) que retira a abstração de muitas considerações de design
em torno do desempenho e distribui os discos virtuais pela plataforma. Cria uma VM,
anexa todos os discos de dados geridos e permite que a plataforma do Azure descubra
redundância e disponibilidade.
4.3.1 Armazenamento de tabelas

Vamos discutir alguns tipos de armazenamento de dados. O primeiro é o armazenamento
de tabelas. A maioria das pessoas provavelmente está familiarizada com uma base de dados
SQL tradicional, como o Microsoft SQL Server, MySQL ou PostgreSQL. Estas são bases de
dados relacionais, compostas por uma ou mais tabelas que contêm uma ou mais linhas de
dados. As bases de dados relacionais são comuns no desenvolvimento de aplicações e
podem ser projetadas, visualizadas e consultadas de maneira estruturada — o S em SQL
(para Structured Query Language).
As bases de dados NoSQL são um pouco diferentes. Não seguem a mesma aborda-
gem estruturada, e os dados não são armazenados em tabelas onde cada linha contém
os mesmos campos. Existem diferentes implementações de bases de dados NoSQL; os
exemplos incluem MongoDB e CouchDB. As vantagens elogiadas das bases de dados
NoSQL são que são dimensionadas horizontalmente (o que significa que pode adicio-
nar mais servidores em vez de adicionar mais memória ou CPU), podem lidar com
grandes quantidades de dados e são mais eficientes no processamento desses grandes
conjuntos de dados.
A forma como os dados são armazenados numa base de dados NoSQL pode ser defi-
nida em algumas categorias:
¡ Chave-valor, como Redis
¡ Coluna, como Cassandra
¡ Documento, como MongoDB
Cada abordagem tem prós e contras do ponto de vista de desempenho, flexibilidade

ou complexidade. Uma tabela de armazenamento do Azure utiliza um armazena-
mento de chave-valor e é uma boa introdução às bases de dados NoSQL quando está
acostumado a uma base de dados SQL, como o Microsoft SQL ou o MySQL.
Pode fazer download e instalar o Azure Storage Explorer em https://azure.micro-
soft.com/features/storage-explorer se quiser visualizar os dados. Não precisa de fazer
isso agora. O Storage Explorer é uma ótima ferramenta para ver tabelas e filas em ação.
Neste capítulo, não me quero aprofundar demasiado sobre as bases de dados NoSQL.
O capítulo 10 explora algumas bases de dados NoSQL interessantes em detalhe com o
Azure Cosmos DB. Na verdade, no exercício a seguir, utiliza a API do Cosmos DB
para se ligar ao Azure Storage e criar uma tabela. A utilização de tabelas do Azure é mais
uma introdução às bases de dados NoSQL do que um exemplo sólido de utilização em
ambientes de produção.
Por enquanto, execute uma aplicação experimental rápida para ver como pode adicio-
nar e consultar dados, exatamente como faria com uma aplicação real. Estes exemplos
são básicos, mas mostram como pode armazenar os tipos de pizza que vende e quanto
custa cada pizza. Em vez de utilizar algo grande como o Microsoft SQL Server ou
o MySQL, utilize uma base de dados NoSQL com o armazenamento de tabelas do Azure.
Experimente agora
Para ver as tabelas do Azure em ação, conclua os passos a seguir:
1 Abra o portal Azure num browser e abra o Cloud Shell.

2 No capítulo 3, obteve uma cópia dos exemplos do Azure no GitHub. Se não fez
isso, siga estes passos para obter uma cópia:
3 Mude para o diretório que contém os exemplos do Azure Storage:

cd ~/azure-mol-samples-2nd-ed/04
4 Instale algumas dependências do Python, se elas ainda não estiverem instaladas.

Aqui instala o pacote azurerm, que processa a comunicação que permite criar e
gerir recursos do Azure, e dois pacotes azure, que são os SDKs Python subjacen-
tes para o Azure CosmosDB e o Storage:
pip install --user azurerm azure-cosmosdb-table azure-storage-
➥queue==2.1.0
O que significa --user quando instala os pacotes? Se utilizar o Azure
Cloud Shell, não poderá instalar pacotes no sistema core. Não tem permissões.
Em vez disso, os pacotes são instalados no ambiente do utilizador. Estas instala-
ções de pacotes persistem em sessões e permitem que utilize todos os SDKs do
Azure nestes exemplos.
5 Execute a aplicação Python de exemplo para tabelas. Siga as instruções para des-
frutar de uma pizza:
python storage_table_demo.py
Serpentes num avião

Python é uma linguagem de programação amplamente utilizada que é muito utilizada
em classes de “Introdução à Ciência da Computação”. Se trabalha principalmente nas
operações ou na administração de TI, pense em Python como uma poderosa linguagem
Azure Storage 55
de script que funciona em SOs. O Python não se destina apenas ao scripting; também
pode ser utilizado para criar aplicações complexas. Por exemplo, o Azure CLI que está a
utilizar é escrito em Python.
Utilizo Python para alguns dos exemplos neste livro porque estes devem funcionar fora
do Cloud Shell sem modificação. As distribuições de macOS e Linux são nativamente
incluídas com Python. Os utilizadores do Windows podem fazer download e instalar rapi-
damente Python e, em seguida, executar estes scripts localmente. Python é ótimo para
aqueles com pouca experiência de programação, como para os programadores mais
experientes que estão familiarizados com outras linguagens. A documentação do Azure
para o Azure Storage e muitos outros serviços fornece suporte para diversas linguagens,
incluindo .NET, Java e Node.js. Não está limitado a utilizar Python ao criar as suas pró-
prias aplicações que utilizam tabelas.
O Quick Python Book, 3.ª edição, de Naomi Ceder (http://mng.bz/6QZA), pode
ajudar a atualizar-se, se quiser saber mais. Há também um curso baseado em vídeo
para Get Programming with Python in Motion, de Ana Bell (http://mng.bz/oPap).
4.3.2 Armazenamento de filas

As tabelas do Azure são fantásticas quando começa a mergulhar no mundo do desen-
volvimento de aplicações na cloud. À medida que começa a criar e gerir aplicações
nativamente na cloud, normalmente divide uma aplicação em componentes menores
que podem dimensionar e processar dados por conta própria. Para permitir que estes
componentes comuniquem e transmitam dados, por norma, é necessária alguma
forma de fila de mensagens. Apresentamos o Azure Queues.
O serviço Azure Queues permite que crie, leia e elimine mensagens
que carregam pequenos blocos de dados. Estas mensagens são criadas e obtidas por
diferentes componentes de aplicações à medida que transmitem os dados. O Azure
Queues não elimina uma mensagem até que uma aplicação tenha terminado de pro-
cessar os dados da mensagem.
Experimente agora
Para ver o Azure Queues em ação, execute o seguinte script de Python a partir do mesmo
diretório azure-samples/4. Siga os avisos para ver as mensagens escritas, lidas e elimi-
nadas da fila:
python storage_queue_demo.py
Continue com a aplicação experimental que lida com pedidos de pizza. Pode ter um
componente de aplicação front-end com o qual os clientes interagem para encomen-
dar as pizzas e uma fila de mensagens que transmite mensagens para um componente
de aplicação de back-end que processa esses pedidos. Conforme os pedidos são recebi-
dos, as mensagens na fila podem ser visualizadas como mostrado na figura 4.2.
Figura 4.2 As mensagens são recebidas do componente de aplicação front-end que detalha a pizza que cada
cliente pediu na propriedade Message Text.
Conforme o componente de aplicação de back-end processa cada pedido de uma

pizza, as mensagens são removidas da fila. A figura 4.3 mostra como fica a fila quando
tem uma pizza vegetariana no forno e essa primeira mensagem é removida.
Figura 4.3 À medida que cada mensagem é processada, é removida da fila. A primeira mensagem mostrada
na figura 4.2 foi removida depois de ser processada pelo componente de aplicação de back-end.
4.3.3 Disponibilidade e redundância de armazenamento

Os datacenters do Azure são concebidos para serem tolerantes a falhas, com ligações
de Internet redundantes, geradores de energia, vários caminhos de rede, matrizes de
armazenamento e assim por diante. Ainda precisa de fazer a sua parte ao projetar e
executar aplicações. Com o Azure Storage, escolhe o nível de redundância de armaze-
namento necessário. Este nível varia para cada aplicação e em função da importância
dos dados. Seguem-se as opções de redundância de armazenamento disponíveis:
¡ Armazenamento localmente redundante (LRS) — Os seus dados são replicados três
vezes dentro do datacenter único no qual a conta de armazenamento foi criada.
Esta opção fornece redundância no caso de uma única falha de hardware, mas se
o datacenter inteiro for desligado (é raro, mas possível), os seus dados serão per-
didos também.
¡ Armazenamento com redundância entre zonas (ZRS) — O próximo nível acima de LRS
replica os seus dados três vezes em dois ou três datacenters numa região (quando
existem vários datacenters numa região) ou entre regiões. O ZRS também está
disponível nas zonas de disponibilidade, que exploramos no capítulo 7.
Laboratório: Explorar o Azure Storage 57
¡ Armazenamento georredundante (GRS) — Com o GRS, os seus dados são replicados

três vezes na região primária em que o armazenamento é criado e, em seguida,
replicados três vezes numa região emparelhada. Geralmente, a região empare-
lhada está a centenas ou milhares de quilómetros de distância. A região E.U.A.
Oeste está emparelhada com a região E.U.A. Leste, por exemplo; o norte da
Europa está emparelhado com a Europa Ocidental e o Sudeste Asiático está
emparelhado com a Ásia Oriental. O GRS oferece uma ótima opção de redun-
dância para as aplicações de produção.
¡ Armazenamento georredundante só de leitura (RA-GRS) — É a opção premium de
redundância de dados. Os seus dados são replicados em regiões emparelhadas
como no GRS, mas também pode ter acesso de leitura aos dados nessa zona
secundária.
4.4 Laboratório: Explorar o Azure Storage

Eis a oportunidade que tem para testar as suas competências. Escolha uma das tarefas
a seguir para concluir o seu exercício de laboratório.
4.4.1 Focado na VM
Se quiser iniciar sessão numa VM e ver que o processo para inicializar um disco e criar
um sistema de ficheiros é o mesmo que qualquer outra VM com a qual tenha traba-
lhado, experimente um destes exercícios:
1 Inicie sessão na VM que criou na secção 4.2. Dependendo da sua escolha, irá
ligar-se com SSH ou RDP.
2 Inicialize o disco e crie uma partição.
¡ No Linux, o fluxo é fdisk, mkfs e mount.
¡ No Windows, utilize qualquer sequência com a qual esteja familiarizado — pro-
vavelmente Gestão de Discos > Inicializar > Criar Volume > Formato.
4.4.2 Focado no programador

Se trabalhar mais como programador e não quiser descobrir como inicializar discos de
dados numa VM, volte para o Cloud Shell e explore as duas demonstrações Python que
utilizam tabelas e filas. Mesmo que seja novo no Python, deve ser capaz de acompanhar
o que está a acontecer:
¡ Pense em alguns cenários em que poderia implementar tabelas ou filas nas
suas próprias aplicações. Do que seria preciso para criar aplicações nativas da
cloud com componentes de aplicações individuais que pudessem utilizar filas,
por exemplo?
¡ Modifique um dos exemplos que lhe interessam, para criar um item de menu de
pizza adicional (se for uma tabela) ou uma nova mensagem de pedido de pizza
(se for uma fila).
Noções básicas do Azure
Networking
5
No capítulo 4, explorou o serviço Azure Storage. Um dos outros servi-
ços core para as aplicações de cloud é o Azure Networking. O Azure tem muitas fun-
cionalidades de rede poderosas para proteger e encaminhar o tráfego a uma escala
verdadeiramente global. Estas funcionalidades são concebidas para ajudar a focar em
como criar e manter as suas aplicações, para que não tenha que se preocupar com
detalhes como endereços IP e tabelas de rotas. Se criar e executar uma loja online
para lidar com pedidos de pizzas, a mesma deverá transmitir com segurança os dados
do cliente e processar as transações de pagamento.
Este capítulo examina as redes virtuais e as sub-redes do Azure e fala sobre como
criar interfaces de rede virtual. Para proteger e controlar o fluxo de tráfego, cria grupos
e regras de segurança de rede. Se o funcionamento em rede é novidade para si, ou se já
passou algum tempo desde que teve de trabalhar com endereços IP e placas de rede,
pode demorar mais algum tempo neste capítulo. Tem muitos exercícios Experimente
agora. No entanto, vale a pena dedicar algum tempo à compreensão deste capítulo,
pois o funcionamento em rede é fundamental para muitos dos serviços no Azure.
5.1 Componentes de rede virtual

Pense em quantos cabos estão atrás da sua mesa de computador ou no seu centro
de entretenimento. Agora pense em todos os cabos necessários para ligar os compu-
tadores num determinado piso de um edifício de escritórios. E em todo o edifício
de escritórios? Já esteve num datacenter ou viu fotografias de um? Tente imaginar
como os datacenters do Azure são grandes. Agora tente imaginar dezenas de data-
centers do Azure, em todo o mundo. A matemática não é o meu ponto forte, por
isso não posso calcular quantos quilómetros de cabos de rede são utilizados para
todo o tráfego no Azure!
58
Componentes de rede virtual 59
A conectividade de rede é uma parte crucial da vida moderna. No Azure, a rede é

fundamental para a comunicação de todos os elementos. Para todos os milhares de dis-
positivos de rede física e quilómetros de cabos de rede que ligam cada um dos elemen-
tos num datacenter do Azure, trabalha com recursos de rede virtual. Como? Redes
definidas por software. Quando cria uma VM ou uma aplicação Web, um técnico não
precisa de ir ao datacenter do Azure para ligar os cabos fisicamente e atribuir endere-
ços IP (embora isso seja engraçado de assistir!). Em vez disso, todos os recursos de rede
que definem todo o ambiente de rede são tratados logicamente pela plataforma do
Azure. A figura 5.1 mostra os componentes de rede virtual que irá criar neste capítulo.
Rede virtual
Sub-rede: regra Web para Sub-rede: regra remota para

permir o tráfego HTTP permir o tráfego SSH
Endereço IP público da Endereço IP público da
interface de rede + DNS interface de rede + DNS
VM caixa
VM Web
de salto
Figura 5.1 Ligações de rede definidas por software no Azure
Alguns dos componentes de rede serão abstraídos se utilizar recursos de PaaS. Os com-
ponentes principais que utiliza para as VMs são os seguintes:
¡ Redes virtuais e sub-redes (incluindo conjuntos de endereços IP)
¡ Placas de interface de rede virtual
¡ Um ou mais endereços IP públicos
¡ Nome DNS interno e nomes DNS públicos opcionais para a resolução de
nomes externos
¡ Grupos de segurança de rede e regras, que protegem e controlam o fluxo
de tráfego de rede como uma firewall normal faz
5.1.1 Redes virtuais e sub-redes

Quando criou uma VM no capítulo 2, não foi necessário ajustar nenhum parâmetro de
rede. A plataforma do Azure pode criar estes recursos para si com nomes predefinidos
e âmbitos de endereço IP. Nesta secção, vai criar os recursos de rede com antecedência
e ver como eles combinam numa VM.
60 Capítulo 5 Noções básicas do Azure Networking
Experimente agora
Em geral, é mais fácil visualizar as redes quando elas podem ser observadas em ação.
Vai utilizar o portal Azure para começar, o que acaba por ter alguns passos separados,
mas verá o poder do Azure CLI mais tarde no capítulo.
Não se preocupe muito sobre como utilizar os seus próprios espaços de endereço
ou nomes DNS personalizados. Para criar a sua rede virtual e sub-rede, conclua os pas-
sos a seguir:
1 Abra o portal Azure e selecione Criar um Recurso no canto superior esquerdo

do dashboard.
2 Selecione Funcionamento em Rede na lista de serviços do Marketplace e escolha
Virtual Network.
3 Introduza um nome para a rede virtual, como vnetmol.
4 Para brincar um pouco mais, mude o espaço de endereço para 10.0.0.0/16.
Intervalos de endereços IP
As redes virtuais abrangem um determinado intervalo de IPs—um espaço de endereço.
Se já viu um endereço IP, pode ter reparado na máscara de sub-rede, muitas vezes algo
como 255.255.255.0. Esta máscara de sub-rede é frequentemente utilizada numa
forma abreviada que especifica o tamanho do intervalo, como /24.
O portal Azure assume por predefinição um espaço de endereço /24. Se pretender
aumentar o número de intervalos IP adicionais aqui sem ter que saber muito sobre
redes, basta aumentar o espaço de endereço para /16. Este tipo de endereço IP não se
concede diretamente a uma VM. No próximo passo, cria uma sub-rede que abrange uma
secção menor deste espaço de endereço.
Se os espaços de endereço de rede forem totalmente estranhos para si, não se preo-
cupe. Na maioria das vezes, não precisa de lidar com eles diariamente. A governação
sensata do Azure pode funcionar da mesma forma que no seu mundo de TI existente
on-premises: um grupo de pessoas pode gerir as redes virtuais do Azure e coloca as
suas aplicações num espaço pré-criado.
5 Crie um grupo de recursos, como azuremolchapter5, e selecione

uma região do Azure próxima de si.
6 Forneça um nome de sub-rede, como websubnet, e introduza o intervalo de
endereços de sub-rede 10.0.1.0/24. Este intervalo de endereços faz parte da
rede virtual mais ampla especificada anteriormente. Posteriormente, irá adicio-
nar outra sub-rede.
7 Veja algumas das outras opções, tais como a proteção contra ataques Denial of
Service distribuído (DDoS), os endpoints do serviço e o Azure Firewall. Deixe as
predefinições por agora, mas espero que este exemplo lhe forneça algumas dicas
sobre o que é possível para além de uma rede virtual básica.
8 Quando estiver pronto, crie a rede e sub-rede virtual.
5.1.2 Placas de interface de rede virtual

Agora que criou uma rede virtual e uma sub-rede, precisa de ligar uma VM. Assim
como faz com um PC de secretária, portátil ou tablet normal, utiliza uma placa de
interface de rede (NIC) para se ligar à rede virtual. E não, não há redes Wi-Fi gratuitas!
Mas há tamanhos de VM no Azure que atualmente fornecem até oito NICs com veloci-
dades de até 32 Gbps. Embora não seja bom em matemática, percebo que isso resulta
numa largura de banda considerável!
Provavelmente iria perguntar a si próprio porquê criar cada um destes recursos com
antecedência. Pode fazer tudo isto quando cria uma VM. Isso é verdade, mas dê um
passo para trás e pense nos recursos de rede como recursos de longa duração.
Os recursos de rede existem separadamente dos recursos de VM e podem persistir
além do ciclo de vida de uma determinada VM. Este conceito permite criar os recursos
de rede fixos e criar, eliminar e criar novamente uma VM que mantém os mesmos
recursos de rede, como os endereços IP e os nomes DNS. Pense numa VM de laborató-
rio ou num ambiente de desenvolvimento e teste. Pode reproduzir o mesmo ambiente
exato rapidamente, pois apenas a VM é alterada.
Experimente agora
Para criar uma NIC, conclua os passos que se seguem:
1 No portal Azure, selecione Criar um Recurso no canto superior esquerdo do dash‑

board.
2 Procure e selecione Interface de Rede e, em seguida, selecione Criar.
3 Forneça um nome para a sua interface de rede, como webvnic e, em seguida,
selecione a rede virtual e a sub-rede criadas no exercício anterior.
4 Falei anteriormente sobre os recursos de longa duração, vamos então ver como
funcionam. Crie uma atribuição de endereço IP estático que utilize o endereço
10.0.1.4.
SUGESTÃO Porquê .4? E os três primeiros endereços no espaço de endereço?

O Azure reserva os três primeiros endereços IP em cada intervalo para sua pró-
pria gestão e encaminhamento. O primeiro endereço utilizável que pode utili-
zar em cada intervalo é .4.
5 Não crie um grupo de segurança de rede por agora. Irá voltar ao mesmo em
alguns minutos. Se é inteligente e sabe tudo sobre IPv6, marque a caixa Ende-
reço IP Privado (IPv6) e forneça um nome. Caso contrário, utilize o IPv4.
6 Selecione o grupo de recursos existente do exercício anterior e, em seguida,
escolha criar a NIC na mesma região que a rede virtual.
7 Quando estiver pronto, crie a NIC.
Separação de funções no Azure

Não precisa de criar outros recursos de computação dentro do mesmo grupo de recur-
sos que a sua rede virtual. Pense novamente no conceito de governação do Azure que
discutimos anteriormente. Pode ter um grupo de engenheiros de rede que gerem todos
os recursos de rede virtual no Azure. Quando cria recursos para as suas aplicações,
como VMs, cria-os e gere-os nos seus próprios grupos de recursos.
Nos capítulos posteriores, falamos sobre alguns dos recursos de segurança e política no
Azure que permitem que defina quem pode aceder e editar determinados recursos.
A ideia é que, se não sabe, ou não quer saber, utilizar uma grande quantidade de recur-
sos da rede, pode ligar-se ao que é fornecido, e pronto. O mesmo se aplica a outros enge-
nheiros ou programadores; eles podem ser capazes de ver os recursos da aplicação,
mas não editá-los nem eliminá-los.
Este tipo de modelo de governação no Azure é bom, mas tenha cuidado para evitar a
armadilha de trabalhar em silos. Em grandes empresas, pode ser inevitável ficar restrito
a linhas de departamento. Mas uma das grandes vantagens dos fornecedores de cloud
computing como o Azure é acelerar o tempo de implementação de aplicações, pois não
precisa de esperar que os recursos de rede física sejam cabeados e configurados. Se
planear criar e configurar os recursos de rede do Azure, poderá criar e gerir os recursos
das aplicações sem problemas.
5.1.3 Endereço IP público e resolução de DNS

Ninguém pode aceder aos seus recursos ainda, porque nenhum endereço IP público
ou nome DNS está associado aos mesmos. Novamente, siga o princípio dos recursos de
longa duração para criar um endereço IP público e um nome DNS público e, em
seguida, atribua-os à sua interface de rede.
Experimente agora
Para criar um endereço IP público e uma entrada DNS para a sua interface de rede, con-
clua os passos a seguir:

board.
2 Procure e selecione Endereço IP Público e, em seguida, selecione Criar.
3 Crie um endereço IPv4 e SKU básicos. Os SKUs padrão e os endereços IPv6
devem ser utilizados com balanceadores de carga (capítulo 8). Não se preocupe
muito com as diferenças neste momento.
4 Introduza um nome, tal como webpublicip, que utilize uma atribuição
dinâmica.
Tipos de atribuição de endereços IP

Uma atribuição dinâmica aloca um endereço IP público quando a VM é iniciada.
Quando a VM é interrompida, o endereço IP público é desalocado. Há alguns
pontos importantes aqui:
¡ Não terá um endereço IP público até que o tenha atribuído a uma VM

e a tenha iniciado.
¡ O endereço IP público poderá ser alterado se parar, desalocar e iniciar a VM.
Uma atribuição estática é um endereço IP público alocado sem uma VM associada,
e esse endereço não mudará. Esta atribuição é útil quando está a utilizar um certificado
SSL mapeado para um endereço IP, ou um nome DNS personalizado e um registo que
aponta para o endereço IP.
Agora, está a utilizar uma única VM. Para utilização em ambientes de produção, o ideal é
executar a sua aplicação em várias VMs com um balanceador de carga com elas. Nesse
cenário, o endereço IP público é atribuído ao balanceador de carga e normalmente cria
uma atribuição estática nesse ponto.
5 Introduza um nome DNS exclusivo. Este nome forma o nome de domínio com-
pletamente qualificado (FQDN) do recurso baseado na região do Azure em que
o cria. Se criar uma etiqueta de nome DNS para azuremol na região E.U.A. Leste,
por exemplo, o FQDN torna-se azuremol.eastus.cloudapp.azure.com.
Entradas de DNS
Que tal um nome DNS personalizado? O FQDN predefinido não é exatamente fácil de
utilizar! Utilize um endereço IP público estático e, em seguida, crie um registo CNAME na
sua zona DNS registada. Retém o controlo do registo DNS e pode criar quantas entradas
pretender para as suas aplicações.
Como exemplo, na zona DNS manning.com, pode criar um CNAME para azuremol que
aponta para um endereço IP público estático no Azure. Um utilizador iria aceder a azure-
mol.manning.com para obter a sua aplicação. Este endereço é muito mais fácil do que
webmol.eastus.cloudapp.azure.com!
6 Selecione o grupo de recursos existente do exercício anterior e, em seguida,

escolha criar o endereço IP público na mesma região que a rede virtual.
7 Quando estiver pronto, crie o endereço IP público.
8 Associe o endereço IP público e a etiqueta de nome DNS à interface de rede que
criou na secção 5.1.2. Navegue para o Grupo de Recursos e selecione-o na barra
de navegação no lado esquerdo do portal Azure. Em seguida, escolha o grupo de
recursos no qual criou os recursos de rede, como azuremolchapter5.
9 Selecione o seu endereço IP público na lista de recursos e escolha Associar.
10 Escolha associar com uma interface de rede (mas tenha em atenção a que mais
pode associar o endereço IP público); em seguida, escolha a interface de rede
que criou, tal como webvnic.
Depois de alguns segundos, a janela do endereço IP público é atualizada para mostrar

que o endereço IP agora está associado à sua interface de rede. Se selecionou Dinâ-
mico como o tipo de atribuição, o endereço IP ainda está em branco, como mostrado
na figura 5.2. Lembre-se de que um endereço IP público é alocado quando uma VM
associada está ligada.
Figura 5.2 O endereço IP público está associado a uma interface de rede. Com uma atribuição
dinâmica, nenhum endereço IP público é mostrado até que uma VM seja criada e ligada.
5.2 Proteger e controlar o tráfego com grupos de

segurança de rede
Vamos fazer um mini-teste: Deve ligar uma VM à Internet sem uma firewall para con-
trolar e restringir o fluxo de tráfego? Se a sua resposta for "Claro, por que não?", creio
que vá ter de dedicar o seu intervalo de almoço para ler um pouco sobre segurança de
rede na selva da Web.
Espero que a sua resposta tenha sido um “Não!” redondo. Infelizmente, existe uma
grande possibilidade de a sua VM sofrer um ciberataque automatizado pouco tempo
depois de ser ligada. Deve seguir sempre as melhores práticas para manter o sistema
operativo e a aplicação atualizados. No entanto, não se aconselha permitir que o trá-
fego de rede chegue à sua VM se não for necessário. Um computador macOS ou Win-
dows normal tem uma firewall de software incorporada e cada rede (competente)
on-premises que vi tem uma firewall de rede entre a Internet e a rede interna. No Azure,
as regras de firewall e tráfego são fornecidas por grupos de segurança de rede.
5.2.1 Criar um grupo de segurança de rede

No Azure, um NSG aplica logicamente um conjunto de regras aos recursos de rede.
Estas regras definem o tráfego que pode entrar e sair da VM. Define quais portas, pro-
tocolos e endereços IP são permitidos e em que direção. Estes grupos de regras podem
ser aplicados a uma única interface de rede ou a uma sub-rede de rede inteira. Esta
flexibilidade permite-lhe controlar detalhadamente como e quando as regras são apli-
cadas para satisfazer as necessidades de segurança da sua aplicação.
Proteger e controlar o tráfego com grupos de segurança de rede 65
A figura 5.3 mostra o fluxo lógico de um pacote de rede de entrada à medida que
passa por um NSG. O mesmo processo seria aplicado aos pacotes de saída. O host do
Azure não diferencia o tráfego da Internet e o tráfego de outro lugar dentro do
ambiente do Azure, como outra sub-rede ou rede virtual. Qualquer pacote de rede de
entrada tem as regras do NSG de entrada aplicadas e qualquer pacote de rede de saída
tem as regras do NSG de saída aplicadas.
Aplicar a Sim
próxima regra
do NSG
Aplicar primeira As regras Não Mais

regra NSG coincidem? regras?
Sim Não Figura 5.3 Os pacotes de

entrada são examinados e
Recusar Sim cada regra do NSG é aplicada
regra? Ignorar pacote em ordem de prioridade. Se for
efetuada uma correspondên-
Não
cia de regra Permitir ou
Recusar, o pacote será
encaminhado para a VM
Permir pacote
ou largado.
Veja o que acontece com cada pacote de rede:
1 A primeira regra do NSG é aplicada.

2 Se a regra não corresponder ao pacote, a próxima regra será carregada até que
não haja mais regras. Em seguida, a regra predefinida para largar o pacote
é aplicada.
3 Se uma regra corresponder, verifique se a ação consiste em recusar o pacote. Em
caso afirmativo, o pacote é largado.
4 Caso contrário, se a regra consistir em permitir o pacote, o pacote será transmi-
tido para a VM.
Em seguida, vai criar um NSG para que estes conceitos comecem a fazer sentido.
Experimente agora
Para criar um grupo de segurança de rede, conclua os passos a seguir:

board.
2 Procure e selecione Grupo de Segurança de Rede e, em seguida, selecione Criar.

3 Introduza um nome, tal como webnsg, e opte por utilizar o grupo de recursos
existente.
Pronto! A maior parte da configuração de um NSG acontece quando cria as regras de
filtragem. A Secção 5.2.2 fala sobre como fazer isso e colocar o seu NSG a funcionar.
5.2.2 Associar um grupo de segurança de rede a uma sub-rede

O NSG não contribui demasiado para a proteção das suas VMs sem regras. Também
precisa de o associar a uma sub-rede, da mesma forma que associou o seu endereço IP
público a uma interface de rede anteriormente. Em primeiro lugar, vai associar o seu
NSG a uma sub-rede.
Experimente agora
Para associar a sua sub-rede de rede virtual ao grupo de segurança de rede, conclua
os passos a seguir:
1 Navegue para o Grupo de Recursos e selecione-o na barra de navegação no lado

esquerdo do portal Azure. Em seguida, escolha o grupo de recursos no qual
criou os recursos de rede, como azuremolchapter5.
2 Selecione o seu NSG, como webnsg.
3 Do lado esquerdo, nas opções de Definições, encontra as Interfaces de Rede e
Sub-redes. Escolha Sub-redes.
4 Selecione o botão Associar, selecione a rede virtual e a sub-rede de rede criadas
anteriormente e, em seguida, selecione OK para associar o NSG à sub-rede.
A flexibilidade dos NSGs significa que pode associar várias sub-redes, em várias
redes virtuais, a um único NSG. O mapeamento é de um para muitos, o que per-
mite definir regras de segurança de rede principais que se aplicam a uma ampla
variedade de recursos e aplicações.
Agora pode ver como é o seu NSG e que regras predefinidas são aplicadas.
5 No lado esquerdo do NSG, selecione Regras de Segurança de Entrada. Nenhuma
regra de segurança é listada, pelo menos nenhuma que criou.
6 Selecione Regras Predefinidas para ver o que a plataforma do Azure cria para si,
como mostrado na figura 5.4.
Proteger e controlar o tráfego com grupos de segurança de rede 67
Figura 5.4 São criadas regras de segurança predefinidas que permitem o tráfego da rede virtual interna ou do
balanceador de carga, mas recusam todo o outro tráfego.
Foram criadas três regras predefinidas para si. É importante enten-
der estas regras:
¡ AllowVnetInBound — Permite qualquer tráfego que seja interno à rede virtual. Se
tiver várias sub-redes na sua rede virtual, o tráfego não será filtrado por predefini-
ção e será permitido.
¡ AllowAzureLoadBalancerInBound — Permite que qualquer tráfego de um balancea-
dor de carga do Azure chegue à sua VM. Se colocar um balanceador de carga
entre as suas VMs e a Internet, esta regra irá garantir que o tráfego do balancea-
dor de carga chegue às suas VMs, como para monitorizar uma pulsação.
¡ DenyAllInBound — A regra final que é aplicada. Larga os pacotes de entrada que
chegaram até esse ponto. Se não existirem regras Permitir anteriores, esta regra
irá largar todo o tráfego por predefinição. Só precisa de permitir qualquer trá-
fego específico pretendido. O resto é largado.
A prioridade de uma regra do NSG é importante. Se for aplicada uma regra Permitir
ou Negar, não serão aplicadas regras adicionais. As regras são aplicadas em ordem de
prioridade numérica ascendente; uma regra com prioridade 100 é aplicada antes de
uma regra com uma prioridade 200, por exemplo.
Tal como se discutiu anteriormente sobre a governação de recursos do Azure, estas
regras do NSG já podem ser criadas e aplicadas a uma determinada sub-rede. Cria as
suas VMs e executa as suas aplicações e outra pessoa gere os NSGs.
É importante entender como o tráfego flui caso ocorra algum problema. Algumas
ferramentas no Azure podem ajudá-lo a determinar por que o tráfego pode não chegar
à sua aplicação quando deveria!
5.2.3 Criar regras de filtragem de grupos de segurança de rede

Agora que tem o NSG associado à sub-rede de rede e que analisámos as regras predefi-
nidas, crie uma regra do NSG básica que permita o tráfego HTTP.
Experimente agora
Para criar as suas próprias regras com o grupo de segurança de rede, conclua os passos
a seguir:
1 Para criar uma regra do NSG a partir da janela anterior do portal Azure, sele-
cione Adicionar na secção Regras de Segurança de Entrada.
2 Tem duas opções para criar regras: Básico e Avançado. Para criar regras pré-cria-
das rapidamente, selecione Básico na parte superior da janela.
3 Escolha HTTP no menu pendente Serviço. São fornecidos muitos serviços pre-
definidos, como SSH, RDP e MySQL. Quando seleciona um serviço, é aplicado o
intervalo de portas apropriado: nesse caso, a porta 80. A ação predefinida sobre
as regras básicas permite o tráfego.
4 É atribuído um valor de prioridade a cada regra. Quanto menor o número,
maior a prioridade. Aceite a prioridade baixa predefinida, como 100.
5 Aceite o nome predefinido ou forneça o seu próprio nome. Em seguida,
selecione OK.
5.3 Criar uma aplicação Web de exemplo com tráfego seguro

Até agora, criou uma rede virtual e uma sub-rede. Em seguida, criou uma interface de
rede e associou um endereço IP público e uma etiqueta de nome DNS. Criou um NSG
que aplicou a toda a sub-rede, e criou uma regra do NSG para permitir o tráfego HTTP.
Mas falta uma coisa: a VM.
5.3.1 Criar ligações de rede de acesso remoto

No ambiente de produção, não deve abrir o acesso remoto, como SSH ou RDP, às VMs
que executam as suas aplicações. Normalmente, tem uma VM jumpbox separada à
qual se liga através da Internet e, em seguida, acede às VMs adicionais através da liga-
ção interna. Até agora, criou todos os recursos de rede virtual no portal Azure. Agora
vamos mudar para o Azure CLI para ver a rapidez com que pode criar estes recursos a
partir da linha de comandos
Experimente agora
Criou o primeiro NSG no portal Azure. Para criar outro NSG com a CLI do Azure,
conclua os passos a seguir:
1 Selecione o ícone do Cloud Shell na parte superior do dashboard do portal

Azure. Certifique-se de que se abre a shell do Bash, não o PowerShell.
2 Crie um NSG adicional no grupo de recursos existente. Como nos capítulos
anteriores, as barras invertidas (\) nos exemplos de comando a seguir servem
para indicar as quebras de linha, mas se não quiser não precisa de as introduzir.
Forneça um nome, como remotensg:
az network nsg create \
--name remotensg
3 Crie uma regra do NSG no novo NSG que permita a porta 22. Forneça o grupo
de recursos e o NSG que criou no passo anterior, juntamente com um nome,
como allowssh:
az network nsg rule create \
Criar uma aplicação Web de exemplo com tráfego seguro 69
--nsg-name remotensg \
--name allowssh \
--protocol tcp \
--priority 100 \
--destination-port-range 22 \
--access allow
4 Crie uma sub-rede de rede para a sua VM remota. Forneça um nome de sub-
-rede, como remotesubnet, juntamente com um prefixo de endereço dentro do
intervalo da rede virtual, como 10.0.2.0/24. Também anexa o NSG que criou
no passo 3 à sub-rede, como remotensg:
az network vnet subnet create \
--vnet-name vnetmol \
--name remotesubnet \
--address-prefix 10.0.2.0/24 \
--network-security-group remotensg
Tudo do que precisa para criar uma sub-rede, um NSG e uma regra são três comandos.
Sente o poder do Azure CLI? O Azure PowerShell é igualmente poderoso, portanto, não
pense que deve criar todos os recursos no portal Azure. À medida que for avançando
no livro, irá utilizar o Azure CLI em vez do portal na maioria dos casos.
5.3.2 Criar VMs

Com todos os componentes de rede no lugar, está pronto para criar duas VMS. Uma VM
é criada na sub-rede que permite o tráfego HTTP para que possa instalar um servidor
Web. A outra VM é criada na sub-rede que permite SSH para que tenha uma jumpbox
para proteger ainda mais o seu ambiente de aplicação e começar a replicar uma imple-
mentação de produção. A figura 5.5 irá servir como recordação do que está a criar.
Rede virtual
Sub-rede: regra Web para Sub-rede: regra remota

permir o tráfego HTTP para permir o tráfego SSH
Endereço IP público da Endereço IP público da
interface de rede + DNS interface de rede + DNS
VM caixa
VM Web
de salto
Figura 5.5 Está a reunir duas sub-redes, NSGs, regras, interfaces de rede e VMs.
Este exemplo é semelhante a uma implementação pronta para produção em que uma
VM executa o servidor Web e está aberta ao tráfego público. É utilizada outra VM
numa sub-rede separada para as ligações remotas ao resto do ambiente de aplicação.
Quando cria uma VM, pode fornecer a interface de rede virtual que criou anterior-
mente. Se não especificou este recurso de rede, o Azure CLI cria uma rede virtual, uma
sub-rede e uma NIC utilizando os valores predefinidos incorporados. É ótimo para
criar uma VM rapidamente, mas é recomendado seguir o princípio dos recursos de
rede de longa duração. Estes recursos podem ser geridos por outra equipa e são o local
onde irá criar as suas VMs.
Experimente agora
Para utilizar o CLI Azure para criar o servidor Web e as VMs jumpbox, complete
os seguintes passos:
1 Crie a primeira VM para o seu servidor Web e forneça um nome, como webvm.
Anexe a interface de rede, como webvnic, e introduza uma imagem, como Ubun-
tuLTS. Forneça um nome de utilizador, como azuremol. O passo final, --generate-
ssh-keys, adiciona à VM as chaves SSH que criou no capítulo 2:
az vm create \
--name webvm \
--nics webvnic \
--image UbuntuLTS \
--generate-ssh-keys
2 Crie a segunda VM para a jumpbox. Este exemplo mostra como pode utilizar
uma sub-rede existente e o NSG e permitir que a CLI do Azure crie a interface de
rede e faça as ligações apropriadas. Crie um endereço IP público, como remote-
publicip, como parte deste comando:
az vm create \
--name remotevm \
--subnet remotesubnet \
--nsg remotensg \
--public-ip-address remotepublicip \
--image UbuntuLTS \
--generate-ssh-keys
A saída de ambos os comandos mostra um endereço IP público. Tome nota destes

endereços IP. No exercício seguinte, se tentar utilizar SSH com a primeira VM para
o servidor Web, irá ocorrer um erro. Porquê? Pode utilizar SSH com a VM remota por-
que criou uma regra do NSG para permitir apenas tráfego HTTP para a VM Web.
Criar uma aplicação Web de exemplo com tráfego seguro 71
5.3.3 Utilizar o agente SSH para se ligar às suas VMs

Existe um truque no SSH para que possa utilizar a jumpbox corretamente e ligar-se à
VM Web através da rede virtual do Azure: o agente SSH. Este agente só se aplica a VMs
Linux, portanto, se trabalha principalmente com VMs Windows e ligações de ambiente
de trabalho remoto (RDP), não se preocupe se isto parecer uma novidade. Pode criar
ligações RDP as VMS do Windows a partir da sua jumpbox com as credenciais remotas
locais, ou com credenciais de domínio se configurar o servidor apropriadamente.
Um agente SSH pode armazenar as suas chaves SSH e encaminhá-las conforme necessá-
rio. No capítulo 2, quando criou um par de chaves públicas SSH, falei sobre a chave pública
e privada. A chave privada é algo que permanece no seu computador. Apenas a chave
pública é copiada para as VMs remotas. Embora a chave pública tenha sido adicionada às
duas VMs que criou, não é possível simplesmente utilizar SSH para a sua jumpbox e, em
seguida, para a VM Web. Porquê? Essa jumpbox não tem uma cópia da sua chave privada.
Quando tenta fazer a ligação SSH a partir da jumpbox, esta não tem nenhuma chave pri-
vada que se possa emparelhar com a chave pública na VM Web para a sua autenticação.
A chave privada é algo que deve proteger, por isso não deve seguir o caminho mais fácil
ao copiar a chave privada para a jumpbox. Quaisquer outros utilizadores que acederem à
jumpbox poderão obter uma cópia da sua chave privada e, em seguida, usar a sua identi-
dade em qualquer lugar em que a chave é utilizada. É aqui que o agente SSH entra em cena.
Se executar o agente SSH na sua sessão do Cloud Shell, poderá adicionar as chaves SSH
à mesma. Para criar a sua ligação SSH à jumpbox, especifique a utilização deste agente para
que envie a sua sessão por túnel. Com esta técnica, poderá passar efetivamente através da
chave privada da jumpbox, sem nunca ter de copiar essa chave privada. Quando utiliza o
SSH da jumpbox para a VM Web, o agente SSH envia por túnel a chave privada através
da jumpbox e, dessa forma, pode autenticar-se
Experimente agora
Para utilizar o SSH com a sua VM jumpbox, conclua os passos a seguir:
1 No Cloud Shell, inicie o agente SSH da seguinte forma:

eval $(ssh-agent)
2 Adicione a chave SSH que criou no capítulo 2 ao agente da seguinte maneira:

ssh-add
3 SSH à VM jumpbox. Especifique a utilização do agente SSH com o parâmetro -A.

Introduza o seu próprio endereço IP público que foi mostrado na saída quando
criou a VM jumpbox:
ssh -A azuremol@<publicIpAddress>
4 Esta é a primeira vez que criou uma ligação SSH à VM jumpbox, portanto, aceite
o aviso para se ligar com as chaves SSH.
5 Lembra-se como criou uma atribuição de endereços IP privados estáticos para a

VM Web na secção 5.1.2? Este endereço estático facilita muito a utilização de
SSH. Utilize SSH para a VM Web da seguinte forma:
ssh 10.0.1.4
6 Aceite o aviso para continuar a ligação SSH. O agente SSH envia por túnel a
chave SSH privada através da jumpbox e permite-lhe estabelecer uma ligação com
sucesso à VM Web. E agora? Bem, tem um laboratório para ver este trabalho!
5.4 Laboratório: instalar e testar o servidor Web LAMP

Já fez o trabalho duro durante todo o capítulo. Este laboratório rápido reforçará os
seus conhecimentos sobre como instalar um servidor Web e permite-lhe ver a regra do
NSG na sua VM em ação:
1 Instale um servidor Web Linux básico. Recorde-se do capítulo 2 quando criou uma
ligação SSH à VM e, em seguida, instalou o pacote de servidor Web LAMP com
apt. Na ligação SSH à VM Web criada na secção 5.3.2, instale e configure o LAMP
Web stack predefinido.
2 Navegue para o site predefinido. Quando o LAMP Web stack estiver instalado, abra o
browser na etiqueta de nome DNS que introduziu quando criou um endereço IP
público na secção 5.1.3. No meu exemplo, foi azuremol.eastus.cloud-
app.azure.com. Também pode utilizar o endereço IP público que se obteve
quando criou a VM Web. Lembre-se: esse endereço IP público é dife-
rente da VM jumpbox em que utilizou SSH!
Parte 2
Elevada disponibilidade
e dimensionamento
O K, vamos começar a divertir-nos! Agora que compreende os recursos

core do Azure, pode mergulhar em áreas como redundância, balanceamento de
carga e distribuição geográfica de aplicações. É nesta parte que as coisas ficam
empolgantes, e esperamos que os tópicos que está a aprender comecem a mos-
trar soluções e as melhores práticas que podem ser utilizadas em implementa-
ções do mundo real. O Azure tem algumas funcionalidades incríveis para replicar
dados globalmente, distribuir o tráfego do cliente para a instância mais próxima
da sua aplicação e dimensionar automaticamente com base na procura. Estas
funcionalidades são o poder do cloud computing e agregam valor verdadeiro ao
seu trabalho.
Azure Resource Manager
6
Na maioria dos dias, pretende passar o menor tempo possível a pensar em como
implementar um ambiente de aplicação e continuar com a implementação real. Em
muitos ambientes de TI, há um movimento para equipas de desenvolvimento e ope-
rações que colaboram e trabalham em estreita colaboração, graças à popularidade
do DevOps, que é objeto de um grande número de conferências e blogues.
Não há nada inerentemente novo ou inovador sobre a cultura de DevOps, mas
muitas vezes as diferentes equipas não trabalham juntas como deveriam. Ferramen-
tas modernas têm estimulado o movimento de DevOps, com soluções de integração
contínua/entrega contínua (CI/CD) que podem automatizar toda a implementa-
ção de ambientes de aplicações com base num único registo de código por um pro-
gramador. Em geral, a equipa de operações é aquela que cria e mantém estes
pipelines de CI/CD, o que permite testes e implementações muito mais rápidos de
atualizações de aplicações para programadores.
O modelo de implementação do Azure Resource Manager é fundamental para
criar e executar recursos, mesmo que não tenha percebido ainda. O Resource Mana-
ger é uma abordagem à criação e implementação de recursos, assim como os proces-
sos de automatização e modelos que impulsionam essas implementações. Neste
capítulo, irá aprender a utilizar as funcionalidades do Resource Manager, como con-
trolos de acesso e bloqueios, implementações de modelos consistentes e implemen-
tações multicamada automatizadas.
6.1 A abordagem do Azure Resource Manager

Quando criou uma VM ou uma aplicação Web nos capítulos anteriores, primeiro criou
um grupo de recursos como a construção core para conter todos os seus recursos. Um
grupo de recursos é essencial para todos os recursos: uma VM, uma aplicação Web, uma
rede virtual ou uma tabela de armazenamento não pode existir fora de um grupo de
recursos. Mas o grupo de recursos é mais do que apenas um lugar para organizar os seus
recursos—muito mais. Esta secção examina o modelo subjacente do Azure Resource
Manager e mostra por que é importante ao criar e executar aplicações.
75
76 Capítulo 6 Azure Resource Manager
6.1.1 Conceber em torno do ciclo de vida da aplicação

Idealmente, não vai criar uma aplicação, nem nunca vai mantê-la. Geralmente, tem
atualizações para desenvolver e implementar, novos pacotes para instalar, novas VMs
para adicionar e blocos de implementação de aplicações Web adicionais para criar.
Talvez seja necessário fazer alterações nas definições da rede virtual e endereços IP.
Mencionei nos capítulos anteriores que as redes virtuais no Azure podem ser geridas
por uma equipa diferente. Precisa de começar a pensar sobre como executa a uma
escala grande e global, e em termos de ciclo de vida e gestão de aplicações.
Há algumas abordagens principais para agrupar recursos no Azure:
¡ Todos os recursos para uma determinada aplicação no mesmo grupo de recursos — Como
mostrado na figura 6.1, esta abordagem funciona bem para aplicações menores e
para ambientes de desenvolvimento e teste. Se não precisar de partilhar grandes
espaços de rede e puder gerir individualmente o armazenamento, poderá criar
todos os recursos num lugar e, em seguida, gerir as atualizações e as alterações de
configuração numa operação.
Rede virtual
Sub-rede de front-end Sub-rede de front-end
NIC 1 NIC 2 NIC 3 NIC 4
VM 1 VM 2 VM 3 VM 4
Disco do Disco de Disco do Disco de Disco do Disco de Disco do Disco de

sistema dados sistema dados sistema dados sistema dados
operavo operavo operavo operavo
Grupo de recursos únicos
Figura 6.1 Uma maneira de criar uma aplicação no Azure é criar todos os recursos relacionados
com essa implementação da aplicação no mesmo grupo de recursos e geri-los como uma entidade.
¡ Recursos semelhantes agrupados por função no mesmo grupo de recursos — Como mos-
trado na figura 6.2, esta abordagem é mais comum em aplicações e ambientes
maiores. A sua aplicação pode existir num grupo de recursos com apenas as VMs
e componentes de aplicações de suporte. Podem existir recursos de rede virtual e
endereços IP num grupo de recursos diferente, protegidos e geridos por um
grupo diferente de engenheiros.
A abordagem do Azure Resource Manager 77
Rede virtual
Sub-rede de front-end Sub-rede de back-end
NIC 1 NIC 2 NIC 3 NIC 4
Grupo de recursos de rede
VM 1 VM 2 VM 3 VM 4
Disco do Disco do Disco de Disco do Disco de Dados

sistema Disco de sistema SO
sistema dados
operavo dados dados operavo disco disco
operavo
Grupo de recursos de computação
Figura 6.2 Uma abordagem alternativa é criar e agrupar recursos com base na sua função. Um exemplo
comum é que todos os recursos de rede core estão num grupo de recursos separado dos recursos de
computação da aplicação core. As VMs no grupo de recursos de computação podem aceder aos recursos
de rede no grupo separado, mas os dois conjuntos de recursos podem ser geridos e protegidos de forma
independente.
Porquê as diferentes abordagens? A resposta não é simplesmente por segurança do

trabalho e pelos silos adoráveis em que algumas equipas gostam de trabalhar. É sobre
como precisa de gerir os recursos subjacentes. Em ambientes menores e aplicações
onde todos os recursos existem no mesmo grupo de recursos, é responsável por tudo
nesse ambiente. Esta abordagem também é adequada para ambientes de desenvolvi-
mento e teste onde tudo é empacotado junto. As alterações efetuadas na rede virtual
só afetam a sua aplicação e grupo de recursos.
A realidade é que as redes não mudam com frequência. Os intervalos de endereços
costumam ser bem definidos e planeados para que possam coexistir no Azure e em
filiais em todo o mundo. Logicamente, em geral, faz sentido colocar os componentes
de rede no seu próprio grupo de recursos. A rede e a aplicação são geridas em sepa-
rado. O armazenamento pode ser gerido e atualizado em separado da mesma forma.
Não há nada inerentemente errado com a divisão de recursos desta forma, contanto
que a equipa de TI não fique presa a uma mentalidade de compartimentação, resul-
tando numa falta de cooperação.
Para as aplicações, a divisão de recursos também pode ser uma vantagem porque fica
livre para fazer as alterações e atualizações que pretender. Precisamente, como não
tem os componentes de rede no seu grupo de recursos, não precisa de se preocupar
com os mesmos quando faz atualizações de aplicações.
6.1.2 Proteger e controlar recursos

Cada recurso pode ter diferentes permissões de segurança aplicadas. Estas políticas
definem quem pode fazer o quê. Pense nisso: quer que um estagiário reinicie a sua
aplicação Web ou elimine os discos de dados da VM? E acha que os seus bons amigos
na equipa de rede querem que crie uma nova sub-rede de rede virtual? Provavelmente
não. No Azure, há quatro funções core que pode atribuir aos recursos, que são seme-
lhantes às permissões de ficheiro:
¡ Proprietário — Controlo completo, basicamente um administrador
¡ Contribuinte — Gestão completa do recurso, exceto para fazer alterações nas atri-
buições de segurança e funções
¡ Leitor — Capacidade para ver todas as informações sobre o recurso, mas não pode
fazer alterações
¡ Administrador de acesso do utilizador — Capacidade para atribuir ou remover o
acesso aos recursos
O RBAC (controlo de acesso baseado em funções) é uma das funcionalidades core do
Azure que se integra automaticamente nas contas de utilizador nas suas subscrições.
Pense nas permissões de ficheiro no seu computador normal. As permissões de ficheiro
básicas são leitura, escrita e execução. Quando estas permissões são combinadas, pode
criar diferentes conjuntos de permissões para cada utilizador ou grupo no seu compu-
tador. À medida que trabalha com partilhas de ficheiros de rede, as permissões são
ferramentas comum para controlar o acesso. O RBAC no Azure funciona da mesma
maneira para controlar o acesso aos recursos, assim como as permissões de ficheiro no
seu computador local ou partilha de rede (figura 6.3).
Figura 6.3 O controlo de acesso para cada recurso do Azure lista as atribuições atuais.
Pode adicionar atribuições ou selecionar Funções para ver informações sobre quais conjuntos
de permissões estão disponíveis.
A abordagem do Azure Resource Manager 79
Experimente agora
Abra o portal Azure num browser e, em seguida, selecione qualquer recurso que tenha,
como cloud-shell-storage. Escolha o botão Controlo de Acesso (IAM), como mostrado na
figura 6.3. Analise as atribuições de funções atuais. Veja como adicionar uma atribuição
de funções e explore todas as atribuições de funções disponíveis. O ícone de informa-
ções para cada função mostra quais permissões são atribuídas.
Ao explorar as funções disponíveis, pode observar várias funções específicas dos

recursos, incluindo as seguintes:
¡ Contribuinte de Virtual Machines
¡ Contribuinte de site
¡ Contribuinte de rede
Consegue adivinhar o que essas funções significam? Elas assumem a função de Contri-
buinte da plataforma core e aplicam-na a um tipo de recurso específico. O caso prático
aqui remonta a esse conceito de como gere recursos semelhantes. Pode ser atribuído à
função de Contribuinte de Virtual Machines ou Contribuinte de Site. Então, as VMs ou
as aplicações Web criadas nesse grupo de recursos estariam disponíveis para que as
gerisse. Mas não pode gerir recursos de rede, que podem estar num grupo de recursos
totalmente diferente.
6.1.3 Proteger recursos com bloqueios

A abordagem baseada em permissões do RBAC é ótima para limitar quem pode aceder
ao quê. Mas ainda podem acontecer erros. Há uma razão pela qual normalmente não
inicia sessão num servidor como um utilizador com permissões administrativas ou de
raiz. Com um toque de tecla ou clique do rato errado, pode eliminar recursos por
engano. Mesmo se tiver cópias de segurança (tem cópias de segurança, certo? E testa-as
com regularidade?), é um processo demorado que pode significar perda de produtivi-
dade ou receitas para o negócio. No capítulo 13, irá aprender mais sobre as maneiras
como os serviços Azure Backup, Recovery e Replication protegem os seus dados.
Outra funcionalidade incorporada no modelo do Resource Manager são os blo-
queios de recursos. Cada recurso pode ter um bloqueio aplicado que limita o acesso só
de leitura ou evita operações de eliminação. O bloqueio de eliminação é particular-
mente útil, pois pode ser muito fácil eliminar o grupo de recursos errado. Depois de
iniciar uma operação de eliminação, não há como voltar atrás ou cancelar a operação
depois de a plataforma do Azure ter aceitado o seu pedido.
Para workloads de produção, sugiro que implemente bloqueios nos seus
recursos core para evitar eliminações. Estes bloqueios apenas servem para os níveis de
recursos e plataformas do Azure, não para os dados dentro dos seus recursos. Pode eli-
minar os ficheiros dentro de uma VM ou colocar uma tabela numa base de dados, por
exemplo. Os bloqueios de recursos do Azure seriam aplicados apenas se tentasse elimi-
nar toda a VM ou a base de dados SQL do Azure. A primeira vez que um bloqueio for
ativado e impedir que o grupo de recursos incorreto seja eliminado, irá agradecer-me!
Figura 6.4 Crie um bloqueio de recursos no portal Azure.
Experimente agora
Para ver os bloqueios de recursos do Azure em ação, como mostrado na figura 6.4,
1 Abra o portal Azure num browser e selecione qualquer grupo de recursos que
tenha, como cloud-shell-storage.
2 Escolha Bloqueios no lado esquerdo do portal.
3 Introduza um Nome de Bloqueio, como Proteger; escolha Eliminar no menu
pendente Tipo de Bloqueio; e escolha OK. O seu novo bloqueio aparece na lista.
4 Selecione Descrição Geral para o grupo de recursos e, em seguida, tente elimi-
nar o grupo de recursos. Precisa de introduzir o nome do grupo de recursos para
confirmar que pretende eliminá-lo (o que também é um bom aviso mental para
se certificar de que tem o recurso certo para eliminar!).
5 Ao escolher o botão Eliminar, analise a mensagem de erro apresentada para
ver como o bloqueio impediu o Azure de eliminar o recurso.
6.1.4 Gerir e agrupar recursos com etiquetas

Um recurso final no modelo do Azure Resource Manager que pretendo apresentar são
as etiquetas. Não há nada de novo ou especial sobre como marca recursos no Azure, mas
este conceito de gestão é muitas vezes negligenciado. Pode aplicar etiquetas a um
recurso no Azure que descreva as propriedades como a aplicação da qual faz parte, o
departamento responsável ou se é um recurso de desenvolvimento ou produção.
Modelos do Azure Resource Manager 81
Pode direcionar recursos com base em etiquetas para aplicar bloqueios ou funções
RBAC ou reportar os custos e o consumo dos recursos. As etiquetas não são exclusivas
de um grupo de recursos e podem ser reutilizadas na sua subscrição. Podem ser aplica-
das até 50 etiquetas a um único recurso ou grupo de recursos, portanto, tem muita fle-
xibilidade na forma como marca e filtra os recursos marcados.
Experimente agora
Para ver as etiquetas de recursos do Azure em ação, conclua os passos a seguir:
1 Abra o portal Azure num browser e, em seguida, selecione qualquer recurso,

como cloud-shell-storage. Embora possa etiquetar um grupo de recursos em si,
não escolha um grupo de recursos para este exercício.
2 Com o recurso selecionado, escolha o botão Etiquetas, como mostra a figura 6.5.
3 Introduza um nome, como workload, e um valor, como development.
4 Selecione Guardar.
5 Abra o Cloud Shell.
6 Para filtrar recursos com base em etiquetas, utilize az resource list com
o parâmetro --tag. Utilize o seu próprio nome e valor da seguinte maneira:
az resource list --tag workload=development
Figura 6.5 Pode criar até 50 etiquetas name:value para cada recurso do Azure ou grupo de recursos.
6.2 Modelos do Azure Resource Manager

Até agora, criou um pequeno número de recursos do Azure de cada vez. Para isso, uti-
lizou o portal Azure ou a CLI do Azure. Embora eu não lhe tenha mostrado o Azure
PowerShell, falei sobre o mesmo no capítulo 1, e está disponível no Cloud Shell. Talvez
tenha experimentado sem mim. Tudo bem, não há problema! Como mencionei no
capítulo 1, o Azure tem ferramentas que permitem escolher o que é mais adequado
para si e para o ambiente em que trabalha.
A desvantagem de utilizar o portal ou os comandos da CLI ou do PowerShell é que

deve clicar em vários botões no browser ou escrever linhas de comandos para criar o seu
ambiente de aplicação. Pode criar scripts para fazer todas estas coisas, mas
deve criar a lógica para controlar a criação de vários recursos ao mesmo tempo, ou a
ordem em que os recursos devem ser criados.
Um script que encurta os comandos da CLI do Azure ou do PowerShell começa a
mover-se na direção certa em termos de como deve criar e implementar ambientes de
aplicações — não apenas no Azure, mas em qualquer plataforma. Há um movimento em
direção à infraestrutura como código (IaC), que não é nenhuma novidade se já trabalha
com TI há algum tempo. Tudo isso significa que não confia num ser humano para intro-
duzir comandos e seguir um conjunto de passos; em vez disso, cria programaticamente a
sua infraestrutura a partir de um conjunto de instruções. As implementações manuais
introduzem um elemento humano que muitas vezes pode levar a pequenas configura-
ções incorretas e diferenças nas VMs finais, como mostrado na figura 6.6.
Scripts VM 1
Listas de Possíveis
Operador verificação diferenças
VM 2
humano nas VMs
implementadas
Vários passos Pacotes do
e scripts para VM 3
instalador
criar VM
Figura 6.6 Os seres humanos cometem erros, como o erro de introdução de um comando ou omitir
um passo numa implementação. Pode acabar com VMs ligeiramente diferentes no final da saída.
A automatização é frequentemente utilizada para remover o operador humano da equação e, em vez
disso, criar implementações consistentes e idênticas todas as vezes.
Mesmo quando tem scripts, ainda precisa de alguém para escrevê-los, efetuar a sua
manutenção e mantê-los atualizados à medida que forem lançadas novas versões dos
módulos da CLI do Azure ou do PowerShell. Sim, às vezes, são feitas alterações nas fer-
ramentas para acomodar novas funcionalidades, embora sejam raras.
6.2.1 Criar e utilizar modelos

Os modelos do Resource Manager podem ajudar a reduzir o erro humano e a depen-
dência de scripts escritos manualmente. Os modelos são escritos em JavaScript Object
Notation (JSON), uma abordagem padrão aberta multiplataforma que permite editá-
-los num editor de texto básico. Com os modelos, pode criar implementações consis-
tentes e reproduzíveis que minimizem erros. Outra funcionalidade incorporada dos
modelos permite que a plataforma compreenda as dependências e pode criar recursos
em paralelo, sempre que possível, para acelerar o tempo de implementação. Se criar
três VMs, por exemplo, não irá precisar de aguardar que a primeira VM conclua a
implementação antes de criar a segunda. O Resource Manager pode criar as três VMs
ao mesmo tempo.
Como um exemplo de dependências, se criar uma NIC virtual, irá precisar de a ligar
a uma sub-rede. Logicamente, a sub-rede deve existir antes que possa criar a NIC vir-
tual, e a sub-rede deve fazer parte de uma rede virtual, para que a rede deva ser criada
antes da sub-rede. A figura 6.7 mostra a cadeia de dependências em ação. Se tentar
escrever um script por conta própria, deverá planear cuidadosamente a ordem em que
os recursos são criados e, mesmo assim, deverá criar a lógica para saber quando os
recursos principais estão prontos e pode passar para os recursos dependentes.
Depende de Depende de
NIC virtual Sub-rede Rede virtual
Figura 6.7 O Azure Resource Manager manipula as dependências para si. A plataforma sabe a ordem
em que deve criar os recursos e tem consciência do estado de cada recurso sem a utilização de lógica
manuscrita e ciclos como aqueles que deve utilizar nos seus próprios scripts.
Quer saber algo fantástico? Já utilizou modelos do Resource Manager, no capítulo 2 e

na primeira VM que criou. À medida que cria uma VM no portal Azure ou na CLI, em
segundo plano, um modelo é criado e implementado programaticamente. Porquê?
Bem, porquê reinventar a roda e criar toda essa lógica para as implementações? Deixe
o Azure Resource Manager fazer isso por si.
Vejamos como é uma secção de um modelo do Resource Manager. A listagem a
seguir mostra a secção que cria um endereço IP público, exatamente como em exem-
plos anteriores quando criou uma VM.
Listagem 6.1 Criar um endereço IP público num modelo do Resource Manager
{
"apiVersion": "2019-04-01",
"type": "Microsoft.Network/publicIPAddresses",
"name": "publicip",
"location": "eastus",
"properties": {
"publicIPAllocationMethod": "dynamic",
"dnsSettings": {
"domainNameLabel": "azuremol"
}
}
},
Mesmo que JSON seja novo para si, é escrito num formato (relativamente) legível por
humanos. Define um tipo de recurso — neste exemplo, Microsoft.Network/publicI-
PAddresses. Em seguida, fornece um nome, como publicip, e uma localização, como
eastus. Finalmente, define o método de alocação — dynamic, neste exemplo — e uma
etiqueta de nome DNS, como azuremol. Estes parâmetros são os mesmos fornecidos
quando utilizou o portal Azure ou a CLI. Se utilizar o PowerShell, terá que? Deverá
utilizar os mesmos parâmetros.
A diferença com o modelo é que não precisa de introduzir nenhuma informação.

Toda a informação estava no código. “Ótimo”, pode pensar, “mas e se eu quiser
utilizar nomes diferentes de cada vez?” Assim como acontece com um script, pode atri-
buí-los dinamicamente utilizando parâmetros e variáveis:
¡ Parâmetros são valores que são pedidos. Muitas vezes são utilizados para as creden-
ciais de utilizador, o nome da VM e a etiqueta de nome DNS.
¡ Variáveis podem ser pré-atribuídas a valores, mas também são ajustadas sempre
que implementa o modelo, como o tamanho da VM ou o nome da rede virtual.
Experimente agora
Para ver um modelo completo do Resource Manager, abra um browser para
o repositório GitHub em http://mng.bz/QyWv.
6.2.2 Criar múltiplos de um tipo de recurso

À medida que cria modelos, tente pensar antes sobre como pode necessitar de expan-
dir as suas aplicações no futuro. Pode precisar apenas de uma única VM ao implemen-
tar a sua aplicação pela primeira vez, mas à medida que a necessidade de aplicações
aumenta, talvez seja necessário criar instâncias adicionais.
Numa implementação com script tradicional, cria um ciclo for ou while para criar
vários tipos de recurso. O Resource Manager tem esta funcionalidade incorporada! Há
mais de 50 tipos de funções no Resource Manager, assim como na maioria das linguagens
de programação e de script. Funções comuns do Resource Manager incluem length,
equals, or e trim. Controla o número de instâncias que serão criadas com a função copy.
Quando utiliza a função copy, o Resource Manager cria o número de recursos espe-
cificado. Sempre que o Resource Manager repete a operação de criação,
é disponibilizado um valor numérico para que nomeie os recursos de forma sequencial.
Acede a este valor com a função copyIndex(). O exemplo na listagem 6.1 criou um
único endereço IP público. O exemplo na listagem 6.2 utiliza o mesmo tipo de fornece-
dor de recursos Microsoft.Network/publicIPAddresses mas cria dois endereços IP
públicos. Pode utilizar copy para definir quantos endereços pretende criar e copyIn-
dex() para nomear os endereços sequencialmente.
Listagem 6.2 Criar vários endereços IP públicos com copy
{
"apiVersion": "2019-04-01",
"type": "Microsoft.Network/publicIPAddresses",
"name": "[concat(‘publicip’, copyIndex())]",
"copy": {
"count": 2
}
"location": "eastus",
"properties": {
"publicIPAllocationMethod": "dynamic",
}
},
Também utiliza a função concat para combinar o nome do endereço IP público e o

valor numérico de cada instância criada. Depois de este modelo ser implementado, os
seus dois endereços IP públicos são denominados publicip0 e publicip1. Estes nomes
não são superdescritivos, mas este exemplo básico mostra como pode utilizar uma con-
venção de numeração à medida que cria vários recursos com a função copy.
6.2.3 Ferramentas para criar os seus próprios modelos

Confesso: embora os modelos do Resource Manager sejam organizados e uma das
principais maneiras em que sugiro criar e implementar aplicações no Azure, ainda irá
precisar de escrever os modelos. Há algumas ferramentas que simplificam esta tarefa e
centenas de modelos de exemplo estão disponíveis na Microsoft e em terceiros. Na
verdade, uma das melhores maneiras de aprender a criar e utilizar os modelos é exami-
nar os modelos de início rápido que a Microsoft disponibiliza no seu repositório de
exemplos em https://github.com/Azure/azure-quickstart-templates.
Se quiser arregaçar as mangas e começar a escrever os seus próprios modelos, reco-
mendo duas ferramentas principais. A primeira é o Visual Studio Code, um editor de
open source gratuito multiplataforma (https://code.visualstudio.com). Juntamente
com algumas funcionalidades incorporadas, como o controlo de origem e a integração
do GitHub, encontram-se disponíveis extensões que podem criar automaticamente as
diferentes secções, ou fornecedores, para que os recursos criem um modelo, como
mostrado na figura 6.8. Se fizer o download e instalar o VS Code, escolha Ver > Exten-
sões e, em seguida, procure Azure.
Figura 6.8 Muitas extensões estão disponíveis no Visual Studio Code para melhorar e otimizar a forma como cria
e utiliza modelos do Azure Resource Manager.
Figura 6.9 Com o Visual Studio, pode criar graficamente modelos e explorar recursos JSON.
Uma maneira mais gráfica de criar modelos do Azure Resource Manager é utilizar o edi-
tor completo do Visual Studio, como mostrado na figura 6.9. Há versões para Windows e
macOS, mas precisa de uma licença separada para poder utilizar o editor. Está disponível
uma Community Edition, mas tenha cuidado se criar modelos dentro da sua empresa:
normalmente precisa de uma versão licenciada. Consulte os seus especialistas em licen-
ças, pois o Visual Studio é direcionado para os programadores de aplicações.
Pode, naturalmente, utilizar um editor de texto básico. Parte do motivo pelo qual os
modelos do Azure Resource Manager são escritos em JSON é que para isso não se
requer nenhuma ferramenta especial. Há uma curva de aprendizagem para trabalhar
com JSON, e é por isso que recomendo que explore os modelos de início rápido no
repositório de exemplos do Azure. Tenha cuidado com os avanços, as vírgulas finais e a
utilização de parênteses, parênteses retos e chavetas!
Vida em Marte
Existem ferramentas de terceiros e outras formas de utilizar modelos no Azure. A Hashi-
Corp fornece muitas ferramentas de open source e soluções de cloud computing; uma
delas é o Terraform. Com o Terraform, define todos os recursos que pretende criar da
mesma forma que faz num modelo nativo do Azure Resource Manager. Também pode
definir dependências e utilizar variáveis. A diferença é que o Terraform é tecnicamente
um fornecedor multiplataforma. As mesmas construções e abordagem de modelo
podem ser utilizadas no Azure, Google Cloud, AWS e vSphere, por exemplo. A diferença
são os aprovisionadores que utiliza para cada recurso.
É realmente uma abordagem de “um modelo para qualquer fornecedor”? Não, não é.
O Terraform também é uma aplicação que analisa o seu modelo e, em seguida, comu-
nica com o fornecedor de cloud relevante, como o Azure. Não tem funcionalidades de
edição, muito menos ferramentas gráficas, para criar o seu modelo. Escolhe um editor e
escreve o modelo manualmente. Novamente, a melhor maneira de aprender a utilizar
o Terraform é através da exploração da sua documentação e modelos de exemplo.
Laboratório: implementar recursos do Azure a partir de um modelo 87
A razão pela qual falo sobre este tópico está relacionada com o conceito de escolha no
Azure. Se achar que os modelos do Azure Resource Manager escritos em JSON são um
pouco complicados, explore um produto como o Terraform. Mas não desista de imple-
mentações do Resource Manager orientadas por modelos. Para alcançar estas imple-
mentações consistentes e reproduzíveis à escala, os modelos são a melhor abordagem,
por isso, encontre uma boa abordagem orientada por modelos que funcione para si.
6.2.4 Armazenar e utilizar modelos

Por isso, a melhor opção é utilizar os modelos do Azure Resource Manager e instalar
o Visual Studio ou o Código para escrever os seus próprios modelos. Como pode armaze-
ná-los e implementá-los? No laboratório de fim de capítulo, implementa um modelo do
repositório de exemplos do Azure no GitHub. Este repositório é público e é possível que
não queira que os seus modelos de aplicações estejam disponíveis para todo o mundo.
Há alguns métodos comuns para armazenar os modelos do Resource Manager
em particular:
¡ Utilize um repositório privado ou uma partilha de ficheiros de rede na
sua organização.
¡ Utilize o Azure Storage para armazenar e proteger centralmente modelos
para implementação.
Não há uma maneira certa ou errada de armazenar e implementar modelos. Tem flexi-
bilidade para utilizar quaisquer processos e ferramentas que já tenha instalados. A van-
tagem de utilizar um repositório é que normalmente tem alguma forma de controlo
de versões para poder garantir implementações consistentes e analisar o histórico dos
seus modelos, se necessário. A única limitação é que, quando implementa o modelo,
precisa de fornecer as credenciais apropriadas para aceder à localização partilhada.
Este processo de autenticação pode variar, como fornecer um nome de utilizador ou
token de acesso como parte do URL para um modelo num repositório, ou fornecer
um token de assinatura de acesso partilhado (SAS) se utilizar o Azure Storage.
Os repositórios públicos como o GitHub também podem ser ótimas maneiras de
aprender e partilhar. Sugiro que mantenha os seus modelos de produção armazenados
em particular, mas se criar um modelo organizado para um ambiente de laboratório ou
para experimentar algumas novas funcionalidades, partilhar no GitHub serve como
agradecimento à comunidade de TI e pode ajudar outras pessoas que queiram fazer as
mesmas implementações. E à medida que comece a criar os seus próprios modelos,
certifique-se de que verifica quais modelos já existem para que não comece do zero
e reinvente a roda a cada vez!
6.3 Laboratório: implementar recursos do Azure a partir de um modelo

Toda esta teoria sobre modelos de implementação e abordagens é excelente, mas começa
(idealmente) a ver as vantagens e a eficiência quando utiliza modelos para algo real:
1 Aceda aos exemplos de início rápido do Azure no GitHub (https://github.com/

Azure/azure-quickstart-templates), e encontre um que lhe interesse. Um bom
lugar para começar é uma simples VM Linux ou Windows.
2 Os exemplos do GitHub têm botões integrados para implementar diretamente

no Azure. Depois de encontrar um modelo que goste, selecione Implementar no
Azure, como mostrado na figura 6.10, e siga os passos no portal. O processo é
parecido com o de criação de uma VM, mas há apenas algumas indicações para
concluir os parâmetros necessários. Todos os outros recursos são criados para si e
abstraídos.
3 O passo final na implementação do seu modelo é aceitar o contrato de licença e,
em seguida, escolher Comprar. Cria recursos do Azure ao implementar
um modelo, portanto, escolher Comprar significa que concorda em pagar pelos
custos desses recursos do Azure.
Um dos modelos básicos, como uma simples VM Linux ou Windows,
custa o mesmo que qualquer outra VM criada até agora. Elimine o grupo de
recursos após a conclusão da implementação, assim como a limpeza
após qualquer outro exercício.
Figura 6.10 Para cada modelo do Resource Manager no repositório de exemplos do GitHub, há um botão
Implementar no Azure. Se selecionar este botão, o portal Azure será carregado, e o modelo também.
Ser-lhe-ão pedidos alguns parâmetros básicos e o restante da implementação é controlado pelo modelo.
Laboratório: implementar recursos do Azure a partir de um modelo 89
Parâmetros em modelos
Conforme discutido na secção 6.2.1, pode utilizar parâmetros e variáveis nos seus
modelos. Lembre-se de que os parâmetros são valores pedidos e as variáveis são
valores dinâmicos que podem ser aplicados através de um modelo. Os valores pedidos
(parâmetros) variam de modelo para modelo. Portanto, dependendo do modelo de início
rápido selecionado, ser-lhe-á pedido que introduza um ou dois valores, ou pode ter de
fornecer sete ou oito itens.
Ao conceber os seus modelos, tente antecipar como você e outros utilizadores podem
pretender reutilizar o modelo à medida que implementa as aplicações. Pode fornecer
um valor predefinido e limitar quais valores são permitidos. Tenha cuidado com estes
valores predefinidos e permitidos; caso contrário, pode restringir demasiado os utiliza-
dores e forçá-los a criar os seus próprios modelos. Sempre que possível, tente criar
modelos core reutilizáveis que tenham flexibilidade suficiente.
4 Depois de o modelo ter sido implementado, volte para o GitHub e examine o

ficheiro azure-deploy.json. Este ficheiro é o modelo do Azure Resource Manager
que utilizou para criar e implementar o exemplo. Veja se consegue entender os
diferentes tipos de recurso e as configurações que foram aplicadas. À medida
que trabalha com mais tipos de recurso e modelos do Azure, o formato JSON fica
mais fácil de entender. Palavra de honra!
Elevada disponibilidade
e redundância
7
Não posso contar o número de vezes em que algo relacionado com TI falhou
comigo. Tive um acidente com o disco rígido do portátil no dia anterior a uma con-
ferência, saía fumo de uma fonte de alimentação de um servidor de e-mail e, noutra
ocasião, as interfaces de rede de um router core deixaram de funcionar. Isso sem
falar do SO, dos controladores e das atualizações de firmware. Tenho a certeza de
que qualquer pessoa que trabalha em TI adoraria partilhar histórias sobre situações
horrorosas com as quais tiveram de lidar, geralmente os problemas aconteceram de
madrugada ou num momento crítico para o negócio. Existe algo comparável a um
erro flagrante no momento mais oportuno?
Se conseguir antecipar-se às falhas em TI, aprenderá a planear e conceber as suas
aplicações tendo em conta os problemas. Neste capítulo, irá aprender a utilizar as
funcionalidades de elevada disponibilidade e redundância do Azure para minimizar
as interrupções causadas por atualizações e interrupções de manutenção. Este capí-
tulo cria a base para os próximos dois ou três capítulos à medida que começa a passar
de uma aplicação que é executada numa única VM ou aplicação Web para uma que
pode ser dimensionada e distribuída globalmente.
7.1 A necessidade da redundância

Se pretender que os clientes confiem em si para que os ajude a realizar o seu impor-
tante negócio de pizzas, tem de fornecer aplicações que estão acessíveis sempre que
necessário. A maioria dos clientes não querem um site com "horário de funciona-
mento", especialmente se trabalham num ambiente global e os clientes podem pro-
vir de qualquer parte do mundo. Quando estão com fome, querem comer!
A figura 7.1 mostra um exemplo básico de uma aplicação que é executada numa
única VM. Infelizmente, esta aplicação cria um único ponto de falha. Se essa VM não
estiver disponível, a aplicação não estará disponível, o que leva à insatisfação e à fome
do cliente.
90
A necessidade da redundância 91
O cliente acede O cliente acede

à aplicação à aplicação
VM VM
única única
Figura 7.1 Se a sua aplicação for executada numa
única VM, qualquer interrupção nessa VM faz com que
a aplicação fique inacessível. Isto pode fazer com que os
Resposta da Aplicação não clientes levem os seus negócios para outro lugar ou, pelo
aplicação devolvida acessível menos, não fiquem satisfeitos com o serviço fornecido.
Se conduzir um automóvel, provavelmente tem um pneu sobresselente no automóvel,

caso o pneu fure. Se utilizar um portátil ou tablet, provavelmente ligará o dispositivo a
um carregador caso fique sem bateria durante o trabalho. Em casa ou no seu aparta-
mento, tem lâmpadas sobresselentes para quando as lâmpadas se fundem? Que tal
uma lanterna ou velas para quando houver uma falha de energia?
A maioria das pessoas gosta de ter alguma forma de redundância ou plano de reserva,
no dia a dia e, especialmente, em TI. Se estiver pronto para utilizar um pneu ou uma
lâmpada sobresselente, saberá lidar com interrupções e falhas com interrupção
mínima. Ao conceber e criar as suas aplicações tendo em conta a redundância, forne-
cerá um alto nível de disponibilidade aos seus clientes que minimizará ou até mesmo
fará desaparecer quaisquer interrupções das aplicações. Todos os datacenters do Azure
são criados para oferecer elevada disponibilidade. Fontes de alimentação de reserva,
várias ligações de rede e matrizes de armazenamento com discos sobressalentes são ape-
nas alguns dos conceitos core de redundância que o Azure fornece e gere. Toda a
redundância que o Azure fornece pode não ser útil se executar a sua aplicação numa
única VM. Para lhe dar flexibilidade e o controlo necessário sobre como tornar a sua
aplicação com elevada disponibilidade, existem duas funcionalidades principais que
faz com que os workloads de IaaS fiquem disponíveis:
¡ Zonas de Disponibilidade — Permitem-lhe distribuir VMs por segmentos fisica-
mente isolados de uma região do Azure para maximizar ainda mais a redundân-
cia de aplicações. As zonas também podem fornecer elevada disponibilidade aos
recursos de rede, como endereços IP públicos e balanceadores de carga.
¡ Conjuntos de Disponibilidade — Permitem-lhe agrupar logicamente as VMs para dis-
tribuí-las por um único datacenter do Azure e minimizar as interrupções causa-
das por falhas ou atualizações de manutenção.
Sugiro que planeie utilizar as Zonas de Disponibilidade na maioria das novas imple-
mentações de aplicações que faça no Azure. Esta abordagem oferece flexibilidade para
que distribua a aplicação como pretender e possa fornecer redundância aos recursos
de rede que são geralmente essenciais no modo como os clientes acedem às VMs subja-
centes. Para ver como cada uma destas abordagens funciona, vamos discuti-las mais
detalhadamente.
92 Capítulo 7 Elevada disponibilidade e redundância
7.2 Redundância de infraestrutura com Zonas de Disponibilidade

As Zonas de Disponibilidade são datacenters fisicamente separados que operam em servi-
ços core independentes, como a energia e a conectividade de rede. Cada região do
Azure que oferece suporte a Zonas de Disponibilidade fornece três zonas. Os recursos
são criados nestas zonas e distribuídos pelas mesmas. A figura 7.2 mostra como
os recursos do Azure podem ser distribuídos pelas Zonas de Disponibilidade.
Europa Ocidental
Endereço IP público
Balanceador de carga
Zona de Disponibilidade 1 Zona de Disponibilidade 2 Zona de Disponibilidade 3
VM 1 VM 2 VM 3
Figura 7.2 Uma região do Azure pode conter várias Zonas de Disponibilidade: datacenters fisicamente
isolados que utilizam energia, rede e arrefecimento independentes. Os recursos da rede virtual do Azure,
como os endereços IP públicos e os balanceadores de carga, podem abranger todas as zonas de uma
região para fornecer redundância para mais do que apenas as VMs.
Com as Zonas de Disponibilidade, as suas aplicações podem sobreviver à desconexão

de todo um datacenter do Azure. Não há dúvida de que algo muito sério teria de acon-
tecer para que essa situação acontecesse, mas ainda assim seria possível.
Em implementações de aplicações grandes, pode criar mais de uma VM em cada
Zona de Disponibilidade. Várias VMs numa Zona de Disponibilidade são automatica-
mente distribuídas pelo hardware disponível dentro da zona. Não há nada que precise
de configurar ou que possa controlar. Mesmo que uma atualização de manutenção ou
falha de equipamento dentro de uma zona afete todas as VMs executadas na zona, lem-
bre-se de que as zonas estão fisicamente isoladas umas das outras—as VMs noutra zona
continuariam a ser executadas.
Agora, se acha que é particularmente azarado, todas as suas VMs em diferentes zonas
poderiam passar por atualizações de manutenção ao mesmo tempo? Sim, mas isso é
improvável. As zonas dentro de uma região têm ciclos de atualização escalonados. As
atualizações são executadas numa zona. Quando estiverem concluídas, as atualizações
serão executadas na próxima zona. As zonas de disponibilidade fornecem um nível alto
de abstração e redundância, e deve examinar a sua aplicação em toda a implementa-
ção, não apenas onde residem as VMs numa zona.
Redundância de infraestrutura com Zonas de Disponibilidade 93
A inclusão dos recursos de rede virtual em Zonas de Disponibilidade é muito

mais importante do que pode parecer no princípio. A figura 7.3 mostra o que acontece-
ria se o data
Europa Ocidental
Zona de Disponibilidade 1 Zona de Disponibilidade 2 Zona de Disponibilidade 3
Balanceador de carga VM 2 VM 3
VM 1
Figura 7.3 Quando os recursos de rede são anexados a um único datacenter do

Azure, ou zona, uma interrupção nessa instalação faz com que toda a aplicação fique
inacessível para o cliente. Não importa que as outras VMs continuem a ser executadas
em outras zonas. Sem a conectividade de rede para distribuir o tráfego dos seus
clientes, toda a aplicação não está disponível.
center ficasse indisponível para recursos de rede, como um endereço IP público e um

balanceador de carga que são executados em Zonas de Disponibilidade.
Falo mais sobre balanceadores de carga no capítulo 8, mas por enquanto, tudo o que
precisa de entender é que o balanceador de carga distribui o tráfego por todas as VMs
disponíveis que estão anexadas. As VMs reportam o seu estado de funcionamento em
intervalos definidos, e o balanceador de carga não distribui mais o tráfego para uma
VM que reporta que não está disponível. Com um balanceador de carga que funciona
em Zonas de Disponibilidade, uma interrupção num datacenter do Azure faz com que
essas VMs fiquem indisponíveis e sejam retiradas da rotação do balanceador de carga.
Um endereço IP público que abrange Zonas de Disponibilidade fornece um único
ponto de entrada para os clientes atingirem o balanceador de carga e, em seguida,
serem distribuídos para uma VM disponível. Numa implementação de aplicações em
que esse endereço IP público reside num único datacenter do Azure, se esse datacenter
tiver um problema, nenhum cliente poderá aceder ao endereço IP público. O cliente
não pode utilizar a sua aplicação, mesmo se houver VMs disponíveis para satisfazer os
pedidos do cliente.
Os recursos que podem utilizar as Zonas de Disponibilidade incluem serviços zonais
e serviços com redundância entre zonas:
¡ Os serviços zonais destinam-se a coisas como VMs, um endereço IP público, ou um
balanceador de carga. Todo o recurso em si corre é executado numa determi-
nada zona e pode funcionar por si mesmo se outra zona não estiver disponível.
¡ Os serviços com redundância entre zonas são para recursos que podem replicar-se
automaticamente entre zonas, tais como armazenamento com redundância entre
zonas e bases de dados SQL. Todo o recurso não está a ser executado numa deter-
minada zona; em vez disso, os respetivos dados estão distribuídos por zonas, de
modo a que continue a estar disponível se uma zona tiver um problema.
O suporte da Zona de Disponibilidade está disponível para mais de 20 serviços do
Azure em mais de dez regiões. O número de serviços e regiões que têm integração com
as Zonas de Disponibilidade continua a crescer. Contudo, dadas as limitações de
região, pode haver alturas em que o suporte da Zona de Disponibilidade não esteja
disponível para recursos core como as VMs. Nesses casos, há outro tipo de redundân-
cia de VM que pode ser utilizado em qualquer região, que analisamos na secção 7.2.1:
Conjuntos de Disponibilidade.
7.2.1 Criar recursos de rede numa Zona de Disponibilidade

Para começar a ver alguma desta disponibilidade e redundância em ação, vamos criar
alguns recursos comuns, tais como um endereço IP público e um balanceador de carga
e, em seguida, as VMs. O objetivo aqui é ver que não é preciso muita configuração para
tirar partido das Zonas de Disponibilidade no Azure. Estes são exemplos simples, mas
formam o core da maior parte dos ambientes de aplicações que implementaria.
Os endereços IP públicos e os balanceadores de carga podem ser criados num dos
dois escalões disponíveis: básico e padrão. A principal diferença é que o escalão padrão
permite que o recurso de rede utilize Zonas de Disponibilidade. Por predefinição, um
endereço IP público padrão ou balanceador de carga é colocado automaticamente na
zona redundante. Não há nenhuma configuração adicional para concluir. A plataforma
do Azure armazena centralmente os metadados para o recurso dentro da região especi-
ficada e certifica-se de que o recurso continue a ser executado se uma zona ficar
indisponível.
Não se preocupe muito com o que acontece com o balanceador de carga e os recur-
sos de rede agora. Lembre-se do que disse no início: estes próximos dois ou três capí-
tulos estão relacionados. No capítulo 8, falaremos sobre os balanceadores de carga, e
tudo deve começar a fazer mais sentido.
Experimente agora
Para criar recursos de rede redundantes em Zonas de Disponibilidade, conclua
os passos a seguir:
1 Selecione o ícone do Cloud Shell na parte superior do dashboard do

portal Azure.
2 Crie um grupo de recursos, como azuremolchapter7az:
az group create --name azuremolchapter7az --location westeurope
3 Crie um endereço IP público padrão no seu grupo de recursos. Por predefini-

ção, um endereço IP público básico seria criado e atribuído a apenas uma única
zona. O parâmetro --sku standard instrui o Azure a criar um recurso com
redundância entre zonas:
az network public-ip create \
--resource-group azuremolchapter7az \
--name azpublicip \
--sku standard
Redundância de infraestrutura com Zonas de Disponibilidade 95
4 Crie um balanceador de carga que abranja as Zonas de Disponibilidade. Mais uma

vez, por predefinição, será criado um balanceador de carga básico e será atribuído
a uma única zona, embora esse não seja o design de elevada disponibilidade que
queria para as suas aplicações. Especifique um SKU de carga padrão para criar um
balanceador de carga com redundância entre zonas, da seguinte maneira:
az network lb create \
--name azloadbalancer \
--public-ip-address azpublicip \
--sku standard
7.2.2 Criar VMs numa Zona de Disponibilidade

Para criar uma VM numa Zona de Disponibilidade, especifique qual zona deve execu-
tar a VM. Para implementar muitas VMs, idealmente cria e utiliza um modelo. O
modelo define e distribui as zonas para cada uma das VMs. À medida que a exigência
do cliente para a sua pizzaria online aumenta, também pode atualizar o modelo com o
número de VMs que pretende agora e, em seguida, voltar a implementar o modelo. As
novas VMs são distribuídas automaticamente pelas zonas, e não há necessidade de con-
trolar manualmente em quais zonas as VMs são executadas. No laboratório de fim de
capítulo, utiliza um modelo para criar e distribuir várias VMs automaticamente. Para
ver o processo lógico para especificar uma zona para uma VM, vamos criar uma VM e
especificar manualmente a zona.
Experimente agora
Para criar uma VM numa Zona de Disponibilidade, conclua os passos a seguir:
1 No portal Azure, selecione o ícone do Cloud Shell na parte superior do

dashboard.
2 Crie uma VM com o comando az vm create que utilizou nos capítulos anterio-
res. Utilize o parâmetro --zone para especificar a zona 1, 2 ou 3 para que a VM
seja executada. O exemplo a seguir cria uma VM chamada zonedvm na zona 3:
az vm create \
--name zonedvm \
--image ubuntults \
--zone 3
A criação da VM irá demorar alguns minutos. Quando o processo terminar, a saída do

comando indica a zona em que a VM é executada. Também pode ver estas informações
com o comando az vm show:
az vm show \
--name zonedvm \
--query zones
NOTA Os exemplos nestes exercícios "Experimente agora" são simples, mas foram con-
cebidos para mostrar que as zonas requerem pouca configuração para serem utilizadas.
Não integrou o balanceador de carga com redundância entre zonas e a VM, mas no
capítulo 8, criará um ambiente de aplicação mais utilizável que é distribuído pelas
Zonas de Disponibilidade. O objetivo aqui é mostrar que a plataforma do Azure pro-
cessa a redundância e a distribuição dos seus recursos, para que possa concentrar-se
na aplicação em si.
7.3 Redundância de VMs com Conjuntos de Disponibilidade

As zonas de disponibilidade são ótimas ao conceber para redundância num conjunto
mais vasto de recursos que compõem as suas aplicações e workloads. Recomendo que,
sempre que possível, as utilize para novas workloads. No entanto, há alturas em que
não é necessariamente preciso tornar todos os recursos com redundância entre zonas.
Ou pode querer criar VMs numa região do Azure que não tem atualmente suporte de
Zona de Disponibilidade.
Se apenas pretender fornecer redundância nas VMs, os Conjuntos de Disponibilidade
cumprem este propósito. São comprovados, fiáveis e estão disponíveis em todas as
regiões. Os Conjuntos de Disponibilidade contêm um grupo lógico de VMs que indicam
à plataforma do Azure que o hardware subjacente em que as VMs são executadas precisa
de ser escolhido com cuidado. Se criar duas VMs executadas no mesmo servidor físico e
um servidor falhar, as duas VMs terão problemas. Com potencialmente dezenas de milha-
res ou mais servidores físicos num datacenter do Azure, é altamente improvável ter essas
duas VMs no mesmo servidor, mas é possível! Pode não ser uma falha, mas uma atualiza-
ção de manutenção que faz com que o servidor físico fique rapidamente indisponível.
E se as suas VMs forem executadas no mesmo bastidor, anexadas ao mesmo equipa-
mento de armazenamento ou de rede? Voltemos ao único ponto de falha discutido no
início do capítulo.
Os conjuntos de disponibilidade permitem que a plataforma do Azure crie as suas
VMs entre grupos lógicos denominados domínios de falha e domínios de atualização. Estes
domínios lógicos permitem que a plataforma do Azure compreenda os limites físicos
dos grupos de hardware para garantir que as suas VMs são distribuídas uniformemente
pelos mesmos. Se uma parte do hardware tiver um problema, apenas algumas
VMs no seu Conjunto de Disponibilidade serão afetadas. Ou se houver atualizações de
manutenção a serem aplicadas ao hardware físico, a manutenção afetará apenas algu-
mas das suas VMs. Na figura 7.4. podemos ver a relação que há entre o hardware físico e
os domínios de falha e de atualização lógicos dentro de um Conjunto de
Disponibilidade.
As Zonas de Disponibilidade fazem o mesmo tipo de distribuição em segundo plano,
mas é abstraída e não é exposta. Mesmo com os Conjuntos de Disponibilidade, não há
muito que se possa configurar. Mas é útil saber o que está a acontecer em segundo plano.
7.3.1 Domínios de falha

Um domínio de falha é um grupo lógico de hardware num datacenter do Azure. Contém
hardware que partilha um equipamento de energia ou rede. Não controla o que estes
domínios de falha são, e não há nada para configurar no nível da VM. A plataforma do
Azure controla em quais domínios de falha as suas VMs são colocadas e distribui novas
VMs por estes domínios de falha para que tenha sempre VMs disponíveis se a energia ou um
comutador de rede falhar.
Redundância de VMs com Conjuntos de Disponibilidade 97
Conjunto de Disponibilidade
Basdor de servidores Basdor de servidores Domínio de falha Domínio de falha
Servidor sico Servidor sico Domínio de atualização Domínio de atualização
VM VM VM VM
Servidor sico Servidor sico Domínio de atualização Domínio de atualização
VM VM VM VM
Figura 7.4 O hardware num datacenter do Azure é dividido logicamente em domínios de atualização e domínios de falha. Estes
domínios lógicos permitem que a plataforma do Azure entenda como distribuir as suas VMs pelo hardware subjacente para cumprir os
seus requisitos de redundância. Este exemplo é básico: um domínio de atualização provavelmente contém mais de um servidor físico.
As VMs que utilizam discos geridos (lembre-se de que todas as VMs devem utilizar discos geri-
dos!) também respeitam a distribuição e os limites lógicos dos domínios de falha. A plataforma
do Azure atribui logicamente clusters de armazenamento a domínios de falha para garantir que,
à medida que as VMs são distribuídas por grupos de hardware, os discos geridos também são dis-
tribuídos pelo hardware de armazenamento. Se todos os discos geridos acabassem num cluster
de armazenamento, não haveria redundância de VMs no hardware de servidor! E sim, os discos
geridos também podem ser utilizados com Zonas de Disponibilidade.
7.3.2 Domínios de atualização

Ao passo que os domínios de falha criam um grupo lógico de hardware como medida de prote-
ção contra falhas de hardware, os domínios de atualização servem de proteção contra a manu-
tenção de rotina. Para fornecer esta proteção, um domínio de falha é dividido logicamente em
domínios de atualização. Mais uma vez, não há nada para configurar aqui. Os domínios de atua-
lização são uma forma de a plataforma do Azure entender como deve distribuir VMs pelo seu
conjunto de disponibilidade.
Os engenheiros do Azure executam a manutenção (principalmente automatizada) e aplicam
atualizações em todo o hardware físico num domínio de atualização e, em seguida, executam a
mesma manutenção em todo o hardware no próximo domínio de atualização. Este trabalho de
manutenção é escalonado em domínios de atualização para garantir que as VMs num Conjunto
de Disponibilidade não estão em execução no hardware que passa pela manutenção ao mesmo
tempo. É o mesmo tipo de processo que analisámos com as Zonas de Disponibilidade; a distribui-
ção dos seus recursos significa que não pode ter um cenário em que todo o hardware subjacente
aos seus recursos esteja a ser atualizado ao mesmo tempo.
Não há nenhuma relação entre domínios em vários Conjuntos de Disponibilidade. Os recur-
sos físicos que compõem os domínios de falha e atualização num Conjunto de Disponibilidade
podem não ser os mesmos para um segundo Conjunto de Disponibilidade. Esta conscientização
significa que, se criar vários Conjuntos de Disponibilidade e distribuir as suas VMs pelos mesmos,
o domínio de falha 1, por exemplo, nem sempre conterá o mesmo hardware físico.
7.3.3 Distribuir VMs por um Conjunto de Disponibilidade

Vamos percorrer passo a passo e ver como as VMs são distribuídas pelos domínios lógicos
de falha e atualização que compõem um Conjunto de Disponibilidade. Desta forma, tem
várias VMs que podem administrar a sua pizzaria, e os clientes não vão ficar com fome!
Experimente agora
Para ver os Conjuntos de Disponibilidade em ação, conclua os passos a seguir para
implementar um modelo do Resource Manager:
1 Abra um browser para um modelo do Resource Manager no repositório de exemplos do
GitHub em https://github.com/fouldsy/azure-mol-samples-2nd-ed/tree/master/ 07/
availability-set, e selecione o botão Implementar no Azure. Utiliza um modelo neste exer-
cício para que possa implementar rapidamente VMs e explorar como essas VMs são distri-
buídas pelo Conjunto de Disponibilidade.
O portal Azure é aberto e pede alguns parâmetros.
2 Escolha criar um novo grupo de recursos e forneça um nome como azuremolchapter7.
Selecione uma região e forneça os dados da chave SSH (pode obtê-los no Cloud Shell
com cat ~/.ssh/id_rsa.pub).
O modelo cria um Conjunto de Disponibilidade que contém três VMs. Estas VMs são
distribuídas pelos domínios lógicos de falha e atualização. Para complementar o que apren-
deu sobre o Resource Manager no capítulo 6, este modelo utiliza a função copyIndex()
para criar várias VMs e NICs.
3 Para confirmar que pretende criar os recursos detalhados no modelo, marque a caixa
“Aceito os termos e condições acima” e selecione Comprar.
A criação das três VMs no Conjunto de Disponibilidade irá demorar alguns minutos. Deixe a
implementação continuar no portal enquanto lê o restante desta secção.
Quando o modelo começa a ser implementado, é criado um Conjunto de Disponibilidade e o
número pedido de domínios de atualização e de falha é atribuído. As seguintes propriedades
foram definidas no modelo de exemplo:
“properties”: {
“platformFaultDomainCount”: “2”,
“platformUpdateDomainCount”: “5”,
“managed”: “true”
}
Estas propriedades criam um Conjunto de Disponibilidade com dois domínios de falha e cinco
domínios de atualização, como mostrado na figura 7.5, e indicam que as VMs devem utilizar dis-
cos geridos; portanto, faça a distribuição de discos conforme necessário. A região selecionada
para o Conjunto de Disponibilidade determina o número máximo de domínios de falha e atua-
lização. As regiões suportam 2 ou 3 domínios de falha e até 20 domínios de atualização.
Domínio de falha 0 Domínio de falha 1

Domínio de Domínio de
atualização 0 atualização 1
Domínio de
atualização 4
Figura 7.5 O Conjunto de Disponibilidade que o modelo de exemplo

implementa contém dois domínios de falha e cinco domínios de atualização.
O sistema de numeração é baseado em zero. Os domínios de atualização
são criados sequencialmente entre os domínios de falha.
À medida que cria mais VMs num Conjunto de Disponibilidade, precisa de considerar quantos
domínios de atualização irão ser utilizados. Cinco domínios de atualização, por exemplo, signifi-
cam que até 20% das VMs podem não estar disponíveis devido à manutenção:
¡ Digamos que tem 10 VMs no seu Conjunto de Disponibilidade. Duas dessas VMs podem
ser submetidas a manutenção ao mesmo tempo. Se pretendesse permitir que apenas uma
VM de cada vez fosse submetida a manutenção, precisaria de criar 10 domínios de atualiza-
ção. Quanto mais domínios de atualização criar, mais tempo a sua aplicação poderá ficar
num estado de manutenção.
¡ Continuemos com o exemplo anterior de 10 VMs em 10 domínios de atualização. Agora há
potencial para perturbações nas suas aplicações até que todos os 10 domínios de atualização
tenham completado o respetivo ciclo de manutenção. Se tiver apenas 5 domínios de atualiza-
ção, esse prazo de manutenção é reduzido. Não é necessariamente mau ter um período de manu-
tenção mais longo; interessa qual é a sua tolerância é para um funcionamento potencial a uma
capacidade inferior à total.
É importante lembrar que estes domínios de atualização e ciclos de manutenção são o que a
plataforma do Azure realiza por si própria. Também precisa de ter em conta as suas próprias
necessidades de atualização e períodos de manutenção.
Quando a primeira VM é criada, a plataforma do Azure procura a primeira posição de imple-
mentação disponível. Este é o domínio de falha 0 e o domínio de atualização 0, como mostrado
na figura 7.6.
Quando a segunda VM é criada, a plataforma do Azure procura a próxima posição de imple-
mentação disponível. Agora, este é o domínio de falha 1 e o domínio de atualização 1, como
mostrado na figura 7.7.
Conjunto de Disponibilidade Conjunto de Disponibilidade
Domínio de falha 0 Domínio de falha 0 Domínio de falha 1

Domínio de Domínio de Domínio de
atualização 0 atualização 0 atualização 1
VM 0 VM 0 VM 1
Figura 7.6 A primeira VM é criada Figura 7.7 Com uma segunda VM criada, as VMs são distribuídas
no domínio de falha 0 e no domínio uniformemente pelos domínios de falha e atualização. Isto é o que
de atualização 0. normalmente se considera o nível mínimo de redundância
necessário para proteger as suas aplicações.
O seu modelo cria três VMs. O que acha que acontece a seguir? A plataforma do Azure procura
novamente a próxima posição de implementação disponível. Criou apenas dois domínios de
falha, portanto, a VM é criada novamente no domínio de falha 0. Mas a VM é criada num domí-
nio de atualização diferente do da primeira VM. A terceira VM é criada no domínio de atualiza-
ção 2, como mostrado na figura 7.8.
Domínio de atualização 0 Domínio de falha 1

VM 0 VM 1
Figura 7.8 A terceira VM é

Domínio criada novamente no domínio
de atualização 2 de falha 0, mas no domínio de
atualização 2. Embora as VMs
VM 2 0 e 2 possam partilhar o risco
de falha de hardware, estão
em domínios de atualização
diferentes e, por isso, não serão
submetidas a manutenção
regular ao mesmo tempo.
As VMs 0 e 2 estão no mesmo domínio de falha e, portanto, uma falha de hardware

pode afetar ambas as VMs. Mas a manutenção de rotina afeta apenas uma dessas VMs
de cada vez, pois são distribuídas pelos domínios de atualização. Se continuar e criar
mais VMs, a plataforma do Azure irá continuar a distribuí-las por domínios de falha e
atualização diferentes. Quando os cinco domínios de atualização são utilizados, a sexta
VM é criada novamente no domínio de atualização 0 e o ciclo continua.
7.3.4 Ver a distribuição de VMs por um Conjunto de Disponibilidade

Agora que compreende a teoria de como as VMs são distribuídas pelos
domínios de falha e atualização num Conjunto de Disponibilidade, vamos verificar
o que aconteceu com a sua implementação do modelo do Resource Manager.
Experimente agora
Para ver como as suas VMs são distribuídas num Conjunto de Disponibilidade, conclua
os passos a seguir:
1 Navegue para o Grupo de Recursos e selecione-o na barra de navegação

à esquerda no portal Azure.
2 Escolha o grupo de recursos que criou para a implementação do modelo,
tal como azuremolchapter7.
3 Selecione o Conjunto de Disponibilidade na lista de recursos, como azuremolavail-
abilityset.
A janela Descrição Geral apresenta uma lista de VMs e dos domínios associados
de falha e atualização, como mostrado na figura 7.9.
Figura 7.9 O Conjunto de Disponibilidade lista as VMs que contém e mostra o domínio de falha e
o domínio de atualização para cada VM. Esta tabela permite-lhe ver como as VMs são distribuídas
pelos domínios lógicos.
Se estiver particularmente atento, poderá perceber que as VMs não estão perfeitamente alinha-
das com a ordem esperada dos domínios de falha e atualização. Trata-se de um erro? Provavel-
mente não. Se examinarmos o exemplo na figura 7.9 e o compararmos com os conceitos que vimos
anteriormente, esperaríamos que as VMs fossem distribuídas como mostrado na tabela 7.1.
Tabela 7.1 Conjunto de Disponibilidade de VMs criadas sequencialmente e distribuídas por domínios
Nome Domínio de falha Domínio de atualização
vm0 0 0
vm1 1 1
vm2 0 2
Então, o que correu mal? Nada. Pense novamente como o Resource Manager cria recur-
sos a partir de um modelo. A plataforma do Azure não espera que a primeira VM seja criada
antes que a segunda possa ser criada. As três VMs são criadas ao mesmo tempo. Assim, pode
haver uma diferença de uma fração de um segundo em que a VM é associada a um Conjunto de
Disponibilidade primeiro. Não importa qual é esta ordem, pois não consegue controlar o
que representam os domínios de falha e atualização subjacentes. Isso fica a cargo da plataforma
do Azure. Só precisa de garantir que as suas VMs são distribuídas, não onde são distribuídas.
Não, preciso de dados mais precisos

Se a forma como as VMs estão a ser criadas em série não o convencer e precisar de distribuir
as VMs de maneira organizada, poderá informar o Resource Manager para criar VMs em
série, não em paralelo. Neste modo, as VMs são criadas uma após a outra e, portanto, o
tempo de implementação é maior. Para ativar este comportamento em série, utilize “mode”:
“serial” nos seus modelos como parte da função copyIndex(). Isso deveria distribuir as
VMs de uma forma sequencial e ordenada!
7.4 Laboratório: implementar VMs altamente disponíveis a partir

de um modelo
Este laboratório combina e reforça o que aprendeu no capítulo 6 sobre o Azure Resource Manager
e os modelos, juntamente com as Zonas de Disponibilidade. Tire algum tempo para examinar o
modelo de início rápido de exemplo neste exercício e ver como pode utilizar a lógica e as fun-
ções para distribuir várias VMs pelas zonas. Não basta implementar o modelo e seguir adiante.
Veja como o modelo se baseia nas funcionalidades introduzidas no capítulo 6!
O que é uma quota?

No Azure, as quotas predefinidas na sua subscrição impedem-no de implementar vários
recursos acidentalmente e esquecer-se dos mesmos, o que lhe irá custar muito dinheiro.
Geralmente, estas quotas variam por tipo de recurso e tipo de subscrição e são impos-
tas no nível da região. Pode ver a lista completa de quotas em http://mng.bz/ddcx.
Quando começar a criar várias VMs nos próximos capítulos, poderá vir a ter problemas
relacionados com as quotas. Também pode vir a ter problemas se não tiver eliminado os
recursos dos capítulos e exercícios anteriores. As quotas são um bom sistema para estar
ciente da utilização de recursos. As mensagens de erro podem não ser claras, mas se
encontrar uma mensagem de erro do tipo:
Os resultados da operação excedem os limites da quota Core.
Máximo permitido: 4, Atualmente em utilização: 4, Pedido adicional: 2.
é um bom indicador de que precisa de pedir um aumento de quotas. Nada é complicado

ou exclusivo do Azure. Pode ver a sua quota atual para uma determinada região
da seguinte maneira:
az vm list-usage --location eastus
Se tiver problemas com este laboratório, elimine os dois primeiros grupos de recursos
criados neste capítulo, como azuremolchapter7 e azuremolchapter7az. Se a quota
predefinida for baixa, as quatro VMs distribuídas por esses grupos de recursos poderão
impedi-lo de executar o exercício corretamente.
Para pedir um aumento das suas quotas de uma região, siga os passos descritos em
http://mng.bz/Xq2f.
Vamos analisar e implementar um modelo de exemplo que contém várias VMs

distribuídas pelas Zonas de Disponibilidade.
1 Num browser, abra o ficheiro JSON https://github.com/Azure/azure-quick‑s-
tart-templates/blob/master/201-multi-vm-lb-zones/azuredeploy.json, e procure
o seguinte texto:
Microsoft.Compute/virtualMachines
A secção de VMs é semelhante à que utilizou no capítulo 6, mas observe o valor da

propriedade de zones. Esta secção combina algumas funções disponíveis em
modelos para escolher uma das zonas 1, 2 ou 3 à medida que a VM é criada. Desta
forma, não precisa de controlar manualmente qual VM é executada em qual zona
e como implementar VMs adicionais.
2 No browser, procure cada um dos seguintes itens para ver as secções do endereço
IP público e do balanceador de carga:
Laboratório: implementar VMs altamente disponíveis a partir de um modelo 103
Microsoft.Network/publicIPAddresses
Microsoft.Network/loadBalancers
Os dois recursos utilizam um SKU padrão, que fornece redundância entre zonas
por predefinição. Não há nenhuma configuração adicional para que isto fun-
cione! Vamos ver tudo isto em ação.
3 No browser, abra o modelo de início rápido em http://mng.bz/O69a, e selecione
o botão Implementar no Azure.
4 Crie ou selecione um grupo de recursos e, em seguida, forneça um nome de uti-
lizador e palavra-passe para as VMs.
5 Introduza um nome DNS exclusivo, como azuremol.
6 Decida se pretende criar VMs Linux ou Windows. As VMs Windows levam um
pouco mais de tempo a criar.
7 Especifique quantas VMs pretende criar, como 3.
8 Marque a caixa para concordar com os termos e condições da implementação do
modelo e selecione Comprar, como mostrado na figura 7.10.
Figura 7.10 Para implementar o modelo de Zona de Disponibilidade no portal Azure, especifique
um grupo de recursos, um nome de utilizador e uma palavra-passe e, em seguida, o tipo de SO e o
número de VMs que pretende criar. O modelo utiliza ciclos, copyIndex(), dependsOn, variáveis
e parâmetros, conforme abordado no capítulo 6.
Depois de as VMs terem sido criadas, utilize o portal Azure ou o comando az vm show
para ver como as VMs foram distribuídas pelas zonas. Se estiver curioso sobre o que o
resto do modelo faz com os recursos de rede, o capítulo 8 fala detalhadamente sobre
os balanceadores de carga!
Laboratório: implementar VMs altamente disponíveis a partir de um modelo 105
Limpeza no corredor 3
Lembra-se que, no início do livro, disse que não deveria esquecer-se de
limpar para gastar o menor número de créditos do Azure possível? Recomendo que eli-
mine os grupos de recursos que criou neste capítulo. Os próximos dois capítulos conti-
nuam a criar várias VMs e instâncias de aplicações Web, por isso, certifique-se de que
mantém os custos e as quotas sob controlo.
Sempre que iniciar sessão no portal Azure, deve receber uma notificação pop-up
com o estado dos seus créditos do Azure. Se reparar que o seu crédito disponível
diminuiu muito de um dia para o outro, examine quais grupos de recursos pode ter-se
esquecido de eliminar!
Aplicações de balanceamento
de carga
8
Um componente importante das aplicações de elevada disponibilidade é como dis-
tribuir o tráfego por todas as VMs. No capítulo 7, aprendeu a diferença entre os
Conjuntos de Disponibilidade e as Zonas de Disponibilidade, bem como a criar
várias VMs em datacenters ou regiões do Azure para fornecer redundância de apli-
cações. Mesmo se tiver todas estas VMs distribuídas e com elevada disponibilidade,
isso não servirá de nada se apenas uma VM receber todo o tráfego dos clientes.
Balanceadores de carga são recursos de rede que recebem o trá-
fego da aplicação de entrada proveniente dos seus clientes, examinam o tráfego para
aplicar filtros e regras de balanceamento de carga e, em seguida, distribuem os pedi-
dos por um conjunto de VMs que executam a sua aplicação. No Azure, há algumas
maneiras diferentes de fazer o balanceamento de carga de tráfego, tais como quando
precisar de executar um descarregamento SSL em aplicações de grande dimensão
que utilizam o tráfego de rede encriptado. Neste capítulo, irá conhecer os vários
componentes do balanceador de carga e irá aprender a configurar regras e filtros de
tráfego e a distribuir o tráfego para as VMs. Irá basear-se nos componentes de ele-
vada disponibilidade do capítulo 8 e irá preparar-se para o capítulo 9 sobre como
dimensionar recursos.
8.1 Componentes do balanceador de carga do Azure

Os balanceadores de carga do Azure podem funcionar em dois níveis: na camada 4,
onde apenas o tráfego de rede é examinado e distribuído (a camada de transporte,
na verdade), e a camada 7, onde se diferenciam os dados da aplicação no tráfego de
rede para ajudar a determinar a distribuição dos dados. Ambos os níveis do balan-
ceador de carga funcionam da mesma forma, como mostrado na figura 8.1.
106
Componentes do balanceador de carga do Azure 107
Internet
Balanceador
de carga
Conjunto IP de front-end
Sondagem do estado de funcionamento

Sondagem do caminho para verificar
health.html em VM de back-end
Regras do balanceador de carga
Permir porta TCP 80 de entrada-> Porta
TCP 80 no conjunto de back-end
Conjunto IP de back-end
NIC NIC NIC
virtual virtual virtual
VM VM VM
Figura 8.1 O tráfego proveniente da Internet entra no balanceador de carga por meio de um endereço IP
público anexado a um conjunto IP de front-end. O tráfego é processado pelas regras do balanceador de
carga que determinam como e onde o tráfego deve ser encaminhado. As sondagens do estado de
funcionamento anexadas às regras garantem que o tráfego é distribuído apenas para os nós em bom
estado de funcionamento. Então, um conjunto de back-end de NICs virtuais ligadas às VMs recebe o
tráfego distribuído pelas regras do balanceador de carga.
Alguns dos principais componentes de um balanceador de carga são os seguintes:

¡ Conjunto IP de front-end: ponto de entrada para o balanceador de carga. Para per-
mitir o acesso a partir da Internet, um endereço IP público pode ser anexado ao
conjunto IP de front-end. Podem ser anexados endereços IP privados para balan-
ceadores de carga internos.
¡ Sondagens do estado de funcionamento: monitorizam o estado das VMs anexadas.
Para garantir que o tráfego é distribuído apenas para as VMs em bom estado de
funcionamento e com capacidade de resposta, as verificações são executadas
regularmente para confirmar que uma VM responde corretamente ao tráfego.
¡ Regras do balanceador de carga: distribuem o tráfego para as VMs. Cada pacote de
entrada é comparado com as regras, que definem os protocolos e as portas de
entrada e, em seguida, são distribuídas por um conjunto de VMs associadas. Se
nenhuma regra coincidir com o tráfego de entrada, o tráfego será descartado.
¡ Regras de Tradução de Endereços de Rede (NAT): podem encaminhar o tráfego direta-
mente para VMs específicas. Se pretender fornecer acesso remoto via SSH ou
RDP, poderá definir regras NAT para encaminhar o tráfego de uma porta externa
para uma única VM.
¡ Conjunto IP de back-end: ao qual estão anexadas as VMs que executam a sua aplicação.
As regras do balanceador de carga estão associadas aos conjuntos de back-end. Pode
criar conjuntos de back-end diferentes para diferentes partes das suas aplicações.
108 Capítulo 8 Aplicações de balanceamento de carga
Azure Application Gateway: balanceamento de carga avançado

Os balanceadores de carga do Azure podem funcionar na camada de rede ou na camada
da aplicação. Este capítulo concentra-se no balanceador de carga normal do Azure, que
funciona na camada de rede (camada 4 ou protocolo de Transporte). Nesta camada,
o tráfego é examinado e distribuído, mas o balanceador de carga não tem nenhum con-
texto do que significa o tráfego ou das aplicações que pretende executar.
O Azure Application Gateway é um balanceador de carga que funciona na camada da aplica-
ção (camada 7). O Application Gateway obtém insights sobre a aplicação que é executada na
VM e pode gerir os fluxos de tráfego de maneiras mais avançadas. Uma grande vantagem do
Application Gateway é a capacidade de lidar com o tráfego Web HTTPS encriptado.
Quando efetua o balanceamento de carga em sites com certificados SSL, pode descar-
regar o processo que verifica e desencripta o tráfego proveniente dos servidores Web.
Em sites com muito tráfego SSL, o processo para verificar e desencriptar o tráfego pode
consumir uma grande parte do tempo de computação nas VMs ou aplicações Web.
O Application Gateway pode verificar e desencriptar o tráfego, passar o pedido pura-
mente Web para os servidores Web e, em seguida, voltar a encriptar o tráfego prove-
niente dos servidores Web e devolvê-lo ao cliente.
O Application Gateway oferece algumas outras funcionalidades do balanceador de carga
mais avançadas, como a capacidade de distribuir o tráfego por qualquer endpoint IP, em
vez de apenas uma VM do Azure. Estas regras de distribuição avançadas podem ser
úteis se estiver a criar aplicações que utilizam mais do que VMs. São aplicados os mes-
mos conceitos core que com um balanceador de carga normal, que é no que nos iremos
concentrar neste capítulo para que entenda como tudo funciona no Azure.
8.1.1 Criar um conjunto IP de front-end

Nos capítulos anteriores, criou VMs que tinham um endereço IP público atribuído
diretamente. Utilizou então este endereço IP público para aceder à VM com uma liga-
ção remota, como SSH ou RDP, ou utilizou um browser para aceder a um site que foi
executado na VM. Quando utiliza um balanceador de carga, já não se liga diretamente
às VMs. Em vez disso, para permitir que o tráfego chegue ao seu balanceador de carga
e seja distribuído para as suas VMs, devem ser atribuídos um ou mais endereços IP à
interface externa de um balanceador de carga.
Os balanceadores de carga podem funcionar num dos dois modos:
¡ Balanceador de carga da Internet: tem um ou mais endereços IP públicos ligados ao
conjunto IP de front-end. Um balanceador de carga da Internet recebe o tráfego
da Internet diretamente e distribui o mesmo para as VMs de back-end. Um exem-
plo comum seria o dos servidores Web de front-end aos quais os clientes acedem
diretamente através da Internet.
¡ Balanceador de carga interno: tem um ou mais endereços IP privados ligados ao con-
junto IP de front-end. Um balanceador de carga interno funciona dentro de uma
rede virtual do Azure, por exemplo, para VMs de bases de dados de back-end. Nor-
malmente, as bases de dados de back-end ou os escalões de aplicações não estão
expostos ao mundo exterior. Em vez disso, um conjunto de servidores Web de fron-
t-end é ligado a um balanceador de carga interno que distribui o tráfego sem
nenhum acesso público direto. A figura 8.2 mostra como um balanceador de carga
interno pode distribuir o tráfego para as VMs de back-end que estão atrás de um
balanceador de carga destinado ao público e para as VMs Web de front-end.
VM de VM de
front-end back-end
Balanceador de VM de Balanceador de VM de
Internet
carga da Internet front-end carga interno back-end
VM de VM de
front-end back-end
Figura 8.2 Um balanceador de carga da Internet pode ser utilizado para distribuir o tráfego para as VMs
de front-end que executam o seu site e que, em seguida, se ligam a um balanceador de carga interno para
distribuir o tráfego para um escalão de base de dados de VMs. O balanceador de carga interno não
é acessível publicamente e só pode ser acedido pelas VMs de front-end na rede virtual do Azure.
O modo do balanceador de carga não altera o comportamento do

conjunto IP de front-end. Atribui um ou mais endereços IP que são utilizados quando
o acesso ao balanceador de carga é pedido. Ambos os endereços IPv4 e IPv6 podem ser
configurados no conjunto IP de front-end, permitindo-lhe configurar as comunica-
ções IPv6 de ponto a ponto entre os clientes e as VMs à medida que o fluxo do tráfego
entra e sai do balanceador de carga.
Experimente agora
Para entender como os componentes do balanceador de carga funcionam em conjunto, con-
clua os passos a seguir para criar um balanceador de carga e um conjunto IP de front-end.
1 Abra o portal Azure e selecione o ícone do Cloud Shell na parte superior

do dashboard.
2 Crie um grupo de recursos com az group create.
Especifique um nome de grupo de recursos, tal como azuremolchapter8,
e uma localização:
az group create --name azuremolchapter8 --location westeurope
Enquanto continua a desenvolver o capítulo 7, irá precisar de utilizar zonas de

disponibilidade; preste atenção à região que vai selecionar para assegurar que a
zona de disponibilidade tem suporte na mesma.
3 Crie um endereço IP público com o comando az network public-ip create.
No capítulo 7, aprendeu que as zonas de disponibilidade fornecem redundân-
cia aos recursos de rede, por isso, crie um endereço IP público padrão com redun-
dância entre zonas e especifique um nome, como publicip:
az network public-ip create \
--name publicip \
--sku standard
Para criar um endereço IP público IPv6, pode adicionar --version IPv6

ao comando anterior. Nestes exercícios, pode utilizar endereços IPv4.
4 Crie o balanceador de carga e atribua o endereço IP público ao conjunto
IP de front-end. Para adicionar o endereço IP público, especifique o parâmetro
--public-ip-address. Se pretendesse criar um balanceador de carga interno,
iria utilizar o parâmetro --private-ip-address em alternativa.
Tal como com o endereço IP público, crie um balanceador de carga padrão
com redundância entre zonas que funcione nas zonas de disponibilidade:
az network lb create \
--name loadbalancer \
--public-ip-address publicip \
--frontend-ip-name frontendpool \
--backend-pool-name backendpool \
--sku standard
Dentro de algumas páginas iremos ver o que é o conjunto de back-end.
8.1.2 Criar e configurar sondagens do estado de funcionamento

Se uma das VMs que executam a sua aplicação tiver um problema, acha que o balan-
ceador de carga deve continuar a distribuir o tráfego para essa VM? Um cliente que
tente aceder à sua pizzaria poderia ser direcionado para essa VM e não ser capaz de
realizar o seu pedido! Um balanceador de carga monitoriza o estado das VMs e pode
remover as VMs que têm problemas. O balanceador de carga continua a monitorizar o
estado de funcionamento e adiciona novamente a VM ao conjunto de distribuição do
tráfego, quando é indicado que a VM responde novamente de forma correta.
Uma sondagem do estado de funcionamento pode funcionar de alguns modos:
¡ Baseado na porta: o balanceador de carga verifica se há resposta de uma VM numa
porta e protocolo específicos, como a porta TCP 80. Enquanto a VM responder à son-
dagem do estado de funcionamento na porta TCP 80, a VM permanecerá na distri-
buição de tráfego do balanceador de carga. Caso contrário, a VM será removida da
distribuição de tráfego do balanceador de carga, como mostrado na figura 8.3. Este
modo não garante que a VM providencie o tráfego conforme o esperado, apenas que
a conectividade de rede e o serviço de destino devolvam uma resposta.
¡ Baseado no caminho HTTP: em cada VM é escrita uma página personalizada (como,
por exemplo, health.html). Este estado de funcionamento personalizado pode
ser utilizado para verificar o acesso a um arquivo de imagens ou a uma ligação de
base de dados. Neste modo, a VM permanece na distribuição de tráfego do balan-
ceador de carga apenas quando a página de verificação do estado de funciona-
mento devolve uma resposta com código HTTP 200, como mostrado na figura
8.4. Com uma sondagem do estado de funcionamento baseada na porta, o servi-
dor Web real pode ser executado, mas não tem nenhuma ligação de base de
dados. Com uma página de verificação do estado de funcionamento personali-
zada, o balanceador de carga pode confirmar que a VM é capaz de providenciar o
tráfego real ao cliente.
Verifica a resposta na
Balanceador de carga porta TCP 80
Internet Sondagem do estado VM
de funcionamento
Removido da distribuição
do balanceador de carga
se não houver resposta
Figura 8.3 Uma sondagem do estado de funcionamento de um balanceador de carga baseada na porta
verifica se existe resposta da VM numa porta e protocolo definidos. Se a VM não responder dentro do
limiar determinado, a VM será removida da distribuição de tráfego do balanceador de carga. Quando
a VM começa a responder novamente de forma correta, a sondagem do estado de funcionamento
deteta a alteração e adiciona novamente a VM à distribuição de tráfego do balanceador de carga.
Verifica a resposta do código VM

Balanceador de carga HTTP 200 (OK) de health.html
Servidor web
Internet Sondagem do estado
de funcionamento health.html
Removido da distribuição
do balanceador de carga se
não devolver HTTP 200 (OK)
Figura 8.4 Uma VM que execute um servidor Web e tenha uma página health.html personalizada
permanece na distribuição de tráfego do balanceador de carga, contanto que a sondagem do estado
de funcionamento receba uma resposta com código HTTP 200 (OK). Se o processo do servidor Web
encontrar um problema e não puder devolver as páginas pedidas, essas páginas serão removidas da
distribuição de tráfego do balanceador de carga. Este processo fornece uma verificação mais completa
do estado do servidor Web do que as sondagens do estado de funcionamento baseadas na porta.
Criar uma página de verificação do estado de funcionamento personalizada requer

mais trabalho, mas a melhoria na experiência do cliente faz com que valha a pena.
A página de verificação do estado de funcionamento não precisa de ser complicada.
Pode ser uma página HTML básica que é utilizada para confirmar que o servidor Web
pode providenciar páginas. Sem a página de verificação do estado de funcionamento,
se o processo do servidor Web apresentar um problema, a VM continua a estar disponí-
vel na porta TCP 80, de tal forma que a sondagem do estado de funcionamento
baseada na porta iria considerar que a VM se encontra em bom estado de funciona-
mento. Uma sondagem do estado de funcionamento baseada no caminho HTTP
requer que o servidor Web devolva corretamente uma resposta HTTP. Se o processo
do servidor Web deixar de responder ou falhar, não é enviada uma resposta HTTP, por
isso, a VM é removida da distribuição de tráfego do balanceador de carga.
A frequência com que a sondagem do estado de funcionamento verifica a VM
e o tipo de resposta também podem ser configurados através de dois parâmetros:
¡ Intervalo: define a frequência com que a sondagem do estado de funcionamento
verifica o estado da VM. Por predefinição, a sondagem do estado de funciona-
mento verifica o estado a cada 15 segundos.
¡ Limiar: define o número de falhas de resposta consecutivas que a sondagem do
estado de funcionamento deve receber antes de a VM ser removida da distribui-
ção de tráfego do balanceador de carga. Por predefinição, a sondagem do estado
de funcionamento tolera duas falhas consecutivas antes de a VM ser removida da
distribuição de tráfego do balanceador de carga.
Experimente agora
Para criar uma sondagem do estado de funcionamento para o seu balanceador
de carga, como na figura 8.4, conclua os seguintes passos:

dodashboard.
2 Especifique um nome para a sondagem do estado de funcionamento, como
healthprobe. Para configurar a sondagem do estado de funcionamento para um
servidor Web, especifique a porta HTTP 80 e, em seguida, defina uma página de
verificação do estado de funcionamento personalizada em health.html. Na sec-
ção 8.2, irá criar esta página de verificação do estado de funcionamento nas suas
VMs. Para mostrar como o intervalo e o limiar de resposta da sondagem do
estado de funcionamento podem ser configurados, defina um intervalo de 10
segundos e um limiar de três falhas consecutivas:
az network lb probe create \
--lb-name loadbalancer \
--name healthprobe \
--protocol http \
--port 80 \
--path health.html \
--interval 10 \
--threshold 3
Depois de a sondagem do estado de funcionamento ser criada, o que deve fazer para
verificar o estado das suas VMs? As sondagens do estado de funcionamento estão asso-
ciadas às regras do balanceador de carga. A mesma sondagem do estado de funciona-
mento pode ser utilizada com várias regras do balanceador de carga. Lembra-se do
capítulo 5, no qual criou grupos de segurança de rede (NSGs) e regras? Estes NSGs
podem ser associados a várias VMs ou sub-redes da rede virtual. Às sondagens do estado
de funcionamento aplica-se uma relação um para muitos semelhante.
Vamos ver como podemos colocar a sua sondagem do estado de funcionamento a
funcionar e criar regras do balanceador de carga.
8.1.3 Definir a distribuição de tráfego com regras do balanceador de carga

Quando o tráfego é direcionado pelo balanceador de carga para as VMs de back-end,
pode definir quais condições fazem com que o utilizador seja direcionado para a
mesma VM. Pode pretender que o utilizador mantenha uma ligação à mesma VM
durante uma única sessão ou permitir que o utilizador retorne e mantenha a sua afini-
dade de VM com base no endereço IP de origem. A figura 8.5 mostra um exemplo do
modo de afinidade de sessão predefinido.
No modo de afinidade de sessão, o fluxo de tráfego é processado por um hash de
5 cadeias de identificação que utiliza o endereço IP de origem, a porta de origem, o
endereço IP de destino, a porta de destino e o tipo de protocolo. Basicamente, cada
pedido que um utilizador faz ao seu servidor Web na porta TCP 80 é direcionado para a
mesma VM de back-end durante essa sessão.
O que acontece se o cliente fechar a sessão do browser? Da próxima vez que se ligar,
será iniciada uma nova sessão. Como o balanceador de carga distribui o tráfego por
todas as VMs em bom estado de funcionamento no conjunto IP de back-end, é possível
que o utilizador se ligue novamente à mesma VM; mas quanto mais VMs tiver no conjunto
IP de back-end, maior será a possibilidade de o utilizador se ligar a uma VM diferente.
Conjunto de
back-end
Regra do balanceador
de carga VM 1
Sessão 1
Modo de afinidade de
sessão (predefinido)
Sessão 1 Hash de 5 cadeias de identificação:
• IP de origem
Internet Sessão 2 • Porta de origem VM 2
• IP de destino
• Porta de destino
• Tipo de protocolo
Sessão 2
VM 3
Figura 8.5 No modo de afinidade de sessão, o utilizador liga-se à mesma VM de back-end apenas
durante a sessão.
Como programador e proprietário da aplicação, talvez queira que o utilizador se ligue

à mesma VM que anteriormente quando iniciar outra sessão. Se a sua aplicação proces-
sar transferências de ficheiros ou utilizar UDP em vez de TCP, por exemplo, é provável
que pretenda que a mesma VM continue a processar os pedidos de um utilizador. Nes-
tes cenários, pode configurar as regras do balanceador de carga para que proporcio-
nem afinidade de IP de origem. A figura 8.6 mostra um exemplo do modo de afinidade
de IP de origem.
Conjunto de
back-end
Regra do balanceador
de carga Sessão 1 VM 1
Modo de afinidade de IP de origem Sessão 2
Hash de 2 cadeias Hash de 3 cadeias
Sessão 1 de identificação: de identificação:
• IP de origem • IP de origem
Internet Sessão 2 VM 2
• IP de destino • IP de destino
• Protocolo
VM 3
Figura 8.6 Quando configura as regras do balanceador de carga para utilizar o modo de afinidade de
IP de origem, o utilizador pode fechar e, em seguida, iniciar uma nova sessão, mas continuar a ligar-
se à mesma VM de back-end. O modo de afinidade de IP de origem pode utilizar um hash de 2 cadeias
de identificação que utiliza o endereço IP de origem e destino ou um hash de 3 cadeias de identificação
que também utiliza o protocolo.
Experimente agora
Para criar uma regra do balanceador de carga que utiliza uma sondagem do estado
de funcionamento, conclua os passos a seguir:

do dashboard.
2 Para criar uma regra do balanceador de carga, especifique um nome para
a regra, como httprule.
3 Forneça a porta externa na qual o tráfego é recebido e a porta interna para a
qual o tráfego é distribuído. Neste exemplo básico, o tráfego é recebido na porta
80 e, em seguida, distribuído na porta 80:
az network lb rule create \
--name httprule \
--protocol tcp \
--frontend-port 80 \
--backend-port 80 \
--frontend-ip-name frontendpool \
--backend-pool-name backendpool \
--probe-name healthprobe
Se executar vários sites numa VM que responda em portas diferentes, uma determi-
nada regra poderá direcionar o tráfego para um site específico na VM.
8.1.4 Encaminhar o tráfego direto com regras de Tradução de Endereços de Rede

As regras do balanceador de carga distribuem o
Internet tráfego pelos conjuntos de back-end das VMs, por
isso, não há nenhuma garantia de que possa ligar-
-se a uma determinada VM para fins de manuten-
ção ou gestão. Como pode ligar-se a uma VM
Balanceador de carga específica que está atrás de um balanceador de
Regras de Tradução de Endereços de Rede l carga? Uma parte final da configuração do balan-
Tráfego direto: porta TCP 5000 externa - >
ceador de carga na qual devemos debruçar-nos
Porta TCP 22 interna são as regras de Tradução de Endereços de Rede
(NAT), que lhe permitem controlar o fluxo de trá-
fego específico para direcioná-lo para uma única
VM. A Figura 8.7 mostra como as regras NAT
Grupo de segurança de rede encaminham o tráfego específico para VMs
Regras do grupo de segurança de rede
individuais.
Permitir porta TCP 22 externa-> Porta TCP 22 interna
Figura 8.7 O tráfego no balanceador de carga é processado

pelas regras NAT. Se um protocolo e uma porta corresponderem
a uma regra, o tráfego será encaminhado para a VM de
back-end definida. Nenhuma sondagem do estado de
funcionamento está anexada, por isso, o balanceador de carga
VM não verifica se a VM é capaz de responder antes de encaminhar
o tráfego. O tráfego sai do balanceador de carga e, em seguida,
é processado pelas regras do NSG. Se o tráfego for permitido,
será passado para a VM.
As regras NAT funcionam em conjunto com as regras do NSG. A VM pode receber o

tráfego apenas se houver uma regra do NSG que permita o mesmo tráfego que a regra
NAT do balanceador de carga.
Por que poderia pretender criar regras NAT? Se pretender utilizar SSH ou RDP para
se ligar a uma VM específica (e não utilizar o Azure Bastion, que mencionei no capítulo
2) ou utilizar ferramentas de gestão para se ligar a um servidor de base de dados de
back-end? Se o balanceador de carga distribuir o tráfego pelas VMs de back-end, terá de
tentar ligar-se várias vezes, e talvez ainda assim não consiga ligar-se à VM pretendida.
Manter a segurança
Analisaremos alguns tópicos de segurança na parte 3 do livro, mas a segurança deve
ser uma consideração sempre presente à medida que cria e executa aplicações no
Azure. A segurança não deve ser algo deixado para mais tarde. Com o surgimento do
cloud computing, de VMs descartáveis e de aplicações Web, é fácil ignorar algumas
melhores práticas básicas de segurança. Especialmente se trabalha no Azure como
parte de uma subscrição empresarial mais ampla, certifique-se de que os recursos cria-
dos não fornecem acidentalmente uma maneira de os hackers obterem acesso à sua
infraestrutura.
Que tipo de coisas não devem ser feitas? Bem, algumas coisas que já viu neste
livro! As portas de gestão remota para SSH e RDP não devem ser abertas à Internet pública
como fez. Deve, pelo menos, restringir o acesso a um intervalo de endereços IP específico.
A melhor prática seria utilizar um serviço gerido como o Azure Bastion ou criar
manualmente uma VM segura que tenha gestão remota disponível. Quando for necessá-
rio, liga-se ao host do Azure Bastion ou à sua VM protegida e, em seguida, liga-se às VMs
adicionais através da rede virtual interna do Azure. No capítulo 5 utilizou esta aborda-
gem básica de VM jumpbox. Esta abordagem minimiza a superfície de ataque e reduz a
necessidade de utilizar regras do NSG e regras NAT do balanceador de carga. No capí-
tulo 16 aborda-se a Centro de Segurança do Azure e mostra-se como pode pedir e abrir
dinamicamente as portas de gestão remota durante um período específico, o que
é o melhor de ambos os mundos.
Mesmo que trabalhe numa subscrição privada do Azure sem conectividade com outras
subscrições do Azure na escola ou no trabalho, tente minimizar a quantidade de conecti-
vidade remota que fornece.
Experimente agora
Para criar uma regra NAT do balanceador de carga, conclua os passos a seguir:

do dashboard.
2 Para criar uma regra NAT do balanceador de carga, defina um nome, como
natrulessh, e o conjunto IP de frontend que será utilizado. A regra NAT exa-
mina o tráfego num determinado protocolo e porta, como a porta TCP 50001.
Quando há uma correspondência de regras, o tráfego é encaminhado para
a porta de back-end 22:
az network lb inbound-nat-rule create \

--name natrulessh \
--protocol tcp \
--frontend-port 50001 \
--backend-port 22 \
--frontend-ip-name frontendpool
Neste ponto, criou um balanceador de carga básico. Examine como os componentes

do balanceador de carga se uniram:
az network lb show \
--name loadbalancer
Um endereço IP público foi atribuído ao conjunto IP de front-end e criou uma sonda-

gem do estado de funcionamento para verificar o estado de um servidor Web numa
página de verificação do estado de funcionamento personalizada. Foi criada uma regra
do balanceador de carga para distribuir o tráfego Web dos seus clientes para um con-
junto de back-end. A regra utiliza a sondagem do estado de funcionamento. Também
tem uma regra NAT do balanceador de carga que permite o tráfego SSH, mas ainda
não há VMs que recebam esse tráfego. Os clientes da sua pizzaria têm fome, por isso
vamos criar algumas VMs que possam executar a sua aplicação Web e para as quais
o balanceador de carga possa distribuir o tráfego!
8.1.5 Atribuir grupos de VMs a conjuntos de back-end

A secção final do balanceador de carga define conjuntos de back-end que incluem uma
ou mais VMs. Estes conjuntos de back-end contêm VMs que executam os mesmos com-
ponentes das aplicações, o que permite que o balanceador de carga distribua o tráfego
para um determinado conjunto de back-end e confie que qualquer VM nesse conjunto
possa responder corretamente ao pedido do cliente. A figura 8.8 detalha como os con-
juntos de back-end agrupam logicamente as VMs que executam as mesmas aplicações.
Conjunto de back-end: VM de
escalão de aplicação
VM 1 VM 2 VM 3
Regras do
Conjunto IP balanceador
Internet de front-end de carga
Sondagens do Conjunto de back-end: VM multimédia
estado de
funcionamento
VM 1 VM 2 VM 3
Figura 8.8 Podem ser criados um ou mais conjuntos de back-end num balanceador de carga. Cada
conjunto de back-end contém uma ou mais VMs que executam o mesmo componente da aplicação.
Neste exemplo, um conjunto de back-end contém VMs que executam o escalão de aplicações Web e
outro conjunto de back-end contém as VMs que fornecem conteúdo multimédia, como imagens e vídeo.
Cria e utiliza um balanceador de carga com VMs, mas tudo funciona ao nível da rede
virtual. O conjunto IP de front-end utiliza endereços IP públicos ou privados. A sonda-
gem do estado de funcionamento examina as respostas numa determinada porta ou
protocolo. Mesmo quando é utilizada uma sondagem HTTP, o balanceador de carga
procura uma resposta positiva da rede. As regras do balanceador de carga concentram-
-se em como distribuir o tráfego a partir de uma porta externa no conjunto de front-
-end para uma porta no conjunto de back-end.
Quando atribui VMs ao conjunto de back-end que recebe o tráfego distribuído pelo
balanceador de carga, é a NIC virtual que é ligada ao balanceador de carga. A VM é
anexada à NIC virtual. Pense no capítulo 5 e verá que esta separação de VMs e NICs vir-
tuais faz sentido no que diz respeito ao modo como os recursos são geridos. As regras do
NSG controlam o tráfego que pode entrar na VM, mas são aplicadas a uma sub-rede da
rede virtual ou NIC virtual, não à VM.
Quais são as implicações disto na configuração dos conjuntos IP de back-end? Tem
de criar o resto dos seus recursos de rede virtual antes de poder ligar uma VM ao balan-
ceador de carga. Os passos para criar os recursos de rede são um resumo do que
aprendeu há alguns capítulos, por isso vamos ver do quanto se lembra!
Rede virtual
Sub-rede
Grupo de segurança de rede

Permir porta TCP 80 (HTTP)
Permir porta TCP 22 (SSH)
NIC NIC Figura 8.9 Para preparar

a rede virtual, neste
virtual 1 virtual 2 exercício, irá criar uma
rede, uma sub-rede e NICs
virtuais protegidas por um
NSG. As regras anexadas
ao NSG permitem o tráfego
HTTP e SSH.
Experimente agora
Para criar os recursos de rede adicionais, como mostrado na figura 8.9, conclua os pas-
sos a seguir:
1 Abra o portal Azure e selecione o ícone do Cloud Shell na parte superior do

dashboard.
2 Criar uma rede virtual e uma sub-rede:
az network vnet create \
--name vnetmol \
--address-prefixes 10.0.0.0/16 \
--subnet-name subnetmol \
--subnet-prefix 10.0.1.0/24
Na prática, há uma boa possibilidade de que estes recursos de rede já existam.

Portanto, estes nomes e intervalos de endereços IP são os mesmos utilizados no
capítulo 5. Deve limpar os recursos do Azure no final de cada capítulo para que a
reutilização dos intervalos IP não seja um problema. Apenas esteja ciente de que
normalmente não irá criar uma rede virtual e uma sub-rede sempre que criar um
balanceador de carga. Em vez disso, pode utilizar os recursos de rede virtual exis-
tentes que já estão implementados.
3 Criar um NSG:
az network nsg create \
--name webnsg
4 Crie uma regra do NSG que permita que o tráfego da porta TCP 80 chegue
às suas VMs. Esta regra é necessária para que as VMs do servidor Web recebam
e respondam ao tráfego do cliente:
--nsg-name webnsg \
--name allowhttp \
--priority 100 \
--protocol tcp \
--access allow
5 Adicione outra regra para gerir o tráfego SSH de forma remota. Esta regra do
NSG funciona com a regra NAT do balanceador de carga criada na secção 8.1.4
para uma das suas VMs:
--nsg-name webnsg \
--name allowssh \
--priority 101 \
--protocol tcp \
--access allow
6 Associe o NSG à sub-rede criada no passo 2. As regras do NSG são aplicadas a

todas as VMs que se ligam a esta sub-rede:
az network vnet subnet update \
--name subnetmol \
--network-security-group webnsg
7 O balanceador de carga funciona com NICs virtuais, portanto, crie duas NICs
virtuais e ligue-as à sub-rede da rede virtual. Também especifique o nome do
balanceador de carga e o conjunto de endereços de back-end aos quais as NICs
virtuais se ligam. A regra NAT do balanceador de carga só é anexada à primeira
NIC virtual criada:
az network nic create \
--name webnic1 \
--subnet subnetmol \
Criar e configurar VMs com o balanceador de carga 119
--lb-address-pools backendpool \
--lb-inbound-nat-rules natrulessh
8 Crie a segunda NIC da mesma forma, menos a regra NAT do balanceador de carga:
az network nic create \
--name webnic2 \
--subnet subnetmol \
--lb-address-pools backendpool
8.2 Criar e configurar VMs com o balanceador de carga

Façamos uma pausa para explorar o que criou. A figura 8.10 mostra o cenário global
dos seus recursos de rede e o balanceador de carga. Veja o grau de integração destes
recursos. O balanceador de carga não pode existir por si só. As NICs virtuais devem
estar ligadas
Internet
Balanceador
de carga
Conjunto IP de front-end
Sondagem do estado de funcionamento

Sondagem do caminho para verificar
health.html em VM de back-end
Regras do balanceador de carga
Permir porta TCP 80 de entrada -> Porta TCP 80

no conjunto de back-end
Back-end IP piscina
Figura 8.10 Aqui não
NIC NIC NIC foi criada nenhuma VM,
virtual virtual virtual a configuração do balan
Grupo de segurança de rede ceador de carga lida com os
Sub-rede da rede virtual recursos de rede virtual. Há
uma estreita relação entre
Rede virtual
o balanceador de carga e os
recursos de rede virtual.
ao balanceador de carga para que qualquer tráfego seja distribuído. Essas NICs virtuais
requerem uma rede virtual e uma sub-rede e, idealmente, estão protegidas por um
NSG. As VMs que executam a sua aplicação não têm quase nada a ver com os passos
para criar e configurar o balanceador de carga!
Criou muitos recursos de rede e configurou várias partes do balanceador de carga.

O endereço IP público e o balanceador de carga foram criados numa zona de disponi-
bilidade como recursos com redundância entre zonas, portanto, vamos criar duas VMs
em zonas diferentes para reforçar como as zonas de disponibilidade melhoram a ele-
vada disponibilidade das suas aplicações.
Se utilizar Conjuntos de Disponibilidade em vez de Zonas de Disponibilidade, é aqui
que irá criar primeiro um Conjunto de Disponibilidade e, em seguida, irá adicionar as
suas VMs. Em seguida, a plataforma do Azure distribui as VMs pelos domínios de falha e
atualização. Pretende maximizar a utilização da elevada disponibilidade do Azure para
a sua pizzaria e, por isso, utiliza Zonas de Disponibilidade.
Experimente agora
Para criar as VMs e anexá-las ao balanceador de carga, conclua os passos a seguir:
1 Crie a primeira VM e atribua-a a uma zona de disponibilidade com --zone 1:

az vm create \
--name webvm1 \
--image ubuntults \
--zone 1 \
--nics webnic1
2 Crie a segunda VM. Atribua-a à zona de disponibilidade 2 e anexe a segunda NIC

virtual que criou anteriormente, utilizando --nics webnic2:
az vm create \
--name webvm2 \
--image ubuntults \
--zone 2 \
--nics webnic2
Para ver o balanceador de carga em ação, precisa de instalar um servidor Web básico,
como fez no capítulo 2. Também pode testar a regra NAT do balanceador de carga.
Pode começar a ver como todos estes componentes do Azure estão relacionados e
como são criados uns sobre os outros?
Experimente agora
No capítulo 5, falámos sobre o agente SSH. O agente SSH permite-lhe passar uma
chave SSH de uma VM para a próxima. Apenas a VM1 tem uma regra NAT do balancea-
dor de carga, por isso precisa de utilizar o agente para se ligar à VM2. Para instalar um
servidor Web nas suas VMs, conclua os passos a seguir:
Criar e configurar VMs com o balanceador de carga 121
1 Inicie o agente SSH e adicione a sua chave SSH para se ligar a ambas as VMs:
eval $(ssh-agent) && ssh-add
2 Obtenha o endereço IP público anexado ao conjunto IP de front-end do balancea-

dor de carga. Esta é a única maneira de encaminhar o tráfego através das VMs:
az network public-ip show \
--name publicip \
--query ipAddress \
--output tsv
3 Agora está pronto para utilizar SSH para VM 1. Especifique o endereço IP

público do balanceador de carga (substitua <your-ip-address> no seguinte
comando) e a porta que foi utilizada com a regra NAT do balanceador de carga,
como 50001. O parâmetro -A utiliza o agente SSH para passar pelas chaves SSH:
ssh -A azuremol@<your-ip-address> -p 50001
No capítulo 2, utilizou apt-get para instalar todo o LAMP stack, incluindo o ser-
vidor Web Apache. Vamos ver algo um pouco diferente do servidor Web Apache
com o independente, mas poderoso servidor Web NGINX. Numa VM Windows, o
IIS normalmente seria instalado aqui. Execute o seguinte comando para instalar
o servidor web NGINX:
sudo apt update && sudo apt install -y nginx
4 No repositório de exemplos do GitHub que utilizou nos capítulos anteriores, há

uma página Web básica HTML e uma página de verificação do estado de funcio-
namento para a sondagem do estado de funcionamento do balanceador de
carga. Clone estes exemplos na VM:
5 Copie a página HTML de exemplo e a verificação do estado de funcionamento

para o diretório do servidor Web:
sudo cp azure-mol-samples-2nd-ed/08/webvm1/* /var/www/html/
6 Agora é necessário ligar-se à segunda VM e instalar o servidor web NGINX e o

código de exemplo. Lembra-se do agente SSH? Deve ser capaz de estabelecer
uma ligação SSH da VM 1 à VM 2 no endereço IP interno privado:
ssh 10.0.1.5
7 Instale o servidor Web NGINX:

sudo apt update && sudo apt install -y nginx
8 Clone os exemplos do GitHub na VM:

9 Copie a página HTML de exemplo e a verificação do estado de funcionamento

para o diretório do servidor Web:
sudo cp azure-mol-samples-2nd-ed/08/webvm2/* /var/www/html/
Abra um browser e ligue-se ao endereço IP público do seu balanceador de carga.

A página Web básica é carregada e mostra que a sua pizzaria agora tem VMs redundan-
tes em Zonas de Disponibilidade que são executadas atrás de um balanceador de carga,
como mostrado na figura 8.11! Talvez seja necessário forçar a atualização do browser
para ver se a VM 1 e a VM2 respondem à medida que o balanceador de carga distribui
o tráfego entre as mesmas.
Figura 8.11 Quando abre o endereço IP público do balanceador de carga num browser, o tráfego é
distribuído para uma das VMs que executam o seu site básico. A sondagem do estado de funcionamento
do balanceador de carga utiliza a página health.html para confirmar as respostas do servidor Web com
um código HTTP 200 (OK). Em caso afirmativo, a VM fica disponível como parte da distribuição de
tráfego do balanceador de carga.
8.3 Laboratório: ver modelos de implementações existentes

Este capítulo reúne o que aprendeu nos vários capítulos anteriores. Criou recursos de
rede, como no capítulo 5. No capítulo 7 fez com que o balanceador de carga e as VMs
tivessem elevada disponibilidade com Zonas de Disponibilidade. No capítulo 2 insta-
lou um servidor Web e implementou ficheiros de exemplo. A sua pizzaria percorreu
um longo caminho desde começou como uma página Web básica numa única VM no
início do livro!
Para associar mais um tema de um capítulo anterior, neste laboratório, pretendo que
explore todos os recursos que compõem o balanceador de carga. Para isto, consulte
o modelo do Resource Manager, como aprendeu no capítulo 6. O objetivo deste labora-
tório é ver como um único modelo permite criar e configurar algo que requereu muitas
páginas e vários comandos da CLI. E, confie em mim, isso envolveria ainda mais coman-
dos do PowerShell! Siga estes passos:
1 Abra o portal Azure.

2 Navegue para o Grupo de Recursos e selecione-o na barra de navegação situada
à esquerda no portal.
Laboratório: ver modelos de implementações existentes 123
3 Escolha o seu grupo de recursos, como azuremolchapter8.

4 Escolha Exportar Modelo na barra do lado esquerdo, como mostra a figura 8.12.
5 Para ver a parte relevante do modelo, selecione cada um dos recursos mostrados
na lista. Dedique alguns minutos para explorar este modelo e veja como todos os
recursos e componentes configurados na CLI do Azure estão presentes.
Figura 8.12 No portal Azure, selecione o grupo de recursos do balanceador de carga e veja o modelo do
Resource Manager.
Um modelo facilita bastante a implementação de um ambiente de aplicação de ele-

vada disponibilidade, redundante e com balanceamento de carga. Pode alterar
o nome, as regras e o modo de distribuição do balanceador de carga e permitir que
o modelo implemente e conFigura todo o ambiente de aplicação por si.
Não se esqueça de eliminar este grupo de recursos para tirar o máximo partido dos
seus créditos gratuitos do Azure!
Aplicações dimensionáveis
9
Nos dois capítulos anteriores, examinámos como criar aplicações altamente disponíveis
e utilizar balanceadores de carga para distribuir o tráfego para várias VMs que executam a
sua aplicação. Mas, como executa e gere eficientemente várias VMs e executa o número
certo de instâncias de VM quando os seus clientes mais precisam? Quando
a procura do cliente aumenta, pretende aumentar automaticamente o dimensionamento da
sua aplicação para lidar com essa procura. E quando a procura diminui, como no meio da
noite, quando a maioria das pessoas sem filhos pequenos estão a dormir, pretende diminuir
o dimensionamento da aplicação e poupar algum dinheiro.
No Azure, pode dimensionar automaticamente os recursos de IaaS com conjuntos de
dimensionamento de virtual machines. Estes conjuntos de dimensionamento executam VMs
idênticas, normalmente distribuídas atrás de um balanceador de carga ou gateway da aplica-
ção. Define as regras de dimensionamento automático que aumentam ou diminuem
o número de instâncias de VM à medida que a procura do cliente muda. O balanceador de
carga ou o gateway da aplicação distribui automaticamente o tráfego para as novas instâncias
de VM, o que lhe permite concentrar-se em como criar e executar melhor as suas aplicações.
Os conjuntos de dimensionamento dão-lhe o controlo dos recursos de IaaS com algumas das
vantagens elásticas de PaaS. As aplicações Web, sobre as quais não falámos muito nos últimos
capítulos, aparecem agora neste capítulo, com a sua própria capacidade de dimensiona-
mento com a procura de aplicações.
Neste capítulo, examinaremos como conceber e criar aplicações que podem ser dimen-
sionadas automaticamente. Vimos por que esta capacidade de dimensionar com a procura o
ajuda a executar aplicações eficientes e a explorar diferentes maneiras de dimensionar com
base em métricas diferentes.
9.1 Por que criar aplicações dimensionáveis e fiáveis?

O que significa criar aplicações que dimensionam? Permite que cresça e acompanhe
a procura do cliente à medida que o workload aumenta, mesmo quando está no cinema
durante um fim de semana. Isso significa não ficar preso a uma fatura por muitos recursos
adicionais que não são utilizados ou, pior ainda, que a aplicação seja desativada devido à
124
Por que criar aplicações dimensionáveis e fiáveis? 125
falta de recursos disponíveis. O ponto ideal para as aplicações e os recursos dos quais raramente
necessitam é estático. Normalmente, a aplicação exige refluxo e fluxo durante todo o dia e
noite, ou entre dias úteis e fins de semana.
Há duas maneiras principais segundo as quais pode dimensionar os recursos, como mostrado
na figura 9.1: verticalmente e horizontalmente. Tanto os conjuntos de dimensionamento de vir-
tual machines como as aplicações Web podem ser dimensionados vertical ou horizontalmente.
vCPU Dimensionar vCPU vCPU

verticalmente (reduzir)
vRAM vRAM vRAM vRAM vRAM
Aumentar os
vRAM vRAM recursos atribuídos vRAM vRAM vRAM
vCPU Dimensionar horizon- vCPU vCPU

talmente (aumentar)
vRAM vRAM vRAM vRAM vRAM vRAM
Aumentar o número
vRAM vRAM de instâncias vRAM vRAM vRAM vRAM
Figura 9.1 Pode aumentar e reduzir verticalmente as suas aplicações, ou aumentá-las e reduzi-las horizontalmente.
O método que utiliza depende de como a sua aplicação é criada para processar o dimensionamento. O dimensionamento
vertical ajusta os recursos atribuídos a uma VM ou a uma aplicação Web, como o número de cores de CPU ou
a quantidade de memória. Este método para dimensionar uma aplicação funciona bem se a aplicação executar
apenas uma instância. O dimensionamento horizontal altera o número de instâncias que executam a sua aplicação
e ajuda a aumentar a disponibilidade e a resiliência.
As aplicações dimensionáveis têm uma forte relação com as aplicações altamente disponíveis.
Nos capítulos 7 e 8, falámos bastante sobre os Conjuntos de Disponibilidade e as Zonas de Dispo-
nibilidade, e como configurar os balanceadores de carga. Ambos os capítulos focam a necessi-
dade de executar várias VMs. Quando a sua aplicação pode ser dimensionada automaticamente,
a disponibilidade dessa aplicação também é aumentada à medida que essas VMs são distribuídas
por Conjuntos de Disponibilidade ou Zonas de Disponibilidade. Tudo isto é bom. O poder do
Azure é que não precisa de se preocupar sobre como adicionar mais instâncias de aplicações,
reparti-las por todo o hardware do datacenter ou até mesmo datacenters e, em seguida, atualizar
os recursos de rede para distribuir o tráfego para as novas instâncias da aplicação.
9.1.1 Dimensionar VMs verticalmente

A primeira maneira de dimensionar recursos é muitas vezes a maneira que pode já ter utilizado
no passado. Se a sua aplicação começa a funcionar lentamente à medida que mais clientes a uti-
lizam, como agiria normalmente? Aumentava a quantidade de CvPU ou memória, certo?
Aumenta verticalmente o recurso em resposta à procura.
Uma das utilizações mais comuns do dimensionamento vertical destina-se aos servidores de
base de dados. As bases de dados são notoriamente famintas quando se trata de recursos de com-
putação; ainda mais famintas do que os seus clientes da pizzaria! Muitas vezes, os servidores de
base de dados consomem todos os recursos fornecidos a uma VM, mesmo que não os utilizem
imediatamente. Isto pode dificultar a monitorização das procuras reais no sistema e saber quando
precisa de dimensionar verticalmente e fornecer mais recursos. A Figura 9.2 mostra a resposta de
dimensionamento vertical típica a um servidor de base de dados que precisa de mais recursos.
126 Capítulo 9 Aplicações dimensionáveis
vCPU vCPU Aumentar o processamento (vCPUs) vCPU vCPU vCPU vCPU

vCPU vCPU vCPU vCPU vCPU vCPU
vRAM vRAM Aumentar a memória (vRAM) vRAM vRAM vRAM vRAM

vRAM vRAM vRAM
Figura 9.2 À medida que uma base de dados cresce, precisa de mais recursos para armazenar e processar os dados em
memória. Para dimensionar verticalmente neste cenário, adiciona mais CPU e memória.
Talvez precise de dimensionar além da procura de CPU ou memória. E se executar um site que
processe imensas imagens ou vídeos? Pode não haver muitos requisitos de processamento, mas
as procuras de largura de banda podem ser altas. Para aumentar a largura de banda disponível,
pode aumentar o número de NICs na sua VM. E se precisar de armazenar mais imagens e vídeos,
adiciona mais armazenamento. Pode adicionar ou remover recursos como NICs virtuais e arma-
zenamento à medida que a VM continua a ser executada.
Redimensionar virtual machines
No Azure, pode aumentar o tamanho da VM (aumentar verticalmente) se precisar de mais
recursos de computação para a sua aplicação. No capítulo 2, criou uma VM básica. O seu tama-
nho era provavelmente algo como Standard_D2s_v3. Esse nome não diz muito sobre os recursos
de computação atribuídos a uma VM para determinar se precisa de aumentar a CPU ou a memó-
ria. Se pretender dimensionar verticalmente, precisa de saber quais são as suas opções.
Experimente agora
Siga adiante para ver os tamanhos de VM disponíveis e os recursos de computação:

2 Introduza o seguinte comando da CLI do Azure para listar os tamanhos de VM disponí-
veis e os recursos de computação que fornecem:
az vm list-sizes --location eastus --output table
A saída de az vm list-sizes varia de região para região e muda ao longo do

tempo à medida que o Azure ajusta as suas famílias de VM. Aqui apresentamos um exemplo con-
densado da saída, no qual se mostram os valores MemoryInMb e NumberOfCores que cada tamanho
de VM fornece:
MaxDataDiskCount MemoryInMb Name NumberOfCores
4 8192 Standard_D2s_v3 2
32 65536 Standard_D16s_v3 16
8 4096 Standard_F2s_v2 2
Por que criar aplicações dimensionáveis e fiáveis? 127
2 2048 Standard_B1ms 1
2 1024 Standard_B1s 1
4 8192 Standard_B2ms 2
4 4096 Standard_B2s 2
Portanto, a sua VM Standard_D2s_v3 fornece dois cores de CPU e 8 GB de memória.

Isso é mais do que suficiente para uma VM básica que executa um servidor Web. Vamos
supor que a sua pizzaria online começa a receber alguns pedidos, e pretende dimen-
sionar verticalmente. Pode utilizar az vm resize para escolher outro tamanho. Espe-
cifica o tamanho da VM que tem o número de núcleos de CPU e a memória de que a
sua aplicação precisa.
A CPU e a memória adicionais não aparecem na VM por magia. Este com-
portamento pode ser um pouco diferente do que encontra com o Hyper-V ou VMware
num mundo on-premises. Com razão, pode adicionar ou remover recursos de compu-
tação core num ambiente on-premises à medida que a VM continua a ser executada. No
Azure, é geralmente necessário reiniciar quando efetua o redimensionamento de uma
VM para registar os novos recursos de computação e acionar as regras de faturação
apropriadas. Quando pretende dimensionar verticalmente, planeie algum tempo de
inatividade à medida que a VM é reiniciada.
Reduzir verticalmente
E se tiver uma VM com mais recursos do que precisa? Muitas vezes este cenário é mais
comum do que o de uma VM que tem menos recursos do que o necessário. Os proprie-
tários de aplicações podem escolher um tamanho de VM maior do que o necessário,
para certificarem-se de que a sua aplicação é executada sem problemas. Todos os
recursos desperdiçados custam dinheiro, e é fácil que os custos passem despercebidos
até a fatura chegar no final do mês.
A capacidade de dimensionar recursos funciona em ambas as direções. Concentrá-
mo-nos em como aumentar verticalmente os recursos, mas todos os mesmos conceitos
servem para reduzir verticalmente os recursos. É importante identificar os tamanhos de
VM em utilização e a quantidade de procura que as aplicações fazem nesses recursos.
Pode utilizar az vm resize para escolher um tamanho de VM com menos
núcleos de CPU e memória. Mais uma vez, como em qualquer operação de redimensio-
namento é necessário reiniciar a VM.
9.1.2 Dimensionar aplicações Web verticalmente

As aplicações Web podem ser aumentadas ou reduzidas verticalmente com base nas
necessidades de recursos, da mesma forma que as VMs. Quando criou uma aplicação
Web no capítulo 3, o tamanho Padrão S1 predefinido forneceu um core de CPU e 1,75
GB de RAM. Cada escalão e tamanho da aplicação Web fornece uma quantidade defi-
nida de recursos, como cores de CPU, memória e blocos de teste. Mesmo se o tamanho
predefinido ou a alocação de recursos for alterado ou se escolher um tamanho de apli-
cação Web diferente, o conceito continua o mesmo.
Se criar a sua aplicação Web e achar que a aplicação requer mais recursos do que o
plano de serviço fornece, pode alterar para um escalão diferente, conforme mostrado
na figura 9.3. O mesmo processo funciona se tiver mais recursos do que precisa. A sua
aplicação Web pode ser aumentada ou reduzida verticalmente de forma manual desta
maneira, conforme necessário.
Figura 9.3 Para dimensionar uma aplicação Web verticalmente de forma manual, altera o escalão de
preços (tamanho) do plano do serviço de aplicações subjacente. O plano do serviço de aplicações define
a quantidade de recursos atribuídos à sua aplicação Web. Se a sua aplicação requerer uma quantidade
diferente de armazenamento, número de CPUs ou blocos de implementação, pode alterar para um
escalão diferente para dimensionar corretamente os recursos atribuídos à procura da aplicação.
9.1.3 Dimensionar recursos horizontalmente

Uma abordagem diferente para acompanhar a procura é a redução horizontal. Para
dimensionar verticalmente, aumenta a quantidade de CPU e memória atribuída a um
único recurso, como uma VM. Para dimensionar horizontalmente, em vez disso,
aumenta o número de VMs, como mostrado na figura 9.4.
Para dimensionar horizontalmente, a sua aplicação precisa de estar ciente desta
capacidade e ser capaz de processar dados sem conflitos. Uma aplicação Web é um
ótimo candidato para dimensionar horizontalmente, porque, a aplicação, em geral,
pode processar dados por si só.
À medida que cria aplicações mais complexas, pode dividir uma aplicação em compo-
nentes individuais menores. Se pensar nas filas de armazenamento do Azure do capítulo 4,
Para dimensionar
vCPU horizontalmente, vCPU vCPU vCPU
aumenta o número
vRAM vRAM de VMs que executam vRAM vRAM vRAM vRAM vRAM vRAM
a sua aplicação.
vRAM vRAM vRAM vRAM vRAM vRAM vRAM vRAM
Figura 9.4 Para lidar com um aumento da procura da sua aplicação, pode aumentar o número de VMs
que executam a aplicação, distribuindo a carga por várias VMs, em vez de por VMs de instância única
cada vez maiores.
talvez tenha um componente da aplicação que receba os pedidos Web do front-end e

outro componente da aplicação que processe esses pedidos e os transmita à pizzaria. A
utilização de filas de mensagens é uma abordagem de como criar e escrever aplicações
que podem operar num ambiente que se dimensiona horizontalmente. Esta aborda-
gem também permite dimensionar cada componente da aplicação em separado e utili-
zar diferentes tamanhos de VM ou planos de aplicações Web para maximizar
a eficiência e reduzir a sua fatura mensal.
Historicamente, dimensionaria verticalmente porque seria mais fácil lançar mais
recursos de computação numa aplicação e esperar que o resultado fosse satisfatório.
Configurar um cluster de recursos e dimensionar uma aplicação horizontalmente era
muitas vezes complexo no mundo físico. Com o cloud computing e a virtualização, os
desafios do dimensionamento horizontal são minimizados até ao ponto em que muitas
vezes pode dimensionar horizontalmente mais rapidamente do que verticalmente e
sem tempo de inatividade.
Lembra-se do comando az vm resize anteriormente neste capítulo? O que acon-
tece quando a operação de redimensionamento da VM é concluída? A VM é reiniciada.
Se essa é a única instância da sua aplicação, ninguém pode aceder à mesma até que
volte a ficar online. Quando dimensiona horizontalmente, não há tempo de inativi-
dade quando adiciona instâncias de VM—quando as novas VMs estão prontas, come-
çam a processar alguns dos pedidos da aplicação. As sondagens do estado de
funcionamento do balanceador de carga (capítulo 8) detetam automaticamente
quando uma nova VM no conjunto de back-end está pronta para processar pedidos de
clientes e o tráfego começa a ser distribuído.
O Azure foi concebido para oferecer flexibilidade e escolha quando se trata do modo
como dimensiona. Se estiver a conceber um novo ambiente de aplicação, sugiro que
implemente uma abordagem de dimensionamento horizontal. As VMs têm um parente
muitointeressantenoAzurequepodeajudá-loaqui:osconjuntosdedimensionamentodevir-
tual machines.
9.2 Conjuntos de dimensionamento de virtual machines

As VMs são um dos workloads mais comuns no Azure, por um bom motivo.
A curva de aprendizagem para criar e executar uma VM é superficial, porque a maior
parte do que já sabe, transfere diretamente para o Azure. Os servidores Web são um
dos workloads mais comuns para uma VM, o que é conveniente para que não tenha
que aprender novas competências para transferir o seu conhecimento de como execu-
tar o Apache, o IIS ou o NGINX numa VM do Azure.
Que tal um cluster de VMs que executa um servidor Web? Como lidar com isso no
seu ambiente on-premises normal? Há muitas soluções de cluster possíveis, para come-
çar. E quanto a atualizações para os seus servidores físicos ou VMs? Como lidaria com isso?
E se quisesse aumentar ou diminuir automaticamente o número de instâncias no clus-
ter? Precisa de utilizar outra ferramenta? A figura 9.5 descreve um conjunto de dimen-
sionamento de virtual machines.
Conjunto de dimensionamento
de virtual machines
Zona de disponibilidade 1
VM 1
Balanceador
Internet de carga VM 2
VM 3
Figura 9.5 Um conjunto de dimensionamento de virtual machines agrupa logicamente um conjunto

de VMs. As VMs são idênticas e podem ser centralizadamente geridas, atualizadas e dimensionadas.
É possível definir métricas que aumentem ou diminuam automaticamente o número de VMs no conjunto
de dimensionamento com base na carga da aplicação.
Um conjunto de dimensionamento simplifica a forma como executa e gere várias VMs

para fornecer uma aplicação com elevada disponibilidade e balanceamento de carga. Diz
ao Azure que tamanho de VM deve ser utilizado, uma imagem base para a VM e quantas
instâncias pretende. Em seguida, pode definir métricas de CPU ou memória para aumen-
tar ou diminuir automaticamente o número de instâncias em resposta à carga da aplica-
ção ou numa agenda nas horas de pico do cliente. Os conjuntos de dimensionamento
combinam o modelo IaaS das VMs com o poder das funcionalidades PaaS, como dimen-
sionamento, redundância, automatização e gestão centralizada de recursos.
Um conjunto de dimensionamento de apenas uma VM?

Se criar aplicações em VMs, planeie iniciar com um conjunto de dimensionamento,
mesmo que precise apenas de uma VM. Porquê? Um conjunto de dimensionamento
pode expandir-se a qualquer momento e cria automaticamente as ligações com um
balanceador de carga ou um gateway da aplicação. Se a procura da aplicação aumentar
repentinamente em dois meses, pode informar o conjunto de dimensionamento para
criar uma ou duas instâncias de VM adicionais.
Para expandir uma VM normal e independente, precisa de adicionar essa VM a um balan-
ceador de carga; e se não tiver começado com a VM num Conjunto de Disponibilidade ou
Zona de Disponibilidade, tem de planear como pode tornar essas VMs altamente disponí-
veis. Ao criar um conjunto de dimensionamento para começar, mesmo para uma VM, pre-
para a aplicação para o futuro com o mínimo de trabalho adicional necessário.
9.2.1 Criar um conjunto de dimensionamento de virtual machines

Embora um conjunto de dimensionamento simplifique a criação e a execução de apli-
cações altamente disponíveis, é necessário criar e configurar alguns novos componen-
tes. Dito isso, pode reduzir o processo para dois comandos para implementar um
conjunto de dimensionamento com a CLI do Azure.
Experimente agora
Para criar um conjunto de dimensionamento com a CLI do Azure, conclua
os passos a seguir:
1 Abra o portal Azure e selecione o ícone do Cloud Shell na parte superior do
dashboard.
2 Crie um grupo de recursos com az group create; especifique um nome do
grupo de recursos, como azuremolchapter9, e uma localização:
az group create --name azuremolchapter9 --location westeurope
Os conjuntos de dimensionamento podem utilizar Zonas de Disponibilidade; por-

tanto, certifique-se de que seleciona uma região onde o suporte está disponível.
3 Para criar um conjunto de dimensionamento, especifique o número de instân-
cias de VM pretendidas e como as instâncias de VM devem lidar com as atualiza-
ções da sua configuração. Quando efetua uma alteração nas VMs, como instalar
uma aplicação ou aplicar atualizações do SO convidado, as VMs podem ser auto-
maticamente atualizadas assim que detetarem a alteração. Ou pode definir a
política de atualização como manual e aplicar as atualizações num momento
adequado da sua escolha. Os restantes parâmetros devem ser-lhe familiares
quando criou uma única VM:
az vmss create \
--name scalesetmol \
--image UbuntuLTS \
--instance-count 2 \
--vm-sku Standard_B1ms \
--upgrade-policy-mode automatic \
--lb-sku standard \
--zones 1 2 3
Pronto! Criou várias VMs numa Zona de Disponibilidade que pode ser dimensionada.
Prepare-se para o que é realmente fantástico sobre o conjunto de dimensionamento
que acabou de criar com a CLI do Azure. Lembra-se de todo o capítulo sobre balancea-
dores de carga (capítulo 8), e todos aqueles comandos CLI que tinha de utilizar, e
como os modelos podem simplificar o modo como cria um balanceador de carga?
Aquele comando az vmss create criou e configurou um balanceador de carga para si!
Lembre-se dos limites das suas quotas

Mencionei esta questão das quotas no capítulo 7, mas vale a pena repetir caso
venha a ter problemas. No Azure, as quotas predefinidas na sua subscrição impedem-no
de implementar recursos acidentalmente e esquecer-se dos mesmos, o que lhe irá cus-
tar dinheiro! Pode ver a lista de quotas em http://mng.bz/ddcx.
Quando cria várias VMs, podem surgir problemas de quotas. Também pode vir a ter pro-
blemas se não eliminar os recursos dos capítulos e exercícios anteriores. Se encontrar
uma mensagem de erro do tipo:
Os resultados da operação excedem os limites da quota Core.

Máximo permitido: 4, Atualmente em utilização: 4, Pedido adicional: 2.
é um bom indicador de que precisa de pedir um aumento de quotas. Pode ver a sua
quota atual para uma determinada região da seguinte maneira:
az vm list-usage --location westeurope
Para pedir um aumento das suas quotas de uma região, siga os passos descritos
em http://mng.bz/Xq2f.
A CLI do Azure ajuda a criar um conjunto de dimensionamento com avisos mínimos.

Foi criado e configurado um balanceador de carga, foi atribuído um endereço IP
público e as instâncias de VM do conjunto de dimensionamento foram adicionadas ao
conjunto IP de back-end.
Experimente agora
Consulte os recursos criados com o seu conjunto de dimensionamento, conforme des-
crito nos comandos a seguir.
Para ver quais os recursos que foram criados com o seu conjunto de dimensionamento,
execute o seguinte comando:
az resource list \
--output table
A saída é semelhante ao seguinte exemplo. Veja a coluna Tipo para comprovar que
uma rede virtual, um endereço IP público e um balanceador de carga foram criados:
Name ResourceGroup Type
mol azuremolchapter9 Microsoft.Compute/virtualMachineScaleSets

molLB azuremolchapter9 Microsoft.Network/loadBalancers
molLBIP azuremolchapter9 Microsoft.Network/publicIPAddresses
molVNET azuremolchapter9 Microsoft.Network/virtualNetworks
O que significa toda esta magia? Quando cria um conjunto de dimensionamento com
a CLI do Azure, são criados um balanceador de carga com redundância entre zonas e
um endereço IP público. As VMs são criadas e adicionadas a um conjunto IP de back-
-end no balanceador de carga. As regras NAT são criadas, o que permite que possa
ligar-se às instâncias de VM. A única coisa que falta são as regras do balanceador de
carga, pois variam de acordo com as aplicações que pretende executar. À medida que
adiciona ou remove VMs ao conjunto de dimensionamentos, a configuração do balan-
ceador de carga é atualizada automaticamente para permitir que o tráfego seja distri-
buído para as novas instâncias. Esta magia não está limitada à CLI do Azure—se utilizar
Azure PowerShell ou o portal Azure, estes recursos de rede de suporte serão criados e
ligados para trabalharem em conjunto.
Experimente agora
O seu dimensionamento foi criado com duas instâncias. Pode dimensionar manual-
mente o número de instâncias de VM no seu conjunto de dimensionamento. Quando o
fizer, o balanceador de carga atualiza automaticamente a configuração do conjunto IP
de back-end. Defina a --new-capacity do conjunto de dimensionamento como quatro
instâncias da seguinte maneira:
az vmss scale \
--name scalesetmol \
--new-capacity 4
9.2.2 Criar regras de dimensionamento automático

Quando criou o seu conjunto de dimensionamento, implementou um número fixo de
instâncias. Um dos recursos mais importantes dos conjuntos de dimensionamento é a
capacidade de aumentar ou reduzir horizontalmente de forma automática o número
de instâncias de VM que o conjunto de dimensionamento executa.
Como mostrado na figura 9.6, o número de instâncias num conjunto de dimensiona-
mento pode aumentar automaticamente à medida que a carga da aplicação aumenta.
Pense numa aplicação empresarial típica no seu ambiente. No início do dia de traba-
lho, os utilizadores começam a aceder à aplicação, o que faz com que a carga de recurso
nessas instâncias de VM aumente. Para garantir o melhor desempenho da aplicação, o
conjunto de dimensionamento adiciona automaticamente mais instâncias de VM. O
balanceador de carga começa a distribuir o tráfego para as novas instâncias automatica-
mente. Mais tarde, à medida que os utilizadores vão para casa, a procura de aplicações
diminui. As instâncias de VM utilizam menos recursos e, portanto, o conjunto de
dimensionamento remove automaticamente algumas instâncias de VM para reduzir os
recursos desnecessários e baixar o custo.
Conjunto de dimensionamento
Conjunto de dimensionamento de virtual machines Conjunto de dimensionamento
de virtual machines VM 1 VM 2 VM 3 de virtual machines
VM 1 VM 2 VM 3 A carga é A carga é VM 1 VM 2
aumentada reduzida
VM 4 VM 5
Reduz horizontal e automaticamente
Aumenta horizontal e automatica- para reduzir o número de instâncias
mente para aumentar o número de de VM
instâncias de VM
Figura 9.6 Os conjuntos de dimensionamento podem aumentar e reduzir horizontalmente de forma automática.
Define regras para monitorizar determinadas métricas que acionam as regras para aumentar ou diminuir o número
de instâncias de VM executadas. À medida que a sua procura de aplicações for alterada, o número de instâncias de
VM também será. Esta abordagem maximiza o desempenho e a disponibilidade da sua aplicação, minimizando o
custo desnecessário quando o carregamento da aplicação diminui.
Pode basear as suas regras do conjunto de dimensionamento em várias métricas. Pode

examinar nas métricas do host o consumo de recursos básicos, configurar a coleção de
métricas de VM do convidado para analisar os contadores de desempenho de aplica-
ções específicos ou utilizar o Azure Application Insights para monitorizar detalhada-
mente o código da aplicação.
Também pode utilizar agendas para definir um determinado número de instâncias
de VM num conjunto de dimensionamento para uma janela de tempo. No exemplo de
uma aplicação empresarial comum para a qual a procura é maior durante o horário de
trabalho do que à noite, pode querer definir um número fixo mais elevado de instân-
cias para executar durante o horário de trabalho e definir um número fixo inferior de
instâncias a executar à noite.
As regras de dimensionamento automático com base em métricas monitorizam
o desempenho num intervalo de tempo definido, como cinco minutos, e podem levar
mais alguns minutos para preparar as novas instâncias de VM e configurá-las para utili-
zação da aplicação. Se utilizar agendas fixas para dimensionar automaticamente o
número de instâncias de VM no seu conjunto de dimensionamento, esses recursos adi-
cionais já estão em utilização e o balanceador de carga distribui o tráfego para os mes-
mos durante o dia.
A utilização de agendas requer uma linha de base para a procura de aplicações típica
e não tem em conta uma procura maior ou menor em determinadas partes da conta de
negócio ou do ciclo de vendas. Por vezes, pode acabar com mais recursos do que pre-
cisa e, consequentemente, paga mais do que o necessário. E pode haver situações em
que a carga da aplicação seja superior ao número de instâncias de VM que o conjunto
de dimensionamento pode fornecer.
Experimente agora
Para criar regras de dimensionamento automático para um conjunto de dimensiona-
mento, conclua os passos que se seguem:

2 Ecolha o grupo de recursos que criou para a implementação do seu modelo, tal
como azuremolchapter9.
3 Selecione o seu conjunto de dimensionamento a partir da lista de recursos, como
scalesetmol.
4 Em Definições, no lado esquerdo da janela Conjunto de Dimensionamento,
escolha Dimensionamento. Pode dimensionar manualmente ou criar as suas
próprias regras de dimensionamento automático personalizadas.
5 Opte por criar regras de dimensionamento automático personalizadas.
6 Introduza um nome, tal como dimensionamento automático, e, em seguida,
defina uma contagem de instâncias mínima, máxima e predefinida. Para este
exercício, defina o mínimo como 2, o máximo como 10 e a predefinição como 2.
7 Escolha adicionar uma regra e, em seguida, examine as definições de regra dis-

poníveis, como mostrado na figura 9.7.
Os parâmetros predefinidos procuram o consumo médio da CPU. A regra é acio-
nada quando a carga é superior a 70% num intervalo de 10 minutos. O conjunto de
dimensionamento é aumentado em 1 instância de VM e as regras esperam 5 minu-
tos antes que a monitorização comece e a próxima regra possa ser acionada.
Figura 9.7 Quando adiciona uma regra de dimensionamento automático, define

o comportamento exato necessário para que a regra seja acionada.
Esse período de arrefecimento fornece às instâncias de VM tempo para imple-

mentar e começar a receber tráfego do balanceador de carga, o que deve dimi-
nuir a carga geral da aplicação no conjunto de dimensionamento. Sem este
período de arrefecimento, as regras podem acionar outra instância de VM que
será adicionada antes de a carga ter começado a ser distribuída pela instância de
VM criada anteriormente.
8 Para criar a regra, selecione Adicionar.
9 Escolha adicionar outra regra. Desta vez, conFigura a regra para diminuir a
contagem em 1 quando a carga média da CPU for inferior a 30% numa duração
de 5 minutos.
10 Examine as suas regras, tal como as mostradas na figura 9.8, e selecione
Guardar.
Figura 9.8 Agora deve ter uma regra que aumenta a contagem de instâncias em 1 quando a carga
média da CPU é superior a 70% e outra regra que diminui a contagem de instâncias em um quando a
carga média da CPU é inferior a 30%.
Também pode configurar regras de dimensionamento automático com o Azure CLI, o

Azure PowerShell ou com modelos. O portal fornece uma forma visual agradável para
analisar as regras e ver as opções disponíveis para cada parâmetro. À medida que cria
regras mais complexas, os modelos fornecem uma maneira de criar conjuntos de
dimensionamento com o mesmo conjunto de regras de forma reproduzível.
Dimensionar uma aplicação Web 137
9.3 Dimensionar uma aplicação Web

Se as aplicações Web do capítulo 3, ou as tabelas e filas do Azure no capítulo 4, desper-
taram o seu interesse, estes últimos três capítulos intensos em VMs IaaS podem ter
levantado algumas dúvidas. A cloud não deveria ser mais fácil do que isto? No caso dos
componentes PaaS, como as aplicações Web, absolutamente!
Não quero que pense que percorremos as páginas seguintes a toda velocidade, para
saber como fornecer os mesmos recursos de elevada disponibilidade e dimensiona-
mento automático às aplicações Web. A verdade é que é muito mais fácil de fazer! Tal
como com a maioria das coisas, a escolha entre IaaS e PaaS é um equilíbrio entre flexi-
bilidade e facilidade de gestão. Grande parte da redundância subjacente é abstraída em
serviços PaaS, tais como aplicações Web, e, portanto, não precisa de um capítulo inteiro
sobre elevada disponibilidade e outro capítulo sobre balanceadores de carga.
O caminho IaaS para criar e executar as suas próprias VMs ou conjuntos de dimen-
sionamento com balanceadores de carga e zonas de disponibilidade pode provir de
uma necessidade ou restrição empresarial. É possível que os programadores, os
engenheiros de operações ou as ferramentas e os workflows não estejam prontos para
adotarem imediatamente as aplicações Web. Dito isto, recomendo fortemente que con-
sidere as aplicações Web para as novas implementações de aplicações. A utilização de
componentes PaaS, tais como as aplicações Web, dá-lhe mais tempo para se concentrar
nas aplicações e nos seus clientes, em vez de na infraestrutura e na administração.
Experimente agora
Para criar uma aplicação Web com o Azure CLI, conclua os passos que se seguem:
1 No capítulo 3, criou uma aplicação Web no portal Azure. Como na maioria dos
recursos, muitas vezes é mais rápido e fácil utilizar o Azure CLI. Abra o Cloud
Shell no portal Azure.
2 Crie um plano do serviço de aplicações com um tamanho padrão S1. Este tama-
nho permite-lhe efetuar o dimensionamento automático de até 10 instâncias da
sua aplicação Web:
az appservice plan create \
--name appservicemol \
--sku s1
3 Crie uma aplicação Web que utilize um repositório Git local para implementa-
ção, como fez no capítulo 3:
az webapp create \
--name webappmol \
--plan appservicemol \
--deployment-local-git
Todos os conceitos e cenários discutidos na secção 9.2.2 em torno de regras de dimen-

sionamento automático e agendas para conjuntos de dimensionamento aplicam-se às
aplicações Web. Como um resumo rápido, aqui estão alguns cenários comuns para o
dimensionamento automático de aplicações Web:
¡ Aumente ou diminua automaticamente o número de instâncias de aplicações

Web com base nas métricas de desempenho, para oferecer suporte à procura de
aplicações durante todo o dia de trabalho.
¡ Agende uma aplicação Web para aumentar automaticamente o número de ins-
tâncias no início do dia de trabalho e, em seguida, diminuir o número de instân-
cias no final do dia de trabalho.
No caso da pizzaria, a aplicação Web pode receber mais tráfego mais tarde no dia e
durante a noite, por isso não há um conjunto de regras de dimensionamento automá-
tico que se aplique a todas as situações. Mais uma vez, é necessário estabelecer uma
linha de base do desempenho da aplicação para compreender como a mesma é execu-
tada em condições de utilização normais e a métrica de desempenho na qual a aplica-
ção precisa de aumentar ou reduzir o dimensionamento horizontalmente. Mesmo
quando utiliza agendas de dimensionamento automático, é necessário continuar a
monitorizar e a controlar quando ocorre o pico de procura das suas aplicações, para
criar regras que suportem esse padrão de utilização.
Experimente agora
Para criar regras de dimensionamento automático para uma aplicação Web, conclua
os passos seguintes:

2 Escolha o grupo de recursos que criou para a sua aplicação Web, tal como
azuremolchapter9.
3 Selecione a sua aplicação Web a partir da lista de recursos, como webappmol.
4 Em Definições no lado esquerdo da janela da aplicação Web, escolha Aumentar
Horizontalmente (Plano do App Service).
5 Mais uma vez, opte por configurar regras de dimensionamento automático per-
sonalizadas e não apenas escalar manualmente a aplicação Web.
6 Introduza um nome, tal como autoscalewebapp, e, em seguida, defina uma con-
tagem de instâncias mínima, máxima e predefinida. Para este exercício, defina o
mínimo como 2, o máximo como 5 e a predefinição como 2.
7 Escolha adicionar uma regra e, em seguida, reveja as definições de regra disponí-
veis. Esta janela tem o mesmo aspeto que as regras de dimensionamento automá-
tico para os conjuntos de dimensionamento. Os parâmetros predefinidos
observam o consumo médio do CPU e são acionados quando a carga é superior a
70% num intervalo de 10 minutos. A aplicação Web é aumentada em uma instân-
cia e as regras esperam 5 minutos antes que a monitorização comece e a pró-
xima regra possa ser acionada.
8 Escolha adicionar outra regra. Desta vez, conFigura a regra para diminuir a con-
tagem em um quando a carga média do CPU for inferior a 30% numa duração
de 5 minutos.
9 Reveja e guarde as suas regras.
Laboratório: instalar aplicações no seu conjunto de dimensionamento ou aplicação Web 139
Quando as regras de dimensionamento automático acionam a aplicação Web para

reduzir ou aumentar horizontalmente, a plataforma do Azure atualiza a distribuição
de tráfego para as instâncias de aplicações Web disponíveis. Não existe um balancea-
dor de carga exposto para si, tal como tem com conjuntos de escala, mas o tráfego
ainda é automaticamente distribuído em todas as instâncias de aplicações Web à
medida que o seu ambiente aumenta ou diminui horizontalmente. O conceito de é
semelhante, apenas lhe é ocultado porque é suposto que desfrute da abordagem PaaS e
que não se preocupe tanto!
Os conjuntos de dimensionamento e as aplicações Web fornecem uma maneira de
criar regras que dimensionam automaticamente o número de instâncias que executam as
suas aplicações. Com várias instâncias para executar a sua aplicação, também aumenta a
disponibilidade da sua aplicação. Os conjuntos de dimensionamento são um bom meio-
-termo entre programadores e decisores empresariais que pretendem ou precisam
de criar aplicações em VM, ao mesmo tempo que utilizam funcionalidades de tipo PaaS
para dimensionar automaticamente e reconfigurar o fluxo do tráfego do cliente.
No capítulo 11, vamos analisar o Azure Traffic Manager, que completa realmente
estas implementações de elevada disponibilidade. Neste momento, ainda não tem tudo
o que precisa para a produção, em termos de ser capaz de oferecer vários conjuntos de
dimensionamento redundantes ou instâncias de aplicações Web com tráfego distri-
buído automaticamente entre eles. Mas veremos isso em breve!
9.4 Laboratório: instalar aplicações no seu conjunto

de dimensionamento ou aplicação Web
Abordámos muitas áreas neste capítulo, por isso agora pode escolher um laboratório
final rápido para os conjuntos de dimensionamento ou as aplicações Web. Ou, se qui-
ser prolongar a sua pausa para o almoço, faça os dois!
9.4.1 Conjuntos de dimensionamento de virtual machines

Tem várias instâncias de VM nos seus conjuntos de dimensionamento, mas não fazem
muito neste momento. Para obter uma descrição geral das diferentes maneiras de ins-
talar aplicações em instâncias de VM num conjunto de dimensionamento, consulte
http://mng.bz/9Ocx. Na prática, iria utilizar um desses métodos de implementação
automatizados, mas, por enquanto, instale manualmente um servidor Web nas instân-
cias de VM como fez no capítulo 8:
1 Lembra-se das regras NAT do balanceador de carga? Por predefinição, cada ins-
tância de VM num conjunto de dimensionamento tem uma regra NAT que lhe
permite comunicar com ela diretamente através de SSH. As portas não estão na
porta TCP padrão 22. Veja a lista de instâncias de VM num conjunto de dimen-
sionamento e os respetivos números de porta da seguinte maneira:
az vmss list-instance-connection-info \
--name scalesetmol
2 Para se ligar a uma porta específica via SSH, utilize o parâmetro -p da seguinte
maneira (forneça o seu próprio endereço IP público e números de porta):
ssh azuremol@40.114.3.147 -p 50003
3 Instale um servidor Web Nginx básico em cada instância de VM com apt ins-
tall. Pense em como fez no capítulo 8.
4 Para ver o conjunto de dimensionamento em ação, abra o endereço IP público
do balanceador de carga do conjunto de dimensionamento num browser.
5 Se tiver problemas, certifique-se de que o equilibrador de carga criou correcta-
mente uma regra de equilibrador de carga para a porta TCP 80 e tem uma sonda
de saúde associada para o either TCP port 80 ou a sua própria sonda de saúde
HTTP personalizada que procura/saúde.html na VM.
9.4.2 Aplicações Web

Para implementar a aplicação numa aplicação Web que executa várias instâncias, o
processo é o mesmo da aplicação Web individual no capítulo 3. Envia a aplicação para
o repositório Git local correspondente à aplicação Web e, graças ao poder do PaaS, a
plataforma do Azure implementa essa base de código individual em várias instâncias
de aplicações Web:
1 Inicialize um repositório Git em azure-mol-samples-2nd-ed/09 e, em seguida,

adicione e confirme os ficheiros de exemplo, como fez no capítulo 3:
cd azure-mol-samples-2nd-ed/09
git init && git add . && git commit -m “Pizza”
2 A sua aplicação Web tem um repositório Git local. Adicione um remoto para a
sua aplicação Web, tal como fez no capítulo 3:
git remote add webappmolscale <your-git-clone-url>
3 Envie este exemplo para a sua aplicação Web. Isto permite confirmar um código
individual, mas, em seguida, a sua aplicação é distribuída por várias instâncias de
aplicações Web:
git push webappmolscale master
10
Bases de dados globais com
Cosmos DB
Dados. É impossível trabalhar sem este serviço. Quase todas as aplicações que com-
pila e executa criam, processam ou obtêm dados. Tradicionalmente, estes dados
foram armazenados numa base de dados estruturada, como MySQL, Microsoft SQL
ou PostgreSQL. Estas bases de dados grandes e estruturadas estão consolidadas e
são muito conhecidas, dispõem de ampla documentação e tutoriais, e podem ser
acedidas a partir da maioria das principais linguagens de programação.
Uma grande potência implica uma grande responsabilidade e, em geral, essas
bases de dados estruturadas tradicionais acarretam muitos custos indiretos e gestão
da infraestrutura. Isso não significa que não deva utilizá-las, longe disso. Mas quando
se trata de aplicações executadas à escala global, criar clusters de servidores de bases
de dados que replicam os seus dados e redirecionam inteligentemente os clientes
para a instância mais próxima não é uma tarefa fácil.
É aí que o Azure Cosmos DB se converte no seu melhor amigo. Não precisa de se
preocupar sobre como replicar os seus dados, garantir a consistência e distribuir os
pedidos dos clientes. Em vez disso, adiciona os dados num dos muitos modelos dis-
poníveis e, em seguida, escolhe onde pretende que os seus dados fiquem disponíveis.
Neste capítulo, irá obter mais informações sobre os modelos de bases de dados não
estruturados no Cosmos DB, irá aprender a criar e configurar a sua base de dados
para distribuição global, bem como a criar aplicações Web que utilizem a sua instân-
cia do Cosmos DB com elevada redundância e capacidade de dimensionamento.
10.1 O que é o Cosmos DB?

O capítulo 4 começou por explorar bases de dados não estruturadas com tabelas de
armazenamento do Azure. O exemplo foi básico, mas os conceitos são os pilares do
Cosmos DB. Primeiro, vamos dar um passo atrás e examinar o que pretendemos
dizer com bases de dados estruturadas e não estruturadas.
141
142 Capítulo 10 Bases de dados globais com Cosmos DB
10.1.1 Bases de dados estruturadas (SQL)

As bases de dados estruturadas são a abordagem mais tradicional de armazenamento de
dados. Uma estrutura ou esquema de base de dados define como os dados são representa-
dos. Os dados são armazenados em tabelas, em que cada uma das suas linhas representa
um item e recebe um conjunto fixo de valores. Se utilizarmos uma pizzaria como mod-
elo, cada linha de uma tabela que armazena os tipos de pizza pode indicar o nome da
pizza, o seu tamanho e o custo. Uma base de dados SQL básica é mostrada na figura 10.1.
Base de dados estruturada
Tabela
id pizzaName tamanho custo FigurAa 10.1 Numa base
de dados estruturada, os
1 Pepperoni 16” 18 USD
dados são armazenados
2 Vegetariana 16” 15 USD em linhas e colunas dentro
de uma tabela. Cada linha
3 Havaiana 16” 12 USD
contém um conjunto fixo de
colunas que representam o
esquema da base de dados.
Nas bases de dados estruturadas, cada servidor deve conter toda a base de dados para
que as consultas e a obtenção de dados sejam bem-sucedidas. Os dados são unidos em
consultas extraídas de diferentes tabelas com base nos critérios que o programador cria
como parte da consulta estruturada. Daí provém o termo linguagem SQL (Structured
Query Language). À medida que as bases de dados crescem em tamanho e complexi-
dade, os servidores que executam a base de dados devem ser suficientemente dimensio-
nados para processar esses dados em memória. Com os conjuntos de dados muito
grandes, essa tarefa torna-se difícil e dispendiosa. Dado que precisam de uma estrutura,
também se torna difícil adicionar propriedades e alterar a estrutura mais tarde.
10.1.2 Bases de dados não estruturadas (NoSQL)

Os dados não estruturados em bases de dados NoSQL não
Base de dados não estruturada são armazenados em tabelas de linhas e colunas; em vez
disso, são armazenados em matrizes dinâmicas que lhe per-
{
mitem adicionar novas propriedades para um item, con-
"custo": "18", forme necessário. Uma grande vantagem desta abordagem
"descrição": "Pepperoni" é que pode adicionar rapidamente um novo tipo de pizza
} ou um ingrediente especial sem alterar a estrutura da base
{
"custo": "15",
de dados subjacente. Numa base de dados estruturada, iria
"descrição": "Vegetariana", precisar de adicionar uma nova coluna a uma tabela e, em
"glúten": "sem" seguida, atualizar a aplicação para processar a coluna adi-
} cional. Nas bases de dados NoSQL, adiciona outra proprie-
{
"custo": "12",
dade a uma determinada entrada a partir do seu código;
"descrição": "Havaiana", consulte a figura 10.2.
"ingredientes": "fiambre,
ananás" Figura 10.2 Numa base de dados não estruturada, os dados são
} armazenados sem mapeamentos fixos de colunas para uma linha numa
tabela. Pode adicionar ingredientes a uma única pizza, por exemplo,
sem atualizar todo o esquema e outros registos.
O que é o Cosmos DB? 143
As bases de dados NoSQL também oferecem modelos de bases de dados diferentes.

Estes modelos dão uma indicação de como os dados são armazenados e obtidos na
base de dados. O modelo que utiliza varia de acordo com o tamanho e o formato dos
dados com os quais trabalha e de como precisa de representar os dados na sua apli-
cação. Estes modelos incluem o documento, o gráfico e a tabela. Por enquanto, não é
necessário aprofundar demasiado os modelos; cada modelo diferente funciona mel-
hor para cada conjunto de dados não estruturados diferente, dependendo de como
precisa de relacionar e consultar os dados. O dado mais importante a ser lembrado é
que as bases de dados NoSQL não estruturadas armazenam e obtêm informações com
base num conceito subjacente diferente do qual pode tirar partido ao criar e executar
aplicações na cloud no Azure.
10.1.3 Dimensionar bases de dados

Lembra-se que disse que, para uma base de dados estruturada, normalmente é
necessário que toda a base de dados exista em cada servidor? Ao trabalhar com bases
de dados muito grandes, são necessários servidores ainda maiores para executá-las.
Talvez nunca trabalhe com bases de dados que atingem centenas de gigabytes ou
mesmo terabytes, mas as bases de dados NoSQL abordam o crescimento e o
dimensionamento das bases de dados de maneira diferente das bases de dados SQL. A
diferença é que, normalmente, as bases de dados NoSQL são dimensionadas horizon-
talmente, em vez de verticalmente.
O dimensionamento vertical de uma VM, ou seja, a adição de mais memória e CPU,
tem um limite. À medida que tentamos tirar o máximo partido do débito do armazena-
mento e da largura de banda da rede, começam a surgir problemas de desempenho em
outros setores da pilha de computação. Para não mencionar o impacto económico
(para si ou o seu chefe) ao receber a fatura de VM de grandes dimensões. Como resumo
do capítulo 9, o dimensionamento vertical é ilustrado na figura 10.3. Agora pense num
cluster composto por essas VM de bases de dados muito grandes. Porque o que procura
para a sua aplicação é redundância e resiliência, não é?
Pelo contrário, o dimensionamento horizontal permite executar VM de bases de
dados com menos recursos e a um preço mais baixo em consonância com as mesmas.
Para isso, as bases de dados NoSQL dividem os dados entre os nós da base de dados e
encaminham os pedidos da sua aplicação para o nó correspondente. Os outros nós no
cluster não precisam de saber de onde todos os dados são armazenados;
vCPU vCPU Aumentar o processamento (vCPUs) vCPU vCPU vCPU vCPU
vCPU vCPU vCPU vCPU vCPU vCPU
vRAM vRAM Aumentar a memória (vRAM) vRAM vRAM vRAM vRAM
vRAM vRAM vRAM
Figura 10.3 As bases de dados estruturadas tradicionalmente são dimensionadas verticalmente.

À medida que a base de dados cresce, aumenta a quantidade de armazenamento, memória e potência
da CPU no servidor.
Só precisam responder aos seus próprios pedidos. Pode adicionar nós a um cluster
rapidamente em resposta à procura do cliente, quando necessário.
Isso significa que, numa base de dados NoSQL, não é necessário que toda a base de
dados caiba na memória de um host. Apenas parte da base de dados, um fragmento, pre-
cisa de ser armazenada e processada. Se a sua aplicação trabalha com grandes quanti-
dades de dados estruturados, uma base de dados NoSQL pode prejudicar o desempenho,
porque são consultados vários hosts para obter informações que serão devolvidas ao
cliente. Se tiver uma grande quantidade de dados não estruturados para processar, as
bases de dados NoSQL podem aumentar o desempenho e até mesmo a gestão e a efi-
ciência. Na figura 10.4. é mostrado um exemplo de dimensionamento horizontal de
bases de dados não estruturadas entre hosts.
Base de dados dividida

vCPU vCPU entre hosts para aumentar vCPU vCPU vCPU vCPU
horizontalmente
vCPU vCPU e equilibrar as necessi- vCPU vCPU vCPU vCPU
dades de processamento
vRAM vRAM vRAM

Fragmentação de Fragmentação de
base de dados base de dados
Figura 10.4 As bases de dados NoSQL não estruturadas são dimensionadas horizontalmente. À medida
que uma base de dados cresce, é fragmentada em segmentos de dados que são distribuídos entre os
servidores de base de dados.
10.1.4 Como reunir tudo com o Cosmos DB

Então, o que é o Cosmos DB? É uma plataforma de base de dados de dimensiona-
mento automático, globalmente distribuída, que lhe permite utilizar várias formas de
bases de dados NoSQL. Assim como ocorre com serviços como o Web Apps, o Cosmos
DB poupa uma grande parte da camada de gestão. Quando cria uma aplicação Web,
não precisa de configurar o balanceamento de carga ou o clustering; escolhe as suas
regiões e pode configurar o dimensionamento automático e, em seguida, carregar o
código da aplicação. A plataforma do Azure processa como replicar e distribuir o
tráfego de aplicações Web com elevada disponibilidade. Com o Cosmos DB, não tem
de se preocupar com o tamanho da base de dados de que precisa, a quantidade de
memória a atribuir ou a forma de replicar dados para a redundância. Apenas precisa
de escolher o débito necessário e as regiões para armazenar os seus dados, e já pode
começar a adicionar dados.
Este capítulo utiliza um modelo SQL para o Cosmos DB, mas os dados são armazena-
dos num formato NoSQL JSON. Estes podem ser conceitos novos, mas acompanhe-me.
Pode utilizar outros modelos, incluindo Mongo, Cassandra, Gremlin e Table. A funcio-
nalidade é a mesma para todos: escolha o seu modelo, escolha as suas regiões e adicione
os seus dados. Esse é o poder do Cosmos DB.
Criar uma conta e uma base de dados Cosmos DB 145
10.2 Criar uma conta e uma base de dados Cosmos DB

Vamos ver o Cosmos DB e as bases de dados não estruturadas em ação, o que podemos
fazer de várias maneiras. A primeira é utilizar o portal Azure para criar uma conta, sele-
cionar e criar um modelo de base de dados e introduzir dados na base de dados para
que a sua aplicação possa consultá-la. Ou pode utilizar kits de desenvolvimento de soft-
ware (SDK) do Azure CLI, do Azure PowerShell ou específicos de uma linguagem para
criar tudo em código. Vamos utilizar o portal Azure para que também possamos criar e
consultar visualmente os dados.
10.2.1 Criar e preencher uma base de dados Cosmos DB

No capítulo 4, criou a sua primeira base de dados NoSQL com uma tabela de arma-
zenamento do Azure. Vamos utilizar o Cosmos DB para criar uma base de dados semel-
hante, desta vez uma que ofereça todas as opções de georredundância e replicação
para assegurar que a sua loja online permite que os clientes façam pedidos de pizzas
sem qualquer tempo de inatividade. Vamos criar uma conta Cosmos DB e uma base de
dados de documentos e, em seguida, adicionar algumas entradas de dados para três
tipos de pizza, como mostrado na figura 10.5.
Pizza de Pizza Pizza

pepperoni vegetariana havaiana Figura 10.5 Nesta
secção, irá criar um grupo
de recursos e uma conta
Base de dados de documentos do Cosmos DB Cosmos DB. É criada uma
base de dados de
documentos nesta conta
Conta do Cosmos DB e deverá adicionar três
entradas que representem
um menu básico para a
Grupo de recursos do Azure sua pizzaria.
Experimente agora
Para ver o Cosmos DB em ação, crie uma conta utilizando o portal Azure:
1 Abra o portal Azure e selecione Criar um Recurso no canto superior esquerdo

do dashboard.
2 Procure e selecione Azure Cosmos DB e, em seguida, escolha Criar.
3 Opte por criar um grupo de recursos, tal como o azuremolchapter10, e insira
um nome único para a sua conta Cosmos DB, tal como azuremol.
4 O tipo de modelo que pode utilizar para a sua base de dados é referido como
API. Para este exemplo, escolha Core SQL no menu pendente.
5 Para a localização, selecione E.U.A. Leste. O Cosmos DB está disponível em todas

as regiões do Azure. No entanto, para este exemplo, é necessário escolher a
região E.U.A. Leste para a aplicação Web que irá implementar no laboratório de
fim de capítulo.
6 Deixe a opção de georredundância desativada, juntamente com quaisquer out-
ras funcionalidades adicionais, tais como regiões multiwrite. A secção 10.2.2
explica em maior detalhe como replicar a sua base de dados globalmente.
Tráfego seguro com endpoints de serviço

Tem a opção de ligar o seu Cosmos DB a uma rede virtual Azure com algo chamado
endpoint de serviço. Não vamos discutir esta opção agora, mas é uma excelente
funcionalidade que o ajuda a proteger a sua instância permitindo o acesso à base de
dados apenas a partir de uma rede virtual definida.
Se desenvolver aplicações de middleware que utilizam Cosmos DB, ou apli-
cações apenas internas, pode utilizar um endpoint de serviço de rede virtual para
estender o acesso a partir de uma rede virtual específica, não através da Internet e com
um endpoint público. Um número crescente de serviços do Azure suportam este tipo de
endpoints, e este é mais um exemplo das opções que lhe são dadas para garantir que o
seu ambiente se adequa às suas necessidades de negócio.
7 Quando tiver tudo pronto, reveja e crie a sua conta Cosmos DB. A criação da
conta demora alguns minutos.
Atualmente, a sua base de dados está vazia, por isso vamos explorar como pode arma-
zenar alguns dados básicos para o menu da sua pizzaria. O Cosmos DB agrupa os dados
numa base de dados em algo chamado um container. Não, não é o mesmo tipo de con-
tainer que é a força motriz por trás do Docker, Kubernetes e aplicações nativas de
cloud de que pode ter ouvido falar. Esta confusão com os nomes não é uma vantagem,
mas acompanhe-me por agora.
Nas bases de dados Cosmos DB que utili-
zam o modelo de documento, os dados são
agrupados de forma lógica em containers
chamados de coleções. Outros modelos da API
Pizza de Pizza Pizza
têm um nome ligeiramente diferente para a
pepperoni vegetariana havaiana
entidade de container, tal como
gráfico para a Gremlin API. Para a nossa SQL
Coleção API, as coleções armazenam partes relacio-
nadas de dados que podem ser rapidamente
Base de dados de documentos do Cosmos DB indexadas e consultadas, como mostrado na
figura 10.6. As coleções não diferem total-
Figura 10.6 Uma base de dados Cosmos DB que utiliza o mente da sua maneira de organizar uma
modelo de documento armazena os dados em coleções.
Estas coleções permitem-lhe agrupar dados para base de dados SQL tradicional em tabe-
indexação e consultas mais rápidas. las, mas as coleções oferecem uma flexibili-
dade muito maior no momento de distribuir
os dados para desempenho ou redundância.
Como o Cosmos DB foi concebido para lidar com grandes quantidades de dados e
débito, pode escolher como dimensionar e controlar o fluxo e o custo desses dados. O
débito é calculado em unidades de pedido por segundo (RU/s) e uma unidade de
pedido equivale a 1 KB de dados de documento. Em suma, define quanta largura de
banda pretende para a sua base de dados. Caso ainda não tenha adivinhado, quanto
mais largura de banda (RU/s) quiser, mais pagará. O Cosmos DB mostra quantos
dados está a utilizar e quanto débito a sua aplicação utiliza. Normalmente, não precisa
de se preocupar muito em conseguir o dimensionamento correto. Mas, para a sua piz-
zaria, vamos começar pouco a pouco!
Experimente agora
Para criar uma coleção e preencher algumas entradas na base de dados, conclua

2 Escolha o grupo de recursos no qual criou a base de dados Cosmos DB, tal como
o azuremolchapter10.
3 Selecione a sua conta Cosmos DB na lista de recursos e, em seguida, selecione
a página Descrição Geral.
4 Escolha adicionar um container.
5 Esta é a sua primeira base de dados, por isso escolha Criar Novo e introduza um
nome, como pizzadb.
6 Deixe o débito definido como o valor predefinido.
7 Para o ID do container, introduza pizzas. Este passo cria um container lógico
que pode utilizar para armazenar os itens no menu da sua pizzaria.
8 Introduza uma chave de partição/descrição para se certificar de que os tipos de
pizza são distribuídos uniformemente.
A chave de partição identifica a forma como os dados podem ser divididos na
base de dados. Não é realmente necessário numa pequena base de dados de
amostra como esta, mas é prático utiliza-la à medida que a sua aplicação escala.
9 Não escolha adicionar uma chave exclusiva. As chaves definem o container adi-
cionalmente, de forma lógica, como, por exemplo, subsecções de alimentos que
os clientes podem pedir. A coleção mais ampla será a do menu, mas pode pre-
tender chaves de partição para pizzas, bebidas e sobremesas.
10 Para criar a base de dados e a coleção, selecione OK.
Agora tem uma conta Cosmos DB, uma base de dados e uma coleção, mas ainda não
contém pizzas. Pode importar alguns dados ou escrever o código que introduz uma
série de dados. Vamos criar manualmente três pizzas para explorar algumas das ferra-
mentas gráficas incorporadas no portal Azure para navegar, consultar e manipular os
dados na sua base de dados Cosmos DB.
Experimente agora
Para adicionar algumas entradas à base de dados, execute os seguintes passos, como
mostra a figura 10.7:
1 Na sua conta Cosmos DB, escolha Explorador de Dados no menu à esquerda na

janela Descrição Geral.
Figura 10.7 Com o Explorador de Dados no portal Azure, pode navegar nas coleções para
consultar ou criar novos documentos. Esta ferramenta gráfica permite-lhe gerir rapidamente a sua
base de dados a partir de um browser.
2 Expanda a base de dados pizzadb e, em seguida, a coleção pizzas.

3 Adicione um novo item para colocar algumas pizzas na base de dados. Os dados
são adicionados no formato JSON.
4 Na caixa de texto, substitua qualquer texto existente com os seguintes dados
para criar um novo item de menu para uma pizza de pepperoni básica:
{
"description": "Pepperoni",
"cost": "18"
}
5 Para adicionar os dados à base de dados, selecione Guardar.

6 Adicione outra pizza ao seu menu. Desta vez, adicione uma propriedade para indi-
car que esta pizza não tem glúten. Não precisa de fazer nada de especial na base de
dados subjacente; basta adicionar outra propriedade aos seus dados. Para adicio-
nar outro novo item, introduza os seguintes dados e selecione Guardar:
{
"description": "Veggie",
"cost": "15",
"gluten": "free"
}
7 Adicione um último tipo de pizza. Desta vez, adicione uma propriedade que
inclua oss ingredientes da pizza. Para adicionar outro item novo, introduza os
dados seguintes e selecione Guardar:
{
"description": "Hawaiian",
"cost": "12",
"toppings": "ham, pineapple"
}
Estas três entradas mostram o poder de uma base de dados NoSQL. Adicionou pro-
priedades às entradas sem necessidade de atualizar o esquema da base de dados. Duas
propriedades diferentes mostraram que a massa da pizza vegetariana é sem glúten da
pizza e os ingredientes da pizza havaiana. O Cosmos DB aceita essas propriedades adi-
cionais e esses dados ficam agora disponíveis nas suas aplicações.
Algumas propriedades JSON extra são adicionadas para coisas como id, _rid e _
self. Estas não são propriedades com as qual precise de se preocupar muito por
enquanto. O Cosmos DB utiliza estas propriedades para monitorizar e identificar os
dados; não deve editá-los manualmente ou eliminá-los.
10.2.2 Adicionar redundância global a uma base de dados Cosmos DB

Tem uma base de dados Cosmos DB que armazena um menu de pizza básico na região
E.U.A. Leste. Mas a sua pizzaria está pronta para abrir franchises em todo o mundo!
Pretende replicar os dados sobre as suas pizzas para as regiões do Azure em local-
izações diferentes, perto dos seus novos clientes.
Por que iria pretender fazer isso? Se todos os seus clientes lerem e escreverem dados
a partir da base de dados numa região, isso significa um grande volume de tráfego
potencial que é transmitido por cabos submarinos e circula à volta ao mundo. Para for-
necer a melhor experiência de baixa latência aos clientes, pode replicar os seus dados
para as regiões do Azure de todo o mundo e os clientes poderão ligar-se à réplica mais
próxima, conforme mostrado na figura 10.8.
A plataforma Cosmos DB possui modelos de consistência e garantias incorporados
que lhe permitem gerir a consistência e a replicação de dados. Designa uma ou mais
regiões como a localização de escrita principal. Os exemplos deste livro utilizam um
único ponto de escrita, mas pode utilizar o suporte de vários mestres para escrever
dados no endpoint mais próximo, os quais são, então, propagados
Cosmos DB (Norte Los Angeles,

da Europa) E.U.A.
Cosmos DB Melbourne,
(E.U.A. Oeste) Austrália
Cosmos DB
(E.U.A. Leste)
Cosmos DB
Paris, França
Região de (Ásia Oriental)
escrita principal
Dados
Cosmos DB (Sudeste Kuala Lumpur,
replicados para
da Austrália) Malásia
várias regiões
Os clientes consultam
Garantias de consistên- e leem o Cosmos DB
cia para dados do a partir da região
Cosmos DB mais próxima
Figura 10.8 Os dados são replicados de uma instância do Cosmos DB principal para várias regiões do
Azure em todo o mundo. Em seguida, as aplicações Web podem ser direcionadas para serem lidas a partir
da região mais próxima e os clientes podem ser encaminhados dinamicamente para a localização mais
próxima para minimizar a latência e melhorar os tempos de resposta.
de forma assíncrona para outras regiões. Os dados também são replicados rapida-
mente para as regiões de leitura que designar. Pode controlar a ordem de ativação pós-
falha, para designar regiões de leitura e, com a sua aplicação, especificar automática
ou manualmente as regiões a partir das quais os dados serão lidos.
Pode definir um modelo de consistência (que é mais uma questão de
design do que operacional) para definir a rapidez com que as escritas em várias regiões
são replicadas. Os modelos de consistência vão de forte, o qual que espera que as
escritas sejam confirmadas por réplicas e, assim, as leituras das garantias são consis-
tentes, a eventual, o que é mais descontraído. O modelo eventual garante que todos os
dados são replicados, mas pode haver um ligeiro atraso quando as leituras das réplicas
devolvem valores diferentes até estarem todos sincronizados.
Há um equilíbrio entre uma distribuição geográfica mais limitada, como com o
modelo de consistência forte, e uma replicação geográfica mais ampla com o modelo
de consistência eventual, mas sabendo que há um ligeiro atraso à medida que os
dados são replicados. Também devemos levar em consideração os custos de largura de
banda e processamento, dependendo do grau de consistência e pontualidade com que
pretende replicar os dados. A plataforma do Azure lida com a replicação subjacente de
dados a partir do seu ponto de escrita; não precisa de criar aplicações para replicar os
dados ou determinar a melhor forma de ler dados a partir de endpoints replicados.
Numa uma escala global, pode ter tantas VM ou aplicações Web quantas
criou nos capítulos anteriores, mas em diferentes regiões do mundo. Essas aplicações
ligam-se a uma instância local do Cosmos DB para consultar e ler todos os seus dados.
Através de algumas funcionalidades de tráfego de rede do Azure interessantes que ire-
mos analisar no capítulo 11, os utilizadores podem ser encaminhados automaticamente
para uma destas instâncias de aplicações Web locais, que também utilizam uma instân-
cia local do Cosmos DB. Em caso de interrupções ou manutenção regionais, toda a
plataforma encaminha o cliente para a instância mais próxima.
No mundo das bases de dados estruturadas tradicionais, nas quais gere as VMs, a
instalação de bases de dados e a configuração de clusters, essa configuração requer um
planeamento de design cuidadoso e a sua implementação é complicada. Com o Cos-
mos DB, o processo é feito com três cliques. Honestamente!
Experimente agora
Para replicar os dados do Cosmos DB globalmente, conclua os passos seguintes:
1 Navegue para o Grupo de Recursos e selecione-o na barra de navegação à

esquerda no portal Azure.
azuremolchapter10.
3 Selecione a sua conta Cosmos DB a partir da lista de recursos. Esses dois cliques
foram gratuitos, mas comece a contar a partir daqui!
4 Selecione a opção do menu à esquerda para replicar dados globalmente. O
mapa, que mostra todas as regiões do Azure disponíveis, mostra que a sua base
de dados está disponível atualmente na região E.U.A. Leste (figura 10.9).
Figura 10.9 Selecione uma região do Azure para replicar a base de dados Cosmos DB e, em seguida,
escolha Guardar. Esses são todos passos necessários para distribuir os seus dados globalmente.
5 Escolha Europa Ocidental e, em seguida, selecione Guardar. Pode escolher

qualquer região do Azure que pretender, mas o laboratório de fim de capítulo
espera que os dados sejam replicados para a Europa Ocidental. Demora apenas
um instante a replicar os dados na região selecionada e a enviá-los para a Web
para que as suas aplicações os utilizem.
Certo, conte os cliques! Três cliques, certo? Vamos ser generosos e contabilizar a
seleção do grupo de recursos e da conta Cosmos DB como os dois primeiros cliques.
Assim, com não mais de cinco cliques e em questão de segundos, irá criar uma instân-
cia de réplica da base de dados que irá permitir que as suas aplicações acedam aos
dados a partir da região mais próxima das mesmas. Pode fazer isso com um cluster
MySQL tradicional? Envie-me um tweet para @fouldsy se puder fazer isso rapidamente
fora do Cosmos DB!
Com a sua base de dados agora distribuída globalmente, precisa de fazer muitas
alterações no código para determinar a qual região do Cosmos DB irá ligar-se? Como
pode manter todas estas versões diferentes das suas aplicações, dependendo da região
do Azure que executam? É fácil. Deixe que a plataforma do Azure o faça por si!
10.3 Aceder aos dados distribuídos globalmente

Na maioria das vezes, a plataforma do Azure determina a melhor localização para con-
versar com a sua aplicação. Normalmente, uma aplicação precisa de ler e escrever
dados. Pode definir as políticas de ativação pós-falha para a sua base de dados Cosmos
DB, que controla a localização de escrita principal. Esta localização de escrita atua
como o hub central para garantir que os dados são replicados consistentemente entre
regiões. Porém, normalmente, a sua aplicação Web pode ler a partir de várias regiões
disponíveis para acelerar as consultas e devolver dados ao cliente. As chamadas REST
tratam de tudo isto.
Vamos ver o que acontece na CLI do Azure quando pede informações sobre uma
base de dados Cosmos DB. Este processo é semelhante a uma aplicação que estabelece
uma ligação a uma base de dados, mas impede-o de aprofundar demasiado no código.
Experimente agora
Utilize az cosmosdb show para encontrar informações sobre a sua localização
de leitura e escrita:

2 Utilize az cosmosdb show para ver as localizações de leitura e escrita da sua base
de dados Cosmos DB database.
Introduza o nome do grupo de recursos e o nome da base de dados que criou
nos exercícios anteriores "Experimente agora". No exemplo a seguir, o grupo de
recursos é azuremolchapter10 e o nome da base de dados Cosmos DB é
azuremol:
az cosmosdb show \
--name azuremol
Aceder aos dados distribuídos globalmente 153
Este comando devolve um resultado extenso, por isso vamos examinar as duas partes
principais: as localizações de leitura e as localizações de escrita. Eis um exemplo do
resultado para a secção readLocations:
"readLocations": [
{
"documentEndpoint":"https://azuremol-eastus.documents.azure.com:443/",
"failoverPriority": 0,
"id": "azuremol-eastus",
"isZoneRedundant": "false",
"locationName": "East US",
"provisioningState": "Succeeded"
},
{
"documentEndpoint":
➥"https://azuremol-westeurope.documents.azure.com:443/",
"failoverPriority": 1,
"id": "azuremol-westeurope",
"isZoneRedundant": "false",
"locationName": "West Europe",
"provisioningState": "Succeeded"
}
],
Quando a sua aplicação estabelece uma ligação a uma base de dados Cosmos DB, pode
especificar uma política de ligação. Se, em geral, as bases de dados não forem o seu
forte, pense numa ligação ODBC (Open Database Connectivity) básica que possa criar
numa máquina Windows. Normalmente, a cadeia de ligação define um nome de host,
o nome de uma base de dados, uma porta e as credenciais. O Cosmos DB não é difer-
ente. Pode estabelecer ligação ao Cosmos DB a partir de várias linguagens, incluindo
.NET, Python, Node.js e Java. As linguagens podem diferir, mas todos os SDKs partil-
ham uma configuração semelhante: a deteção de um endpoint. Existem duas proprie-
dades principais da política de ligação que são importantes:
¡ Deteção automática de endpoints: o SDK lê todos os endpoints disponíveis a partir do
Cosmos DB e utiliza a ordem de ativação pós-falha especificada. Esta abordagem
garante que a sua aplicação segue sempre a ordem especificada ao nível da base
de dados. Pode, por exemplo, pretender que todas as leituras percorram a região
E.U.A. Leste e que apenas utilizem a Europa Ocidental quando há manutenção
na localização principal.
¡ Localizações de endpoints preferenciais: especifica as localizações que pretende uti-
lizar. Um exemplo é se implementar a sua aplicação na Europa Ocidental e quiser
garantir que utiliza o endpoints da Europa Ocidental. Perde-se alguma flexibili-
dade à medida que os endpoints são adicionados ou removidos, mas certifique-se
de que o endpoints predefinido está próximo da sua aplicação, sem haver a neces-
sidade de um encaminhamento de rede mais avançado para ajudar a
determiná-lo.
Normalmente, a aplicação permite que o SDK do Cosmos DB efetue a gestão desta
tarefa. A aplicação não altera a maneira como gere a ligação à base de dados: sabe ape-
nas que pode ligar-se a várias localizações. Mas o SDK é o que estabelece a ligação e utiliza
este conhecimento da localização.
Uma abordagem simplificada de como esse conhecimento da localização entre a

aplicação e o SDK é utilizado é mostrada na figura 10.10. Mais uma vez, a linguagem
não importa, e a abordagem é a mesma; a figura utiliza o SDK de Python porque é a
linguagem em que alguns exemplos foram escritos. Este exemplo também pressupõe
que esteja a utilizar localizações de endpoints automáticos.
Azure
2. Pede localizações dos Cosmos DB
endpoints automáticos
1. Pedido de ligação 3. Ligação

e localizações
devolvidas
4. Ligação devolvida SDK de Cosmos
Web App
5. Pedido de dados DB Python
6. Pede dados a partir

8. Dados devolvidos do endpoint principal
Azure Cosmos
7. Dados enviados DB (leitura
a partir do endpoint principal
de leitura principal
Figura 10.10 O fluxo de pedidos por meio de um SDK do Cosmos DB quando uma aplicação utiliza
o conhecimento da localização para consultar o Cosmos DB
Os passos ilustrados na figura 10.10 são os seguintes:
1 A sua aplicação precisa de fazer uma ligação a uma base de dados Cosmos DB. Na
política de ligação, ativa a deteção automática de endpoints. A aplicação utiliza o
SDK do Cosmos DB para fazer uma ligação de base de dados.
2 O SDK do Cosmos DB faz um pedido de ligação e indica que pretende utilizar
localizações de endpoints automáticos.
3 É devolvida uma ligação com base nas credenciais e na base de dados pedidas.
4 O SDK devolve um objeto de ligação para que a aplicação o utilize. As infor-
mações sobre a localização são abstraídas da aplicação.
5 A aplicação pede alguns dados a partir da base de dados Cosmos DB. O SDK é
utilizado novamente para consultar e obter os dados.
6 O SDK utiliza a lista de endpoints disponíveis e faz o pedido ao primeiro endpoints
disponível. Em seguida, o SDK utiliza o endpoints de ligação para consultar os dados.
Se o endpoints principal não estiver disponível, como durante um evento de
manutenção, será automaticamente utilizada a próxima localização do endpoints.
7 O Cosmos DB devolve os dados a partir da localização do endpoints.
8 O SDK devolve os dados a partir do Cosmos DB à aplicação para analisá-los e
apresentá-los, conforme necessário.
Aceder aos dados distribuídos globalmente 155
As últimas coisas a ver no Cosmos DB são as chaves de acesso, que lhe permitem con-
trolar quem pode aceder aos dados e que permissões têm. As chaves podem ser gera-
das novamente e, como faz com as palavras-passe, pode pretender implementar uma
política para executar regularmente este processo de regeneração de chave. Para
aceder aos dados distribuídos no Cosmos DB, precisa de obter as suas chaves. O portal
Azure fornece uma maneira de ver todas as chaves e cadeias de ligação para a sua base
de dados.
Experimente agora
Para ver as chaves da sua conta Cosmos DB, conclua os passos seguintes:
1 Navegue para o Grupo de Recursos e selecione-o na barra de navegação à

esquerda no portal Azure.
azuremolchapter10.
3 Selecione a sua conta Cosmos DB a partir da lista de recursos.
4 No lado esquerdo, escolha Chaves.
5 Anote o URI e a chave primária (figura 10.11). Irá utilizar estes valores
no laboratório de fim de capítulo.
Figura 10.11 A secção Chaves da sua conta Cosmos DB lista as informações de ligação e as chaves de
acesso. Precisa destas informações quando criar e executar aplicações, como no laboratório de fim
de capítulo.
Grande parte do que acontece no Cosmos DB são processos técnicos para distribuir os
seus dados e permitir que as suas aplicações leiam e escrevam a partir das localizações
mais apropriadas. Mas é precisamente disso que se trata. Saber que o serviço Cosmos
DB ajuda a conceber e planear a sua aplicação ou a resolver problemas se as aplicações
não permitirem que o SDK execute operações de leitura e escrita conforme necessário.
Mas não se preocupe com a forma e o momento; concentre-se nas suas aplicações e
utilize os serviços do Azure como o Cosmos DB para desfrutar das funcionalidades e
das vantagens da cloud que lhe permitem operar a uma escala global.
10.4 Laboratório: implementar uma aplicação Web que utiliza

o Cosmos DB
Na secção 10.2.2, distribuiu a sua base de dados Cosmos DB globalmente. Em seguida,
iremos abordar o aspeto teórico sobre como as aplicações Web podem ler a partir de
localizações em quaquer parte do mundo. Agora, provavelmente, quer apenas ver o
Cosmos DB em ação, por isso, aproveite! Neste laboratório, a aplicação web básica de
capítulos anteriores é usada, mas desta vez, o menu de pizza sai dos itens que adicio-
nou à base de dados cosmos DB num exercício anterior “Experimente agora”:
1 No portal Azure, crie uma aplicação Web.

2 Como a pizzaria já não é uma página HTML básica, escolha Node LTS para
o tempo de execução que funciona em Linux.
3 Quando a aplicação Web estiver pronta, crie uma fonte de implementação
(repositório local de Git). Os passos são os mesmos que realizou para criar uma
nos capítulos anteriores, como o 3; portanto, se precisar de refrescar a sua
memória, poderá rever esses exercícios.
4 Abra o Cloud Shell. Nos capítulos anteriores, obteve uma cópia dos exemplos do
Azure no GitHub. Se não fez isso, siga estes passos para obter uma cópia:
5 Mude para o diretório que contém o exemplo da aplicação Web do Cosmos DB:
cd ~/azure-mol-samples-2nd-ed/10/cosmosdbwebapp
6 Edite o ficheiro de configuração com o URI e a chave de acesso da base de dados

que copiou no exercício anterior "Experimente agora" para ver as chaves do Cos-
mos DB:
nano config.js
7 Escreva o ficheiro premindo Ctrl-O e, em seguida, saia pressionando Ctrl-X.

8 Adicione e confirme as suas alterações no Git com o seguinte comando:
9 Crie uma ligação para o novo repositório Git no bloco de teste com git remote
add azure, seguido pelo URL de implementação do Git.
10 Utilize git push azure master para emitir as suas alterações via push para a sua
aplicação Web.
Laboratório: implementar uma aplicação Web que utiliza o Cosmos DB 157
11 Selecione o URL para a aplicação Web na janela Descrição Geral do portal Azure.
12 Abra este URL num browser para ver a sua pizzaria, que agora funciona
com o Cosmos DB, como mostrado na figura 10.12.
Figura 10.12 A aplicação Web básica do Azure mostra o seu pequeno menu de pizzas com base
nos dados da base de dados Cosmos DB. A pizzaria de capítulos anteriores é mostrada, mas agora
a lista de pizzas e seus preços é alimentada pela Cosmos DB. O site ainda é básico, pois o objetivo
é que veja o serviço em ação e compreenda como poderia começar a construir as suas próprias
aplicações.
11
Gerir o tráfego e o
encaminhamento de rede
A resolução de DNS (Sistema de Nomes de Domínio) está no centro de quase todas

as ligações digitais que faz. É como navega na Web, recebe e-mails, assiste ao Netflix
e faz chamadas Skype. DNS é o mecanismo que converte um nome, como
manning.com, num endereço IP. Quando quero aprender um tópico novo, não
preciso de me lembrar de 35.166.24.88; apenas introduzo manning.com num brow-
ser e navego por alguns livros! Os dispositivos de rede fazem o encaminhamento do
tráfego com base em endereços IP; então, precisa de uma abordagem que ajude os
que têm memória fraca a fazerem coisas como comprar livros ou pizzas online.
Nos capítulos anteriores, passou muito tempo a aprender a criar aplicações que
podem ser dimensionadas, são altamente disponíveis e distribuídas globalmente.
Uma das últimas peças que falta é como direcionar os clientes de todo o mundo para
a instância de aplicação mais apropriada, normalmente a instância mais próxima
deles. O Azure Traffic Manager facilita o encaminhamento automático dos clientes
para as suas instâncias da aplicação com base no desempenho ou na localização geo-
gráfica. Neste capítulo, discutimos como pode criar e gerir zonas DNS no Azure e,
em seguida, como utilizar o Traffic Manager para encaminhar clientes com consul-
tas DNS, como apresentado na figura 11.1.
11.1 O que é o DNS do Azure?

Não precisa de entender em detalhe como funciona o DNS para concluir este capí-
tulo e utilizar o DNS do Azure. A figura 11.2 mostra uma descrição geral de alto
nível de como um utilizador consulta um serviço DNS para obter o endereço IP
para uma aplicação Web. Podem ocorrer muitos subpassos nos passos 1 e 2, por-
tanto, se tiver um pouco de tempo ao almoço no final deste capítulo, fique à von-
tade para ler como funcionam as consultas DNS e a recursão.
158
O que é o DNS do Azure? 159
Cliente
Londres
Internet
Cliente encaminhado para

Azure Traffic a instância de aplicação
Consultas DNS para localizar Manager
o destino apropriado com mais apropriada com base
base na localização do nas respostas DNS de
cliente e no método de Traffic Manager
encaminhamento
Regiões do Azure
Zona do DNS do Azure
azuremol.com Região Leste dos E.U.A. Região da Europa
Ocidental
eastus.azuremol.com westeurope.azuremol.com
VM Web 1 VM Web 2
53.17.91.8 102.42.9.67
A 53.17.91.8 A 102.42.9.67
Figura 11.1 Neste capítulo, examinaremos como pode criar zonas DNS no DNS do Azure. Para minimizar
a latência e melhorar os tempos de resposta, o Traffic Manager pode, então, ser utilizado para consultar
o DNS e direcionar os clientes para a sua instância da aplicação mais próxima.
O DNS do Azure funciona da mesma forma que qualquer solução DNS existente que
utilize ou conheça. A zona e os registos são armazenados no Azure e os servidores de
nomes que respondem às consultas DNS são distribuídos globalmente pelos datacen-
ters do Azure.
Cliente
1. Consultas DNS para 3. Liga-se ao endereço IP

www.azuremol.com 2. Registo de host devolvido: público da aplicação em Figura 11.2 Este fluxo
53.17.91.8 Azure simplificado de tráfego DNS
mostra como um utilizador
Infraestrutura do Azure envia um pedido DNS para
www.azuremol.com para
um servidor DNS, recebe
Azure DNS Web App 53.17.91.8 uma resposta que contém
o endereço IP associado e,
em seguida, liga-se à
aplicação Web.
160 Capítulo 11 Gerir o tráfego e o encaminhamento de rede
O DNS do Azure dá suporte a todos os tipos de registo esperados numa oferta de servi-
ços DNS regular. Os registos IPv4 e IPv6 podem ser criados. Os tipos de registo são os
seguintes:
¡ A — Registos de host IPv4, para direcionar os clientes para as suas aplicações
e serviços
¡ AAAA — Registos de host IPv6, para os crânios que utilizam o IPv6 para direcio-
nar os clientes para as suas aplicações e serviços
¡ CNAME — Nome canónico ou alias, registos, como fornecer um nome abreviado
que é mais fácil de utilizar do que o nome de host completo de um servidor
¡ MX — Registos de troca de e-mails para encaminhar o tráfego de e-mail para os
seus servidores ou fornecedores de e-mail
¡ NS — Registos de servidor de nomes, que incluem os registos gerados automatica-
mente para os servidores de nomes do Azure
¡ PTR — Registos PTR, para consultas DNS revertidas para mapear endereços IP
para nomes de host
¡ SOA—Registos de início de autoridade, que incluem os registos gerados
automaticamente para os servidores de nomes do Azure
¡ SRV—Registos de serviço, para fornecer a deteção de serviços de rede, como para
identidade
¡ TXT—Registos de texto, como para Sender Protection Framework (SPF) ou
DomainKeys Identified Mail (DKIM)
Numa configuração típica de DNS, configura vários servidores DNS. Mesmo com a
distribuição geográfica desses servidores para redundância, os clientes podem consul-
tar um servidor de nomes do outro lado do mundo. Esses milissegundos necessários
para consultar, resolver e, em seguida, pedir uma resposta para a aplicação Web podem
acumular-se quando tem muitos clientes que querem pedir pizza.
Uma zona do DNS do Azure é replicada globalmente pelos datacenters do Azure. A
rede Anycast assegura que quando um cliente faz uma consulta DNS no seu domínio, o
servidor de nomes mais próximo disponível responde ao seu pedido. Como consegue o
encaminhamento Anycast fazer isso? Normalmente, um único endereço IP é propa-
gado em várias regiões. Em vez de utilizar uma consulta DNS simples que resolve um
único endereço IP que existe apenas numa localização, o encaminhamento Anycast
permite que a infraestrutura de rede determine de maneira inteligente de onde vem
um pedido e direcione o cliente para a região anunciada mais próxima. Este encami-
nhamento permite que os seus clientes se liguem à sua aplicação Web mais rapidamente
e oferece uma melhor experiência geral ao cliente.
Não precisa de ser um especialista em redes para entender totalmente como isto
funciona; o Azure faz isso por si! Quando combina o DNS do Azure com o Azure Traffic
Manager (secção 11.2), não só devolve consultas DNS a partir dos servidores de nomes
mais próximos, como também liga os clientes à instância da aplicação mais próxima.
Faça que esses milissegundos contem!
11.2 Delegar um domínio real ao DNS do Azure

Quando regista um domínio real, o seu fornecedor oferece uma interface de gestão e
ferramentas para gerir esse domínio. Para permitir que os clientes acedam aos seus servi-
ços e utilizem a zona e os registos do DNS do Azure, delega a autoridade do seu domínio
Delegar um domínio real ao DNS do Azure 161
aos servidores de nomes do Azure. Esta delegação faz com que todas as consultas DNS
sejam direcionadas imediatamente para esses servidores de nomes do Azure, como mos-
trado na figura 11.3. Atualmente, o Azure não lhe permite comprar e registar domínios na
plataforma; portanto, precisa de comprar o nome de domínio por meio de um registador
externo e, em seguida, direcionar os registos NS para os servidores de nomes do Azure.
Fornecedor configurado com

servidores de nomes do
Azure para delegar o seu
domínio ao DNS do Azure
ns1.azure-dns.com
Fornecedor do nome
de domínio Zona do DNS
NS ns1.azure-dns.com.
Cliente
NS ns2.azure-dns.net. Registo de host
Consulta O fornecedor
NS ns3.azure-dns.org.
DNS para o encaminha
seu domínio NS ns4.azure-dns.info. todas as www A 53.17.91.8
consultas para
o DNS do Azure
Figura 11.3 Para delegar o seu domínio no Azure, conFigura o fornecedor de domínio atual com os
endereços do servidor de nomes do Azure. Quando um cliente faz uma consulta DNS para o seu domínio,
os pedidos são enviados diretamente para os servidores de nomes do Azure da sua zona.
Porquê delegar o DNS ao Azure? Para simplificar a gestão e as operações. Se criar servi-
ços adicionais, ajuste a configuração do balanceador de carga, ou se quiser melhorar os
tempos de resposta com o DNS globalmente replicado, o Azure fornecerá essa única
interface de gestão para concluir essas tarefas. Quando as suas zonas DNS são alojadas
no Azure, também pode implementar algumas das funcionalidades de segurança do
Gestor de Recursos abordadas no capítulo 6: funcionalidades como o RBAC (controlo
de acesso baseado em funções) para limitar e auditar o acesso às zonas DNS e aos blo-
queios de recursos para impedir a eliminação acidental, ou mesmo maliciosa, da zona.
A maioria dos registadores de domínio fornecem interfaces e controlos bastante bási-
cos para gerir zonas e registos DNS. Para reduzir as despesas gerais de gestão e melhorar a
segurança, o DNS do Azure permite-lhe utilizar a CLI do Azure, o Azure PowerShell ou as
APIs REST para adicionar ou editar registos. As equipas de operações podem utilizar as
mesmas ferramentas e workflows para integrar novos serviços; e se ocorrerem problemas,
muitas vezes é mais fácil resolver problemas quando puder verificar se o DNS funciona
como esperado sem introduzir a variável de um fornecedor DNS de terceiros.
Portanto, se estiver convencido de que há uma lógica para delegar o seu domínio ao
DNS do Azure, para quais servidores de nomes do Azure direciona o seu domínio? Se
criar uma zona do DNS do Azure, os servidores de nomes serão listados no portal, como
mostrado na figura 11.4. Também pode aceder a estes endereços de servidores de
nomes com o Azure CLI ou o Azure PowerShell.
Nestas últimas páginas, não houve exercícios “Experimente agora”, porque a
menos que compre e configure um domínio real, não pode testar como pode encami-
nhar o tráfego real.
Figura 11.4 Pode ver os servidores de nomes do Azure para a sua zona DNS no portal Azure, no
Azure CLI ou no Azure PowerShell.
tráfego. Pode criar uma zona do DNS do Azure sem um domínio real, mas não poderá
ser encaminhado nenhum tráfego para a mesma. Na vida real, atualiza os registos NS
com o seu fornecedor atual para direcionar quaisquer consultas do seu domínio para
os servidores de nomes do Azure. A propagação da delegação do seu domínio pela
hierarquia DNS global pode levar entre 24 e 48 horas (embora geralmente seja muito
menos tempo), portanto, planeie-a de maneira conveniente; isto pode causar breves
interrupções dos clientes que acedam à sua aplicação.
11.3 Encaminhamento global e resolução com o Traffic Manager

Nos capítulos anteriores, aprendeu sobre aplicações altamente disponíveis que são dis-
tribuídas globalmente. O objetivo são várias instâncias de aplicações Web ou de VM,
em diferentes regiões ou continentes, que se ligam a uma instância do Cosmos DB
próxima. Mas, como consegue que os seus clientes se liguem à VM ou aplicação Web
mais próxima que executa a sua aplicação?
O Azure Traffic Manager é um serviço de rede que atua como um destino central
para os seus clientes. Vamos utilizar o exemplo de uma aplicação Web no endereço
www.azure-mol.com. A figura 11.5 fornece uma descrição geral de como o Traffic Mana-
ger encaminha os utilizadores para a aplicação mais próxima disponível.
2. Resolve o endereço para

1. Consultas do cliente azuremol.trafficmanager.net 3. Tráfego de consultas
www.azuremol.com Gestor para endpoint
Tráfego 4. O Traffic Manager
Cliente DNS Gestor examina a política de
encaminhamento,
6. Resolve 5. Endpoint devolvido devolve um endpoint
eastus.cloudapp.net como eastus.cloudapp.net
para 53.17.91.8
7. O cliente liga-se
à aplicação Web
VM Web
Leste dos
E.U.A.
53.17.91.8
Figura 11.5 Um cliente envia uma consulta DNS para um serviço DNS para www.azuremol.com. O serviço DNS
encaminha a consulta para o Traffic Manager, que devolve um endpoint com base no método de encaminhamento
em utilização. O endpoint é resolvido num endereço IP, que o cliente utiliza para se ligar à aplicação Web.
Encaminhamento global e resolução com o Traffic Manager 163
O Traffic Manager não executa a função de um balanceador de carga, sobre o qual

aprendeu no capítulo 8. Como mostra a figura 11.5, o Traffic Manager encaminha o trá-
fego para um IP público. Vamos examinar o fluxo de tráfego um pouco mais de perto:
1 O utilizador faz uma consulta DNS para www.azuremol.com. O seu servidor DNS
contacta os servidores de nomes para azuremol.com (que podem ser os servido-
res de nomes do Azure se utilizar o DNS do Azure!) e pede o registo para www.
2 O host www é resolvido num registo CNAME que o direciona para azuremol.traf-
ficmanager.net.
3 O serviço DNS encaminha o pedido DNS para os servidores de nomes do Azure
para trafficmanager.net.
4 Em seguida, o Traffic Manager examina o pedido e determina um endpoint
para direcionar o utilizador. O estado e o estado de funcionamento do endpoint
são examinados, como com os balanceadores de carga do Azure. O método de
encaminhamento do Traffic Manager também é examinado. Os métodos de
encaminhamento que o Traffic Manager pode utilizar são os seguintes:
¡ Prioridade—Controla a ordem na qual os endpoints são acedidos
¡ Ponderada—Distribui o tráfego pelos endpoints com base numa métrica de
ponderação atribuída
¡ Desempenho—Encaminhamento de utilizadores com base na latência para um
endpoint para que o utilizador receba o tempo de resposta mais rápido possível
¡ Geográfico—Associa os endpoints a uma região geográfica e direciona os utiliza-
dores com base na sua localização
5 O endpoint eastus.cloudapp.net é devolvido ao serviço DNS pelo Traffic Manager.
6 O serviço DNS procura o registo DNS para eastus.cloudapp.net e devolve o resul-

tado da consulta ao cliente.
7 Com o endereço IP do seu endpoint pedido, o cliente contacta a aplicação Web
diretamente. Neste ponto, o tráfego pode chegar ao endereço IP público de um
balanceador de carga do Azure em vez de uma VM diretamente.
Como pode ver, a função do Traffic Manager é determinar um endpoint de uma deter-
minada aplicação para a qual se direciona os clientes. Algumas verificações do estado
de funcionamento monitorizam o estado dos endpoints, semelhantes às sondagens do
estado de funcionamento do balanceador de carga que vimos no capítulo 8. Além
disso, pode definir um mecanismo de encaminhamento de tráfego prioritário ou pon-
derado para distribuir os utilizadores por um conjunto de endpoints disponíveis, mais
uma vez, de forma semelhante a um balanceador de carga. Normalmente, o Traffic
Manager direciona o tráfego para um balanceador de carga ou um gateway da aplica-
ção do Azure ou para uma implementação de aplicações Web.
Azure Front Door

O Traffic Manager, que examinámos nesta secção, é ótimo para distribuir e encaminhar
o tráfego globalmente. Funciona com qualquer tipo de endpoint da Internet, não apenas
recursos no Azure. O encaminhamento de tráfego é baseado em DNS e não tem em
observa a aplicação em si.
Se precisar de distribuição de tráfego ao nível da aplicação e da capacidade de descar-

regar TLS/SSL ou encaminhar pedidos por HTTP/HTTPS, o Azure Front Door pode ajudar.
Traffic Manager
(continuação)
e o Front Door oferece o mesmo tipo de opções de serviço e configuração, mas o Front
Door é especificamente projetado para trabalhar na camada de aplicação. O Front Door
também tem alguns truques de desempenho interessantes, tais como a divisão de TCP
para quebrar ligações em pedaços menores e reduzir a latência.
No capítulo 8, analisámos os balanceadores de carga e mencionámos o Application
Gateway, que funciona na camada de aplicação e permite fazer ações como o descarre-
gamento de TLS. O capítulo focava os balanceadores de carga para ajudar a aprender os
conceitos core nos quais o Application Gateway se basearia. O mesmo é aplicável aqui.
Focamo-nos no Traffic Manager neste capítulo, embora muitos dos mesmos conceitos e
opções de configuração, como opções de encaminhamento, também estejam disponí-
veis para o Azure Front Door. Tal como acontece com a maioria das coisas no Azure, o
que deve ser utilizado em cada serviço é impulsionado pelas aplicações que executa e
pelas necessidades das mesmas.
11.3.1 Criar perfis do Traffic Manager

O Traffic Manager utiliza perfis para determinar qual método de encaminhamento deve
ser utilizado e quais são os endpoints associados para um determinado pedido. Para con-
tinuar o tema dos capítulos anteriores sobre uma aplicação distribuída globalmente, pre-
tende que os utilizadores utilizem a aplicação Web mais próxima deles. Se examinar os
métodos de encaminhamento novamente, tem duas maneiras de fazer isso:
¡ Encaminhamento de desempenho—O cliente é encaminhado para o endpoint com a
latência mais baixa, em relação à origem do pedido. Este método de encaminha-
mento fornece alguma informação e permite sempre que o Traffic Manager enca-
minhe o cliente para um endpoint disponível.
¡ Encaminhamento geográfico —O cliente é sempre encaminhado para um determi-
nado endpoint, com base na origem do seu pedido. Se o cliente está nos Estados
Unidos, é sempre direcionado para a região E.U.A. Leste, por exemplo. Este
método de encaminhamento requer que defina as regiões geográficas que serão
associadas a cada endpoint.
Quando utiliza o encaminhamento geográfico, tem um pouco mais de controlo dos
endpoints que os clientes utilizam. Pode haver motivos regulamentares que exijam
que os clientes de uma determinada região utilizem sempre endpoints na mesma
região. Os exercícios utilizam endpoints geográficos para mostrar um exemplo mais
real, porque há o encaminhamento geográfico tem um truque: deve especificar um
perfil subordinado, não diretamente um endpoint.
O céu não vai cair se utilizar o método de encaminhamento geográfico com
endpoints, mas a prática recomendada é utilizar outro perfil do Traffic Manager para
passar o tráfego para o último endpoint. Porquê? As regiões podem ser associadas ape-
nas a um perfil do Traffic Manager. Nos capítulos anteriores sobre elevada
disponibilidade, quis sempre ter a certeza de que tinha redundância. Se associar uma
região a um determinado endpoint e utilizar o encaminhamento geográfico, não terá
opção de ativação pós-falha se esse endpoint encontrar um problema ou se executar a
manutenção.
Em vez disso, os perfis subordinados aninhados permitem-lhe definir uma priori-
dade que direciona sempre o tráfego para um endpoint em bom estado de funciona-
mento. Se o endpoint não estiver em bom estado, o tráfego vai para um
endpoint alternativo. A figura 11.6 mostra uma ativação pós-falha do tráfego numa
região diferente, embora também possa criar várias instâncias de aplicações Web nos
E.U.A. Oeste e utilizar um método de encaminhamento ponderado no perfil subordi-
nado. À medida que começa a reduzir horizontalmente o ambiente de aplicação, tenha
tempo para pensar na melhor forma de fornecer elevada disponibilidade aos endpoints
por trás do Traffic Manager. Para estes exemplos, irá criar uma ativação pós-falha entre
regiões para ver claramente as diferenças de comportamento.
Perfil com método

de encaminham-
ento geográfico
Este dos EUA Europa Ocidental

Perfil subordinado com Perfil subordinado com
método de encaminha- método de encaminha-
mento prioritário mento prioritário
Web App Web App Web App Web App

Leste dos E.U.A. Europa Ocidental Leste dos E.U.A. Europa Ocidental
Prioridade 1 Prioridade 100 Prioridade 100 Prioridade 1
Figura 11.6 Um perfil do Traffic Manager principal com o método de encaminhamento geográfico deve
utilizar perfis subordinados que contenham vários endpoints. Depois, esses endpoints subordinados
podem utilizar o encaminhamento prioritário para direcionar o tráfego para o endpoint preferencial. O
perfil subordinado da região E.U.A. Leste, por exemplo, envia sempre tráfego para o endpoint na região
E.U.A. Leste, contanto que o endpoint esteja em bom estado de funcionamento. Se o endpoint não
estiver em bom estado de funcionamento, então, o tráfego será direcionado para a Europa Ocidental.
Sem este perfil subordinado, os clientes na região E.U.A. Leste não puderam efetuar a ativação pós-falha
para um endpoint alternativo e não puderam aceder à sua aplicação Web.
Experimente agora
Para criar os perfis do Traffic Manager para a sua aplicação distribuída, conclua os pas-
sos a seguir.
O resto dos exercícios utiliza a região E.U.A. Leste e Europa Ocidental. Se não vive em
nenhuma dessas regiões, escolha uma região diferente que seja mais apropriada. Ape-
nas lembre-se de ser consistente em todos os exercícios! O laboratório de fim de capítulo
mostra como tudo isto se reúne e funciona, mas não será direcionado corretamente
para as suas aplicações Web se viver fora da América do Norte ou da Europa e não alte-
rar as regiões em conformidade.

do dashboard.
2 Crie um grupo de recursos, especificando um nome do grupo de recursos, como
azuremolchapter11, e uma localização, como eastus:
3 Crie o perfil do Traffic Manager principal. Pretende utilizar o método de enca-

minhamento geográfico e, em seguida, especifique um nome, como azuremol.
O parâmetro para o nome DNS informa que o mesmo deve ser exclusivo; por-
tanto, forneça um nome exclusivo. O domínio a seguir cria o nome de host azu-
remol.trafficmanager.net, que utiliza para configurar as aplicações Web no
laboratório no fim do capítulo:
az network traffic-manager profile create \
--name azuremol \
--routing-method geographic \
--unique-dns-name azuremol
4 Crie um dos perfis subordinados do Traffic Manager. Desta vez, utilize o método
de encaminhamento prioritário e o nome eastus e especifique outro nome DNS
exclusivo, como azuremoleastus:
--name eastus \
--routing-method priority \
--unique-dns-name azuremoleastus
5 Crie mais um perfil subordinado do Traffic Manager com o nome westeurope e

outro nome DNS exclusivo, como azuremolwesteurope:
--name westeurope \
--routing-method priority \
--unique-dns-name azuremolwesteurope
6 Agora criou uma aplicação Web algumas vezes, por isso, utilize a CLI para criar
rapidamente dois planos do serviço de aplicações e uma aplicação Web em cada
plano. Uma destas aplicações Web fica na região E.U.A. Leste; a outra na Europa
Ocidental. No laboratório de fim de capítulo, irá carregar páginas Web de exem-
plo para estas aplicações Web; portanto, por enquanto, basta criar o site vazio e
preparar as aplicações para utilizar um repositório Git local.
Crie a aplicação Web na região E.U.A. Leste da seguinte maneira:
--name appserviceeastus \
--location eastus \
--sku S1
az webapp create \
--name azuremoleastus \
--plan appserviceeastus \
7 Crie uma segunda aplicação Web na Europa Ocidental:

--name appservicewesteurope \
--location westeurope \
--sku S1
az webapp create \
--name azuremolwesteurope \
--plan appservicewesteurope \
11.3.2 Distribuição global de tráfego para a instância mais próxima

Criou os perfis e os endpoints do Traffic Manager, mas nenhum tráfego que possa fluir.
Se os clientes fossem direcionados para os perfis, não haveria nenhuma associação aos
seus endpoints. O diagrama na figura 11.7 mostra como precisa de associar endpoints
aos perfis.
Perfil com método

de encaminham-
ento geográfico


Leste dos Europa Leste dos Europa
E.U.A. Ocidental E.U.A. Ocidental
Figura 11.7 Nesta secção, irá associar os endpoints aos perfis do Traffic Manager e define a prioridade
para o tráfego a ser distribuído.
As primeiras associações que faz destinam-se aos endpoints da aplicação Web. Lembre-
-se de que, para ter elevada disponibilidade, pretende que ambas as aplicações Web
fiquem disponíveis para cada perfil do Traffic Manager. Utiliza um método de encami-
nhamento prioritário para direcionar todo o tráfego para a aplicação Web principal
para cada perfil. Se essa aplicação Web não estiver disponível, o tráfego poderá efetuar
a ativação pós-falha para o endpoint secundário da aplicação Web.
Quando criou os perfis do Traffic Manager na secção 11.3.1, foram utilizadas algumas
predefinições para as opções de verificação do estado de funcionamento e a monitori-
zação dos endpoints. Vamos explorar quais são essas opções:
¡ DNS Time to Live (TTL): 30 segundos—Define quanto tempo as respostas do Traffic
Manager podem ser colocadas em cache. Um TTL breve garante que o tráfego do
cliente é encaminhado apropriadamente quando são efetuadas atualizações na
configuração do Traffic Manager.
¡ Protocolo de monitorização de endpoints: HTTP —Também pode optar por HTTPS ou
por uma verificação TCP básica. Da mesma forma que com os balanceadores de
carga, o HTTP ou o HTTPS garante que seja devolvida uma resposta HTTP 200
OK a partir de cada endpoint.
¡ Porta: 80—A porta a ser verificada em cada endpoint.
¡ Caminho: /—Por predefinição, verifica a raiz do endpoint, embora também possa
configurar uma página personalizada, como a página de verificação do estado de
funcionamento utilizada pelos balanceadores de carga.
¡ Intervalo de Sondagem de Endpoints: 30 segundos —Com que frequência deve verifi-
car-se o estado de funcionamento do endpoint. O valor pode ser 10 segundos ou
30 segundos. Para executar uma sondagem rápida a cada 10 segundos, há um
custo adicional por endpoint.
¡ Número de Falhas a Tolerar: 3—Quantas vezes um endpoint pode falhar numa
verificação do estado de funcionamento antes de ser marcado como
indisponível.
¡ Tempo Limite de Sondagem: 10 segundos —O período de tempo antes de uma pes-
quisa ser marcada como falha e o endpoint ser novamente sondado.
Não precisa de alterar nenhuma destas opções predefinidas. Para workloads críticos
quando cria os seus próprios ambientes de aplicações no mundo real, pode reduzir o
número de falhas a tolerar ou o intervalo de sondagem. Estas alterações irão garantir
que quaisquer problemas do estado de funcionamento sejam detetados rapidamente,
e o tráfego seria encaminhado para um endpoint diferente mais cedo.
Experimente agora
Para associar endpoints a perfis e concluir o encaminhamento geográfico, conclua
1 No portal Azure, navegue e selecione o seu grupo de recursos. Para este exercí-
cio, selecione o perfil do Traffic Manager criado para a região E.U.A. Leste.
2 Escolha Endpoints na barra de navegação à esquerda no perfil e, em seguida,
selecione Adicionar.
3 Crie um endpoint Azure e insira um nome, como eastus.
4 Existem diferentes tipos de recurso de destino; pretende utilizar o App Service.
Para o recurso de destino, selecione a sua aplicação Web na região E.U.A. Leste,
como azuremoleastus.
5 Deixe a Prioridade definida para 1, aceite quaisquer outras predefinições que
possam ser definidas e, em seguida, selecione OK.
6 Repita o processo para adicionar outro endpoint. Desta vez, nomeie o endpoint
como westeurope, selecione a sua aplicação Web na Europa Ocidental como o
recurso de destino e defina uma prioridade de 100.
O seu perfil do Traffic Manager lista, agora, dois endpoints: um para a aplica-
ção Web na região E.U.A. Leste e outro para a aplicação Web na Europa Ociden-
tal, como mostrado na figura 11.8. Este encaminhamento baseado na prioridade
dos endpoints direciona sempre o tráfego para a aplicação Web na região
E.U.A. Leste quando esse recurso está em bom estado de funcionamento. Se esse
recurso não estiver disponível, há redundância para efetuar a ativação pós-falha
para a aplicação Web na Europa Ocidental.
Figura 11.8 Estão listados dois endpoints no perfil do Traffic Manager. O endpoint para a região E.U.A.
Leste tem a prioridade mais baixa, portanto, recebe sempre o tráfego quando o endpoint está em bom estado
de funcionamento. A redundância é fornecida com o endpoint da Europa Ocidental, que é utilizado apenas quando
o endpoint da região E.U.A. Leste não está disponível.
7 Volte ao seu grupo de recursos e selecione o perfil do Traffic Manager para

a Europa Ocidental.
8 Escolha para adicionar endpoints.
9 Repita os passos para adicionar dois endpoints e configurá-los como se segue:
¡ Nome: westeurope
Recurso de destino: aplicação Web na Europa Ocidental
Prioridade: 1
¡ Nome: eastus
Recurso de destino: aplicação Web em E.U.A. Leste
Prioridade: 100
O seu perfil do Traffic Manager lista, agora, dois endpoints: um para a aplicação Web na
Europa Ocidental e outro para a aplicação Web na região E.U.A. Leste, como mostrado na
figura 11.9. Forneceu a mesma redundância que no perfil anterior do Traffic Manager,
desta vez com todo o tráfego a ser encaminhado para a Europa ocidental quando está em
bom estado de funcionamento e, caso contrário, para a região E.U.A. Leste.
Figura 11.9 A mesma configuração de endpoints como o perfil anterior do Traffic Manager, desta vez com a
localização das aplicações Web revertidas. Estes perfis subordinados podem ser sempre utilizados para encaminhar
sempre os clientes para a aplicação Web na região E.U.A. Leste ou Europa Ocidental, mas agora tem a redundância
para efetuar a ativação pós-falha para outro endpoint se o endpoint principal na região não estiver disponível.
Este processo tem só mais uma parte, prometo! Lembre-se de que esta é uma boa
prática para obter elevada disponibilidade se utilizar o Traffic Manager para a distribui-
ção global de aplicações. No mundo real, o seu ambiente pode não ser tão complexo.
Veja o diagrama novamente para ver os perfis subordinados e as associações às aplica-
ções Web regionais que precisa de criar, como mostrado na figura 11.10.
Perfil com
método de
encaminhamento
geográfico


Leste dos E.U.A. Europa Ocidental Leste dos E.U.A. Europa Ocidental
Figura 11.10 Os perfis subordinados do Traffic Manager para a região E.U.A. Leste e a Europa
Ocidental foram criados, com as aplicações Web regionais e as prioridades configuradas
conforme necessário. Agora, precisa de associar os perfis subordinados ao perfil principal.
Para direcionar o tráfego com base na geografia, define uma região, como a América do
Norte, e um perfil aninhado, tal como eastus. Todos os clientes da região da América do
Norte são direcionados para este perfil subordinado. Configurou as prioridades desse
perfil subordinado para que a aplicação Web na região E.U.A. Leste providencie sempre
o tráfego. Porém, forneceu uma opção redundante para efetuar a ativação pós-falha para
a aplicação Web na Europa Ocidental, conforme necessário.
Para os clientes na Europa Ocidental ocorre o inverso. Pode ser adicionado outro
endpoint para o perfil principal do Traffic Manager, desta vez com a Europa como a
região a ser associada ao endpoint e, em seguida, o perfil aninhado westeurope. Todo o
tráfego europeu é encaminhado para este perfil, e a aplicação Web na Europa Ociden-
tal providencia sempre a aplicação Web. Caso ocorra um problema, o tráfego pode efe-
tuar a ativação pós-falha para a região E.U.A. Leste.
Se houver mandatos de soberania de dados ou de políticas para as quais o tráfego
não pode efetuar a ativação pós-falha para uma região diferente, talvez seja necessário
ajustar a configuração dos endpoints e dos perfis do Traffic Manager. Pode, por exem-
plo, criar várias aplicações Web na Europa Ocidental, como viu no capítulo 9. Desta
forma, tem várias instâncias de aplicações Web que podem servir os clientes. Ou, se a
sua aplicação foi executada em VMs, utilize um conjunto de dimensionamento atrás de
um balanceador de carga para definir um perfil de redundância semelhante.
Experimente agora
Aqui é onde a sua própria localização regional importa! Se vive fora de um dos agrupa-
mentos regionais mostrados nos perfis do Traffic Manager, certifique-se de que sele-
ciona a sua própria região; caso contrário, não conseguirá aceder à aplicação Web no
laboratório de fim de capítulo.
Para associar os perfis subordinados ao perfil principal, conclua os passos seguintes:
1 No portal Azure, navegue e selecione o seu grupo de recursos.

2 Selecione o perfil do Traffic Manager principal. Nos exemplos anteriores, foi
denominado azuremol.
3 Escolha Endpoints na barra de navegação à esquerda no perfil e, em seguida,
selecione Adicionar.
4 Crie um endpoint que utiliza o primeiro perfil subordinado. Defina o tipo como
endpoint aninhado e forneça um nome, como eastus. Como recurso de destino,
selecione o perfil do Traffic Manager que criou para a região E.U.A. Leste.
5 Em Agrupamento Regional, escolha América do Norte/América Central/Caraí-
bas no menu pendente e selecione OK.
6 Repita os passos para adicionar outro endpoint. Desta vez, nomeie o endpoint
westeurope, defina recurso de destino para o perfil subordinado do Traffic
Manager para a Europa Ocidental e escolha Europa no menu pendente para o
agrupamento regional.
Agora os seus endpoints para o perfil principal listam os dois perfis subordina-
dos, cada um dos quais com um endpoint associado à região geográfica apro-
priada, conforme mostrado na figura 11.11.
Figura 11.11 Perfis subordinados aninhados com as regiões geográficas associadas. Este perfil principal do
Traffic Manager direciona todo o tráfego da Europa para a aplicação Web na Europa Ocidental, com redundância
para utilizar a região E.U.A. Leste se houver um problema. Para os clientes na América do Norte/América Central/
Caraíbas, o caso é o contrário.
As aplicações Web estão atualmente definidas para aceitar o tráfego apenas no
seu domínio predefinido, o qual está na forma de webappname.azurewebsites.net.
Quando o Traffic Manager direciona os clientes para essas instâncias de aplica-
ções Web, o tráfego parece vir do domínio do perfil principal, como azuremol.
trafficmanager.net. As aplicações Web não reconhecem este domínio, portanto, a
aplicação Web não será carregada.
7 Adicione o domínio do perfil principal do Traffic Manager a ambas as instân-
cias de aplicações Web criadas nos passos 4-6. Se necessário, pode encontrar o
nome do domínio na página Descrição Geral do perfil principal do Traffic
Manager:
az webapp config hostname add \
--webapp-name azuremoleastus \
--hostname azuremol.trafficmanager.net
az webapp config hostname add \
--webapp-name azuremolwesteurope \
--hostname azuremol.trafficmanager.net
Agora, quando abre o endereço do seu perfil principal do Traffic Manager num browser,
como https://azuremol.trafficmanager.net, you can’t tell which endpoint you access, as
both web apps run the same default web page. No laboratório de fim de capítulo, irá car-
regar uma página Web básica em cada aplicação Web para as diferenciar!
Vamos parar para examinar o que criou através destes exercícios. Isto é importante
porque agora os clientes podem utilizar todas as funcionalidades de elevada disponibi-
lidade e redundância dos capítulos anteriores, com o encaminhamento automático de
tráfego que os direciona para a instância mais próxima da sua aplicação Web. Neste
capítulo, criou o seguinte:
¡ Uma aplicação Web na região E.U.A. Leste e outra na Europa Ocidental
¡ Os perfis do Traffic Manager que utilizam o encaminhamento geográfico para
direcionar todos os clientes da América do Norte e Central para a aplicação Web
da região E.U.A. Leste e todos os clientes da Europa para a aplicação
Web da Europa Ocidental.
¡ As políticas subordinadas do Traffic Manager com encaminhamento prioritário
que facilita a utilização de uma ativação pós-falha da região alternativa se a aplica-
ção Web principal para a região não estiver disponível.
Em termos de elevada disponibilidade:

¡ Se combinar esta configuração com as aplicações Web que são dimensionadas
automaticamente, terá imensa redundância.
¡ Se combinar estas aplicações Web com o Cosmos DB, toda a aplicação será auto-
maticamente dimensionada e distribuída globalmente, com os clientes a acede-
rem sempre os recursos que estão próximos deles para a latência mais baixa em
tempos de resposta e melhor desempenho.
¡ Mesmo se ficar preso às VMs, poderá utilizar conjuntos de dimensionamento
com balanceadores de carga para oferecer o mesmo ambiente disponível e distri-
buído globalmente.
E sim, pode substituir o Traffic Manager pelo Front Door se precisar de utilizar funcio-
nalidades avançadas de gestão de tráfego ao nível da aplicação.
Sei que estes últimos capítulos contêm imensas novidades, e a leitura de cada capí-
tulo consumiu mais ou menos toda a hora do seu almoço todos os dias! Mas veja até
onde chegámos na última semana. Agora pode criar uma aplicação Web com
VMs IaaS ou aplicações Web PaaS, torná-las altamente disponíveis e balancear a sua
carga, além de permitir que sejam dimensionadas automaticamente (figura 11.12).
Pode utilizar um back-end do Cosmos DB globalmente distribuído para as suas necessi-
dades de bases de dados, e pode encaminhar automaticamente os clientes para a ins-
tância regional mais próxima da sua aplicação, todos com o DNS alojado no Azure.
Cliente
Internet
Azure Traffic
Azure DNS
Manager
Solução PaaS do Azure Solução IaaS do Azure

Este dos EUA Europa Ocidental Leste dos EUA 2 Europa Ocidental
Dimensionar Dimensionar Zonas de Disponibilidade Zonas de Disponibilidade
automatica- automatica-
mente a mente a ou Balanceador de carga Balanceador de carga
aplicação Web aplicação Web
Conjunto de Conjunto de
dimensionamen- dimensionamen-
Cosmos DB to de virtual to de virtual
machines machines
Figura 11.12 Após os últimos capítulos, deve entender como criar aplicações IaaS ou PaaS altamente disponíveis
no Azure. As soluções IaaS podem utilizar zonas de disponibilidade, balanceadores de carga e conjuntos de
dimensionamento. As soluções PaaS podem utilizar aplicações Web de dimensionamento automático e o Cosmos
DB. O Traffic Manager e o DNS do Azure podem encaminhar automaticamente os clientes para a instância de
aplicação mais apropriada, com base na sua localização geográfica.
O laboratório de fim de capítulo carrega alguns sites básicos para as suas aplicações
Web, apenas para provar que o Traffic Manager funciona e o endpoint apropriado pro-
videncia o seu tráfego. Se tiver tempo, vá em frente e faça o exercício. Caso contrário,
tire um tempo para si e faça uma sesta. Prometo que não digo ao seu chefe!
Temos mais um capítulo nesta segunda secção do livro, e fala sobre como pode certificar-
-se de que as suas aplicações permanecem em bom estado de funcionamento: como
monitorizar e resolver problemas das suas aplicações e infraestrutura.
11.4 Laboratório: implementar aplicações Web para ver o Traffic

Manager em ação
Este capítulo abordou muitas coisas; portanto, este exercício deve continuar a fortale-
cer o músculo mental das suas competências com o Azure e as aplicações Web. No
repositório GitHub de exemplos do Azure, há duas páginas Web básicas para a aplica-
ção da pizzaria online. O título de cada página Web mostra a localização da aplicação
Web. Carregue estas páginas Web na instância da aplicação Web relevante para ver os
fluxos do Traffic Manager na prática:
1 Se for necessário, clone o repositório de exemplos do GitHub no seu Cloud Shell

2 Comece pela página Web eastus e, em seguida, repita os seguintes passos no dire-
tório westeurope:
cd ~/azure-mol-samples-2nd-ed/11/eastus
3 Inicialize o repositório Git e adicione a página Web básica:

4 No portal Azure, a janela Descrição Geral da sua aplicação Web lista o URL de
clonagem do Git. Copie este URL e, em seguida, defina-o como um destino para
o seu site HTML de exemplo no Cloud Shell com o seguinte comando:
git remote add eastus <your-git-clone-url>
5 Emita o site HTML de exemplo via push para a sua aplicação Web:
git push eastus master
6 Repita estes passos para o diretório azure-mol-samples-2nd-ed/11/westeurope.

7 Quando terminar, abra o seu browser no nome de domínio do seu perfil princi-
pal do Traffic Manager, tal como https://azuremol.trafficmanager.net, to see the
traffic flow.
12
Monitorizção e resolução de
problemas
Nos capítulos anteriores, aprendeu a tornar as suas aplicações altamente disponíveis

e a encaminhar clientes de todo o mundo para instâncias globalmente distribuídas
da sua aplicação. Um objetivo era minimizar a quantidade de interação com a sua
infraestrutura de aplicação e deixar a plataforma do Azure gerir o estado de funcio-
namento e o desempenho por si. Às vezes, ainda precisa de arregaçar as mangas e
examinar o diagnóstico ou as métricas de desempenho. Neste capítulo, irá aprender
a examinar o diagnóstico de arranque para uma VM, a monitorizar métricas de
desempenho e a resolver problemas de conectividade com o Observador de Rede.
12.1 Diagnóstico de arranque de VMs

Com as aplicações Web, implementa o seu código e deixa que a plataforma Azure
cuide do resto. No capítulo 3, examinámos as noções básicas resolução e diagnós-
tico de problemas com as implementações de aplicações Web. Aprendeu a ver even-
tos de aplicações em tempo real para monitorizar o desempenho. Quando trabalha
com VMs na cloud, muitas vezes é difícil resolver um problema quando não pode
ver fisicamente o ecrã do computador, para que possa obter um diagnóstico da apli-
cação Web.
Um dos problemas mais comuns com as VMs é a falta de conectividade. Se não
pode utilizar SSH ou RDP numa VM, como pode resolver o problema? Uma das pri-
meiras coisas que pode querer verificar é se a VM está a ser executada corretamente.
Para ajudá-lo neste aspeto, o Azure fornece o diagnóstico de arranque da VM que
inclui registos de arranque e uma captura de ecrã da consola.
175
176 Capítulo 12 Monitorizção e resolução de problemas
Acesso interativo à consola de arranque

Em cenários de resolução de problemas específicos, pode aceder a uma consola de
série em direto para as VMs no Azure. Esta consola de série permite inícios de sessão
interativos e resolução de problemas em caso de problemas de arranque. Pode reconfi-
gurar a sua VM para corrigir cenários de arranque com falha ou configurações incorretas
de serviços e aplicações que impedem que a sua VM arranque corretamente.
Neste capítulo, não entramos em cenários específicos para a utilização da consola
de série, mas é um excelente recurso que lhe permite sentar-se praticamente à frente
do ecrã de uma VM quando esta arranca. Também precisa de ter o diagnóstico de arran-
que ativado, por isso, estes exercícios são pré-requisitos para a consola de série.
Experimente agora
Para criar uma VM e ativar o diagnóstico de arranque, conclua os passos seguintes:
1 No portal Azure, selecione Criar um Recurso, no canto superior esquerdo.

2 Procure e selecione uma imagem VM do Datacenter do Windows Server 2019.
3 Crie um grupo de recursos, como azuremolchapter12, e, em seguida, selecione
a região do Azure apropriada mais próxima de si.
4 Selecione um tamanho de VM, como DS1_v2.
5 Introduza um nome de utilizador para o VM, como azuremol, e uma senha.
A palavra-passe deve ter um mínimo de 12 carateres e conter 3 dos seguintes ele-
mentos: um caráter minúsculo, um caráter maiúsculo, um número e um caráter
especial.
6 Aceite quaisquer opções de redundância ou regras de portas de entrada.
7 Aceite as predefinições dos discos e da rede; não precisa de alterar nada. Essas
definições já lhe devem ser familiares.
Uma coisa que pode ter ignorado anteriormente foi a secção Gestão. Como
mostrado na figura 12.1, a opção de diagnóstico de arranque está ativada por pre-
definição e é criada uma conta de armazenamento.
8 Por enquanto, deixe a opção de diagnóstico do SO convidado desativada.
9 Reveja as definições de configuração de VM e selecione Criar.
Leva alguns minutos a criar e configurar a VM, por isso vamos continuar a explorar o
diagnóstico de arranque.
Se não tiver o diagnóstico de arranque ativado, mas tiver um problema, provavel-
mente não poderá arrancar a VM para ativar o diagnóstico. É o cenário clássico da gali-
nha e do ovo, não é? Como resultado, o diagnóstico de arranque é ativado
automaticamente para as VMs criadas no portal Azure. Para o Azure PowerShell,
o Azure CLI e os SDKs específicos de linguagem, precisa de ativar
Diagnóstico de arranque de VMs 177
Figura 12.1 Por predefinição, o diagnóstico de arranque está ativado quando cria
uma VM no portal Azure. É criada uma conta de armazenamento; o diagnóstico de
arranque é armazenado nesta conta. Num exercício posterior, irá examinar e ativar o
diagnóstico do SO convidado; por isso, não o ative agora. Para utilização em ambientes
de produção, recomendo que ative o diagnóstico de arranque e o diagnóstico do SO
convidado para cada VM criada.
diagnóstico de arranque. Recomendo vivamente que ative o diagnóstico de arranque

nas suas VMs quando as criar. Habitue-se a utilizar modelos do Azure Resource Mana-
ger (capítulo 6) ou os seus próprios scripts do Azure CLI ou do PowerShell que permi-
tam a realização de diagnósticos de arranque durante a implementação.
Precisa de criar uma conta de armazenamento para os registos de arranque e captu-
ras de ecrã da consola, mas o custo para armazenar estes dados é provavelmente menor
do que 0,01 $ por mês, a menos que tenha uma VM muito solicitada que gere muitos
dados. Da primeira vez que tiver um problema numa VM e precisar de acesso ao diag-
nóstico de arranque, este cêntimo por mês vai valer a pena! Esta conta de armazena-
mento também pode ser utilizada para armazenar métricas e registos de desempenho
adicionais ao nível da VM, os quais iremos examinar na secção 12.2. Mais uma vez, os
custos de armazenamento devem ser mínimos. Mesmo que o seu ambiente de VM
cresça, vale a pena investir esse pequeno custo adicional para que possa resolver
rapidamente um problema caso ocorra.
Experimente agora
Para ver o diagnóstico de arranque para a sua VM, conclua os passos seguintes:
1 No portal Azure, selecione Virtual Machines, no menu à esquerda.

2 Escolha a VM que criou no exercício anterior.
3 Na secção Suporte + Resolução de Problemas do menu VM, escolha Diagnóstico
de Arranque. O diagnóstico de arranque e o estado da VM são apresentados,
como mostrado na figura 12.2. O relatório do estado de funcionamento indica
qualquer problema de arranque com a VM e permite-lhe fazer o diagnóstico da
causa raiz do problema.
Figura 12.2 O diagnóstico de arranque de uma VM reporta o estado de funcionamento e o estado

do arranque. Se forem apresentados erros, deve poder resolver problemas e diagnosticar a causa raiz.
Também pode fazer download dos registos do portal para análise no seu computador local.
12.2 Métricas de desempenho e alertas

Um dos primeiros passos para resolver um problema é uma análise do desempenho.
Quanta memória está disponível, quanta CPU é consumida e quanta atividade de
disco existe?
À medida que cria e testa as suas aplicações no Azure, recomendo que registe linhas
de base de desempenho em vários pontos. Estas linhas de base dão-lhe uma ideia do
desempenho da sua aplicação com diferentes quantidades de carga. Por que é isso
importante? Em três meses, como pode determinar se encontrará problemas de desem-
penho se não tiver dados para comparar o desempenho atual?
Quando aprendeu a dimensionar automaticamente as aplicações no capítulo 9, utili-
zou métricas de desempenho básicas, como a utilização da CPU, para informar a plata-
forma do Azure sobre quando aumentar ou diminuir o número de instâncias da sua
aplicação. Estas métricas básicas dão-lhe apenas alguns insights sobre a operação da
VM. Para métricas mais detalhadas,é necessário observar o desempenho da VM e, para
isso, é necessário instalar a extensão de diagnóstico do Azure.
12.2.1 Ver métricas de desempenho com a extensão de diagnóstico da VM

Para adicionar funcionalidades às suas VMs, o Azure tem dezenas de extensões que
pode instalar facilmente. Estas extensões instalam um pequeno agente ou runtime da
aplicação na VM que, frequentemente, reporta as informações para a plataforma do
Azure ou para soluções de terceiros. As extensões de VM podem automaticamente
configurar e instalar componentes ou executar scripts nas suas VMs.
Métricas de desempenho e alertas 179
A extensão de diagnóstico da VM é uma extensão comum utilizada para transmitir

métricas de desempenho da VM para uma conta de armazenamento. Estas métricas de
desempenho podem, então, ser analisadas no portal Azure ou utilizadas numa solução
de monitorização existente. Também pode ser feito o download das mesmas. Pode utili-
zar a extensão de diagnóstico para obter uma compreensão mais detalhada do desem-
penho de CPU e do consumo de memória da VM, que normalmente pode fornecer
uma imagem mais detalhada e precisa do que o host.
Automation e extensões de VM
No capítulo 18, iremos abordar a Automation do Azure, a qual permite realizar tarefas
nas suas VMs de forma automatizada e agendada. Uma funcionalidade poderosa da
Automation do Azure é a capacidade de atuar como um servidor de extração da Desired
State Configuration (DSC) do PowerShell. O PowerShell DSC define um determinado
estado de como um sistema deve ser configurado, quais pacotes devem ser instalados,
ficheiros e permissões, e assim por diante. Cria definições para a configuração preten-
dida e aplica-as às VMs ou aos servidores físicos. Em seguida, pode reportar e impor a
conformidade com essas políticas. A extensão DSC do Azure PowerShell é utilizada para
aplicar configurações DSC, tais como de um servidor de extração de Auto-
matização do Azure.
Outras extensões que podem aplicar configurações e executar scripts em VMs incluem a
Extensão de Script Personalizado do Azure. Com a Extensão de Script Personalizado,
define um conjunto simples de comandos ou aponta para um ou mais scripts externos,
como os alojados no Armazenamento do Azure ou no GitHub. Estes scripts podem exe-
cutar tarefas complexas de configuração e instalação e garantir que todas as VMs imple-
mentadas sejam consistentemente configuradas.
A extensão DSC do Azure PowerShell e a Extensão de Script Personalizado são geralmente
utilizadas com conjuntos de dimensionamento de máquinas virtuais. Aplica uma destas
extensões ao conjunto de dimensionamento e, como as instâncias de VM são criadas den-
tro do conjunto de dimensionamento, são configuradas automaticamente para executar a
sua aplicação. O objetivo destas extensões é minimizar a configuração manual necessária
de VMs, que é um processo propenso a erros que requerem interação humana.
Outras formas de automatizar as configurações de VM incluem Puppet e Chef, ambos
com extensões de VM do Azure disponíveis. Se já estiver a utilizar uma ferramenta de
configuração e gestão, verifique se o fornecedor oferece suporte ao Azure. Há uma
boa possibilidade de que uma extensão da VM estar disponível para facilitar a sua vida.
Experimente agora
Para ativar a extensão de diagnóstico da VM, conclua os passos seguintes:
1 No portal Azure, escolha Virtual Machines no menu à esquerda.

2 Escolha a VM que criou num exercício anterior.
3 Na secção Monitorização do menu VM, escolha Definições de Diagnóstico.
4 Selecione o botão para ativar a monitorização ao nível do convidado.
Leva alguns minutos a ativar a monitorização ao nível do convidado. Veja o que

o Azure faz em segundo plano:
¡ Instala a extensão de diagnóstico da VM
¡ Configura a extensão para transmitir métricas ao nível do convidado para
as seguintes áreas:
– Disco lógico
– Memória
– Interface de rede
– Processo
– Processador
– Sistema
– Permite a transmissão de registos da aplicação, de segurança e do sistema para
o Azure Storage
Após a extensão de diagnóstico ser instalada, pode limitar quais dados são recolhidos,
selecionando apenas determinados contadores de desempenho para reportar. Pode
pretender recolher apenas a utilização da memória, por exemplo, ou ativar a recolha
de métricas do Microsoft SQL Server. Por predefinição, as métricas são recolhidas a
cada 60 segundos. Pode ajustar esta taxa de amostragem conforme pretendido para as
suas aplicações e infraestrutura.
A extensão de diagnóstico de VM também pode transmitir ficheiros de registo a par-
tir da sua VM, permitindo-lhe centralizar os registos de aplicação, segurança e sistema
para análise ou alertas, como mostrado na figura 12.3. Por predefinição, os registos da
aplicação ou sistema que geram alertas Crítico, com Erro ou Aviso são registados, junta-
mente com os eventos de Erros de Auditoria. Pode alterar os níveis de registo para ati-
var a recolha de registos a partir dos registos de IIS e de aplicações e para eventos de
Rastreio de Eventos para o Windows (ETW). Como parte do planeamento e implemen-
tação da aplicação, determine quais registos pretende recolher.
As VMs Windows não têm nada de exclusivo. Pode utilizar da mesma forma a exten-
são de diagnóstico em VMs Linux para obter métricas de desempenho e transmitir
vários registos.
Se a sua VM encontrar um problema, muitas vezes a única maneira de analisar o que
aconteceu é analisando as informações de falha de sistema. Muitas vezes, os canais de
suporte pedem estas informações de falha se pretender chegar à causa raiz de um pro-
blema. Tal como com o diagnóstico de arranque, não há nenhuma maneira de ativar
retroativamente as informações de falha de sistema para ver por que algo falhou, por
isso determine se precisa de monitorizar determinados processos e seja pró-ativo sobre
como configurar as informações de falha. Pode, por exemplo, monitorizar o processo
do IIS e registar uma informação de falha de sistema completa no Azure Storage, se o
processo falhar.
Aqui estão algumas outras áreas que pode configurar para as métricas de convidado:
¡ Sinks permitem-lhe configurar a extensão de diagnóstico da VM para enviar deter-
minados eventos para o Azure Application Insights. Com o Application Insights,
pode obter visibilidade diretamente em como o seu código é executado.
¡ Agente permite-lhe especificar uma quota de armazenamento para todas as suas
métricas. (A predefinição é de 5 GB.) Também pode ativar a recolha de registos
para o próprio agente ou desinstalar o agente.
Métricas de desempenho e alertas 181
Figura 12.3 Pode configurar eventos e níveis de registo para vários componentes na VM. Esta
funcionalidade permite-lhe centralizar os seus registos da VM para análise e gerar alertas. Sem a
necessidade de instalar sistemas de monitorização complexos e, muitas vezes, dispendiosos, pode
analisar e receber notificações quando surgem problemas nas suas VMs do Azure.
Experimente agora
Para ver as métricas ao nível do convidado, conclua os passos seguintes:
1 No portal Azure, escolha Virtual Machines no menu à esquerda.

2 Escolha a VM que criou num exercício anterior.
3 Na secção Monitorização do menu VM, escolha Métricas.
Muitas mais métricas estão agora disponíveis, em comparação com as métricas básicas
baseadas no host do capítulo 9. Explore algumas das métricas para host da VM e convi-
dados disponíveis e pense em algumas aplicações para as quais possa querer monitori-
zar métricas específicas.
12.2.2 Criar alertas para condições de desempenho

Com a sua VM configurada para expor métricas de desempenho ao nível de convidado,
como sabe quando há um problema? Não quer ficar sentado a olhar para os gráficos do
desempenho em tempo real e esperar que ocorra um problema! Não sou o seu chefe, se
é isso que o preocupa. Mas, há uma maneira muito melhor: alertas de métrica.
Alertas de métrica permitem-lhe selecionar um recurso, uma métrica e um limiar e, em

seguida, definir quem e como pretende notificar quando esse limiar é atingido. Além
das VMs, podem ser utilizados alertas com mais elementos. Pode definir alertas em
endereços IP públicos que detetam pacotes de denial of service (DDoS) distribuídos de
entrada, por exemplo, e avisá-lo quando for atingido um determinado limiar que pode-
ria constituir um ataque.
Quando os alertas são gerados, pode optar por enviar uma notificação aos proprietá-
rios, contribuintes e leitores. Estes utilizadores e endereços de e-mail são obtidos com
base nas políticas RBAC aplicadas. Em organizações maiores, os alertas poderiam enviar
notificações por e-mail a um grande grupo de pessoas; por isso tenha com cuidado!
Outra opção é especificar os endereços de e-mail, que podem ser os proprietários de
aplicações ou engenheiros de infraestrutura específicos, ou uma lista de distribuição ou
grupo direcionado para as partes diretamente envolvidas.
Existem outras opções úteis ao executar uma ação quando um alerta é acionado:
¡ Execute um runbook. No capítulo 18, examinaremos a Automation do Azure. O ser-
viço de Automation permite-lhe criar e utilizar runbooks que executam scripts.
Estes scripts podem executar uma ação de correção básica na VM, como reiniciar
um processo ou até mesmo reiniciar a VM. Também podem executar cmdlets do
Azure PowerShell para ativar as funcionalidades do Observador de Rede do
Azure, como pacotes de captura, que iremos explorar no restante deste capítulo.
¡ Executar uma aplicação lógica. As aplicações lógicas do Azure permitem-lhe criar
workflows que executam um código sem servidor. Pode escrever informações
num sistema de pedidos de suporte ou iniciar uma chamada telefónica automati-
zada para um engenheiro de serviço permanente. No capítulo 21, iremos explo-
rar o maravilhoso mundo da computação sem servidor com as aplicações lógicas
do Azure e as funções do Azure.
No laboratório de fim de capítulo, irá configurar alguns alertas para a sua VM. O Azure
pode fazer mais do que ajudar a resolver problemas e monitorizar as suas VMs. Vamos
falar agora de outra causa comum para que as coisas corram mal: a rede.
12.3 Observador de Rede do Azure

As métricas de desempenho da VM e os diagnósticos de arranque são ótimas maneiras de
monitorizar as suas aplicações IaaS do Azure. Os registos de aplicações Web e o App Insi-
ghts fornecem uma conscientização sobre o desempenho das suas aplicações PaaS. Muitas
vezes, o tráfego de rede é menos glamouroso, mas é mais provável que seja a causa dos
problemas de conectividade de aplicações que você ou os seus clientes encontram.
No capítulo 5, brinquei com o facto de a equipa de rede ser sempre culpada pelos pro-
blemas que a equipa de operações não consegue explicar. Aqui é onde podemos tentar
fazer amigos novamente, ou pelo menos obter alguma prova sólida de a rede ser a cul-
pada! O Observador de Rede do Azure é uma dessas funcionalidades que ajuda a unir os
membros de várias equipas num agradável abraço comunitário. Com o Observador de
Rede, pode monitorizar e resolver problemas utilizando funcionalidades como estas:
¡ Capturar pacotes de rede
¡ Validar o fluxo de IP para NSGs
¡ Gerar topologia de rede
O melhor destas funcionalidades é que colocam equipas diferentes no comando para
resolverem problemas. Se criar algumas VMs e não conseguir ligar-se às mesmas,
Observador de Rede do Azure 183
poderá verificar se há conectividade de rede. Para os programadores, se a sua aplica-

ção não conseguir estabelecer ligação ao escalão de base de dados de back-end, pode
examinar as regras do NSG para ver se há um problema. E os engenheiros de rede
podem capturar pacotes para examinar o fluxo de comunicação completo entre hosts
para uma análise mais aprofundada.
Resolução de problemas adicionais de rede

O Observador de Rede funciona em conjunto com os registos e métricas de diagnóstico
discutidos anteriormente no capítulo. Os recursos de rede, como os balanceadores de
carga e gateways da aplicação também podem gerar registos de diagnóstico. Estes
registos funcionam da mesma forma que os registos da aplicação e do sistema a partir
de uma VM ou aplicação Web. Os registos são agrupados no portal Azure para que deter-
mine se há erros na configuração ou nas comunicações entre os hosts e as aplicações.
O DNS e o Traffic Manager também têm uma área para Resolução de Problemas, no
portal Azure. O portal orienta-o através de alguns erros comuns que pode encontrar,
oferece conselhos de configuração e fornece ligações para documentação adicional.
Se tudo o resto falhar, pode abrir um pedido de suporte com o Suporte do Azure.
Embora possa ser mais fácil criar implementações de aplicações de grande dimensão
com os modelos do Azure Resource Manager ou com os scripts do Azure CLI ou do
PowerShell, o portal Azure tem muitas ferramentas e excelentes funcionalidades quando
ocorrem problemas. Com apenas alguns segundos dedicados à análise dos resultados
das ferramentas do Observador de Rede, pode identificar um problema e resolvê-lo rapi-
damente, especialmente com configurações de rede complicadas e políticas de segu-
rança. Todas estas ferramentas ajudam a melhorar o estado de funcionamento geral e a
experiência das suas aplicações para os seus clientes.
Quais são alguns cenários nos quais convém utilizar o Observador de Rede e as funcio-
nalidades de resolução de problemas que o mesmo oferece? Vejamos alguns proble-
mas comuns e vejamos como o Observador de Rede pode ajudar.
12.3.1 Verificar os fluxos de IP

Aqui está um problema comum: os clientes não conseguem estabelecer ligação à sua
aplicação. A aplicação funciona bem quando estabelecer a ligação a partir do escritório,
mas os clientes não conseguem aceder à aplicação através da Internet pública. Porquê?
VPNs e ExpressRoute
As VPNs (redes privadas virtuais) do Azure fornecem comunicações seguras entre os escri-
tórios on-premises e os datacenters do Azure. O Azure ExpressRoute fornece ligações pri-
vadas de alta velocidade e dedicadas a partir de escritórios on-premises para os
datacenters do Azure e é frequentemente utilizado em organizações de grande dimensão.
Ambas as ligações são um pouco mais complicadas para configurar o que podemos cobrir
em apenas uma hora durante o almoço e, muitas vezes, são coisas que só se configuram
uma vez. A equipa de rede é, normalmente, responsável pela sua configuração e pode
nem mesmo aperceber-se de que está a aceder ao Azure através de uma ligação privada.
Todos os testes da sua aplicação funcionam muito bem. Pode aceder à aplicação atra-
vés de um browser, fazer pedidos e receber notificações por e-mail. Mas quando os seus
clientes tentam fazer um pedido, a aplicação não carrega.
Como é que o Observador de Rede pode ajudar? Através da verificação dos fluxos de
IP. O Observador de Rede simula o fluxo de tráfego para o seu destino e reporta se o
tráfego pode alcançar a sua VM.
Experimente agora
Para ativar o Observador de Rede e verificar os fluxos de IP, conclua os passos seguintes:
1 No portal Azure, selecione Todos os Recursos na parte superior do menu de

navegação à esquerda.
2 Filtre e selecione Observador de Rede na lista de serviços disponíveis. Ativa o
Observador de Rede na(s) região(ões) que pretende monitorizar. Quando ativa
o Observador de Rede numa região, o Azure utiliza controlos de acesso baseados
em funções para os vários recursos e o tráfego de rede.
3 Aumente a lista de regiões para a sua conta. Algumas regiões podem já estar ati-
vadas. Se a região em que a sua VM foi implantada não estiver ativada, selecione
a região e , em seguida, ative o observador de rede.
4 Quando o Observador de Rede estiver ativado numa região (demora um minuto
ou dois), selecione Verificação de Fluxo de IP em Ferramentas de Diagnóstico de
Rede no lado esquerdo da janela do Observador de Rede.
5 Selecione o grupo de recursos, como azuremolchapter12, e a VM, como
molvm. Por predefinição, o Protocolo é definido como TCP e a Direção como
Entrada. O Endereço IP Local da NIC virtual também é preenchido.
6 Em Porta Local, introduza a porta 80. Se tiver aceite as predefinições quando
criou a VM no exercício anterior, não abriu a porta 80 e, por isso, este é um bom
teste do que acontece quando o tráfego é negado.
7 Em Endereço IP Remoto, introduza 8.8.8.8. Este endereço pode parecer fami-
liar: é um servidor DNS aberto fornecido pelo Google. Não está a fazer nada com
este servidor; só precisa de fornecer ao Observador de Rede um endereço IP
externo para simular o fluxo de tráfego. Também pode aceder a https://whats-
myip.com e introduzir o seu endereço IP público real.
8 Defina Porta Remota como a porta 80 e, em seguida, selecione Verificar.
O resultado da verificação de fluxo de IP deve ser Acesso negado. Felizmente, o Observa-
dor de Rede diz-lhe qual a regra que causou a falha do fluxo de tráfego: a regra
DenyAllInBound. Sabe que há uma regra de segurança de rede que bloqueia o tráfego,
mas onde é que esta regra é aplicada? Na sub-rede, na NIC virtual ou no grupo de segu-
rança de aplicações? Outra funcionalidade do Observador de Rede pode indicar-lhe isso!
12.3.2 Ver regras do NSG efetivas

As regras do NSG podem ser aplicadas a uma única NIC virtual, ao nível de sub-rede,
ou a um grupo de VMs num grupo de segurança de aplicações. As regras são combina-
das, o que permite especificar um conjunto comum de regras numa sub-rede inteira e,
em seguida, ser-se mais específico para os grupos de segurança de aplicações (como
“Permitir a porta TCP 80 em todos os servidores Web”) ou para uma VM individual.
Aqui estão alguns exemplos comuns de como as regras do NSG podem ser aplicadas:
¡ Nível de sub-rede—Permitir a porta TCP 5986 para uma gestão remota segura a par-
tir da sub-rede de gestão 10.1.10.20/24.
¡ Nível do grupo de segurança de aplicações —Permitir a porta TCP 80 para o tráfego
HTTP para as aplicações Web e aplicar o grupo de segurança de aplicações a
todas as VMs de aplicações Web.
¡ Nível da NIC virtual—Permitir a porta TCP 3389 para acesso ao ambiente de traba-
lho remoto a partir da sub-rede de gestão 10.1.10.20/24.
Estas regras são básicas e permitem explicitamente um determinado tráfego. Se
nenhuma regra de permissão corresponderem a um pacote de rede, serão aplicadas
regras predefinidas DenyAll para interromper o tráfego.
Durante o teste realizado na aplicação analisado no exemplo, pode ter configurado
essa regra HTTP para permitir apenas o tráfego proveniente de uma das suas sub-redes
on-premises. Agora, os clientes que acedem através da Internet pública não conseguem
estabelecer a ligação.
Experimente agora
Para determinar onde uma regra do NSG é aplicada, conclua os passos seguintes:
1 No Observador de REde, selecione regras de segurança eficazes à esquerda.

2 Selecione o grupo de recursos, como azuremolchapter12, e a sua VM, como
molvm. Leva alguns segundos até as regras efetivas serem apresentadas, como
Figura 12.4 Quando seleciona uma VM, o Observador de Rede examina como todas as regras do NSG
são aplicadas e a ordem de precedência, e mostra quais regras efetivas estão aplicadas no momento.
Em seguida, pode explorar em detalhe a sub-rede, a NIC virtual e as regras predefinidas para localizar
e editar onde uma determinada regra é aplicada.
As regras predefinidas da VM que criou anteriormente não são empolgantes, mas pode
percorrer a sub-rede, a interface de rede e as regras predefinidas para obter uma sen-
sação de como as regras efetivas são combinadas e como pode identificar onde as
regras são aplicadas se precisar de efetuar alterações.
12.3.3 Capturar pacotes de rede

Vamos partir do princípio de que atualizou as suas regras de segurança de rede para
permitir o acesso à sua aplicação pelos clientes através da Internet pública, mas um
cliente reporta que se está a deparar com um comportamento incomum. Às vezes, a
aplicação Web não carrega ou apresenta imagens interrompidas. Parece que a sua liga-
ção excede o tempo limite com frequência.
Os problemas intermitentes são frequentemente os mais difíceis de resolver, espe-
cialmente se tem acesso limitado ou inexistente ao computador no qual é encontrado
um problema. Uma abordagem comum de resolução de problemas é capturar os paco-
tes de rede e analisá-los para obter sinais de problemas, como erros de transmissão de
rede, pacotes incorretamente formados ou problemas de protocolo e comunicação.
Com as capturas de pacotes de rede, irá obter o fluxo de dados não processados
entre dois ou mais hosts. É uma arte analisar capturas de rede, e não é apto para cardía-
cos! Ferramentas especiais de terceiros, como Wireshark da Riverbed, Fiddler da Tele-
rik e Microsoft
Figura 12.5 Uma captura de pacotes de rede quando vista no Message Analyzer da Microsoft. Cada
pacote individual está disponível para inspeção. Pode agrupá-los e filtrá-los por meio de um protocolo
de comunicação ou cliente-host. Essa profundidade de dados da rede permite examinar os pacotes reais
que fluem entre os nós para resolver problemas quando ocorrer um erro. Um ex-colega disse-se uma vez:
“os pacotes nunca mentem”. O puzzle consiste em averiguar o que dizem.
O Message Analyzer fornece uma forma gráfica de visualizar e filtrar os pacotes de

rede, normalmente agrupando-os através de comunicações ou protocolos relaciona-
dos. A figura 12.5 mostra um exemplo de captura de pacotes de rede.
Para ativar o Observador de Rede para capturar pacotes de e para as suas VMs, pri-
meiro instale a extensão da VM do Observador de Rede. Como vimos na secção 12.3.2,
as extensões da VM oferecem uma maneira de a plataforma do Azure aceder à parte
interna de uma VM para executar várias tarefas de gestão. No caso da extensão da VM
do Observador de Rede, examina o tráfego de rede de e para a VM.
Experimente agora
Para instalar a extensão da VM do Observador de Rede e capturar pacotes de rede,
conclua os passos seguintes:
1 No portal Azure, escolha Virtual Machines a partir do menu à esquerda e sele-

cione a sua VM, como molvm.
2 Na categoria Definições, à esquerda na janela VM, selecione Extensões.
3 Escolha Adicionar uma Extensão.
4 Na lista de extensões disponíveis, escolha Agente do Observador de Rede para o
Windows e, em seguida, selecione Criar.
5 Para confirmar a instalação da extensão, selecione OK. Pode levar alguns minu-
tos a instalar o Agente do Observador de Rede na sua VM.
6 Para voltar ao menu do Observador de Rede no portal Azure, escolha Todos os
Recursos na parte superior do menu de navegação Serviços, à esquerda no portal
e escolha Observador de Rede.
7 Na secção Ferramentas de Diagnóstico de Rede, à esquerda na janela do Observador
de Rede, selecione Captura de Pacotes e escolha Adicionar uma Nova Captura.
8 Selecione o seu grupo de recursos, como azuremolchapter12, e a sua VM, como
molvm; em seguida, introduza um nome para a captura do seu pacote, como
molcapture.
Por predefinição, as capturas de pacotes são guardadas no Azure Storage. Tam-
bém pode escolher guardar no ficheiro e especificar um diretório local na VM de
origem. A extensão do Agente do Observador de Rede escreve o ficheiro de cap-
tura de pacotes no disco da VM.
9 Se ainda não estiver selecionada, escolha o nome da conta de armazenamento
que começa pelo nome do seu grupo de recursos, como azuremolchapter-
12diag493. Esta é a conta de armazenamento criada e utilizada pela extensão de
diagnóstico da VM que ativou anteriormente.
10 Pode especificar um tamanho máximo para cada pacote (a predefinição é 0 para
todo o pacote), o tamanho máximo do ficheiro para a sessão de captura de paco-
tes (a predefinição é de 1 GB) e o tempo limite para a captura do pacote (a pre-
definição é de 5 horas). Para capturar apenas o tráfego a partir de fontes ou
portas específicas, também pode adicionar um filtro para restringir o âmbito das
suas capturas de pacotes.
11 Defina um tempo limite de 60 segundos.
12 Para iniciar a captura do pacote, selecione OK.
Leva um minuto ou dois a iniciar a captura. Quando a captura estiver em curso, os dados
são transmitidos para a conta do Azure Storage ou para o ficheiro local na VM. A lista de
capturas é mostrada na página do portal do Observador de Rede. Se transmitir os regis-
tos para o Azure Storage, poderá fazer com que a captura vá diretamente para a conta do
Armazenamento e fazer download do ficheiro de captura .cap. Em seguida, pode abrir a
captura de pacotes num programa de análise, conforme abordado na secção 12.3.3. Na
verdade, a captura de rede de exemplo mostrada na figura 12.5, anteriormente neste
capítulo, é de uma captura de um pacote do Observador de Rede do Azure!
12.4 Laboratório: criar alertas de desempenho

Espero que as funcionalidades de diagnóstico da VM, as métricas e o Observador de Rede
da VM, abordadas neste capítulo, lhe tenham fornecido alguns insights sobre o que está
disponível no Azure para resolver problemas relacionados com aplicações. Alguns elemen-
tos, tais como o diagnóstico de arranque e a extensão de diagnóstico da VM, fazem mais
sentido quando são ativados e configurados durante a implementação das VMs.
Neste laboratório, irá configurar alguns alertas de métrica para ver
sobre o que pode ser notificado e como são os alertas quando os recebe:
1 No portal Azure, navegue para a VM que criou nos exercícios anteriores.

2 Na secção Monitorização da VM, selecione Alertas.
3 Escolha criar uma regra de alerta e, em seguida, adicione uma condição para
quando a percentagem de CPU for superior a uma média de 10% nos últimos 5
minutos. Um gráfico deve mostrar quais são as métricas mais recentes; por isso
ajuste o limiar, se 10% não acionar um alerta.
4 Adicione um grupo de ação e atribua-lhe um nome e um nome abreviado. Para
este laboratório, defina os dois nomes como azuremol. Os grupos de ação permi-
tem-lhe definir conjuntos reutilizáveis de passos para realizar quando um é
gerado, como um e-mail enviado a um conjunto de utilizadores ou executar um
script PowerShell automatizado ou uma Azure Logic App.
5 Explore os tipos de ação disponíveis e, em seguida, selecione E-mail/SMS/
Push/Voz.
6 Escolha como deseja ser notificado, por exemplo, por e-mail ou mensagem de
texto. Podem ser aplicadas tarifas de operadoras às notificações SMS ou de voz.
7 Quando o grupo de ação for criado, dê ao alerta um nome e, em seguida, especi-
fique gravidade. Esta gravidade é útil quando tem muitos alertas definidos para
ajudá-lo a triar e a priorizar o que resolver primeiro.
8 Crie a regra quando tiver tudo pronto. Leva 10 a 15 minutos para que a regra
fique ativa e gere as notificações que definiu.
Este exemplo é básico, por isso pense em quaisquer alertas e notificações existentes
que tenha para aplicações e serviços e como poderia utilizar esta funcionalidade
quando executar workloads no Azure.
Parte 3
Seguro por predefinição
N um mundo online no qual as aplicações costumam ser ligadas à Internet

dia e noite, a ameaça de um ataque digital é muito real. Estes ataques custam em
termos de tempo, dinheiro e confiança do cliente. Uma parte central da criação
de aplicações altamente redundantes e distribuídas inclui a proteção das mesmas
e a proteção dos seus dados. O Azure possui várias funcionalidades incorporadas
para proteger os seus dados, incluindo a encriptação, o key vault digital e as
cópias de segurança. Nesta parte do livro, aprende a proteger e a manter as suas
aplicações protegidas desde o início.
13
Cópia de segurança, recuperação
e replicação
Os próximos capítulos introduzem algumas das funcionalidades e serviços core do

Azure que lhe permitem criar segurança para as suas aplicações. Isso é provavel-
mente muito subjetivo: a segurança não deve ser uma funcionalidade ou uma consi-
deração suplementar. Em vez disso, a segurança deve ser inerentemente incorporada
no cerne da aplicação desde o início. Neste capítulo, irá iniciar a sua jornada na
segurança do Azure com a realização de cópias de segurança e a recuperação os
seus dados. As cópias de segurança podem não parecer um tópico de segurança
comum, mas pense na segurança como sendo mais do que a encriptação de dados
ou os certificados SSL de sites. E em relação à proteção dos seus dados contra inter-
rupções do serviço, perdas de dados ou ataques de hackers? As cópias de segurança
e a replicação também são assuntos importantes para estabelecer a ponte entre o
capítulo sobre a elevada disponibilidade e o presente capítulo.
As cópias de segurança podem parecer um tanto triviais. Obviamente, que como
ex-administrador responsável pelas cópias de segurança, garanto que as tarefas e
rotações envolvidas não são empolgantes! No entanto, é essencial ter cópias de segu-
rança realmente funcionais para proteger as suas aplicações e garantir que, se o pior
acontecer, consegue restaurar os dados de maneira rápida e fiável. Também pode
replicar as suas VMs de uma região do Azure para outra. Esta capacidade baseia-se
nos conceitos de elevada disponibilidade que vimos anteriormente no capítulo 7.
Neste capítulo, irá aprender a fazer cópias de segurança e a restaurar VMs e, em
seguida, a replicar VMs automaticamente no Azure. Todas estas cópias de segurança
e pontos de restauração são encriptados para proteger os seus dados.
13.1 Azure Backup

Um dos aspetos interessantes sobre o Azure Backup é que é um serviço e um grande
registo de armazenamento no qual as cópias de segurança podem ser armazenadas.
O Azure Backup pode proteger VMs no Azure, VMs on-premises ou servidores físi-
cos, e até mesmo VMs em outros fornecedores, como o Amazon Web Services
(AWS). As cópias de segurança dos dados podem ser armazenados nas suas próprias
191
192 Capítulo 13 Cópia de segurança, recuperação e replicação
matrizes de armazenamento on-premises ou num cofre de recuperação do Azure. A

figura 13.1 mostra como o serviço Azure Backup pode proteger e orquestrar todas as
suas necessidades de cópia de segurança.
Servidores
VMs on-premises
Azure físicos on-prem- VM externas
(VMware/Hyper-V)
VMs ises (Windows/- (como AWS)
Linux)
Podem ser copiadas várias

origens de dados
O Azure Backup organiza cópias de Azure

segurança de dados por política
definida.
Backup As cópias de segurança de dados
podem ser armazenadas no Azure ou
para proteger uma localização
on-premises.
Cofre dos Solução de

Serviços de armazenamen-
Recuperação to on-premises
do Azure
Figura 13.1 Vários servidores físicos ou VMs, de vários fornecedores e localizações, podem ser
copiados pelo serviço de orquestração central. O Azure Backup utiliza as políticas definidas para fazer
cópias de segurança dos dados com uma determinada frequência ou de acordo com uma agenda. Depois,
estas cópias de segurança podem ser armazenadas no Azure ou numa solução de armazenamento
on-premises. Os dados são inteiramente encriptados para maior segurança.
Basicamente, o Azure Backup gere agendas de cópia de segurança e retenção de dados

e coordena as cópias de segurança ou a restauração das tarefas. Para fazer cópias de
segurança de VMs do Azure, não precisa de instalar nenhum componente de servidor
ou agente manualmente. Todas as operações de cópia de segurança e restauração são
incorporadas na plataforma do Azure.
Para fazer cópias de segurança de VMs ou servidores físicos on-premises ou de virtual
machines alojadas por outros fornecedores, como o AWS, é instalado um pequeno
agente que permite a comunicação segura com o Azure. Esta comunicação segura
garante que os seus dados são encriptados durante a transferência.
Para os dados armazenados no Azure, as cópias de segurança são encriptadas com a
utilização de uma chave de encriptação criada por si. Só tem acesso a essas cópias de
segurança encriptadas. Também pode fazer cópias de segurança de VMs encriptadas
(como iremos explicar no capítulo 14) para garantir que todas as cópias de segurança
dos seus dados ficam realmente protegidas.
O fluxo do tráfego de rede utilizado ao fazer cópias de segurança ou restaurar os dados
não gera encargos. Paga apenas por cada instância protegida, independentemente da
quantidade de armazenamento que consome no Azure. Se utilizar uma localização de
armazenamento on-premises, o custo da utilização do Azure Backup é mínimo, pois
não há custos para o Azure Storage ou o tráfego de rede.
Azure Backup 193
13.1.1 Políticas e retenção

O Azure Backup utiliza um modelo de cópia de segurança incremental. Quando pro-
tege uma instância, a primeira operação de cópia de segurança executa uma cópia de
segurança completa dos dados. Depois disso, cada operação de cópia de segurança
executa uma cópia de segurança incremental dos dados. Cada uma destas cópias de
segurança é denominada ponto de recuperação. As cópias de segurança incrementais eco-
nomizam tempo e permitem otimizar o armazenamento e o consumo de largura de
banda da rede. Apenas os dados que foram alterados desde a cópia de segurança ante-
rior foram transferidos para a localização da cópia de segurança de destino. A figura
13.2 detalha como as cópias de segurança incrementais funcionam.
Cópia de segurança Cópia de segurança Cópia de segurança

incremental
integral incremental
VM
protegida
A primeira operação de
cópia de segurança faz
cópia de segurança de
todos os dados da VM
para a localização de
recuperação
selecionada. A tarefa de cópia de As tarefas de cópia de
segurança seguinte faz apenas segurança adicionais continuam
cópia de segurança dos dados apenas a fazer cópia de
que foram alterados desde a segurança dos dados que foram
operação anterior de cópia de alterados desde a operação
segurança. anterior de cópia de segurança.
Figura 13.2 Nas cópias de segurança incrementais, apenas os dados que foram alterados desde a operação
anterior são copiados. A primeira cópia de segurança está sempre completa. Em cada tarefa de cópia de segurança
subsequente, apenas os dados que foram alterados desde a cópia anterior foram copiados. Pode controlar a
frequência das cópias de segurança por meio de políticas. Com esta abordagem, a quantidade de dados que deve
viajar com segurança pela rede e permanecer na localização de armazenamento de destino é minimizada. O Azure
Backup mantém as relações das cópias de segurança incrementais entre si, para que, ao restaurar os dados, estes
sejam consistentes e estejam completos.
Com o Azure Backup, pode armazenar até 9999 pontos de recuperação para cada ins-
tância protegida. Para ter uma ideia, se fizer cópias de segurança diárias, poderá man-
ter os pontos de restauração durante mais de 27 anos. Ou, se fizer cópias de segurança
semanais, poderá mantê-las durante 200 anos. Acho que deveria ser suficiente para
cobrir quase todas as situações de auditoria! Pode optar por manter as cópias de segu-
rança diariamente, semanalmente, mensalmente ou anualmente, o que está de acordo
com a maioria das políticas de cópia de segurança existentes.
Para implementar a estratégia de cópia de segurança ideal para o seu workload, pre-
cisa de entender e determinar o objetivo de ponto de recuperação (RPO) e o objetivo de tempo
de recuperação (RTO) aceitáveis.
Objetivo de ponto de recuperação
O RPO define o ponto em que pode restaurar os dados na cópia de segurança mais
recente. Por predefinição, o Azure Backup faz uma cópia de segurança diária. Em
seguida, define as políticas de retenção, como durante quantos dias, semanas, meses
ou anos pretende manter estes pontos de recuperação. Embora, normalmente, o RPO
seja utilizado para definir a quantidade máxima de perda de dados aceitável, também
deve considerar o quanto pretende retroceder no tempo. A figura 13.3 mostra como o
RPO define a quantidade de perda de dados aceitável.
Cópia de
segurança
diária
Perda de dados aceitável
VM protegida
Cópia de
segurança
semanal
Perda de dados Perda de dados

de 1 dia no de 1 semana no
máximo máximo
Figura 13.3 O objetivo do ponto de recuperação (RPO) define a quantidade de perda de dados que
pode sustentar para uma instância protegida. Quanto mais longo for o RPO, maior será a perda de dados
aceitável. Um RPO de 1 dia significa que até 24 horas de dados podem ser perdidos, dependendo de
quando a perda ocorreu em relação à última cópia de segurança. Um RPO de uma semana significa que
podem ser perdidos até sete dias de dados.
Não é frequente que ocorram interrupções graves ou que sejam perdidas grandes
quantidades de dados. Por outro lado, incidentes de perda ou substituição de peque-
nas quantidades de dados são mais comuns. Frequentemente, passam despercebidos
ou não são notificados até depois de um tempo desde que ocorreram. É aqui que a
política de retenção das instâncias protegidas torna-se importante. Se tiver uma polí-
tica de retenção curta, talvez não consiga restaurar os dados no ponto de recuperação
necessário. É importante encontrar o equilíbrio entre a quantidade de pontos de recu-
peração e os custos de armazenamento que a sua retenção implica.
O armazenamento do Azure é relativamente barato, geralmente inferior a 0,02 $ por
gigabyte de armazenamento. Este custo equivale a aproximadamente 2 $ por mês para
cópias de segurança de dados de VM com 100 GB (mais uma taxa para o serviço de
Backup Azure em si). Dependendo do quanto os seus dados mudam, o tamanho dos
pontos de recuperação incrementais pode aumentar rapidamente. Reter pontos de
recuperação durante semanas ou meses pode custar dezenas de dólares por mês por
instância protegida. Isto não é para o desencorajar, mas é importante planear as suas
necessidades e realizar uma gestão inteligente dos seus custos. O armazenamento a
0,02 $ por gigabyte parece barato até que tenha centenas de gigabytes por instância
protegida e dezenas ou centenas de instâncias para proteger.
Azure Backup 195
Quando era administrador de cópias de segurança, a capacidade de armazenamento

costumava ser um fator essencial para determinar a quantidade de pontos de recupera-
ção retidos. Muitas vezes, essa capacidade de armazenamento é forçada a fazer conces-
sões em relação aos RPOs. Mas se utilizar o Azure Storage em vez de uma solução de
armazenamento on-premises, não precisará de se preocupar com a capacidade de
armazenamento disponível. Com quase total segurança, o armazenamento disponível
excede o limite do seu cartão de crédito!
Objetivo de tempo de recuperação
O RTO dita a rapidez com que pode restaurar os seus dados. Se optar por fazer cópias
de segurança de VMs do Azure e armazenar os pontos de recuperação numa solução
de armazenamento on-premises, levará muito mais tempo a restaurar essas cópias de
segurança do que se estivessem alojadas diretamente no Azure Storage. O inverso seria
verdadeiro se fizesse cópias de segurança de VMs ou servidores físicos on-premises
para o Armazenamento do Azure. A figura 13.4 descreve o RTO.
Única cópia
de segurança
completa Duração aceitável da
interrupção da aplicação
VM protegida
Várias cópias
de segurança
incrementais
Menor tempo Tempo de
para recuperar recuperação
os dados progressivamente
mais longo
Figura 13.4 O RTO define quanto tempo é aceitável para o processo de restauração de dados ser
executado e a aplicação estar indisponível. Quanto mais pontos de recuperação estiverem envolvidos no
processo de restauração, mais longo será o RTO. Da mesma forma, quanto mais próximas as cópias de
segurança estiverem armazenadas do ponto de restauração, mais curto será o RTO.
Em qualquer cenário, os dados do ponto de recuperação precisariam de ser transferi-

dos da localização de armazenamento do ponto de recuperação para a localização de
restauração. No caso de grandes operações de restauração, nas quais pode precisar de
transferir centenas de gigabytes, a sua largura de banda de rede torna-se um fator de
restrição de desempenho real que controla a rapidez com que as aplicações podem
ficar novamente disponíveis.
O mesmo acontece quando as políticas de retenção prolongada são aplicadas com
muitos pontos de recuperação incrementais sucessivos. A restauração dos dados pode
exigir que vários pontos de recuperação sejam montados e restaurados. A sua tarefa é
determinar quanto será necessário recuar no tempo e quanto tempo é aceitável levar a
restaurar os dados.
O RPO e o RTO variam de acordo com as suas aplicações e utilização comercial.
Uma aplicação que processa pedidos em tempo real não pode tolerar uma interrupção
ou tempo de inatividade muito longos e, portanto, o RPO e o RTO serão provavel-
mente muito baixos. Normalmente, é utilizada uma base de dados para conter os dados;
portanto, é comum incluir tolerâncias ao conceber a aplicação, em vez de depender
dos pontos de recuperação. Voltando ao Cosmos DB, não há nada para incluir na cópia
de segurança: porque a plataforma do Azure é automaticamente responsável por repli-
car e proteger os dados. Se criar uma solução personalizada no MySQL ou no Microsoft
SQL Server, seria normal utilizar um tipo semelhante de clustering e replicação para
garantir que haja várias cópias da base de dados. Portanto, caso uma instância seja per-
dida, não seria necessário restaurá-la a partir de uma cópia de segurança. As cópias de
segurança protegem principalmente contra uma interrupção grave do serviço ou no
caso de os dados serem corrompidos.
13.1.2 Agendas de cópia de segurança

Como controla a frequência das suas cópias de segurança e a retenção dos pontos de
recuperação? No Azure Backup, estas definições são definidas em políticas. Cria estas
políticas para abranger os vários cenários dos quais pretende proteger-se, e pode reuti-
lizar as políticas para várias instâncias protegidas.
Uma política de cópia de segurança pode definir que pretende fazer uma cópia de
segurança às 18h30 todos os dias, por exemplo. Além disso, pretende manter as cópias
de segurança diárias durante 6 meses e alterná-las para manter as cópias de segurança
semanais durante 2 anos. Para efeitos de conformidade, mantém cópias de segurança
mensais durante 5 anos. Uma cópia de segurança anual é mantida durante 10 anos.
Estes valores de retenção podem parecer excessivos. No entanto, numa aplicação de
comunicação e mensagens, muitas vezes é necessário manter cópias de segurança
durante longos períodos para fins de regulamentação e conformidade. O Azure Backup
fornece flexibilidade para definir políticas apropriadas para diferentes workloads das
aplicações e implementar rapidamente os requisitos de conformidade.
Experimente agora
Todas as cópias de segurança do Azure são armazenadas num cofre dos Serviços
de Recuperação. Para criar um cofre e uma política de cópia de segurança, conclua
os passos a seguir:
1 Abra o portal Azure e escolha a opção Criar um Recurso no canto superior

esquerdo do menu.
2 Procure e selecione Backup e Site Recovery e, em seguida, escolha Criar.
3 Introduza um grupo de recursos, como azuremolchapter13 e, em seguida, intro-
duza um nome para o cofre, como azuremol.
4 Selecione uma localização e, em seguida, reveja e crie o cofre.
5 Após criar o cofre, escolha Grupos de Recursos no menu à esquerda no portal
e escolha o grupo de recursos que criou.
6 Selecione o seu cofre dos Serviços de Recuperação na lista de recursos disponí-
veis, escolha Políticas de Cópia de Segurança no menu à esquerda e escolha adi-
cionar uma política.
7 Selecione o tipo de política da Virtual Machine do Azure e forneça um nome
para a sua nova política, como molpolicy. Por predefinição, é criada uma cópia
de segurança diariamente.
8 Escolha o fuso horário mais apropriado no menu pendente. Por predefinição,
o Azure utiliza a Hora Universal Coordenada (UTC).
Azure Backup 197
Se pretender, analise e ajuste as políticas de retenção para diário, semanal,

mensal e anual. A secção sobre os conceitos dos agendamentos de cópias de segu-
rança e retenção detalha como selecionar estes valores. Estes valores normal-
mente variam à medida que cria e aplica políticas de cópias de segurança para
proteger as suas instâncias VM.
9 Quando estiver pronto, selecione Criar.
A vida simples
Também pode configurar cópias de segurança de VM ao criar uma VM no portal Azure.
Na página Definições na qual configure as definições de rede virtual ou diagnóstico e
opções de resolução de problemas, pode ativar o Azure Backup. Pode escolher um cofre
dos Serviços de Recuperação existente ou criar um e, em seguida, criar ou utilizar uma
política de cópia de segurança. Atualmente, não pode ativar cópias de segurança como
parte da implementação da VM na CLI do Azure ou no Azure PowerShell, mas geralmente
basta um único comando pós-implementação para fazer isso.
Gosto de planear uma estratégia de cópia de segurança, políticas de retenção e agen-
das, motivo pelo qual estes exercícios criaram primeiro o cofre e as políticas dos Servi-
ços de Recuperação. Mas, se pretender criar uma VM e ativar as cópias de segurança
rapidamente, poderá fazer isso no portal Azure num único passo.
Agora tem uma política de cópia de segurança, que também define políticas de reten-
ção para vários períodos, mas ainda não tem nada para copiar. Vamos criar uma VM
com o Cloud Shell para que possa criar uma cópia de segurança e, num exercício pos-
terior, replicar os dados.
Experimente agora
Para criar uma VM de teste para cópia de segurança e replicação, conclua os passos
a seguir:
1 Selecione o ícone do Cloud Shell na parte superior do portal Azure.

2 Crie uma VM com az vm create; forneça o nome para o grupo de recursos
criado no laboratório anterior, como azuremolchapter13, e introduza um
nome para a VM, tal como molvm:
az vm create \
--name molvm \
--image win2019datacenter \
--admin-password P@ssw0rdMoL123
É definida uma política de cópia de segurança e há uma VM de teste preparada. Para

ver o Azure Backup em ação, vamos aplicar a política de cópia de segurança à VM.
Experimente agora
Para fazer uma cópia de segurança de uma VM com a sua política definida, conclua os
passos a seguir:
1 Selecione Grupos de Recursos no menu à esquerda no portal.

2 Escolha o grupo de recursos e, em seguida, a VM que criou.
3 Em Operações, selecione Cópia de Segurança.
4 Verifique se o cofre dos Serviços de Recuperação está selecionado e escolha
a política de cópia de segurança no menu pendente.
5 Reveja as opções de agendamento e retenção de cópias e, em seguida, ative a
cópia de segurança. Leva alguns segundos a aplicar a política de cópia de
segurança.
6 Quando a política estiver ativada, volte às definições de cópia de segurança.
O estado VM indica Aviso (Cópia de segurança inicial pendente).
7 Para criar a primeira cópia de segurança, escolha o botão Criar Cópia de Segu-
rança Agora, como mostra a figura 13.5.
Figura 13.5 Para criar a primeira cópia de segurança, selecione o botão Criar Cópia de Segurança
Agora. O estado é atualizado quando concluído e mostra a hora da cópia de segurança mais recente,
o ponto de restauração mais recente e o ponto de restauração mais antigo.
Pode demorar entre 15 e 20 minutos a concluir a primeira operação de cópia de segu-

rança. Para ver o progresso da tarefa de cópia de segurança, pode selecionar a opção
Ver Todas as Tarefas. Não há nenhuma barra de progresso ou indicador de percenta-
gem, mas pode verificar se a tarefa ainda está em execução.
Isso é tudo o que é necessário para fazer uma cópia de segurança das VMs e proteger
os seus dados no Azure! Continue a ler para ver como pode restaurar os dados, se ocor-
rerem problemas.
13.1.3 Restaurar uma VM

O Azure Backup permite restaurar uma VM completa ou executar uma restauração ao
nível do ficheiro. Em todos os meus anos na área, as operações de restauro ao nível dos
ficheiros eram as mais comuns das duas. Este tipo de trabalho de restauro é geral-
mente realizado quando os ficheiros são eliminados ou acidentalmente substituídos.
Azure Backup 199
Em geral, as restaurações ao nível do ficheiro determinam as políticas de retenção

para as suas cópias de segurança. Quanto mais importantes forem os dados, maior é a
probabilidade de manter as cópias de segurança durante mais tempo, caso receba uma
chamada a meio da noite para restaurar um ficheiro de há seis meses.
Uma restauração completa da VM, como pode esperar, restaura toda a VM. Rara-
mente executei uma restauração completa da VM para colocar uma VM eliminada
novamente online. Um caso prático interessante para a restauração completa de VMs é
fornecer uma VM de teste que seja funcionalmente equivalente à original. Pode restau-
rar uma VM e, em seguida, testar uma atualização de software ou outro procedimento
de manutenção, o que pode ajudá-lo a identificar potenciais problemas e criar um
plano para gerir a VM de produção real.
Também é importante testar as cópias de segurança regularmente. Não espere até
precisar de restaurar dados num cenário real. Confie no Azure Backup, mas verifique
se sabe como e onde restaurar os dados quando necessário!
Restauração ao nível do ficheiro
Uma restauração ao nível do ficheiro é um
processo muito interessante no Azure Backup.
Para oferecer flexibilidade em como e onde
restaura os ficheiros, o Azure cria um script de
recuperação que faz download e executa. Este
script de recuperação é protegido por palavra-
-passe para que apenas você possa executar o
processo de recuperação. Quando executar o
script de recuperação, ser-lhe-á pedido para
introduzir a palavra-passe antes de continuar.
A janela para transferir o script de recupera-
ção é mostrada na figura 13.6.
Quando executa o script de recuperação, o
seu ponto de recuperação é ligado como um
sistema de ficheiros local no seu computador.
Para as VMs Windows, é gerado um script do
PowerShell e é ligado um volume local, como
F:. Para as VMs Linux, o ponto de recuperação
é montado como um disco de dados, como /
dev/sdc1 no seu volume doméstico. Em ambos
os casos, o script de recuperação indica clara-
mente onde pode encontrar os seus ficheiros.
Quando concluir a restauração de ficheiros
do cofre de recuperação, regresse ao portal
Azure e selecione a opção Desmontar Discos.
Este processo desanexa os discos do computa-
dor local e devolve-os para utilização no cofre Figura 13.6 Quando executa uma
de recuperação. Não se preocupe se se esque- restauração ao nível do ficheiro, escolhe
cer de executar este processo de desmontagem um ponto de recuperação para restaurar.
no calor do momento em que precisa de res- Em seguida, um script de recuperação
taurar rapidamente ficheiros para uma VM de é descarregado para o seu computador.
produção! O Azure desanexa automatica- Só pode executar este script introduzindo
mente quaisquer pontos de recuperação ane- a palavra-passe gerada. O script de
xados depois de 12 horas. recuperação monta o ponto de recuperação
como um volume local no computador. Após
restaurar os ficheiros necessários, desmonta
os discos do computador, devolvendo-os para
utilização no cofre de recuperação.
Restauração completa de VMs

Uma restauração completa de VMs cria uma VM, liga a VM à rede virtual e anexa todos
os discos rígidos virtuais. Vamos experimentar o processo para uma restauração com-
pleta de VMs. Como é sempre melhor testar atualizações de manutenção antes de exe-
cutá-las na vida real, este exercício de restauração é uma boa prática.
Experimente agora
Para restaurar uma VM completa, conclua os passos a seguir:
1 No grupo de recursos, selecione a VM à qual fez uma cópia de segurança no

exercício anterior.
2 Selecione a opção Cópia de Segurança no menu à esquerda na VM. A descrição
geral de cópia de segurança deve reportar que foi criado um ponto de recupera-
ção, como mostrado na figura 13.7. Caso contrário, aguarde alguns minutos e,
em seguida, volte a este exercício. Ou leia apenas o que o processo implica.
Figura 13.7 Quando a cópia de segurança da VM for concluída, a página de descrição geral
mostrará os dados da última cópia de segurança e dos pontos de restauração disponíveis. Para
iniciar o processo de restauração, selecione Restaurar VM.
3 Selecione o botão Restaurar VM, escolha um ponto de restauro da lista e,

em seguida, selecione OK.
4 Escolha um ponto de restauro e escolha como restaurar a VM. Pode optar por
criar uma nova VM ou substituir uma VM existente.
A opção predefinida é criar uma nova VM. Nesta configuração, uma nova VM é
criada e ligada à rede virtual especificada e os discos são restaurados e ligados.
Também pode optar por substituir uma VM existente. Neste cenário, os discos são
restaurados a partir da cópia de segurança e ligados à VM existente. Quaisquer opções
de rede virtual ou outras opções de configuração aplicadas à VM são mantidas.
5 Para este exercício, escolha restaurar para uma nova VM. Forneça um nome para
a VM restaurada, como restoredvm e analise as definições de rede virtual e arma-
zenamento. Em produção, normalmente liga a VM restaurada a uma rede virtual
isolada para que não afete o tráfego de produção.
6 Selecione OK e, em seguida, Restaurar.
Azure Site Recovery 201
Demora alguns minutos a ligar o ponto de recuperação e a criar uma VM restaurada com
os discos anteriores anexados. Neste ponto, pode ligar-se à VM restaurada para testar atua-
lizações de software ou restaurar grandes quantidades de dados, conforme necessário.
Também pode fazer cópia de segurança de uma aplicação Web; portanto, esta abor-
dagem não é apenas para VMs. O processo é um pouco diferente, mas os conceitos são
os mesmos. Migrar o seu modelo de aplicação para uma solução de PaaS como uma
aplicação Web não significa que pode esquecer-se dos princípios básicos das cópias de
segurança e da retenção!
13.2 Azure Site Recovery

Lembra-se de quando discutimos o Cosmos DB, e aprendeu que, com um simples cli-
que de um botão, os seus dados são replicados para uma região do Azure completa-
mente diferente para redundância e tolerância a falhas? Também pode fazer isso com
VMs inteiras! O Azure Site Recovery é um serviço poderoso que pode fazer muito mais
do que apenas replicar VMs para uma região diferente. A figura 13.8 descreve como
o Azure Site Recovery atua para orquestrar workloads entre localizações.
Recursos on-premises
Azure VMs VMs Servidores

VMs VMware Hyper-V físicos
Vários servidores
virtuais ou físicos
podem ser protegidos
e replicados com O Azure Site Recovery atua como
o Site Recovery. Azure Site um orquestrador para replicar
workloads com base em políticas
Recovery definidas que definem a agenda
e as localizações.
Localização Os recursos podem ser

Região do Azure on-premises replicados ou migrados
secundária para o Azure ou uma
localização secundária
on-premises.
Figura 13.8 O Azure Site Recovery coordena a replicação e a migração de recursos físicos ou virtuais
para outra localização. As localizações on-premises e o Azure podem servir como pontos de origem e de
destino para proteção, replicação ou migração.
Um aspeto importante é que o Azure Site Recovery serve para mais do que apenas VMs
do Azure; o Site Recovery pode ser utilizado para replicar VMs do VMware ou Hyper-V
on-premises para o Azure para recuperação após desastre (DR) ou como parte de uma
migração para o Azure. Também pode utilizar o Azure Site Recovery puramente como
o orquestrador para replicar VMs on-premises de uma localização para uma localiza-
ção on-premises secundária.
Da mesma forma que o Azure Backup não significa “só funciona com o Azure”, o
Azure Site Recovery não significa “apenas replica VMs do Azure”. O Azure Backup e o
Azure Site Recovery podem ser utilizados como soluções híbridas para cópia de segura-
ção e recuperação após desastre. Estes serviços do Azure podem ser utilizados para pro-
teger todas as suas workloads, tanto on-premises como na no Azure. Em seguida, uma
única estrutura de comunicação para conformidade e validação pode ser gerada para
garantir que todos os workloads que pensar que estão protegidos estão realmente em
segurança contra perdas de dados.
Por que utilizaria o Azure Site Recovery? Dois motivos principais são mais comuns:
replicação e migração.
A replicação protege-o de uma interrupção completa da região do Azure. Seria pre-
ciso um evento catastrófico para uma região inteira ficar offline, mas quando trabalha
em TI, sabe que tudo é possível. Mesmo os conjuntos de disponibilidade e as zonas de
disponibilidade, que vimos no capítulo 7, normalmente só o protegem de uma inter-
rupção menor dentro de uma região do Azure. Se a região inteira ficar inativa, a sua
aplicação ficará indisponível. Com o Site Recovery, todo o seu ambiente de aplicação,
incluindo recursos de rede virtual, é replicado para uma região secundária do Azure.
Ao clicar num botão, essa localização secundária pode ser colocada online e ficar ativa.
Em seguida, o tráfego pode então ser encaminhado para esta localização secundária e
começar a providenciar os seus clientes. A figura 13.9 apresenta uma descrição geral de
alto nível sobre como o Azure Site Recovery protege o seu ambiente.
Ambientes de Ambiente de
produção recuperação
Este dos EUA Costa Oeste EUA
VM do Azure
Azure Site Recovery
Discos virtuais Discos virtuais
Política de replicação
VM, configu- Configuração e
Rede virtual ração, Cofre dos Serviços de Rede virtual
dados replicados
do Azure armazenamento Recuperação do Azure
a partir da
e rede virtual produção com
Sub-rede replicada Sub-rede
base na política
definida
Figura 13.9 O Azure Site Recovery replica a configuração, os dados e as redes virtuais do ambiente de
produção para um ambiente de recuperação. As VMs não são criadas no ambiente de recuperação até
que seja iniciada uma ativação pós-falha. Apenas os dados são replicados.
A VM consiste apenas nos metadados que definem o tamanho da VM, quais discos estão
anexados e a quais recursos de rede a VM se liga. Estes metadados são replicados, o que
permite que as VMs sejam criadas rapidamente quando uma ativação pós-falha é ini-
ciada. Os discos virtuais são replicados para o ambiente de recuperação e são anexados
quando uma VM de recuperação é criada durante um evento de ativação pós-falha.
Azure Site Recovery 203
Para a replicação do Azure para o Azure, não há nenhuma agenda de replicação

definida. Os discos são replicados em tempo quase real. Quando os dados nos discos
virtuais de origem forem alterados, serão replicados para o ambiente de recuperação.
Para workloads híbridos, onde protege VMs VMware ou Hyper-V on-premises, define
políticas que controlam a agenda de replicação.
Se nos concentrarmos na replicação do Azure para o Azure, como os dados são replica-
dos em tempo quase real? É criada uma cache da conta de armazenamento na localização
do ambiente de produção, como mostrado na figura 13.10. As alterações escritas nos dis-
cos virtuais de produção são imediatamente replicadas para a cache da conta de armaze-
namento. Em seguida, a cache da conta de armazenamento é então replicada para o
ambiente de recuperação. Esta cache da conta de armazenamento atua como uma
memória intermédia para que qualquer atraso de replicação na localização de recupera-
ção distante não tenha impacto sobre o desempenho no workload de produção.
Ambientes de produção
Ambiente de recuperação
Este dos EUA
Costa Oeste EUA
VM do Azure
Cache da conta
Discos virtuais
Discos virtuais Os dados escritos nos Storage Dados replicados da
discos de produção são cache da conta de
imediatamente armazenamento
replicados para a cache para o ambiente
da conta de armazena- de recuperação
mento.
Figura 13.10 As alterações nos discos de produção são imediatamente replicadas para uma cache
da conta de armazenamento. Esta cache da conta de armazenamento evita impactos de desempenho
nos workloads de produção na medida que aguardam para replicar as alterações na localização de
recuperação remota. Em seguida, as alterações da cache da conta de armazenamento são replicadas
para o ponto de recuperação remoto para manter a consistência dos dados.
O processo de configuração do Site Recovery para a replicação do Azure para o Azure

é simples, mas leva algum tempo a criar todos os recursos replicados necessários e a
concluir a replicação de dados inicial. No laboratório de fim de capítulo, irá configu-
rar esta replicação do Azure para o Azure.
O que pode fazer com VMs replicadas para uma localização secundária com o Azure
Site Recovery? Acima de tudo, cruze os dedos e espero que não precise deles!
No entanto, existem dois cenários onde podem ser úteis.
O primeiro deve ser óbvio: uma grande interrupção. Se uma região do Azure ficar
totalmente indisponível, como por causa de um desastre natural na área, pode iniciar
uma ativação pós-falha dos seus recursos. Esta ativação pós-falha informa o Azure Site
Recovery para criar VMs na localização de recuperação com base nos metadados de VM
replicados e, em seguida, anexar os discos rígidos virtuais e as ligações de rede apropria-
dos. Também pode ser proativo aqui: se se prever que um desastre natural vá atingir
uma região do Azure, poderá iniciar uma ativação pós-falha antes de o evento ocorrer.
Esta abordagem permite-lhe decidir quando incorrer em algum tempo de inatividade
potencial à medida que os recursos efetuam a ativação pós-falha na localização secun-
dária, normalmente fora do horário de funcionamento principal. Após o evento pre-
visto ter passado na região principal do Azure, poderá reativar os seus recursos e deixar
que continuem a ser executados normalmente.
O segundo cenário no qual pode efetuar uma ativação pós-falha é para testar que o
processo funciona. Da mesma forma que as cópias de segurança devem ser testadas regu-
larmente, deve testar um plano de replicação e ativação pós-falha. Quando precisa de
colocar uma localização secundária online, seria bastante comprometedor e stressante
descobrir que há um problema de configuração nas redes virtuais ou que não pode exe-
cutar a ativação pós-falha com êxito em nenhuma das aplicações. O Azure deve fornecer
uma opção especificamente para testar a ativação pós-falha. Normalmente, é utilizada
uma rede virtual do Azure isolada na localização secundária e os workloads de produção
continuam a ser executados normalmente na localização principal. Se utilizar o Azure
Site Recovery, certifique-se de que testa regularmente o processo de ativação pós-falha!
13.3 Laboratório: configurar uma VM para Site Recovery

Há vários pré-requisitos para a configuração da replicação do VMware ou do Hyper-V
on-premises com o Azure Site Recovery. É uma funcionalidade muito boa, tanto para a
recuperação de após desastres como para migrar as VMs para o Azure, mas isto demora
muito mais tempo do que a sua pausa para almoço! Se pretender saber mais sobre
esses cenários, aceda a http://mng.bz/x71V.
Vamos configurar a replicação do Azure para o Azure com a VM de teste que criou e
fez cópia de segurança anteriormente:
1 No portal Azure, escolha Grupos de Recursos no menu à esquerda.

2 Selecione o grupo de recursos que utilizou nos exercícios anteriores, como
azuremolchapter13.
3 Selecione a VM que criou nos exercícios anteriores, como molvm.
4 Escolha Recuperação Após Desastre no menu à esquerda na janela VM.
5 Nas definições avançadas, veja as definições predefinidas utilizadas pelo Azure
Site Recovery para criar um grupo de recursos e uma rede virtual na localização
de destino. É criada uma cache da conta de armazenamento para replicar a par-
tir dos discos virtuais de origem e são criados um cofre e uma política de Serviços
de Recuperação para controlar o processo de replicação.
6 Não precisa de alterar nada aqui, embora se utilizar o Site Recovery em ambien-
tes de produção e tiver várias VMs para proteger, irá precisar de analisar como as
VMs mapeiam para as redes virtuais replicadas e sub-redes existentes. Para este
laboratório, analise e ative a replicação utilizando os valores padrão.
Agora, volte ao trabalho. A sério! Demora um pouco a configurar todos os recur-
sos replicados e a concluir a sincronização de dados inicial. Não fique à espera, a
menos que o seu chefe ache bem que faça um intervalo para almoço mais longo hoje!
Laboratório: configurar uma VM para Site Recovery 205
Proteção das cópias de segurança contra eliminação

Espero que, como boa prática, tenha eliminado os grupos de recursos e os seus recur-
sos no final de cada capítulo para manter os seus créditos do Azure gratuitos disponíveis
para utilizar no resto do do livro.
Se tiver VMs protegidas com o Azure Backup ou o Site Recovery, não poderá eli-
minar o cofre dos Serviços de Recuperação ou o grupo de recursos da VM. A plataforma
do Azure sabe que tem dados ativos que são copiados ou replicados e impede que esses
recursos sejam eliminados.
Para eliminar as VMs protegidas, desative primeiro qualquer tarefa de cópia de segu-
rança ativa ou as VMs replicadas. Quando fizer isso, pode optar por reter os dados prote-
gidos ou removê-los. Para os exercícios do laboratório neste capítulo, opte por eliminar
os pontos de restauro. Como funcionalidade de segurança, o Azure elimina automatica-
mente, de forma recuperável, estes pontos de restauro e permite-lhe anular a elimina-
ção durante 14 dias. Não há nada para configurar aqui e não pode forçar a removação
destes pontos de restauro eliminados de forma recuperável. Não o recomendo, mas
também pode desativar a função de eliminação recuperável de um cofre do Recovery
Services selecionando as propriedades do cofre no portal Azure.
A boa notícia é que o resto do grupo de recursos pode ser eliminado e não
paga por estes pontos de restauro apagados de forma recuperável. Decorrido o período
de eliminação recuperável de 14 dias, o cofre do Recovery Services pode ser eliminado
normalmente. O objetivo aqui é protegê-lo de eliminação acidental, ou maliciosa, de
pontos de restauro e dar-lhe tempo para perceber see são realmente necessários
e recuperá-los.
14
Encriptação de dados
A segurança dos seus dados é importante. Mais especificamente, a segurança dos dados
dos seus clientes é fundamental. Todas as semanas lemos nas notícias que alguma
empresa importante detetou uma violação de dados. Muitas vezes, estes incidentes são
causados por uma falta de segurança, uma configuração incorreta ou um simples des-
cuido. Nesta era digital, é muito fácil para os hackers automatizarem as tentativas de
obter acesso aos dados. O tempo necessário para se recuperar de um incidente de segu-
rança ao nível da aplicação pode não ser nada comparado com o tempo que leva à
empresa recuperar a confiança do cliente se os seus dados foram expostos.
O Azure inclui funcionalidades de encriptação que dificultam a utilização de des-
culpas como o facto de não ter tempo ou experiência para proteger os dados. Neste
capítulo, examinamos como encriptar os dados armazenados no Azure Storage, em
discos geridos ou em toda a VM. Foram escritos livros inteiros sobre a encriptação de
dados e este capítulo não aprofunda os métodos e as considerações de encriptação.
Em vez disso, verá como ativar alguns dos serviços e funcionalidades core do Azure
para proteger os seus dados durante o ciclo de vida da aplicação.
14.1 O que é a encriptação de dados?

Quando compra algo online, verifica se há um pequeno ícone de cadeado na barra
de endereços a indicar que o site utiliza HTTPS? Por que não é recomendável enviar
os dados do seu cartão de crédito por uma ligação HTTP normal e desprotegida?
Todos os bits de dados num pacote de rede que circulam entre dispositivos podem
ser monitorizados e examinados. A figura 14.1 mostra como a compra online sem
uma ligação HTTPS pode ser prejudicial para o extrato do seu cartão de crédito.
Não há desculpa para os servidores Web utilizarem ligações não protegidas. Cada
aplicação Web que cria no Azure tem automaticamente um certificado SSL de cará-
ter universal aplicado.
206
O que é a encriptação de dados? 207
O servidor Web não

Os dados transmitidos
sabe que o tráfego
através de uma ligação
foi intercetado. Não
HTTP não encriptada
pode proteger os
podem ser intercetados
por hackers.
seus dados. Ligação do
Cliente Internet site HTTP
011
110
101
011
110
101
Os hackers podem ver todo o

tráfego de rede e reunir as suas
informações privadas, como
Hacker detalhes do cartão de crédito e
endereço de faturação.
Figura 14.1 Neste exemplo básico, um hacker pode intercetar o tráfego de rede enviado por uma
ligação HTTP não encriptada. Como os dados não são encriptados, o hacker pode juntar os pacotes
de rede e obter as suas informações pessoais e financeiras. Se se ligar ao servidor Web por meio de uma
ligação HTTPS encriptada, um hacker não poderá ler o conteúdo dos pacotes de rede e ver os dados.
Um certificado SSL é um componente digital que é utilizado para proteger o servidor

Web e permitir que um browser valide a ligação. Um certificado SSL de caráter univer-
sal pode ser utilizado num domínio inteiro, como *.azurewebsites.net, o domínio pre-
definido para aplicações Web. Quando criou uma aplicação Web no capítulo 3, poderia
ter adicionado https:// to the web address and started to use encrypted communica-
tions with your web apps. É tão simples quanto isto!
Os certificados SSL personalizados são relativamente baratos e fáceis de implemen-
tar. Graças a projetos como o Let’s Encrypt (https://letsencrypt.org), pode obter um
certificado gratuitamente e configurar automaticamente o seu servidor Web em minu-
tos. Também pode comprar e usar um certificado do App Service que se integra direta-
mente nas Web Apps. Os certificados do App Service estão armazenados no Azure Key
Vault, que aprofundaremos no capítulo 15.
Ao conceber e criar aplicações no Azure, deve implementar comunicações seguras
sempre que possível. Esta abordagem ajuda a proteger os dados enquanto em
trânsito, mas e quando esses dados forem escritos no disco? Existe um processo seme-
lhante para discos e VMs que protege os dados inativos. A figura 14.2 mostra como fun-
ciona a encriptação do disco e da VM.
Espero que estes exemplos simplificados de encriptação de dados no Azure o moti-
vem a implementar a encriptação ao conceber e criar aplicações no Azure. A maioria
dos clientes espera que os seus dados sejam protegidos e muitas empresas têm requisi-
tos regulamentares e de conformidade que exigem a encriptação. Não pense apenas
nas possíveis multas que a empresa teria que enfrentar por uma violação de dados ou na
perda de confiança do cliente. Considere também o risco ao qual os dados pessoais e
financeiros dos seus clientes estará exposto e o impacto que isso pode
208 Capítulo 14 Encriptação de dados
Os dados são encriptados

à medida que são escritos Aplicação
no disco. Os dados podem
Figura 14.2 Quando encripta
ser acedidos e desencrip- os seus dados, apenas você pode
011
Para VMs do Azure, os dados em desencriptar e ver o conteúdo.
tados apenas com as 110 memória e os discos temporários
101
chaves de encriptação. Se um hacker tiver acesso a
também são encriptados. Apenas
um disco virtual ou a ficheiros
011
110 você pode desencriptar e ver os
101
dados da VM. individuais, não irá conseguir
desencriptar o conteúdo. Os
métodos de encriptação podem
Disco Blob do Ficheiro ser combinados: os clientes
VM do
gerido Azure do Azure podem ligar-se à Web por HTTPS,
Azure
pode forçar o tráfego para as
do Azure Storage Storage
contas de armazenamento por
HTTPS e, depois, encriptar os
dados escritos no disco.
ter no seu dia a dia. Provavelmente não gosta da ideia de expor os seus próprios dados, por isso
faça tudo o que puder para proteger os dados dos seus clientes.
14.2 Encriptação inativa

Se a encriptação de dados é assim tão importante, como é utilizada no Azure? Basta con-
tinuar a fazer o que já aprendeu neste livro! Logo no início, mencionei que todas as suas
VMs devem utilizar discos geridos, certo? Há muitas boas razões para isso, uma das quais
é a segurança. Um disco gerido é automaticamente encriptado. Não há nada para confi-
gurar e não afeta desempenho quando está ativado. Não há exceções aqui; com os discos
geridos, os seus dados são encriptados automaticamente quando estão inativos.
O que significa para os dados serem encriptados de forma inativa? Quando utiliza dis-
cos geridos, os seus dados são encriptados quando são escritos no armazenamento sub-
jacente do Azure. Os dados que residem nos discos temporários, ou dados que existam
na memória da VM, não são encriptados. Apenas quando os dados do sistema operativo
do disco de dados repousam no disco físico subjacente é que se tornam encriptados. A
figura 14.3 mostra como os dados são encriptados à medida que são
escritos num disco gerido.
Virtual machine
Disco
Disco Memória gerido
temporário virtual Os dados são encriptados
quando são escritos num
disco gerido.
O disco temporário e os
dados em memória da VM
não são encriptados.
Figura 14.3 À medida que os dados são escritos num disco gerido, são encriptados. Os dados em
memória na VM ou os dados em discos temporários locais da VM não são encriptados, a menos que toda
a VM esteja ativada para a encriptação, o que veremos mais adiante na secção 14.4.2. A encriptação
automática de dados escritos em discos geridos não provoca nenhuma sobrecarga na VM. A plataforma
do Azure executa a operação de encriptação no armazenamento subjacente. A VM não precisa de
manipular os processos de encriptação/desencriptação.
Encriptação do Serviço de Armazenamento 209
Esta encriptação de dados inativos para os discos geridos significa que não afeta o
desempenho das VMs. Não há nenhum processamento adicional para a VM executar
para encriptar e desencriptar os dados, portanto, toda a potência da CPU disponível
pode ser utilizada para executar aplicações. Em cenários típicos de encriptação de
VMs, a VM utiliza uma certa quantidade de potência de computação para processar e
gerir a encriptação de dados. A contrapartida da encriptação automática de
discos geridos é que apenas o SO e os discos de dados estão protegidos. Outros dados
em memória ou em discos temporários na VM poderiam ficar expostos.
A Microsoft gere as chaves de encriptação digital dentro da plataforma do Azure
com a encriptação automática de discos geridos. Isto cria outra contrapartida em que
pode encriptar automaticamente os seus dados sem a necessidade de criar, gerir, alter-
nar ou revogar chaves, mas tem de confiar na Microsoft para proteger essas chaves.
14.3 Encriptação do Serviço de Armazenamento

A encriptação automática de discos geridos é ótima, mas e se utilizar o Azure Storage
para blob ou o armazenamento de ficheiros? A Encriptação do Serviço de Armazena-
mento do Azure (SSE) permite-lhe encriptar dados ao nível da conta de armazena-
mento. Os dados são encriptados à medida que são escritos na conta. Novamente, a
Microsoft manipula novamente as chaves de encriptação, portanto, não há nenhuma
sobrecarga administrativa nem se requer uma configuração. A plataforma Azure
resume a geração de chaves e a gestão para si. Se preferir, pode criar e usar as suas pró-
prias chaves de encriptação, com poucos custos de gestão adicionais. Tal como a
encriptação automática do disco gerida de forma inativa, a encriptação do armazena-
mento do Azure é automaticamente ativada quando cria uma conta.
O objetivo da encriptação automática de discos geridos e da SSE é facilitar o máximo
possível a encriptação dos dados e permitir-lhe gastar mais tempo a conceber, criar e
executar as suas aplicações. A figura 14.4 mostra como a SSE protege os seus dados e
também pode forçar as comunicações seguras quando os dados estão em trânsito.
Conta de armazena-
mento encriptado HTTP
Dados Aplicação
Os dados são HTTPS
encriptados à medida Blob Ficheiro
Apenas o tráfego que utiliza
que são escritos no
a comunicação encriptada,
blob ou no armazena-
como HTTPS, é aceite.
mento de ficheiros
Figura 14.4 Quando ativa a SSE, os blobs e ficheiros do Azure são encriptados à medida que os dados
são escritos no disco. As tabelas e filas do Azure não são encriptadas. Para obter uma melhor segurança
dos dados, pode forçar todas as comunicações com uma conta de Armazenamento a utilizarem
protocolos de comunicação seguros, como HTTPS. Isto protege os dados em trânsito até ao momento
em que são encriptados no disco.
Forçar o tráfego de armazenamento a utilizar transferências seguras

Além de ativar a SSE, pode forçar todos os pedidos de armazenamento e transferências a
utilizarem um método de comunicação seguro. Esta definição força todas as chamadas
API REST a utilizarem HTTPS e todas as ligações dos ficheiros do Azure que não ativam
a encriptação, como as versões mais antigas do protocolo SMB, a serem descartadas.
(continuação)
Os SDKs do Azure, como os exemplos do Python que examinámos no capítulo 4, podem
utilizar ligações encriptadas. Os documentos de referência para cada SDK específico da
linguagem fornecem orientação sobre como implementar comunicações seguras.
A utilização de comunicações seguras deve ser incorporada nas aplicações desde o iní-
cio. A ativação de comunicações seguras numa aplicação existente pode causar proble-
mas se alguns componentes não tiverem sido configurados corretamente originalmente.
Pelo menos, primeiro teste as comunicações seguras para uma aplicação existente num
ambiente de desenvolvimento.
Experimente agora
Para criar uma conta de armazenamento e ativar a encriptação e as comunicações
seguras, conclua os passos a seguir:
1 Abra o portal Azure e escolha o ícone do Cloud Shell na parte superior do menu.
3 Crie uma conta de armazenamento com az storage account create. Forneça

um nome único, como azuremolstorage e insira o grupo de recursos que
criou no passo 2. Introduza um tipo de conta de armazenamento, como Stan-
dard_LRS para armazenamento localmente redundante. Para forçar as comuni-
cações seguras, defina --https-only.
az storage account create \
--name azuremolstorage \
--sku standard_lrs \
--https-only true
4 Verifique se a conta de armazenamento está encriptada e ativada para comunicações

seguras ao consultar enableHttpsTrafficOnly e os parâmetros de encriptação:
az storage account show \
--name azuremolstorage \
--query [enableHttpsTrafficOnly,encryption]
A saída é semelhante à seguinte:

[
true,
{
"keySource": "Microsoft.Storage",
"keyVaultProperties": null,
"services": {
"blob": {
Encriptação de VMs 211
"enabled": true,
"lastEnabledTime": "2019-09-27T03:33:17.441971+00:00"
},
"file": {
"enabled": true,
"lastEnabledTime": "2019-09-27T03:33:17.441971+00:00"
},
"queue": null,
"table": null
}
}
]
14.4 Encriptação de VMs

A encriptação automática do Azure Managed Disks ajuda a fornecer um nível de segu-
rança de VM. Para uma abordagem abrangente para a segurança dos dados da VM, pode
encriptar a própria VM. Este processo envolve mais do que encriptar os discos rígidos
virtuais subjacentes. O disco do SO e todos os discos de dados anexados, juntamente
com o disco temporário, são encriptados. A memória da VM também é encriptada para
reduzir ainda mais a superfície de ataque. Utiliza chaves digitais para encriptar VMs.
Uma vantagem de encriptar toda a VM é que pode gerir as chaves de encripta-
ção. Estas chaves de encriptação são armazenadas com segurança no Azure Key Vault e
pode escolher entre utilizar chaves geradas por software e por hardware. Controla estas
chaves, para que possa definir o seu acesso e utilizar controlos de acesso baseado em
funções e as auditorias para controlar a utilização. Também pode alternar as chaves de
encriptação seguindo uma agenda definida, bem como alterar a sua palavra-passe a
cada 60 ou 90 dias. Estes controlos e tarefas de gestão adicionais para chaves de encrip-
tação adicionam alguma sobrecarga administrativa, mas fornecem flexibilidade
máxima para proteger os seus dados, e podem ser necessários para determinados
fins regulamentares. Aprofundemos um pouco mais o Azure Key Vault.
14.4.1 Armazenar chaves de encriptação no Azure Key Vault

Dedicamos o capítulo 15 ao Azure Key Vault, mas primeiro quero mostrar o poder da
encriptação de dados e da VM. Como uma descrição geral rápida, o Azure Key Vault
consiste num cofre digital que permite armazenar com segurança chaves de encripta-
ção, certificados SSL e segredos como palavras-passe. Para redundância, os cofres de
chaves são replicados entre as regiões do Azure. Esta replicação protege as suas chaves
e os seus segredos e garante que estejam sempre disponíveis para utilização.
Só você tem acesso aos seus cofres de chaves. Pode gerar e armazenar objetos em
cofres de chaves e, em seguida, definir quem tem acesso a esses cofres. A Microsoft gere
o serviço Key Vault subjacente, mas não tem acesso ao conteúdo dos cofres. Este limite
de segurança significa que quando encripta os seus dados no Azure, é o único que pode
desencriptá-los e vê-los.
Experimente agora
Para criar um cofre de chaves e uma chave de encriptação, conclua os passos a seguir:
2 Crie o cofre de chaves com o comando az keyvault create; especifique o grupo
de recursos que criou no exercício anterior, como azuremolchapter14, e forneça
um nome exclusivo para o seu cofre de chaves, como azuremolkeyvault:
az keyvault create \
--name azuremolkeyvault \
--enabled-for-disk-encryption
Vamos parar para pensar sobre o motivo pelo qual adiciona um parâmetro para --ena-
bled-for-disk-encryption. Quando encripta uma VM, a plataforma do Azure pre-
cisa de conseguir iniciar e desencriptar a VM para que esta possa ser executada. A
plataforma do Azure não tem nenhuma permissão para aceder a estes dados e a Micro-
soft não tem acesso para ver nem utilizar essas chaves de encriptação para outra finali-
dade que não seja iniciar uma VM. Quando ativa um cofre de chaves para a encriptação
de discos, concede permissões para que o Azure aceda ao cofre de chaves e utilize a
chave de encriptação associada a uma VM.
Recapitulando, a Microsoft não tem acesso a essas chaves ou aos seus dados, apenas
tem a capacidade de iniciar a sua VM encriptada. É bastante difícil fazer algo com uma
VM encriptada quando esta não pode arrancar. A figura 14.5 mostra como a plataforma
do Azure utiliza a chave de encriptação para iniciar uma VM encriptada.
2. A plataforma do Azure pede a

Plataforma chave de encriptação do cofre
1. A plataforma do Azure tenta do Azure de chaves para desencriptar e
iniciar a VM encriptada. Obtém iniciar a VM
detalhes para a chave de
encriptação necessária. 3. Cofre de chaves
ativado para
4. VM iniciada com encriptação de
sucesso discos e devolve a Azure Key Vault
VM do chave necessária
Azure Chave de
encriptação
Figura 14.5 Quando um cofre de chaves está ativado para a encriptação de discos, concede permissão para
que a plataforma do Azure peça e utilize a chave de encriptação para iniciar uma VM encriptada com sucesso.
As chaves podem ser criadas e armazenadas no software ou podem ser armazenadas

em módulos de segurança de hardware (HSMs) para segurança adicional. Para muitos
propósitos, as chaves de software funcionam muito bem, embora possa ter exigências
de segurança que exijam a utilização de HSMs. Iremos discutir esta questão com mais
detalhe no capítulo 15.
Encriptação de VMs 213
3 Para criar uma chave, especifique o cofre que criou no passo 2, como azure-
molkeyvault, e forneça um nome para a chave, como azuremolencryptionkey:
az keyvault key create \
--vault-name azuremolkeyvault \
--name azuremolencryptionkey \
--protection software
14.4.2 Encriptar uma VM do Azure

A chave de encriptação que criou na secção 14.4.1 pode ser usada para encriptar mui-
tas VMs, se desejar. Esta abordagem minimiza a sobrecarga de gestão de chaves e, se
utilizar conjuntos de dimensionamento de máquinas virtuais permite-lhe dimensionar
automaticamente o número de instâncias de VM sem a necessidade de gerar chaves de
encriptação cada vez. A alternativa é que cada VM tenha uma chave de encriptação
própria, que adiciona complexidade mas fornece uma camada de segurança para as
suas VMs. Se tiver a mesma chave de encriptação utilizada para VMs de aplicação de
back-end e VMs de base de dados, por exemplo, um intruso hipotético com essa chave
poderia ter acesso aos dados de ambos os conjuntos de VMs. Se forem utilizadas chaves
diferentes, o número de VMs potencialmente comprometidas é menor. No laboratório
de fim de capítulo, irá encriptar uma única VM, embora o mesmo processo possa fun-
cionar com um conjunto de escala que tenha várias VMs mas que utiliza apenas uma
chave. Especialmente quando trabalhar com aplicações maiores de dimensionamento
automático, certifique-se de que concebe e cria funcionalidades de segurança.
Quando encripta uma VM, é instalada uma extensão de VM do Azure. A extensão
controla a encriptação do disco do SO, disco temporário, todos os discos de dados ane-
xados e dados em memória, como mostrado na figura 14.6. No caso das VMs Windows,
é utilizado o mecanismo de encriptação BitLocker. No caso das VMs Linux, é utilizado
o dm-crypt para processar a encriptação. Em seguida, a extensão de VM pode reportar
o estado de encriptação e desencriptar a VM conforme pretendido.
Quando encripta uma VM, a VM do Azure

extensão de encriptação de
discos de VM é instalada na VM. Extensão de Bitlocker /
Extensão encriptação de Processo
discos de VM A extensão gere os DM-Crypt
processos a nível do
SO para encriptar
/desencriptar dados.
Figura 14.6 Quando encripta uma VM, a extensão de encriptação de discos do Azure é instalada. Esta
extensão gere a utilização do BitLocker em VMs Windows ou dm-crypt em VMs Linux, para executar a
encriptação de dados na sua VM. A extensão também é utilizada quando consulta o estado de
encriptação de uma VM.
Como a extensão de encriptação de discos de VMs depende do BitLocker ou do

dm-crypt, há algumas limitações quanto à utilização da encriptação de VMs. A maioria
das imagens do Azure Marketplace suporta a encriptação de discos, embora existam
algumas restrições aos tamanhos de VMs que suportam a encriptação ou a encriptação

de partilhas de ficheiros de rede ligados, como ficheiros do Azure. Para obter as infor-
mações mais abrangentes sobre as limitações e considerações suportadas para a encrip-
tação de VMs, leia os documentos mais recentes do Azure em http://mng.bz/yyvd.
Este capítulo forneceu uma introdução rápida às funcionalidades de encriptação e
segurança de dados no Azure. A encriptação automática de discos geridos e a SSE não
requerem muita configuração, portanto, não há nenhuma barreira real para impedi-lo
de utilizá-las.
14.5 Laboratório: encriptar uma VM

Vamos ver tudo isto em ação através da encriptação de uma VM com a chave de encrip-
tação que armazenou no cofre de chaves:
1 Crie uma VM. A maioria das imagens do Linux no Azure Marketplace oferece
suporte à encriptação, assim como as imagens do Windows Server do Server 2008
R2 e posterior. Para agilizar e facilitar, crie uma VM Ubuntu LTS, assim como fez
na maior parte deste livro. Como a VM requer memória suficiente para executar
a operação de encriptação do disco, especifique um tamanho de
Standard_D2s_v3:
az vm create \
--name molvm \
--image ubuntults \
--size Standard_D2s_v3 \
--generate-ssh-keys
2 Ative a encriptação na VM e forneça o nome da chave Azure Key

Vault e a chave digital que criou num exercício anterior:
az vm encryption enable \
--name molvm \
--disk-encryption-keyvault azuremolkeyvault \
--key-encryption-key azuremolencryptionkey
Leva alguns minutos a instalar a extensão de encriptação de discos de VMs do

Azure e a começar o processo de encriptação da VM.
3 Após a encriptação ser iniciada, monitorize o progresso e esteja preparado para
reiniciar a VM para concluir o processo de encriptação. Veja o estado da seguinte
maneira:
az vm encryption show \
--name molvm \
--query ‘status’
Veja uma saída de exemplo de uma VM em processo de encriptação. No início, a

mensagem de estado reporta como
[
{
Laboratório: encriptar uma VM 215
"code": "ProvisioningState/succeeded",
"displayStatus": "Provisioning succeeded",
"level": "Info",
"message": "OS disk encryption started",
"time": null
}
]
A encriptação de discos pode demorar um pouco, por isso sugiro que espere
cerca de uma hora antes de voltar a este exercício prático, a menos que pretenda
fazer uma longa pausa para o almoço! Atenção, não me considero o seu chefe, mas
ficará rapidamente entediado ao ver a mesma mensagem de estado da
encriptação.
4 Quando o estado da encriptação reportar Encriptação com êxito para todos
os volumes, reinicie a VM:
az vm restart --resource-group azuremolchapter14 --name molvm
Em seguida, pode verificar novamente o estado de encriptação de VMs com az vm

encryption show para confirmar que a VM é reportada como Encriptada.
Não se esqueça das suas tarefas de limpeza

Estes últimos dois laboratórios de fim de capítulo não demoraram muito a serem con-
cluídos, mas podem ter levado algum tempo a terminar. Não se esqueça de voltar atrás e
eliminar os recursos quando terminar.
Como discutido no capítulo 13, lembre-se de que precisa de desativar a proteção do
Azure Backup ou do Site Recovery antes de poder eliminar o cofre do Recovery Services
ou o grupo de recursos (depois de aguardar que decorram os 14 dias para que os pontos
de recuperação gratuitos de eliminação recuperável expirem). Certifique-se de que volta
atrás e limpa os recursos de laboratório antes que comecem a utilizar
muitos dos seus créditos gratuitos do Azure.
Proteger informações com o Azure
Key Vault
15
Quase todas as semanas, surgem notícias de um incidente de cibersegurança a envolver
uma grande empresa. Da mesma forma que utilizou várias formas de automatização
para aumentar ou replicar as suas aplicações e dados, os hackers automatizam as suas
próprias ações. É improvável que uma única pessoa vá tentar manualmente comprome-
ter a segurança dos seus sistemas. Este conceito dificulta a defesa dos seus sistemas 24
horas por dia, 7 dias por semana, 365 dias por ano (está bem, ou 366 dias!).
No capítulo 14 discutimos como encriptar os seus dados e VMs. Este processo é um
ótimo primeiro passo e examinámos brevemente como criar e utilizar chaves de encrip-
tação armazenadas com o serviço Azure Key Vault. É melhor armazenar os dados segu-
ros, como chaves, segredos e certificados, num cofre digital, como um cofre de chaves,
que pode gerir, emitir e auditar centralmente a utilização das suas credenciais e dados
críticos. Como as suas aplicações e serviços precisam de acesso a diferentes recursos,
podem automaticamente pedir, obter e utilizar estas chaves, segredos e credenciais.
Neste capítulo, irá aprender por que e como criar um cofre de chaves seguro, controlar
o acesso e, em seguida, armazenar e obter segredos e certificados.
15.1 Proteger informações na cloud

À medida que as aplicações se tornam mais complexas e o risco de ciberataques
aumenta, a segurança torna-se uma parte crítica de como concebe e executa os seus
serviços. Especialmente à medida que executa aplicações mais interessantes, on-pre-
mises ou na cloud, certificar-se de minimizar o risco de acesso a dados não autoriza-
dos deve ser uma das principais áreas de conceção em que se concentra. Não faz
sentido ter a maior pizzaria do mundo se os clientes não fornecerem os seus dados
de pagamento ou dados pessoais porque não confiam em si.
216
Proteger informações na cloud 217
Uma maneira comum de fornecer segurança para aplicações e serviços é através de

chaves digitais, segredos e certificados, como mostrado na figura 15.1. Em vez de utili-
zar um nome de utilizador e uma palavra-passe que devem ser introduzidos de vez em
quando manualmente, ou, talvez ainda pior, escritos num ficheiro de configuração não
encriptado, utiliza um cofre digital para armazenar essas credenciais e os dados segu-
ros. Quando uma aplicação ou serviço requer acesso, pede a chave ou o segredo especí-
fico de que necessita, e também é criado um registo de auditoria
para controlar qualquer possível uso indevido ou violação de segurança.
Aplicações VMs Serviços
As aplicações e os serviços,
ou recursos do Azure, como
VMs, podem ver, criar e
atualizar itens no cofre.
Chave Cofre
Itens, como certificados,
chaves e segredos (como
palavras-passe) podem ser
armazenados com segurança
no Vault e auditar o seu acesso.
Certificados Segredos Chaves
Figura 15.1 O Azure Key Vault fornece uma maneira segura de armazenar as informações digitais, como
certificados, chaves e segredos. Em seguida, estes itens seguros podem ser acedidos diretamente pelas
suas aplicações e serviços, ou recursos do Azure, tais como VMs. Com a interação humana mínima, pode
distribuir centralmente credenciais e certificados seguros pelos seus ambientes de aplicações.
Quando concebidos e implementados corretamente, estes cofres digitais são quase

totalmente automatizados e seguros. Os serviços podem pedir um novo certificado
digital, ter um emitido que seja armazenado de forma segura no cofre, e utilizá-lo em
outros componentes da aplicação. Os servidores podem configurar o software através
da obtenção de segredos como palavras-passe do cofre digital e através da instalação de
componentes de aplicações, sem que as credenciais sejam armazenadas num ficheiro
de configuração baseado em texto. Um administrador de aplicação pode gerir central-
mente todos os segredos, chaves e certificados para um serviço e atualizá-los regular-
mente, conforme necessário.
O Azure Key Vault fornece todas estas funcionalidades de segurança digital e permi-
te-lhe controlar rigidamente quais utilizadores e recursos podem aceder aos dados
seguros. Os cofres de chaves podem ser replicados com segurança para redundância e
desempenho melhorado da aplicação e integram-se em recursos comuns do Azure,
como VMs, aplicações Web e contas do Azure Storage.
15.1.1 Cofres de software e módulos de segurança de hardware

Antes de avançarmos para um exemplo prático de como criar e utilizar um cofre de cha-
ves, é importante entender a maneira como as suas informações seguras são armazenadas
num cofre. Como mostrado na figura 15.2, todas as chaves, segredos e certificados num
cofre de chaves são armazenados num módulo de segurança de hardware (HSM). Estes
218 Capítulo 15 Proteger informações com o Azure Key Vault
dispositivos não são exclusivos no Azure; são dispositivos de hardware de todo o setor, que
fornecem um alto nível de segurança para todos os dados armazenados.
Azure Key Vault
Todos os certificados, segredos Software - protected vault

e chaves de um cofre de chaves
são armazenados em módulos Operações de
Para os cofres protegidos por encriptação
de segurança de hardware nos
software, as operações de
datacenters do Azure.
encriptação/desencriptação são
executadas no software, fora do
limite do HSM.
Hardware security module (HSM)
Certificados Segredos Chaves
Figura 15.2 O Azure Key Vault é um recurso lógico no Azure, mas todos os certificados, segredos e
chaves são armazenados num HSM. Em cenários de desenvolvimento ou teste, pode ser utilizado um
cofre protegido por software, que então executa qualquer operação de encriptação criptográfica, como
a encriptação ou a desencriptação de dados, no software, e não no hardware no HSM. Em ambientes de
produção, deve utilizar um cofre protegido por HSM, onde todo o processamento é realizado no hardware.
Atualmente, pode utilizar dois tipos de cofres de chaves: protegido por software e pro-
tegido por HSM. A diferença pode parecer confusa, por isso é que quero esclarecer
tudo antes de começarmos:
¡ Um cofre protegido por software armazena chaves, segredos e certificados num HSM,
mas todas as operações criptográficas necessárias para encriptar ou desencriptar
o seu conteúdo são executadas pela plataforma Azure no software. Os cofres pro-
tegidos por software são ótimos para cenários de desenvolvimento e teste, embora
possa decidir que os workloads de produção requerem uma maneira um pouco
mais segura para executar as operações criptográficas.
¡ Um cofre protegido por HSM também armazena chaves, segredos e certificados num
HSM, e as operações criptográficas necessárias para encriptar ou desencriptar o
seu conteúdo são executadas diretamente no HSM. Também pode gerar as suas
próprias chaves seguras num HSM on-premises e, em seguida, importá-las para o
Azure. Existem algumas ferramentas e processos adicionais a serem seguidos, mas
desta forma garante que controla completamente as chaves e que estas nunca
saem dos limites do HSM.
Para maximizar a segurança e a integridade dos seus dados, os
cofres protegidos por hardware são a abordagem preferencial dos workloads de
produção.
Independentemente de qual tipo de cofre utiliza, é importante lembrar que todos os seus
dados são armazenados com segurança num HSM validado (no mínimo) com o Padrão
Federal de Processamento de Informações (FIPS) 140–2 nível 2, e que a Microsoft não
Proteger informações na cloud 219
pode aceder às chaves ou obtê-las. Os cofres protegidos pelo HSM são um custo adicional.
Portanto, como em todos os aspetos do Azure e do cloud computing, deve comparar o
custo com o risco incorrido em caso de comprometimento dos seus dados.
15.1.2 Criar um cofre de chaves e segredo

Um cofre digital parece ótimo, mas pode estar um pouco inseguro sobre como explorar
toda a potência do Azure Key Vault. Vamos criar um exemplo de um servidor básico que
executa uma base de dados como o MySQL Server, como mostrado na figura 15.3.
2. Se o acesso ao cofre de
chaves e ao segredo for
1. A VM pede o segredo do
permitido, o segredo é
cofre de chaves
obtido a partir do cofre
Palavra-passe da
VM Linux Chave Cofre base de dados
3. Segredo devolvido à VM
4. O segredo é utilizado para

fornecer uma palavra-passe segura
para instalar o MySQL Server
Instalação do
MySQL Server
Figura 15.3 Nos próximos exercícios, irá criar um exemplo de um segredo armazenado
num cofre de chaves que pode ser utilizado como a palavra-passe da base de dados para
uma instalação do MySQL Server. É criada uma VM com permissões para pedir o
segredo do cofre de chaves. Em seguida, o segredo obtido é utilizado para introduzir
automaticamente uma credencial segura durante o processo de instalação da aplicação.
Um dos primeiros exercícios deste livro foi criar uma VM e, em seguida, instalar o
LAMP stack do servidor Web. Provavelmente precisou de fornecer uma palavra-passe
do MySQL Server ou foi utilizada automaticamente uma palavra-passe em branco.
Agora que sabe tudo sobre cofres de chaves, pode obter automaticamente uma pala-
vra-passe do cofre e utilizá-la dinamicamente para instalar e configurar o servidor.
Experimente agora
Para criar um cofre de chaves e adicionar um segredo, conclua os passos a seguir:
1 Abra o portal Azure, execute o Cloud Shell e crie um grupo de recursos, como
o azuremolchapter15:
2 Crie um cofre de chaves com um nome único, tal como azuremol, e ative-o para
implementação para que possa utilizar o cofre para injetar chaves e certificados
numa VM:
az keyvault create \
--name azuremol \
--enable-soft-delete \
--enabled-for-deployment
Por predefinição, a sua conta de utilizador do Azure recebe permissões comple-

tas para o cofre de chaves. Para estes exercícios, isso é suficiente, embora como
uma melhor prática de segurança, deva considerar limitar quem pode aceder ao
seu cofre de chaves. Pode adicionar o parâmetro --no-self-perms para ignorar a
atribuição de permissão à sua conta
3 Crie um segredo, tal como databasepassword, e atribua um valor de palavra-
-passe, como SecureP@ssw0rd. (Sim, muito seguro, certo?) Este segredo pode ser
utilizado como as credenciais de um servidor de base de dados, que irá imple-
mentar nos seguintes exercícios:
az keyvault secret set \
--name databasepassword \
--vault-name azuremol \
--description "Database password" \
--value "SecureP@ssw0rd"
4 Tem permissões completas para o cofre de chaves, para que possa ver o conteúdo
do seu segredo:
az keyvault secret show \
--vault-name azuremol
Do ponto de vista da gestão, também pode executar ações comuns, como fazer cópias
de segurança e restaurar, fazer downloads, atualizar e eliminar itens armazenados num
cofre de chaves. Uma propriedade adicional que se define ao criar o cofre de chaves é
a opção enable-soft-delete. Se as suas aplicações e serviços não puderem obter os
segredos que precisam do cofre de chaves, poderá deparar-se com uma interrupção da
aplicação bastante grande! Um cofre de chaves pode armazenar metadados dos segre-
dos durante até 90 dias depois de terem sido realmente eliminados, o que lhe permite
recuperar os dados que são eliminados de forma incorreta ou maliciosa.
5 Elimine a chave que acabou de criar para simular um erro, ou possivelmente
alguém com intenção maliciosa:
az keyvault secret delete \
6 Recupere o segredo para que possa continuar a utilizar a palavra-passe da base

de dados com a sua aplicação e os seus serviços:
Identidades geridas para recursos do Azure 221
az keyvault secret recover \

Se realmente pretender remover um segredo, também tem a opção de limpar um

segredo eliminado. Esta opção remove permanentemente o segredo sem aguardar o
período de recuperação predefinido de 90 dias.
Fique à vontade para utilizar az keyvault secret show novamente para ver as infor-
mações sobre o seu segredo e confirmar que a palavra-passe que armazenou está lá,
após a eliminar e restaurar. Agora, vamos avançar para ver como uma VM pode aceder a
um cofre de chaves e utilizar o segredo para instalar o MySQL Server.
15.2 Identidades geridas para recursos do Azure

A capacidade de utilizar o Azure Key Vault para armazenar segredos ou chaves é ótima,
mas como acede a estes segredos? A CLI do Azure ou o Azure PowerShell podem ace-
der às informações armazenadas num cofre de chaves, mas geralmente é mais conve-
niente permitir que as suas VMs ou aplicações obtenham diretamente os segredos ou
as chaves quando precisarem deles. Uma maneira de fazer isso é com identidades geri-
das de recursos do Azure, conforme mostrado na figura 15.4.
Azure Active
1. Principal de serviço, um tipo Directory
especial de conta, criado no
Azure Active Directory Principal de serviço
Ativar a identidade
de serviço gerida
numa VM do Azure
Instance 3. A VM utiliza o Instance
Metadata Service para pedir
Metadata o token de acesso para se
Service ligar a um serviço ou recurso
2. Identidade de serviço gerida

aplicada a uma VM que VM do Recurso do
concede acesso aos recursos
do Azure Azure 4. Token de acesso utilizado Azure
para se ligar ao recurso,
como para obter o segredo
do cofre de chaves
Figura 15.4 Quando cria uma identidade gerida para uma VM, é criado um principal de serviço no Azure Active
Directory. Este principal de serviço é um tipo especial de conta que pode ser utilizado para os recursos se
autenticarem. Em seguida, esta VM utiliza o endpoint de Instance Metadata Service para efetuar pedidos de
acesso aos recursos. O endpoint liga-se ao Azure AD para pedir tokens de acesso quando a VM precisa de pedir
dados a partir de outros serviços. Quando um token de acesso é devolvido, pode ser utilizado para pedir acesso aos
recursos do Azure, como um cofre de chaves.
Uma identidade gerida permite criar um tipo especial de conta que pode ser usada por
um recurso do Azure, como uma VM. Se tiver utilizado um serviço de diretório como o
Active Directory, é frequentemente utilizada uma conta de computador para identifi-
car e conceder acesso aos vários recursos de rede de que um computador precisa. Não
cria e utiliza contas de utilizador regulares para este tipo de autenticação, o que
melhora a segurança: pode conceder um conjunto restritivo de permissões apenas a
um computador, em vez de também ter de se preocupar com permissões de utilizador
e acesso às pastas partilhadas, por exemplo.
Uma identidade gerida é como uma conta de computador, mas é armazenada no
Azure Active Directory (Azure AD). A identidade, denominada principal de serviço, é
exclusiva a cada VM e pode ser utilizada para atribuir permissões a outros recursos do
Azure, como uma conta do Azure Storage ou um cofre de chaves. A VM tem permissões
para aceder a esses recursos, para que possa executar tarefas de script (como a Automa-
tion do Azure, que iremos explorar no capítulo 18) que não requerem nenhuma inter-
venção do utilizador ou que não requer nomes de utilizadores e palavras-passe. As VMs
autenticam-se e a plataforma do Azure autoriza o acesso aos recursos atribuídos.
É possível criar dois tipos de identidades geridas:
¡ Atribuído pelo sistema— Este tipo de identidade gerida é aplicada diretamente a um
recurso, como uma VM, e é utilizado apenas por esse recurso. Cada recurso tem a
sua própria identidade única quando se trata de auditoria ou resolução de pro-
blemas de acesso. Quando o recurso é eliminado, a identidade gerida é eliminada
automaticamente.
¡ Atribuído pelo utilizador—Um recurso Azure separado é criado e gerido para a identi-
dade gerida especificada. Esta identidade gerida pode ser partilhada através de
outros recursos para definir o acesso. Quando quaisquer recursos que utilizam a
identidade são eliminados, a identidade gerida permanece disponível para uso.
Vamos ver como pode utilizar uma identidade gerida atribuída pelo sistema para pedir
o segredo databasepassword de um cofre de chaves. Assim que a VM consiga obter o
segredo, a palavra-passe pode ser utilizada para instalar automaticamente um servidor
de base de dados MySQL. Com um cofre de chaves e MSIs, pode executar alguns
comandos para obter o segredo do cofre de chaves, executar o instalador do MySQL
Server e fornecer automaticamente a palavra-passe segura.
Azure Instance Metadata Service

Uma VM ativada com uma identidade gerida utiliza um endpoint REST por meio do Ins-
tance Metadata Service (IMDS) para pedir um token de acesso a partir do Azure AD que
pode, então, utilizar para pedir dados a partir do Azure Key Vault. Mas o que é o Instance
Metadata Service?
IMDS é um endpoint REST que só é acessível internamente às VMs. O endpoint está dispo-
nível no endereço não encaminhável 169.254.169.254. Uma VM pode efetuar um pedido
ao endpoint IMDS para obter informações sobre si mesmo, como a região do Azure ou o
nome do grupo de recursos. Esta capacidade permite que a VM entenda como e onde na
plataforma do Azure está em execução. O endpoint IMDS pode ser acedido a partir de
várias linguagens diferentes, incluindo Python, C#, Go, Java e PowerShell.
Identidades geridas para recursos do Azure 223
No caso de eventos de manutenção, o endpoint IMDS também pode ser consultado para
que a VM fique ciente de um evento de atualização ou arranque pendente. Qualquer
tarefa de pré-atualização ou arranque necessárias podem ser executadas. Como o IMDS
é um endpoint REST num endereço IP não encaminhável, não há nenhum agente ou
extensão para a VM ser instalada nem representa nenhum problema de segurança de
rede ou encaminhamento.
Para finalidades da identidade gerida, o endpoint IMDS é utilizado para reencaminhar
o pedido de um token de acesso ao Azure AD. Esta abordagem fornece uma maneira segura
para que as VMs peçam acesso sem a necessidade de falar diretamente com o AAD.
Experimente agora
Para criar uma VM com uma MSI, conclua os passos a seguir:
1 Crie uma VM Ubuntu; em seguida, forneça o seu grupo de recursos, como azu-
remolchapter15 e um nome para a VM, como molvm. Uma conta de utilizador
denominada azuremol é criada e as chaves SSH que utilizou nos capítulos ante-
riores são adicionadas à VM:
az vm create \
--name molvm \
--image ubuntults \
--generate-ssh-keys
2 Como uma melhor prática de segurança, não deve permitir que as contas acedam
a todos os recursos em toda a sua subscrição do Azure. Especialmente para identi-
dades geradas, conceda apenas a quantidade mínima necessária de permissões.
Para este exercício, limite o acesso apenas ao seu grupo de recursos, tal como azu-
remolchapter15. Defina o âmbito consultando o ID do grupo de recursos com
--query id. Em seguida, este ID é então atribuído a uma variável denominada scope:
scope=$(az group show --resource-group azuremolchapter15
➥--query id --output tsv)
3 Crie uma identidade gerida atribuída por sistemas para a VM com a função de
leitura para que só possa ler recursos, e não fazer alterações nos mesmos. Limite
a identidade ao grupo de recursos. A variável que criou no passo anterior que
contém o ID do grupo de recursos é fornecida:
az vm identity assign \
--name molvm \
--role reader \
--scope $scope
4 Aplique permissões ao Azure Key Vault que concedam acesso ao principal de

serviço para a identidade gerida. Pode fazê-lo através do portal em Políticas de
Acesso o recurso Key Vault ou pode utilizar o Azure CLI. Vamos usar o CLI para
ver como obter a informação através de programação.
Primeiro, obtenha informações sobre o principal de serviço do Azure AD para
a sua identidade gerida. Filtre no display-nome da VM que criou no passo 3, tal
como o molvm:
az ad sp list \
--display-name molvm \
--query [].servicePrincipalNames
A saída é semelhante ao seguinte exemplo condensado. Não se preocupe

muito com o que estes valores significam; não precisa de trabalhar com eles para
além de atribuir as permissões iniciais aqui. Mais uma vez, pode utilizar o portal
Azure para evitar o CLI se estiver desconfortável.
Anote o primeiro servicePrincipalName. Este valor é utilizado para
atribuir permissões em recursos do Azure, como o seu cofre de chaves, e é neces-
sário no próximo passo:
[
"887e9665-3c7d-4142-b9a3-c3b3346cd2e2",
"https://identity.azure.net//
➥ihxXtwZEiAeNXU8eED2Ki6FXRPkklthh84S60CiqA4="
]
5 Agora, defina a política de acesso no cofre de chaves para que o principal de ser-
viço da sua VM possa ler segredos, e introduza o seu primeiro servicePrinci-
palName do passo 4:
az keyvault set-policy \
--name azuremol \
--secret-permissions get \
--spn 887e9665-3c7d-4142-b9a3-c3b3346cd2e2
Um ponto aqui é que quando a identidade gerida foi criada e limitada ao grupo de
recursos, isto não significou que a VM podia realizar todas as tarefas que quisesse. Pri-
meiro, a única função criada para a identidade foi conceder-lhe permissões para ler os
recursos. Mas, ainda tinha de atribuir permissões ao cofre de chaves em si. Estas cama-
das de segurança e permissões permitem-lhe controlar de forma granular os recursos
exatos aos quais cada identidade pode aceder.
Agora que tem acesso a um cofre de chaves, provavelmente quer saber como obter o
segredo, certo?
15.3 Obter um segredo de uma VM com identidade gerida

Armazenou um segredo num cofre de chaves para uma palavra-passe da base de dados,
e tem uma VM com uma identidade gerida que concede o acesso para ler esse segredo
a partir do cofre de chaves. E agora? Como obtém e utiliza o segredo? A figura 15.5
mostra como uma VM utiliza o IMDS para pedir o acesso a um recurso, tal como um
cofre de chaves. Vamos percorrer os passos para ver como a VM obtém o segredo.
Obter um segredo de uma VM com identidade gerida 225
A maioria dos casos de utilização do Azure Key Vault não teria uma VM a ligar e a
obter os segredos desta forma. O Key Vault é realmente útil quando as próprias aplica-
ções, dentro do código, ligam-se para obter segredos. O código de aplicação utilizaria o
Azure SDK apropriado, como Python, .Net ou Java. Para evitar complexidades de resu-
mir o que está a acontecer através da codificação, o seguinte exercício utiliza uma VM e
algum trabalho com a linha de comandos. À medida que trabalha neste exercício, lem-
bre-se que esta magia normalmente aconteceria no código da aplicação.
1. A VM efetua o pedido HTTP para o endpoint

do Instance Metadata Service (IMDS)
curl 'http://169.254.169.254/metadata/identity/oauth2/token?api
version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net'
Instance
Azure Metadata
VM 3. Token de acesso devolvido do Service
5. Segredo do cofre Azure Active Directory
2. O IMDS transmite o
de chaves para pedido de VM do token de
databasepassword 4. Token de acesso acesso para o Azure Active
devolvido à VM utilizado pela VM para Directory para o recurso
pedir acesso ao recurso, de destino
como o cofre de chaves
Azure Active
Azure Key Vault
Directory
databasepassword Principal de serviço
secret
Figura 15.5 A VM utiliza o IMDS para pedir o acesso a um cofre de chaves. O endpoint comunica com
o Azure AD para pedir um token de acesso. O token de acesso é devolvido à VM, que é utilizado para pedir
o acesso a partir do cofre de chaves. Se o acesso for concedido pelo cofre de chaves, o segredo para
databasepassword é devolvido à VM.
Experimente agora
Para obter e utilizar um segredo numa VM com uma identidade gerida conclua os
passos a seguir:
1 Obtenha o endereço IP público da VM criada no exercício anterior,

tal como molvm:
az vm show \
--name molvm \
--show-details \
--query [publicIps] \
--output tsv
2 SSH para a sua VM, como ssh azuremol@publicIps.

3 Para aceder a um cofre de chaves, precisa de um token de acesso. Este token de acesso
é pedido a partir do IMDS. É um pedido HTTP, e numa VM Linux pode utilizar o pro-
grama curl para efetuar o pedido. O IMDS transmite o seu pedido ao AAD:
curl 'http://169.254.169.254/metadata/identity/oauth2/token?
➥api-version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net'
➥-H Metadata:true
4 A saída é um pouco difícil de ler, porque o texto não parece ter pés nem cabeça.
Está no formato JSON Web Token (JWT). Para processar a saída JSON e tornar
as coisas mais legíveis, instale um analisador JSON denominado jq:
sudo apt-get update && sudo apt-get -y install jq
5 Efetue o seu pedido curl novamente, mas desta vez veja a saída com jq:
curl 'http://169.254.169.254/metadata/identity/oauth2/token?
➥-H Metadata:true --silent | jq
Estes primeiros passos mostram como os pedidos são efetuados e como é a saída, como
mostrado na figura 15.6. Se ainda iniciar sessão na VM e pedir manualmente um token
de acesso, qual é o sentido de utilizar uma identidade gerida? Poderia apenas fornecer
as suas próprias credenciais. Em ambientes de produção, provavelmente iria utilizar
um script executado na VM para efetuar automaticamente o pedido de um token de
acesso e, em seguida, obter o segredo a partir do cofre da chave. Vamos avançar para
ver como automatiza este processo e obtém o segredo.

version=201802-01&resource=https%3A%2F%2Fvault.azure.net'
VM do Instance
Azure Metadata
3. Token de acesso devolvido Service
5. Segredo do cofre do Azure Active Directory
2. O IMDS transmite o
de chaves para pedido de VM do token de
databasepassword 4. Token de acesso
acesso para o Azure Active
devolvido à VM utilizado pela VM para
Directory para o recurso
pedir acesso ao recurso,
de destino
como o cofre de chaves
Azure Active
Azure Key Vault
Directory
secret
Figura 15.6 O pedido curl cobre os três primeiros passos deste diagrama. O pedido curl é efetuado,
o endpoint comunica com o Azure AD e um token de acesso é emitido.
6 Para facilitar o processo (e se vai realizá-lo num script) pode utilizar jq para
processar a resposta de curl, extrair apenas o token de acesso e defini-lo como
uma variável denominada access_token:
access_token=$(curl
➥'http://169.254.169.254/metadata/identity/oauth2/token?
➥-H Metadata:true --silent | jq -r '.access_token')
7 Como um passo manual para ajudá-lo a entender como isto se parece, veja
a variável access_token:
echo $access_token
8 Agora, a parte divertida! Utilize o token de acesso para pedir o seu segredo a par-
tir do cofre de chaves. Vamos primeiro fazer isso manualmente para que entenda
o que acontece.
9 Obtenha o segredo com outro pedido curl e formate a saída com jq. Introduza
o seu próprio nome de cofre de chaves no início do https:// address:
curl https://azuremol.vault.azure.net/secrets/databasepassword?
➥api-version=2016-10-01 -H "Authorization: Bearer $access_token"
➥--silent | jq
A saída é semelhante à seguinte, que mostra o valor da palavra-passe armazenada
no segredo, juntamente com alguns metadados adicionais sobre o segredo, com
os quais não precisa de se preocupar agora:
{
"value": "SecureP@ssw0rd!",
"contentType": "Database password",
"id":
➥"https://azuremol.vault.azure.net/secrets/databasepassword/
➥87e79e35f57b41fdb882c367b5c1ffb3",
}
Este pedido curl é a segunda parte do workflow, como mostrado na figura 15.7.

version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net'
Instance
VM do
Metadata
Azure
3. Token de acesso devolvido Service
do Azure Active Directory
5. Segredo do cofre
de chaves para 2. O IMDS transmite o
databasepassword 4. Token de acesso pedido de VM do token de
devolvido à VM utilizado pela VM para acesso para o Azure Active
pedir acesso ao recurso, Directory para o recurso
como o cofre de chaves de destino
Azure Active
Azure Key Vault
Directory
secret
Figura 15.7 Este segundo pedido curl cobre os dois últimos passos no diagrama. O token de acesso é utilizado
para pedir o segredo a partir do cofre de chaves. A resposta JSON é devolvida, incluindo o valor do segredo.
10 Da mesma forma que utilizou uma variável para armazenar o token de acesso,
pode, num script, atribuir também o valor do segredo a uma variável. Desta vez,
utilize jq para processar a resposta, extraia apenas o valor secreto e defina-o
como uma variável denominada database_password:
database_password=$(curl
➥https://azuremol.vault.azure.net/secrets/databasepassword?
➥--silent | jq -r '.value')
11 Mais uma vez, como um passo manual para ajudá-lo a entender o processo, veja o
conteúdo da variável database_password:
echo $database_password
Espero que esteja a acompanhar! Se escrever uma aplicação em Python, ASP.NET ou

Node.js, por exemplo, o processo será semelhante ao para efetuar um pedido de um
token de acesso e, em seguida, utilizar o token para pedir um segredo a partir de um
cofre de chaves. Há provavelmente outras bibliotecas que poderia utilizar no seu
código, em vez do utilitário jq na linha de comandos.
Como uma recapitulação rápida, todos estes passos podem ser condensados em duas
linhas, como mostrado na listagem a seguir.
Listing 15.1 Pedir um token de acesso e, em seguida, um segredo a partir de um

cofre de chaves
access_token=$(curl
➥'http://169.254.169.254/metadata/identity/oauth2/token?
➥-H Metadata:true --silent | jq -r '.access_token')
database_password=$(curl
➥https://azuremol.vault.azure.net/secrets/databasepassword?
➥-silent | jq -r '.value')
E agora? A identidade gerida para a sua VM pode recuperar um segredo de um cofre

de chaves. Vejamos como pode utilizar essa identidade gerida para instalar e configu-
rar o MySQL Server.
No Ubuntu, pode definir seleções de configuração para instaladores de pacotes,
como o MySQL Server. Estas seleções de configuração permitem-lhe fornecer valores
como nomes de utilizador e palavras-passe e que utilizá-los automaticamente na parte
relevante do processo de instalação. Os pedidos manuais para fornecer manualmente
uma palavra-passe, mostrados no capítulo 2, desapareceram.
12 Defina as seleções de configuração para as palavras-passe do MySQL Server com
a variável database_password que criou no passo 10:
sudo debconf-set-selections <<< "mysql-server mysql-server/root_password
➥password $database_password"
sudo debconf-set-selections <<< "mysql-server mysql-
➥server/root_password_again password $database_password"
13 Instale o MySQL Server. Não há avisos, porque a palavra-passe é fornecida
pelas seleções de configuração:
sudo apt-get -y install mysql-server
14 Vamos provar que tudo funcionou! Veja a variável database_password para

verificar claramente qual deve ser a sua palavra-passe:
echo $database_password
15 Inicie sessão no MySQL Server. Quando for pedida uma palavra-passe, introduza o
valor de database_password, que é o valor do segredo a partir do cofre de chaves:
mysql -u root -p
Tem sessão iniciada no MySQL Server, que confirma que o segredo do cofre
de chaves foi utilizado para criar as credenciais do SQL Server com sucesso!
16 Introduza exit duas vezes para fechar a linha de comandos do MySQL Server e,
em seguida, feche a sessão SSH para a VM.
Este é um exemplo básico; ainda precisa de proteger o MySQL Server, bem como for-
necer credenciais adicionais para que as aplicações possam aceder às bases de dados
ou tabelas, por exemplo. A vantagem de utilizar um segredo a partir de um cofre de
chaves é que garante que todas as palavras-passe são as mesmas. Se utilizar conjuntos
de dimensionamento de virtual machines, por exemplo, cada instância de VM poderá
pedir automaticamente o segredo e instalar o MySQL Server para que esteja pronto
para providenciar os dados da sua aplicação. Essas palavras-passe nunca são definidas
em scripts, e ninguém precisa de ver quais são as palavras-passe. Pode até mesmo gerar
palavras-passe aleatoriamente e alterná-las como segredos num cofre de chaves.
Armazenar palavras-passe num cofre de chaves é ótimo, mas pode utilizar um cofre
de chaves para armazenar certificados e obtê-los automaticamente a partir das suas apli-
cações ou VMs? É claro que pode!
15.4 Criar e injetar certificados

Os certificados digitais são uma forma comum de segurança e autenticação em aplica-
ções e serviços Web. Os certificados são emitidos por uma autoridade de certificação
(AC), em quem (esperamos nós!) os utilizadores finais confiam. O certificado permite
aos utilizadores verificar se um site ou aplicação é realmente quem diz ser. Sempre que
vê um site com um endereço de browser que começa com https:// and has a padlock
symbol, the traffic is encrypted ane é protegido por um certificado digital.
Muitas vezes, a gestão de certificados digitais pode converter-se numa tarefa exi-
gente. Um problema comum é como armazenar e conceder acesso aos certificados à
medida que os serviços e as aplicações precisam deles. Nos exercícios anteriores, exami-
námos como um cofre de chaves pode ser utilizado para partilhar segredos e chaves
seguras com serviços e aplicações, mas um cofre de chaves também pode fazer o mesmo
com os certificados. Como mostrado na figura 15.8, um cofre de chaves pode ser utili-
zado para pedir, emitir e armazenar certificados.
Em ambientes de produção, deve utilizar sempre uma AC fidedigna para emitir os
seus certificados. Para utilização interna, pode emitir certificados autoassinados criados
por si. Estes
2. Pedido de assinatura de
1. Pedido para criar um certificado (CSR) enviado
certificado enviado para para a autoridade de
o cofre de chaves certificação (CA)
Utilizador,
aplicação ou Key Vault Autoridade de
serviço certificação
4. Certificado emitido 3. Certificado X.509
a partir do cofre de chaves assinado devolvido
e armazenado no
cofre de chaves
Figura 15.8 Um utilizador, uma aplicação ou um serviço pode pedir um novo certificado a partir de um
cofre de chaves. Um pedido de assinatura de certificado (CSR) é enviado pelo cofre de chaves para uma AC
externa de terceiros ou uma AC interna fidedigna. O Azure Key Vault também pode atuar como a sua própria
AC para gerar certificados autoassinados. Em seguida, a AC emite um certificado X.509 assinado, que é
armazenado no cofre de chaves. Finalmente, o cofre de chaves devolve o certificado ao requerente original.
certificados autoassinados não são de confiança para outros serviços e aplicações, por
isso, normalmente geram um aviso, mas os certificados autoassinados permitem-lhe
ficar operacional rapidamente e certificar-se de que o seu código funciona conforme o
esperado com o tráfego encriptado.
O Azure Key Vault pode gerar certificados autoassinados por si. De facto, o Key Vault
atua como a sua própria AC para pedir, emitir e, em seguida, armazenar certificados.
Vamos utilizar esta capacidade para gerar um certificado autoassinado e ver como inje-
tá-lo facilmente numa VM. Em seguida, o certificado é utilizado para um servidor Web
básico para mostrar como ativar rapidamente o SSL para proteger o tráfego Web.
Criar e injetar certificados 231
Experimente agora
Para criar e injetar um certificado numa VM, conclua os passos a seguir:
1 Crie um certificado autoassinado no Azure Key Vault e introduza um nome, tal

como molcert. As políticas são utilizadas para definir propriedades, como perío-
dos de tempo de expiração, força de encriptação e formato do certificado. Pode
criar políticas diferentes para satisfazer as necessidades das suas aplicações e dos
seus serviços. Neste exercício, utilize a política predefinida que cria um certifi-
cado de 2048 bits, que é válido durante um ano:
az keyvault certificate create \
--vault-name azuremol \
--name molcert \
--policy "$(az keyvault certificate get-default-policy)"
2 Para ver o certificado em ação, crie outra VM, tal como molwinvm. Desta vez, criee
uma VM do Windows que utilize o Windows Server 2019, para que espa-
lhe o amor do SO e veja que estas funcionalidades do Key Vault não dependem
de um sistema operativo específico! Forneça o seu próprio nome de utilizador e
palavra-passe de administrador:
az vm create \
--name molwinvm \
--image win2019datacenter \
--admin-password P@ssw0rd1234
3 Pode adicionar automaticamente o certificado à VM diretamente da CLI do

Azure. Esta aplicação não se baseia numa identidade gerida; a plataforma Azure
injeta o certificado utilizando o agente de VM do Windows Azure.
Adicione o seu certificado, tal como molcert, à VM criada no passo 2, tal
como molwinvm:
az vm secret add \
--name molwinvm \
--keyvault azuremol \
--certificate molcert
4 Ligue-se à VM e verifique se o certificado foi injetado corretamente. Para se ligar

à sua VM, primeiro obtenha o seu endereço IP público:
az vm show \
--name molwinvm \
--show-details \
--query [publicIps] \
--output tsv
Utilize um cliente de ligação local do Ambiente de Trabalho Remoto da Micro-

soft no seu computador para se ligar à sua VM. Utilize as credenciais para se ligar
a localhost\azuremol, não as credenciais predefinidas do seu computador local
que o cliente do Ambiente de Trabalho Remoto pode tentar utilizar, como mos-
trado na figura 15.9.
Figura 15.9 O seu cliente do Ambiente

de Trabalho Remoto pode tentar
utilizar as suas credenciais
predefinidas do computador local. Em
vez disso, selecione Utilizar uma Conta
Diferente e, em seguida, forneça as
credenciais localhost\azuremol
especificadas quando criou a VM.
5 Depois de ter sessão iniciada, selecione o botão Iniciar do Windows e introduza

mmc e abra a Consola de Gestão da Microsoft.
6 Escolha Ficheiro > Adicionar/Remover Snap-in e, em seguida, selecione a opção
para adicionar o snap-in de Certificados.
7 Escolha os certificados que pretende adicionar à conta do Computador,
selecione Seguinte e, em seguida, selecione Concluir.
8 Escolha OK para fechar a janela Adicionar/Remover Snap-in.
9 Expanda a pasta Certificados (Computador Local) > Pessoal > Certificados. O
certificado do Azure Key Vault que injetou na VM aparece listado, tal como CLI-
GetDefaultPolicy, como mostrado na figura 15.10.
Figura 15.10 Na Consola de Gestão da Microsoft, adicione o snap-in de Certificados no computador

local. Expanda o arquivo Pessoal > Certificados para ver os certificados instalados. O certificado injetado
do Key Vault aparece listado.
Laboratório: configurar um servidor Web seguro 233
É tão simples quanto isto! Crie o certificado no Key Vault e, em seguida, adicione o
certificado à VM. O certificado é colocado no arquivo de certificados local do compu-
tador, ao qual qualquer serviço ou aplicação pode aceder. Numa VM Windows, os certi-
ficados são armazenados na cache do certificado local, como mostrado neste exercício.
Em VMs Linux, os ficheiros .prv e .crt para as partes pública e privada do certificado
são armazenados em /var/lib/waagent/. Em seguida, pode mover os certificados para
a localização de que precisa para a sua aplicação ou serviço.
Os certificados podem ser utilizados para autenticação entre clientes e servidores ou
entre componentes e serviços de aplicações. Um exemplo comum é que um servidor
Web utilize um certificado SSL, que é o que irá fazer no laboratório de fim de capítulo.
15.5 Laboratório: configurar um servidor Web seguro

No último exercício, injetou um certificado autoassinado do Azure Key Vault numa
VM Windows. Neste laboratório, instale e configure o servidor Web do IIS para utilizar
o certificado, seguindo este guia:
1 Abra o PowerShell na sua VM Windows e instale o servidor Web do IIS:

Add-WindowsFeature Web-Server -IncludeManagementTools
2 Abra o Gestor de Servidor dos Serviços de Informação Internet (IIS). Pode fazer
isso no menu Ferramentas no Gestor de Servidor.
3 No Site Predefinido, escolha Editar Enlaces.
4 Adicione um enlace HTTPS em todos os endereços IP não atribuídos na porta 443.
5 Selecione o certificado auto-assinado que criou e injetou a partir do Key Vault,
normalmente nomeado como CLIGetDefaultPolicy.
6 Abra um browser na VM e introduza https://localhost. Gerou
um certificado autoassinado no Key Vault, para que o browser não confie no
mesmo.
7 Aceite o aviso para continuar e verifique se o enlace HTTPS funciona.
8 Novamente no Azure Cloud Shell ou no portal, crie uma regra do NSG para a
VM na porta TCP 443. Introduza https://yourpublicipaddress num browser
no seu computador local. Esta é a experiência que os utilizadores teriam, com
um aviso sobre um certificado autoassinado que não é de confiança. Na maioria
dos casos práticos, lembre-se de utilizar um AC interno ou terceiro para gerar
certificados fidedignos e armazená-los num cofre de chaves.
Centro de Segurança do Azure e
atualizações
16
Não seria ótimo se o Azure fosse inteligente o suficiente para monitorizar todos os
recursos core da sua aplicação e alertá-lo sobre quaisquer preocupações de segu-
rança? Ou se a sua empresa tivesse políticas de segurança já definidas? (Se não tiver
quaisquer políticas de segurança, pare agora e tome nota para criar algumas!) Neste
último caso, como garantir que as suas implementações do Azure se mantêm confor-
mes? Se já passou por uma auditoria de segurança de TI, sabe como pode ser diver-
tido olhar para uma lista de configurações erradas aplicadas ao seu ambiente,
especialmente os lapsos de segurança básica que conhece!
O Centro de Segurança do Azure fornece uma localização central para que os aler-
tas e as recomendações de segurança sejam agrupados para sua análise. Pode definir as
suas próprias políticas de segurança e, em seguida, permitir que o Azure monitorize o
estado dos seus recursos para conformidade.
Neste capítulo, iremos discutir como o Centro de Segurança pode alertá-lo de pro-
blemas e fornecer passos para corrigi-los, como pode utilizar o acesso just-in-time à VM
para controlar e auditar ligações remotas, e como a Gestão de Atualizações mantém as
suas VMs atualizadas automaticamente com os patches de segurança mais recentes.
16.1 Centro de Segurança do Azure

Ao longo deste livro, discutimos tópicos relacionados com a segurança, tais como
criar e configurar grupos de segurança de rede (NSGs) para restringir o acesso às
VMs, e como permitir apenas o tráfego encriptado para contas do Azure Storage.
Para as suas próprias implementações além dos exercícios neste livro, como sabe
por onde começar, e como pode verificar que aplicou todas as melhoras práticas de
segurança? É aí que o Centro de Segurança do Azure pode ajudar, verificando o seu
ambiente em áreas que pode ter deixado passar.
234
Centro de Segurança do Azure 235
O Centro de Segurança do Azure analisa os seus recursos, recomenda cor-

reções e ajuda a resolver as preocupações de segurança, como mostrado na figura 16.1.
Quando tiver apenas algumas VMs de teste e uma única rede virtual na sua subscrição
do Azure, talvez não pareça difícil controlar quais restrições de segurança precisa de
implementar. Mas, à medida que dimensiona até dezenas, centenas ou até milhares de
VMs, manter manualmente o controlo de quais configurações de segurança precisam
de ser aplicadas a cada VM poderá deixar de ser gerível.
Redes
VMs Storage Aplicações
virtuais
Monitorizar Figura 16.1 O Centro de

Gerar alertas e fornecer
recursos do Azure orientação de
Segurança do Azure
para problemas remediação monitoriza os seus recursos
de segurança
do Azure e utiliza políticas
de segurança definidas
para alertá-lo sobre
possíveis ameaças e
Centro de Segurança do Azure vulnerabilidades. São
fornecidas recomendações
e passos para corrigir
Funcionalidades de problemas. Também pode
segurança dedicadas utilizar o acesso just-in-time
para complementar à VM, monitorizar e aplicar
as recomendações da política
atualizações de segurança
e controlar as aplicações,
Acesso à VM Gestão de Aprovação de
incluídas na lista de
just-in-time atualizações aplicações
permissões, que podem
ser executadas nas VMs.
O Centro de Segurança também pode alertá-lo sobre as melhores práticas gerais, tais
como se uma VM não tiver o diagnóstico ativado. Lembra-se de quando vimos no capí-
tulo 12 sobre como monitorizar e resolver problemas de VMs? Precisa de instalar e
configurar o agente de diagnóstico antes de ter um problema. Se suspeitar de uma vio-
lação de segurança, talvez não consiga aceder à VM e analisar os registos. Mas, se tiver
configurado a extensão de diagnóstico para efetuar o streaming de registos para o
Azure Storage, poderá analisar o que ocorreu e (com sorte) controlar a origem e a
extensão do problema.
Experimente agora
Para começar com o Centro de Segurança do Azure, conclua os passos a seguir:
236 Capítulo 16 Centro de Segurança do Azure e atualizações
3 Crie uma VM Linux básica para que o Centro de Segurança tenha algo para
monitorizar e fornecer recomendações:
az vm create \
--name azuremol \
--image ubuntults \
--generate-ssh-keys
4 Quando a VM for implementada, feche o Cloud Shell.

5 No portal Azure, selecione Centro de Segurança na lista de serviços à esquerda.
Da primeira vez que o painel é aberto, leva alguns segundos a preparar todos os
componentes disponíveis; consulte a figura 16.2.
Figura 16.2 A janela Descrição Geral do Centro de Segurança do Azure fornece uma lista de recomendações,
alertas e eventos. Pode selecionar um tipo de recurso core, como Computação ou Funcionamento em Rede,
para ver uma lista de itens de segurança específicos para esses recursos.
O Centro de Segurança analisa como os recursos como VMs, as regras do NSG e o

armazenamento são implementados. As linhas de base de segurança incorporadas são
utilizadas para identificar problemas e fornecer recomendações. A rede virtual imple-
mentada com a sua VM gera alguns avisos, por exemplo, como mostrado na figura 16.3.
Pode, e deve, implementar as suas próprias políticas de segurança que digam ao Azure
como pretende restringir o acesso ou o que precisa de ser feito para cumprir os man-
datos de negócios. Em seguida, à medida que cria ou atualiza recursos, o Azure
Acesso just-in-time 237
Figura 16.3 A rede virtual para

a sua VM já aciona avisos de
segurança. Neste exemplo, avisa
que um grupo de segurança de
rede deve ser associado à
sub-rede.
monitoriza continuamente os desvios destas políticas e alerta-o sobre quais passos pre-
cisam de ser realizados para corrigir os problemas de segurança. Irá utilizar as políticas
de segurança predefinidas do Azure neste capítulo, mas pense em qualquer configura-
ção de segurança específica que pretenda aplicar às suas VMs e como elas podem ser
definidas nas suas próprias políticas personalizadas.
6 Escolha Computador e Aplicações no menu esquerdo na janela do Centro de
Segurança; em seguida, escolha VMs e Computadores.
7 Selecione a VM criada no passo 3. Mesmo que tenha criado esta VM e utilizado
os valores predefinidos da CLI do Azure, são mostrados alguns avisos de segu-
rança neste exemplo.
Explore algumas destas recomendações. Ao selecionar cada recomendação, algumas
apenas lhe dão mais informações; outras guiam-no através da reparação. Estas regras
não são difíceis e rápidas; são recomendações e boas práticas. No seu próprio ambiente,
alguns destes podem não fazer sentido. Mas são um bom ponto de partida para saber o
que deve fazer para garantir recursos à medida que os cria no Azure.
16.2 Acesso just-in-time

Na secção 16.1, aprendeu como o Centro de Segurança sugere que limite o âmbito da
conectividade remota de entrada. Pode fornecer um intervalo IP para limitar o trá-
fego, mas, idealmente, só abre a conectividade de entrada quando necessário. Dessa
forma, a VM é completamente fechada para ligações remotas e é acessível apenas
durante um curto período de tempo quando
1. O utilizador pede 4. Regras do NSG

acesso just-in-time configuradas para
(JIT) à VM Centro de conceder acesso definido
Segurança do Azure Regras do grupo
Utilizador de segurança de
do Azure rede (NSG)
6. O utilizador pode Acesso JIT à VM 5. As regras do NSG
aceder à VM para permitem o acesso
o período de tempo para o período de
definido tempo definido
2. Permissões de RBAC 3. Se forem permitidas as

verificadas para acesso permissões de RBAC, o acesso
ao recurso VM JIT é concedido e configurado
Permissões do
controlo de acesso
baseado em
funções (RBAC)
Figura 6.4 Com o acesso JIT à VM, as regras do NSG são configuradas para negar ligações remotas a uma VM. As
permissões RBAC são utilizadas para verificar permissões quando um utilizador pede acesso a uma VM. Estes pedidos
são auditados e, se o pedido for concedido, as regras do NSG serão atualizadas para permitir o tráfego a partir de um
determinado intervalo IP durante um período de tempo definido. O utilizador pode aceder à VM apenas durante este
tempo. Quando expirar o tempo, as regras do NSG revertem automaticamente para um estado de negação.
necessário. E, sim, ainda deve limitar essa breve janela de conectividade a um intervalo IP
específico! É aí que o acesso just-in-time (JIT) à VM é útil, como mostrado na figura 16.4.
Com o acesso JIT, o Centro de Segurança ajusta dinamicamente as restrições de
acesso numa VM. Quando ativado, são criadas regras do NSG que negam todo o tráfego
de ligação remota. Em seguida, um utilizador pode então pedir acesso a uma VM ape-
nas quando necessário. Em combinação com o controlo de acesso baseado em funções
(discutido no capítulo 6), o Centro de Segurança determina se um utilizador tem direi-
tos para aceder a uma VM quando pede uma ligação. Se o utilizador tiver permissões, o
Centro de Segurança irá atualizar as regras do NSG relevantes para permitir o tráfego
de entrada. Estas regras são aplicadas apenas numa janela de tempo específico. Quando
o tempo se esgotar, as regras são revertidas e a VM fica novamente fechada às ligações
remotas. Se tiver uma ligação ativa a um VM, não é desligado automaticamente quando
o tempo expira. Pode terminar o seu trabalho de manutenção ou resolução de proble-
mas e desligar quando estiver pronto, mas não será capaz de iniciar uma nova ligação a
menos que solicite acesso ao JIT novamente.
Beber de uma boca de incêndio

Ainda não olhamos para o Azure Firewall, mas este é um recurso de rede virtual que
é um pouco mais parecido com uma firewall física on-premises do que com os NSGs por
si só. Se o precisa de mais flexibilidade e controlo do tráfego, a Azure Firewall é uma
ótima opção, embora exista um custo associado.
Sem aprofundar o Azure Firewall demasiado, quero notar que o Azure Security Center tam-
bém pode ser integrado com o Azure Firewall para abrir e fechar as regras exigidas. Se
Acesso just-in-time 239
utilizar o Azure Firewall para proteger o tráfego da VM em redes virtuais, e não apenas
NSGs, pode continuar a utilizar as regras de gestão automática de acesso à VM do JIT.
Para saber mais sobre a Azure Firewall, consulte os docs em https://docs.microsoft.
com/azure/firewall/overview.
Quando iria utilizar o JIT na sua pizzaria fictícia? Pense em qualquer VM que executa-
ria a aplicação web, sistema de pedidos, ou aplicações de lógica de negócio.
Quer que estes estejam ligados à Internet e disponíveis para que as pessoas acedam a
qualquer momento? Espero que não! Há razões válidas para o acesso remoto com SSH
ou RDP, mas tente sempre minimizar o tempo que o acesso está disponível. Mesmo
que tenha regras do NSG que restrinjam o acesso a determinados intervalos IP, o JIT
adiciona outra camada de proteção em termos de que a que localizações os utiliza-
dores do Azure podem aceder e, em seguida, cria um registo de auditoria mais fácil
sobre o qual o Centro de Segurança pode fornecer relatórios.
Experimente agora
Para ativar o acesso just-in-time à VM, conclua os passos a seguir:
1 Abra o portal Azure e escolha Centro de Segurança no menu à esquerda.

2 Em Defesas da Cloud Avançadas, selecione Acesso Just in Time à VM.
3 Se lhe for pedido, escolha a opção Tentar Acesso Just in Time à VM ou Atualizar para
Escalão Padrão do Centro de Segurança. Este trial gratuito dura 60 dias e não deve
ser prolongado automaticamente. A mesma sobrepõe-se à sua conta gratuita do
Azure e não custará nada a mais. Selecione a opção Aplicar Plano Padrão e aguarde
alguns instantes para que a mesma fique ativada. Quando estiver ativada, talvez seja
necessário fechar e reabrir o portal Azure antes de concluir os passos a seguir.
4 Selecione novamente Acesso Just in Time à VM na janela Centro de Segurança.
Quando a sua conta do escalão padrão estiver ativada, poderá ver uma lista de VMs
que podem ser utilizadas.
5 Selecione a sua VM e, em seguida, escolha Pedir Acesso, como indicado
na figura 16.5.
Figura 16.5 Selecione VM a partir das opções Recomendadas e, em seguida, escolha Ativar JIT na VM 1. O estado
mostra agora que esta VM está Aberta a todo o acesso remoto, o que sinaliza a severidade da preocupação de
segurança como Alta.
Por predefinição, o JIT define regras que podem abrir portas para SSH (porta 22),
RDP (porta 3389) e comunicação remota do PowerShell (portas 5985 e 5986)
durante um período de três horas.
6 Para este exercício, escolha ativar o SSH a partir do seu próprio IP. Como boa
práticas para utilizar a produção, insira uma justificação para acompanhar o por-
quê do acesso ser solicitado. Deixe as predefinições e escolha Abrir Portas, como
Figura 16.6 Ao ativar o JIT, pode alterar para que as regras predefinidas sejam permitidas, os IPs
de origem permitidos e um tempo máximo, em horas, de pedido. Estas regras JIT permitem o
controlo granular sobre o que é permitido, para permitir apenas o mínimo de conectividade.
7 Com o JIT ativado, navegue para o grupo de recursos e selecione a sua VM.
8 Escolha Funcionamento em Rede para ver a configuração de rede virtual atri-
buída para a VM. A lista de regras do NSG atribuídas é apresentada, como na
figura 16.7.
Figura 16.7 As regras JIT são criadas com a prioridade mais baixa. Estas prioridades certificam-se de que as
regras JIT tenham precedência sobre quaisquer regras posteriores aplicadas ao nível da sub-rede.
Gestão de Atualizações do Azure 241
As regras JIT são mostradas na parte superior da lista, porque têm a prioridade mais
baixa. O tráfego é permitido para o endereço IP da VM, mas apenas a partir do seu
próprio endereço IP. Isto foi o que o JIT configurou. O que pode parecer estranho
aqui é que ainda existe uma regra default-allow-ssh, permite todo o tráfego. Lembre-se
do capítulo 5, quando abordámos os NSGs. Pode dizer o que está a acontecer aqui?
O JIT aplica-se apenas à VM. Na regra JIT, a opção Destino mostra o endereço IP da
VM. No exemplo mostrado na figura 16.7, isso é 10.0.0.4. O tráfego é permitido. Mas, a
regra do NSG real é aplicada à sub-rede inteira. A regra default-allow-ssh aplica-se
ao nível da sub-rede e permite o tráfego de qualquer fonte e para qualquer destino.
As regras do NSG são processadas em ordem de prioridade, de baixa para alta. Como
abordado no capítulo 5, é sempre aplicada uma ação de negação, independentemente
de quaisquer regras adicionais. Mesmo que tenha alterado a default-allow-ssh para
recusar o tráfego, a regra JIT continuaria a permitir o acesso à VM específica e ao ende-
reço IP de origem definida.
Tenha cuidado com esta camada das regras da NSG. Idealmente, removeria a regra
default-allow-ssh rule, em seguida, permitiria o acesso apenas conforme necessário com o
JIT. Nesta abordagem, o SSH é negado pela regra final DenyAllInbound. Quando precisar
de se ligar a um VM, utilize o JIT para pedir o acesso, o que cria automaticamente uma regra
para permitir que o SSH seja confinado ao seu endereço IP durante um período definido.
A regra do NSG é eliminada automaticamente após o período de tempo especificado
decorrer. Por predefinição, as regras JIT são aplicadas durante três horas. Após esse tempo,
a VM voltará a um estado mais seguro e irá precisar de pedir acesso à VM novamente.
Este processo JIT controla quem pode pedir e receber o acesso à VM. Mas, só porque
uma pessoa pode ser bem-sucedida no pedido de acesso a uma VM não significa que ela
tenha permissões para iniciar sessão nessa VM. Tudo o que acontece no Azure é que as
regras do NSG definidas são atualizadas. O Centro de Segurança e o JIT não podem
adicionar, remover nem atualizar credenciais de acesso na VM.
Todos os pedidos de JIT também são registados. No Centro de Segurança, selecione
a opção Acesso Just in Time à VM e escolha a sua regra. À direita, selecione a opção de
menu ... e escolha Registo de Atividade. Este registo de atividade ajuda a auditar quem
pediu acesso a uma VM no caso de um problema.
O acesso ao JIT VM é uma forma de o Centro de Segurança e o Azure ajudarem a
manter as suas VMs em seguranaça. Controlar o acesso às VMs é uma grande parte da
segurança. Mas e as aplicações, bibliotecas e serviços em execução nas VMs? É aí que
precisa de garantir que todas as atualizações de segurança mais recentes sejam aplica-
das atempadamente às suas VMs.
16.3 Gestão de Atualizações do Azure

Uma área sobre a qual o Centro de Segurança do Azure pode reportar é o estado de
quaisquer atualizações do SO exigidas pela VM. Na sua pizzaria, deve tentar instalar os
patches de segurança e de aplicação mais recentes. Não quer executar qualquer sis-
tema que tenha uma vulnerabilidade conhecida ou área de ataque; portanto, contar
com uma maneira de automatizar as atualizações desses sistemas e controlar a confor-
midade melhora a sua segurança. Quando trabalhar com aplicações que envolvam
dados do cliente e informações de pagamento, não execute sistemas sem os patches
mais recentes instalados. E lembre-se de planear um ambiente de teste que lhe permita
aplicar patches de segurança e validar que não causam problemas antes de os aplicar
nos sistemas de produção!
Nas VMs do Azure é incorporada uma funcionalidade de Gestão de Atualizações,

que pode analisar, reportar e corrigir as atualizações do SO. O que é ótimo sobre esta
solução é que funciona no Windows e no Linux, e mesmo dentro do Linux, através de
diferentes distribuições, tais como Ubuntu, Red Hat e SUSE. A figura 16.8 mostra como
a Gestão de Atualizações monitoriza e pode instalar as atualizações necessárias.
Azure
Monitor
2. Recolhe e analisa dados

do agente na VM para
determinar o estado da
atualização
Agente VM Gestão de Azure

de monitor-
ização 1. Agente instalado Atualizações 3. Runbooks
Automation
na VM para reportar executados na agenda
dados nas atualizações definida para aplicar as
instaladas atualizações necessárias
Figura 16.8 A Gestão de Atualizações instala um agente de VM que recolhe informações sobre as
atualizações instaladas em cada VM. Estes dados são analisados pelo Azure Monitor e reportados à
plataforma do Azure. A lista de atualizações necessárias pode ser agendada para instalação automática
por meio de runbooks da Automation do Azure.
Leva alguns minutos até a VM ser preparada e reportar novamente o seu estado de
atualização; por isso, vamos configurar a sua VM e, em seguida, ver o que acontece em
segundo plano.
Experimente agora
Para configurar a sua VM para a Gestão de Atualizações, conclua os passos a seguir:
1 Abra o portal Azure e escolha Grupos de Recursos no menu à esquerda.

2 Selecione o seu grupo de recursos, como azuremolchapter16, e, em seguida,
selecione a sua VM, como azuremol.
3 Em Operações, selecione Gestão de Atualizações.
4 Aceite as opções predefinidas de Localização e a opção de criar de uma área de
trabalho do Log Analytics e de uma Conta de Automation. Iremos examinar
estes componentes no resto desta secção.
5 Para ativar a gestão de atualizações para a VM, selecione Ativar.
Volta à janela Descrição Geral da Gestão de Atualizações, mas leva alguns
minutos a configurar a VM e a reportar o seu estado. Continue a ler e deixe o pro-
cesso continuar.
Vamos ver melhor o que acontece para que a solução de Gestão de Atualizações
funcione.
16.3.1 Serviços de gestão do Azure combinados

Se já tiver trabalhado com quaisquer tecnologias Microsoft on-premises, pode ter-se
deparado com o conjunto de aplicações do System Center. O System Center é consti-
tuído por vários componentes, como o Configuration Manager, o Operations Mana-
ger, o Orchestrator e o Data Protection Manager. Existem outros componentes, mas
esses componentes core fornecem uma forma de realizar o seguinte:
¡ Definir as configurações e o estado pretendido
¡ Instalar aplicações e atualizações
¡ Reportar o estado de funcionamento e a segurança
¡ Automatizar implementações de serviços e aplicações de grande dimensão
¡ Fazer cópias de segurança e replicar dados
À medida que as empresas migraram para fornecedores de cloud computing nos últi-
mos anos, esses componentes on-premises mais tradicionais do System Center são
substituídos pelos serviços do Azure que podem funcionar num ambiente híbrido.
Analisámos dois componentes do OMS em capítulos anteriores, mesmo que não se
tenha apercebido disso:
¡ Azure Backup fornece uma maneira de fazer cópias de segurança de VMs ou fichei-
ros individuais, definir políticas de retenção e restaurar dados.
¡ Azure Site Recovery permite replicar VMs para diferentes regiões geográficas em
caso de desastre natural ou interrupção prolongada.
O Azure Backup e o Site Recovery ajudaram-no a proteger os seus dados no
capítulo 13. Agora, irá utilizar dois componentes adicionais do OMS com a Gestão de
Atualizações:
¡ Áreas de trabalho do Log Analytics recolhem informações de várias fontes ou agentes, e
permitem definir políticas e consultas para alertá-lo para condições que podem
ocorer. Estas consultas e alertas podem ajudá-lo a rastrear o estado de atualização
de uma VM ou notificá-lo de problemas de configuração ou segurança.
¡ Azure Monitor detalha e informa informações baseadas no processamento reali-
zado em áreas de trabalho Log Analytics. O Azure Monitor fornece uma forma
centralizada de visualizar alertas, consultar dados de registo e gerar notificações
em todos os seus recursos Azure.
¡ Automation do Azure permite-lhe criar runbooks que executam comandos ou
scripts inteiros. Os runbooks podem ser implementações grandes e complexas e
podem chamar vários outros runbooks. Iremos ver a Automation do Azure em
detalhe no capítulo 18.
A integração destes componentes é mostrada na figura 16.9.
Área de
Azure
trabalho do
Automation
Log Analytics
Compara e analisa Executa automaticamente

registos de várias fontes para runbooks; vários
fornecer consultas e alertas destinos de host
Azure
Faça a cópia de segurança Replica dados para as

de dados ou de VM inteiras regiões definidas com
com base nas políticas de base nas políticas de
agendamento e retenção agendamento e retenção
Azure Azure Site

Backup Recovery
Figura 16.9 Vários serviços do Azure funcionam em conjunto para

fornecer funcionalidades de gestão e configuração em todo o ambiente
de aplicação. Os serviços que utilizam estes componentes não estão
limitados às VMs ou recursos do Azure e, desde que estejam configurados
corretamente, podem funcionar com outros fornecedores de cloud ou
sistemas on-premises.
As áreas de trabalho do Log Analytics e a Automation do Azure são componentes

poderosos. Poderíamos facilmente preencher capítulos ou até livros a falar apenas
sobre eles. Com apenas um punhado de VMs para gerir, pode achar fácil ignorar a
necessidade de um repositório de registos centralizado para consultar e alertar, ou
ignorar uma maneira de automatizar configurações e implementações em VMs. Se
ainda não tiver feito uma lista de componentes do Azure para acompanhar quando
terminar este livro, faça uma lista e adicione estes dois componentes a essa lista!
Algo que é importante entender é que no Azure, existem vários serviços e compo-
nentes que podem interagir e complementar-se entre si. Da mesma forma como as VMs
do Azure e as redes virtuais do Azure são serviços individuais, ambos os serviços também
se complementam ou até dependem um do outro. O Azure Backup e a extensão de
diagnóstico do Azure são ótimos componentes individuais, mas na realidade destacam-
-se se as áreas de trabalho do Log Analytics e se o Azure Monitor forem utilizados para
monitorizar o seu estado e agrupar quaisquer eventos ou avisos gerados. Espero que
tenha começado a identificar alguns destes componentes relacionados e a ver como os
serviços do Azure muitas vezes funcionam entre si. Agora que estamos nestes capítulos
finais e observamos as opções de segurança e monitorização, o objetivo é garantir que
as aplicações executadas no Azure estejam em bom estado de funcionamento e sejam
estáveis.
Esta coisinha a que chamamos “Identidade”

Pensando em serviços que se complementam, uma grande (e quero dizer grande!) parte
do Azure que abordámos apenas ligeiramente é o Azure Active Directory (Azure AD). A
identidade é central para tudo em Azure, e o Azure AD fornece algumas das funcionali-
dades de segurança que examinamos no capítulo 6 com o
modelo de implementação do Azure Resource Manager. A capacidade de utilizar o RBAC
para limitar que ações podem ser executadas num recurso por certos utilizadores ou
grupos está ligada a uma solução de identidade central. Mesmo a capacidade de
iniciar sessão no portal Azure ou na CLI do Azure é acionada pelo Azure AD.
Este livro não abrange o Azure AD, pois o âmbito do que fornece é amplo e bastante dife-
rente dos serviços IaaS e PaaS do Azure, como VMs, conjuntos de dimensionamento e
aplicações Web. Pode haver alguma sobreposição no público de tópicos, mas a maioria
dos programadores teria uma meta diferente para o que queriam aprender sobre o
Azure AD em comparação com um gestor de aplicações ou um profissional de TI que
implementa a infraestrutura.
Dependendo da sua conta Azure, pode estar limitado no que pode fazer com o Azure
AD. Quando regista uma conta trial do Azure grátis, uma instância Azure AD padrão é
criada para si. A conta principal desse diretório é a sua e tem todos os direitos de admi-
nistrador. Se iniciar sessão no Azure com uma conta da sua empresa ou instituição de
ensino, há uma boa possibilidade de que tenha pouco ou nenhum direito administrativo.
Assim, mesmo se pudéssemos concordar em focar alguns tópicos, pode não ser capaz
de realizar diretamente nenhum dos exercícios. E não recomendo mesmo
entrar num ambiente Azure AD real para aprender como funciona!
Mas, o Azure AD é outro desses serviços centrais do Azure que une muitos outros
serviços e componentes. O cloud computing não é uma solução mágica que
facilita as tarefas nem decompõe os silos operacionais; ainda precisa das competências
para trabalhar com diferentes equipas e intervenientes. Espero que ao longo destes capítu-
los tenha adquirido as competências core destes serviços do Azure para entender como criar
aplicações redundantes em larga escala e como comunicar com outras equipas de maneira
mais eficaz e com melhor conhecimento dos desafios que podem encontrar.
16.3.2 Analisar e aplicar atualizações

Pode levar algum tempo até o agente de VM executar a primeira análise e reportar
novamente o estado das atualizações aplicadas. A lista de componentes instalados tam-
bém deve ser cruzada com a lista de atualizações disponíveis para um determinado SO
e versão. Se a sua VM não tiver concluído a operação e tiver reportado o seu estado,
continue a ler e volte a este passo após alguns minutos. Quando estiver pronto, a des-
crição geral é como aparece na figura 16.10. Seja paciente; pode levar 10 a 15 minutos
para que a prontidão do agente indique o estado Pronto e permita agendar atuali-
zações para a instalação.
É ótimo que haja uma lista de atualizações necessárias, mas não seria melhor haver
uma maneira de instalá-las? É aí que entra a Automatização do Azure! Quando ativou a
Gestão de Atualizações, foram criados vários runbooks da Automation do Azure, que
manipulam automaticamente o processo para aplicar as atualizações necessárias.
Figura 16.10 Assim que o agente de VM tenha analisado a conformidade, é fornecida uma lista
de atualizações disponíveis. Dependendo do SO e da versão, a Gestão de Atualizações pode ser capaz
de funcionar com as áreas de trabalho do Log Analytics para classificar as atualizações com base
na severidade ou fornecer ligações para as páginas de correções de atualizações relevantes.
Experimente agora
Se tiver sorte (ou azar), a sua VM pode reportar que não é necessária nenhuma atualiza-
ção. As imagens de VM são atualizadas com frequência no Azure, e se implementar uma
VM imediatamente depois de a última imagem ter sido criada, todas as atualizações
necessárias já estão instaladas. Em caso afirmativo, leia estes passos para que entenda
o que é necessário quando as suas VMs precisam de ser atualizadas!
Para aplicar as atualizações necessárias para a sua VM, conclua os passos a seguir:
1 Na secção Gestão de Atualizações da sua VM, selecione Agendar Implementação

de Atualizações.
2 Introduza um nome para a implementação de atualização, como azuremolupdates,
e analisa as Classificações de Atualizações. Pode controlar quais conjuntos de atuali-
zações são aplicados. Por enquanto, deixe todas as opções predefinidas definidas.
3 A opção Atualizações a Excluir permite-lhe especificar atualizações específicas
que não pretende instalar. Se souber que a sua aplicação requer uma versão espe-
cífica de um pacote ou biblioteca, pode certificar-se de que um pacote atualizado
que possa criar problemas não está instalado. Reveja as opções disponíveis, mas
não há nada a mudar neste exercício.
4 Selecione Definições de Agendamento e, em seguida, escolha uma hora para

que as atualizações sejam aplicadas a partir das opções de calendário e hora. A
hora de início deve ser, pelo menos, cinco minutos antes da hora atual, para dar
à plataforma do Azure alguns instantes para processar e agendar o seu runbook
na Automation do Azure.
5 Quando estiver pronto, selecione OK.
6 Se certas aplicações e serviços precisarem de parar ou desligar antes de as atuali-
zações serem aplicadas e reiniciar quando as atualizações estiverem terminadas,
escolha Pré-scripts + Post-scripts. Tarefas de automatização distintas podem ser
configuradas para realizar ações nos VMs antes e depois de as atualizações serem
aplicadas.
7 A opção Janela de Manutenção (minutos) define quanto tempo, em minutos, o
processo de atualização pode ser executado antes de a VM precisar de estar nova-
mente em operação. Esta janela de manutenção evita processos de atualização
de execução prolongada que podem fazer com que uma VM não fique disponí-
vel durante horas. Pode querer tornar a janela de manutenção mais curta ou
mais longa, dependendo de quaisquer contratos de nível de serviço para as apli-
cações executadas nessas VMs, ou o número e o tamanho das atualizações neces-
sárias. Aceite o valor predefinido e, em seguida, selecione Criar.
8 Novamente na janela Gestão de Atualizações, selecione Implementações Agen-
dadas. As atualizações são listadas conforme agendadas para instalação na data
e hora que seleciona, como mostrado na figura 10.86.11.
Figura 16.11 A lista de tarefas de implementação agendada é mostrada. Se pretender, pode eliminar uma
determinada tarefa; caso contrário, as atualizações são aplicadas automaticamente na hora definida.
9 Na parte superior da janela Gestão de Atualizações, selecione Gerir Várias Máqui-

nas. A janela muda para a conta da Automation do Azure que foi criada automa-
ticamente quando a Gestão de Atualizações foi ativada para a VM. Não se
preocupe muito agora com o que os runbooks fazem. Não há nada para persona-
lizar e examinamos a Automation do Azure no capítulo 18.
Tenha em atenção que pode escolher Adicionar VM do Azure ou Adicionar
Máquina que não é do Azure, como mostrado na figura 16.12. Esta capacidade
destaca uma abordagem única para gerir atualizações em todo o ambiente de
aplicação, não apenas para as VMs do Azure.
Figura 16.12 Na conta da Automation do Azure, pode gerir vários computadores e ver o estado ou aplicar
atualizações. As VMs do Azure e os computadores que não são do Azure podem ser monitorizados e
controlados pela mesma conta da Automation do Azure. Em segundo plano, o Azure pode integrar-se em
outros fornecedores para instalar agentes nos computadores num ambiente híbrido. Esta integração
permite gerir todas as suas necessidades de atualização num único dashboard e na plataforma de
administração.
10 Volte à janela Gestão de Atualização para a sua VM e selecione o separador His-

tórico. Quando a implementação de atualização é iniciada, o seu estado é mos-
trado. Lembre-se que agendou o trabalho para ser executado uns minutos no
futuro, para que não apareça imediatamente.
11 Selecione o calendário para ver o estado e a saída, como indicado na figura 16.13.
Figura 16.13 Pode monitorizar o estado da execução de tarefas da Automation do Azure no portal.
Para rever ou resolver problemas de tarefas, pode clicar numa tarefa para ver qualquer saída e
os registos gerados.
Laboratório: ativar o JIT e atualizações para uma VM Windows 249
12 Após a implementação de atualização ser concluída, volte ao seu grupo de recur-

sos, selecione a sua VM e, em seguida, escolha Gestão de Atualizações. Pode levar
alguns minutos até o agente ser atualizado e reportar através de uma área de tra-
balho do Log Analytics que as atualizações foram aplicadas; em seguida, deve
mostrar no dashboard que a VM está atualizada e que não é necessária nenhuma
atualização adicional.
Este capítulo tem sido uma jornada vertiginosa pelo Centro de Segurança e os seus
componentes associados, como o acesso JIT a VMs ou a Gestão de Atualizações. O
objetivo é que comece a pensar não apenas em implementar e executar uma VM ou
uma aplicação Web mas, em vez disso, planear uma gestão mais ampla de aplicações. O
cloud computing não muda a necessidade de políticas de segurança; há, sem dúvida,
uma necessidade maior de os recursos serem protegidos. Deixe que as funcionalidades
do Azure, como o Centro de Segurança, o orientem para saber o que deve ser feito e
utilize as ferramentas incorporadas, tal como a Gestão de Atualizações e a Automation
do Azure, para manter permanentemente uma proteção plena.
16.4 Laboratório: ativar o JIT e atualizações para uma VM Windows

Este capítulo cobriu alguns componentes que podem ter levado algum tempo a serem
ativados e a reportar o estado esperado. Este laboratório é opcional; foi projetado para
mostrar que nenhuma destas funcionalidades é específica para qualquer sistema ope-
rativo. Se não tiver tempo ou considerar entender como aplicar estas funcionalidades
a uma VM Windows, sinta-se à vontade para ignorar este laboratório. Caso contrário,
tente as tarefas a seguir para obter alguma prática adicional com o Centro de Segu-
rança e a Gestão de Atualizações. A prática leva à perfeição, certo?
1 Crie uma VM Windows Server da sua escolha no mesmo grupo de recursos utili-
zado nos exercícios anteriores, como azuremolchapter16.
2 Consulte as regras do NSG para a VM/sub-rede e elimine quaisquer regras pre-
definidas que permitam RDP na porta TCP 3389.
3 Utilize o seu cliente de Ligação ao Ambiente de Trabalho Remoto local para
verificar se as liga-ções RDP estão bloqueadas.
4 Peça acesso JIT, analise as regras do NSG novamente e confirme que agora pode
fazer RDP para a sua VM.
5 Ative Gestão de Atualizações na sua VM Windows. Desta vez, deve poder utilizar a
área de trabalho do Log Analytics existente e as contas da Automation do Azure.
6 Deixe que o agente de monitorização reporte as atualizações necessárias e, em
seguida, agende as atualizações a serem aplicadas pela Automation do Azure.
Parte 4
O fantástico
A gora, a parte realmente interessante! Nestes últimos capítulos, vai apren-

der sobre algumas das tecnologias futuras que pode utilizar no Azure, como a
inteligência artificial e o machine learning, os containers e o Kubernetes e a
Internet of Things. Pode não estar a utilizar estes serviços agora, mas, com as ten-
dências atuais na computação, provavelmente serão utilizados em breve. Estes
serviços são algumas das tecnologias mais emocionantes para se trabalhar.
Embora o livro avance muito rapidamente para cobrir estes tópicos durante a sua
pausa para almoço, esta parte é uma ótima maneira resumir as coisas e mostrar-
lhe as possibilidades do que pode construir com o Azure.
17 Machine learning e
inteligência artificial
Esperamos que não acabemos num mundo em que filmes como O Exterminador
Implacável e Matrix se tornem realidade. Nesses filmes, a ascensão da inteligência
artificial (AI) quase provoca o extermínio da humanidade na medida em que as
máquinas lutam para assumir o controlo. Uma causa de preocupação na computa-
ção agora é como o desenvolvimento da AI é feito na maior parte por grandes
empresas privadas, com pouco ou nenhum regulamento e supervisão central. Não
pretendo afirmar que a IA é uma coisa má! Assistentes digitais em smartphones
podem ajudar com muitas tarefas do dia a dia. O machine learning (ML) em aplica-
ções de navegação pode monitorizar a unidade diária do utilizador para sugerir
rotas alternativas baseadas em condições de estrada ou clima. Os controlos de aque-
cimento doméstico podem ajustar-se automaticamente com base na temperatura
exterior, na hora do dia e na hora do ano (como o verão ou o inverno).
Ao iniciar esta parte final do livro, irá aprender sobre os serviços do Azure para
machine learning e inteligência artificial. Num capítulo. No seu intervalo para o
almoço. Vamos definir algumas expectativas realistas: não vai ficar um especialista
em ML ou IA nos próximos 45 minutos! Pode, se comer a sua sanduíche rapida-
mente, aprender o suficiente sobre os muitos serviços que o Azure oferece para
entender como integrar alguns destes serviços de ML e IA nas suas aplicações. Mui-
tos dos serviços de ML e IA do Azure esperam, pelo menos, alguma experiência pré-
via em algoritmos de dados, linguagens de programação, processamento em lotes ou
compreensão de linguagem; portanto, não espere tornar-se num especialista na pró-
xima hora!
Neste capítulo, vamos mergulhar em alguns dos serviços cognitivos do Azure que for-
necem funcionalidades de ML e IA. Irá aprender como utilizar estes serviços para
executar o machine learning básico em modelos de dados e, em seguida, utilizar um
pouco do serviço Azure Web Apps e o Microsoft Bot Framework para aplicar alguns
dos serviços de IA que podem executar um bot de pizzaria para que os clientes façam
pedidos de pizza.
253
254 Capítulo 17 Machine learning e inteligência artificial
17.1 Descrição geral e relação entre IA e ML

Mantenha-se firme, porque estamos prestes a ir dos 0 aos 900 km/h em apenas algumas
páginas! Muitas vezes, a IA e o ML sobrepõem-se à medida que cria aplicações no Azure.
Vamos explorar o que cada um é, e depois ver sobre como trabalham em conjunto.
17.1.1 Inteligência artificial

IA permite que os computadores realizem tarefas com alguma flexibilidade e cons-
cientização e ajustem as suas decisões com base em fatores externos ou sem a necessi-
dade de interação humana. Geralmente, o objetivo não é criar um sistema
completamente autónomo que pode evoluir e desenvolver pensamentos por conta
própria, mas sim utilizar um conjunto de modelos de dados e algoritmos para ajudar a
orientar o processo de tomada de decisões.
A IA comum em computadores e smartphones pessoais inclui Siri, Cortana e o Assis-
tente do Google. Como mostrado na figura 17.1, estes recursos de IA permitem-lhe
comunicar, muitas vezes, através de comandos de voz, para perguntar direções, definir
lembretes, pesquisar na Web e muito mais.
Comandos de voz
Definir
Verificar a
Comandos de texto
lembrete
meteorologia
Criar Enviar
memorando e-mail
Ligar ao Bob
Assistentes digitais
Iniciar
de IA comuns temporizador
Assistente do
Google
Cortana
Siri
Aplicações integradas
Aplicações
Notificações por
de calendário
e-mail
Tráfego +
deslocação
Figura 17.1 Uma utilização comum de IA na vida quotidiana são os assistentes digitais, como Cortana,
Siri e o Assistente do Google. Pode utilizar comandos de voz ou texto para interagir com eles, e eles podem
monitorizar o seu calendário diário e as condições da deslocação para avisá-lo sobre problemas de tráfego.
Assistentes digitais como estes normalmente não envolvem uma grande quantidade do
que pode considerar inteligência. Escutam e respondem às entradas que fornece. Mas,
essas entradas podem variar e nem sempre podem ser comandos específicos. Pense em
como um assistente digital lhe permite definir um lembrete. Pode utilizar uma das
seguintes frases:
Descrição geral e relação entre IA e ML 255
¡ “Às 5, lembre-me de comprar leite.”

¡ “Diga-me para comprar leite a caminho de casa.”
¡ “Preciso de leite quando estiver na loja.”
Se desenvolveu uma aplicação tradicional, precisaria de escrever um código que pode-
ria lidar com todas as possíveis variações de como um utilizador pode fornecer instru-
ções. Pode criar expressões regulares para ajudar a capturar algumas das variações,
mas o que acontece quando o utilizador diz uma frase que não programou? E se intera-
gir via texto e houver um erro de digitação no seu pedido que não previu? Estes tipos
de interação são perfeitos para a IA. Como mostrado na figura 17.2, a aplicação é pro-
gramada para várias frases comuns e, em seguida, é capaz de fazer uma conjuntura
lógica com base no que "pensa" que o utilizador está a pedir.
Provavelmente o utilizador não

quer estar acordado às 5:00 da
manhã para ir buscar leite Lembrete definido
“Às 5, lembre-me
para as 17:00 para
de comprar leite.” Assistentes digitais
O utilizador deixa ir buscar leite
de IA comuns
o edifício e entra no
“Diga-me para Assistente seu carro para iniciar Monitorizar e detetar
comprar leite do Google quando viajar
Cortana deslocação do
a caminho de casa.” para casa
trabalho para casa
Siri
Utilizar a localização
“Preciso de leite GPS para detetar
quando estiver na loja.” A localização GPS do a mercearia
utilizador e a pesquisa no
mapa indicam a mercearia
Figura 17.2 A IA pode considerar a entrada do utilizador e tomar as decisões que melhor se adequam à ação
antecipada. A IA não é pré-programada com todas estas possíveis respostas e árvores de decisão. Em vez disso,
utiliza modelos de dados e algoritmos para aplicar o contexto à entrada do utilizador e interpretar o significado e o
resultado apropriado.
Não é verdadeira inteligência (ainda), mesmo em formas complexas de IA; em vez

disso, é uma conjuntura sólida com base num modelo de dados utilizado para a forma-
ção de IA. Este modelo de dados pode incluir muitas variações e frases e pode ser
capaz de aprender novos significados ao longo do tempo. Como aprende e de onde
vêm estes modelos de dados? É aí que o ML se torna importante.
17.1.2 Machine learning

Uma expressão da moda na computação ao longo dos últimos anos tem sido big data.
O conceito é que os sistemas informáticos, especialmente na cloud, são um ótimo
recurso para processar grandes quantidades de dados. Realmente, grandes quantidades
de dados. Estas tarefas de processamento podem ser executadas durante alguns minu-
tos ou horas, dependendo do volume de dados e dos cálculos necessários, e permitem-
-lhe preparar e analisar grandes volumes de dados para determinar padrões e
correlações específicos. Estas aprendizagens formam modelos de dados que outras
aplicações ou
Dados
Algoritmos de As aplicações
pré-processados Modelo de
Big Data ML aplicados utilizam o modelo
e prepara- dados
aos dados de dados
dos/limpos
Figura 17.3 São processadas grandes quantidades de dados não processados, que são deixadas prontas para
utilização. Podem ser aplicadas diferentes técnicas de preparação e limpeza de dados, dependendo das entradas
não processadas. Em seguida, os algoritmos de ML são aplicados aos dados preparados para criar um modelo de
dados apropriado que reflita a melhor correlação entre todos os pontos de dados. Diferentes modelos de dados
podem ser produzidos e refinados ao longo do tempo. As aplicações podem, então, utilizar os modelos de dados nas
suas próprias entradas de dados para ajudar a orientar a sua tomada de decisões e compreender os padrões.
A IA pode ser utilizada para tomar decisões. Como mostrado na figura 17.3, o ML
envolve alguns passos e inclui entradas e saídas.
Veja como a forma mais básica de ML funciona:
1 Para iniciar o processo, são fornecidas grandes quantidades de dados não proces-
sados como entrada.
2 Estes dados são processados e preparados num formato utilizável para focar
os pontos de dados específicos necessários para análise.
3 Os algoritmos de ML são aplicados aos dados. Este é o lugar onde o verdadeiro
cálculo numérico acontece. Os algoritmos foram concebidos para detetar e compu-
tar semelhanças ou diferenças em toda a grande quantidade de pontos de dados.
4 Com base na análise dos algoritmos, é produzido um modelo de dados que
define padrões nos dados. Estes modelos de dados podem ser refinados ao longo
do tempo se partes do modelo provarem estar incorretas ou incompletas quando
forem aplicados dados adicionais do mundo real.
5 As aplicações utilizam os modelos de dados para processar os seus próprios con-
juntos de dados. Estes conjuntos de dados são normalmente muito menores do
que os dados não processados fornecidos para os algoritmos de ML. Em seguida,
se o modelo de dados é válido, mesmo com uma pequena entrada de dados da
aplicação, é possível determinar o resultado ou a correlação correto.
Muitas vezes, o ML envolve algoritmos complexos que foram concebidos para proces-
sar todos os pontos de dados fornecidos. O Hadoop e o Apache Spark são duas pilhas
de aplicações comumente utilizadas para processar big data. O Azure HDInsight é um
serviço gerido que permite analisar os grandes conjuntos de dados processados por
estas pilhas de aplicações. Para aprofundar um pouco mais a análise e os algoritmos, os
cientistas de dados utilizam comumente a linguagem de programação R para desen-
volver os modelos necessários. Não se preocupe muito com o que é Hadoop ou R. O
ponto chave é que o Azure pode executar as ferramentas de ML comuns que são
amplamente aceites no setor.
17.1.3 União da IA e do ML
Uma aplicação comum num smartphone é a aplicação de navegação, como mostrado
na figura 17.4. O seu fornecedor, como o Google, pode controlar a rota que utiliza
para ir trabalhar todos os dias, a que horas costuma sair de casa e quanto tempo leva a
chegar ao seu local de trabalho.
Este exemplo do Google Maps mostra a IA e o ML a trabalharem em conjunto. A IA
é aplicada para saber quando gerar uma notificação com base nos dados recebidos após
o processamento de
Descrição geral e relação entre IA e ML 257
Previsão do
Utilizador 1 tempo
Deslocação diária Meteorologia Controla-
Deslocação diária em tempo real dor ativo 1
Deslocação diária
Controla-
dor ativo 2
Utilizador 2 Controla-
Deslocação diária dor ativo 3
Serviço do
Deslocação diária Google Maps
Utilizador 3 Alertas e
sugestões de
tráfego
Deslocação diária O seu
smartphone
Figura 17.4 Todos os dias, o serviço do Google Maps recebe vários pontos de dados de utilizadores, que
registam os detalhes do seu trajeto. Estes dados podem ser preparados e processados, juntamente com
a previsão do tempo e a meteorologia em tempo real durante esses percursos. Os algoritmos de ML podem
ser aplicados a estes grandes conjuntos de dados e é criado um modelo de dados. Na medida em que uma
amostra menor de condutores ativos alimentam as condições dos seus percursos ou na medida em que dados
meteorológicos no serviço do Google Maps são capturados, o modelo de dados pode ser aplicado para prever
o trajeto e gerar um alerta de tráfego no seu smartphone, que sugere uma rota alternativa para casa.
modelo de dados de ML. Outro exemplo de IA e ML a trabalharem em conjunto é a

ideia de definir um lembrete para comprar leite. Se a IA foi formada com modelos de
dados de ML, o assistente saberia que provavelmente compra leite no supermercado, e
este não iria lembrá-lo de ir à loja de ferragens. O modelo de dados de ML também
seria capaz de ajudar a IA a entender que há uma probabilidade muito grande de que-
rer ser lembrado de algo às 17:00, e não às 5:00, e, por isso, não deve acordá-lo às 5:00
para comprar leite. Se o seu smartphone controla que entra no seu carro às 17:00 e
começa a afastar-se do trabalho, o ML vai gerar um modelo de dados que prevê que
está a conduzir para ir para casa. Por isso, a essa hora, é um bom momento para a IA o
lembrar de comprar leite.
Estes exemplos básicos, mas poderosos, mostram como o ML é utilizado para melho-
rar a IA. Treina a IA, fornecendo um conjunto de pontos de dados que são processados
pelo ML para melhorar a precisão ou a tomada de decisões.
17.1.4 Ferramentas de ML do Azure para cientistas de dados

Quero rapidamente saber algumas maneiras em que alguns cálculos numéricos do
mundo real e o ML podem trabalhar em conjunto. Para tornar este capítulo acessível a
todos, os exercícios usam o Microsoft Bot Framework para IA e o ML com o Language
Understanding Intelligent Service (LUIS). Para colocar as mãos na massa com o ML,
precisamos de focar-nos um pouco mais no processamento de dados e nos algoritmos.
No Azure, há alguns componentes interessantes para ajudá-lo a obter conhecimentos

mais profundos dos dados em massa. Primeiro, há o próprio Azure Machine Learning
Studio, um serviço baseado na Web que permite criar, visualmente, experiências adicio-
nando conjuntos de dados e modelos de análise. Estas experiências podem utilizar fontes
de dados, como Hadoop e SQL, e o suporte de programação adicional é fornecido para
linguagens como R e Python. Pode arrastar e largar fontes de dados, técnicas de prepara-
ção de dados e algoritmos de ML. Pode ajustar esses algoritmos e, em seguida, analisar e
ajustar os modelos de dados produzidos.
O objetivo do Azure Machine Learning é fornecer uma barreira baixa para a entrada
nos recursos de computação de grande escala disponíveis no Azure. Uma vantagem prin-
cipal de executar o cálculo numérico de dados ML no Azure é que pode aceder a uma
grande quantidade de poder de computação e utilizá-la apenas pelo tempo necessário
para fazer os seus cálculos. Em ambientes tradicionais, estes recursos de computação dis-
pendiosos ficariam inativos durante grandes períodos de tempo entre as tarefas de pro-
cessamento de dados.
Um outro recurso interessante que o ajuda a realizar cálculos numéricos mais pesados
de ML no Azure são as virtual machines de ciência de dados (DSVMs). Estas VMs estão
disponíveis para Linux e Windows. Incluem muitas aplicações comuns pré-instaladas,
incluindo Jupyter Notebooks, Anaconda Python e R Server ou SQL Server (figura 17.5).
Figura 17.5 Estas VMs estão disponíveis para Windows e Linux. Este Window Server 2016 DSVM inclui
várias aplicações de ciência de dados pré-instaladas, como R Server e Jupyter Notebooks. As DSVMs
permitem que esteja rapidamente pronto para o processamento de big data e a criação de algoritmos de ML.
Azure Cognitive Services 259
Não há necessidade de instalar todas as ferramentas e dependências no seu computa-

dor local; pode criar uma DSVM e recursos de CPU e memória de que precisa para
processar rapidamente os seus dados e, em seguida, eliminar a VM quando a sua tarefa
de processamento for concluída e obtiver os modelos de dados que precisa.
17.2 Azure Cognitive Services

Ora bem, o que dizer dos serviços de IA para deixar as suas aplicações mais inteligen-
tes? No Azure, um conjunto de serviços relacionados formam o conjunto de aplicações
dos Serviços Cognitivos. Os serviços abrangem algumas áreas comuns de IA que lhe
permitem integrar rapidamente estes recursos inteligentes nas suas aplicações, dividi-
das nas seguintes áreas gerais:
¡ Imagem
¡ Voz
¡ Linguagem
¡ Decisão
¡ Pesquisa
Mais de duas dezenas de serviços fazem parte da família dos Serviços Cognitivos.
Alguns destes serviços são
¡ Imagem, que inclui
– Imagem computorizada para análise de imagens, legendagem e etiquetagem.
– Face para analisar e detetar rostos em imagens.
¡ Voz, que inclui
– Serviços de voz para analisar e converter a voz em texto e vice-versa.
– Reconhecimento de Orador para identificar e verificar o orador.
¡ Linguagem, que inclui
– Language Understanding (LUIS) para compreender e processar a interação com
os utilizadores. Vamos explorar o LUIS no laboratório no final deste capítulo.
– Tradução de Texto para analisar e corrigir erros ortográficos ou efetuar
traduções.
¡ Decisão, que inclui
– Moderador de Conteúdos para analisar e moderar fotos, vídeos e textos.
– Personalizador para analisar padrões e fornecer recomendações aos clientes.
¡ Pesquisa, que inclui
– Bing Custom Search para implementar a pesquisa nos seus dados personalizados
e em aplicações.
– Bing Autosuggest para fornecer sugestões automáticas à medida que os utilizado-
res introduzam frases e consultas de pesquisa.
Como pode ver, muitos serviços do Azure combinam funcionalidades de IA e ML. Este
capítulo foca-se na linguagem, especificamente o LUIS. Este serviço é geralmente utili-
zado para criar um bot inteligente que pode ajudar os clientes no seu site. Depois,
pode criar uma aplicação, que utilize serviços de IA em Azure, que possa interpretar
frases e perguntas, bem como fornecer a resposta apropriada para orientar um utiliza-
dor através de um processo de pedido ou de um pedido de suporte.
17.3 Criar um bot inteligente para ajudar com pedidos de pizza

Um bot é uma aplicação que está programada para responder a tarefas e à entrada de
um utilizador. Se isto soa muito como qualquer aplicação normal, bem, é porque é
mesmo! A diferença é como a aplicação do bot determina a resposta.
Muitas vezes, um bot básico e comum é nada mais do que uma aplicação que fornece
algum tipo de automatização. Quando um utilizador envia uma mensagem, define uma
etiqueta numa mensagem de e-mail ou submete um termo de pesquisa, o bot executa
tarefas pré-programadas que executam uma ação específica. Não há aqui IA ou ML
reais. A aplicação bot está apenas a responder à entrada do utilizador.
Com a estrutura certa, um bot pode ser expandido e receber um pouco mais de
liberdade e inteligência. No início da nossa descrição geral de IA, discuti como uma
aplicação típica deve ser pré-programada com todas as entradas de utilizador antecipa-
das e qual seria a saída correspondente. Mas, não há flexibilidade se o utilizador forne-
cer uma frase de entrada diferente ou cometer um erro ortográfico, por exemplo.
A Microsoft produz o Bot Framework, que permite a um bot do Azure integrar facil-
mente os SDKs do Bot Builder e ligar-se ao Azure Cognitive Services. Com uma expe-
riência mínima em códigos, pode criar bots inteligentes que utilizem o poder do Azure
para oferecer uma ótima experiência ao cliente. Só não tente criar a Skynet, a menos
que saiba como O Exterminador Implacável termina!
17.3.1 Criar um bot da aplicação Web no Azure

Vamos implementar um bot e integrar alguns serviços de IA e ML. O bot é executado
numa aplicação Web do Azure e utiliza o Microsoft Bot Framework para se ligar ao
LUIS e permitir que um cliente faça um pedido de pizza. A figura 17.6 descreve o que
estes exercícios irão criar e quais serviços são utilizados.
Subscrição do Azure
Plano do App Service
Compreensão Web App

e intenção da
linguagem Microsoft Bot
Aplicação Aplicação
Connector
LUIS Node.js
Framework
Armazena dados persistentes

do bot e estado de sessão
Figura 17.6 Nos próximos
Conta Storage exercícios, irá criar um bot
da aplicação Web que integra
Tabela vários serviços de IA e ML do
Azure para interagir com um
cliente e ajudá-lo a fazer pedidos
de pizza.
Criar um bot inteligente para ajudar com pedidos de pizza 261
Experimente agora
Para criar um bot da aplicação Web do Azure, conclua os passos seguintes:
1 Abra o portal Azure e selecione, no canto superior esquerdo, a opção Criar um

Recurso.
2 Pesquise e selecione Bot da Web App, e selecione Criar.
3 Introduza um nome, como azuremol. Depois, crie um novo grupo de recursos e
forneça um nome, como azuremolchapter17.
4 Selecione a região mais adequada para si e escolha o escalão de preços F0. O seu
bot não irá processar muitas mensagens, portanto, o escalão gratuito (F0) é
suficiente.
5 Selecione um modelo bot e escolha a linguagem Node.js SDK.
6 Crie um bot básico, uma vez que forneceremos o nosso próprio código de aplica-
ção experimental num exercício posterior. Este passo cria uma aplicação LUIS
que pode utilizar para realizar formação de linguagem e ML.
7 Escolha a região mais apropriada para a sua aplicação LUIS e crie uma nova
conta LUIS.
8 Forneça um nome para a conta LUIS, como azuremol. Esta conta LUIS trata do
sentimento do utilizador em relação ao nosso bot.
9 Escolha Plano do App Service e crie um novo plano. Forneça um nome, como
azuremol, e volte a selecionar a região mais apropriada para si.
10 Desative o App Insights, porque o seu bot não vai utilizá-lo. Tal como em capítulos
anteriores sobre aplicações Web para utilização em ambientes de produção, pode
querer aproveitar o poder do App Insights para obter visibilidade sobre o desem-
penho da sua aplicação, transmitindo dados e análises diretamente do código.
11 Aceite a opção de criar automaticamente o ID e a palavra-passe da aplicação
Microsoft, aceite o contrato e, em seguida, escolha Criar.
Leva alguns minutos a criar o bot da aplicação Web e os componentes associados.
Muita coisa acontece em segundo plano:
¡ É criado um plano do App Service do Azure.
¡ É implementada uma aplicação Web, juntamente com uma aplicação Web em
Node.js de exemplo.
¡ É criada uma aplicação LUIS e as chaves de ligação são configuradas com a sua
aplicação Web.
¡ É criado um bot com o Microsoft Bot Connector e as chaves de ligação são confi-
guradas a partir da sua aplicação Web.
17.3.2 Linguagem e compreensão de intenções com LUIS

Uma das áreas do Azure Cognitive Service que vimos anteriormente foi a linguagem.
Isto faz sentido, porque, muitas vezes, é utilizada alguma forma de linguagem para
interagir com uma IA. Pode utilizar o LUIS para processar uma mensagem ou frase do
utilizador e determinar a sua intenção. Essa intenção ajuda a sua aplicação a fornecer
uma resposta apropriada. Vamos expandir o seu bot com LUIS.
Experimente agora
Para criar uma aplicação LUIS e utilizar o ML para treiná-lo, conclua os passos a seguir
1 Abra um browser para www.luis.aie inicie sessão usando as mesmas credenciais

Microsoft na sua subscrição do Azure.
2 Selecione As Minhas Aplicações e, em seguida, escolha a sua aplicação, como azure-
mol. Provavelmente, o nome da aplicação LUIS tem alguns carateres numéricos adi-
cionais anexados a partir do nome do bot que especificou no portal Azure.
Foram criadas algumas intenções pré-criadas, mas pretende substituir a aplica-
ção LUIS por um exemplo mais apropriado para uma pizzaria.
3 Faça download do ficheiro azuremol.json do GitHub em https://github.com/
fouldsy/ azure-mol-samples-2nd-ed/blob/master/17/luisapp/azuremol.json
para o seu computador local. Para facilitar-lhe a vida, selecione o botão Não Pro-
cessado no GitHub para ver apenas o conteúdo do ficheiro.
4 Ao voltar à sua aplicação LUIS, opte por Gerir a aplicação e, em seguida, sele-
cione Versões.
5 Escolha importar uma versão, navegue até ao ficheiro azuremol.json que fez
download e selecione-o. Introduza um nome de versão 1.0, e, em seguida, sele-
cione Concluído.
6 Volte a Criar, no menu superior, para ver as intenções importadas da aplicação
de exemplo. Escolha uma ou duas intenções, tais como greetings ou order-
Food, e veja algumas das frases de exemplo que um cliente pode utilizar para
comunicar com o bot.
7 Antes de poder ver a aplicação em ação, deve treiná-la. Selecione Treinar e
aguarde alguns segundos para que o processo fique concluído. A figura 17.7
mostra os processos de ML em funcionamento para treinar a sua aplicação LUIS.
Intenções
saudações
showMenu
orderFood Modelo de
Formar dados da Bot da aplicação
aplicação LUIS Compreensão Web
Entidades
da linguagem
"Uma de pepperoni" e processamento
da intenção
"Uma pizza vegetari-
ana, por favor"
Figura 17.7 Quando treina a aplicação LUIS, as intenções e as entidades são introduzidas e processadas para
criar um modelo de dados. Depois, o seu bot da aplicação web utiliza este modelo de dados para processar a
compreensão e a intenção da linguagem. O número de intenções e entidades introduzidas para processamento é
reduzido e, portanto, o modelo de dados não é perfeito. No mundo real, muitas mais intenções e entidades seriam
fornecidas e iria, repetidamente, treinar, testar e refinar o modelo de dados para criar conjuntos de dados
progressivamente maiores, de forma a criar um modelo preciso para processar a linguagem e a intenção.
Numa aplicação mais complexa e real, pode levar mais tempo a concluir este pro-
cesso de treino, porque todas as suas intenções e entidades são processadas pelos
algoritmos de ML para criar o modelo de dados necessário de forma a que a sua
aplicação responda adequadamente à comunicação do cliente.
8 Com a aplicação LUIS treinada, selecione Teste e insira algumas saudações, tais
como oi e olá. Por baixo de cada uma das suas mensagens está a intenção de pon-
tuação superior, juntamente com a probabilidade de que a mensagem, ou
expressão, que introduziu coincide com a intenção. Estas saudações básicas
devem corresponder à intenção de saudação.
9 Tente introduzir uma saudação diferente, como (boa) tarde ou (boa) noite. A sauda-
ção de uma só palavra com base na hora do dia pode devolver uma intenção
incorreta de pontuação superior, como orderStatus. Experimente algumas
outras frases até que algo não se alinhe com a intenção esperada, o que indica
que a aplicação LUIS não compreende totalmente o que quer dizer. Selecione
uma das suas mensagens incorretas, como manhã, e escolha Inspecionar.
10 No menu Inspecionar, escolha editar a intenção de pontuação superior incor-
reta. No menu pendente, escolha saudações ou a intenção que seja mais apro-
priada para a frase incorreta.
11 Fez uma alteração na sua aplicação, por isso escolha Treinar para treinar a aplica-
ção LUIS novamente. A figura 17.8 mostra como fornecer entradas adicionais
para os algoritmos de ML para processar o modelo de dados e refinar a intenção
e compreensão da linguagem.
12 Na janela de mensagens de teste, volte a introduzir a mensagem incorreta nova-
mente, tal como manhã. Desta vez, a intenção de pontuação superior deve ser
identificada corretamente como saudações.
13 Para que a aplicação LUIS atualizada fique disponível no bot da aplicação Web,
escolha a opção Publicar no menu superior. Aceite todas as predefinições e esco-
lha publicar num bloco de produção. Demora alguns segundos a concluir o pro-
cesso de publicação.
Intenções
saudações
showMenu
orderFood
Modelo de Figura 17.8 À medida que
Formar dados da reclassifica a intenção das
aplicação LUIS mensagens e volta a treinar a
Entidades aplicação LUIS, o modelo de dados é
refinado à medida que as entradas de
"Uma de pepperoni"
dados adicionais são fornecidas aos
"Uma pizza vegetari- algoritmos de ML. Quando introduzir
ana, por favor" Reclassificar a saudações semelhantes no futuro,
intenção da o modelo de dados será (idealmente)
mensagem melhorado e responderá mais
apropriadamente.
Lembre-se de que o seu bot é executado numa aplicação Web e, por isso, possui blocos de
teste e produção, tal como aprendeu no capítulo 3. No mundo real, deve publicar num
bloco de teste, verificar se tudo funciona conforme o esperado e, em seguida, voltar a
publicar no bloco de produção. As mesmas funcionalidades PaaS que lhe permitiram tes-
tar e movimentar o código Web entre os ciclos de vida de desenvolvimento e produção
também beneficiam o ciclo de vida do seu bot da aplicação Web processado pelo LUIS.
Neste exemplo básico, o ML foi capaz de gerir a sua entrada de dados (bom) dia como
sendo uma saudação e para entender que saudações similares, tais como (boa) noite,
também são saudações. O ML funciona melhor quando um grande conjunto de dados
pode ser introduzido no modelo de dados; portanto é importante testar e ajudar a for-
mar a sua aplicativa. O desempenho da IA - neste caso a aplicação LUIS - depende dire-
tamente do tamanho e da qualidade dos dados fornecidos nos algoritmos de ML.
17.3.3 Criar e executar um bot da aplicação Web com LUIS

Tem agora um bot da aplicação Web básico no Azure e uma aplicação LUIS que gere
processamento da linguagem e devolve a intenção do cliente Para integrar os dois, pre-
cisa de modificar o código para o seu bot, de forma a utilizar o LUIS. Os SDKs estão dis-
poníveis para as linguagens de programação C# e Node.js. Se tudo isto for novo para si,
creio que com Node.js será um pouco mais rápido e fácil de entender o que acontece no
código. Se estiver familiarizado com C#, está convidado a explorar o SDK C# quando
tiver terminado este capítulo. Por enquanto, vamos utilizar uma aplicação Node.js básica
do repositório de exemplo do GitHub para ver o seu bot em ação com o LUIS.
Experimente agora
Para atualizar o seu bot da aplicação Web com o seu bot LUIS treinado, conclua os pas-
sos a seguir:
1 No portal Azure, escolha Grupos de Recursos, no menu à esquerda, e o seu

grupo de recursos, como azuremolchapter17. Em seguida, selecione o seu
bot de aplicação web, como o azuremol.
Vamos usar um bot de exemplo do nosso repositório de exemplos do GitHub.
O bot de exemplo está escrito em Node.js, mas, tal como em anteriores aplicações
experimentais, não se preocupe se isso não for a sua praia.
2 Para implementar o bot de exemplo, abra o Cloud Shell. Se for necessário, clone
o repositório de exemplos do GitHub no seu Cloud Shell da seguinte maneira:
3 Mude para o diretório encontrado no capítulo 17:

cd azure-mol-samples-2nd-ed/17/webappbot
4 Inicialize o repositório Git e adicione os ficheiros de bot:

5 Para carregar o bot de exemplo, crie uma ligação à sua aplicação Web. O
comando seguinte obtém o repositório de aplicações Web e configura o seu
repositório Git de exemplos local para se ligar ao mesmo. Nos capítulos anterio-
res, fi-lo procurar este endereço, mas agora espero que tenha começado a explo-
rar aquilo que a CLI do Azure pode fazer mais e que tenha percebido que muitas
destas informações podem ser obtidas rapidamente.
git remote add webappbot \

$(az webapp deployment source config-local-git \
--name azuremol \
--output tsv)
6 Emita o bot Node.js de exemplo para a sua aplicação Web com o seguinte
comando:
git push webappbot master
7 Quando pedido, introduza a palavra-passe do utilizador do Git que criou e utili-

zou nos capítulos anteriores (a conta criada no capítulo 3).
Se não escreveu a sua palavra-passe do Git num post-it

Se se esqueceu da palavra-passe, pode repô-la. Primeiro, obtenha o nome de utilizador
da sua conta de implementação do Git local:
az webapp deployment user show --query publishingUserName
Para repor a palavra-passe, introduza o nome da sua conta a partir do comando anterior
e, em seguida, responda às instruções para definir uma nova palavra-passe. O exemplo
a seguir repõe a palavra-passe da conta de utilizador denominada azuremol:
az webapp deployment user set --user-name azuremol
Vamos consultar a figura 17.9 para ver o que implementou. Agora, a aplicação LUIS é
treinada com algoritmos de ML e o seu modelo de dados está pronto para a aplicação
Node.js, de forma a permitir que os clientes interajam e façam pedidos de pizza.
Subscrição do Azure
Plano do App Service
Compreensão e Web App
intenção da O cliente
linguagem Microsoft Bot
Aplicação Node.js esfomeado online
Connector
LUIS aplicação Chats do cliente com quer pedir uma
Framework
bot, que é processado pizza
pelo LUIS.
Armazena dados persistentes
do bot e estado de sessão
Conta Storage
Tabela
Figura 17.9 Um cliente pode agora aceder ao seu bot online e pedir para ver o menu ou fazer pedidos de pizza.
O LUIS fornece a compreensão da linguagem, que permite que o bot processe os pedidos e os envie para o Azure
Storage para processamento adicional.
Novamente no portal Azure, para o seu bot da aplicação Web, selecione Teste no Chat
na Web. Leva alguns segundos a ligar-se ao bot da primeira vez, mas, depois, deverá
poder interagir, ver a lista de pizzas no menu e criar um pedido, tal como mostrado na
figura 17.10. Experimente você mesmo!
Figura 17.10 Com o seu bot da aplicação Web em execução, inicie uma conversa e tente fazer um
pedido de pizza. Nesta caixa de diálogo de exemplo, pode visualizar o menu, fazer um pedido de pizza
e verificar o estado do pedido. A aplicação é básica e não está, realmente, a criar pedidos ou a atualizar
o estado além da pizza pedida, mas espero que o exercício mostre como pode implementar rapidamente
um bot no Azure.
Laboratório: adicionar canais para comunicação com o bot 267
Espero que estes exercícios básicos tenham-lhe dado uma ideia do que o Azure pode
oferecer para IA e ML. O bot da aplicação Web com o LUIS pode ser expandido para
incluir Azure Cognitive Services adicionais, como Spellcheck e o Translator. Estes servi-
ços permitem-lhe interpretar palavras e frases caso o utilizador as escreva incorreta-
mente ou fazer com que o seu bot converse em vários idiomas. Por outro lado, pode
utilizar o Face e Personalizador para detetar qual cliente estava a fazer um pedido com
base no reconhecimento facial da sua câmara e sugerir automaticamente pizzas que o
mesmo possa gostar.
O ML fazia parte da aplicação LUIS, mas muitos outros recursos e ferramentas de
ML estão disponíveis no Azure. A capacidade de processar grandes conjuntos de dados
e computar modelos de dados de ML em recursos de computação do Azure de elevado
desempenho reduz a entrada, para que possa criar aplicações suportadas por alguns
conjuntos de dados maiores. As aplicações são mais precisas e eficientes e não há har-
dware para comprar ou ferramentas especiais para instalar, porque as DSVMs incluem
todos os componentes necessários. Nem todas as aplicações são adequadas para AI e
ML, mas como os clientes começam a esperar mais funcionalidades inteligentes da sua
empresa, estes serviços do Azure podem, geralmente, ajudar a fazer a diferença.
Processamento de workload em lotes

Outras duas áreas do Azure que podem ser de interesse em termos de big data e compu-
tação para ML são os serviços Azure Batch e HPC. O Azure Batch permite executar tare-
fas de computação repetitivas e grandes sem a necessidade de gerir clusters de
agendadores para o trabalho. O Batch executa tarefas em VMs com a sua própria gestão
e agendador para ajudá-lo, uma vez que os conjuntos de dimensionamento incluem o
dimensionamento automático e o balanceamento de carga para VMs. Embora o Batch
não esteja diretamente relacionado com o ML, se precisar de outras tarefas de proces-
samento de computação grandes, o Batch é bastante adequado.
Há também componentes de computação de alto desempenho (HPC) no Azure para VMs
de grande dimensão ou acesso às VMs da unidade de processamento gráfico (GPU).
Também podem ser utilizadas ferramentas e conjuntos de aplicações específicos,
como DataSynapse e Microsoft HPC Pack, para executar aplicações que exigem uma
grande capacidade de processamento.
As áreas como o ML, o Azure Batch e o HPC são ótimos exemplos de como utilizar forne-
cedores de cloud computing, como o Azure, para executar tarefas de computação gran-
des. Só paga pelos recursos de computação que utiliza, não precisando assim de
comprar e fazer manutenção de um equipamento caro que é pouco utilizado.
17.4 Laboratório: adicionar canais para comunicação com o bot

Nos exemplos anteriores, comunicou com o bot por meio de uma janela de teste no
portal Azure. Os canais permitem-lhe expandir as formas como pode interagir com o
seu bot. Pode permitir que o seu bot comunique com o Skype ou Facebook Messenger,
ou com aplicações como o Microsoft Teams e Slack. O Azure Bot Service simplifica os
passos necessários para integrar um bot nesses serviços externos:
1 No portal Azure, selecione o bot da aplicação Web e escolha Canais.

2 Escolha um canal que goste, como o Skype.
Muitas vezes, outros canais exigem que crie uma ligação de programador,
como para Facebook ou Slack. O Skype permite-lhe copiar e colar algum código
HTML para fazê-lo funcionar.
3 Forneça todas as informações necessárias, como o ID de Aplicação do Bot. Pode
encontrar este ID em Definições para Gestão de Bots.
4 Se necessário, utilize o editor de código online para criar uma página HTML
básica, como default.htm, no diretório wwwroot e cole qualquer código incorpo-
rado para o seu canal. Pode abrir a sua aplicação Web a partir do portal Azure e,
em seguida, selecionar o seu URL para abrir a página default.htm que inclui o
seu código de canal, tal como http://azuremol.azurewebsites.net/default.htm.
18 Azure Automation
Sempre que possível, não deve iniciar sessão manualmente num servidor e realizar
alterações. O software não precisa de ser instalado clicando nos botões numa GUI, e
as atualizações não precisam de ser efetuadas em ficheiros de configuração num edi-
tor de texto. Estas ações manuais introduzem uma oportunidade para que ocorram
erros, o que pode resultar em configurações incorretas e falhas na aplicação. Se pre-
tender replicar a configuração de um servidor, conseguirá lembrar-se de todos os pas-
sos que foram necessários para colocar o servidor existente em funcionamento? E se
precisar de fazer isso novamente dentro de seis meses?
No capítulo 16, abordámos uma forma de verificar e aplicar atualiza-
ções aos servidores automaticamente. Esta magia aconteceu com a utilização da Auto-
mation do Azure. Neste capítulo, iremos examinar como pode criar, executar e editar
runbooks e utilizar a Desired State Configuration do PowerShell para instalar aplica-
ções e configurar servidores automa ticamente.
18.1 O que é o Azure Automation?

Uma conta de Automation do Azure reúne muitos elementos diferentes, tal como
mostrado na Figura 18.1. Uma funcionalidade core é criar e executar scripts a
pedido ou numa agenda definida. Pode criar scripts no PowerShell ou Python e per-
mitir que a plataforma do Azure processe o agendamento e a execução desses
runbooks. Pode partilhar credenciais e objetos de ligação, bem como aplicar e
reportar automaticamente as configurações pretendidas dos servidores. A Gestão
de Atualizações, que examinámos no capítulo 16, mantém os seus servidores segu-
ros e atualizados com os patches e atualizações de host mais recentes ao longo do
ciclo de vida do seu ambiente de aplicação.
269
270 Capítulo 18 Azure Automation
Configuração de estado desejada

Runbooks
• Define aplicações,
• Automatizar tarefas com configurações e ficheiros
o PowerShell ou Python
• Aplica, reporta e corrige
• Ferramentas de design gráficas o desvio
• Execução agendada • Suporte para Windows + Linux
Azure Automation
Gestão de Atualizações Recursos partilhados

• Atualizações de host • Credenciais, certificados
do Windows/Linux e ligações
• Relatórios de conformidade • Importar módulos adicionais
• Atualizações agendadas • Reutilizar agendas
Figura 18.1 A Automation do Azure fornece muitas funcionalidades relacionadas. Um conjunto partilhado
de recursos, como credenciais, certificados, agendas e objetos de ligação, pode ser utilizado para executar
scripts do PowerShell ou Python automaticamente em servidores de destino. Pode definir o estado pretendido
de um servidor, e a Automation do Azure instala e configura o servidor apropriadamente. As atualizações
de hosts e os patches de segurança podem ser aplicados automaticamente. Todas estas funcionalidades
funcionam em servidores Windows e Linux, no Azure, em outros fornecedores de cloud e on-premises.
Para simplificar a gestão em vários runbooks ou configurações do estado pretendido

numa conta de Automation, pode partilhar os seguintes recursos:
¡ Agendas permitem definir um conjunto de horários e recorrências que podem ser
aplicados a cada tarefa de runbook ou Gestão de Atualizações. Se pretender alte-
rar uma ocorrência regular posteriormente, poderá alterar uma das agendas par-
tilhadas em vez de cada runbook individual ou tarefa de Gestão de Atualizações
que o utiliza.
¡ Módulos expandem a funcionalidade core armazenando os módulos adicionais
do PowerShell. Os módulos básicos do Windows PowerShell e do Azure já estão
disponíveis, mas os módulos adicionais, como a gestão do Linux, podem ser adi-
cionados e utilizados em runbooks.
¡ Credenciais das diferentes contas que têm permissões para executar vários runbooks
são armazenadas como ativos, não definidas em cada runbook. Esta abordagem
permite atualizar e repor as credenciais conforme necessário e cada runbook que
as utiliza é atualizado automaticamente. Assim, as credenciais não são armazenadas
em texto simples em runbooks, o que aumenta a segurança dos runbooks.
¡ Ligações definem propriedades de autenticação para principais de serviço do
Azure AD. Este é um tipo especial de conta de utilizador que permite que os
runbooks acedam aos seus recursos do Azure. Normalmente, estas ligações utili-
zam certificados digitais, e não nomes de utilizador e palavras-passe, para forne-
cer uma camada adicional de segurança.
¡ Certificados muitas vezes são integrados nos ativos de ligação para fornecer uma
maneira segura de verificar a identidade de um principal de serviço. Tal como com
as credenciais básicas, pode atualizar regularmente estes certificados numa locali-
zação central e cada runbook que os utiliza pode aceder automaticamente aos
novos certificados. Pode criar e armazenar os seus próprios certificados para utiliza-
ção com runbooks ou com as definições de configuração do estado pretendido.
O que é o Azure Automation? 271
¡ Variáveis fornecem um local central para valores de runtime, como nomes,

cadeias de localização e números inteiros a serem armazenados. Quando os seus
runbooks são executados, estas variáveis são injetadas. Esta abordagem limita a
quantidade de recursos codificados dentro de cada runbook.
Não trabalhe mais horas. Trabalhe de forma mais eficaz.

No capítulo 16, vimos como os serviços de gestão do Azure trabalham em conjunto para
monitorizar e reportar servidores no Azure, on-premises ou em outros fornecedores
de cloud. Você instala e configura os agentes necessários em servidores remotos e,
em seguida, fornece uma maneira para que os mesmos se voltem a ligar à infraestrutura
do Azure.
A Automation do Azure também pode funcionar em plataformas e infraestruturas dife-
rentes. A função de trabalho runbook híbrida pode executar runbooks de Automation em
servidores fora do Azure, por exemplo. Continua a utilizar os ativos de Automation parti-
lhados que definem credenciais, ligações e certificados, só que, desta vez, esses ativos
podem ser utilizados para definir os componentes de autenticação para as diferentes
plataformas. Também pode utilizar as configurações do estado pretendido em VMs que
não são do Azure, tanto para Windows como para Linux.
Em todos os casos, um componente de gateway é instalado no ambiente remoto para
atuar como um proxy para os comandos de Automation, pois são enviados para os desti-
nos designados. Esta abordagem de proxy de gateway fornece um único ponto de liga-
ção para a Automation em ambientes remotos e minimiza quaisquer preocupações de
segurança, pois não há acesso direto aos servidores remotos de outra forma.
Os runbooks e as definições de configuração do estado pretendido talvez precisem de
ser editados um pouco para serem executados em servidores físicos on-premises em
comparação com as VMs do Azure. Assim como o Azure Backup, Site Recovery ou a Ges-
tão de Atualizações, a vantagem da Automation do Azure é que fornece um único plano
de gestão e um conjunto de ferramentas para fornecer automatização em todas as suas
diferentes infraestruturas e servidores.
18.1.1 Criar uma conta de Automation do Azure

Vamos entrar, criando uma conta de Automation do Azure e analisando os runbooks
predefinidos incluídos. Os runbooks de demonstração fornecem uma ótima estrutura
para criar os seus próprios runbooks, e há também um editor gráfico que pode utilizar
para arrastar e largar blocos modulares para gerar scripts de automatização.
Experimente agora
Para criar uma conta de Automation do Azure e runbooks de exemplo, conclua os pas-
sos a seguir:
1 No portal Azure, selecione Criar um Recurso, no canto superior esquerdo.

2 Procure e selecione Automation e, em seguida, selecione Criar.
A opção Automation e Controlo também cria um espaço de trabalho do Ope-
rations Management Suite (OMS) e configura a Função de Trabalho Híbrida de
Automation para gerir os recursos fora do Azure. O OMS está um pouco na porta
de saída, substituído pelos serviços principais do Azure que analisámos em capítu-
los anteriores. Por enquanto, opte por criar apenas o recurso de automatização.
3 Introduza um nome, como azuremol, e crie um novo grupo de recursos,

como azuremolchapter18.
4 Selecione a região mais apropriada do Azure mais próxima de si e aceite a opção
Criar Conta de Execução do Azure.
A opção Criar Conta de Execução cria contas adicionais no Azure AD. Tam-
bém são criados certificados de segurança para permitir que as contas sejam
autenticadas de forma automatizada e sem a necessidade de pedir informação ao
utilizador ou de guardar palavras-passe. Pode criar e especificar credenciais de
conta regulares adicionais, definidas como um ativo de Automation, para forne-
cer um controlo mais granular de quais contas são utilizadas para executar deter-
minados runbooks.
Quando combinado com RBAC, que vimos no capítulo 6, podem ser criadas contas de
Execução específicas para runbooks que fornecem um conjunto limitado de permis-
sões necessárias para realizar as tarefas que cada runbook, ou conjunto de runbooks,
requer. Do ponto de vista de segurança, esta abordagem permite-lhe auditar e contro-
lar como e quando estas contas são utilizadas. Evite a tentação de criar uma única conta
de Execução que forneça permissões de administrador, pois esta abordagem fornece
pouca proteção contra abuso.
18.1.2 Ativos e runbooks de Automation do Azure

A conta de Automation do Azure criada na secção 18.1.1 inclui alguns runbooks de
exemplo. Encontram-se disponíveis exemplos do PowerShell e do Python. Também
são adicionados ativos de ligação e certificados à conta de Automation para as contas
de Execução que foram criadas. Vamos explorar esses ativos de ligação partilhados.
Experimente agora
Para ver os ativos configurados e os runbooks de exemplo, conclua os passos a seguir:
1 No portal Azure, selecione Grupos de Recursos à esquerda, escolha o seu grupo,

como o azuremolchapter18 e selecione a sua conta de Automation do Azure,
como azuremol.
2 Em Recursos Partilhados, no menu à esquerda, selecione Ligações.
3 Selecione AzureRunAsConnection, tal como mostrado na figura 18.2.
4 Escolha Certificados no menu principal da conta de Automation, em Recursos parti-
lhados, e, em seguida, escolha o AzureRunAsCertificate. Como mostrado na figura
18.3, o thumbprint corresponde ao modelo RunAsConnection do passo anterior.
O que é o Azure Automation? 273
Figura 18.2 As informações sobre a conta Execução incluem um ApplicationId e TenantId, propriedades
específicas para Azure AD que ajudam a identificar as credenciais para esta conta. É apresentado um
CertificateThumbprint, que coincide com um certificado digital que iremos visualizar no próximo passo.
Figura 18.3 O thumbprint

do RunAsCertificate
corresponde ao mostrado
em RunAsConnection. Nos
seus runbooks, define qual
ativo de ligação vai ser
utilizado. É utilizado o
certificado apropriado
para iniciar sessão na
conta do Azure.
5 Agora que compreende os ativos para ligações e certificados, vamos olhar

para um dos runbooks de exemplo. Escolha Runbooks no menu à esquerda da
conta de Automation. Alguns runbooks de exemplo estão disponíveis.
6 Escolha o runbook do PowerShell chamado AzureAutomationTutorialScript.
7 Na parte superior do runbook de exemplo encontram-se opções para Iniciar, Ver
e Editar o runbook. Estas opções devem ser autoexplicativas!
Também tem uma opção para agendar, que lhe permite criar ou selecionar um
recurso partilhado que define uma agenda para executar o runbook num determi-
nado momento e uma opção para webhooks, que permite criar um URL de webhook
para executar o runbook a partir de algum outro script ou ação. Escolha Visualizar.
Automation do Azure e controlo de origem com GitHub

Os runbooks podem ser integrados num sistema de controlo de origem, como o GitHub.
Um dos grandes benefícios de um sistema de controlo de origem para os seus runbooks
é que fornece uma maneira para a gestão de alterações ser documentada e para rever-
ter para versões anteriores dos runbooks, caso ocorra algum problema.
De cada vez que guarda um runbook da Automation do Azure, é consolidada uma nova
versão no controlo de origem. Não é necessário deixar o editor do runbook, porque a pla-
taforma e o sistema de controlo da origem do Azure estão configurados para trabalhar
para trás e para a frente. Se tiver um problema com o novo runbook, poderá utilizar uma
versão anterior do controlo de origem que permite que as tarefas continuem a ser execu-
tadas sem atraso e, em seguida, resolver problemas da versão atualizada.
Utilizar o controlo de origem também fornece um registo de quais alterações ocorreram
e quando. Se precisar de auditar os seus runbooks ou entender como se desenvolveram
ao longo do tempo, os sistemas de controlo de origem fornecem uma ótima maneira de
ver as diferenças com cada revisão.
18.2 Runbook de exemplo de Automation do Azure

Vamos examinar como o runbook do PowerShell de exemplo, AzureAutomationTuto-
rialScript, se liga ao Azure e recolhe informações sobre os seus recursos. Pode acompanhar
o runbook do Python de exemplo, se preferir; o layout é semelhante. O PowerShell
e o Python são as únicas linguagens atualmente suportadas nos runbooks de Automation
do Azure. A listagem a seguir configura as credenciais de ligação no runbook.
Listagem 18.1 Configurar credenciais de ligação
$connectionName = "AzureRunAsConnection" Cria um objeto para $connectionName

try
{ Realiza o pedido de ligação
# Get the connection "AzureRunAsConnection "
$servicePrincipalConnection=Get-AutomationConnection -Name
➥$connectionName
"Logging in to Azure..."
Add-AzureRmAccount ` Cria um objeto do principal de serviço
Runbook de exemplo de Automation do Azure 275
-ServicePrincipal `
-TenantId $servicePrincipalConnection.TenantId `
-ApplicationId $servicePrincipalConnection.ApplicationId ` Inicia sessão
-CertificateThumbprint
no Azure
➥$servicePrincipalConnection.CertificateThumbprint
}
O código começa por criar um objeto para $connectionName. No exercício "Experi-

mente agora", viu que foi criado um ativo de ligação predefinido para AzureRunAs-
Connection. À medida que cria os seus próprios runbooks, convém criar contas de
execução e ativos de ligação adicionais para separar os runbooks e as credenciais que
utilizam. As partes de ligação e o processamento de exceções que iremos ver em
seguida devem ser comuns em todos os runbooks. Conforme necessário, pode alterar
o ativo de ligação de execução a ser utilizado.
Em seguida, é utilizada uma instrução try para realizar o pedido de ligação. É criado
um objeto do principal de serviço denominado $servicePrincipalConnection com
base em $connectionName. Em seguida, o runbook inicia sessão no Azure com Add-
-AzureRmAccount e utiliza o objeto $servicePrincipalConnection para obter o
TenantId, ApplicationId e Certificate-Thumbprint. Discutimos anteriormente
estes parâmetros como parte do ativo de ligação. O ativo do certificado que corres-
ponde ao thumbprint de $servicePrincipalConnection é utilizado para concluir o
início de sessão no Azure.
A próxima listagem mostra que, se a ligação falhar, o runbook irá capturar o erro e irá
parar a execução.
Listagem 18.2 Capturar um erro e parar a execução do runbook
catch {
if (!$servicePrincipalConnection)
{
$ErrorMessage = "Connection $connectionName not found."
throw $ErrorMessage
} else{
Write-Error -Message $_.Exception
throw $_.Exception
}
}
A instrução catch processa quaisquer erros como parte da tentativa de início de ses-
são. Se uma ligação do principal de serviço não puder ser encontrada, é gerado um
erro. Geralmente, este erro significa que o ativo de ligação especificado não pode ser
encontrado. Confirme o nome e a ortografia da sua ligação.
Caso contrário, o objeto de ligação foi encontrado e o principal de serviço foi utilizado
para iniciar sessão, mas esse processo de autenticação não foi bem-sucedido. Esta falha
pode ter origem num certificado que já não é válido ou numa conta de Execução que já
não está ativa. Esta funcionalidade mostra como pode revogar uma conta no Azure AD e
garantir que todos os runbooks que utilizem as credenciais já não podem ser executados.
Agora, o runbook obtém uma lista de todos os recursos do Azure.
Listagem 18.3 Obter uma lista de recursos do Azure
$ResourceGroups = Get-AzureRmResourceGroup
foreach ($ResourceGroup in $ResourceGroups)
{
Write-Output ("Showing resources in resource group "
➥+ $ResourceGroup.ResourceGroupName)
$Resources = Find-AzureRmResource -ResourceGroupNameContains
➥$ResourceGroup.ResourceGroupName |
➥Select ResourceName, ResourceType
ForEach ($Resource in $Resources)
{
Write-Output ($Resource.ResourceName + " of type "
➥+ $Resource.ResourceType)
}
Write-Output ("")
}
A parte final do runbook é para onde o seu código de runbook iria. É criado um objeto
para $ResourceGroups que obtém uma lista de todos os grupos de recursos do Azure
disponíveis. Em seguida, um ciclo foreach passa por cada grupo de recursos, localiza
uma lista de recursos e escreve uma lista de nomes e tipos de recurso.
Este exemplo básico mostra como pode interagir com o Azure quando o runbook tiver
sido autenticado na subscrição. Se implementar RBAC na conta de Execução, apenas os
grupos de recursos que a conta tem permissão para ver serão devolvidos. Esta abordagem
ao RBAC destaca por que é que é um bom principal de segurança para criar e utilizar con-
tas de Execução com âmbito para limitar o acesso dos runbooks aos recursos no seu
ambiente do Azure. Certifique-se sempre de fornecer os privilégios mínimos necessários.
Se tudo isto do PowerShell ou Python for novo para si, não se preocupe. Ambos for-
necem boas linguagens de script básica que também podem ser utilizados para desen-
volver aplicações complexas e poderosas. Como programador, deve achar qualquer
linguagem relativamente fácil para escolher e utilizar. Se for um profissional de TI,
automatizar tarefas liberta o seu tempo para executar todas as outras tarefas e o Power-
Shell ou Python são bons lugares para começar. A Manning Publications também tem
alguns outros ótimos livros para ajudá-lo!
18.2.1 Executar e ver a saída de um runbook de exemplo

Agora que já viu o que o script de runbook de exemplo contém e como os ativos de liga-
ção e de certificado são utilizados, vamos executar o runbook e examinar o resultado.
Experimente agora
Para ver o runbook em ação, conclua os passos a seguir:
1 Feche a janela que mostra o conteúdo do runbook e volte à descrição geral

do AzureAutomationScriptTutorial.
2 Selecione Iniciar na parte superior da janela do runbook.
Runbook de exemplo de Automation do Azure 277
3 Confirme se pretende iniciar o runbook e aguarde alguns segundos para o

runbook começar a ser executado.
4 Selecione Saída, como mostrado na figura 18.4, e, em seguida, veja a janela da
consola. Enquanto o runbook inicia sessão no Azure, obtém uma lista de grupos
de recursos e percorre e gera a lista de recursos em cada grupo.
Figura 18.4 Pode visualizar a saída do runbook, juntamente com os registos que são gerados ou
erros e avisos. Este exemplo básico é concluído em poucos segundos, mas os runbooks mais
complexos podem demorar mais tempo. Pode monitorizar o estado desses runbooks mais longos
e parar ou pausar a sua execução, caso seja necessário.
Os runbooks de Automation não precisam de existir isoladamente. Um runbook pode

executar outro runbook. Esta capacidade permite-lhe criar uma automatização com-
plexa de vários passos e minimizar a duplicação do código. À medida que conceber e
criar runbooks, tente dividi-los em blocos de código pequenos e discretos. As funções
comuns que pode reutilizar, como iniciar sessão no Azure e gerar uma lista de recursos
ou uma lista de VMs, devem ser criadas como runbooks pequenos que possam ser
incluídos em runbooks maiores. À medida que novos cmdlets do PowerShell são lança-
dos ou os parâmetros são alterados, pode atualizar rapidamente um só runbook parti-
lhado que inclua esses cmdlets, em vez de precisar de atualizar vários runbooks
diferentes. No início, pode não parecer valer a pena trabalhar um pouco mais os
runbooks mais pequenos e reutilizáveis, mas, à medida que o seu ambiente e utilização
da automação vão aumentando, vai agradecer-me! Muito do que fez neste livro tem
sido em pequenas implementações, mas comece a pensar em como implementar
e gerir aplicações em escala.
18.3 PowerShell Desired State Configuration (DSC)

O capítulo 12 introduziu o conceito de extensões de VM. Uma extensão é um compo-
nente de software pequeno que é instalado numa VM para executar uma determinada
tarefa. A extensão de diagnóstico de VM foi instalada numa VM para permitir que as
métricas de desempenho e os registos de diagnóstico sejam reportados à plataforma
do Azure dentro da VM. Isso é ótimo, mas também conversámos um pouco sobre como
pode instalar o software automaticamente.
Uma forma de instalar o software e configurar um servidor é utilizar o PowerShell
Desired State Configuration (DSC). Com o DSC, define como pretende que um servi-
dor seja configurado, o estado pretendido. Pode, por exemplo, definir os pacotes a
serem instalados, os recursos a serem configurados ou os ficheiros a serem criados.
O interessante do DSC é que vai para além da primeira ação de instalação e configura-
ção. Com o tempo, muitas das vezes, os servidores passam por eventos de manutenção
ou de resolução de problemas em que as configurações e os pacotes são alterados
manualmente. Em seguida, o servidor vai desviar-se do estado pretendido que definiu
inicialmente. A figura 18.5 mostra como a Automation do Azure pode atuar como um
servidor central que armazena as definições de DSC, permitindo que os servidores de
destino recebam as suas configurações e reportem a sua conformidade.
O Local Configuration Manager (LCM) em cada servidor de destino controla o pro-
cesso de ligação ao servidor pull de Automation do Azure, recebendo e analisando a
definição de DSC e aplicando e reportando a conformidade. O motor LCM pode ope-
rar sem um servidor pull, onde chama localmente o processo para ler e aplicar uma
Servidor pull do DSC

do Azure Automation
1. Configuração
pretendida armazenada 3. Os servidores extraem e aplicam
no Azure Automation 2. Servidores
configurados para a configuração pretendida
utilizar o servidor pull
do DSC de Automation
configuration WebServer {
Node localhost {
WindowsFeature WebServer { VM do Azure Servidor
Ensure = "Present"
Name = "Web-Server
físico
} on-premises VM de outro
} fornecedor de
} cloud
Figura 18.5 A configuração do estado pretendido para um servidor é criada e armazenada na Automation
do Azure. A conta de Automation atua como um servidor pull, que permite que os servidores ligados
retirem a configuração necessária de uma localização central. Podem ser definidos diferentes modos de
configuração para o comportamento de remediação do servidor se a sua configuração se desviar do
estado pretendido.
PowerShell Desired State Configuration (DSC) 279
definição DSC. Neste modo, no qual envia manualmente a configuração para o motor
LCM, perde imensos controlos centrais e relatórios que muitas vezes são necessários ao
gerir muitos servidores.
Também há flexibilidade na forma como os servidores de destino processam as defi-
nições de DSC recebidas do servidor pull de Automation do Azure. Pode configurar o
DSC para funcionar num dos três modos de configuração:
¡ Apenas aplicar: o estado pretendido é enviado e aplicado ao servidor de destino e
já está. Isto é como o comportamento da Extensão de Script Personalizado do
Azure, em que todas as configurações ou instalações são aplicadas quando imple-
mentadas pela primeira vez mas não há nenhum processo implementado para
parar manualmente essas configurações, alterando o ciclo de vida do servidor.
¡ Aplicar e monitorizar: depois de o servidor ter o estado pretendido aplicado, o DSC
continuará a monitorizar as alterações que fazem com que o servidor se desvie
dessa configuração inicial. Pode ser utilizado um relatório central para ver os ser-
vidores que já não são compatíveis com o seu estado pretendido. Esta configura-
ção é um bom equilíbrio entre a necessidade de manter um servidor compatível
com o estado pretendido e fornecer um elemento de interação humana para
decidir sobre as opções de remediação.
¡ Aplicar e corrigir automaticamente: a configuração mais automatizada e autónoma
aplica o estado pretendido, monitoriza os desvios e corrige automaticamente o
servidor caso ocorram alterações, para garantir que permanece compatível. Há
um risco de que as alterações manuais legítimas sejam substituídas e, em
vez disso, devolvidas ao estado pretendido configurado, mas este modo de confi-
guração garante que as definições que atribui têm sempre prioridade.
O PowerShell DSC pode ser utilizado em VMs executadas em outros fornecedores de
cloud, bem como em VMs on-premises e em servidores físicos. Graças ao .NET Core, o
PowerShell DSC também pode ser utilizado em servidores Linux; portanto, não é uma
solução apenas para Windows. Este suporte compatível com vários fornecedore
s e sistemas operativos torna o PowerShell uma opção poderosa de configuração e de
gestão servidores à escala.
Pode criar e manter o seu próprio servidor pull de DSC, mas as funcionalidades
incorporadas de Automation do Azure fornecem alguns benefícios adicionais:
¡ As credenciais são geridas centralmente e os certificados são gerados
automaticamente.
¡ A comunicação entre o servidor pull de DSC e os servidores de destino
é encriptada.
¡ Os relatórios incorporados são fornecidos para conformidade com DSC, e há
integração com o Log Analytics para gerar relatórios e alertas mais detalhados.
Esta secção é muito mais do que um curso intensivo do PowerShell DSC, é um compo-
nente poderoso por si só e tem estado amplamente disponível há alguns anos. Quando
combinado com a Automation do Azure, o DSC é uma ótima opção para automatizar a
instalação e a configuração do software. Recapitule, por exemplo, os capítulos anterio-
res sobre conjuntos de dimensionamento de virtual machines. Pode aplicar uma confi-
guração de DSC ao conjunto de dimensionamento com Automation do Azure e, como
cada VM é criada no conjunto de dimensionamento, será configurada automatica-
mente com os componentes e os ficheiros de aplicação necessários.
18.3.1 Definir e utilizar o PowerShell DSC, bem como um servidor pull de Automation
do Azure
Espero que essa jornada vertiginosa pelo PowerShell DSC lhe tenha dado uma ideia
do que é possível! Vamos usar o PowerShell DSC para automatizar o exemplo anterior
de instalação de um servidor Web básico numa VM.
Experimente agora
Para ver o PowerShell DSC em ação, conclua os passos a seguir:
1 Crie uma VM Windows Server 2019 Datacenter e abra a porta TCP 80 para
tráfego HTTP. Vá adiante, sem hesitações, pois já estamos no capítulo 18! Pode
criar a VM no Cloud Shell ou no portal Azure: a decisão é sua. Utilize o grupo de
recursos que criou nos exercícios anteriores, como azuremolchapter18. Pode
continuar com os próximos passos à medida que a VM é implementada.
2 No seu computador local, crie um ficheiro chamado webserver.ps1, introduza
o seguinte código e guarde e feche o ficheiro quando tiver acabado:
configuration WebServer {
Node localhost {
WindowsFeature WebServer {
Ensure = "Present"
Name = "Web-Server"
}
}
}
3 No portal Azure, selecione o seu grupo de recursos e escolha a sua conta de

Automation.
4 À esquerda, escolha State Configuration (DSC), selecione o separador Configu-
rações e, na parte superior da janela, escolha a opção Adicionar uma
configuração.
5 Pesquise e selecione o ficheiro webserver.ps1. O nome da configuração deve
coincidir com o nome do ficheiro. Portanto, aceite o nome predefinido do servi-
dor Web e, em seguida, escolha OK.
Leva alguns instantes a carregar e criar a configuração.
6 Quando estiver pronto, selecione a configuração na lista e escolha Compilar.
Nos bastidores do DSC

Vamos fazer uma pausa para falar sobre o que acontece quando compila a configura-
ção, conforme mostrado na figura desta barra lateral. Para distribuir as definições de
DSC, os seus ficheiros do PowerShell são convertidos num ficheiro Managed Object For-
mat (MOF). Este tipo de ficheiro é utilizado para mais do que apenas o PowerShell DSC e
permite alterações de configuração em componentes do Windows de uma maneira cen-
tralizada e bem compreendida. Qualquer definição de DSC, não apenas na Automation
do Azure, deve ser compilada antes de poder ser aplicada a um servidor de destino.
O motor LCM apenas aceita e processa ficheiros MOF.
PowerShell Desired State Configuration (DSC) 281
O servidor pull de DSC de Automation do Azure compila automaticamente a definição de DSC

que fornece num ficheiro Managed Object Format (MOF). Os certificados digitais geridos pela
Automation são utilizados para encriptar o ficheiro MOF. Os servidores de destino de DSC recebem
os certificados digitais públicos necessários e permitem ao motor LCM desencriptar e processar
o ficheiro MOF. Em seguida, o estado pretendido pode ser aplicado ao servidor.
Como o ficheiro MOF define o estado completo dos seus servidores, deve proteger
o seu conteúdo. Se um hacker conhecer todos os componentes da aplicação instalados
e a localização de vários ficheiros de configuração e código personalizados, isso aumen-
tará a possibilidade de os seus servidores ficarem comprometidos. As versões recentes
do PowerShell encriptam todo o ficheiro MOF. A Automatização do Azure gera automati-
camente os certificados e chaves digitais necessários quando um servidor de destino
está configurado para DSC, o que lhe permite utilizar facilmente ficheiros MOF encripta-
dos. A Automation também encripta o tráfego entre o servidor pull de DSC e os nós de
destino, não apenas o ficheiro MOF.
O processo de compilação na Automation do Azure converte a definição de DSC que for-
nece num ficheiro MOF e encripta o ficheiro MOF com as chaves e certificados digitais.
O processo de compilação da sua definição de DSC demora alguns segundos, mas pro-
tege muito bem o seu ambiente: apenas mais um exemplo do Azure a proteger os seus
recursos por predefinição!
7 Para aplicar a configuração na sua VM, selecione o separador de nós nas janelas
de configuração do Estado (DSC), selecione Adicionar e escolha a VM que criou
em passos anteriores.
8 Escolha Ligar.
9 No menu pendente Nome de Configuração do Nó, escolha webserver.
local-host.
10 Defina o modo de configuração como ApplyAndMonitor e selecione OK.
Isto pode levar um minuto ou dois a permitir que a VM utilize o servidor pull
do Azure PowerShell DSC e aplique o estado inicial pretendido.
11 Quando o portal Azure comunicar que a configuração foi aplicada, selecione
o seu grupo de recursos. Em seguida, selecione a VM que criou nos passos
anteriores.
12 Abriu a porta TCP 80 para a VM quando criou esta última? Caso contrário, crie
uma regra de grupo de segurança de rede para permitir o tráfego e, em seguida,
abra o IP público da VM num browser. O processo DSC instala o servidor Web do
IIS e a página Web predefinida é carregada, tal como mostrado na figura 18.6.
Figura 18.6 Depois de a VM ter sido ligada ao DSC de Automation do Azure, o estado pretendido será
aplicado e o servidor Web do IIS será instalado.
Este exemplo básico do PowerShell DSC só instala a funcionalidade do servidor Web.

Pode utilizar o PowerShell DSC para configurar o servidor Web do IIS ou copiar
o código da aplicação para a VM e executar o site. Podem ser utilizadas definições com-
plexas de DSC para preparar a VM para fornecer o tráfego aos clientes da pizzaria sem
interação manual. Mais uma vez, pense em como deve criar as suas aplicações para
dimensionar automaticamente: a VM não pode esperar que alguém instale e configure
tudo manualmente!
18.4 Laboratório: utilizar o DSC com Linux

Apenas para provar que o PowerShell DSC funciona em servidores Linux, vamos criar
uma VM Ubuntu, instalar os pré-requisitos necessários e, em seguida, instalar um servi-
dor Web NGINX básico com DSC. Em ambientes de produção, pode utilizar uma ima-
gem de VM personalizada que já tenha os componentes de gestão instalados e, em
seguida, aplicar definições do PowerShell DSC normalmente:
Laboratório: utilizar o DSC com Linux 283
1 O PowerShell DSC para Linux tem algumas limitações nos Linux distros que
suporta sem configuração adicional. Por isso, de modo a manter este exercício
de laboratório de fim de capítulo o mais simples possível, crie uma CentOS 7.7
ou uma VM mais recente e abra a porta 80.
2 Na sua conta de Automation do Azure, escolha Módulos, no menu à esquerda.
3 Selecione Procurar na Galeria e, em seguida, selecione e importe o módulo nx
para gerir os recursos Linux DSC.
4 No seu computador local, crie um ficheiro chamado httpd.ps1 e introduza
o seguinte código:
configuration httpd {
Import-DSCResource -Module nx
Node localhost {
nxPackage httpd {
Name = "httpd"
Ensure = "Present"
PackageManager = "yum"
}
nxService httpd {
Name = "httpd"
State = "running"
Enabled = $true
Controller = "systemd"
}
}
}
5 Adicione uma configuração DSC à conta da Automation do Azure, carregue

o ficheiro httpd.ps1 e compile a configuração.
6 Adicione um nó DSC à sua conta Azure Automation, selecione a sua VM CentOS
e, em seguida, escolha o nome de configuração do seu nó httpd.localhost.
Mais uma vez, demora um minuto ou dois até que a VM aplique a configuração
pretendida. Pode ver a lista de VMs ligadas e o seu estado de conformidade na
janela de nós DSC. A VM informa a Conformidade quando o LCM tiver aceite e
aplicado o ficheiro MOF, mas os comandos para instalar e configurar os pacotes
httpd necessários dentro da VM podem demorar mais um minuto ou dois.
7 Selecione a sua VM CentOS no portal Azure, obtenha o seu endereço de IP
público e introduza o endereço de IP da sua VM num browser para visualizar o
servidor web instalado pelo DSC. Se o site não for carregado, aguarde um ou dois
minutos até que o processo de instalação fique concluído e, em seguida, atualize
a página.
Se quiser realmente experimentar o admirável mundo novo da Microsoft e Linux, ins-
tale o PowerShell na sua VM Linux. Conclua os breves passos de configuração em
http://mng.bz/VgyP para entender como os scripts do PowerShell multiplataforma
podem ser!
19
Containers do Azure
Containers, Docker e Kubernetes ganharam um enorme número de adeptos em

poucos anos. Da mesma forma que a virtualização de servidores começou a mudar a
forma como os departamentos de TI executavam os seus datacenters em meados da
década de 2000, as modernas ferramentas e orquestradores de containers estão,
agora, a reorganizar a maneira como criamos e executamos as aplicações. Não há
nada que ligue de forma inerente o crescimento de containers com o cloud compu-
ting, mas, quando combinados, fornecem uma ótima maneira de desenvolver apli-
cações com uma abordagem nativa de cloud. Foram escritos livros inteiros sobre
Docker e Kubernetes, mas vamos ler uma introdução rápida e ver como pode exe-
cutar containers no Azure rapidamente. Um conjunto poderoso de serviços do
Azure é dedicado a containers, que se alinham mais à abordagem PaaS. Pode con-
centrar-se em como criar e executar as suas aplicações, em vez de como gerir a
infraestrutura de container, a orquestração e os componentes de cluster.
Neste capítulo, iremos examinar o que são containers, como o Docker foi envol-
vido e o que o Kubernetes pode fazer por si. Para saber como executar uma única
instância de container ou várias instâncias de container rapidamente num cluster,
iremos explorar o Azure Container Instances (ACI) e o Azure Kubernetes
Service (AKS).
19.1 O que são containers?

Houve uma enorme onda de interesse na adesão aos containers em anos recentes e
ficaria impressionado se os utilizadores não tivessem ouvido falar de uma empresa
que liderou este êxito: a Docker. Mas o que é exatamente um container e o que a
Docker tem a ver com isso?
Primeiro, vamos analisar um host de virtualização tradicional que executa VMs.
A figura 19.1 é como o diagrama que analisámos no capítulo 1, onde cada VM tem o
seu próprio hardware virtual e sistema operativo convidado.
284
O que são containers? 285
Host de virtualização
Figura 19.1 Com uma infraestrutura de
Hipervisor VM tradicional, o hipervisor em cada host de
virtualização fornece uma camada de isolamento,
VM 1 VM 2 fornecendo a cada VM o seu próprio conjunto de
vCPU vRAM vNIC vCPU vRAM vNIC dispositivos de hardware virtual, como uma CPU
virtual, RAM virtual e NICs virtuais. A VM instala
SO Linux guest SO Windows guest um SO convidado, como o Ubuntu Linux ou o
Windows Server, que pode utilizar este hardware
Bibliotecas core + binários Bibliotecas core + binários virtual. Finalmente, instala a sua aplicação e
O código da aplicação O código da aplicação quaisquer bibliotecas necessárias. Este nível
de isolamento torna as VMs muito seguras, mas
adiciona uma camada de sobrecarga em termos
de recursos de computação, armazenamento
e tempos de arranque.
Um container remove o har-

dware virtual e o sistema opera- Host de container
tivo convidado. Tudo o que Runtime de container (como Docker)
está incluído num container Container 1 Container 2
são as aplicações e bibliotecas
Bibliotecas core + binários Bibliotecas core + binários
core necessárias para executar
a sua aplicação, conforme mos- O código da aplicação O código da aplicação
Muitas VMs podem ser exe- Figura 19.2 Um container contém apenas as bibliotecas
cutadas num único hipervisor, core, os binários e o código da aplicação necessários para
cada uma delas com o seu pró- executar uma aplicação. O container é leve e portátil, uma
prio sistema operativo virtual vez que remove o sistema operativo convidado e a camada de
convidado, hardware virtual e hardware virtual, o que também reduz o tamanho do container
no disco e os tempos de arranque.
pilha de aplicações. O hipervi-
sor gere pedidos do hardware
virtual de cada VM, agenda a
alocação e a partilha desses
recursos físicos de hardware e
reforça a segurança e o isola- Host de virtualização
mento de cada VM. O trabalho
CPU Física RAM Física NIC Física
do hipervisor é mostrado na
figura 19.3.
Hipervisor
Figura 19.3 Num host de VM

tradicional, o hipervisor fornece o
agendamento de pedidos do
hardware virtual em cada VM vCPU vRAM vNIC vCPU vRAM vNIC
para o hardware físico
subjacente e a infraestrutura. VM 1 VM 2
Normalmente, o hipervisor não tem
consciência de quais instruções SO Linux guest SO Windows guest
específicas o sistema operativo
convidado está a planear no tempo de
CPU físico, apenas o tempo de CPU
é necessário.
286 Capítulo 19 Containers do Azure
Também podem ser executados vários containers num único host. O host do contai-
ner recebe as várias chamadas do sistema de cada container e, em seguida, agenda a
alocação e distribuição desses pedidos num kernel de base partilhado, sistema opera-
tivo e recursos de hardware. Os containers fornecem um isolamento lógico dos proces-
sos de aplicações. O trabalho do runtime do container é mostrado na figura 19.4.
Host de container
SO convidado Kernel convidado
Runtime de container (como Docker)

Figura 19.4 Os containers têm
Pedidos de kernel e SO um sistema operativo convidado e
convidados partilhados um kernel em comum. O runtime do
container processa os pedidos dos
Container 1 Container 2 containers ao kernel partilhado.
Bibliotecas core + binários Bibliotecas core + binários Cada container é executado num
espaço de utilizador isolado
O código da aplicação O código da aplicação e algumas funcionalidades de
segurança adicionais protegem
os containers uns dos outros.
Geralmente, os containers são muito mais leves do que as VMs. Os containers podem
iniciar-se mais rapidamente do que as VMs (regra geral em segundos, em vez de minu-
tos). Geralmente, o tamanho de uma imagem de container é de apenas algumas deze-
nas ou centenas de MB, em comparação com muitas dezenas de GB das VMs. Ainda há
limites e controlos de segurança em vigor, mas é importante lembrar que cada contai-
ner partilha tecnicamente o mesmo kernel de outros containers no mesmo host.
Experimente agora
Leva alguns minutos a criar um cluster do AKS para utilização nos próximos exercícios.
Por isso, conclua os passos a seguir e continue a ler o capítulo.
2 Crie um grupo de recursos. Forneça um nome, como azuremolchapter19, e
uma localização, como eastus. A disponibilidade de região do AKS pode variar,
por isso escolha uma região importante, como eastus ou westeurope. (Para
obter uma lista atualizada da disponibilidade das regiões, ver https://azure.
microsoft.com/regions/services.)
A abordagem de microsserviços para aplicações 287
3 Para criar um cluster Kubernetes, especifique a --node count como 2 e utilize os

conjuntos de dimensionamento e as zonas de disponibilidade (que aprendeu em
capítulos anteriores):
az aks create \
--name azuremol \
--node-count 2 \
--vm-set-type VirtualMachineScaleSets \
--zones 1 2 3 \
--no-wait
O parâmetro final --no-wait devolve o controlo ao Cloud Shell enquanto o restante

cluster é criado. Continue a ler enquanto o cluster é implementado.
O Docker juntou-se ao grupo de containers com um conjunto de ferramentas e for-
matos padrão que definiam como criar e executar um container. O Docker baseia-se
em funcionalidades existentes ao nível do kernel do Linux e do Windows para fornecer
uma experiência de container consistente e portátil em todas as plataformas. Um pro-
gramador pode criar um container Docker no portátil com sistema operativo macOS,
validar e testar a aplicação e, em seguida, executar exatamente o mesmo container
Docker, sem alteração, num cluster de servidor mais tradicional baseado em Linux ou
Windows on-premises, ou no Azure. Todos os binários, bibliotecas e ficheiros de confi-
guração necessários da aplicação são agrupados como parte do container, portanto, o
sistema operativo do host subjacente não se torna um fator ou restrição de design.
A importância do Docker não deve ser omitida aqui. Geralmente, os termos container
e Docker são utilizados de forma alternada, embora isso não seja tecnicamente exato. O
Docker é um conjunto de ferramentas que ajuda os programadores a criarem e execu-
tarem containers de maneira consistente, fiável e portátil. A facilidade de utilizar estas
ferramentas levou a uma adesão rápida e fez com que a tecnologia de containers subja-
cente, que já existia de outras formas há mais de uma década, se tornasse na tendência
do momento. Os programadores aderiram aos containers e à plataforma Docker, e os
departamentos de TI tiveram que se esforçar para recuperar o atraso desde então.
A Docker participa na Open Container Initiative. O formato e as especifica-
ções definidos pela Docker para estabelecer a forma como um container deve ser empa-
cotado e executado eram alguns dos princípios básicos deste projeto. O trabalho da
Docker continuou e foi desenvolvido por outras pessoas. Grandes contribuintes na área
de containers incluem a IBM e a Red Hat, que contribuíram com alguns dos projetos e
códigos core que alimentam as atuais plataformas de containers. A Open Container
Initiative e o formato de design para empacotamentos e runtimes de containers são
importantes, porque permitem que cada fornecedor coloque as suas próprias ferra-
mentas sobre os formatos comuns, permitindo que mova o container subjacente entre
as plataformas e tenha a mesma experiência core.
19.2 A abordagem de microsserviços para aplicações

Se os containers oferecerem um conceito de isolamento semelhante às VMs, poderá exe-
cutar o mesmo tipo de workloads numa VM? Bem, a resposta é sim e não. Só porque
pode fazer algo, isso não significa necessariamente que o deveria fazer! Os containers
podem ser utilizados para executar qualquer workload com o qual se sinta confortável,
existindo benefícios em termos de funcionalidades de portabilidade e orquestração, os
quais examinaremos na secção 19.4. Para maximizar os benefícios dos containers e se
preparar para o sucesso, aproveite a oportunidade para adotar um modelo mental ligei-
ramente diferente quando começar a trabalhar com containers. A figura 19.5 compara o
modelo de aplicação tradicional com uma abordagem de microsserviços.
Microsserviços
Aplicação monolítica
Processamento Processamento Processamento Processamento

de pedidos de pagamentos de pedidos de pagamentos
Gestão de contas Informações Gestão de contas Informações

sobre o stock sobre o stock
Figura 19.5 Numa aplicação monolítica tradicional, toda a aplicação é executada como uma única
aplicação. A aplicação pode ter vários componentes, mas esta é executada a partir de uma única
instalação e é corrigida e atualizada como uma única instância. Com os microsserviços, cada
componente é dividido pelo seu próprio serviço de aplicação e unidade de execução. Cada
componente pode ser atualizado, corrigido e dimensionado independentemente dos outros.
Uma VM padrão inclui uma instalação completa do sistema operativo convidado,

como o Ubuntu ou o Windows Server. Esta instalação básica do sistema operativo inclui
centenas de componentes, bibliotecas e ferramentas. Depois, instala mais bibliotecas e
aplicações, como o servidor Web NGINX ou o Microsoft SQL Server. Finalmente,
implementa o código da aplicação. Geralmente, esta VM executa uma grande parte, se
não toda, da aplicação. É uma grande instalação de aplicação e instância em execução.
Para melhorar o desempenho, pode adicionar mais memória ou CPU à VM (dimensio-
namento vertical, discutido nos capítulos anteriores) ou aumentar o número de ins-
tâncias que executam a aplicação (dimensionamento horizontal, como em conjuntos
de dimensionamento). A criação de várias instâncias de aplicações apenas funciona se
a aplicação suportar clusters e, geralmente, isso envolve algum tipo de armazenamento
partilhado para permitir um estado consistente nas instâncias da aplicação. Esta forma
tradicional de implementação é denominada aplicação monolítica.
Uma abordagem diferente de como cria, desenvolve e executa aplicações é dividir as
coisas em componentes menores e reduzidos. Esta é uma abordagem de microsserviços
para desenvolvimento e implementação de aplicações. Cada microsserviço é responsá-
vel por uma pequena parte do ambiente de aplicação mais amplo. Os microsserviços
podem crescer, dimensionar e ser atualizados independentemente do restante do
ambiente de aplicação.
Embora este modelo possa oferecer desafios no início, enquanto as equipas de
desenvolvimento e de TI aprendem a adotar uma maneira diferente de criar e imple-
mentar aplicações, os containers são excelentes para a abordagem de microsserviço. Os
programadores têm o poder de implementar atualizações menores e mais incrementais
num ritmo mais rápido do que na abordagem monolítica do desenvolvimento de apli-
cações. Os microsserviços e containers também são ótimos para workflows de integra-
ção contínua e entrega contínua (CI/CD), que torna mais fácil de criar, testar, preparar
e implementar atualizações. Os seus clientes recebem novas funcionalidades ou corre-
ções de erros mais rapidamente do que de outra forma e, idealmente, que a sua empresa
cresça como resultado disso.
Azure Container Instances 289
Microsserviços com o Azure Service Fabric

Este capítulo concentra-se, principalmente, em containers e orquestração do Docker
com Kubernetes, mas há um serviço similar do Azure que direciona o desenvolvimento
de aplicações para um modelo de microsserviços. O Azure Service Fabric existe há vários
anos e era, historicamente, uma abordagem centrada no Windows para criar aplicações,
nas quais cada componente era dividido no seu próprio microsserviço. O Service Fabric
controla onde cada componente de microsserviço é executado num cluster, permite que
os serviços descubram e comuniquem uns com os outros e lida com a redundância
e o dimensionamento.
Muitos dos grandes serviços do Azure utilizam o Service Fabric em segundo plano, incluindo
o Cosmos DB. Isso deve dar-lhe uma ideia de como o Service Fabric pode ser capaz e pode-
roso! O próprio Service Fabric é executado sobre conjuntos de dimensionamento de virtual
machines. Já sabe agora algo sobre os conjuntos de dimensionamento, certo?
A plataforma do Service Fabric está desenvolvida e, agora, pode gerir o Windows
e o Linux como o sistema operativo convidado, para que possa criar a sua aplicação com
qualquer linguagem de programação com a qual esteja familiarizado. Veja outro exem-
plo de opção no Azure: tem a flexibilidade de escolher como pretende gerir e orquestrar
as suas aplicações de container. O Service Fabric e o AKS têm excelentes benefícios
e casos práticos.
Como um bom ponto de partida, se atualmente desenvolve ou gostaria de desenvolver
microsserviços fora dos containers, o Service Fabric é uma ótima escolha. As aplicações
criadas em torno do modelo de ator também são uma ótima escolha, uma vez que o Ser-
vice Fabric foi originalmente criado com este modelo de programação em mente. O Ser-
vice Fabric fornece uma abordagem unificada para lidar com aplicações de
microsserviços mais tradicionais e aplicações baseadas em containers. Se optar pela
adoção de containers para outros workloads, poderá utilizar as mesmas ferramentas
e interface de gestão do Service Fabric para gerir todos os ambientes de aplicação.
Para uma abordagem de aplicação mais focada em containers desde o início, o AKS
pode ser uma melhor opção, com o crescimento e a adesão do Kubernetes proporcio-
nando uma experiência de container de primeira classe. Pode executar com containers
Linux e Windows em AKS.
19.3 Azure Container Instances

Agora que entende um pouco mais sobre o que são containers e como pode utilizá-los,
vamos aprofundar e criar uma instância básica da pizzaria. Este exemplo é o mesmo
utilizado nos capítulos anteriores, onde criou uma VM básica que executava o seu site
ou implementou a aplicação em aplicações Web. Nos dois casos, precisava de criar a
VM ou a aplicação Web, ligar-se à mesma e, em seguida, implementar uma página Web
básica. O poder dos containers pode tornar a sua vida muito mais fácil? Com certeza!
Um serviço simples chamado Azure Container Instances (ACI) permite criar e exe-
cutar containers em questão de segundos. Não há recursos de rede iniciais para criar e
configurar. Para além disso, paga por cada instância de container ao segundo. Se nunca
tiver utilizado containers e não pretende instalar nada localmente no seu computador,
a ACI é uma ótima maneira de experimentar a tecnologia.
Para ver como pode executar rapidamente a sua pizzaria, vamos criar uma instância
de container. É necessário apenas um comando para executar uma instância de contai-
ner, mas a figura 19.6 mostra como reúne muitos componentes para que isso ocorra em
segundo plano. Analisaremos os componentes de um Dockerfile e Docker Hub depois
de a instância de container estar em funcionamento.
Imagem base
1. NGINX:1.17.5
Dockerfile
Azure Container
FROM nginx:1.17.5 Docker Hub Instance
2. Mapear porta externa 80 Implementar
EXPOSE 80:80 iainfoulds:
-> porta de container 80 azuremol
azuremol
COPY index.html
/usr/share/nginx/html 3.
index.html
/usr/share/nginx/html
Imagem de container
local criada a parr do
Dockerfile emida via
push para o repositório
azuremol público do Docker Hub
Figura 19.6 Foi utilizado um Dockerfile para criar uma imagem completa do container: o azuremol. Esta
imagem foi emitida via push para um registo público online chamado Docker Hub. Agora, pode criar uma
instância de container utilizando esta imagem pública pré-criada do Docker Hub, que fornece uma
imagem de aplicação pronta para execução.
Experimente agora
Para criar uma instância de container do Azure que execute um site básico, conclua os
passos a seguir:
1 Abra o portal Azure e escolha o ícone do Cloud Shell na parte

superior do menu.
2 Crie uma instância de container e especifique que pretende ter um ende-
reço de IP público e abra a porta 80:
az container create \
--name azuremol \
--image iainfoulds/azuremol \
--ip-address public \
--ports 80
Este exercício usa uma imagem de exemplo que criei para si, a qual examinare-
mos um pouco melhor quando o container estiver a funcionar.
Azure Container Instances 291
3 Para ver o que foi criado, olhe para a saída do comando para criar o con-tainer.
Na secção Eventos, pode visualizar como a imagem é obtida (por download) a
partir do Docker Hub, um container será criado e iniciado.
Algumas reservas de CPU e memória também são atribuídas, as quais podem
ser ajustadas, se necessário. Um endereço de IP público é mostrado juntamente
com algumas informações sobre o container, como o estado de aprovisiona-
mento, o tipo de sistema operativo e a política de reinicialização.
4 Para abrir o site básico que é executado no container, pode consultar apenas
o endereço IP público atribuído:
az container show \
--name azuremol \
--query ipAddress.ip \
--output tsv
5 Abra o endereço de IP público da sua instância de container num browser. A piz-

zaria básica deverá ser apresentada como mostra a figura 19.7.
Figura 19.7 Quando criar uma instância de container, o site da pizzaria será executado sem
qualquer configuração adicional. Toda a configuração e o conteúdo estão incluídos na imagem
do container. Este exercício rápido destaca a portabilidade e o poder dos containers. Quando
a imagem do container estiver preparada, a sua aplicação fica a funcionar assim que for
implementada uma nova instância de container.
Vamos examinar a imagem do container. Não quero abordar os detalhes do Docker e

de como criar imagens de container, mas é importante entender de onde essa imagem
veio e como é executada no site sem nenhuma configuração adicional.
A imagem é criada a partir de uma definição de configuração chamada Dockerfile.
Num Dockerfile, define qual é a plataforma base, a configuração que pretende aplicar
e os comandos a serem executados ou os ficheiros a serem copiados. Os Dockerfiles
podem ser, e geralmente são, mais complexos do que o exemplo a seguir, que foi utili-
zado para criar o exemplo de container azuremol:
FROM nginx:1.17.5
EXPOSE 80:80
COPY index.html /usr/share/nginx/html
Se este Dockerfile foi utilizado para criar uma imagem de container do Docker, o NGINX
foi utilizado como a imagem de origem e a página Web de exemplo foi copiada para a
mesma. Em seguida, este container foi emitido via push para o Docker Hub, um reposi-
tório público online que o Docker fornece para partilhar e implementar containers.
Para implementar a instância do container, forneceu iainfoulds/azuremol como a ima-
gem do container a ser utilizada. O Azure procurou no Docker Hub e encontrou um
repositório chamado iainfoulds e, dentro dele, uma imagem chamada azuremol.
Vamos examinar cada linha do Dockerfile:
¡ FROM nginx:1.17.5 - Nos capítulos anteriores, criou uma VM básica, ligou-
-se à mesma com SSH e, em seguida, instalou manualmente o servidor Web NGINX.
No exemplo do Dockerfile, tudo isso é realizado numa linha. Esta linha informa que
o container deve ser baseado numa imagem de container existente pré-instalada com
o NGINX. O 1.17.5 é a versão da imagem pública do container NGINX para utili-
zar. Trata-se da mais recente no momento da escrita. É uma boa prática incluir um
número de versão específico. Se não incluir um número de versão, será sempre utili-
zada a versão mais recente. Isto parece resultar na teoria, mas as aplicações de micros-
serviços podem escalar para um grande número de containers ativos. Por isso, para
garantir que tem um ambiente consistente, tem de controlar
o número da versão exata de cada componente que estiver em utilização.
¡ EXPOSE 80:80—Para permitir o acesso à VM nos capítulos anteriores, criou
uma regra do NSG que permitia a porta 80. No Dockerfile, esta linha informa o
container para abrir a porta 80 e mapeá-la para a porta interna 80. Quando criou
a sua instância de container com az container create, também especificou que
a plataforma do Azure deve permitir tráfego com --ports 80. Trata-se de toda a
rede virtual em que precisa de pensar!
¡ COPY index.html /usr/share/nginx/html—A parte final é obter a sua aplicação
no container. Nos capítulos anteriores, utilizou o Git para obter a página Web da
pizzaria de exemplo e emiti-la via push para a sua aplicação Web. Com o Docker-
file, faz COPY do ficheiro index.html para o diretório local /usr/share/nginx/
html no container. Pronto!
Para os seus próprios cenários, pode definir um Dockerfile que utiliza uma imagem base
diferente, como Node.js ou Python. Depois, instala quaisquer bibliotecas ou pacotes de
suporte adicionais necessários, obtém o código da aplicação no controlo de origem,
como o GitHub, e implementa a sua aplicação. Este Dockerfile será utilizado para criar
imagens de container que são armazenadas num registo de container privado e não num
repositório público do Docker Hub, como aquele visto no exemplo.
Azure Kubernetes Service 293
Azure Container Registry

Pode pensar que o Docker Hub é uma boa opção. Será que o Azure tem também
algo tão maravilhoso? Sim! Infelizmente, por ser necessário criar um Dockerfile e cons-
truir uma imagem de container, este não é um exercício de dois minutos, sendo que há
muito a abordar neste capítulo. Pode facilmente integrar o Azure Container Registry
(ACR) e o AKS, portanto os dois serviços trabalham bem em conjunto. Pode criar as suas
próprias imagens a partir de um Dockerfile no Cloud Shell, e encorajo-o a explorar isso
se tiver tempo. No entanto, o Azure Container Registry (ACR) é a opção que escolho para
armazenar as minhas imagens de container, por alguns motivos:
¡ É um registo privado para as suas imagens de container. Portanto, não precisa de
se preocupar com o acesso potencial indesejado aos seus ficheiros e configurações
da aplicação. Pode aplicar os mesmos mecanismos de RBAC que abordámos no
capítulo 6. O RBAC ajuda a limitar e auditar quem tem acesso às suas imagens.
¡ Armazenar as suas imagens de container num registo no Azure significa que as
suas imagens estão nos mesmos datacenters que a infraestrutura utilizada para
executar as suas instâncias de container ou clusters (que veremos na secção
19.4.1). Embora as imagens de container devam ser relativamente pequenas
(geralmente com apenas dezenas de MB), as mesmas podem aumentar se conti-
nuar a fazer download dessas imagens a partir de um registo remoto.
O ACR também oferece opções de replicação e redundância incorporadas que pode utili-
zar para colocar os seus containers perto de onde os implementa e executá-los para que
os utilizadores tenham acesso. Esta localidade de região é semelhante à maneira como
utilizou a replicação global do Cosmos DB no capítulo 10 para fazer com que esses milis-
segundos fossem contabilizados e fornecer aos seus clientes o tempo de acesso mais
rápido possível às suas aplicações.
Se tudo isso parecer interessante, veja a página de introdução do ACR a funcionar rapi-
damente com o seu próprio repositório privado em alguns minutos: http://mng.bz/04rj.
19.4 Azure Kubernetes Service

A execução de uma única instância de container é ótima, mas isso não significa muita
redundância ou capacidade de dimensionar. Lembra-se de como passámos capítulos
inteiros no início do livro a falar sobre como executar várias instâncias da aplicação,
equilibrar a carga e dimensioná-las automaticamente? Não seria ótimo fazer o mesmo
com os containers? E é nesse caso que precisa de um orquestrador de containers.
Como o nome indica, um orquestrador de containers gere as suas instâncias de contai-
ner, monitoriza o estado de funcionamento e pode dimensionar conforme necessário.
Os orquestradores podem, e geralmente fazem-no, lidar com muito mais do que isso,
mas a um nível alto, um foco principal é processar todas as partes móveis envolvidas na
execução de uma aplicação baseada em containers altamente disponível e dimensioná-
vel. Existem alguns orquestradores de containers, como o Docker Swarm e o Distribu-
ted Cloud Operating System (DC/OS), mas houve um que se destacou em relação aos
demais para se tornar a escolha principal do orquestrador, o Kubernetes.
O Kubernetes começou como um projeto open source liderado e patrocinado pelo
Google que nasceu das ferramentas internas de orquestração de containers da empresa.
Amplamente aceite pela comunidade open source, o Kubernetes é um dos maiores e mais
crescentes projetos open source do GitHub. Muitas grandes empresas de tecnologia,
incluindo a Red Hat, a IBM e a Microsoft, contribuem para o projeto do Kubernetes core.
Nesta secção, iremos utilizar a mesma aplicação Web de exemplo do exercício ante-
rior com a ACI para executar uma implementação redundante e dimensionável no
Kubernetes. Irá terminar com alguns componentes, como mostra a figura 19.8.
Azure Kubernetes Implementação

Services (AKS) de Kubernetes
Docker Hub Cluster de Kubernetes Serviço Kubernetes

Executar
iainfoulds: Balanceador de
Nó 1
azuremol carga Porta TCP 80
Nó 2
Pod 1
Pod 2
Figura 19.8 O seu container de exemplo do Docker Hub é executado num cluster de
Kubernetes de dois nós que cria no AKS. A implementação do Kubernetes contém dois
pods lógicos, um em cada nó do cluster, com uma instância de container em execução
dentro de cada pod. Depois, expõe um balanceador de carga público para permitir que
a sua aplicação Web seja vista online.
19.4.1 Criar um cluster com o Azure Kubernetes Services

No capítulo 9, iremos examinar como os conjuntos de dimensionamento de virtual
machines reduzem a complexidade de implementar e configurar a infraestrutura sub-
jacente. Informa quantas instâncias de VM pretende num conjunto de dimensiona-
mento e o restante da rede, armazenamento e configuração será implementado para
si. O AKS funciona da mesma maneira para oferecer um cluster de Kubernetes resi-
liente e dimensionável, com gestão controlada pela plataforma do Azure. Os conjun-
tos de dimensionamento podem ser utilizados para as VMs subjacentes que são
executadas no cluster do AKS, sendo que essas VMs podem ser distribuídas pelas Zonas
de Disponibilidade. Os balanceadores de carga do Azure, também com redundância
entre zonas, são usados. Basicamente, o AKS reúne vários dos componentes da infraes-
trutura e as melhores práticas que aprendeu até agora neste livro!
Experimente agora
Para ver as informações sobre o seu cluster do AKS, conclua os passos a seguir:
2 No início do capítulo, criou um cluster de Kubernetes. O processo levou alguns
minutos, mas espero que esteja pronto agora! Observe o estado do cluster da
seguinte forma:
az aks show \
--name azuremol
O provisioningState junto ao final deve reportar Succeeded.

3 Se o cluster estiver pronto, obtenha um ficheiro de credenciais que permita utili-

zar as ferramentas da linha de comandos do Kubernetes para autenticar e gerir
recursos:
az aks get-credentials \
--name azuremol
Isso é tudo o que é preciso para colocar o Kubernetes em funcionamento no Azure!

Pode estar a perguntar a si próprio: "Não é possível criar o meu próprio cluster com
VMs ou conjuntos de dimensionamento e instalar manualmente os mesmos compo-
nentes do Docker e do Kubernetes?" Claro que pode. O paralelo é a abordagem IaaS e
PaaS de VMs versus aplicações Web. A abordagem da aplicação Web oferece muitos
benefícios: o utilizador preocupa-se apenas com as opções de configuração de alto
nível e, em seguida, carrega o código da aplicação. Um cluster gerido do Kubernetes,
oferecido pelo AKS, reduz o nível de complexidade e gestão. O foco do utilizador con-
verte-se nas suas aplicações e na experiência dos seus clientes.
Da mesma forma que pode escolher VMs em aplicações Web, pode optar por imple-
mentar o seu próprio cluster de Kubernetes em vez de utilizar o AKS. Isso é bom, pois as
duas abordagens acabam por utilizar os mesmos componentes de serviços do Azure.
VMs, conjuntos de escalas dimensionamento, balanceadores de carga e NSGs são tópi-
cos que aprendeu nos capítulos anteriores, e todos ainda fazem parte do tópico de clus-
ters do AKS, embora estejam separados. Do ponto de vista de planeamento e resolução
de problemas, deve ter as competências necessárias para entender o que está a aconte-
cer em segundo plano para fazer com que as ofertas geridas do Kubernetes funcionem.
Informações como o seu nível de conforto e quanto tempo pretende gastar a gerir a
infraestrutura irão ajudar a guiar o seu processo de tomada de decisões à medida que
cria uma nova aplicação em torno de containers no Azure.
19.4.2 Executar um site básico no Kubernetes

Criou um cluster de Kubernetes na secção 19.4.1, mas não há nenhuma aplicação em
execução. Vamos mudar isso! Precisa de criar a implementação do Kubernetes que viu
anteriormente na figura 19.8. Veja a figura 19.9.
Azure Kubernetes Implementação

Services (AKS) de Kubernetes
Dockerhub Cluster de Kubernetes Serviço Kubernetes

Executar
iainfoulds: Balanceador de
Nó 1
azuremol carga Porta TCP 80
Nó 2
Pod 1
Pod 2
Figura 19.9 Com o cluster de Kubernetes criado no AKS, agora pode criar uma implementação do
Kubernetes e executar a aplicação. O seu container é executado nos dois nós, com um pod lógico em
cada nó; precisa de criar um serviço do Kubernetes que exponha um balanceador de carga público para
encaminhar o tráfego para a sua aplicação.
Experimente agora
Para implementar uma aplicação no seu cluster de Kubernetes, conclua
os passos a seguir:
1 Interage com um cluster de Kubernetes, utilizando um utilitário da linha de

comandos chamado kubectl. Utilize a mesma imagem do container iainfoulds/
azuremol do Docker Hub que executou como uma instância de container:
kubectl run azuremol \
--image=docker.io/iainfoulds/azuremol:latest \
--port=80
Pode demorar um minuto a fazer download da imagem do container do Docker

Hub e iniciar a aplicação no Kubernetes. A aplicação é executada num pod: uma
construção lógica no Kubernetes que aloja cada container.
2 Os pods podem conter componentes auxiliares adicionais, mas, por enquanto,
monitorizam o estado do seu container observando o pod:
kubectl get pods --watch
Mesmo quando o estado dos relatórios do pod for Em execução, não poderá aceder à
sua aplicação. A instância do container que criou anteriormente poderia encaminhar
o tráfego sobre um endereço IP público diretamente para essa instância, mas o que
acha que é necessário para um cluster de Kubernetes encaminhar o tráfego para os
containers? Se disse: um balanceador de carga, parabéns! No momento, tem apenas
um pod: uma única instância de container. Irá aumentar na horizontal o número de
pods no laboratório de fim de capítulo e, para que isso funcione, precisa de uma
maneira de encaminhar o tráfego para várias instâncias. Por isso, vamos dizer ao
Kubernetes para utilizar um balanceador de carga.
Esse é o ponto onde a integração entre o Kubernetes e o Azure se torna interessante.
Quando informa o Kubernetes que pretende criar um balanceador de carga para os
seus containers, em segundo plano, o Kubernetes entra novamente na plataforma do
Azure e cria um balanceador de carga do Azure. Este balanceador de carga do Azure é
como o que aprendeu no capítulo 8. Há conjuntos IP de front-end e de back-end e
regras de balanceamento de carga, sendo possível configurar sondagens do estado de
funcionamento. À medida que a sua implementação do Kubernetes é aumentada ou
reduzida verticalmente, o balanceador de carga é atualizado automaticamente, con-
forme necessário.
Experimente agora
Para expor a sua aplicação à internet, conclua os seguintes passos:
1 Diga ao Kubernetes que pretende usar um balanceador de carga e adicione uma

regra para distribuirtráfego na porta 80:
kubectl expose deployment/azuremol \
--type=”LoadBalancer” \
--port 80
2 Como anteriormente, observe o estado da sua implementação de serviço:

kubectl get service azuremol --watch
Quando o endereço de IP público estiver atribuído, isso significa que o balancea-

dor de carga do Azure concluiu a implementação e o cluster, bem como os nós do
Kubernetes, estão ligados.
3 Abra o endereço IP público do seu serviço num browser para ver a sua aplicação
Web em execução.
Muitas vezes, as implementações de aplicações no Kubernetes são muito mais envolvi-
das do que este exemplo básico. Normalmente define um manifesto de serviço, seme-
lhante a um modelo do Resource Manager, que define todas as características da sua
aplicação. Estas propriedades podem incluir o número de instâncias da aplicação a ser
executada, qualquer armazenamento a ser anexado, métodos de balanceamento de
carga e portas de rede a serem utilizadas e assim por diante. No mundo real, isto nem
se executa manualmente. Um sistema CI/CD, como o Azure DevOps ou Jenkins, auto-
matiza as implementações de aplicações e serviços diretamente dentro do cluster do
AKS. O que é ótimo sobre o AKS é que não necessita de se preocupar com a instalação
e a configuração do Kubernetes. Assim como com outros serviços de PaaS, tais como
aplicações Web e o Cosmos DB, traz as suas aplicações e permite que a plataforma do
Azure trate da infraestrutura e da redundância subjacentes.
Mantenha-o limpo e organizado

Lembre-se de limpar e eliminar os seus grupos de recursos, para que não acabe por con-
sumir muitos dos seus créditos gratuitos do Azure. À medida que começa a explorar con-
tainers, torna-se ainda mais importante prestar atenção aos recursos do Azure que
deixa ativados. Uma única aplicação Web não custa muito, mas um cluster do AKS de
cinco nós e algumas instâncias do container com imagens do Azure Container Registry
georreplicadas certamente que custa algum dinheiro!
As instâncias da ACI são cobradas por segundo e o custo aumenta rapidamente se
forem executadas continuamente durante dias ou semanas. Um cluster do AKS executa
uma VM para cada nó, portanto, se aumentar verticalmente e executar muitas VMs no
seu cluster, estará a pagar por uma VM para cada nó.
Não há qualquer cobrança pelo número de containers que cada um desses nós do AKS
executa, mas, como ocorre com qualquer VM, um nó do AKS fica caro quando deixado
em execução. O que é ótimo sobre o Kubernetes é que pode exportar as suas configura-
ções de serviço (a definição para os seus pods, balanceadores de carga, escalonamento
automático e assim por diante) para implementá-las em outro lugar. À medida que cria e
testa as suas aplicações, não precisa de deixar um cluster do AKS em execução.
Pode implementar um cluster conforme necessário e implementar o seu serviço a partir
de uma configuração anterior.
Os clusters do AKS podem aumentar ou diminuir verticalmente, tal como verá no exercício
de laboratório no final do capítulo. Também pode configurar o dimensionamento automá-
tico, que faz este dimensionamento para si, em função da carga. É o mesmo tipo de dimen-
sionamento automático que observámos no capítulo 9 para conjuntos de dimensionamento
e aplicações Web. Está a começar a entender como tudo funciona no Azure?
Este capítulo foi uma introdução rápida aos containers e Kubernetes. Por isso, não se preo-
cupe se se sentir um pouco sobrecarregado agora! A Manning tem vários
livroos formidáveis, tais como Learn Docker in a Month of Lunches de Elton Stoneman
(https://livebook.manning.com/book/learn-docker-in-a-month-of-lunches), e Kubernetes in
(continuação)
Action, de Marko Luksa (https://livebook.manning.com/book/kubernetes-in-action),
que podem ajudá-lo a aprofundar ainda mais o Docker, o desenvolvimento de aplicações
de microsserviços e o Kubernetes. Consulte esses livros se este capítulo parecer interes-
sante e quiser explorar mais!
Os exemplos deste capítulo utilizaram VMs Linux para os nós de cluster do AKS e, em
seguida, executaram containers Linux para NGINX. Os containers são um pouco mais
difíceis se executar apenas containers Linux em nós Linux, por exemplo. Tal como
aprendeu no início do capítulo, os containers partilham o sistema operativo e kernel
convidados. Desta forma, não pode executar containers Windows num nó Linux. Em
geral, também não é possível executar containers Linux num nó Windows. Estão envol-
vidos alguns bons truques técnicos, mas, regra geral, o container e o SO do nó subja-
centes devem coincidir.
O que é ótimo no AKS é que pode executar os nós Linux e Windows, para que possa
executar os containers Linux e Windows! Precisa de prestar um pouco de atenção à
forma como estes diferentes containers são programados nos diferentes sistemas opera-
tivos do nó. Contudo, esta abordgem aalarga o leque de aplicações e serviços que pode
executar no AKS.
19.5 Laboratório: dimensionar as suas implementações

do Kubernetes
O exemplo básico neste capítulo criou um cluster de Kubernetes de dois nós e um
único pod que executa o site. Neste laboratório, explore como pode dimensionar o
cluster e o número de instâncias de container. Este exemplo é básico, mas quanto mais
nós tiver, mais instâncias de containers pode executar, o que é especialmente útil
quando precisa de mais aplicações para executar no seu cluster.
1 Pode ver quantos nós estão no seu cluster de Kubernetes com kubectl get
nodes. Aumente verticalmente o seu cluster para três nós:
az aks scale \
--name azuremol \
--node-count 3
Leva um ou dois minutos a aumentar verticalmente e a adicionar o novo nó.

2 Utilize kubectl novamente para ver o estado dos seus nós. Quando
dimensiona um nó, o Kubernetes não cria automaticamente quaisquer instân-
cias de containers adicionais para as suas aplicações. Por isso, não obtém imedia-
tamente qualquer benefício dos recursos de computação adicionais fornecidos
pelo novo nó.
Laboratório: dimensionar as suas implementações do Kubernetes 299
3 Veja a sua implementação atual com kubectl get deployment azuremol.

Apenas uma instância foi criada anteriormente. Esta aplicação de amostra não
está a tirar o máximo partido do novo nó que adicionou ao cluster no passo 1.
Dimensione até cinco instâncias ou réplicas:
kubectl scale deployment azuremol --replicas 5
4 Utilize kubectl novamente para examinar a implementação. Veja os pods, as ins-

tâncias de container em execução, com kubectl get pods. Em questão de
segundos, todas essas réplicas adicionais foram iniciadas e ligadas ao balancea-
dor de carga.
5 Utilize kubectl get pods -o wide para ver quais os nós que podem ser executa-
dos nos pods. Olhe para o último número no nome do nó, que indica qual o nó
no conjunto de dimensionamento que é usado. Os pods devem ser distribuídos
por todos os nós no seu cluster. À medida que outras aplicações aumentariam o
número de containers de forma semelhante, pode começar a maximizar a utili-
zação dos recursos computacionais em todos os nós do cluster.
20
O Azure e a Internet of Things
Para mim, uma das áreas mais interessantes da tecnologia nos anos mais recentes é a
Internet of Things (IoT). Não acredito que uma máquina de lavar louça ou um frig-
orífico precise ainda de estar ligado à Internet, mas existem preocupações de privaci-
dade válidas sobre uma TV ou um dispositivo de áudio que está permanentemente
ligado à Internet e a ouvir sempre o som da sua voz para emitir um comando. No
entanto, existem muitas aplicações práticas para dispositivos IoT. Pode ter relatórios de
equipamentos de indústria no seu estado de funcionamento, gerar alertas de
manutenção e permitir que os operadores entendam a sua eficiência em várias fábricas
em todo o mundo. Uma empresa de camionagem pode transmitir a telemetria dos
seus veículos sobre as cargas transportadas e os tempos médios de condução, além de
conseguir redirecionar os condutores, conforme necessário, de forma mais inteli-
gente. As transportadoras conseguem controlar cada container e ajudar os seus clien-
tes a gerir melhor a sua cadeia de fornecimento, sabendo onde estão os seus recursos.
No Azure, pode integrar dispositivos IoT com uma variedade de serviços. O Azure
Web Apps pode fornecer um front-end para os dados serem vistos, o Storage pode
ser utilizado para registar os dados transmitidos em fluxo a partir de dispositivos, e as
funcionalidades sem servidor, como o Azure Logic Apps (abordadas no próximo e
último capítulo), podem processar os dados recebidos.
Neste capítulo, vamos examinar o que é a IoT e como utilizar o Azure IoT Hub
para gerir e recolher dados a partir de dispositivos centralmente. Depois, verá como
utilizar uma aplicação Web do Azure para ver os dados em tempo real a partir de um
dispositivo IoT.
20.1 O que é a Internet of Things?

O interesse na Internet of Things (IoT) cresceu consideravelmente nos últimos
anos. Contudo, é um termo vago que pode ser aplicado a muitos cenários. A um
nível básico, a IoT é uma abordagem em que muitos dispositivos interligados, geral-
mente dispositivos eletrónicos pequenos e de baixo custo, se ligam aos sistemas e
aplicações centrais. Geralmente, os dispositivos ligados comunicam as informações
que recolhem a partir de sensores ou entradas associadas. Depois, estas informações
300
O que é a Internet of Things? 301
poderão ser processadas por um sistema central, talvez com IA ou ML (conforme dis-
cutido no capítulo 17), e realizar as ações apropriadas. A figura 20.1 mostra uma abor-
dagem de alto nível para a IoT.
As mensagens são enviadas

entre dispositivos IoT
e o sistema central.
Dispositivo IoT
Dispositivo IoT
Sistema Aplicações
e serviços
central Os dados recolhidos a partir dos
Dispositivo IoT dispositivos IoT são processados e as
instruções podem ser enviadas novamente
para os dispositivos ou outros sistemas.
Figura 20.1 As mensagens são enviadas entre muitos dispositivos IoT ligados e um sistema central.
As suas aplicações e serviços poderão processar os dados recebidos e enviar instruções do
dispositivo para realizar ações adicionais em resposta aos dados recolhidos.
Exemplos de IoT podem ser encontrados nos seguintes cenários:

¡ Parque de estacionamento —Um pequeno sensor acima de cada área de estaciona-
mento deteta se um veículo está estacionado. Uma luz acima de cada área poderá
iluminar-se na cor verde se a área de estacionamento estiver vazia ou na cor ver-
melha, se estiver ocupada. Os controladores que entram no parque de estaciona-
mento podem ver quadros informativos em tempo real em cada andar,
informando quantas vagas disponíveis existem. As luzes vermelha e verde acima
de cada área ajudam os condutores a determinar rapidamente a localização dos
pontos disponíveis enquanto dirigem por cada corredor.
¡ Fábrica—As máquinas numa fábrica podem reportar informações sobre a saída
operacional, os níveis de consumíveis e as necessidades de manutenção. Depois,
um sistema central poderá agendar um técnico de manutenção para reparar
proativamente o equipamento ou reabastecer os consumíveis, o que reduz
qualquer tempo de inatividade na linha de produção. Quando combinado com
IA e ML, as agendas de manutenção podem ser previstas e a quantidade correta
de produtos ou matérias-primas pode ser entregue pouco antes de serem
necessários na produção.
¡ Transporte—Os transportes públicos, como autocarros ou comboios, podem
incluir sensores de GPS que reportam a localização e a velocidade. Informações
sobre a emissão de bilhetes podem ser recolhidas para informar sobre quantas
pessoas estão a ser transportadas. Os painéis informativos dos passage-
iros numa estação de comboio ou terminal de autocarro podem fornecer infor-
mações em tempo real sobre quando cada veículo chegará. Quando esta
tecnologia é combinada com IA e ML, os passageiros em espera podem receber
sugestões de rotas alternativas com base nas condições de tráfego, atrasos ou
grande quantidade de passageiros.
Geralmente, a IoT funciona juntamente com outras aplicações e serviços. Os cenários de
fábrica e transporte podem utilizar IA e ML para melhor informar as decisões de pro-
dução ou dar sugestões aos passageiros. As aplicações Web podem utilizar as informações
recebidas a partir dos dispositivos IoT para fornecer acesso a partir de dispositivos móveis
302 Capítulo 20 O Azure e a Internet of Things
ou gerar alertas e notificações. Os dados recebidos a partir dos dispositivos IoT podem
ser registados num sistema de base de dados, como o Azure Cosmos DB, sendo depois
processados por aplicações de business intelligence e gerar relatórios.
Ideias com maiores perspetivas de futuro para IoT incluem coisas como o seu frig-
orífico detetar os níveis de alimentos e gerar uma lista de compras ou, até mesmo, pedir
comida num supermercado local. O seu automóvel pode reportar os dados ao conces-
sionário, para que possa ter todas as peças ou consumíveis necessários prontos quando
levar o veículo à revisão. E se o seu despertador tocasse de manhã e a máquina de café se
ligasse para lhe preparar o pequeno-almoço?
Uma grande área de preocupação com a IoT é a segurança do dispositivo. Com tan-
tos dispositivos fora da sua infraestrutura de rede principal e, muitas das vezes, ligados à
Internet pública, poder aprovisionar, manter e atualizar esses dispositivos é um desafio.
Muitos dispositivos IoT são de baixa potência, simples componentes eletrónicos que
podem não ter os recursos de armazenamento ou de processamento para se atualiza-
rem com atualizações de segurança e de aplicações como acontece num computador
de secretária ou portátil tradicionais. Não é suficiente implementar vários dispositivos
IoT, especialmente dispositivos ao nível do consumidor, sem um plano de proteção ade-
quado e fornecer atualizações e manutenção.
Estas preocupações de segurança não devem impedi-lo de criar aplicações e serviços
que utilizam dispositivos IoT. A IoT traz um novo conjunto de desafios para a
manutenção de dispositivos tradicionais, mas existem soluções que permitem aprovi-
sionar e manter dispositivos de forma central, bem como fornecer proteção à comuni-
cação do dispositivo.
Nesta altura, tenho a certeza de que pode ter adivinhado que o Azure tem essa
solução IoT! Ele oferece um conjunto de serviços de IoT. Vejamos como pode começar
a explorar a IoT com o Azure.
Acelerar as suas implementações da IoT do Azure

Este capítulo concentra-se no Azure IoT Hub, um serviço que permite aprovisionar e ligar
dispositivos IoT para criar as suas próprias soluções. Pode definir como esses dispositi-
vos IoT se ligam, quais utilizadores ou aplicações podem aceder aos seus dados e prote-
ger a conectividade. O modo de criação e implementação da infraestrutura de aplicações
para ligar tudo é consigo.
Os aceleradores de solução IoT do Azure são cenários principais pré-criados, como a moni-
torização remota de dispositivos ou uma fábrica ligada. Os aceleradores implementam
serviços comuns do Azure, como o Hub IoT, o Web Apps, o Cosmos DB e o Armazenamento,
e executam uma aplicação experimental que integra todos estes serviços diferentes.
Ainda precisa de personalizar a aplicação para o seu próprio ambiente, os dispositivos
IoT em utilização e os dados a serem recolhidos e monitorizados, mas os aceleradores
de soluções IoT oferecem uma excelente estrutura para começar. Ao passo que o IoT
Hub cria uma maneira de ligar dispositivos IoT ao Azure e permite implementar serviços
adicionais que possa precisar, os aceleradores de soluções IoT implementam soluções
pré-criadas que utilizam os serviços mais comuns do Azure que iria utilizar.
Se ficar viciado na IoT após este capítulo e quiser saber mais, os aceleradores de
soluções IoT do Azure são uma ótima maneira de ver as possibilidades que o Azure pode
oferecer. Conforme abordámos ao longo deste livro, o Azure é muito mais do que apenas
um ou dois serviços independentes. Pode implementar muitos serviços em conjunto
para fornecer a melhor experiência de aplicação possível aos seus clientes.
Gerir centralmente os dispositivos com o Azure IoT Hub 303
20.2 Gerir centralmente os dispositivos com o Azure IoT Hub

O Azure IoT Hub permite-lhe gerir, atualizar e transmitir dados centralmente a partir
de dispositivos IoT. Com este serviço, pode executar ações como configurar rotas de
aplicações para os dados recebidos a partir dos dispositivos, aprovisionar e gerir certifi-
cados para proteger a comunicação e monitorizar o estado de funcionamento com
diagnósticos e métricas do Azure. Pode ligar os seus dispositivos IoT a outros serviços e
aplicações do Azure para permitir que enviem e recebam dados como parte de uma
solução mais ampla. Como acontece com todas as coisas no Azure, o acesso pode ser
controlado com RBAC e os dados de diagnóstico podem ser recolhidos centralmente
para resolução de problemas e monitorização ou alertas. A figura 20.2 descreve como
um IoT Hub atua como ponto central para que os dispositivos IoT se liguem aos
serviços e aplicações mais amplos do Azure.
Controlar configuração, Aprovisionamento automa- Encaminhar mensagens

estado e metadados tizado de dispositivos para outros serviços do Azure Storage
Duplos de Aprovisionamento
Azure para processa-
dispositivos de dispositivos mento ou análise
Azure Service
Dispositivo IoT Azure Web Apps
Bus
Dispositivo IoT
Azure IoT
Hub Grelha de
Dispositivo IoT
Eventos do Azure Azure Logic Apps
Mensagens dos dispositivos
para a cloud e da cloud para Monitorizar, resolver
os dispositivos para receber problemas e alertar
e enviar dados sobre problemas
Figura 20.2 Com um IoT Hub, pode aprovisionar e gerir centralmente muitos dispositivos IoT à escala. Existe
uma comunicação bidirecional entre os dispositivos e o Azure para ler e escrever dados. Pode processar os
dados recebidos a partir dos dispositivos e encaminhá-los para outros serviços do Azure, como o Web Apps
e o Storage. Para monitorizar e resolver problemas, pode encaminhar as informações para o Azure Event Grid,
que veremos no capítulo 21, e depois criar ligações para outras soluções de monitorização.
Controla o acesso a um IoT Hub com políticas de acesso partilhado. Estas políticas são
como contas de utilizador e permissões. Existem políticas predefinidas que permitem
que dispositivos e serviços se liguem ao IoT Hub ou que leiam e escrevam informações
do registo do dispositivo que controla os dispositivos IoT ligados e as chaves de segu-
rança. Cada política pode receber uma ou mais das seguintes permissões:
¡ Leitura do registo
¡ Escrita do registo
¡ Ligação do serviço
¡ Ligação do dispositivo
As aplicações e os serviços utilizam chaves de acesso partilhado para se ligarem a um

IoT Hub. Como no Storage (abordado no capítulo 4), as chaves de acesso partilhado
permitem-lhe definir cadeias de ligação para identificar o host, a política de acesso e a
chave de acesso. Uma cadeia de ligação combina a chave de acesso, o tipo de política
de acesso e o nome de host do IoT Hub. Veja um exemplo de uma cadeia de
ligação do hub IoT:
HostName=azuremol.azure-devices.net;SharedAccessKeyName=registryRead;
➥SharedAccessKey=6be2mXBVN9B+UkoPUMuwVDtR+7NZVBq+C7A1xCmQGAb=
Existem chaves primárias e secundárias, as quais podem ser alternadas e atualizadas
para fins de segurança, como para atualizar regularmente as palavras-passe. As soluções
como o Azure Key Vault (abordadas no capítulo 15) são ótimas maneiras de controlar
e armazenar estas chaves, para que as aplicações as obtenham, quando necessário. Esta
abordagem à gestão de chaves indica que pode alternar frequentemente chaves de
acesso sem precisar de atualizar também todo o código da aplicação.
Os certificados digitais podem ser armazenados num IoT Hub e aprovisionados auto-
maticamente para os dispositivos IoT. Lembre-se de que, muitas das vezes, os dispositivos
IoT estão fora da sua infraestrutura core e podem ligar-se diretamente pela Internet sem
qualquer forma de ligação de rede segura, como uma VPN. Certifique-se de que todos os
dados entre os seus dispositivos e o IoT Hub estão encriptados com ligações SSL/TLS. O
Azure Key Vault pode gerar e armazenar certificados SSL que são adicionados ao IoT
Hub. Ou pode utilizar uma autoridade de certificação existente para pedir e emitir cer-
tificados. O importante é garantir que toda a comunicação entre os seus dispositivos IoT e
o Azure é encriptada. Caso contrário, é provável que receba um erro.
As rotas de IoT Hub permitem-lhe enviar dados dos dispositivos IoT para outros
serviços do Azure. Pode definir critérios, como o conteúdo da mensagem que contém
uma determinada palavra-chave ou valor, e encaminhar as mensagens para serem arma-
zenadas no Azure Storage ou processadas por uma aplicação Web. Num dos exercícios
a seguir, irá simular um sensor básico de temperatura ligado a um dispositivo IoT. Pode
definir uma rota no IoT Hub para observar os dados recebidos e, se a temperatura reg-
istada ultrapassar os 30 °C, pode encaminhar os dados para uma aplicação lógica para
enviar um alerta por e-mail. Iremos abordar o maravilhoso mundo da computação sem
servidor e das aplicações lógicas no capítulo 21!
Viva no limite
Neste capítulo, iremos focar-nos no Azure IoT Hub. Outro serviço, o Azure IoT Edge, per-
mite executar serviços, como o Azure Functions e o Stream Analytics, no seu ambiente
local. Em vez de ter todos os seus dispositivos IoT a transmitir dados para serem proces-
sados centralmente no Azure, pode processar os dados em cada localização.
O Azure IoT Edge executa aplicações e serviços em containers (abordados no
capítulo 19). A utilização de containers permite que o IoT Edge seja portátil e consistente
na forma como funciona em diferentes dispositivos e ambientes. Os serviços pré-criados
do Azure podem ser implementados ou pode criar as suas próprias aplicações e dis-
tribuí-las para as localizações na periferia.
O principal benefício do IoT Edge é que descarrega parte do processamento de dados
e das transferências de dados da rede. Se puder processar dados localmente no IoT
Edge, poderá agrupar grandes blocos de dados e transmiti-los novamente ao Azure.
Depois, as aplicações centrais podem agregar informações de outras localizações do
Edge para serem processadas por serviços como IA e ML.
Gerir centralmente os dispositivos com o Azure IoT Hub 305
Outro excelente cenário para o Azure IoT Edge são as localizações remotas, muitas das
vezes encontradas nas indústrias de gás e de petróleo ou de transporte, onde a conec-
tividade da Internet pode não ser fiável o suficiente para todos os dados do dispositivo
de IoT serem transmitidos novamente para o Azure e serem processados central-
mente. O IoT Edge permite essas localizações remotas para continuar a operar com
algum nível de autonomia, mesmo quando não há ligação à internet.
Ao planear uma infraestrutura de aplicações que envolva dispositivos IoT, examine como
pode gerir as interrupções de rede e as ligações à Internet deficientes. Se o seu ambi-
ente depende da Internet, planeie ligações de Internet redundantes e equipamentos
para encaminhar os dados. Ou veja o IoT Edge para processar localmente dados quando
não for possível fazer isso centralmente no Azure.
Experimente agora
Para começar a utilizar o IoT e criar um IoT Hub, conclua os passos a seguir:
1 Abra o portal Azure, execute o Cloud Shell e crie um grupo de recursos, como o
azuremolchapter20:
2 Trabalhou muito com a CLI do Azure neste livro, porque os comandos do Cloud
Shell e da CLI permitem-lhe criar e gerir recursos rapidamente. Como mencio-
nado nos capítulos anteriores, a CLI do Azure também pode utilizar módulos
adicionais, denominados extensões. Estas extensões adicionam mais funcionali-
dade e geralmente são atualizadas fora do ciclo de lançamento regular da CLI
principal do Azure. A IoT do Azure está a expandir-se rapidamente e a adicionar
novas funcionalidades. Por isso, os principais comandos para interagir com o IoT
Hub provêm de uma extensão da CLI do Azure.
Para obter a funcionalidade completa de que precisa para realizar estes exer-
cícios, instale a extensão IoT da CLI do Azure:
az extension add --name azure-cli-iot-ext
3 Crie um IoT Hub e dê-lhe um nome, como azuremol. Para estes exercícios,
pode utilizar um IoT Hub de escalão gratuito, f1:
az iot hub create \
--name azuremol \
--sku f1 \
--partition-count 2
NOTA Pode criar apenas um hub de escalão gratuito por subscrição, mas estes
hubs são ótimos para testar a comunicação entre dispositivos e integrar outros
serviços do Azure. O hub de escalão gratuito está atualmente limitado a 8000
mensagens por dia e suporta um máximo de 500 dispositivos ligados. Isto pode
parecer muito, mas, dependendo do que estiver a fazer, um único dispositivo
que envia uma mensagem para o IoT Hub a cada 12 segundos, aproximada-
mente, aumenta o limite de 8000 mensagens!
O seu IoT Hub está bem vazio agora. Não há muito que se possa fazer sem um ou mais
dispositivos IoT ligados. Um dispositivo habitualmente usado é o Raspberry Pi, um
minicomputador de baixo custo que pode ligar-se a redes Wi-Fi e utilizar sensores
comuns prontos a utilizar para medir temperatura, humidade e pressão. Também
pode utilizá-lo para controlar pequenos motores, luzes e temporizadores. Não precisa
de ir a correr comprar um Raspberry Pi para trabalhar com um IoT Hub, uma vez que
pode simular um no seu browser!
20.3 Criar um dispositivo Raspberry Pi simulado

Os dispositivos IoT são ótimos, mas existe uma barreira à entrada, pois é preciso de um
dispositivo físico, certo? Não! Existem algumas maneiras de simular um dispositivo IoT
com software. Esta abordagem baseada em software permite que se concentre na
criação da aplicação rapidamente e, em seguida, que faça a transição para um hard-
ware real. Ainda precisa de prestar atenção em como o seu código é executado em
hardware IoT real, especialmente dispositivos de baixo consumo, porque eles podem
não ter acesso a todas as bibliotecas necessárias, ou mesmo a recursos de memória, às
quais a sua aplicação simulada tem acesso.
A Microsoft fornece um simulador Raspberry Pi gratuito através do GitHub em
https://azure-samples.github.io/raspberry-pi-web-simulator. Um Raspberry Pi é ótimo
para testar, mas tenha cuidado ao utilizar hardware barato pronto a usar como o Rasp-
berry Pi em ambientes de produção. Planeie como vai atualizar e gerir esses dispositi-
vos. Dispositivos IoT dedicados, como o Azure Sphere (https://azure.microsoft.com/
services/azure-sphere), fornecem opções adicionais de segurança e de gestão. Para
este livro e no seu próprio teste e formação, o Raspberry Pi é uma boa alternativa. Neste
simulador, um sensor BME280 comum, que recolhe leituras de temperatura e de humi-
dade, é simulado no software juntamente com um LED simulado para mostrar quando
o dispositivo transmite dados para o hub IoT. Não é possível personalizar muito, mas
pode ver como uma aplicação Node.js básica pode ser executada no Raspberry Pi,
pesquisar dados de um sensor e enviá-os novamente para o Azure.
NOTA Se coisas como o Raspberry Pi, os sensores eletrónicos e de temperatura
e o Node.js parecerem intimidadores, não se preocupe. Assim como nos capítu-
los sobre IA e ML, containers e Kubernetes, não faremos uma análise profunda
sobre dispositivos IoT e programação. Se acha que até ao final desse capítulo
ficará fascinado com a eletrónica a ponto de querer ligar um ferro de solda, é
mais do que bem-vindo!
Antes de poder utilizar o simulador do Raspberry Pi, precisa de criar uma atribuição
de dispositivo no Azure IoT Hub. Este processo cria um ID de dispositivo exclusivo,
para que o IoT Hub compreenda com qual dos dispositivos está a comunicar e como
processar os dados. Em cenários mais complexos, pode aprovisionar definições adicio-
nais para o dispositivo e emitir certificados digitais via push. Para este exercício, bas-
tará criar uma identidade do dispositivo.
Experimente agora
Para criar um dispositivo IoT Raspberry Pi simulado, conclua os passos a seguir:
Criar um dispositivo Raspberry Pi simulado 307
1 No Azure Cloud Shell, crie uma identidade de dispositivo no seu IoT Hub, como
azuremol, e forneça um nome para o dispositivo, como raspberrypi:
az iot hub device-identity create \
--hub-name azuremol \
--device-id raspberrypi
2 Lembra-se das políticas de acesso partilhado da secção 20.2? Cada dispositivo IoT
também possui a sua própria chave de acesso e cadeia de ligação, que são utiliza-
das para identificá-lo quando comunica de novo com o seu IoT Hub. Esta princi-
pal característica do Azure IoT protege os dispositivos e minimiza o risco de
exposição no caso de um dispositivo estar comprometido.
Para utilizar o seu dispositivo com o simulador Raspberry Pi, precisa das infor-
mações da cadeia de ligação do dispositivo. Este identificador exclusivo inclui o
nome de host do seu IoT Hub, o ID do dispositivo e uma chave de acesso:
az iot hub device-identity show-connection-string \
--device-id raspberrypi \
--output tsv
3 Copie o conteúdo da sua cadeia de ligação, pois vai precisar dele no passo 4.
A saída é smiliar ao exemplo seguinte:
HostName=azuremol.azure-devices.net;DeviceId=raspberrypi;
➥SharedAccessKey=oXVvK40qYYI3M4u6ZLxoyR/PUKV7A7RF/JR9WcsRYSI=
4 Agora, vem a parte divertida! Abra o simulador do Raspberry Pi no seu browser:
https://azure-samples.github.io/raspberry-pi-web-simulator. Veja a secção de
código à direita no simulador. Por volta da linha 15, deve haver uma variável
connectionString, que já pede a [Cadeia de ligação do dispositivo do IoT Hub].
Copie e cole a cadeia de ligação do passo 3, conforme mostrado na figura 20.3.
5 Selecione o botão Executar logo abaixo da janela de código para iniciar o
simulador.
A cada dois segundos, a janela da consola apresenta uma mensagem que mos-
tra os dados enviados ao IoT Hub. O LED vermelho no diagrama de circuito tam-
bém pisca quando isso acontece, de forma a simular como as saídas ligadas ao
Raspberry Pi podem ser controladas. A mensagem de saída na janela da consola é
semelhante à seguinte:
Sending message: {"messageId":1,"deviceId":"Raspberry Pi Web
➥Client","temperature":24.207095037347923,
➥"humidity":69.12946775681091}
De onde vieram as leituras de temperatura e humidade? Este dispositivo é um
Raspberry Pi simulado e não há um sensor BME280 real, portanto, a aplicação
gera estes valores no software. Se olhar para o resto do código no
Figura 20.3 Copie e cole a cadeia de ligação do seu dispositivo IoT do Azure no simulador do Raspberry
Pi. A variável connectionString é utilizada para se ligar para transmitir os dados do sensor simulado
para o Azure.
janela do simulador, por volta da linha 99, a aplicação define o sensor. Depois, o
simulador replica como o sensor real vai agir e gera os dados devolvidos do sensor
para a aplicação. Este é um exemplo básico, então pense no que mais pode ler aqui:
rotações por minuto (RPM) de um motor ou mecanismo ou coordenadas de GPS
de um container de barco ou camião, e assim por diante. Existe um equilíbrio
entre simular um dispositivo no software e criar uma aplicação funcional com
dados reais de hardware e sensor. Em algum momento, irá precisar de comprar ou
pedir equipamentos emprestados se quiser analisar melhor a IoT do Azure.
6 Para confirmar que as mensagens do dispositivo simulado estão a ser recebidas
pelo seu IoT Hub, examine o estado da quota. Forneça o nome do seu IoT Hub,
como azuremol:
az iot hub show-quota-metrics --name azuremol
A saída é semelhante ao exemplo a seguir, o qual mostra que 5 mensagens,

do total máximo de 8000 mensagens por dia, foram recebidas e que há 1 disposi-
tivo ligado de um máximo de 500 dispositivos no total. Pode levar alguns minutos
até que estas métricas fiquem preenchidas. Portanto, não se preocupe se não vir
dados imediatamente:
[
{
Transmitir dados do Azure IoT Hub às aplicações Web do Azure 309
"currentValue": 5,
"maxValue": 8000,
"name": "TotalMessages"
},
{
"currentValue": 1,
"maxValue": 500,
"name": "TotalDeviceCount"
}
]
Também pode procurar no portal Azure: escolha o seu grupo de recursos e seleci-
one o seu IoT Hub. Na página Descrição Geral, a utilização do hub reporta o
número de mensagens recebidas e dispositivos ligados. Mais uma vez, pode
demorar um ou dois minutos para as mensagens aparecerem e serem registadas
na quota. Todas as aplicações podem utilizar imediatamente as mensagens rece-
bidas, como veremos na secção 20.4.
Problemas no paraíso
Se não receber nenhuma mensagem no hub da IoT, verifique a janela de saída do seu
dispositivo Raspberry Pi simulado. Uma das primeiras coisas que a aplicação faz é
ligar-se ao Hub IoT do Azure. Será mostrado um erro de ligação se a sua cadeia de
ligação estiver errada. Assegure-se de que copia e cola corretamente toda a cadeia de
ligação. A cadeia de ligação começa por HostName e o último caráter em cada tecla de
acesso é sempre um sinal de igual (=).
Se a janela de saída reportar um erro, copie o texto do erro para o seu motor de
busca preferencial e procure um resultado correspondente. Certifique-se de que não
alterou nenhuma das outras linhas de código, o que causará um problema! A única coisa
que precisa de mudar na janela de código é a linha da sua cadeia de ligação.
Como o dispositivo Raspberry Pi simulado é executado num browser, pode ter um prob-
lema de site genérico. Tente atualizar a página ou aceda ao simulador num
browser diferente (https://azure-samples.github.io/raspberry-pi-web-simulator).
20.4 Transmitir dados do Azure IoT Hub às aplicações Web do Azure

Um dispositivo que se liga a um IoT Hub não é útil se não conseguir fazer nada com os
dados. É aqui que pode começar a integrar muitos dos serviços e funcionalidades que
aprendeu neste livro. Pretende transmitir para tabelas ou filas do Azure Storage? Pode
fazer isso. Processar dados de dispositivos IoT em VMs ou containers do Azure? Vá em
frente! Utilizar o Azure Cosmos DB para replicar os seus dados e, depois, aceder aos mes-
mos com aplicações Web do Azure globalmente redundantes e o Traffic Manager? Claro!
No cenário de exemplo, o IoT Hub é o mecanismo de ligação e o ponto de entrada dos
seus dispositivos IoT no Azure. O hub, em si, não faz nada diretamente com os dados.
Existe um endpoint predefinido para eventos, que é um grande registo para todas as men-
sagens recebidas do dispositivo IoT. O seu dispositivo Raspberry Pi simulado envia men-
sagens para o IoT Hub, que atingiu este endpoint de eventos. O fluxo de mensagens de
dispositivos por meio do IoT Hub para um endpoint é mostrado na figura 20.4.
As mensagens são enviadas de

Disposivo disposivos IoT para o Azure IoT Hub.
IoT
Disposivo Azure IoT Endpoint
IoT
Disposivo
Hub As mensagens
são enviadas para
IoT
um endpoint definido.
Figura 20.4 Um IoT Hub recebe mensagens de dispositivos IoT ligados e envia as mensagens para um
endpoint. Estes endpoints podem ser utilizados por outros serviços do Azure para consumir dados dos
dispositivos IoT. Existe um endpoint predefinido para eventos e serviços, como aplicações Web, podem
ser lidos.
Pode criar endpoints personalizados que encaminham mensagens diretamente para

os serviços do Azure, como o Storage e o Service Bus. No capítulo 4, examinámos as
filas do Azure Storage, de forma a obter uma maneira de devolver mensagens entre as
aplicações. Uma plataforma de mensagens empresarial mais robusta e dimensionável é
o Azure Service Bus. As mensagens podem ser adicionadas ao service bus, como os
dados recebidos de dispositivos IoT. Depois, as outras aplicações podem ouvir
estas mensagens e responder adequadamente.
Se não precisar da complexidade de ler mensagens de uma fila de mensagens como
um service bus, poderá utilizar grupos de consumidores com o endpoint de eventos
predefinido. Um grupo de consumidores permite que serviços, como o Azure Web
Apps, leiam dados do endpoint, como mostra a figura 20.5. Cada leitura de serviço do
Azure IoT Hub deve ter o seu próprio grupo de consumidores. Vários serviços, cada um
com o seu próprio grupo de consumidores, podem receber as mesmas mensagens e
processá-las conforme necessário.
Mensagens enviadas de disposivos IoT eventos

Disposivo
através do Azure IoT Hub do para um endpoint
IoT msg msg
Disposivo Azure IoT msg msg
IoT Endpoint
Hub
Disposivo
IoT Grupo de
consumidores Web Apps
Um grupo de consumidores permite que outros

serviços, como o Azure Web Apps, acedam às
mensagens recebidas por um endpoint.
Figura 20.5 As mensagens são enviadas de dispositivos IoT para o IoT Hub, que direciona as mensagens para um
endpoint. Em cada endpoint, podem ser criados grupos de consumidores. Estes grupos de consumidores permitem
que outros serviços do Azure acedam às mensagens do dispositivo, às quais não teriam acesso de outra forma. Com
os grupos de consumidores, não precisa de utilizar filas de mensagens para permitir que as aplicações externas
leiam os dados do dispositivo IoT.
Vamos criar uma aplicação Web do Azure que utilize um grupo de consumidores para
ler dados de mensagens em tempo real a partir do seu dispositivo Raspberry Pi simu-
lado. Este exemplo básico mostra como pode transmitir dados de dispositivos IoT e
aceder aos mesmos a partir de aplicações Web.
Experimente agora
Para criar uma aplicação Web do Azure que leia dados de dispositivos IoT, conclua
os passos a seguir:
1 Crie um plano do App Service do Azure para a sua aplicação Web no Azure
Cloud Shell e forneça um nome, como azuremol. Para estes exercícios, o escalão
gratuito (f1) é bom o suficiente e mantém os custos baixos:
--name azuremol \
--sku f1
2 Crie a aplicação Web. Forneça um nome, como molwebapp, e ative-o para uti-
lização com o Git para que possa implementar a aplicação experimental. Tal
como acontece com outros recursos do Azure acessíveis ao público, precisa de
fornecer o seu próprio nome único globalmente.
az webapp create \
--plan azuremol \
--name molwebapp \
3 Definia o grupo de consumidores para o seu IoT Hub, juntamente com algumas
definições da aplicação para aplicações Web. Estas definições permitem que a
sua aplicação Web se ligue ao seu IoT Hub. A figura 20.6 mostra o que criará nos
próximos passos.
As definições da aplicação são

Azure Web App transmitidas para o código da
aplicação. O nome do grupo de
Definição de aplicação consumidores e a string de ligação
consumergroup=molwebapp não são codificados na sua aplicação.
Definição de aplicação Código da aplicação

Endpoint Azure
IoT Hub iot=$iotconnectionstring
msg msg
WebSockets
msg msg
ativados true
Grupo de
consumidores Browser
As mensagens recebidas pelo endpoint do Azure IoT Hub são lidas por
uma aplicação Web. É utilizada uma ligação WebSocket para emitir
automaticamente via push as atualizações para os browsers ligados.
Figura 20.6 Para permitir que a aplicação Web leia os dados do dispositivo IoT Raspberry Pi simulado, crie um
grupo de consumidores no IoT Hub. Depois, crie duas definições da aplicação para a sua aplicação Web que lhe
permitem ligar ao grupo de consumidores. Para permitir que o browser receba automaticamente o fluxo de dados
do Raspberry Pi à medida que novos dados são recebidos, também irá ativar uma definição para WebSockets.
4 Crie um grupo de consumidores que permita que a sua aplicação Web aceda aos
dados do evento transmitidos pelo dispositivo IoT. Forneça o seu IoT Hub, como
azuremol, e introduza um nome para o seu grupo de consumidores, como molwe-
bapp. Certifique-se de que utiliza o seu próprio nome durante os passos seguintes.
O seu grupo de consumidores será criado no endpoint de eventos predefinido:
az iot hub consumer-group create \
--name molwebapp
5 Precisa de informar a aplicação Web sobre o nome do grupo de consumidores.

Crie uma definição da aplicação para aplicações Web utilizada pela aplicação de
exemplo que irá implementar no final do exercício. As definições da aplicação
para aplicações Web permitem que defina definições específicas, como o nome
do grupo de consumidores e a cadeia de ligação, sem que esses valores sejam
codificados na sua aplicação.
Forneça o nome do grupo de consumidores que criou no passo 4, como mol
webapp:
az webapp config appsettings set \
--name molwebapp \
--settings consumergroup=molwebapp
6 Para se ligar ao seu IoT Hub, a sua aplicação Web precisa de conhecer a cadeia
de ligação do hub. Esta cadeia de ligação é diferente daquela que copiou para o
seu dispositivo Raspberry Pi simulado no exercício anterior. Lembre-se de que
há uma cadeia de ligação para o seu IoT Hub, que utiliza políticas de acesso par-
tilhado para definir as permissões de acesso. Existe igualmente uma cadeia de
ligação para cada dispositivo IoT. A sua aplicação Web precisa de efetuar a leitura
a partir do endpoint do IoT Hub do grupo de consumidores, por isso tem de
definir uma cadeia de ligação para o próprio IoT Hub.
7 Obtenha a cadeia de ligação do IoT Hub e atribua-a a uma variável denominada
iotconnectionstring, que será utilizada no passo 8.
iotconnectionstring=$(az iot hub show-connection-string \
--output tsv)
8 Crie outra configuração para a aplicação Web, desta vez para a cadeia de ligação
do IoT Hub. A variável definida no passo 7 é utilizada para permitir que a apli-
aplicação experimental se ligue e leia dados a partir do dispositivo IoT:
az webapp config appsettings set \
--name molwebapp \
--settings iot=$iotconnectionstring
9 Permitir WebSockets. Um WebSocket é um meio de comunicação bidirecional

entre um browser e um servidor. A aplicação experimental atualiza automatica-
mente o browser com os dados recebidos do dispositivo Raspberry Pi. Para exe-
cutar esta atualização automatizada, a aplicação utiliza o WebSockets. Em
seguida, o servidor poderá enviar dados para o browser e fazer com que o mesmo
atualize automaticamente:
az webapp config set \

--name molwebapp \
--web-sockets-enabled
Vamos fazer uma pausa aqui para recapitularmos o que fez até agora. Trabalhou
com aplicações Web em muitos dos capítulos anteriores, mas as definições das
aplicações Web e os WebSockets são novas. A figura 20.7 recapitula como a sua
aplicação Web e o IoT Hub estão ligados.
As definições da aplicação são

Azure Web App transmitidas para o código da
aplicação. O nome do grupo de
Definição de aplicação consumidores e a string de ligação
consumergroup=molwebapp não são codificados na sua aplicação.
Definição de aplicação Código da aplicação

Endpoint Azure
IoT Hub iot=$iotconnectionstring
msg msg
WebSockets ativados
msg msg
true
Grupo de
consumidores Browser
As mensagens recebidas pelo endpoint do Azure IoT Hub são lidas
por uma aplicação Web. É utilizada uma ligação WebSocket para emitir
automaticamente via push as atualizações para os browsers ligados.
Figura 20.7 À medida que as mensagens são enviadas de dispositivos IoT, passam pelo IoT Hub para um endpoint.
O código da aplicação lê as definições das aplicações Web que definem a cadeia de ligação do IoT Hub e o grupo de
consumidores a ser utilizado. Assim que a aplicação estiver ligada ao IoT Hub, o grupo de consumidores permite
que as aplicações Web leiam as mensagens do dispositivo IoT. Cada vez que uma nova mensagem é recebida de um
dispositivo IoT, a sua aplicação Web irá utilizar uma ligação do WebSocket com browsers que acedem ao seu site
para enviar atualizações automaticamente. Esta ligação permite ver dados em tempo real transmitidos de
dispositivos IoT, como informações de temperatura e humidade, a partir do seu dispositivo Raspberry Pi simulado.
Agora, vamos concluir o exercício e implementar a aplicação experimental do

repositório GitHub na sua aplicação Web. Poderá abrir a aplicação Web no browser
e ver os dados em tempo real transmitidos a partir do Raspberry Pi simulado!
10 Se for necessário, clone o repositório de exemplos do GitHub no seu Cloud Shell
11 Mude para o diretório encontrado no capítulo 20:

cd azure-mol-samples-2nd-ed/20
12 Inicialize o repositório Git e adicione a página Web básica:

13 Para carregar a aplicação experimental, crie uma ligação à sua aplicação Web. O
comando seguinte obtém o repositório de aplicações Web e configura o seu
repositório Git de exemplos local para se ligar ao mesmo:
git remote add molwebapp \
$(az webapp deployment source config-local-git \
--name molwebapp \
--output tsv)
Nos capítulos anteriores, fi-lo procurar este endereço, mas agora, espero que
tenha começado a explorar o que mais a CLI do Azure pode fazer e tenha perce-
bido que muitas destas informações podem ser obtidas rapidamente.
14 Emita o site HTML de exemplo para a aplicação Web com o seguinte comando:
git push molwebapp master
15 Quando pedido, introduza a palavra-passe do utilizador do Git que criou e uti-

lizou nos capítulos anteriores (a conta criada no capítulo 3).
Se não escreveu a sua palavra-passe do Git num post-it

Se se esqueceu da palavra-passe, pode repô-la. Primeiro, obtenha o nome de utilizador
da sua conta de implementação do Git local:
az webapp deployment user show --query publishingUserName
Para repor a palavra-passe, introduza o nome da sua conta a partir do comando anterior
e, em seguida responda às instruções para definir uma nova palavra-passe. O exemplo a
seguir repõe a palavra-passe da conta de utilizador denominada azuremol:
az webapp deployment user set --user-name azuremol
16 Veja o nome de host da aplicação Web e abra o endereço num browser:

az webapp show \
--name molwebapp \
--query defaultHostName \
--output tsv
Na primeira vez que abrir o site no seu browser, pode levar alguns segundos
até a aplicação Web ligar-se ao seu IoT Hub, iniciar a ligação do WebSocket e
aguardar pela primeira mensagem do dispositivo a ser recebida. A cada dois
segundos, o browser deverá efetuar a atualização automaticamente com os dados
simulados mais recentes do dispositivo Raspberry Pi, conforme mostrado na
figura 20.8.
Análise dos componentes IoT do Azure 315
Figura 20.8 A aplicação experimental utiliza uma ligação do WebSocket entre o seu browser e a
aplicação Web para efetuar a atualização automaticamente a cada dois segundos com os dados
mais recentes do dispositivo Raspberry Pi simulado.
Se a instância da aplicação Web não mostrar dados, certifique-se de que o dispositivo

Raspberry Pi simulado ainda está em execução. Se necessário, inicie o dispositivo simu-
lado e certifique-se de que se liga à IoT do Azure e envia mensagens. Os dados deverão
começar a aparecer na instância da aplicação Web.
20.5 Análise dos componentes IoT do Azure

Espero que os exercícios deste capítulo lhe tenham dado uma ideia sobre quais os
serviços que estão disponíveis no Azure para as soluções IoT:
¡ O Azure IoT Hub fornece uma ótima maneira de aprovisionar, ligar e gerir muitos
dispositivos IoT, além de se integrar em outros serviços do Azure.
¡ Os aceleradores de soluções IoT do Azure fornecem cenários pré-criados que integram
automaticamente muitos serviços diferentes do Azure para fornecer um ambi-
ente de aplicação completo.
¡ O Azure IoT Edge permite-lhe implementar serviços do Azure no seu ambiente
local para processar dados de dispositivos IoT sem a necessidade de transmitir
todos os dados centralmente de novo para o Azure.
Para realmente explorar os dispositivos IoT e a IoT do Azure em geral, recomendo que
compre um Raspberry Pi básico ou um dispositivo semelhante. Estes dispositivos são
relativamente baratos, vêm, geralmente, com alguns sensores básicos ou componentes
elétricos para testar ideias diferentes e oferecem uma ótima plataforma de aprendiza-
gem, à medida que vê o que é capaz de fazer ao integrar o hardware e o software. Basta
lembrar os avisos no capítulo 17 sobre IA e ML e a criação da Skynet! A Manning tam-
bém tem excelentes livros, como o Building the Web of Things, por Dominique D. Gui-
nard e Vlad M. Trifa (https://www.manning.com/books/building-the-web-of-things) e
o JavaScript on Things, por Lyza Danger Gardner (https://www.manning.com/books/
javascript-on-things), que aborda mais detalhadamente o Raspberry Pi, as melhores
práticas de IoT e a programação Node.js e JavaScript em dispositivos de IoT.
Lembra-se de ter dito: “Elimine sempre os seus grupos de recursos”?

A melhor prática em todo este livro foi eliminar os seus grupos de recursos no final de
cada capítulo. Esta abordagem dá a garantia de que não deixe serviços e aplicações que
custam dinheiro em utilização quando não precisa deles.
(continuação)
A IoT do Azure oferece uma ótima plataforma para transmitir dados para o Azure. Nor-
malmente, precisa de processar esses dados, não apenas apresentá-los numa apli-
cação Web como nos exercícios. O capítulo 21 examina a computação sem servidor com
os serviços Logic Apps e Functions.
Para mostrar como estes serviços do Azure funcionam bem juntos, não elimine o grupo
de recursos e os serviços implementados neste capítulo. Irá utilizá-los logo no início do
capítulo 21 para ver como pode executar ações com base nos dados recebidos dos seus
dispositivos IoT. Certifique-se apenas de que volta ao dispositivo Raspberry Pi simulado
e seleciona o botão Parar. Caso contrário, esse limite de 8000 mensagens será utilizado
muito rapidamente!
20.6 Laboratório: explorar casos práticos para IoT

Este capítulo abordou muitas novidades e, sem um dispositivo IoT real, está limitado
ao que pode fazer. O Capítulo 21 baseia-se no Azure IoT Hub e no Raspberry Pi simu-
lado, por isso não quero fazer mais configurações agora. Deixamos aqui algumas coisas
que pode fazer para refletir sobre a IoT:
1 Em que as áreas acha que os dispositivos IoT podem beneficiar a sua empresa? Se
não trabalha numa empresa agora, pense na pizzaria fictícia do Azure durante os
almoços de um mês.
2 O que poderia fazer para melhorar as coisas para os clientes com IoT?
3 Iria utilizar o Azure IoT Edge? Por que sim ou por que não?
4 Quais os outros serviços do Azure que iria, provavelmente, integrar para execu-
tar as suas aplicações?
5 Se tiver tempo suficiente na sua hora de almoço, experimente um dos acelera-
dores de soluções IoT do Azure em www.azureiotsolutions.com/Accelerators. Há
um cenário de Simulação de Dispositivos que cria uma VM e sensores simulados,
que é como o dispositivo Raspberry Pi simulado, mas muito maior! Leva alguns
minutos a aprovisionar todos os recursos necessários, mas, depois procure no
portal Azure para ver o que foi criado e como todas as partes funcionam juntas.
6 Consegue ver como os serviços dos capítulos anteriores, como o Storage e o Cos-
mos DB, são utilizados?
7 Que outros aceleradores de soluções IoT estão disponíveis? Algum deles
enquadra-se nas ideias que tinha para as suas próprias aplicações?
21
Computação sem servidor
Neste capítulo final, iremos contemplar o futuro da computação sem servidor. Se for
um programador, a ideia de containers (que examinámos no capítulo 19) pode ter
sido atraente, pois há menos necessidade de configurar a infraestrutura subjacente
para as suas aplicações. Se a resposta for afirmativa, vai adorar os componentes sem
servidor do Azure! E se for um administrador de TI que, de repente, se pergunta qual
será o seu trabalho se não houver servidores no futuro, não se preocupe! A computação
sem servidor pode ser mais um termo de marketing, mas muitas das competências de
servidor e de infraestruturas que possui vão continuar a ser aplicadas!
No Azure, duas principais ofertas oferecem funcionalidades de computação sem
servidor: Azure Logic Apps e Azure Function Apps. Neste capítulo, iremos explorar
o que cada serviço oferece e como podem trabalhar juntos. Para garantir que as suas
aplicações sem servidor podem comunicar entre si e transmitir dados, iremos tam-
bém abordar os serviços de mensagens, como o Azure Event Grid, o Service Bus e os
Event Hubs.
21.1 O que é a computação sem servidor?

Dizer que essa computação sem servidor não tem um servidor é simplesmente
errado: existe sempre um servidor em algum lugar que executa algum código para
si. A diferença dos workloads de aplicações IaaS, como VMs do Azure e workloads
de PaaS em aplicações Web, é que as aplicações sem servidor geralmente são dividi-
das em unidades discretas menores de uma aplicação. Não executa uma única apli-
cação de grandes dimensões. Em vez disso, executa componentes de aplicações
mais pequenos. Se isso o fizer lembrar dos containers e dos microsserviços que abor-
dámos no capítulo 19, não se preocupe se estiver a enlouquecer: a computação sem
servidor tem muita coisa em comum com esses tópicos em termos de como concebe
as suas aplicações. Pode, provavelmente, criar microsserviços usando as abordagens
sem servidor que iremos analisar neste capítulo.
A figura 21.1 mostra como uma aplicação é dividida em pequenos componentes
que são executados num fornecedor de computação sem servidor e fornecem
pequenas unidades de saída.
317
318 Capítulo 21 Computação sem servidor
Função de
Saída da aplicação
aplicação pequena
Fornecedor de
Função de
aplicação pequena computação sem Saída da aplicação
servidor
Função de
Saída da aplicação
aplicação pequena
Figura 21.1 Num ambiente de computação sem servidor, cada aplicação é dividida em unidades pequenas
e discretas de componentes de aplicações. Cada componente é executado num fornecedor de computação
sem servidor, como o Azure Function Apps, e é produzida uma saída que pode ser consumida por outros
componentes da aplicação sem servidor ou outros serviços do Azure, como a IoT do Azure ou o Azure Storage.
No Azure, a computação sem servidor abrange dois serviços principais:

¡ Azure Logic Apps—Para responder a determinadas entradas e acionadores, as apli-
cações lógicas permitem-lhe criar visualmente workflows que podem processar e
gerar ações adicionais apenas apontando e clicando, sem necessidade de código.
As aplicações lógicas podem ser criadas por utilizadores sem experiência em pro-
gramação ou infraestrutura de TI. Um esquema de uma aplicação lógica simples
é mostrado na figura 21.2.
Mensagem de entrada
Mensagem recebida do dispositivo IoT
Verificar o conteúdo da mensagem Figura 21.2 Numa aplicação lógica,

uma entrada poderá ser quando um
Dados dentro da mensagem extraída tweet é publicado, um ficheiro carregado
ou uma mensagem ser recebida de um
Aplicar lógica ao conteúdo
dispositivo IoT. A aplicação lógica
Verifique se a temperatura se encontra aplicará regras e filtros aos dados e
acima do limiar
determinará se a mensagem cumpre
Gerar ação de saída os critérios definidos. Depois, serão
concluídas as ações de saída, como
gerar um e-mail. Toda esta lógica não
E-mail enviado envolve nenhuma infraestrutura de
programação ou aplicação além de
uma subscrição do Azure.
Não há atualizações de segurança a serem mantidas nem nenhum requisito de

design para elevada disponibilidade ou capacidade de dimensionar. A plataforma
do Azure processa automaticamente estas tarefas. Existem centenas de conecto-
res pré-criados para as aplicações lógicas se integrarem em serviços, como Twitter,
Office 365, SharePoint e Outlook. Pode responder a tweets públicos sobre a sua
empresa ou produto, enviar um alerta por e-mail quando um ficheiro for carre-
gado no SharePoint ou enviar uma notificação quando uma mensagem for rece-
bida de um dispositivo IoT.
¡ Azure Function Apps—Para executar pequenos blocos de código, as aplicações de
função permitem-lhe utilizar linguagens de programação comuns, como C#,
Node.js e Python, sem qualquer gestão de infraestruturas adicional. O seu código
Plataformas de mensagens do Azure 319
será executado num ambiente seguro e isolado, e será cobrado com base no con-
sumo de memória por segundo. A figura 21.3 descreve o processo básico de uma
aplicação de função.
Um evento, como uma

mensagem recebida de um
dispositivo IoT do Azure, aciona
uma aplicação de função. Azure Function Apps
Notificação Pequena unidade Saída de
de evento de código execução
C#, Node.js, Python
Uma pequena unidade de código
é executada e é fornecida a saída
que pode integrar outros serviços
ou aplicações.
Figura 21.3 Tal como acontece com uma aplicação lógica, uma notificação ou acionador de evento,
geralmente, inicia uma função do Azure. A aplicação de função contém uma pequena unidade de
código que executa uma tarefa específica. Não há nenhuma infraestrutura a ser configurada ou
mantida. Apenas o pequeno bloco de código será necessário. No momento em que a execução do
código ficar concluída, a saída poderá ser integrada noutro serviço ou aplicação do Azure.
Não há VMs a serem mantidas e nenhuma aplicação Web será necessária. Não pre-
cisa de se preocupar com a elevada disponibilidade ou o dimensionamento, por-
que o serviço Azure Function Apps trata destas tarefas por si. Tudo o que fornece é
o seu código, sendo que a plataforma do Azure garante que, sempre que precisar
de executar esse código, os recursos ficarão disponíveis para processar o seu pedido.
As aplicações lógicas não requerem código, têm uma base de possíveis utilizadores
mais ampla. Os proprietários de aplicações de negócio ou as equipas de finanças e con-
tabilidade, por exemplo, podem criar as suas próprias aplicações lógicas sem precisar
de escrever códigos. O Function Apps fornece mais controlo e flexibilidade e permite
o processamento de eventos de maneira específica e uma integração melhor noutros
componentes da aplicação.
As aplicações lógicas e as aplicações de função fornecem uma maneira de executar
ações com base em acionadores sem precisar de manter nenhum ambiente de aplica-
ção ou infraestrutura. Um servidor em algum lugar no Azure executa a aplicação lógica
ou função, mas, do seu ponto de vista de administrador ou de programador de TI, estas
são tecnologias sem servidor.
21.2 Plataformas de mensagens do Azure

No capítulo 12, vimos como monitorizar e resolver problemas dos recursos do Azure e
no capítulo 16 vimos como utilizar o Centro de Segurança do Azure para detetar pro-
blemas e executar a gestão de atualizações. As duas funcionalidades dependem de flu-
xos de dados, como a extensão de diagnóstico da VM do Azure, para informar a
plataforma sobre o que se passa na VM. A plataforma de monitorização e diagnóstico
do Azure é excelente e outros serviços, como as aplicações Web, o Azure Container
Instances e o Azure IoT Hub, também podem transmitir diagnósticos de serviço para
análise central.
Com as aplicações sem servidor, muitas vezes precisará de trocar mensagens e trans-
mitir dados reais da aplicação, não apenas resolver diagnósticos ou atualizações de
estado. É nesse ponto que precisa de uma plataforma de mensagens.
21.2.1 Grelha de Eventos do Azure

E se quiser apenas informar certas ações ou atividades que estão a ser concluídas? Nos
workflows de automatização e computação sem servidor, a capacidade de executar
uma ação em resposta a um evento é útil, como mostra a figura 21.4.
À medida que os serviços ou as ações de

recursos são executados, as notificações podem
ser enviadas para a Grelha de Eventos do Azure.
IoT do Azure Funções do Azure

Grelha de
Blobs do Azure
Storage Eventos do Azure Automation
Azure
Grupos de recursos Webhooks
Os serviços do Azure ou fornecedores

externos podem ser configurados para
responder a estes eventos.
Figura 21.4 Os serviços do Azure, como a IoT do Azure e o Azure Storage, podem enviar notificações
para o Azure Event Grid. Estas notificações podem ocorrer quando uma mensagem for recebida de um
dispositivo IoT ou um ficheiro for carregado no armazenamento. O Azure Event Grid permite que outros
serviços e fornecedores subscrevam estas notificações para executar ações adicionais em resposta a
eventos.
Vamos examinar alguns cenários que pode utilizar na sua pizzaria:

¡ Mensagem recebida num IoT Hub—Um dispositivo IoT ligado a um IoT Hub pode
comunicar uma leitura de temperatura num forno ou a localização de um veículo
de entregas. O hub IoT é configurado para encaminhar uma notificação para o
Azure Event Grid.
Uma função do Azure subscreve as notificações do Event Grid para um
hub IoT e executa um pequeno componente de aplicação sem servidor para
registar as informações no Azure Cosmos DB e enviar uma notificação por e-mail.
Também pode utilizar Logic Apps em vez de Azure Function Apps, dependendo
do tipo de complexidade que a resposta da aplicação precisa de ter.
¡ Ficheiro carregado no Azure Storage—O departamento de marketing pode carregar no
Storage um cupão promocional para poupar dinheiro num pedido de pizza.
Quando um novo ficheiro é criado, uma notificação será enviada para o Event Grid.
Um webhook subscreve o Event Grid e publica uma cópia da imagem do arma-
zenamento no Twitter. Este tweet permitirá que os clientes saibam sobre a oferta
da semana ou sobre o cupão para poupar dinheiro.
Estes cenários servem para os casos de computação sem servidor, mas o Event Grid
também pode integrar recursos mais tradicionais, como as VMs e as aplicações Web.
Um grupo de recursos pode ser configurado para enviar notificações para o Event Grid,
por exemplo. Há muitas maneiras de criar uma VM, como no portal, com a CLI do
Azure ou com um modelo do Gestor de Recursos. Por isso, deve certificar-se de que a
VM está configurada corretamente para a Gestão de Atualizações através do Centro de
Segurança. Um runbook de Automation do Azure pode subscrever o Event Grid para
receber notificações sobre operações de criação de VMs. Em seguida, irá incorporar a
VM no serviço de Gestão de Atualizações e instalar as atualizações de segurança ou de
aplicação necessárias.
21.2.2 Event Hubs do Azure e Service Bus

O Event Grid pode trabalhar com muitos recursos do Azure e é adequado para compu-
tação sem servidor com aplicações lógicas ou aplicações de função. Mas as aplicações
lógicas e as aplicações de função podem ser executadas com base em outras entradas
de dados, como hubs de eventos ou um service bus. Vejamos as diferenças entre estes
diversos serviços de mensagens, para que possa decidir melhor quando deve
utilizá-los:
¡ O Azure Event Hubs permite-lhe receber um fluxo de dados, como de dispositivos
IoT ou telemetria das aplicações. Os hubs de eventos fornecem uma plataforma
de mensagens de baixa latência capaz de lidar com milhões de eventos por
segundo de vários fornecedores simultâneos. Os hubs de eventos são uma loja de
dados em vez de uma fila de mensagens, em que o cliente ou a aplicação verifica a
existência de eventos no hub com a frequência escolhida. Em seguida, os dados
recebidos no hub de eventos podem ser processados por outros servi-
ços, tal como mostrado na figura 21.5.
¡ O Azure Service Bus permite que os componentes da aplicação troquem dados de
mensagens, como as filas de armazenamento examinadas no capítulo 4. As filas
de armazenamento são uma implementação anterior e mais básica de uma plata-
forma de mensagens no Azure. Um service bus oferece funcionalidades mais
Vários dispositivos IoT ligam-se

ao Azure IoT Hub e transmitem
dados dos sensores.
Dispositivo IoT
Azure IoT Azure Azure

Dispositivo IoT
Hub Event Hubs HDInsight
Dispositivo IoT
Os dados são transmitidos para os Fluxos de dados dos Event Hubs
Azure Event Hubs, que podem podem ser processados por
processar vários fluxos de dados serviços de cálculo de big data,
grandes e eventos simultâneos. como o HDInsight e estruturas
como o Hadoop e o Spark.
Figura 21.5 Os dispositivos IoT ligam-se ao IoT Hub e podem transmitir todos os dados do sensor. Pode haver
centenas ou milhares de dispositivos IoT ligados. O Azure Event Hubs trata de todos estes fluxos de dados
separados e permite que serviços como o Azure HDInsight processem os dados não processados nos clusters
Hadoop ou Spark para analisar e gerar relatórios.
avançadas, como a garantia da ordem das mensagens, operações atómicas e o

envio de mensagens em lotes. A figura 21.6 descreve um cenário comum para um
service bus.
Aplicação de Aplicação de Aplicação de

front-end middleware back-end
O componente A mensagem é obtida
da aplicação da fila do Service Bus
coloca os dados da e processada por
A mensagem está disponível
mensagem na fila outro componente
para outros componentes
do Service Bus. da aplicação.
de aplicações ligados.
Msg Msg
Azure Service Bus
Figura 21.6 As mensagens são colocadas numa fila de service bus pelos componentes da aplicação,
uma aplicação de front-end, neste exemplo. Outras aplicações de middleware ou de back-end poderão
recolher estas mensagens e processá-las, conforme necessário. Aqui, uma aplicação de back-end
recolhe a mensagem e processa-a. As funcionalidades avançadas de mensagens incluem a garantia
da ordem das mensagens na fila, bloqueio de mensagens, tempos limite e reencaminhamentos.
De três serviços que lhe permitem transmitir, receber e processar dados entre aplica-
ções e serviços no Azure, qual o que utiliza e quando? A tabela 21.1 fornece uma reca-
pitulação de alto nível dos serviços Event Grid, Event Hubs e Service Bus.
Tabela 21.1 Cada serviço foi concebido para abranger um cenário diferente. O Event Grid permite
reagir a eventos, o Event Hubs permite transmitir grandes quantidades de dados e o Service Bus permite
transmitir mensagens entre serviços e componentes da aplicação.
Serviço do Fornece Caso práco

Azure
Event Grid Distribuição de eventos Realizar uma ação adicional com base numa ocorrência
de evento.
Receber e transmir grandes volumes de dados
Event Hubs Fluxos de dados simultâneos.
Service Bus Transmissão de mensagens Fornecer comunicação entre serviços e aplicações.
As Logic Apps e Function Apps do Azure podem ser acionadas por todas as três plata-
formas de mensagens. Vamos criar um service bus que possa ser utilizado para acionar
uma aplicação lógica.
21.2.3 Criar um service bus e integrá-lo num IoT Hub

Neste cenário, vamos utilizar um service bus para transmitir mensagens recebidas de
um IoT Hub. O seu dispositivo Raspberry Pi simulado do capítulo 20 gera leituras de
temperatura e transmite-as para o seu IoT Hub. Se a temperatura for superior a 30 °C,
outro dado será incluído na mensagem do dispositivo IoT: temperatureAlert = true.
A figura 21.7 descreve como pode integrar um IoT Hub no service bus para processar
mensagens com este alerta de temperatura.
Azure IoT Hub Azure Logic Apps
O dispositivo IoT
envia dados com um A mensagem é obtida
alerta de temperatura; da fila do Service Bus e
a mensagem A mensagem está disponível aciona a aplicação lógica.
é colocada na fila do para outros componentes
Service Bus. de aplicações ligados.
Msg Msg
Azure Service Bus
Figura 21.7 Quando o dispositivo Raspberry Pi IoT simulado envia dados de mensagens, uma leitura de
temperatura de 30 °C ou mais gera um alerta. As mensagens marcadas com este alerta são colocadas
num service bus. Em seguida, estas mensagens podem ser utilizadas para acionar aplicações lógicas.
Experimente agora
Para criar um service bus, conclua os passos a seguir:
1 Abra o portal Azure e escolha a opção Criar um Recurso no canto superior

esquerdo do menu.
2 Procure e selecione Service Bus e escolha Criar.
3 Forneça um nome, como azuremol e selecione o escalão de preços básico.
4 Crie um novo grupo de recursos e forneça um nome, como azuremolchap-
ter21. Verifique se o local é o mesmo dos recursos criados no capítulo 20, como
a região E.U.A. Leste. A interação entre uma fila de service bus,
uma aplicação lógica e uma aplicação de função pode ter problemas se não esti-
ver consistente com as suas localizações.
5 Aceite as outras predefinições e opte por criar o service bus.
6 Quando criar o recurso, selecione o seu grupo de recursos e escolha o service bus
que criou no passo 5.
7 Selecione Filas e adicione uma fila e um nome, como azuremol.
8 Aceite todas as outras predefinições e escolha Criar.
Com um service bus e uma fila criada, como configura um IoT Hub para utilizá-los? No
IoT Hub, define endpoints como o destino de mensagens recebidas de dispositivos IoT.
Existe um endpoint predefinido no IoT Hub para todas as mensagens que não cum-
prem os critérios definidos. Pode configurar o service bus como um endpoint para rece-
ber mensagens. Será definida uma rota que inclui critérios para os quais as mensagens
devem ser direcionadas para um endpoint. Neste exemplo, essa rota requer que qual-
quer mensagem que contenha temperatureAlert = true no corpo da mensagem seja
encaminhada para o endpoint do service bus, conforme mostrado na figura 21.8.
Um disposivo IoT envia uma

mensagem que indica que
um aviso de temperatura IoT Hub
foi gerado.
Rota Service
Disposivo IoT
bus
Msg
temperatureAlert = true
Endpoint
O service bus é configurado
como um endpoint que recebe
O IoT Hub encaminha as mensagens mensagens com um alerta de
para um endpoint específico temperatura.
se um critério for cumprido,
como um alerta de temperatura.
Figura 21.8 Como as mensagens são transmitidas a partir de dispositivos IoT para um IoT Hub, podem
ser encaminhadas para endpoints específicos com base nos critérios definidos por si. As mensagens que
contêm um alerta de temperatura no corpo da mensagem podem ser encaminhadas para um endpoint
que utiliza a fila do service bus. Em seguida, as mensagens colocadas na fila do service bus que contêm
um alerta de temperatura podem ser utilizadas para acionar coisas como aplicações lógicas
ou aplicações de função do Azure.
Experimente agora
Para configurar um IoT Hub para encaminhar mensagens de alerta de temperatura para
o service bus, conclua os passos a seguir:
1 Selecione o seu grupo de recursos do capítulo 20, como azuremolchapter20, e

escolha o IoT Hub.
2 Em Mensagens, na barra de navegação à esquerda, selecione Encaminhamento de
Mensagens e escolha adicionar um endpoint personalizado para uma fila de ser-
vice bus.
3 Forneça um nome de endpoint, como azuremol.
4 Selecione o espaço de nomes da fila do service bus, como azuremol, e, em
seguida, selecione a sua fila real.
5 Para direcionar mensagens para este endpoint, crie uma rota. Na secção Encami-
nhamento de Mensagens, na barra de navegação à esquerda, selecione Rotas e
escolha adicionar uma nova rota.
6 Forneça um nome, como temperatureAlert.
7 Escolha o endpoint do service bus que criou no passo anterior, como azuremol.
8 Para a consulta de encaminhamento, introduza o seguinte:
temperatureAlert = "true"
9 Quando estiver pronto, guarde a rota.

Agora, tem um dispositivo Raspberry Pi simulado que envia dados para o IoT Hub,
bem como uma rota para colocar mensagens que contêm um alerta de temperatura
Criação de uma aplicação lógica do Azure 325
numa fila de mensagens do service bus. Contudo, ainda não tem uma aplicação, não
podendo fazer nada com os dados na fila do service bus. O que pode querer fazer com
um alerta de temperatura? O envio de uma notificação por e-mail é um exemplo
comum. Por isso, vamos ver como pode acionar uma aplicação lógica sempre que uma
mensagem for colocada na fila do service bus.
21.3 Criação de uma aplicação lógica do Azure

Como viu durante a nossa abordagem às aplicações lógicas na secção 21.1, uma mensa-
gem recebida de uma fila do service bus pode ser utilizada como um acionador para
iniciar o processo de execução. Utiliza o IoT Hub para processar as mensagens recebi-
das de dispositivos IoT e encaminhar somente para as mensagens do endpoint da fila
do service bus que contêm temperatureAlert = true no corpo da mensagem. Com
esta abordagem, a sua aplicação lógica apenas será executada quando um alerta de
temperatura for gerado.
A figura 21.9 descreve o que a sua aplicação lógica faz. Quando uma mensagem for colo-
cada na fila do service bus, a aplicação lógica será executada e enviará um alerta por e-mail.
O IoT Hub encaminha as mensagens

para o endpoint do service bus.
Fila do service bus Aplicação lógica

IoT Hub Caixa de entrada
Msg Conector de
de e-mail
e-mail
Cada mensagem na fila
É enviado um e-mail por meio
do service bus aciona
de um conector de fornecedor
a aplicação lógica. de e-mail para avisar sobre a alta
temperatura do disposivo IoT.
Figura 21.9 Cada mensagem recebida na fila do service bus do IoT Hub aciona a aplicação lógica.
Quando a aplicação lógica for executada, enviará uma notificação por e-mail por meio de um fornecedor
de e-mail definido.
Experimente agora
Para criar uma aplicação lógica, conclua os passos que se seguem:
1 No portal Azure, escolha Criar um recurso no canto superior esquerdo do menu.

2 Procure e selecione Logic App e escolha Criar.
3 Forneça um nome, como azuremol, e selecione o seu grupo de recursos, como
azuremolchapter21. Mais uma vez, escolha o mesmo local que os seus outros
recursos IoT do capítulo 20.
4 Aceite as outras predefinições e, em seguida, escolha Criar.
5 Quando o recurso tiver sido criado, selecione o seu grupo de recursos e, em
seguida, abra a aplicação lógica. Para a opção “Adicionar acionadores comuns”,
escolha “Quando uma mensagem é recebida numa fila de Service Bus”.
6 Forneça um nome, como azuremol. Em seguida, selecione a sua fila de service
bus, como azuremol.
7 Escolha a política predefinida de service bus listada, como RootManageShare-

dAccessKey, e crie a ligação.
8 Selecione Continuar. Em seguida, escolha o nome da fila do service bus, como
azuremol.
9 Aceite as predefinições, como a frequência, para verificar se há mensagens.
10 Escolha adicionar um novo passo à aplicação lógica.
11 Para adicionar uma ação, procure o que pretende fazer. Neste exercício, procure
por e-mail. Selecione o seu fornecedor, como o Gmail - Enviar um E-mail,
Outlook.com - Enviar um E-mail ou SMTP - Enviar um E-mail, conforme mos-
Figura 21.10 Procure e selecione o fornecedor de e-mail atual, como o Gmail ou o Outlook.com.
Também pode escolher SMTP - Enviar um E-mail para configurar um fornecedor diferente
manualmente.
12 Inicie sessão no fornecedor de e-mail para autorizar o encaminhamento de

e-mails e confirme que deseja conceder permissões às aplicações lógicas para
enviar e-mails.
Criação de uma aplicação lógica do Azure 327
13 Forneça um endereço de e-mail do destinatário no qual recebe e-mails, um

assunto de e-mail, como Alerta de temperatura, e um corpo da mensagem,
como Temperatura elevada detetada no dispositivo IoT.
14 Guarde a aplicação lógica.
Vamos fazer uma pausa para analisarmos o que criou nos últimos exercícios, tal como
mostra a figura 21.11. Este design básico de aplicação sem servidor não inclui nenhum
controlo que limite o número de mensagens a serem enviadas. Na aplicação lógica, pode
definir que pretende enviar até cinco alertas de e-mail e, em seguida, esperar 30 minutos
antes de enviar mais. Como parte do processo de conceção da sua aplicação, deve esco-
lher a forma como quer ser notificado de situações como esta. Também pode configurar
a aplicação lógica para ler os dados da mensagem a partir da fila do service bus e incluir
o carimbo de data/hora da mensagem do dispositivo IoT e a temperatura real registada.
Vamos abordar a forma como podemos fazer isto no próximo exercício.
3. Uma mensagem na fila do

1. Mensagem enviada service bus aciona a aplicação
IoT Hub lógica para execução.
do dispositivo IoT
Rota Service bus Aplicação lógica
Raspberry Pi
simulado Msg Conector
Msg de e-mail
temperatureAlert = true Endpoint
4. A aplicação lógica envia uma
notificação por e-mail sobre
o alerta de temperatura.
2. O IoT Hub encaminha a mensagem E-mail
para o endpoint do service bus.
Figura 21.11 O dispositivo Raspberry Pi simulado envia uma mensagem, a cada dois segundos, ao IoT
Hub que contém as leituras do sensor de temperatura. Se a temperatura estiver acima de 30 °C, será
observado um alerta de temperatura. O IoT Hub encaminha qualquer mensagem que contenha um alerta
de temperatura para uma fila do service bus. As mensagens nesta fila acionam uma aplicação lógica do
Azure para ser executada. A aplicação lógica é ligada a um fornecedor de e-mail, como o Outlook ou
Gmail, e envia uma notificação por e-mail sobre o aviso de temperatura do dispositivo IoT.
Vejamos esta aplicação básica sem servidor em ação.
Experimente agora
Para executar o seu dispositivo Raspberry Pi simulado e testar a sua aplicação lógica,
1 Abra um browser para o dispositivo IoT Raspberry Pi simulado criado no capí-

tulo 20 (https://azure-samples.github.io/raspberry-pi-web-simulator).
2 Verifique se a cadeia de ligação do seu IoT Hub ainda está adicionada na janela
de código que configurou no capítulo 20.
3 Escolha executar a aplicação.

As leituras simuladas de temperatura e humidade do sensor são geradas a cada
dois segundos, sendo enviada uma mensagem para o IoT Hub. Pode levar algu-
mas mensagens até que uma leitura de temperatura simulada de 30 °C seja gerada
e apresentada na janela de saída.
O IoT Hub encaminha qualquer mensagem que contenha temperatu-
reAlert: true para o endpoint do service bus. Como estas mensagens são colo-
cadas na fila do service bus, a aplicação lógica recolhe-as e envia um e-mail por
meio do fornecedor definido. Em seguida, recebe um e-mail a notificá-lo de um
leitura de temperatura elevada. Este processo deve levar apenas alguns segundos
a concluir.
4 O dispositivo Raspberry Pi simulado gera mensagens a cada dois segundos. Por
isso, a menos que goste de receber muitos alertas de e-mail, pare a aplicação!
Quando recebe alertas por e-mail, a mensagem não contém muitas informações. A sua
aplicação lógica não extrai o conteúdo da mensagem do service bus nem formata as
informações. Seria ótimo se o e-mail de alerta pudesse incluir o nome do dispositivo
IoT ou a temperatura registada. Como pode processar cada mensagem e realizar algu-
mas análises? E quanto ao outro componente sem servidor do Azure que analisámos: o
Azure Function Apps?
21.4 Criação de uma aplicação de função do Azure para analisar dados

do dispositivo IoT
Para expandir a sua aplicação sem servidor atual, pode acionar uma aplicação de fun-
ção do Azure na sua aplicação lógica. Os dados da mensagem do service bus podem ser
enviados para uma aplicação de função para análise da temperatura registada. Depois,
a notificação por e-mail enviada pela aplicação lógica pode incluir informações sobre o
nome do dispositivo IoT e a temperatura registada. A interação entre a aplicação lógica
e a aplicação de função é apresentada na figura 21.12.
1. A aplicação lógica aciona

a aplicação de função
e transmite a mensagem
Função aplicação
da fila do service bus.
Aplicação lógica Receber mensagem Analisar
dados Extrair leitura de
Msg do service bus temperatura Devolver
à aplicação lógica
2. A aplicação de função
executa o código para analisar
a mensagem, extrair os dados e
devolver o valor à aplicação lógica
Figura 21.12 A aplicação lógica acionará a aplicação de função. A mensagem recebida na fila do
service bus será passada para a função. O código na aplicação de função analisa a mensagem, extrai a
temperatura e devolve esse valor para a aplicação lógica. Leva alguns milissegundos para a aplicação de
função executar este código. Por isso, o custo de execução destas tarefas de computação é equivalente
a uma fração de um cêntimo.
Criação de uma aplicação de função do Azure para analisar dados do dispositivo IoT 329
Experimente agora
Para criar uma aplicação de função e ativá-la a partir da aplicação lógica, conclua
os passos a seguir:
1 No portal Azure, selecione Criar um recurso no canto superior

esquerdo do menu.
2 Procure e selecione Function App e escolha Criar.
3 Selecione o seu grupo de recursos, como azuremolchapter21, e forneça um
nome, como azuremol. Quer estar na mesma região que os seus recursos
anteriores.
Pretende publicar código, mas saiba que, também, pode publicar uma imagem
de container Docker (capítulo 19). Nem precisa de criar uma ins-
tância de container ou qualquer infraestrutura adicional. Um container de curta
duração funciona sempre que for necessário e, depois, para.
4 Para esta aplicação básica, escolha o runtime Node.js, pois utilizamos algum
JavaScript simples.
5 Dispõe de três opções de plano de alojamento. Um plano de consumo permite que
pague por execução, sendo os recursos necessários dinamicamente atribuídos
em runtime. No caso de aplicações mais consistentes e prontas para produção,
pode utilizar um plano de alojamento premium ou dedicado que oferece um custo
fixo e mais previsível. Os planos premium oferecem funcionalidades adicionais,
como proteger a conectividade para um conjunto definido de redes virtuais do
Azure e ter sempre uma instância pronta para evitar alguns atrasos num cenário
de arranque a frio para a sua aplicação. Para este exercício, escolha um plano de
consumo.
6 Aceite as outras predefinições para criar uma conta Storage e Application Insi-
ghts com nome atribuído e, em seguida, escolha Rever + Criar.
7 Quando estiver pronto, crie a aplicação de função. Leva um ou dois minutos a
criar a aplicação de função.
8 Quando o recurso tiver sido criado, selecione o seu grupo de recursos, abra a sua
aplicação lógica do exercício anterior e selecione Editar.
9 No Logic Apps Designer, escolha adicionar um novo passo.
10 Procure e selecione Azure Functions, escolha a função criada nos passos anterio-
res (como azuremol) e, em seguida, escolha Criar Nova Função.
11 Forneça um nome de função, como analyzeTemperature.
12 Elimine qualquer código existente, substitua-o pelo código das listagens seguin-
tes e, em seguida, escolha Criar.
Este código também está disponível no repositório GitHub, em w.
Listagem 21.1 Código Javascript analyzeTemperature para uma aplicação de função

Cria a função. Cada aplicação de função JavaScript começa
com a exportação de uma função que contém um objeto Lê no conteúdo da
de contexto. Este objeto de contexto é utilizado para mensagem do service bus Cria um objeto
troca de dados. JSON de mensagens
de service bus
module.exports = function (context, req) { descodificadas
var buffer = new Buffer(req.body.ContentData, 'base64')
var decodedString = buffer.toString(); Extrai a temperatura
Descodifica a registada do
partir de var objects = JSON.parse(decodedString);
var temperature = objects["temperature"]; dispositivo IoT
base64
context.res = {
body: { Cria uma resposta
Emite a analysis: “Recorded temperature was ” + temperature + “!” a devolver à Logic
temperatura } App
para o registo };
da consola context.log("Recorded temperature was " + temperature);
context.done(); Termina a função. Cada aplicação de função
}; JavaScript deve terminar com uma chamada para
context.done, que informa a aplicação de função
de que o seu código foi concluído.
13 Novamente no Logic Apps Designer, para o seu passo de função, selecione a
caixa de texto Corpo do Pedido e escolha Mensagem do Service Bus da lista de
conteúdo dinâmico, no lado direito.
14 No Logic Apps Designer, arraste e largue para reorganizar os passos, para que a
ação Enviar um E-mail fique abaixo do passo da aplicação de função analyze-
Temperature, conforme mostrado na figura 21.13.
15 Selecione a ação Enviar um E-mail e escolha a caixa de texto do corpo da mensa-
gem de e-mail.
Figura 21.13 Arraste a ação Enviar um E-mail abaixo da função analyzeTemperature. Selecione
o final do Corpo da mensagem e a caixa de diálogo Conteúdo dinâmico será apresentada. Para inserir
o valor de temperatura computado pela aplicação de função, selecione o Corpo da mensagem na função
analyzeTemperature.
Criação de uma aplicação de função do Azure para analisar dados do dispositivo IoT 331
16 Na função analyzeTemperature, selecione a resposta Corpo, conforme mos-

17 No Logic Apps Designer, escolha Guardar.
A sua aplicação sem servidor tem muitos elementos dinâmicos. Vamos exami-
nar o que criou antes de executar o dispositivo IoT Raspberry Pi simulado, para
gerar alertas por e-mail que incluam a leitura da temperatura calculada pela apli-
cação de função. A figura 21.14 oferece uma descrição geral de todos os compo-
nentes agora em utilização na aplicação sem servidor.
4. A aplicação de função processa

dados na mensagem do service
bus, extrai e devolve o valor de
Aplicação de função
temperatura à aplicação lógica.
Código JavaScript
1. Mensagem enviada Aplicação lógica
IoT Hub
do dispositivo IoT Acionador da
aplicação de função
Rota
Raspberry Pi
simulado Conector
de e-mail E-mail
Msg
temperatureAlert = true Endpoint 5. A aplicação lógica envia uma
notificação por e-mail sobre
o alerta de temperatura.
2. O IoT Hub encaminha 3. Uma mensagem na fila do
a mensagem para service bus aciona a aplicação
o endpoint do service bus. lógica para execução.
Service bus
Msg
Figura 21.14 Conforme as mensagens são recebidas do dispositivo Raspberry Pi simulado, todas as mensagens
que contêm um alerta de temperatura são encaminhadas para o endpoint da fila do service bus. As mensagens na
fila do service bus acionam uma aplicação lógica, que passa a mensagem para uma aplicação de função. Uma
função JavaScript analisa a leitura de temperatura e devolve a mesma à aplicação lógica, que envia uma
notificação por e-mail que inclui a temperatura registada por um sensor no dispositivo IoT.
18 Abra o seu dispositivo Raspberry Pi simulado num browser e execute a aplicação.

Cada vez que o alerta de temperatura é gerado, a aplicação lógica aciona a aplica-
ção de função para extrair os dados de temperatura do corpo da mensagem e
incluí-los na notificação por e-mail. Pode demorar alguns instantes até que uma
leitura de temperatura fique acima de 30 °C, que, depois, sinaliza a mensagem
com um alerta de temperatura. Quando esse alerta for enviado e a mensagem
processada, recebe uma notificação por e-mail que informa qual era a
temperatura.
Muito bem, agora respire fundo. Fez bastante durante a sua hora de almoço!
Erros de autenticação da sua aplicação lógica até à aplicação de função

Pode ver o histórico de execuções na janela de descrição geral da sua aplicação lógica
no portal Azure. Se tiver muitos erros repetidos, selecione um dos erros para ver melhor
o que está a falhar.
Uma problema habitual é a aplicação lógica não estar automaticamente autorizada a
falar com a aplicação de função. A reimplementação da aplicação lógica corrige, normal-
mente, este erro, mas a resolução real é, talvez, adicionar o que é chamado de chave de
função ao cabeçalho da sua aplicação lógica.
Para obter esta chave, selecione a sua aplicação de função e, em seguida, escolha a
função que criou, como analyzeTemperature. Na opção Gerir, a chave de função pre-
definida pode ser visualizada e copiada. Copie esta chave, volte à sua aplicação lógica e
abra o estruturador.
Na função analyzeTemperature, escolha adicionar um parâmetro e, em seguida, adi-
cione um cabeçalho. Deseja enviar um pouco de informação no início da chamada para
a aplicação de função que envia a chave. O processo é um pouco complexo à medida
que entra no par de chaves, mas introduza x-functions-key para a chave e, em
seguida, cole a sua chave de função atual como o valor.
Leva alguns instantes para atualizar a integração da aplicação lógica/aplicação de fun-
ção. Depois disso, o histórico de execuções da aplicação lógica deve mostrar os eventos
que estão a funcionar corretamente e as notificações de e-mail devem começar a ser
entregues.
21.5 Não pare de aprender

Este capítulo continha muitos conceitos novos. De facto, os capítulos anteriores conti-
nham muitas ideias e tecnologias novas! Não se preocupe se está com dificuldades para
entender como pode começar a implementar todos estes serviços do Azure, como con-
tainers, IA e ML e computação sem servidor. Estes capítulos foram criados para mostrar-
-lhe o que é possível fazer no Azure e provar que não está limitado à execução de uma
migração "Lift and Shift" das aplicações legadas. À medida que começa a criar e executar
aplicações no Azure, aproveite a oportunidade para modernizar as aplicações e analisar
workflows de gestão ou implementação. Muitos serviços do Azure simplificam e acele-
ram o ciclo de vida da aplicação, por isso, não pense que tem de continuar com as VMs
em execução, porque isso é o que as empresas preferem utilizar.
Sim, o Azure oferece muitos serviços novos e brilhantes. Contudo, todos eles são
baseados em componentes de infraestrutura core que foram abordados na 1ª parte
deste livro. Os programadores podem começar a usar as abordagens de design de apli-
cação mais recentes que envolvem o Kubernetes ou a computação sem servidor, sendo
que os administradores podem reutilizar o seu conhecimento de datacenter on-premi-
ses com as noções básicas sobre o cloud computing e as técnicas de resolução de proble-
mas. À medida que as necessidades do seu negócio aumentam, o Azure é
capaz de oferecer suporte às mesmas.
No capítulo 1, fui sincero e honesto, ao afirmar que não abordaria todos os serviços
no Azure. Há muito mais serviços do Azure para aprender e pode aprofundar ainda
mais tudo o que analisámos no livro. Espero que tenha encontrado, pelo menos, algu-
mas áreas que lhe interessem e que o motivem a explorar um pouco mais. Os meus
favoritos incluem conjuntos de dimensionamento de virtual machines, o Cosmos DB e
o Azure Kubernetes Service.
Não pare de aprender 333
21.5.1 Materiais de aprendizagem adicionais

Posso ser tendencioso, mas acho que um ótimo lugar para continuar a aprender sobre o
Azure é em https://docs.microsoft.com/azure. Esta página web possui todos os docu-
mentos de serviço core do Azure, guias de arquitetura, recursos de referência e SDK e
exemplos. Cada serviço do Azure tem o seu próprio conjunto de inícios rápidos, tutoriais
e exemplos, além de informações conceituais e guias de procedimentos individuais.
Se levar o conteúdo a sério, pode pesquisar opções de certificação para o Azure. Os
exames individuais incluem Microsoft Azure Administrator (AZ-104), Microsoft Azure Archi-
tect Technologies and Design (AZ-303 e AZ-304) e Microsoft Azure Security Technologies
(AZ-500). Este livro e os exercícios de laboratório que concluiu abrangeram muitas das
áreas em que esses exames testam os seus conhecimentos. Contudo, precisa de estudar
algumas áreas adicionais de Azure AD e desenvolver as melhores práticas antes de fazer
os exames. O site do Microsoft Learn, em https://docs.microsoft.com/learn , fornece
alguns percursos de formação adicionais para várias opções de certificação do Azure
que o vão ajudar a preparar-se.
21.5.2 Recursos do GitHub

Ao longo deste livro, utilizou exemplos de código, modelos e aplicações experimentais
de https://github.com/fouldsy/azure-mol-samples-2nd-edition. Estes exemplos
devem permanecer atualizados à medida que novas versões da CLI do Azure são lança-
das. Para além disso, o repositório GitHub também inclui exemplos e modelos do
PowerShell para todos os exercícios. Este livro concentra-se na CLI do Azure no Azure
Cloud Shell, mas fique à vontade para explorar como é cada exercício no PowerShell
ou num modelo.
Se detetar algum problema com os exemplos, crie uma discussão no GitHub em
https://github.com/fouldsy/azure-mol-samples-2nd-edition/issues. Tudo anda
depressa no Azure e quero garantir que dispõe sempre dos exemplos mais recentes e
úteis para aprender. Sinta-se à vontade para também fazer sugestões! Todos os docu-
mentos do Azure em https://docs.microsoft.com/azure também aceitam comentários,
discussões e edições. Assim, ao explorar o restante do que é oferecido no Azure, sinta-se
à vontade para se envolver e ajudar os outros a aprender e crescer.
21.5.3 Uma reflexão final

Respire fundo e entenda que a mudança é algo natural. Novas funcionalidades e servi-
ços são lançados quase diariamente. O Azure, como todos os principais fornecedores
de cloud computing, pode parecer e estar um pouco diferente desde a última vez que
o utilizou (há uma hora). Se tiver as competências e os conhecimentos básicos funda-
mentais, que espero que tenha obtido neste livro, poderá adaptar-se e crescer com
todas as novas oportunidades oferecidas pelo Azure. Terá sempre algo novo para
aprender, e eu adoraria ouvir o que acabará por criar e executar no Azure!
Índice
Símbolos dimensionar aplicações Web verticalmente 127–
&& caracter 27 128
Objeto $ResourceGroups 276 dimensionar recursos horizontalmente 128–129
Objeto $servicePrincipalConnection 275 dimensionar VMs verticalmente 125–127
conjuntos de dimensionamento de VM 129–136
criar regras de dimensionamento automático 133–
A 136
criar 131–133
acesso interativo à consola de arranque 176 dimensionar aplicações Web 136–139
ACI (Azure Container Instance) 284, 290, 292 Aplicações Web do Azure 33–45
ACR (Azure Container Registry) 293 blocos de implementação e 35, 44–46
agendas 134, 270 criar bots com o LUIS 264–267
agentes 180 criar bots 260
aglomerado de Docker 293 criar com tráfego seguro 68–72
agrupar recursos 80–81 criar ligações de rede de acesso remoto 68–69
AKS (Azure Kubernetes Service) 284, 293–297 criar VMs 69–70
criar clusters com 294–295 utilizar agentes SSH para ligar a VMs 70–72
executar sites no Kubernetes 295–297 criar 37–42
ver informação no 294 criar aplicações Web básicas 37
alertas de métrica 182 implementar sites HTML de exemplo 39–42
alertas 178–182 descrição geral de 34–35
Amazon Web Services (AWS) 191 dimensionar 127–139
Ambientes do Serviço de Aplicações 36 executar bots com o LUIS 264–267
ambientes isolados 36 gerir 42–44
analisar atualizações 245–249 idiomas e ambientes suportados 34–35
APIs (interfaces de programação de aplicações) 31 implementar aplicação em aplicação Web com várias
APIs REST 161 instâncias em execução 140
aplicação monolítica 288 registos de diagnóstico, ver 42–44
aplicações Replicação de Azure para Azure 203
Aplicações de Funções 328–331 streaming de dados do Hub IoT do Azure para 309–
ciclos de vida de 76–77 315
Logic Apps 325–328 aplicações. Consulte também Aplicações Web do Azure
planos de serviço 38 APT (Ferramenta de embalagem avançada) 27
aplicações de balanceamento de carga 106–123 Áreas de trabalho do Log Analytics 243
Aplicações de Funções do Azure 318 armazenamento
Aplicações de Funções 328–331 armazenamento de filas 55–56
Aplicações de lógica 35, 182, 325–328 disponibilidade de 56–57
aplicações dimensionáveis 124–140 em VMs 47–50
benefícios de 124–129 armazenamento padrão vs. premium 48–49
335
336 índice
discos de dados 49–50 RTO (objetivo de tempo de recuperação) 195–196

discos temporários 49–50 restaurar VMs 198–201
opções de colocação de discos em cache 50 concluir restauro de VMs 199–201
no Azure 18 restauro ao nível do ficheiro 199
redundância 56–57 Azure Bastion 24, 115
armazenamento (vDisk) 11 Azure Cloud Shell 12–13
Armazenamento de blobs 52 Azure Container Instance. Consulte ACI
Armazenamento de ficheiros 53 Azure Container Registry. Consulte ACR
Armazenamento de filas 53, 55–56 Azure Event Grid 320–321
Armazenamento de tabelas 52 etiquetas Azure Firewall 238
agrupar recursos com 80–81 Azure Front Door 163–164
gerir recursos com 80–81 Azure IoT (Internet das Coisas) 300–316
Armazenamento do Azure 47–57 criar aplicações de funções para analisar o dispositivo
adicionar discos a VMs 50–52 dados 328–331
armazenamento de VMs 47–50 descrição geral de 300–302
armazenamento padrão vs. premium 48–49 Hub, gestão centralizada de dispositivos com 303–
discos de dados 49–50 309
discos temporários 49–50 integração com Service Bus 322–325
opções de colocação de discos em cache 50 revisão de componentes 315
benefícios de 52–57 streaming de dados do hub para aplicações
armazenamento de filas 55–56 Web 309–315
armazenamento de tabelas 53–54 Azure IoT Edge 304–305
disponibilidade de armazenamento 56–57 Azure Key Vault 216–233, 304
redundância 56–57 armazenar chaves de encriptação em 211–213
armazenamento georredundante (GRS) 56 criar certificados 229–232
armazenamento georredundante com acesso de leitura descrição geral de 211
(RA-GRS) 57 injetar certificados 229–232
armazenamento localmente redundante (LRS) 56 MSIs (identidades de serviço geridas) 221–229
Armazenamento localmente redundante (LRS) 56 proteger informações nas clouds 216–221
armazenar modelos 87 cofres de software e HSMs 217–218
ativos, em Automatização do Azure 272–274 criar cofres de chaves e segredos 219–221
atribuição dinâmica 62 Azure Kubernetes Service. Consulte AKS
atribuição estática 63 Azure Logic Apps 318
atualizações JIT (just-in-time) 237–249 Azure Monitor 243
atualizações 234–249 Azure PowerShell 11, 13, 31, 81–82, 161
Gestão de Atualizações do Azure 241–249 Azure Resource Manager 75–89
OMS (Operations Management Suite) 243 abordagem a 75-81
rever e aplicar atualizações 245–249 gerir e agrupar recursos com etiquetas 80–81
JIT (just-in-time) 237–241, 249 projetar em função do ciclo de vida da
NSGs do Centro de Segurança do Azure 234 aplicação 76–77
Auto Swap 46 proteger e controlar recursos 78–79
Automatização do Azure 243, 269–283 proteger recursos com bloqueios 79–80
ativos 272–274 modelos para 81–87
criar contas no 271–272 armazenar 87
descrição geral de 179, 269–274 criar vários tipos de recursos 84–85
PowerShell DSC 278–282 criar 82–84
definir 280–282 ferramentas para criar 85–86
Servidores pull de Automatização do Azure Azure Service Bus 310, 321–322
e 280–282 Azure Service Fabric 289
runbooks 272–274 Azure Site Recovery 201–204, 243
executar 276–277
exemplo de 274–277
ver a saída de 276–277 B
AWS (Amazon Web Services) 191
Azure AD (Azure Active Directory) 222 balanceador de carga da Internet 108
Azure Application Insights 180 balanceador de carga interno 108
Azure Backup 191–201, 243 balanceadores de carga 94
Horários de cópia de segurança 196–198 componentes de 106–119
políticas e retenção 193–196 atribuir grupos de VMs a conjuntos de back-
RPO (objetivo de ponto de recuperação) 194–195 end 116–119
índice 337
criar conjuntos IP de front-end 108–110 colocação em cache de leitura/escrita 50

definir a distribuição de tráfego com regras do comando az cosmosdb show 152
balanceador de carga 112–114 comando az group create 131
encaminhar o tráfego direto com regras de Tradução comando az keyvault create 212
de Endereços de Rede 114–116 comando az keyvault secret show 221
pesquisas de estado de funcionamento 110–112 comando az storage account create 210
criar e configurar VMs com 119–122 comando az vm create 51, 95, 197
definir a distribuição de tráfego com regras 112–114 comando az vm disk attach 51
em ação 120–122 comando az vm list-sizes 127
bases de dados comando az vm resize 127, 129
dimensionar 143–144 comando az vm show 105
em Cosmos DB comando az vm 95
adicionar redundância global a 149–152 comando git push azure master 156
criar 145, 149–152 comando git push dev master 45
povoar 145–149 comando ssh-keygen 21
Bases de dados estruturadas SQL 142 Comandos, envolver linhas longas 40
blocos de implementação 44–46 computação sem servidor 317–333
bloqueios 79–80 criar aplicações de funções para analisar dados do
Botão de Controlo de Acesso (IAM) 79 dispositivo IoT 328–331
Botão Implementar no Azure 98 criar aplicações lógicas 325–328
bots para aplicações Web plataformas de mensagens 319–325
criar com o LUIS 264–267 Azure Event Grid 320–321
criar 260 Azure Service Bus 321–322
executar com o LUIS 264–267 criar service bus 322–325
browsers, criar VMs em 22 descrição geral de 317–319
Armazenamento do Azure 18 Hubs de Eventos do Azure 321–322
tamanhos de VM 17 integrar o Service Bus nos hubs IoT 322–325
Building the Web of Things (Guinard e Trifa) 315 plataformas de mensagens 319–325
recursos do GitHub 333
condições de desempenho, alertas para 181–182
C conectividade de rede (vNIC) 11
configurar
capturar pacotes de rede 186–188 pesquisas de estado de funcionamento 110–112
caráter de barra invertida 40, 68 VMs com balanceadores de carga 119–122
cartões de interface 61 conjunto de dimensionamento de uma única VM 130
CD (entrega contínua) 75 conjunto de IPs de back-end, em balanceadores de
Centro de Segurança do Azure 234, 249 carga 107
Certificado SSL 207 conjuntos
certificados SSL personalizados 207 back-end 116–119
certificados 270 conjuntos IP de front-end 108–110
criar 229–232 conjuntos de back-end 107, 116–119
injetar 229–232 conjuntos de dimensionamento, para VMs 129–136
chave privada, do par de chaves SSH 71 criar regras de dimensionamento automático 133–
chave pública, do par de chaves SSH 20–22, 71 136
chaves criar 131–133
armazenar chaves de encriptação no Azure Key Conjuntos de Disponibilidade 91
Vault 211–213 distribuir VMs em 98–101
criar cofres de chaves 219–221 redundância de VMs com 96–102
CI (integração contínua) 75 atualizar domínios 97–98
ciclos de vida de aplicações 76–77 domínios de falha 96–97
cientistas de dados, ferramentas para 257–259 ver distribuição de VMs em 101–102
CLI (interface de linha de comandos) 12 conjuntos de IP 107
CLI do Azure 7, 12–13, 28, 31, 81–82, 152, 161 conjuntos IP de front-end 107–110
clouds, proteger informações em 216–221 conta do Azure, criar 5–7
cofres de software e HSMs 217–218 containers 146, 284–299
criar cofres de chaves e segredos 219–221 ACI (Azure Container Instance) 289–292
clusters com AKS 294-295 coleções 146 AKS (Azure Kubernetes Service) 293–297
código de fonte 5 criar clusters com 294–295
cofres de software 217–218 executar sites no Kubernetes 295–297
cofres, chave 219–221
338 índice
descrição geral de 284–288 dimensionar verticalmente 127

contas redimensionar VMs 126–127
em Automatização do Azure, criar 271–272 VMs verticalmente 127
em Cosmos DB disco rígido virtual (VHD) 53
adicionar redundância global a 149–152 discos
criar 145–149, 152 adicionar a VMs 50–52
povoar 145–149 discos de dados 49–50
contas Run As 272 opções de colocação em cache 50
contratos de nível de serviço (SLAs) 247 temporários 49–50
contratos de nível de serviço (SLAs) 247 discos de dados 49–50
controlar discos geridos 18
recursos 78–79 discos HDD padrão 18
tráfego com NSGs 64–68 discos SSD premium (drive de estado sólido) 18-19
associar NSGs a sub-redes 66–67 discos temporários 49–50
criar NSGs 64–65 DKIM (DomainKeys Identified Mail) 160
criar regras de filtragem de NSGs 67–68 DNS do Azure (Serviço de Nomes de Domínio) 158–
controlo de acesso baseado em funções (RBAC) 78, 162
161, 211 Docker 284, 287
cópias de segurança incrementais 193 Dockerfiles 291–292
cópias de segurança 191–204 DomainKeys Identified Mail (DKIM) 160
Azure Backup 191–201 domínios
Horários de cópia de segurança 196–198 atualizar 97–98
políticas e retenção 193–196 falha 96–97
restaurar VMs 198–201 reais, delegar ao DNS do Azure 160–162
Azure Site Recovery 201–204 domínios de atualização 96
Cosmos DB 141–157 domínios de falha 96–97
aceder aos dados distribuídos globalmente 152–156 DR (recuperação após desastre) 201
adicionar redundância global a 149–152 DSC (Desired State Configuration) 179, 278, 282–283
criar contas e bases de dados 145–152 DSVMs (máquinas virtuais de ciência de dados) 258
criar e povoar bases de dados 145–149
descrição geral de 141–144
bases de dados estruturadas (SQL) 142 E
bases de dados não estruturadas (NoSQL) 142–143
dimensionar bases de dados 143–144 Editor do Visual Studio 85-86
implementar aplicação Web com 156-157 eliminar VMs protegidas 205
CPU virtual (vCPU) 11 encaminhamento de desempenho 163–164
credenciais 270 encaminhamento geográfico 163–164
encaminhamento global, com o Gestor de
Tráfego 162–173
D criar perfis do Gestor de Tráfego 164–166
distribuição global de tráfego para a instância mais
dados distribuídos globalmente 152–156 próxima 167–173
dados estruturados 144 encaminhar o tráfego direto com regras de Tradução de
dados inativos 208 Endereços de Rede 114–116
dados não estruturados 144 encriptação 206–215
DC/OS (sistema operativo de datacenter) 293 armazenar chaves no Azure Key Vault 211–213
DDoS (denial of service distribuído) 182 de VMs 211–214
delegar domínios reais 160–162 descrição geral de 206–208
denial of service distribuído (DDoS) 182 inativo 208–209
dependências 82 SSE (Encriptação do Serviço de
dependsOn 104 Armazenamento) 209–210
deteção de pontos finais 153 endereços de IP privados 108
diagnóstico de arranque 175–177 endereços de IP públicos 20, 62–64, 94, 108
dimensionar endereços IPv4 109
Aplicações Web endereços IPv6 109
descrição geral de 136–139 entrega contínua (CD) 75
verticalmente 127–128 erros de autenticação 332
base de dados 143–144 estado de negação 238
recursos horizontalmente 128–129 Estrutura de proteção do remetente (SPF) 160
VMs verticalmente 125–127 ETW (Rastreio de Eventos para o Windows) 180
índice 339
Exemplo do Google Maps 256 grupos de recursos 315

ExpressRoute 19, 183 grupos de segurança de rede. Consulte NSGs
Extensão de script personalizado 179 Guinard, Dominique D. 315
extensões 305
H
F
Hashicorp 86
Federal Information Processing Standard (FIPS) 218 Hora Universal Coordenada (UTC) 196
ferramentas de terceiros 86 horário de produção 46
Ficheiro MOF (Managed Object Format) 280 Horários de cópia de segurança 196–198
ficheiro MOF (Managed Object Format) 280 host de bastião 23–24
filtrar 67–68 HPC (computação de alto desempenho) 267
FIPS (Federal Information Processing Standard) 218 HSMs (módulos de segurança de hardware) 212,
fluxos de IP, verificar 183–184 217–218
fórum, para este livro 5 HTTP 20, 168, 206
FQDN (nome de domínio totalmente qualificado) 63 HTTPS 20, 168, 206
função concat, Gestor de Recursos 85 Hubs de Eventos do Azure 321–322
função copyIndex() 84, 98, 102, 104 Hyper-V 15
função de Administrador de acesso do utilizador 78
função de Contribuidor de Máquina Virtual 79
função de Contribuidor do Site 79 I
função de Contribuidor 78
função de copiar, Gestor de Recursos 84 IA (inteligência artificial) 253–268
função de Proprietário 78 Bots de Aplicação Web
Função de Trabalho Híbrida de Automatização 272 criar com o LUIS 264–267
funcionamento em rede. Consulte Rede do Azure criar 260
Gardner, Lyza Danger 315 executar com o LUIS 264–267
LUIS 261 – 264
G machine learning e 254–259
Serviços Cognitivos do Azure 259–260
Gateway de Aplicação do Azure 108 IaaS (Infraestrutura como Serviço) 9, 14, 33–34
Gateway de Aplicação 107–108 IaC (infraestrutura como código) 82
Gerente de configuração local (LCM) 278 identidades geridas atribuídas pelo sistema 222
Gestão de Atualizações do Azure 241–249 identidades geridas atribuídas pelo utilizador 222
OMS (Operations Management Suite) 243 idiomas suportados 34–35
rever e aplicar atualizações 245–249 IIS (Serviços de informação Internet) 29, 233
Gestor de Tráfego IIS (Serviços de informação Internet) 29, 233
Área de resolução de problemas 183 Imagens, VM 16–17
criar perfis em 164–166 implementar sites HTML 39–42
distribuição global de tráfego para as instâncias mais informações de falha de sistema 180
próximas 167–173 infraestrutura como código (IaC) 82
encaminhamento global e resolução com 162–173 Infraestrutura como Serviço (IaaS) 9, 14, 33
implementar aplicações Web em 174 injetar certificados 229–232
Gestor de Tráfego do Azure. Consulte Gestor de Tráfego instalar comando 27
Git 12 instalar servidores Web 24–27
formação 37 instâncias, criar 290–292
implementar sites HTML de exemplo com 39–42 integração contínua (CI) 75
palavra-passe para, repor 314 inteligência artificial. Consulte IA
GitHub interface da linha de comandos (CLI) 12
Automatização do Azure e controlo de origem intervalo de pesquisa de pontos finais 168
com 274 Intervalos de endereços IP 60
conta para, criar 7
descrição geral de 39
Exemplos de início rápido do Azure em 87 J
recursos 333
repositório para este livro 5 Janela Descrição Geral da Gestão de Atualizações 243
GPU (unidade de processamento gráfico) 267 Janela descrição geral do centro de segurança 236
GRS (armazenamento georredundante) 56 JavaScript on Things (Gardner) 315
340 índice
Jq parser 226 inteligência artificial e 254, 256

JSON (JavaScript Object Notation) 82–83, 86 LUIS (Language Understanding Intelligent
JWT (JSON Web Token) 226 Service) 261–264
relação com a inteligência artificial 257–259
Serviços Cognitivos do Azure 259–260
K Modelos de Início Rápido do Azure 7
modelos, para o Azure Resource Manager 81–87
Kubernetes em Ação (Luksa) 298 armazenar 87
Kubernetes 293, 295–299 criar vários tipos de recursos 84–85
Consulte também AKS criar 82–84
ferramentas para criar 85–86
Modo Apenas aplicar, DSC 279
L Modo Aplicar e corrigir automaticamente, DSC 279
Learn Docker in a Month of Lunches (Stoneman) 297 Modo Aplicar e monitorizar, DSC 279
Learn Git in a Month of Lunches (Umali) 37 modo baseado na porta, pesquisas de estado de
Ligação RDP (Protocolo de área de trabalho funcionamento 110
remota) 20, 71 modo de afinidade de sessão 112–113
Ligação RDP (Protocolo de área de trabalho Modo HTTP baseado no caminho, sondagens de
remota) 20, 71 funcionamento 110
ligações de rede de acesso remoto 68–69 módulo nx 283
ligações 270 módulos 270
Linguagem de programação Perl 34 monitorizar 175
linguagem de programação Python 28, 34 alertas 178–182
Linux diagnóstico da VM 175–177
executar aplicações Web em 34 métricas de desempenho 178–182
utilizar DSC com 282-283 Observador de Rede do Azure 182–188
Local Configuration Manager (LCM) 278 capturar pacotes de rede 186–188
localizações de pontos finais 153 ver regras do NSG eficazes 184–186
LTS (Suporte a Longo Prazo) 22 verificar fluxos de IP 183–184
LUIS (Language Understanding Intelligent Service) MSIs (identidades de serviço geridas) 221–229
criar bots de Aplicação Web com 264–267
executar bots de Aplicação Web com 264–267 N
Luksa, Marko 298 NAT (Tradução de endereços de rede) 107, 114–116
NICs (placas de interface de rede) 61, 117
Nível de NIC virtual 185
M Nível de sub-rede 185
machine learning. Consulte ML Nível do grupo de segurança da aplicação 185
máquinas virtuais. Consulte VMs NoSQL (bases de dados não estruturadas) 142–143
Marketplace, Azure 7 NSGs (grupos de segurança de rede) 20
materials de formação 333 associar a sub-redes 66–67
Maven 12 criar regras de filtragem 67–68
memória (vRAM) 11 criar 64–65, 118
mensagens de erro 31 descrição geral de 112
Message Analyzer da Microsoft 186 no Centro de Segurança do Azure 234
Message Analyzer, Microsoft 186 proteger e controlar o tráfego com 64–68
Método de encaminhamento ponderado, Gestor de ver regras efetivas 184–186
Tráfego 163
Método de encaminhamento prioritário, Gestor de
Tráfego 163 O
métricas de desempenho 178–182, 188 objetivo de tempo de recuperação (RTO) 193
ML (machine learning) 253–268 Observador de Rede do Azure 182–188
Bots de Aplicação Web capturar pacotes de rede 186–188
criar com o LUIS 264–267 ver regras do NSG eficazes 184–186
criar 260 verificar fluxos de IP 183–184
executar com o LUIS 264–267 Observador de Rede 184
descrição geral de 255–256 obter servidores 280–282
ferramentas para cientistas de dados 257–259 OMS (Operations Management Suite) 243, 272
índice 341
Opção de desmontagem de discos 199 Portal do Azure 12

opção Teste no Chat na Web 266 povoar bases de dados 145–149
orquestrador de containers 293 PowerShell DSC (Desired State Configuration) 278–
282
definir 280–282
P Servidores pull de Automatização do Azure e 179,
280–282
PaaS (Plataforma como Serviço) 10, 33, 37, 137 PowerShell. Consulte Azure PowerShell
pacotes de rede 186–188 principal de serviço 222
Papel do leitor 78 projeto Let’s Encrypt 207
parâmetro -A 121 propriedade Message Text 56
parâmetro de intervalo, sondagens de proteger
funcionamento 111 recursos 78–79
parâmetro de limite, pesquisas de estado de tráfego com NSGs 64–68
funcionamento 111 associar NSGs a sub-redes 66–67
--parâmetro de zona 95 criar NSGs (grupos de segurança de rede) 64–65
parâmetro enableHttpsTrafficOnly 210 criar regras de filtragem de NSGs 67–68
parâmetro--no-self-perms 220 proteger recursos 79–80
parâmetros 82, 84, 89 protocolo de monitorização de pontos finais 168
pares de chaves SSH 20–22
pares de chaves 20
pedido de curl 226-227 Q
perfis, no Gestor de Tráfego 164–166
pesquisas de estado de funcionamento quotas predefinidas 102
configurar 110–112 quotas 102, 132
criar 110–112
descrição geral de 107
PHP 34 R
placas de interface de rede (NICs) 61
Plano de serviço básico 36 RA-GRS (armazenamento georredundante com acesso
Plano de serviço gratuito/partilhado 36 de leitura) 57
Plano de serviço padrão 36 ramos, no Git 41
Plano de serviço premium 36 Raspberry Pi 306–309
planos de serviço para aplicações 35–38 RBAC (controlo de acesso baseado em funções) 78,
planos do Serviço de Aplicações 35–38 161, 184, 211
Plataforma Azure readLocations 153
armazenar em 18 recuperação após desastre (DR) 201
descrição geral de 8–13 recursos de rede 94–95
ferramentas de gestão 11–13 recursos 5, 7
Azure Cloud Shell 12–13 com etiquetas
Azure PowerShell 13 agrupar 80–81
CLI do Azure local 13 gerir 80–81
Portal do Azure 12 controlar 78–79
resolução de problemas 31–32 dimensionar horizontalmente 128–129
virtualização em 10–11 limpar 30
Plataforma como Serviço (PaaS) 10, 33 proteger com bloqueios 79–80
plataformas de mensagens 319–325 proteger 78–79
Azure Event Grid 320–321 rede anycast 160
Azure Service Bus 321–322 Rede do Azure 58–72
criar service bus 322–325 componentes de rede virtual 58–64
Hubs de Eventos do Azure 321–322 criar redes virtuais 59
integrar o Service Bus nos hubs IoT 322–325 criar sub-redes 59
política de cache só de leitura 50 endereços IP públicos 62–64
políticas 193–196 placas de interface de rede virtual 61
RPO (objetivo de ponto de recuperação) 194–195 resolução DNS 62–64
RTO (objetivo de tempo de recuperação) 195–196 criar aplicações Web de exemplo com tráfego
ponto final de eventos 310, 312 seguro 68–72
pontos de recuperação 193 criar ligações de rede de acesso remoto 68–69
pontos finais do serviço 146 criar VMs 69–70
pontos finais 323 utilizar agentes SSH para ligar a VMs 70–72
342 índice
proteger e controlar o tráfego com NSGs 64–68 RPO (objetivo de ponto de recuperação) 194–195
associar NSGs a sub-redes 66–67 RTO (objetivo de tempo de recuperação) 195–196
criar NSGs 64–65 RPO (objetivo de ponto de recuperação) 193–195
criar regras de filtragem de NSGs 67–68 RTO (objetivo de tempo de recuperação) 193,
redes privadas virtuais (VPNs) 19, 36, 38 195–196
redes virtuais 58–64 runbooks, para Automatização do Azure 274–277
cartões de interface 61 descrição geral de 272–274
criar sub-redes 59 executar 182
criar 59 executar 276–277
endereços IP públicos 62–64 ver a saída de 276–277
resolução DNS 62–64
redimensionar VMs 126–127
redundância S
benefícios de 90–91
de VMs com Conjuntos de Disponibilidade 96–102 SaaS (Software como Serviço) 10
descrição geral de 56–57 segredos
redundância de infraestrutura, com Zonas de criar 219–221
Disponibilidade 95 obter a partir de VMs com MSIs 224–229
criar recursos de rede em Zonas de segurança 115
Disponibilidade 94–95 separação de funções 62
criar VMs em Zonas de Disponibilidade 95 Server Message Block (SMB) 53
redundância global 149–152 Service Bus
redundância. Consulte também redundância de criar 322–325
infraestrutura, com Zonas de Disponibilidade integrar com os hubs IoT 322–325
registos de alias 160 servicePrincipalName 224
registos de diagnóstico 42–44 serviço Azure Machine Learning 258
registos de host IPv4 160 serviço Content Moderator 259
registos de host IPv6 160 Serviço de decisão 259
registos de início de autoridade (SOA) 160 Serviço de idioma 259
registos de serviço 160 Serviço de metadados da instância (IMDS) 222
registos de servidor de nomes 160 Serviço de metadados da instância (IMDS) 222
registos indicadores 160 Serviço de pesquisa 259
registos. Consulte registos de diagnóstico Serviço de reconhecimento de orador 259
Regra AllowAzureLoadBalancerInBound 67 Serviço facial 259
Regra AllowVnetInBound 67 serviço Imagem Digitalizada 259
regra default-allow-ssh 241 Serviço personalizado 259
Regra DenyAllInBound 67, 184 serviço Pesquisa Personalizada do Bing 259
regras de dimensionamento automático 133–136 serviço Sugestão Automática do Bing 259
Regras DenyAll 185 serviço Tradução de Texto 259
remotas 41 serviço Visão 259
resolução de problemas 175 Serviços Cognitivos do Azure 259–260
alertas 178–182 serviços com redundância entre zonas 93
diagnóstico da VM 175–177 Serviços de voz 259
métricas de desempenho 178–182 Serviços zonais 93
Observador de Rede do Azure 182–188 Servidor Web LAMP 27, 72
capturar pacotes de rede 186–188 servidores de bases de dados, escala vertical para 126
ver regras do NSG eficazes 184–186 servidores Web
verificar fluxos de IP 183–184 em ação 28–29
Plataforma Azure 31–32 instalar 24–27
resolução DNS 62–64, 158 shell Bash 12
resolução, com o Gestor de Tráfego 162–173 símbolo de acento circunflexo 27
criar perfis do Gestor de Tráfego 164–166 sinks 180
distribuição global de tráfego para a instância mais sistema de numeração baseado em 99
próxima 167–173 sistema operativo de datacenter (DC/OS) 293
REST (Representational State Transfer) 31 sistemas de numeração, baseados em zero 99
restaurar máquinas virtuais 198–201 sites HTML, implementar 39–42
concluir restauro de VMs 199–201 sites, executar no Kubernetes 295–297
restauro ao nível do ficheiro 199 SMB (Server Message Block) 53
restauro ao nível do ficheiro 199 Software como serviço (SaaS) 10
retenção 193–196
índice 343
SONiC (Software for Open Networking in the TTL (Time to Live) 167
Cloud) 11
SPF (Estrutura de proteção do remetente) 160
SQL (Linguagem de consulta estruturada) 53, 142 U
SSDs de alto desempenho 18
SSDs padrão 18–19 Ubuntu Linux 14, 26
SSE (Encriptação do Serviço de Umali, Rick 37
Armazenamento) 209–210 UTC (Hora universal coordenada) 196
SSH (Secure Socket Shell) Utilitários do Azure DevOps 7
agentes para ligar a VMs 70–72
ligar a VMs com 24–27
streaming de dados do hub IoT 309–315 V
streaming de ficheiros de registo 43 variáveis 82, 84, 89, 271
Structured Query Language (SQL) 53, 142 variável access_token 226
sub-redes variável connectionString 307
associar NSGs a 66–67 variável database_password 228
criar 59 variável iotconnectionstring 312
Suporte a Longo Prazo (LTS) 22 verificar fluxos de IP 183–184
VHD (disco rígido virtual) 53
virtual machines de ciência de dados (DSVMs) 258
T virtualização 10–11
tamanhos de VM com otimização de memória 17 VM da série B 18
tamanhos de VM de utilização geral 17 VMs (máquinas virtuais)
Tamanhos de VM GPU 17 adicionar discos a 50–52
tamanhos de VM otimizados para armazenamento 17 armazenamento 47–50
tamanhos de VM otimizados para computorização 17 armazenamento padrão vs. premium 48–49
tecla de função 332 discos de dados 49–50
Terraform 86 discos temporários 49–50
teste 41 opções de colocação de discos em cache 50
Time to Live (TTL) 167 atribuir grupos a conjuntos de back-end 116–119
tipos de recursos 84–85 configuração 15–20
Tipos de registo de DNS do Azure 160 Armazenamento do Azure 18–19
token de assinatura de acesso partilhado (SAS) 87 Imagens de VM e 16-17
token de SAS (assinatura de acesso partilhado) 87 redes virtuais 19–20
tráfego tamanhos de VM 17–18
definir a distribuição com regras do balanceador de configurar com balanceadores de carga 119–122
carga 112–114 conjuntos de dimensionamento 129–136
distribuir globalmente para as instâncias mais criar regras de dimensionamento automático 133–
próximas 167–173 136
encaminhar o tráfego direto com regras de Tradução criar 131–133
de Endereços de Rede 114–116 instalar aplicações em 139
proteger e controlar com NSGs 64–68 criar 14–32, 69–70
associar NSGs a sub-redes 66–67 com balanceadores de carga 119–122
criar NSGs 64–65 de browsers 22
criar regras de filtragem de NSGs 67–68 em Zonas de Disponibilidade 95
tráfego de rede limpar os recursos 30
encaminhar 158–174 redução de custos e 18
gerir 158–174 resolução de problemas do Azure 31–32
tráfego direto, encaminhar 114–116 Windows VM 29–30
tráfego seguro, criar aplicações Web com 68–72 desalocar 30
criar ligações de rede de acesso remoto 68–69 diagnóstico 175–177
criar VMs 69–70 dimensionar verticalmente 125–127
utilizar agentes SSH para ligar a VMs 70–72 dimensionar verticalmente 127
tráfego Web distribuir pelos Conjuntos de Disponibilidade 98–
criar regras para permitir 28 101
permitir o alcance às VMs 27–29 eliminar 30
Transferência de estado representacional (REST) 31 encriptação de 211–214
Trifa, Vlad M. 315 armazenar chaves de encriptação no Azure Key
troca com pré-visualização 46 Vault 211–213
344 índice
laboratório 214-215 VMs em paralelo 102

extensões de diagnóstico 178 VMs em série 102
implementar com modelos 102–105 VMs protegidas, eliminar 205
instalar servidores Web 24–27 VMware 15
ligar a 120–122 VPNs (redes privadas virtuais) 19, 36, 38, 183
com agentes SSH 70–72
com SSH 24–27
obter segredos a partir de MSIs 224–229 W
par de chaves SSH, criar para autenticação 20–22
permitir que o tráfego Web alcance 27–29 webhooks 274
criar regras para permitir o tráfego na Web 28 WebSockets 312
ver o servidor Web em ação 28–29 Windows, executar aplicações Web no 34
redimensionar 126–127
redundância com Conjuntos de Disponibilidade 96–
102 Z
atualizar domínios 97–98
domínios de falha 96–97 Zonas de Disponibilidade 91
restaurar 198–201 criar recursos de rede em 94–95
concluir restauro de VMs 199–201 criar VMs em 95
restauro ao nível do ficheiro 199 redundância de infraestrutura com 95
tamanhos de 17 ZRS (armazenamento com redundância entre
ver a distribuição pelos Conjuntos de Disponibilidade zonas) 56
101–102
By developers, Get technical articles, sample
code, and information on
● Keep up on the latest
technologies
for developers upcoming events in ● Connect with your peers
Microsoft.Source, the at community events Sign up

curated monthly developer ● Learn with
Microsoft.Source newsletter community newsletter. hands-on resources

Original

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Original

Uploaded by

Copyright:

Available Formats

Segunda Edição

Aprofunde 21 Obtenha uma base sólida em Azure com as lições

lições do Azure do Azure e use o seu crédito de 200 USD para

Mais livros com aprendizagem durante os almoços de um mês

Ler livros da Manning GRATUITAMENTE no liveBook

• Registe-se para obter uma conta GRATUITA no LiveBook em livebook.manning.com.

Da primeira edição do Conhecer o Azure num mês de almoços de Iain Foulds:

"Qualquer programador ocupado precisa de conhecer o Azure."

©2020 pela Manning Publications Co. Todos os direitos reservados.

Reconhecendo a importância de preservação do que foi escrito, é política da Manning imprimir os

Manning Publications Co. Editor de aquisições: Mike Stephens

Parte 1 Serviços core do Azure..................................1

práticos 5 Código fonte e materiais suplementares 5

1.3 Criar o seu ambiente de laboratório 5

bónus: criação de uma conta do GitHub gratuita 7

2 Criar uma virtual machine 14

Tamanhos de VM 17 Azure Storage 18 Redes virtuais 19

2.2 Criação de um par de chaves SSH para autenticação 20

2.5 Permitir que o tráfego Web chegue à VM 27

2.6 Laboratório: criar uma VM Windows 29

3 Azure Web Apps 33

versões com blocos de implementação 35 Planos de serviço de

4 Introdução ao Azure Storage

Discos do SO 48 Discos temporários e discos de dados 49

Opções de colocação de discos em cache 50

4.2 Adicionar discos a uma VM 50

Disponibilidade e redundância de armazenamento 56

4.4 Laboratório: Explorar o Azure Storage 57

5 Noções básicas do Azure Networking 58

virtual 61 Endereço IP público e resolução de DNS 62

5.2 Proteger e controlar o tráfego com grupos de segurança

Criar um grupo de segurança de rede 64 Associar um grupo de

segurança de rede a uma sub-rede 66 Criar regras de filtragem de

grupos de segurança de rede 67

VMs 69 Utilizar o agente SSH para se ligar às suas VMs 71

5.4 Laboratório: instalar e testar o servidor Web LAMP 72

Parte 2 Elevada disponibilidade

e controlar recursos 78 Proteger recursos com bloqueios 79

de recurso 84 Ferramentas para criar os seus próprios

modelos 85 Armazenar e utilizar modelos 87

6.3 Laboratório: implementar recursos do Azure a partir de

7.2 Redundância de infraestrutura com Zonas de

VMs por um Conjunto de Disponibilidade 97 Ver a distribuição de

VMs por um Conjunto de Disponibilidade 100

8 Aplicações de balanceamento de carga 106

do estado de funcionamento 110 Definir a distribuição de tráfego com

regras do balanceador de carga 112 Encaminhar o tráfego direto com

regras de Tradução de Endereços de Rede 114 Atribuir grupos de VMs

a conjuntos de back-end 116

8.2 Criar e configurar VMs com o balanceador de carga 119

9 Aplicações dimensionáveis 124

aplicações Web verticalmente 127 Dimensionar recursos

9.3 Dimensionar uma aplicação Web 137

10 Bases de dados globais com Cosmos DB

Bases de dados estruturadas (SQL) 142 Bases de dados

não estruturadas (NoSQL) 142 Dimensionar bases de

dados 143 Como reunir tudo com o Cosmos DB 144

redundância global a uma base de dados Cosmos DB 149

11 Gerir o tráfego e o encaminhamento de rede

1.2 Delegar um domínio real ao DNS do Azure 160

tráfego para a instância mais próxima 167

12 Monitorizção e resolução de problemas 175

12.3 Observador de Rede do Azure 182

Capturar pacotes de rede 186

Parte 2 Elevada disponibilidade

Infraestrutura Plataforma Soware

Host sico no Azure