Azure para Arquitetos
Azure para Arquitetos
Azure para Arquitetos
Terceira edição
● Treinamento gratuito
Azure grátis
Experimente o Azure grátis >
Prefácio i
Computação na nuvem ........................................................................................... 2
Vantagens da computação na nuvem .......................................................................... 3
Por que adotar a computação na nuvem? .................................................................. 3
Paradigmas de implantação no Azure ......................................................................... 5
Noções básicas sobre o Azure ................................................................................ 6
O Azure como nuvem inteligente .......................................................................... 8
Azure Resource Manager ........................................................................................ 8
Arquitetura do ARM ........................................................................................................ 9
Por que usar o ARM? ...................................................................................................... 9
Vantagens do ARM ........................................................................................................ 10
Conceitos do ARM ......................................................................................................... 11
Virtualização ........................................................................................................... 14
Contêineres ............................................................................................................ 15
Docker ..................................................................................................................... 17
Interação com a nuvem inteligente .................................................................... 17
O portal do Azure .......................................................................................................... 17
PowerShell ..................................................................................................................... 18
A CLI do Azure ............................................................................................................... 18
A API REST do Azure ...................................................................................................... 19
Modelos do ARM ........................................................................................................... 19
Resumo ................................................................................................................... 20
Capítulo 2: Disponibilidade, escalabilidade
e monitoramento da solução do Azure 23
Automação ........................................................................................................... 104
Automação do Azure ........................................................................................... 105
Arquitetura da Automação do Azure ................................................................ 105
Automação de processos .......................................................................................... 107
Gerenciamento de configuração ............................................................................. 108
Gerenciamento de atualizações .............................................................................. 109
Conceitos relacionados à Automação do Azure .............................................. 109
Runbook ..................................................................................................................... 109
Contas de execução ................................................................................................... 110
Trabalhos ................................................................................................................... 111
Ativos ........................................................................................................................... 112
Credenciais ................................................................................................................. 112
Certificados ................................................................................................................. 113
Criar uma entidade de serviço usando credenciais de certificado ..................... 115
Conexões ..................................................................................................................... 116
Criação e execução do runbook ......................................................................... 118
Runbooks pais e filhos .............................................................................................. 119
Criar um runbook ...................................................................................................... 120
Usar módulos Az .................................................................................................. 122
Webhooks ............................................................................................................. 125
Invocar um webhook ................................................................................................. 127
Invocar um runbook do Azure Monitor .................................................................. 129
Hybrid Workers .......................................................................................................... 134
Configuração de estado da Automação do Azure ........................................... 136
Preços da Automação do Azure ......................................................................... 141
Comparação com a automação sem servidor ................................................. 141
Resumo ................................................................................................................. 142
Capítulo 5: Criar políticas, bloqueios e marcas para
implantações do Azure 145
Segurança ............................................................................................................. 226
Ciclo de vida da segurança ....................................................................................... 228
Segurança do Azure ................................................................................................... 230
Segurança de IaaS ................................................................................................ 231
Grupos de segurança de rede .................................................................................. 231
Firewalls ...................................................................................................................... 234
Grupos de segurança de aplicações ........................................................................ 235
Firewall do Azure ....................................................................................................... 236
Reduzir a área de superfície de ataque .................................................................. 237
Implementar servidores de salto ............................................................................. 238
Azure Bastion ............................................................................................................. 239
Segurança de aplicações ..................................................................................... 239
SSL/TLS ........................................................................................................................ 239
Identidades gerenciadas ........................................................................................... 240
Azure Sentinel ...................................................................................................... 244
Segurança de PaaS ............................................................................................... 245
Link Privado do Azure ............................................................................................... 245
Gateway de Aplicativo do Azure .............................................................................. 245
Azure Front Door ....................................................................................................... 246
Ambiente do Serviço de Aplicativo do Azure .......................................................... 247
Log Analytics ............................................................................................................... 247
Armazenamento do Azure .................................................................................. 248
SQL do Azure ........................................................................................................ 252
Azure Key Vault .................................................................................................... 256
Autenticação e autorização usando OAuth ...................................................... 257
Monitoramento e auditoria de segurança ....................................................... 265
Azure Monitor ............................................................................................................ 265
Central de Segurança do Azure ................................................................................ 267
Resumo ................................................................................................................. 268
DevOps .................................................................................................................. 422
A essência do DevOps ......................................................................................... 425
Práticas de DevOps .............................................................................................. 427
Gerenciamento de configuração ............................................................................. 428
Ferramentas de gerenciamento de configuração ................................................. 429
Integração contínua .................................................................................................. 430
Implantação contínua ............................................................................................... 433
Entrega contínua ........................................................................................................ 435
Aprendizado contínuo ............................................................................................... 435
Azure DevOps ....................................................................................................... 436
TFVC ............................................................................................................................. 439
Git ................................................................................................................................. 439
Preparar para o DevOps ..................................................................................... 440
Organizações do Azure DevOps ............................................................................... 441
Provisionar o Azure Key Vault .................................................................................. 442
Provisionar um servidor/serviço de gerenciamento de configuração ................ 442
Log Analytics ............................................................................................................... 443
Contas de armazenamento do Azure ...................................................................... 443
Imagens do Docker e do sistema operacional ....................................................... 443
Ferramentas de gerenciamento .............................................................................. 443
DevOps para soluções de PaaS .......................................................................... 444
Serviço de Aplicativo do Azure ................................................................................. 445
Slots de implantação ................................................................................................. 445
SQL do Azure .............................................................................................................. 446
Os pipelines de build e lançamento ........................................................................ 446
DevOps para IaaS ................................................................................................. 458
Máquinas virtuais do Azure ...................................................................................... 458
Balanceadores de carga públicos do Azure ............................................................ 459
O pipeline de build ..................................................................................................... 459
O pipeline de lançamento ......................................................................................... 460
DevOps com contêineres .................................................................................... 462
Contêineres ................................................................................................................ 462
O pipeline de build ..................................................................................................... 463
O pipeline de lançamento ......................................................................................... 463
Azure DevOps e Jenkins ...................................................................................... 464
Automação do Azure ........................................................................................... 466
Provisionar uma conta da Automação do Azure ................................................... 467
Criar configuração do DSC ........................................................................................ 468
Importar a configuração do DSC .............................................................................. 469
Compilar a configuração do DSC ............................................................................. 470
Atribuir configurações a nós .................................................................................... 470
Validação ..................................................................................................................... 471
Ferramentas para DevOps .................................................................................. 471
Resumo ................................................................................................................. 473
IoT .......................................................................................................................... 576
Arquitetura de IoT ............................................................................................... 577
Conectividade ............................................................................................................. 579
Identidade ................................................................................................................... 581
Captura ........................................................................................................................ 581
Ingestão ....................................................................................................................... 581
Armazenamento ........................................................................................................ 582
Transformação ........................................................................................................... 582
Análise ......................................................................................................................... 582
Apresentação ............................................................................................................. 583
Azure IoT ............................................................................................................... 584
Conectividade ............................................................................................................. 584
Identidade ................................................................................................................... 585
Captura ........................................................................................................................ 585
Ingestão ....................................................................................................................... 585
Armazenamento ........................................................................................................ 586
Transformação e análise ........................................................................................... 586
Apresentação ............................................................................................................. 587
Hub IoT do Azure ................................................................................................. 588
Protocolos ................................................................................................................... 589
Registro do dispositivo .............................................................................................. 589
Gerenciamento de mensagens ................................................................................ 590
Segurança ................................................................................................................... 593
Escalabilidade ............................................................................................................. 594
Azure IoT Edge ............................................................................................................ 596
Alta disponibilidade ............................................................................................. 596
Azure IoT Central ................................................................................................. 597
Resumo ................................................................................................................. 598
Índice 661
Prefácio
>
Sobre
Esta seção apresenta brevemente os autores, a cobertura deste livro, as habilidades técnicas
de que você precisará para começar e os requisitos de hardware e software para arquitetar
soluções usando o Azure.
ii | Prefácio
Sobre os autores
Ritesh Modi foi evangelista tecnológico sênior da Microsoft. Ele foi reconhecido
como diretor regional da Microsoft por suas contribuições para produtos, serviços
e comunidades da Microsoft. Ele é arquiteto de nuvem, autor publicado, palestrante
e um líder popular por suas contribuições para datacenters, Azure, Kubernetes,
blockchain, serviços cognitivos, DevOps, inteligência artificial e automação.
Ele é o autor de oito livros.
Ritesh deu palestras em inúmeras conferências nacionais e internacionais e é um
autor publicado da MSDN Magazine. Ele tem mais de uma década de experiência na
criação e implantação de soluções empresariais para clientes e mais de 25 certificações
técnicas. Seus interesses e hobbies são escrever livros, brincar com sua filha, assistir
a filmes e aprender sobre novas tecnologias. Ele atualmente mora em Hyderabad, na
Índia. Você pode segui-lo no Twitter em @automationnext.
Jack Lee é consultor certificado sênior do Azure e líder de prática do Azure com
uma paixão por desenvolvimento de software, nuvem e inovações de DevOps. Jack
foi reconhecido como MVP da Microsoft por suas contribuições para a comunidade
tecnológica. Ele se apresentou em vários grupos de usuários e conferências, incluindo
o Global Azure Bootcamp na Microsoft Canada. Jack é um mentor experiente e juiz
em hackathons e também é o presidente de um grupo de usuários que se concentra
em Azure, DevOps e desenvolvimento de software. Ele é o coautor de Análise de
Nuvem com Microsoft Azure, publicado pela Packt Publishing. Você pode seguir
Jack no Twitter em @jlee_consulting.
Azure para Arquitetos – Terceira edição | iii
Sobre os revisores
Melony Qin é uma mulher em STEM. Atualmente trabalhando como gerente de
programas na Microsoft, ela é membro da Association for Computing Machinery
(ACM) e do Project Management Institute (PMI). Ela contribuiu para computação sem
servidor, processamento de big data, DevOps, inteligência artificial, aprendizado de
máquina e IoT com o Microsoft Azure. Ela possui todas as certificações do Azure (ambas
as faixas Aplicativos e infraestrutura e Dados e IA), bem como Certified Kubernetes
Administrator (CKA) e Certified Kubernetes Application Developer (CKAD), e está
trabalhando principalmente em suas contribuições para software Open Source (OSS),
DevOps, Kubernetes, sem servidor, análise de big data e IoT no Microsoft Azure para
a comunidade. Ela é autora e coautora de dois livros, Infraestrutura do Microsoft Azure
e O workshop do Kubernetes, ambos publicados pela Packt Publishing. É possível entrar
contato via Twitter em @MelonyQ.
Sanjeev Kumar é arquiteto de soluções de nuvem para SAP no Azure na Microsoft.
Atualmente, mora em Zurique, na Suíça. Ele trabalha com a tecnologia SAP há mais
de 19 anos e com tecnologias de nuvem pública há cerca de 8 anos, sendo os últimos
2 anos com foco no Microsoft Azure.
Objetivos de aprendizagem
Até o final deste livro, você será capaz de:
• Entender os componentes da plataforma de nuvem do Azure
• Usar padrões de design de nuvem
• Usar as diretrizes de segurança empresarial para sua implantação do Azure
• Criar e implementar soluções de integração e sem servidor
• Criar soluções de dados eficientes no Azure
• Entender os serviços de contêiner no Azure
Público-alvo
Se você for um arquiteto de nuvem, engenheiro de DevOps ou desenvolvedor que busca
aprender sobre os principais aspectos arquitetônicos da plataforma de nuvem do Azure,
este livro é destinado a você. Uma compreensão básica da plataforma de nuvem do
Azure ajudará você a entender os conceitos abordados neste livro de forma mais eficaz.
Abordagem
Este livro aborda cada tópico com explicações passo a passo de conceitos essenciais,
exemplos práticos e perguntas de autoavaliação. Ao oferecer um equilíbrio entre teoria
e experiência prática com projetos envolventes, este livro vai ajudá-lo a entender como
os arquitetos trabalham no mundo real.
Requisitos de hardware
Para oferecer a experiência ideal, recomendamos a seguinte configuração:
• Mínimo de 4 GB de RAM
• Memória mínima gratuita de 32 GB
Azure para Arquitetos – Terceira edição | v
Requisitos de software
• Visual Studio 2019
• Versão mais recente do Docker para Windows
• Módulo AZ do PowerShell, 1.7 e posterior
• Versão mais recente da CLI do Azure
• Assinatura do Azure
• Windows Server 2016/2019
• Versão mais recente do Windows 10 de 64 bits
Convenções
Palavras de código em textos, nomes de tabelas de bancos de dados, nomes de pastas,
nomes de arquivos, extensões de arquivos, nomes de caminhos, simulações de URLs
e entrada do usuário são mostrados da seguinte maneira:
A configuração do DSC ainda não é conhecida pela Automação do Azure. Ela está
disponível em alguns computadores locais. Ela deve ser carregada nas Configurações
do DSC da Automação do Azure. A Automação do Azure fornece o cmdlet Import-
AzureRMAutomationDscConfiguration para importar a configuração:
Import-AzureRmAutomationDscConfiguration -SourcePath "C:\DSC\AA\DSCfiles\
ConfigureSiteOnIIS.ps1" -ResourceGroupName "omsauto" -AutomationAccountName
"datacenterautomation" -Published -Verbose
A inovação mais notável dos anos 2000 foi o surgimento e a adoção de dispositivos
portáteis, especialmente os smartphones, e com eles vieram uma infinidade de
aplicativos. Os aplicativos podiam se conectar a servidores centralizados na Internet
e conduzir os negócios normalmente. Os usuários não eram mais dependentes de
navegadores para fazer esse trabalho; todos os servidores eram auto-hospedados
ou hospedados usando um provedor de serviços, como um Provedor de Serviços
de Internet (ISP).
Os usuários não tinham muito controle sobre seus servidores. Vários clientes e suas
implantações faziam parte do mesmo servidor, mesmo sem os clientes saberem disso.
No entanto, algo mais acontecia em meados e nas últimas partes da primeira década dos
anos 2000. Era o surgimento da computação na nuvem e, novamente, isso transformou
todo o cenário da Indústria de TI. Inicialmente, a adoção foi lenta e as pessoas
a abordaram com cautela, seja porque a nuvem estava em fase inicial e ainda tinha
muito a evoluir ou porque as pessoas tinham noções negativas variadas a respeito dela.
Para compreender melhor a tecnologia revolucionária, abordaremos os seguintes
tópicos neste capítulo:
• Computação na nuvem
• Infraestrutura como serviço (IaaS), Plataforma como serviço (PaaS) e Software
como serviço (SaaS)
• Noções básicas sobre o Azure
• Azure Resource Manager (ARM)
• Virtualização, contêineres e Docker
• Interação com a nuvem inteligente
Computação na nuvem
Hoje, a computação na nuvem é uma das tecnologias do futuro mais promissoras.
Ela está sendo adotada por empresas de todos os portes como parte de sua estratégia
de TI. Nos dias de hoje, é difícil ter uma conversa significativa sobre uma estratégia de
TI sem incluir a computação na nuvem nas discussões sobre soluções em geral.
A computação na nuvem, ou simplesmente a nuvem em termos gerais, refere-se
à disponibilidade de recursos na internet. Esses recursos são disponibilizados para os
usuários na internet como serviços. Por exemplo, o armazenamento é disponibilizado
sob demanda pela Internet para que os usuários possam armazenar seus arquivos,
documentos e muito mais. Nesse caso, o armazenamento é um serviço oferecido
por um provedor de nuvem.
Computação na nuvem | 3
Flexibilidade e agilidade
Em vez de criar uma grande aplicação monolítica usando uma metodologia de
implantação de abordagem Big-Bang, hoje as aplicações compreendem serviços
menores usando o paradigma de microsserviços. Os microsserviços ajudam a criar
serviços de forma independente e autônoma. Eles podem ser evoluídos isoladamente
sem reduzir toda a aplicação. Eles proporcionam grande flexibilidade e agilidade para
trazer mudanças à produção de maneira mais rápida e melhor. Muitos microsserviços
são convergidos para criar uma aplicação e fornecer soluções integradas aos clientes.
Eles devem ser detectáveis e ter pontos de extremidade bem definidos para a
integração. O número de integrações com a abordagem de microsserviços é muito alto
em comparação com as aplicações monolíticas tradicionais. Essas integrações agregam
complexidade ao desenvolvimento e à implantação das aplicações.
Velocidade, padronização e consistência
Portanto, a metodologia das implantações também deve sofrer alterações para se
adaptar às necessidades desses serviços, ou seja, mudanças e implantações frequentes.
Para mudanças e implantações frequentes, é importante usar processos que ajudem
a promover essas alterações de maneira previsível e consistente. Os processos
ágeis automatizados devem ser usados para que as alterações menores possam
ser implantadas e testadas isoladamente.
Manutenção da relevância
Por fim, os destinos de implantação devem ser redefinidos. Os destinos de implantação
devem ser criados facilmente em poucos segundos, e o ambiente desenvolvido deve
ser consistente em todas as versões, com binários, tempos de execução, estruturas
e configuração apropriados. As máquinas virtuais foram usadas com aplicações
monolíticas, mas os microsserviços precisam de mais agilidade, flexibilidade
e uma opção mais leve do que as máquinas virtuais. A tecnologia de contêineres
é o mecanismo preferido para destinos de implantação desses serviços, e falaremos
mais sobre isso mais adiante neste capítulo.
Escalabilidade
Alguns princípios importantes do uso dos microsserviços: eles têm uma capacidade
de escala ilimitada isoladamente, alta disponibilidade global, Disaster Recovery com
um ponto de recuperação quase zero e objetivos de tempo. Essas qualidades dos
microsserviços exigem uma infraestrutura que pode ser escalada de forma ilimitada.
Não deve haver restrições de recursos. Embora esse seja o caso, também é importante
que uma organização não pague pelos recursos com antecedência quando eles não
forem utilizados.
Computação na nuvem | 5
Economia
O princípio fundamental da computação na nuvem é pagar pelos recursos que estão
sendo consumidos e usá-los de maneira ideal, aumentando e diminuindo o número
de recursos e a capacidade automaticamente. Esses requisitos de aplicações
emergentes exigem a nuvem como a plataforma preferida para facilidade de escala,
alta disponibilidade, resistência a desastres, implantação de mudanças com facilidade
e obtenção de implantações automatizadas previsíveis e consistentes de maneira
econômica.
Fica claro na Figura 1.1 que os clientes têm mais controle ao usar implantações de IaaS
e que esse nível de controle diminui continuamente à medida que progredimos das
implantações de PaaS para SaaS.
IaaS
IaaS é um tipo de modelo de implantação que permite aos clientes provisionar sua
própria infraestrutura no Azure. O Azure fornece vários recursos de infraestrutura, e os
clientes podem provisioná-los sob demanda. Os clientes são responsáveis por manter
e governar sua própria infraestrutura. O Azure garantirá a manutenção da infraestrutura
física em que esses recursos de infraestrutura virtual estão hospedados. Com base nessa
abordagem, os clientes exigem operações e gerenciamento ativo no ambiente do Azure.
PaaS
A PaaS usa a implantação de infraestrutura e o controle do cliente. Esta é uma abstração
de nível mais alto em comparação com a IaaS. Nesta abordagem, os clientes trazem
a própria aplicação, código e dados e os implantam na plataforma fornecida pelo Azure.
Essas plataformas são gerenciadas e controladas pelo Azure, e os clientes são os únicos
responsáveis por suas aplicações. Os clientes executam apenas atividades relacionadas
à implantação de suas aplicações. Esse modelo fornece opções mais rápidas e fáceis
para a implantação de aplicações em comparação com a IaaS.
SaaS
A SaaS é uma abstração de nível mais alto em comparação com a PaaS. Nessa
abordagem, o software e seus serviços estão disponíveis para o consumo do cliente.
Os clientes só trazem seus dados para esses serviços. Eles não têm nenhum controle
sobre esses serviços. Agora que temos uma compreensão básica dos tipos de serviço
no Azure, vamos detalhar o Azure e entendê-lo do zero.
Observação
Na China e na Alemanha, os Serviços de Nuvem do Azure são separados para
uso geral e para uso governamental. Isso significa que os serviços de nuvem são
mantidos em datacenters separados.
8 | Introdução ao Azure
Arquitetura do ARM
A arquitetura do ARM e seus componentes são mostrados na Figura 1.2. Como
podemos ver, a Assinatura do Azure é composta por vários grupos de recursos.
Cada grupo contém instâncias de recursos que são criadas a partir dos tipos de
recursos disponíveis no provedor de recursos:
Microsoft Azure
Assinatura do Azure
Azure
Grupo de recursos
Serviço de Armazena- Banco de
Aplicativo mento dados SQL
Aplicativo LOB do Azure do Azure do Azure
Grupo de recursos
Armazena- Rede Banco de Dados
VM do mento virtual MySQL ClearDB
Workload de IaaS Azure do Azure do Azure do Azure
Provedores de recursos
Limitações do ASM
O ASM tem restrições inerentes. Por exemplo, as implantações do ASM são lentas
e causam bloqueio. As operações serão bloqueadas se uma operação anterior já estiver
em andamento. Algumas das limitações do ASM são:
• Paralelismo: o paralelismo é um desafio no ASM. Não é possível executar várias
transações em paralelo com êxito. As operações no ASM são lineares e executadas
uma após a outra. Se várias transações forem executadas ao mesmo tempo, haverá
erros de operações paralelas ou as transações serão bloqueadas.
• Recursos: os recursos no ASM são provisionados e gerenciados isoladamente uns
dos outros. Não existe relação entre os recursos do ASM. Não é possível agrupar
serviços e recursos nem os configurar em conjunto.
• Serviços de nuvem: os serviços de nuvem são as unidades de implantação no ASM.
Eles dependem de grupos de afinidade e não são escaláveis devido ao seu design
e arquitetura.
Funções e permissões granulares e discretas não podem ser atribuídas aos recursos
no ASM. Os clientes são administradores de serviços ou coadministradores na
assinatura. Eles têm controle total sobre os recursos ou não têm acesso a eles. O ASM
não fornece suporte para implantação. As duas implantações são feitas manualmente.
Caso contrário, precisaremos recorrer à escrita de scripts de procedimentos no .NET
ou PowerShell. As APIs do ASM não são consistentes entre os recursos.
Vantagens do ARM
O ARM fornece as seguintes vantagens e benefícios distintos em relação ao ASM:
• Agrupamento: o ARM permite o agrupamento de recursos em um contêiner
lógico. Esses recursos podem ser gerenciados em conjunto e passar por um
ciclo de vida comum, como um grupo. Isso facilita a identificação de recursos
relacionados e dependentes.
• Ciclos de vida comuns: os recursos de um grupo têm o mesmo ciclo de vida.
Esses recursos podem evoluir e ser gerenciados em conjunto, como uma unidade.
• RBAC: funções e permissões granulares podem ser atribuídas a recursos,
proporcionando acesso discreto para os clientes. Os clientes também podem
ter somente os direitos que lhe são atribuídos.
Azure Resource Manager | 11
Conceitos do ARM
Com o ARM, tudo no Azure é um recurso. Exemplos de recursos são VMs, interfaces
de rede, endereços IP públicos, contas de armazenamento e redes virtuais. O ARM
é baseado em conceitos relacionados a provedores de recursos e a consumidores
de recursos. O Azure fornece recursos e serviços por meio de vários provedores
de recursos que são consumidos e implantados em grupos.
Provedores de recursos
Esses são os serviços responsáveis por fornecer tipos de recursos por meio do ARM.
O conceito de nível superior do ARM engloba o provedor de recursos. Esses provedores
são contêineres de tipos de recursos. Os tipos de recursos são agrupados em
provedores de recursos. Eles são responsáveis por implantar e gerenciar os recursos.
Por exemplo, um tipo de recurso de VM é fornecido por um provedor de recursos
chamado Microsoft.Compute/virtualMachines. As operações de APIs Representational
State Transfer (REST) têm versões para distinguir entre elas. A nomenclatura das
versões é baseada nas datas em que elas são lançadas pela Microsoft. É necessário
que um provedor de recursos relacionado esteja disponível para uma assinatura para
implantar um recurso. Nem todos os provedores de recursos estão disponíveis para
uma assinatura de imediato. Se um recurso não estiver disponível para uma assinatura,
precisaremos verificar se o provedor de recursos necessário está disponível em cada
região. Se estiver disponível, o cliente poderá inscrever-se explicitamente na assinatura.
12 | Introdução ao Azure
Tipos de recursos
Os tipos de recursos são uma especificação real de recursos que define sua interface
e implementação de API pública. Eles implementam o funcionamento e as operações
com suporte do recurso. Semelhantes aos provedores de recursos, os tipos de recursos
também evoluem ao longo do tempo, no que se refere à sua implementação interna,
e têm várias versões de seus esquemas e das interfaces de API pública. Os nomes
das versões são baseados nas datas em que elas são lançadas pela Microsoft como
uma versão prévia ou disponibilidade geral (GA). Os tipos de recursos tornam-se
disponíveis como uma assinatura depois que um provedor de recursos é registrado
nela. Além disso, nem todos os tipos de recursos estão disponíveis em todas as regiões
do Azure. A disponibilidade de um recurso depende da disponibilidade e do registro de
um provedor de recursos em uma região do Azure e deve dar suporte à versão da API
necessária para o provisionamento dele.
Grupos de recursos
Os grupos de recursos são unidades de implantação no ARM. Eles são contêineres que
agrupam várias instâncias de recursos em um limite de gerenciamento e segurança. Um
grupo de recursos recebe um nome exclusivo em uma assinatura. Os recursos podem
ser provisionados em diferentes regiões do Azure e ainda pertencerem ao mesmo grupo
de recursos. Os grupos de recursos fornecem serviços adicionais a todos os recursos
deles. Os grupos de recursos fornecem serviços de metadados, como marcação, o que
permite a classificação dos recursos, o gerenciamento de recursos com base em
políticas, o RBAC, a proteção de recursos contra exclusão ou atualizações acidentais
e muito mais. Como mencionado anteriormente, eles têm um limite de segurança, e os
usuários que não têm acesso a um grupo de recursos não podem acessar os recursos
contidos nele. Cada instância de recurso precisa fazer parte de um grupo de recursos.
Caso contrário, ela não poderá ser implantada.
Recursos do ARM
Veja alguns dos principais recursos fornecidos pelo ARM:
• RBAC: Azure Active Directory (Azure AD) autentica os usuários para fornecer
acesso a assinaturas, grupos de recursos e recursos. O ARM implementa OAuth
e RBAC na plataforma, permitindo a autorização e o controle de acesso a recursos,
grupos de recursos e assinaturas com base nas funções atribuídas a um usuário
ou grupo. Uma permissão define o acesso às operações em um recurso. Essas
permissões podem permitir ou negar acesso ao recurso. Uma definição de função
é uma coleção dessas permissões. As funções mapeiam usuários e grupos do
Azure AD para permissões específicas. As funções são atribuídas posteriormente
a um escopo, que pode ser um indivíduo, uma coleção de recursos, um grupo
de recursos ou a assinatura. As identidades do Azure AD (usuários, grupos e
princípios de serviço) adicionadas a uma função ganham acesso ao recurso de
acordo com as permissões definidas na função. O ARM fornece várias funções
prontas para uso. Ele fornece funções de sistema, como o proprietário,
o colaborador e o leitor. Também fornece funções baseadas em recursos,
como colaborador de BD SQL e colaborador de VM. O ARM também permite
a criação de funções personalizadas.
• Marcas: as marcas são pares de nome-valor que adicionam mais informações e
metadados aos recursos. Recursos e grupos de recursos podem ter várias marcas.
As marcas ajudam na categorização dos recursos para melhorar a capacidade de
descoberta e gerenciamento. Os recursos podem ser pesquisados rapidamente e
identificados de forma fácil. Informações de cobrança e custos também podem ser
buscadas para os recursos que têm as mesmas marcas. Embora esse recurso seja
fornecido pelo ARM, um administrador de TI define seu uso e taxonomia em matéria
de recursos e grupos de recursos. A taxonomia e as marcas, por exemplo, podem
estar relacionadas a departamentos, uso de recursos, localização, projetos ou
quaisquer outros critérios considerados adequados do ponto de vista de custo, uso,
cobrança ou pesquisa. Essas marcas podem, então, ser aplicadas aos recursos. As
marcas definidas no nível de grupo de recursos não são herdadas por seus recursos.
• Políticas: outro recurso de segurança fornecido pelo ARM são as políticas
personalizadas. As políticas personalizadas podem ser criadas para controlar
o acesso aos recursos. As políticas são definidas como regras e convenções e
devem ser respeitadas durante a interação com os recursos e grupos de recursos.
A definição de política contém uma negação explícita de ações nos recursos
ou acesso aos recursos. Por padrão, todo acesso é permitido quando não é
mencionado na definição de política. Essas definições de política são atribuídas
ao escopo de recursos, grupos de recursos e assinaturas. É importante notar que
essas políticas não substituem o RBAC (controle de acesso baseado em função). Na
verdade, elas complementam e trabalham em conjunto com o RBAC. As políticas
14 | Introdução ao Azure
Virtualização
A virtualização foi uma inovação revolucionária que mudou completamente a maneira
como os servidores físicos eram vistos. Refere-se à abstração de um objeto físico em
um objeto lógico.
A virtualização de servidores físicos levou a servidores virtuais conhecidos como VMs.
Essas VMs consomem e compartilham a CPU física, memória, armazenamento e outros
componentes de hardware do servidor físico em que são hospedadas. Isso permite
um provisionamento mais rápido e fácil de ambientes de aplicações sob demanda,
fornecendo alta disponibilidade e escalabilidade com custo reduzido. Um servidor
físico é suficiente para hospedar várias VMs, com cada VM contendo o próprio sistema
operacional e serviços de hospedagem.
Não havia mais necessidade de comprar servidores físicos adicionais para implantar
novas aplicações e serviços. Os servidores físicos existentes eram suficientes para
hospedar mais VMs. Além disso, como parte da racionalização, o número de servidores
físicos foi reduzido com a ajuda da virtualização.
Contêineres | 15
Contêineres
Contêineres também são uma tecnologia de virtualização. No entanto, eles não
virtualizam um servidor. Na verdade, um contêiner é uma virtualização no nível
do sistema operacional. Isso significa que os contêineres compartilham o kernel
do sistema operacional (que é fornecido pelo host) entre si, juntamente com o host.
Vários contêineres em execução em um host (físico ou virtual) compartilham o kernel
do sistema operacional do host. Os contêineres garantem que eles reutilizem o kernel
do host em vez de cada um ter um kernel dedicado a eles mesmos.
Os contêineres são completamente isolados de seu host ou de outros contêineres
em execução no host. Os contêineres do Windows usam drivers de filtro de
armazenamento e isolamento de sessão do Windows para isolar serviços do sistema
operacional, como sistema de arquivos, registro, processos e redes. O mesmo acontece
para contêineres do Linux em execução em hosts Linux. Os contêineres do Linux usam
o namespace do Linux, os grupos de controle e o sistema de arquivos da união para
virtualizar o sistema operacional do host.
O contêiner aparece como se tivesse um sistema operacional e recursos completamente
novos e intocados. Esse arranjo fornece muitos benefícios. São eles:
• O provisionamento dos contêineres é rápido e leva menos tempo em comparação
com as máquinas virtuais. A maioria dos serviços de sistemas operacionais em um
contêiner é fornecida pelo sistema operacional do host.
• Os contêineres são leves e exigem menos recursos de computação do que as VMs.
A sobrecarga de recursos do sistema operacional não é mais necessária com os
contêineres.
• Os contêineres são muito menores do que as VMs.
• Os contêineres podem ajudar a resolver problemas relacionados ao gerenciamento
de várias dependências de aplicações de maneira intuitiva, automatizada e simples.
• Os contêineres fornecem a infraestrutura para definir todas as dependências
de aplicações em um único lugar.
16 | Introdução ao Azure
Docker
O Docker fornece recursos de gerenciamento a contêineres do Windows.
Ele é composto pelos dois executáveis a seguir:
• Daemon do Docker
• Cliente do Docker
O portal do Azure
O portal do Azure é um ótimo lugar para começar. Com o portal do Azure, os usuários
podem fazer logon e começar a criar e gerenciar recursos do Azure manualmente.
O portal fornece uma interface de usuário intuitiva e fácil de usar por meio do
navegador. O portal do Azure fornece uma maneira fácil de navegar nos recursos
usando folhas. As folhas exibem todas as propriedades de um recurso, incluindo seus
logs, custo, relação com outros recursos, marcas, opções de segurança e muito mais.
Uma implantação inteira da nuvem pode ser gerenciada por meio do portal.
18 | Introdução ao Azure
PowerShell
O PowerShell é um shell de linha de comando baseado em objeto e linguagem de
script usado para a administração, a configuração e o gerenciamento de infraestrutura
e ambientes. Ele é baseado no .NET Framework e fornece recursos de automação.
O PowerShell realmente se tornou um cidadão de primeira classe entre administradores
de TI e desenvolvedores de automação para gerenciar e controlar o ambiente Windows.
Hoje, quase todos os ambientes Windows e muitos ambientes Linux podem ser
gerenciados pelo PowerShell. Na verdade, quase todos os aspectos do Azure também
podem ser gerenciados pelo PowerShell. O Azure fornece suporte avançado para
o PowerShell. Ele fornece um módulo do PowerShell para cada provedor de recursos
contendo centenas de cmdlets. Os usuários podem usar esses cmdlets em seus
scripts para automatizar a interação com o Azure. O módulo do Azure PowerShell está
disponível por meio do instalador da plataforma Web e pela Galeria do PowerShell.
O Windows Server 2016 e o Windows 10 fornecem gerenciamento de pacotes e módulos
PowerShellGet para downloads e instalações rápidos e fáceis de módulos do PowerShell
da Galeria do PowerShell. O módulo PowerShellGet fornece o cmdlet Install-Module
para fazer o download e instalar módulos no sistema.
A instalação de um módulo é o simples ato de copiar os arquivos do módulo em locais
de módulos bem definidos, o que pode ser feito da seguinte forma:
Import-module PowerShellGet
Install-Module -Name az -verbose
O comando Import-module importa um módulo e suas funções relacionadas dentro
do atual escopo de execução, e o Install-Module ajuda na instalação de módulos.
A CLI do Azure
O Azure também fornece o Azure CLI 2.0, que pode ser implantado em sistemas
operacionais Linux, Windows e macOS. O Azure CLI 2.0 é o novo utilitário de linha
de comando do Azure para gerenciar os recursos do Azure. O Azure CLI 2.0 é otimizado
para gerenciar e administrar recursos do Azure a partir da linha de comando e para
criar scripts de automação que funcionam com o ARM. A CLI pode ser usada para
executar comandos usando o shell do Bash ou a linha de comando do Windows.
A CLI do Azure é muito famosa entre usuários que não são do Windows, pois permite
interagir com o Azure no Linux e no macOS. As etapas para instalação do Azure CLI 2.0
estão disponíveis em https://docs.microsoft.com/cli/azure/install-azure-cli?view=
azure-cli-latest.
Interação com a nuvem inteligente | 19
Modelos do ARM
Em uma seção anterior, analisamos os recursos de implantação, como vários serviços,
várias regiões, extensível e idempotente, fornecidos pelo ARM. Os modelos do ARM
são os principais meios de provisionamento de recursos no ARM. Os modelos do ARM
fornecem suporte de implementação para os recursos de implantação do ARM.
Eles fornecem um modelo declarativo por meio do qual recursos, suas configurações,
scripts e extensões são especificados. Os modelos do ARM se baseiam no formato
JavaScript Object Notation (JSON). Eles usam as convenções e a sintaxe JSON para
declarar e configurar recursos. Arquivos JSON são baseados em texto, fáceis de usar
e de ler.
Eles podem ser armazenados em um repositório de código-fonte e submetidos ao
controle de versão. Eles também servem para representar a IaC que pode ser usada para
provisionar recursos em um grupo de recursos do Azure de forma constante, previsível
e uniforme. Um modelo precisa de um grupo de recursos para implantação. Ele só
pode ser implantado em um grupo de recursos, que deve existir antes de executar
a implantação de um modelo. Um modelo não é capaz de criar um grupo de recursos.
Os modelos fornecem a flexibilidade de serem genéricos e modulares no seu design
e na sua implementação. Eles fornecem a capacidade de aceitar parâmetros de usuários,
declarar variáveis internas, definir dependências entre recursos, vincular recursos
dentro do mesmo grupo de recursos ou em grupos de recursos diferentes, além de
executar outros modelos. Eles também fornecem expressões e funções do tipo de
linguagem de script que os tornam dinâmicos e personalizáveis no tempo de execução.
20 | Introdução ao Azure
Implantações
O PowerShell permite os dois modos a seguir para a implantação de modelos:
• Incremental: a implantação incremental adiciona recursos declarados no modelo
que não existem em um grupo de recursos e deixa os recursos inalterados em um
grupo que não faz parte de uma definição de modelo e em um grupo existente no
modelo e no grupo com o mesmo estado de configuração.
• Completa: a implantação completa, por outro lado, adiciona recursos declarados
em um modelo ao grupo de recursos, exclui recursos que não existem no modelo
do grupo e deixa inalterados os recursos que existem no grupo e no modelo com
o mesmo estado de configuração.
Resumo
A nuvem é um paradigma relativamente novo e ainda está em fase incipiente.
Haverá muita inovação e recursos adicionados ao longo do tempo. O Azure é um dos
principais provedores de nuvem do momento e fornece recursos avançados por meio
de implantações de IaaS, PaaS, SaaS e híbridas. Na verdade, o Azure Stack, que é uma
implementação da nuvem privada da Microsoft, será lançado em breve. Ele terá os
mesmos recursos que estão disponíveis em uma nuvem privada na nuvem pública.
Ambas poderão, de fato, se conectar e funcionar em conjunto de forma transparente
e integrada.
É muito fácil começar a usar o Azure, mas os desenvolvedores e arquitetos também
podem cair em uma armadilha se não projetarem e arquitetarem suas soluções
adequadamente. Este livro é uma tentativa de fornecer orientações e instruções para
arquitetar soluções da maneira certa, usando os serviços e recursos adequados. Cada
serviço no Azure é um recurso. É importante compreender como esses recursos são
organizados e gerenciados no Azure. Este capítulo apresentou o contexto do ARM
e dos grupos, que são as estruturas básicas que fornecem os elementos básicos dos
recursos. O ARM oferece um conjunto de serviços para recursos que ajudam a fornecer
uniformidade, padronização e consistência no gerenciamento deles. Os serviços,
como o RBAC, marcas, políticas e bloqueios, estão disponíveis para todos os recursos
e provedores de recursos. O Azure também fornece funcionalidades avançadas de
automação para automatizar e interagir com recursos. Ferramentas como o PowerShell,
modelos do ARM e a CLI do Azure podem ser incorporadas como parte dos pipelines de
lançamento e da implantação e entrega contínuas. Os usuários podem se conectar ao
Azure a partir de ambientes heterogêneos usando essas ferramentas de automação.
O próximo capítulo abordará algumas das importantes preocupações de arquitetura que
ajudam a resolver problemas comuns da implantação baseada na nuvem e a garantir que
as aplicações sejam seguras, disponíveis, escaláveis e de fácil manutenção no longo prazo.
Disponibilidade,
2
escalabilidade
e monitoramento
da solução do Azure
As preocupações com arquitetura, como alta disponibilidade e escalabilidade,
são alguns dos itens de maior prioridade para qualquer arquiteto. Isso é comum
em muitos projetos e soluções. No entanto, isso se torna ainda mais importante ao
implantar aplicações na nuvem devido à complexidade envolvida. Na maioria das
vezes, a complexidade não vem da aplicação, mas das opções disponíveis em termos
de recursos semelhantes na nuvem. O outro problema complexo que surge da nuvem
é a disponibilidade constante de novos recursos. Esses novos recursos podem tornar
as decisões de um arquiteto completamente redundantes em retrospectiva.
Neste capítulo, analisaremos a perspectiva de um arquiteto em termos de implantação
de aplicações altamente disponíveis e escalonáveis no Azure.
24 | Disponibilidade, escalabilidade e monitoramento da solução do Azure
O Azure é uma plataforma madura que fornece várias opções para implementar
alta disponibilidade e escalabilidade em vários níveis. Para um arquiteto, é essencial
conhecê-las, incluindo as diferenças entre elas e os custos envolvidos, e estar em uma
posição de escolher uma solução adequada que atenda aos melhores requisitos. Não há
uma única solução para tudo, mas há uma boa solução para cada projeto.
Alta disponibilidade
A alta disponibilidade é um dos requisitos técnicos não funcionais essenciais para
qualquer serviço crítico para os negócios e sua implantação. A alta disponibilidade
refere-se ao recurso de um serviço ou aplicação que os mantém operacionais
continuamente. Para fazer isso, ela atende ou supera o acordo de nível de serviço (SLA)
prometido. Os usuários recebem a promessa de determinado SLA com base no tipo de
serviço. O serviço deve estar disponível para utilização com base em seu respectivo SLA.
Por exemplo, um SLA pode definir 99% de disponibilidade de uma aplicação para o ano
inteiro. Isso significa que ele deve estar disponível para os usuários 361,35 dias por ano.
Se ele não permanecer disponível para esse período, isso constitui uma violação do SLA.
A maioria das aplicações de missão crítica define seu SLA de alta disponibilidade como
99,999% por um ano. Isso significa que a aplicação deve estar ativa, em execução
e disponível o ano todo, mas só pode ficar inativa e indisponível por 5,2 horas. Se
o tempo de inatividade for além disso, você estará qualificado para crédito, que
será calculado com base na porcentagem de tempo de atividade total.
Alta disponibilidade do Azure | 25
Veremos cada um desses fatores nas seções a seguir. Vamos dar uma olhada mais
de perto em como a alta disponibilidade é assegurada para implantações no Azure.
Conceitos
Os conceitos fundamentais fornecidos pelo Azure para obter alta disponibilidade são:
• Conjuntos de disponibilidade
• O domínio de falha
• O domínio de atualização
• Zonas de disponibilidade
O domínio de falha
Os domínios de falha (FDs) representam um grupo de VMs que compartilham a mesma
fonte de energia e comutador de rede. Quando uma VM é provisionada e atribuída
a um conjunto de disponibilidade, ela é hospedada em um FD. Cada conjunto de
disponibilidade tem dois ou três FDs, dependendo da região do Azure. Algumas regiões
fornecem dois, enquanto outras fornecem três FDs em um conjunto de disponibilidade.
Os FDs não podem ser configurados pelos usuários.
Quando várias VMs são criadas, elas são colocadas em FDs separados. Se o número de
VMs for maior do que o de FDs, as VMs adicionais serão colocadas em FDs existentes.
Por exemplo, se houver cinco VMs, haverá FDs hospedados em mais de uma VM.
Os FDs estão relacionados aos racks físicos no datacenter do Azure. Os FDs fornecem
alta disponibilidade em caso de tempo de inatividade não planejado devido a falhas
de hardware, energia e rede. Como cada VM é colocada em um rack diferente com
hardware, fonte de alimentação e rede diferentes, outras VMs continuarão sendo
executadas se um rack for desligado.
O próximo na lista é o domínio de atualização.
O domínio de atualização
Um FD cuida do tempo de inatividade não planejado. Já um domínio de atualização
gerencia o tempo de inatividade da manutenção planejada. Cada VM também é
atribuída a um domínio de atualização, e todas as VMs dentro desse domínio de
atualização serão reinicializadas juntas. Pode haver mais de 20 domínios de atualização
em um único conjunto de disponibilidade. Os domínios de atualização não podem
ser configurados pelos usuários. Quando várias VMs são criadas, elas são colocadas
em domínios de atualização separados. Se mais de 20 VMs forem provisionadas em
um conjunto de disponibilidade, elas serão colocadas em um modo de distribuição
alternada nesses domínios de atualização. Os domínios de atualização cuidam da
manutenção planejada. Em Integridade do serviço no portal do Azure, você pode
verificar os detalhes da manutenção planejada e definir alertas.
Região do Azure
Zona de Disponibilidade 3
Balanceamento de carga
O balanceamento de carga, como o nome sugere, refere-se ao processo de
balanceamento de uma carga entre VMs e aplicações. Com uma VM, não há necessidade
de balanceador porque a carga inteira está em uma única VM, e não há outra para
compartilhá-la. No entanto, com várias VMs contendo a mesma aplicação e serviço,
é possível distribuir a carga entre elas por meio do balanceamento de carga. O Azure
fornece alguns recursos para viabilizar o balanceamento de carga:
• Balanceadores de carga: o balanceador de carga do Azure ajuda a criar soluções com
alta disponibilidade. Na pilha do Protocolo de Controle de Transmissão (TCP) há um
balanceador de carga no nível de transporte da camada 4. Ele é um balanceador de
carga da camada 4 que distribui o tráfego de entrada entre instâncias íntegras dos
serviços definidos em um conjunto de balanceamento de carga. Os balanceadores de
carga de nível 4 funcionam no nível de transporte e têm informações de rede, como
endereço IP e porta, para decidir o destino da solicitação de entrada. Os balanceadores
de carga são explicados em mais detalhes posteriormente neste capítulo.
• Gateways de aplicação: o gateway de aplicação do Azure proporciona alta
disponibilidade para suas aplicações. Eles são balanceadores de carga de camada
7 que distribuem o tráfego de entrada entre instâncias íntegras de serviços.
Os balanceadores de carga de nível 7 podem funcionar no nível da aplicação
e possuem informações sobre ela, como cookies, HTTP, HTTPS e sessões da
solicitação de entrada. Os gateways de aplicação são explicados em mais detalhes
posteriormente neste capítulo. Eles também são usados ao implantar os serviços
do Kubernetes do Azure especificamente para cenários em que o tráfego de
ingresso da Internet deve ser roteado para os serviços do Kubernetes no cluster.
• Azure Front Door: o Azure Front Door é muito semelhante aos gateways de
aplicação. No entanto, ele não funciona no nível da região ou do datacenter. Em vez
disso, ele ajuda no roteamento de solicitações entre regiões globalmente. Ele tem
o mesmo conjunto de recursos que o oferecido pelos gateways de aplicação, mas
no nível global. Ele também fornece um firewall de aplicação Web para a filtragem de
solicitações e outra proteção relacionada à segurança. Ele fornece afinidade de sessão,
terminação de TLS e roteamento baseado em URL como alguns de seus recursos.
• O Gerenciador de Tráfego: ajuda no roteamento de solicitações no nível
global em várias regiões com base na integridade e na disponibilidade de
pontos de extremidade regionais. Ele permite fazer isso usando entradas
de redirecionamento de DNS. Ele também é altamente resiliente e não causa
nenhum impacto no serviço durante falhas regionais.
30 | Disponibilidade, escalabilidade e monitoramento da solução do Azure
Já que exploramos os métodos e serviços que podem ser usados para alcançar
o balanceamento de carga, vamos discutir como tornar as VMs altamente disponíveis.
FD 0 FD 1 FD 2
UD 0 UD 1
UD 2
• Um endereço IP de origem
• Um endereço IP de destino
• Um número da porta de origem
• Um número da porta de destino
• Um tipo de protocolo – TCP ou HTTP
34 | Disponibilidade, escalabilidade e monitoramento da solução do Azure
Porta TCP 80
Balanceador de
carga público
Sub-rede da
camada da
Web
Balanceador de
carga interno
Sub-rede da
camada de
negócios
Rede virtual
Na Figura 2.4, você pode ver que os usuários externos estão acessando as VMs por meio
do balanceador de carga público e, em seguida, o tráfego da VM é distribuído em outro
conjunto de VMs usando um balanceador de carga interno.
Fizemos uma comparação de como os balanceadores de carga do Azure diferem dos
gateways de aplicação. Na próxima seção, discutiremos os gateways de aplicação em
mais detalhes.
Alta disponibilidade do Azure | 35
As implantações que buscam resiliência no nível global devem incluir o Azure Front
Door em sua arquitetura, junto com gateways de aplicação e balanceadores de carga.
Na próxima seção, você verá algumas das considerações de arquitetura que você deve
levar em conta ao criar soluções altamente disponíveis.
Agora que você já sabe como criar soluções altamente disponíveis na mesma região,
vamos discutir como uma arquitetura semelhante, mas espalhada por regiões do Azure,
pode ser criada.
Escalabilidade
A execução de aplicações e sistemas que estão disponíveis para os usuários para
consumo é importante para arquitetos de qualquer aplicação crítica para os negócios.
No entanto, há outro recurso de aplicação igualmente importante que é uma das
principais prioridades para os arquitetos: a escalabilidade da aplicação.
Imagine uma situação em que uma aplicação é implantada e obtém excelente
performance e disponibilidade com poucos usuários, mas tanto a disponibilidade
quanto a performance diminuem à medida que o número de usuários começa a
aumentar. Há momentos em que uma aplicação sob carga normal tem boa performance,
mas essa performance diminui com o aumento do número de usuários. Isso pode
acontecer quando há um aumento repentino no número de usuários e o ambiente
não foi criado para um número tão grande de usuários.
Para acomodar esses picos no número de usuários, você pode provisionar o hardware
e a largura de banda para gerenciar esses picos. O desafio com isso é que a capacidade
adicional não é usada na maior parte do ano e, portanto, não fornece retorno sobre
o investimento. Ela é provisionada para uso apenas durante a temporada de férias ou
vendas. Espero que até o momento você esteja se familiarizando com os problemas
que os arquitetos estão tentando resolver. Todos esses problemas estão relacionados
ao dimensionamento da capacidade e à escalabilidade de uma aplicação. O foco deste
capítulo é entender a escalabilidade como uma preocupação de arquitetura e conferir
os serviços fornecidos pelo Azure para implementar a escalabilidade.
Planejamento e dimensionamento de capacidade são algumas das principais prioridades
dos arquitetos e seus serviços e aplicações. Os arquitetos devem encontrar um
equilíbrio entre a compra e o provisionamento de recursos a mais ou a menos. Se tiver
menos recursos, você não conseguirá atender a todos os usuários, e eles recorrerão
aos concorrentes. Por outro lado, ter mais recursos pode prejudicar seu orçamento
e retorno sobre o investimento, pois a maioria dos recursos permanece não utilizada
na maior parte do tempo. Além disso, o problema aumenta com os níveis variados de
demanda em diferentes momentos. É quase impossível prever o número de usuários
de uma aplicação em um dia, muito menos um ano. No entanto, é possível encontrar
um número aproximado usando informações anteriores e monitoramento contínuo.
A escalabilidade refere-se à capacidade de gerenciar um número crescente de usuários
e de fornecer a eles o mesmo nível de performance quando há menos usuários fazendo
uso de recursos de implantação de aplicações, processos e tecnologia. A escalabilidade
pode significar o atendimento de mais solicitações sem reduzir a performance ou
a capacidade de lidar com um trabalho maior e mais demorado sem qualquer perda
de performance nos dois casos.
Escalabilidade | 43
Escalabilidade do Azure
Nesta seção, veremos as funcionalidades e os recursos fornecidos pelo Azure
para tornar as aplicações altamente disponíveis. Antes de entrarmos em detalhes
de arquitetura e configuração, é importante compreender os conceitos de alta
disponibilidade do Azure. Em outras palavras, dimensionamento.
O dimensionamento refere-se ao aumento ou à diminuição da quantidade de recursos
usados para atender a solicitações de usuários. A escala pode ser manual ou automática.
A escala manual exige que um administrador inicie manualmente o processo de
escalonamento, enquanto a escala automática refere-se a um aumento ou diminuição
de forma automática de recursos com base nos eventos disponíveis no ambiente e no
ecossistema, como disponibilidade da memória e da CPU. Os recursos podem ter
expansão ou redução vertical ou horizontal, o que será explicado a seguir nesta seção.
Além do lançamento de atualizações, as construções fundamentais proporcionadas pelo
Azure para obter alta disponibilidade são as seguintes:
• Expansão e redução verticais
• Expansão e redução horizontais
• Dimensionamento automático
Expansão vertical
A escala vertical de uma VM ou de um serviço envolve a adição de mais recursos
para servidores existentes, como CPU, memória e discos. O objetivo é aumentar
a capacidade do hardware e dos recursos físicos existentes.
Redução vertical
A redução vertical de uma VM ou de um serviço envolve a remoção de recursos
existentes de servidores existentes, como CPU, memória e discos. O objetivo é reduzir
a capacidade do hardware e dos recursos físicos e virtuais existentes.
Escalabilidade | 45
Expansão horizontal
A expansão envolve a adição de mais hardware, como servidores e capacidade
adicionais. Isso normalmente envolve adicionar novos servidores, atribuir endereços
IP a eles, implantar aplicações neles e torná-los parte dos balanceadores de carga
existentes, de modo que o tráfego possa ser encaminhado para eles. A escala horizontal
também pode ser manual ou automática. No entanto, para melhores resultados,
a automação deve ser usada:
Redução horizontal
A redução horizontal refere-se ao processo de remoção do hardware existente em
termos de capacidade e servidores existentes. Isso normalmente envolve remover
servidores existentes, desalocar endereços IP e removê-los da configuração existente
de balanceadores de carga de modo que o tráfego não possa ser roteado para eles.
Assim como a escala horizontal, a redução horizontal pode ser automática ou manual.
Dimensionamento automático
A escala automática refere-se ao processo de expandir/reduzir vertical ou
horizontalmente de forma dinâmica com base na demanda da aplicação e ocorre
por meio da automação. O dimensionamento automático é útil porque garante
que a implantação sempre consista em um número ideal de instâncias de servidor.
A escala automática ajuda a criar aplicações tolerantes a falhas. Isso não só ajuda na
escalabilidade, mas também torna as aplicações altamente disponíveis. Por fim, ela
proporciona o melhor gerenciamento de custos. O dimensionamento automático
possibilita a configuração ideal para instâncias de servidor com base na demanda.
Ele ajuda a não provisionar demais os servidores para que eles acabem subutilizados
e remove servidores que não são mais necessários após a escala horizontal.
Até agora, discutimos a escalabilidade no Azure. O Azure oferece opções de
escalabilidade para a maioria dos seus serviços. Vamos explorar a escalabilidade
para PaaS no Azure na próxima seção.
46 | Disponibilidade, escalabilidade e monitoramento da solução do Azure
Escalabilidade da PaaS
O Azure fornece serviços de aplicativo para hospedar aplicações gerenciadas.
O serviço de aplicativo é uma oferta de PaaS do Azure. Ele fornece serviços para a Web
e plataformas móveis. Por trás das plataformas Web e móvel está uma infraestrutura
gerenciada pelo Azure em nome de seus usuários. Os usuários não veem nem
gerenciam nenhuma infraestrutura. No entanto, eles podem estender a plataforma
e implantar suas aplicações nela. Com isso, os arquitetos e desenvolvedores podem se
concentrar em seus problemas de negócios em vez de se preocupar com a plataforma
básica e o provisionamento, a configuração e a solução de problemas da infraestrutura.
Os desenvolvedores têm a flexibilidade de escolher qualquer linguagem, sistema
operacional e estrutura para desenvolver suas aplicações. O serviço de aplicativo
fornece vários planos e, com base nos planos escolhidos, vários graus de escalabilidade
são disponibilizados. O serviço de aplicativo fornece os cinco planos a seguir:
• Gratuito: usa uma infraestrutura compartilhada. Isso significa que várias
aplicações serão implantadas na mesma infraestrutura do mesmo ou de vários
locatários. Ele fornece 1 GB de armazenamento gratuito. No entanto, não há
capacidade de escala nesse plano.
• Compartilhado: também usa uma infraestrutura compartilhada e fornece 1 GB
de armazenamento gratuito. Além disso, domínios personalizados também são
fornecidos como um recurso extra. No entanto, não há capacidade de escala
nesse plano.
• Básico: tem três unidades de manutenção de estoque (SKUs): B1, B2 e B3. Elas
têm um número maior de unidades de recursos disponíveis em termos de CPU
e memória. Resumindo, essas unidades fornecem uma configuração melhor das
VMs com apoio para esses serviços. Além disso, fornece armazenamento, domínios
personalizados e suporte para SSL. O plano básico oferece recursos básicos para
escala manual. Não há dimensionamento automático disponível nesse plano. No
máximo três instâncias podem ser usadas para a escala horizontal da aplicação.
• Padrão: também tem três SKUs diferentes: S1, S2 e S3. Elas têm um número maior
de unidades de recursos disponíveis em termos de CPU e memória. Resumindo,
essas unidades fornecem uma configuração melhor das VMs com apoio para esses
serviços. Além disso, elas fornecem armazenamento, domínios personalizados
e suporte para SSL semelhantes ao do plano básico. Esse plano também fornece
uma instância do Gerenciador de Tráfego, slots de preparo e um backup diário
como recurso adicional acima do plano básico. O plano padrão oferece recursos
para dimensionamento automático. No máximo 10 instâncias podem ser usadas
para a escala horizontal da aplicação.
Escalabilidade | 47
• Premium: também tem três SKUs diferentes: P1, P2 e P3. Elas têm um número
maior de unidades de recursos disponíveis em termos de CPU e memória.
Resumindo, essas unidades fornecem uma configuração melhor das VMs com
apoio para esses serviços. Além disso, elas fornecem armazenamento, domínios
personalizados e suporte para SSL semelhantes ao plano básico. Esse plano
também fornece uma instância do Gerenciador de Tráfego, slots de preparo
e 50 backups diários como recurso adicional acima do plano básico. O plano
padrão oferece recursos para dimensionamento automático. No máximo
20 instâncias podem ser usadas para a escala horizontal da aplicação.
Exploramos os níveis de escalabilidade disponíveis para serviços PaaS. Agora, vamos ver
como o dimensionamento pode ser feito no caso de um plano de serviço de aplicativo.
Escalabilidade da IaaS
Há usuários que querem ter controle total sobre sua infraestrutura de base,
a plataforma e a aplicação. Eles preferem consumir soluções de IaaS, em vez de
soluções de PaaS. Quando esses clientes criam VMs, eles também são responsáveis
por dimensionar e escalar a capacidade. Não há nenhuma configuração pronta
para o uso para dimensionamento manual ou automático de VMs. Esses clientes
precisarão escrever os próprios scripts de automação, gatilhos e regras para obter
o dimensionamento automático. Com as VMs vem a responsabilidade de mantê-
las. A aplicação de patches, atualização e upgrade de VMs é da responsabilidade dos
proprietários. Os arquitetos devem pensar tanto na manutenção planejada quanto
na não planejada. Como essas VMs devem receber patches, a ordem, o agrupamento
e outros fatores devem ser considerados para garantir que nem a escalabilidade nem
a disponibilidade de uma aplicação sejam comprometidas. Para ajudar a aliviar esses
problemas, o Azure fornece conjuntos de escalas de VM (VMSS) como uma solução,
o que discutiremos a seguir.
50 | Disponibilidade, escalabilidade e monitoramento da solução do Azure
Conjuntos de escalas de VM
Os VMSSs são recursos de computação do Azure que você pode usar para implantar
e gerenciar um conjunto de VMs idênticas. Com todas as VMs configuradas da mesma
maneira, os conjuntos de escalas são projetados para oferecer suporte à escala
automática real, e nenhum pré-provisionamento de VMs é necessário. Isso ajuda no
provisionamento de várias VMs idênticas conectadas umas às outras por meio de uma
rede virtual e sub-rede.
Um VMSS consiste em várias VMs, mas é gerenciado no nível dos VMSS. Todas as VMs
fazem parte dessa unidade e todas as alterações feitas são aplicadas à unidade que, por
sua vez, as aplica a VMs que usam um algoritmo predeterminado:
Isso permite que essas VMs tenham a carga balanceada usando um balanceador de
carga do Azure ou um gateway de aplicação. As VMs podem ser Windows ou Linux.
Elas podem executar scripts automatizados usando uma extensão do PowerShell
e podem ser gerenciadas centralmente usando uma configuração de estado. Elas
podem ser monitoradas como uma unidade ou individualmente usando a análise de log.
Os VMSSs podem ser provisionados do portal do Azure, da CLI do Azure, dos modelos
do Azure Resource Manager, das APIs REST e de cmdlets do PowerShell. É possível
invocar as APIs REST e a CLI do Azure de qualquer plataforma, ambiente e sistema
operacional ou em qualquer linguagem.
Muitos serviços do Azure já usam VMSSs como arquitetura subjacente. Entre eles estão
o Lote do Azure, Azure Service Fabric e Serviço de Contêiner do Azure. O Serviço de
Contêiner do Azure, por sua vez, provisionam o Kubernetes e o DC/OS nesses VMSSs.
Conjuntos de escalas de VM | 51
Arquitetura de VMSS
Os VMSSs permitem a criação de até 1.000 VMs em um conjunto de dimensionamento ao
usar uma imagem de plataforma e 100 VMs, se estiver usando uma imagem personalizada.
Se o número de VMs for inferior a 100 em um conjunto de dimensionamento, elas
serão colocadas em um único conjunto de disponibilidade. No entanto, se o número
for superior a 100, vários conjuntos de disponibilidade serão criados (conhecidos como
grupos de posicionamento), e as VMs serão distribuídas entre esses conjuntos de
disponibilidade. Sabemos desde o Capítulo 1, Introdução ao Azure, que as VMs em um
conjunto de disponibilidade são colocadas em domínios de falha e atualização separados.
Os conjuntos de disponibilidade relacionados aos VMSSs têm cinco domínios de falha
e atualização por padrão. Os VMSSs fornecem um modelo que contém informações de
metadados para todo o conjunto. Alterar esse modelo e aplicar alterações afeta todas as
instâncias de VM. Essas informações incluem os números de instâncias de VM máximas
e mínimas, a SKU e a versão do sistema operacional, o número atual de VMs, domínios
de falha e atualização e muito mais. Isso é demonstrado na Figura 2.13:
Escala VMSS
A escala refere-se a um aumento ou diminuição de recursos de computação
e armazenamento. Um VMSS é um recurso avançado que torna a escala fácil e eficiente.
Ele oferece a escala automática, que ajuda a expandir ou reduzir verticalmente com
base em eventos e dados externos, como uso de CPU e memória. Alguns dos recursos
de escala do VMSS são indicados aqui.
Capacidade
Os VMSSs têm uma propriedade de capacidade que determina o número de VMs
em um conjunto de escalas. Um VMSS pode ser implantado com o zero como o valor
dessa propriedade. Isso não criará uma única VM. No entanto, se você provisionar um
VMSS fornecendo um número para a propriedade de capacidade, esse número de VMs
será criado.
Dimensionamento automático
O dimensionamento automático de VMs no VMSS refere-se à adição ou remoção de
instâncias de VM com base no ambiente configurado para atender às demandas de
performance e escalabilidade de uma aplicação. Geralmente, na ausência de um VMSS,
isso é conseguido por meio de scripts de automação e runbooks.
Os VMSSs ajudam nesse processo de automação, com o suporte da configuração.
Em vez de escrever scripts, um VMSS pode ser configurado para expansão e redução
verticais automatizadas.
O dimensionamento automático usa vários componentes integrados para atingir seu
objetivo final. O dimensionamento automático envolve o monitoramento contínuo
de VMs e a coleta de dados de telemetria sobre elas. Esses dados são armazenados,
combinados e, então, avaliados com base em um conjunto de regras para determinar
se o dimensionamento automático deve ser acionado. O gatilho poderia ser para uma
expansão/redução horizontal ou vertical.
O mecanismo de dimensionamento automático usa logs de diagnóstico para coletar
dados de telemetria de VMs. Esses logs são armazenados em contas de armazenamento
como métricas de diagnóstico. O mecanismo de dimensionamento automático também
usa o serviço de monitoramento de insights de aplicação, que lê essas métricas e as
combina e armazena em uma conta de armazenamento.
Os trabalhos em segundo plano com dimensionamento automático são executados
continuamente para ler os dados de armazenamento de insights de aplicação, avaliá-
los com base em todas as regras configuradas para dimensionamento automático
e executar o processo de dimensionamento automático, se alguma das regras ou uma
combinação de regras for atendida. As regras podem levar em consideração as métricas
das VMs convidadas e do servidor host.
As regras definidas usando as descrições de propriedade estão disponíveis em
https://docs.microsoft.com/azure/virtual-machine-scale-sets/virtual-machine-
scale-sets-autoscale-overview.
Conjuntos de escalas de VM | 53
Atualizações e manutenção
Depois que um VMSS e as aplicações são implantados, eles precisam ser mantidos
ativamente. A manutenção planejada deve ser realizada periodicamente para garantir
que tanto o ambiente quanto a aplicação sejam atualizados com os recursos mais
recentes do ponto de vista de segurança e resiliência.
Atualizações podem ser associadas a aplicações, à instância de VM convidada
ou à própria imagem. As atualizações podem ser bastante complexas, pois devem
acontecer sem afetar a disponibilidade, escalabilidade e performance de ambientes
e aplicações. Para garantir que as atualizações possam ocorrer em uma instância de
cada vez usando métodos de atualização sem interrupção, é importante que o VMSS
ofereça suporte e recursos para esses cenários avançados.
A equipe do Azure fornece um utilitário para gerenciar atualizações dos VMSSs. É um
utilitário baseado em Python cujo download pode ser feito em https://github.com/
gbowerman/vmssdashboard. Ele faz chamadas da API REST para o Azure para gerenciar
conjuntos de escalas. Esse utilitário pode ser usado para iniciar, parar, atualizar e recriar
VMs em um FD ou grupo de VMs, conforme mostrado na Figura 2.15:
Atualizações e manutenção | 55
Atualizações de aplicações
As atualizações de aplicações nos VMSSs não devem ser executadas manualmente. Elas
devem ser executadas como parte do gerenciamento e pipelines de versões que usam
a automação. Além disso, a atualização deve ocorrer em uma instância de aplicação
por vez e não deve afetar a disponibilidade geral e a escalabilidade de uma aplicação.
Ferramentas de gerenciamento de configuração, como a configuração de estado
desejada (DSC), devem ser implantadas para gerenciar as atualizações de aplicações.
O servidor de pull do DSC pode ser configurado com a versão mais recente da
configuração de aplicações, e ele deve ser aplicado sem interrupção a cada instância.
Na próxima seção, vamos nos concentrar em como as atualizações são feitas no sistema
operacional convidado.
Atualizações de convidados
As atualizações de VMs são de responsabilidade do administrador. O Azure não
é responsável por corrigir VMs convidadas. As atualizações de convidados estão
no modo de visualização, e os usuários devem controlar a aplicação de patches
manualmente ou usar métodos de automação personalizada, como runbooks e scripts.
No entanto, as atualizações de patch sem interrupção estão no modo de visualização
e podem ser configuradas no modelo do Azure Resource Manager usando uma política
de atualização, conforme mostrado aqui:
"upgradePolicy": {
"mode": "Rolling",
"automaticOSUpgrade": "true" or "false",
"rollingUpgradePolicy": {
"batchInstancePercent": 20,
"maxUnhealthyUpgradedInstanceCount": 0,
"pauseTimeBetweenBatches": "PT0S"
}
}
Atualizações de imagens
Um VMSS pode atualizar a versão do sistema operacional sem qualquer tempo de
inatividade. As atualizações do sistema operacional envolvem a alteração da versão
ou da SKU do sistema operacional ou a alteração do URI de uma imagem personalizada.
Atualizar sem tempo de inatividade significa atualizar as VMs uma de cada vez ou em
grupos (como um FD por vez) em vez de todas de uma vez. Ao fazer isso, as VMs que
não estiverem sendo atualizadas poderão continuar funcionando.
Até agora, discutimos atualizações e manutenção. Agora vamos ver quais são as práticas
recomendadas de dimensionamento para VMSSs.
Atualizações e manutenção | 57
Monitoramento
O monitoramento é uma importante questão de arquitetura que deve ser parte de
qualquer solução, seja ela grande ou pequena, de missão crítica ou não, baseada na
nuvem ou não. Ele não deve ser negligenciado.
O monitoramento refere-se ao ato de manter o controle de soluções e capturar várias
informações de telemetria, processá-las, identificar as informações que se qualificam
para alertas com base em regras e criá-los. Geralmente, um agente é implantado dentro
do ambiente e o monitora, enviando as informações de telemetria para um servidor
centralizado, onde ocorrerá o restante do processamento de geração de alertas
e notificação de stakeholders.
O monitoramento realiza ações proativas e reativas e avalia uma solução. Ele também
é o primeiro passo da auditoria de uma solução. Sem a capacidade de monitorar
registros de log, é difícil auditar um sistema em relação a vários aspectos, como
segurança, performance e disponibilidade.
O monitoramento ajuda a identificar problemas de disponibilidade, performance
e escalabilidade antes que eles aconteçam. Falhas de hardware, configuração incorreta
de software e desafios de atualização de patches podem ser descobertos bem antes de
afetar os usuários por meio do monitoramento, e a degradação de performance pode
ser corrigida antes de acontecer.
O monitoramento de logs reativamente indica áreas e locais que estão causando
problemas, identifica os problemas e permite reparos mais rápidos e melhores.
Monitoramento | 59
Monitoramento do Azure
A primeira pergunta deve ser respondida é: “O que devemos monitorar?” Essa questão
se torna mais importante para soluções que são implantadas na nuvem devido ao seu
controle restrito.
Há alguns componentes importantes que devem ser monitorados. Eles incluem:
• Aplicações personalizadas
• Recursos do Azure
• Sistemas operacionais convidados (VMs)
• Sistemas operacionais do host (servidores físicos do Azure)
• Infraestrutura do Azure
Por fim, temos os logs de sistema operacional convidado e do host. Vamos entender
o que eles são.
Azure Monitor
Logs
O espaço de trabalho do Log Analytics fornece recursos de pesquisa para buscar
entradas de log específicas, exportar todos os dados de telemetria para o Excel e/ou
o Power BI e pesquisar uma linguagem de consulta chamada linguagem de consulta
Kusto (KQL), que é semelhante ao SQL.
62 | Disponibilidade, escalabilidade e monitoramento da solução do Azure
Na próxima seção, veremos as soluções do Log Analytics, que são como recursos
adicionais em um espaço de trabalho do Log Analytics.
Soluções
As soluções no Log Analytics são recursos adicionais que podem ser adicionados
a um espaço de trabalho com a captura de dados de telemetria adicionais que não
são capturados por padrão. Quando essas soluções são adicionadas a um espaço de
trabalho, Management Packs adequados são enviados para todos os agentes conectados
ao espaço de trabalho para que possam se configurar para capturar dados específicos
da solução de VMs e contêineres e, em seguida, enviá-los para o espaço de trabalho
do Log Analytics. As soluções de monitoramento da Microsoft e de parceiros estão
disponíveis no Azure Marketplace.
Monitoramento | 63
Alertas
O Log Analytics permite gerar alertas em relação aos dados ingeridos. Ele faz isso
por meio da execução de uma consulta predefinida composta por condições de dados
de entrada. Se for encontrado um registro que se encaixe no âmbito dos resultados
da consulta, será gerado um alerta. A Log Analytics fornece um ambiente altamente
configurável para determinar as condições para a geração de alertas, janelas de tempo
em que a consulta deve retornar os registros, janelas de tempo em que a consulta deve
ser executada e a ação a ser realizada quando a consulta retorna um alerta:
Vamos percorrer as etapas para configurar alertas por meio do Log Analytics:
1. A primeira etapa na configuração de um alerta é adicionar uma nova regra de
alerta do portal do Azure ou da automação do menu de alerta do recurso do
Log Analytics.
2. No painel resultante, selecione um escopo para a regra de alerta. O escopo
determina qual recurso deve ser monitorado para alertas — pode ser uma instância
de recurso, como uma conta de armazenamento do Azure, um tipo de recurso,
como uma VM do Azure, um grupo de recursos ou uma assinatura:
4. Por fim, crie um grupo de ação ou reutilize um grupo existente que determine
notificações sobre alertas para stakeholders. A seção Grupos de ação permite
configurar coisas que devem seguir um alerta. Em geral, deve haver uma ação
corretiva e/ou de notificação. O Log Analytics permite criar uma nova ação
de oito maneiras diferentes. Você pode combiná-las como quiser. Um alerta
executará todas ou qualquer uma das seguintes ações configuradas:
• Notificação por email/SMS/push/voz: isso envia uma notificação por
email/SMS/push/voz para os destinatários configurados.
• Webhooks: executa um processo externo arbitrário usando um mecanismo de
HTTP POST. Por exemplo, uma API REST pode ser executada. Caso contrário,
o Service Manager/APIs ServiceNow podem ser invocados para criar um tíquete.
• Funções do Azure: executa uma função do Azure, que passa a carga necessária
e executa a lógica que a carga contém.
• Aplicativos Lógicos: executa um fluxo de trabalho de Aplicativos Lógicos.
• Enviar email à função do Azure Resource Manager: envia emails a um titular de
uma função do Azure Resource Manager, como um proprietário, colaborador ou
leitor.
• Webhook seguro: executa um processo externo arbitrário usando um mecanismo
de HTTP POST. Os webhooks são protegidos com um provedor de identidade,
como o Azure Active Directory.
• Runbooks de automação: essa ação executa runbooks de Automação do Azure.
• ITSM: as soluções ITSM devem ser provisionadas antes do uso dessa opção. Elas
ajudam a conectar e enviar informações para sistemas ITSM.
5. Depois de toda essa configuração, você precisa fornecer os
valores Nome, Descrição e Gravidade para a regra de alerta para gerá-lo.
Resumo
A alta disponibilidade e a escalabilidade são preocupações de arquitetura muito
importantes. Quase todos os arquitetos e aplicações tentam implementar a alta
disponibilidade. O Azure é uma plataforma madura que compreende a necessidade
dessas preocupações de arquitetura em aplicações e fornece recursos para
implementá-las em vários níveis. Essas preocupações de arquitetura não são um
conceito tardio e devem fazer parte do desenvolvimento do ciclo de vida da aplicação,
começando pela própria fase de planejamento.
O monitoramento é um aspecto de arquitetura importante de qualquer solução.
Ele também é o primeiro passo para auditar uma aplicação corretamente. Ele permite
que as operações gerenciem uma solução, tanto reativamente quanto proativamente.
Ele oferece os registros necessários para solução e correção de problemas que podem
surgir em plataformas e aplicações. Há muitos recursos no Azure que são específicos
para implementar o monitoramento no Azure, outras nuvens e datacenters na
infraestrutura local. O Application Insights e o Log Analytics são dois dos recursos
mais importantes para isso. Evidentemente, o monitoramento é uma obrigatoriedade
de melhorar suas soluções e produtos ao inovar com base em insights derivados de
dados de monitoramento.
Este capítulo tratava apenas da disponibilidade, escalabilidade e monitoramento
de soluções; o próximo capítulo é sobre padrões de design relacionados a redes
virtuais, contas de armazenamento, regiões, zonas de disponibilidade e conjuntos de
disponibilidade. Ao criar soluções na nuvem, esses princípios são muito importantes
na criação de soluções econômicas com maior produtividade e disponibilidade.
Padrão de design –
3
redes, armazenamento,
mensagens e eventos
No capítulo anterior, você teve uma visão geral da nuvem do Azure e conheceu alguns
dos conceitos importantes relacionados a ela. Este capítulo apresenta padrões de nuvem
do Azure relacionados a redes virtuais, contas de armazenamento, regiões, zonas de
disponibilidade e conjuntos de disponibilidade. Esses são componentes importantes
que afetam a arquitetura final fornecida aos clientes em termos de custo, eficiência
e produtividade geral. O capítulo também discutirá brevemente os padrões de nuvem
que nos ajudam a implementar escalabilidade e performance em uma arquitetura.
Neste capítulo, vamos abordar os seguintes tópicos:
• Design de rede virtual do Azure
• Design de armazenamento do Azure
• Zonas de disponibilidade, regiões e conjuntos de disponibilidade do Azure
• Padrões de design do Azure relacionados a mensagens, performance e escalabilidade
70 | Padrão de design – redes, armazenamento, mensagens e eventos
Performance de aplicações
A performance de uma aplicação depende da rota de rede adotada pelas solicitações
e respostas para chegar ao seu destino e voltar. O local geograficamente mais perto
de você nem sempre é a região com a menor latência. Calculamos a distância em
quilômetros ou milhas, mas a latência baseia-se na rota que o pacote leva. Por exemplo,
uma aplicação implantada na Europa Ocidental para usuários no sudeste da Ásia não
terá uma performance tão boa quanto uma aplicação implantada na região do leste da
Ásia para usuários dessa região. Portanto, é muito importante que você arquitete suas
soluções na região mais próxima para fornecer a menor latência e, assim, a melhor
performance.
Redes virtuais
As redes virtuais devem ser consideradas como uma configuração de rede LAN física
em sua casa ou escritório. Conceitualmente, elas são iguais, embora a Rede Virtual do
Azure (VNet) seja implementada como uma rede definida por software com o apoio de
uma infraestrutura de rede física gigante.
Uma VNet é necessária para hospedar uma máquina virtual. Ela fornece um mecanismo
de comunicação segura entre os recursos do Azure para que eles se conectem entre
si. As VNets fornecem endereços IP internos aos recursos, facilitam o acesso e a
conectividade a outros recursos (incluindo máquinas virtuais na mesma rede virtual),
encaminham solicitações e fornecem conectividade com outras redes.
Uma rede virtual está contida em um grupo de recursos e é hospedada em uma região,
por exemplo, Europa Ocidental. Ela não pode abranger várias regiões, mas pode
abranger todos os datacenters dentro de uma região. Portanto, podemos abranger
redes virtuais em várias zonas de disponibilidade em uma região. Para a conectividade
entre regiões, as redes virtuais podem ser conectadas usando a conectividade de VNet
a VNet.
72 | Padrão de design – redes, armazenamento, mensagens e eventos
DNS dedicado
A VNet, por padrão, usa o DNS do Azure para resolver nomes em uma rede virtual, e isso
também permite a resolução de nomes na Internet. Se uma aplicação quiser um serviço
de resolução de nome dedicado ou se conectar aos datacenters na infraestrutura local,
ela deverá provisionar seu próprio servidor DNS, que deverá ser configurado na rede
virtual para a resolução de nomes ser bem-sucedida. Além disso, você pode hospedar
seu domínio público no Azure e gerenciar completamente os registros do portal do
Azure, sem a necessidade de gerenciar servidores DNS adicionais.
Número de redes virtuais
O número de redes virtuais é afetado por fatores como número de regiões, uso
de largura de banda pelos serviços, conectividade entre regiões e segurança. Ter
menos VNets maiores, em vez de várias VNets menores, eliminará a sobrecarga de
gerenciamento.
Número de sub-redes em cada rede virtual
As sub-redes fornecem isolamento dentro de uma rede virtual. Elas também podem
fornecer um limite de segurança. Grupos de segurança de rede (NSGs) podem ser
associados a sub-redes, restringindo ou permitindo o acesso específico a endereços
IP e portas. Os componentes da aplicação com requisitos de segurança e acessibilidade
separados devem ser colocados em sub-redes separadas.
Intervalos de IP para redes e sub-redes
Cada sub-rede tem um intervalo de IP. O intervalo de IP não deve ser tão grande de
modo que os IPs sejam subutilizados, mas, inversamente, não devem ser tão pequenos
de modo que as sub-redes sejam sufocadas devido à falta de endereços IP. Isso deve
ser considerado após a compreensão das necessidades futuras de endereços IP da
implantação.
O planejamento deve ser feito para intervalos e endereços IP para redes do Azure,
sub-redes e datacenters na infraestrutura local. Não deve haver sobreposição para
garantir conectividade e acessibilidade sem problemas.
74 | Padrão de design – redes, armazenamento, mensagens e eventos
Monitoramento
O monitoramento é uma faceta importante da arquitetura e deve ser incluído na
implantação geral. O Observador de Rede do Azure fornece recursos de registro
e diagnóstico com insights sobre a performance e a integridade da rede. Alguns
dos recursos do Observador de Rede do Azure são:
• Diagnosticar problemas de filtragem de tráfego de rede de ou para uma
máquina virtual
• Entender o próximo salto de rotas definidas pelo usuário
• Visualizar os recursos em uma rede virtual e seus relacionamentos
• Monitoramento de comunicação entre uma máquina virtual e um ponto de extremidade
• Captura de tráfego de uma máquina virtual
• Logs de fluxo de NSG, que registram informações relacionadas ao tráfego que
fluem por meio de um NSG. Esses dados ficarão no Armazenamento do Azure
para análise posterior
Ele também fornece logs de diagnóstico para todos os recursos de rede em um grupo
de recursos.
A performance da rede pode ser monitorada por meio do Log Analytics. A solução
de gerenciamento do Monitor de Performance da Rede fornece o recurso de
monitoramento de rede. Ele monitora a integridade, disponibilidade e acessibilidade
das redes. Esse recurso também é usado para monitorar a conectividade entre a nuvem
pública e as sub-redes da infraestrutura local que hospedam várias camadas de uma
aplicação multicamadas.
Considerações sobre segurança
As redes virtuais estão entre os primeiros componentes a serem acessados por qualquer
recurso no Azure. A segurança desempenha um papel importante na permissão ou
negação de acesso a um recurso. Os NSGs são os principais meios de segurança das
redes virtuais. Eles podem ser conectados a sub-redes de rede virtual, e cada fluxo
de entrada e saída é restringido, filtrado e permitido por eles.
Como muitas organizações têm uma nuvem híbrida, os recursos do Azure às vezes
precisam se comunicar ou se conectar com datacenters na infraestrutura local ou
vice-versa. As redes virtuais do Azure podem se conectar aos datacenters na
infraestrutura local usando a tecnologia VPN e o ExpressRoute. Na verdade, uma rede
virtual é capaz de se conectar a vários datacenters na infraestrutura local e a outras
regiões do Azure em paralelo. Como prática recomendada, cada uma dessas conexões
deve estar em suas sub-redes dedicadas dentro de uma rede virtual.
Agora que exploramos vários aspectos das redes virtuais, vamos discutir os benefícios delas.
76 | Padrão de design – redes, armazenamento, mensagens e eventos
Comunicação VNet
VNet1 do VNet2 do
Oeste dos EUA Oeste dos EUA
172.16.0.0/16 10.0.0.0/16
Azure Azure
Assinatura A Assinatura B
Figura 3.2: emparelhamento VNet de recursos com diferentes assinaturas usando gateways
Azure Azure
Assinatura A Assinatura B
Comunicação VNet
O emparelhamento VNet fornece uma conexão de baixa latência com alta largura
de banda e, como mostrado no diagrama, não estamos implantando gateways para
fazer a comunicação acontecer. Isso é útil para cenários como replicação de dados ou
failover. Como mencionado anteriormente, o emparelhamento usa a rede de backbone
da Microsoft, que elimina a necessidade da Internet pública.
Design da rede virtual | 79
Comunicação VNet
ExpressRoute
As conectividades VPNs site a site e ponto a site funcionam usando a Internet pública.
Elas criptografam o tráfego nas redes usando a tecnologia de VPN e certificados. No
entanto, há aplicações que devem ser implantadas com tecnologias híbridas — alguns
componentes no Azure, com outros em um datacenter na infraestrutura local — e, ao
mesmo tempo, não devem usar a Internet pública para se conectar a datacenters do
Azure e na infraestrutura local. O Azure ExpressRoute é a melhor solução para eles,
embora seja uma opção cara em comparação com os outros dois tipos de conexão.
Ele também é o provedor mais seguro e confiável, com maior velocidade e latência
reduzida porque o tráfego nunca atinge a Internet pública. O Azure ExpressRoute
pode ajudar a estender as redes na infraestrutura local para o Azure por meio de uma
conexão privada dedicada facilitada por um provedor de conectividade: Se sua solução
for de rede intensiva, por exemplo, uma aplicação corporativa transacional como o SAP,
o uso do ExpressRoute é altamente recomendável.
Circuito do ExpressRoute
É uma boa prática para as redes virtuais terem sub-redes separadas para cada componente
lógico com implantações separadas da perspectiva de segurança e isolamento.
Todos os recursos que implantamos no Azure exigem redes de uma forma ou de outra,
portanto, uma compreensão profunda da rede é necessária ao arquitetar soluções no
Azure. Outro elemento-chave é o armazenamento. Na próxima seção, você saberá mais
sobre o armazenamento.
84 | Padrão de design – redes, armazenamento, mensagens e eventos
Armazenamento
O Azure fornece uma solução de armazenamento durável, altamente disponível
e escalável por meio de serviços de armazenamento.
Categorias de armazenamento
O armazenamento tem duas categorias de contas de armazenamento:
• Uma camada de performance de armazenamento padrão que permite armazenar
tabelas, filas, arquivos, blobs e discos de máquina virtual do Azure.
• Uma camada de performance de armazenamento Premium que dá suporte aos
discos de máquina virtual do Azure no momento da gravação. O armazenamento
Premium fornece maior performance e IOPS do que o armazenamento padrão
geral. O armazenamento Premium está atualmente disponível como discos de
dados para máquinas virtuais com backup de SSDs.
Dependendo do tipo de dados que estão sendo armazenados, o armazenamento
é classificado em diferentes tipos. Vamos analisar os tipos de armazenamento e saber
mais sobre eles.
Tipos de armazenamento
O Azure fornece quatro tipos de serviços de armazenamento geral:
• Armazenamento de blobs do Azure: esse tipo de armazenamento é mais adequado
para dados não estruturados, como documentos, imagens e outros tipos de
arquivos. O armazenamento de blobs pode estar na camada de acesso frequente,
de acesso esporádico ou de arquivamento. A camada de acesso frequente
é destinada ao armazenamento de dados que precisam ser acessados com muita
frequência. A camada de acesso esporádico é para dados acessados com menos
frequência do que os da camada de acesso frequente. Eles são armazenados por
30 dias. Por fim, a camada de arquivamento é para fins de arquivamento, em que
a frequência de acesso é muito baixa.
• Armazenamento de tabelas do Azure: é um repositório de dados de atributo-
chave NoSQL. Ele deve ser usado para dados estruturados. Os dados são
armazenados como entidades.
• Armazenamento de filas do Azure: fornece armazenamento confiável de mensagens
para armazenar grandes quantidades delas. Essas mensagens podem ser acessadas
de qualquer lugar por meio de chamadas HTTP ou HTTPS. Uma mensagem de fila
pode ter até 64 KB de tamanho.
Armazenamento | 85
Recursos de armazenamento
O armazenamento do Azure é flexível. Isso significa que você pode armazenar apenas
alguns megabytes ou até mesmo petabytes de dados. Você não precisa pré-bloquear a
capacidade. Ela aumenta e diminui automaticamente. Os consumidores precisam pagar
apenas pelo uso real de armazenamento. Veja alguns dos principais benefícios do uso
do Armazenamento do Azure:
• O armazenamento do Azure é seguro. Ele só pode ser acessado usando
o protocolo SSL. Além disso, o acesso deve ser autenticado.
• O armazenamento do Azure fornece a facilidade de gerar um token de assinatura
de acesso seguro (SAS) no nível da conta que pode ser usado pelos clientes de
armazenamento para se autenticarem. Também é possível gerar tokens SAS de
nível de serviço individuais para blobs, filas, tabelas e arquivos.
• Os dados salvos no armazenamento do Azure podem ser criptografados.
Isso é conhecido como proteção de dados em repouso.
• A criptografia de disco do Azure é usada para criptografar o sistema operacional
e os discos de dados em máquinas virtuais IaaS. Criptografia do cliente (CSE)
e Criptografia do serviço de armazenamento (SSE): ambas são usadas para
criptografar dados no armazenamento do Azure. SSE é uma configuração do
armazenamento do Azure que garante que os dados sejam criptografados durante
a gravação no armazenamento e sejam descriptografados durante a leitura pelo
mecanismo de armazenamento. Isso garante que nenhuma alteração na aplicação
seja necessária para ativar a SSE. Na CSE, as aplicações cliente podem usar o SDK
de armazenamento para criptografar os dados antes que eles sejam enviados e
gravados no armazenamento do Azure. A aplicação cliente poderá descriptografá-
los posteriormente durante a leitura. Isso fornece segurança para dados em
trânsito e em repouso. A CSE depende de segredos do Azure Key Vault.
• O armazenamento do Azure é altamente disponível e durável. Isso significa que
o Azure sempre mantém várias cópias das contas dessa solução. A localização
e o número de cópias dependem da configuração de replicação.
86 | Padrão de design – redes, armazenamento, mensagens e eventos
A essa altura, você deve saber quais são os diferentes serviços de armazenamento
e como eles podem ser utilizados em suas soluções. Na próxima seção, analisaremos
os padrões de design e veremos como eles se relacionam com projetos arquitetônicos.
Padrões de mensagens
Os padrões de mensagens ajudam a conectar os serviços por meio de uma associação
livre. Isso significa que os serviços nunca interagem diretamente uns com os outros.
Em vez disso, um serviço gera e envia uma mensagem para um intermediário
(geralmente uma fila), e qualquer outro serviço que tenha interesse nessa mensagem
pode selecioná-la e processá-la. Não há comunicação direta entre o serviço remetente
e o destinatário. Essa dissociação não só torna os serviços e a aplicação geral mais
confiáveis, mas também mais robustos e tolerantes a falhas. Os destinatários podem
receber e ler mensagens em sua própria velocidade.
As mensagens ajudam a criar padrões assíncronos. O serviço de mensagens envolve
o envio de mensagens de uma entidade para outra. Essas mensagens são criadas
e encaminhadas por um remetente, salvas em um armazenamento durável e finalmente
consumidas pelos destinatários.
As principais preocupações de arquitetura abordadas pelos padrões de mensagens são:
• Durabilidade: as mensagens são salvas em um armazenamento durável, e as
aplicações podem lê-las depois que elas são recebidas em caso de failover.
• Confiabilidade: as mensagens ajudam a implementar a confiabilidade, pois elas
persistem no disco e nunca são perdidas.
• Disponibilidade das mensagens: as mensagens estão disponíveis para consumo
por aplicações após a restauração da conectividade e antes do tempo de
inatividade.
No entanto, se a fila não puder reordenar as mensagens, filas separadas podem ser
criadas para prioridades diferentes, e cada fila pode ter consumidores separados
associados a ela:
Embora esse padrão ajude a lidar com picos de demanda inesperada, ele não é a melhor
opção quando você está arquitetando um serviço com latência mínima. Falando em
latência, que é uma medição de performance, na próxima seção vamos nos concentrar
nos padrões de performance e escalabilidade.
Padrão de repetição
O padrão de repetição é um padrão extremamente importante que torna aplicações
e serviços mais resilientes a falhas temporárias. Imagine que você está tentando se
conectar e usar um serviço, e ele não está disponível por algum motivo. Se o serviço
for disponibilizado em breve, convém continuar tentando estabelecer uma conexão
bem-sucedida. Isso tornará a aplicação mais robusta, tolerante a falhas e estável. No
Azure, a maioria dos componentes funciona na internet, e a conexão de internet pode
gerar falhas temporárias intermitentemente. Como essas falhas podem ser corrigidas
em poucos segundos, a falha de uma aplicação não deve ser permitida. A aplicação deve
ser projetada de modo a poder tentar usar o serviço novamente várias vezes em caso de
falha e parar de tentar quando houver êxito. Ela também pode determinar que há uma
falha que levará tempo para ser corrigida.
Esse padrão deve ser implementado quando uma aplicação correr o risco de falhas
temporárias quando interagir com um serviço remoto ou acessar um recurso remoto.
Espera-se que essas falhas sejam passageiras e que a repetição de uma solicitação que
falhou anteriormente possa ter êxito em uma tentativa subsequente.
O padrão de repetição pode adotar estratégias de repetição diferentes com base na
natureza dos erros e da aplicação:
• Repetir um número fixo de vezes: isso indica que a aplicação tentará se
comunicar com o serviço por um número fixo de vezes antes de determinar que
houve uma falha e gerar uma exceção. Por exemplo, repetir três vezes a tentativa
de conexão com outro serviço. Se a conexão for bem-sucedida dentro dessas três
tentativas, toda a operação será bem-sucedida. Caso contrário, será gerada uma
exceção.
• Repetir com base na agenda: indica que a aplicação tentará se comunicar com
o serviço repetidamente por um número fixo de segundos ou minutos e aguardará
um número fixo de segundos ou minutos antes de tentar novamente. Por exemplo,
a aplicação tentará se conectar ao serviço a cada 3 segundos por 60 segundos. Se
houver êxito na conexão dentro desse tempo, toda a operação será bem-sucedida.
Caso contrário, será gerada uma exceção.
• Postergar e atrasar a repetição: indica que a aplicação tentará se comunicar com
o serviço repetidamente com base no cronograma e continuará adicionando um
atraso incremental nas tentativas subsequentes. Por exemplo, por um total de
60 segundos, a primeira nova tentativa ocorre após um segundo, a segunda ocorre
dois segundos após a anterior, a terceira ocorre quatro segundos após a tentativa
anterior e assim por diante. Isso reduz o número total de repetições.
Padrões de design de nuvem | 99
A Figura 3.17 ilustra o padrão de repetição. A primeira solicitação recebe uma resposta
HTTP 500, a segunda tentativa recebe novamente uma resposta HTTP 500 e, por fim,
a solicitação é bem-sucedida e recebe HTTP 200 como a resposta:
Resumo
Há vários serviços disponíveis no Azure, e a maioria pode ser combinada para criar
soluções reais. Este capítulo explicou os três serviços mais importantes fornecidos pelo
Azure: regiões, armazenamento e redes. Eles formam a base da maioria das soluções
implantadas em qualquer nuvem. Este capítulo forneceu detalhes sobre esses serviços
e como a configuração e o provisionamento deles pode afetar as decisões de design.
Considerações importantes para armazenamento e redes foram detalhadas neste
capítulo. As redes e o armazenamento fornecem muitas opções, e é importante escolher
uma configuração adequada com base nos seus requisitos.
Por fim, alguns dos padrões de design importantes relacionados a mensagens, como
consumidores concorrentes, fila de prioridade e nivelamento de carga, foram descritos.
Padrões como CQRS e limitação foram ilustrados, e outros padrões, como repetição
e disjuntor de circuito, também foram discutidos. Manteremos esses padrões como
a linha de base quando implantarmos nossas soluções.
No próximo capítulo, discutiremos como automatizar as soluções que vamos arquitetar.
À medida que avançamos no mundo da automação, todas as organizações querem
eliminar a sobrecarga da criação de recursos um por um, algo muito exigente. Como
a automação é a solução para isso, no próximo capítulo você aprenderá mais sobre ela.
Automatizar
4
a arquitetura no Azure
Todas as organizações desejam reduzir o esforço manual e o erro em suas atividades,
e a automação desempenha um papel importante para trazer previsibilidade,
padronização e consistência para a criação de um produto e as operações. A automação
tem sido o foco de quase todos os diretores de informações (CIO) e diretores digitais
para garantir que seus sistemas sejam altamente disponíveis, escaláveis, confiáveis
e capazes de atender às necessidades de seus clientes.
A automação se tornou mais proeminente com o advento da nuvem porque novos
recursos puderam ser provisionados rapidamente, sem a aquisição de recursos de
hardware. Portanto, as empresas de nuvem desejam a automação em quase todas as
suas atividades para reduzir o uso indevido, os erros, a governança, a manutenção
e a administração.
104 | Automatizar a arquitetura no Azure
Automação
A automação é necessária para o provisionamento, as operações, o gerenciamento
e o desprovisionamento de recursos de TI em uma organização. A Figura 4.1 mostra
uma visão mais detalhada sobre o que cada um desses casos de uso representa:
Automação do Azure
O Azure fornece um serviço chamado Automação do Azure, que é essencial para a
automação de processos, atividades e trabalhos, não só no Azure, como também na
infraestrutura local. Usando a Automação do Azure, as organizações podem automatizar
seus processos e trabalhos relacionados ao processamento, à destruição, às operações
e aos gerenciamento dos recursos na nuvem, em ambientes de TI, em plataformas e em
linguagens. Na Figura 4.2, podemos ver alguns recursos da Automação do Azure:
A primeira etapa para começar a usar a Automação do Azure é criar uma nova conta.
Depois que a conta for criada, todos os outros artefatos serão criados na conta.
A conta funciona como o principal recurso de nível superior que pode ser gerenciado
usando grupos de recursos do Azure e seu próprio plano de controle.
A conta deve ser criada em uma região, e toda a automação nessa conta é executada
em servidores nessa região.
É recomendável criar essas contas de execução mais tarde, em vez de criá-las durante a
criação da conta da Automação porque, se elas forem criadas durante a configuração da
conta da Automação, a Automação gerará os certificados e as entidades de serviço nos
bastidores com a configuração padrão. Se for necessário mais controle e configuração
personalizada para essas contas de execução, como o uso de um certificado existente
ou da entidade de serviço, as contas de execução devem ser criadas após a conta da
Automação.
Depois que a conta da Automação for criada, ela fornecerá um painel por meio do qual
vários cenários de automação podem ser habilitados.
Alguns dos cenários importantes que podem ser habilitados usando uma conta da
Automação estão relacionados a:
• Automação de processos
• Gerenciamento de configuração
• Gerenciamento de atualizações
A automação envolve a escrita de scripts que são reutilizáveis e genéricos para que
possam ser reutilizados em vários cenários. Por exemplo, um script de automação deve
ser genérico o suficiente para iniciar e interromper qualquer VM em qualquer grupo de
recursos em qualquer grupo de assinatura e gerenciamento. As informações de servidor
de VM de codificação, juntamente com nomes de grupo de recursos, assinatura e grupo
de gerenciamento, resultarão na criação de vários scripts semelhantes, e qualquer
alteração em um resultará na alteração de todos os scripts. É melhor criar um único
script para essa finalidade usando parâmetros e variáveis de script, e você deve garantir
que os valores sejam fornecidos pelo executor desses artefatos.
Vamos analisar em detalhes cada um dos cenários mencionados anteriormente.
Automação de processos
A automação de processos refere-se ao desenvolvimento de scripts que refletem
processos do mundo real. A automação de processos consiste em várias atividades,
em que cada atividade executa um trabalho discreto. Juntas, essas atividades formam
um processo completo. As atividades podem ser executadas com base em se a atividade
anterior foi executada com êxito ou não.
108 | Automatizar a arquitetura no Azure
Gerenciamento de configuração
O gerenciamento de configuração refere-se ao processo de gerenciamento da
configuração do sistema ao longo de seu ciclo de vida. A Configuração de Estado da
Automação do Azure é o serviço de gerenciamento de configuração do Azure que
permite que os usuários gravem, gerenciem e compilem a configuração do PowerShell
DSC para nós de nuvem e datacenters na infraestrutura local.
A Configuração de Estado da Automação do Azure permite gerenciar VMs do Azure,
VMs clássicas do Azure e máquinas físicas ou VMs (Windows/Linux) na infraestrutura
local, além de fornecer suporte para VMs em outros provedores de nuvem.
Uma das maiores vantagens da Configuração de Estado da Automação do Azure
é que oferece escalabilidade. Podemos gerenciar milhares de máquinas em uma única
interface de gerenciamento central. Podemos atribuir configurações a máquinas com
facilidade e verificar se elas estão em conformidade com a configuração desejada.
Outra vantagem é que a Automação do Azure pode ser usada como um repositório
para armazenar as configurações do Desired State Configuration (DSC) e, quando
necessário, elas podem ser usadas.
Na próxima seção, vamos falar sobre o gerenciamento de atualizações.
Conceitos relacionados à Automação do Azure | 109
Gerenciamento de atualizações
Como você já sabe, o gerenciamento de atualizações é de responsabilidade do
cliente para gerenciar atualizações e patches quando se trata de IaaS. O recurso
de gerenciamento de atualizações da Automação do Azure pode ser usado para
automatizar ou gerenciar atualizações e patches para suas VMs do Azure. Há vários
métodos pelos quais você pode habilitar o gerenciamento de atualizações em sua
VM do Azure:
• Na sua conta da Automação
• Navegando no portal do Azure
• Em um runbook
• Em uma VM do Azure
Habilitá-lo em uma VM do Azure é o método mais fácil. No entanto, se você tiver muitas
VMs e precisar habilitar o gerenciamento de atualizações, terá que considerar uma
solução escalável, como um runbook ou em uma conta de automação.
Agora que os cenários estão claros, vamos explorar os conceitos relacionados
à Automação do Azure.
Runbook
Um runbook da Automação do Azure é uma coleção de instruções de script que
representam uma única etapa na automação de processos ou uma automação de
processos completa. É possível invocar outros runbooks de um runbook pai, e esses
runbooks podem ser criados em várias linguagens de script. As linguagens que
oferecem suporte à criação de runbooks são as seguintes:
• PowerShell
• Python 2 (no momento da escrita)
• Fluxos de trabalho do PowerShell
• PowerShell Gráfico
• Fluxos de trabalho do PowerShell Gráfico
110 | Automatizar a arquitetura no Azure
A criação uma conta da Automação é muito fácil e pode ser feita no portal do Azure.
Na folha Todos os serviços, você pode encontrar Conta da Automação ou pesquisá-la
no portal do Azure. Como mencionado anteriormente, durante a criação, você terá
a opção de criar uma conta de execução. A Figura 4.4 mostra as entradas necessárias
para criar uma conta da Automação:
Contas de execução
Por padrão, as contas da Automação do Azure, não têm acesso a nenhum recurso
incluído em nenhuma assinatura do Azure, incluindo a assinatura em que estão
hospedados. Uma conta precisa de acesso a uma assinatura do Azure e seus recursos
a fim de gerenciá-las. Uma conta de execução é uma maneira de fornecer acesso
a assinaturas e os recursos nelas.
Esse é um exercício opcional. Pode haver no máximo uma conta de execução para
cada assinatura baseada no gerenciador de recursos e clássica. No entanto, uma
conta da Automação pode precisar se conectar a várias assinaturas. Nesses casos,
é recomendável criar recursos compartilhados para cada uma das assinaturas
e usá-los em runbooks.
Conceitos relacionados à Automação do Azure | 111
Essas contas de execução podem ser criadas usando o portal do Azure, o PowerShell
e a CLI. Para obter informações sobre como criar essas contas usando o PowerShell,
acesse https://docs.microsoft.com/azure/automation/manage-runas-account.
No caso da conta de execução do ARM, este script cria uma nova entidade de serviço
do Azure AD e um novo certificado e fornece permissões de RBAC de colaborador
para a entidade de serviço recém-criada na assinatura.
Trabalhos
O envio de uma solicitação de trabalho não está vinculado diretamente à execução
da solicitação de trabalho devido à arquitetura dissociada da Automação do Azure.
A vinculação entre eles é indireta usando um armazenamento de dados. Quando uma
solicitação para executar um runbook é recebida pela Automação, ela cria um novo
registro em seu banco de dados com todas as informações relevantes. Há outro serviço
em execução em vários servidores, conhecido como Hybrid Runbook Worker, no Azure,
que procura novas entradas adicionadas ao banco de dados para a execução de um
runbook. Depois que vê um novo registro, ele bloqueia o registro para que nenhum
outro serviço possa lê-lo e, em seguida, executa o runbook.
112 | Automatizar a arquitetura no Azure
Ativos
Os ativos da Automação do Azure referem-se a artefatos compartilhados que podem ser
usados em runbooks. Eles são mostrados na Figura 4.6:
Credenciais
As credenciais se referem aos segredos, como a combinação de nome de usuário/senha,
que pode ser usados para se conectar a outros serviços de integração que precisam
de autenticação. Essas credenciais podem ser usadas em runbooks usando o cmdlet
Get-AutomationPSCredential do PowerShell, juntamente com o nome associado:
$myCredential = Get-AutomationPSCredential -Name 'MyCredential'
Certificados
Os certificados referem-se ao certificado X. 509 que pode ser adquirido das autoridades
de certificação ou pode ser autoassinado. Os certificados são usados para fins
de identificação na Automação do Azure. Cada certificado tem um par de chaves
conhecidas como chaves privadas/públicas. A chave privada é usada para criar um
ativo de certificado na Automação do Azure, e a chave pública deve estar disponível
no serviço de destino. Usando a chave privada, a conta da Automação pode criar uma
assinatura digital e anexá-la à solicitação antes de enviá-la para o serviço de destino.
O serviço de destino pode obter os detalhes (o hash) da assinatura digital usando
a chave pública já disponível e verificar a identidade do remetente da solicitação.
Os ativos de certificado armazenam informações de certificado e chaves na Automação
do Azure. Esses certificados podem ser usados diretamente nos runbooks e também
são usados pelos ativos da conexão. A próxima seção mostra a forma de consumir
certificados em um ativo de conexão. O recurso de conexão principal do serviço do
Azure usa uma impressão digital do certificado para identificar o certificado que
deseja usar, enquanto outros tipos de conexão usam o nome do ativo de certificado
para acessar o certificado.
Um ativo de certificado pode ser criado fornecendo um nome e fazendo upload de um
certificado. É possível fazer upload de certificados públicos (arquivos .cer ), bem como
certificados privados (arquivos .pfx). A parte privada do certificado também tem uma
senha que deve ser usada antes de acessar o certificado.
Login-AzAccount
$certKey = [system.Convert]::ToBase64String($cert.GetRawCertData())
$cert.Thumbprint
Get-AzSubscription
116 | Automatizar a arquitetura no Azure
Para criar um ativo de conexão, a ID da aplicação pode ser obtida usando o cmdlet
Get-AzADServicePrincipal, e o resultado é mostrado na Figura 4.9:
Conexões
Os ativos de conexão são usados para criar informações de conexão para serviços
externos. Nesse sentido, até mesmo o Azure é considerado um serviço externo.
Os ativos de conexão têm todas as informações necessárias para se conectar com
êxito a um serviço. Há três tipos de conexão fornecidos pela Automação do Azure
e prontos para uso:
• Azure
• Certificado clássico do Azure
• Entidade de serviço do Azure
$connection = Get-AutomationConnection -name $connectionName
$subscriptionid = $connection.subscriptionid
$tenantid = $connection.tenantid
$applicationid = $connection.applicationid
$cretThumbprint = $connection.CertificateThumbprint
Login-AzureRMAccount -CertificateThumbprint $cretThumbprint
-ApplicationId $applicationid -ServicePrincipal -Tenant $tenantid
Get-AzureRMVM
O runbook usa o cmdlet Get-AutomationConnection para fazer referência ao ativo
de conexão compartilhada. O nome do ativo está no valor do parâmetro. Depois que
a referência ao ativo de conexão for feita, os valores da referência de conexão serão
preenchidos na variável $connection e, posteriormente, eles serão atribuídos a várias
outras variáveis.
O cmdlet Login-AzureRMAccount é autenticado com o Azure e fornece os valores obtidos
do objeto de conexão. Ele usa a entidade de serviço criada anteriormente neste capítulo
para autenticação.
Por fim, o runbook invoca o cmdlet Get-AzureRMVm para listar todas as VMs na
assinatura.
Criação e execução do runbook | 119
Por padrão, a Automação do Azure ainda fornece módulos AzureRM para trabalhar com
o Azure. Ela não instala módulos Az por padrão. Mais adiante, instalaremos um módulo
Az manualmente na conta da Automação do Azure e usaremos cmdlets em runbooks.
Criar um runbook
Um runbook pode ser criado no portal do Azure, acessando o item do menu Runbook
no painel de navegação à esquerda. Um runbook tem um nome e um tipo. O tipo
determina a linguagem de script usada para criar o runbook. Já abordamos as possíveis
linguagens e, neste capítulo, o PowerShell será usado principalmente para todos os
exemplos.
A criação de um runbook do PowerShell é exatamente igual à criação de um script do
PowerShell. Ele pode declarar e aceitar vários parâmetros: os parâmetros podem ter
atributos como tipos de dados, que são obrigatórios (assim como quaisquer atributos de
parâmetro do PowerShell). Ele pode invocar cmdlets do PowerShell cujos módulos estão
disponíveis e já carregados e declarados e pode invocar funções e retornar a saída.
Um runbook também pode invocar outro runbook. Ele pode invocar um runbook filho
em linha no processo e contexto originais ou em um processo e contexto separados.
A inovação de um runbook em linha é semelhante à invocação de um script do
PowerShell. O próximo exemplo invoca um runbook filho usando a abordagem em linha:
.\ConnectAzure.ps1 -connectionName "azureforarchitectsconnection"
Get-AzSqlServer
Criação e execução do runbook | 121
Usar módulos Az
Até agora, todos os exemplos usaram módulos AzureRM. Os runbooks anteriormente
mostrados serão reescritos para usar cmdlets no módulo Az.
Como mencionado anteriormente, os módulos Az não são instalados por padrão. Eles podem
ser instalados usando o item do menu Galeria de módulos na Automação do Azure.
Pesquise Az na galeria, e os resultados mostrarão vários módulos relacionados a ele.
Se o módulo Az for selecionado para ser importado e instalado, ele lançará um erro
informando que seus módulos dependentes não estão instalados e que eles devem ser
instalados antes de instalar o módulo atual. O módulo pode ser encontrado na folha
Galeria de módulos pesquisando Az, conforme mostrado na Figura 4.13:
$connection = Get-AutomationConnection -name $connectionName
$subscriptionid = $connection.subscriptionid
$tenantid = $connection.tenantid
$applicationid = $connection.applicationid
$cretThumbprint = $connection.CertificateThumbprint
Login-AzAccount -CertificateThumbprint $cretThumbprint
-ApplicationId $applicationid -ServicePrincipal
-Tenant $tenantid -SubscriptionId $subscriptionid
Get-AzVm
As duas últimas linhas do código são importantes. Elas estão usando cmdlets Az, em vez
de cmdlets AzureRM.
124 | Automatizar a arquitetura no Azure
Webhooks
Os webhooks ficaram famosos após o advento dos pontos de extremidade REST
e das cargas de dados JSON. Os webhooks são um conceito importante e uma
decisão arquitetônica na extensibilidade de qualquer aplicação. Os webhooks são
espaços reservados que são deixados em áreas especiais de uma aplicação para que
o usuário da aplicação possa preencher esses espaços reservados com URLs de ponto
de extremidade com lógica personalizada. A aplicação invocará a URL do ponto de
extremidade, passando automaticamente nos parâmetros necessários, e, em seguida,
executará o login disponível nele.
Os runbooks da Automação do Azure podem ser invocados manualmente no portal do
Azure. Eles também podem ser invocados usando cmdlets do PowerShell e a CLI do
Azure. Há SDKs disponíveis em várias linguagens que são capazes de invocar runbooks.
Os webhooks são uma das formas mais poderosas de invocar um runbook. É importante
observar que os runbooks que contêm a lógica principal nunca devem ser expostos
diretamente como um webhook. Eles devem ser chamados usando um runbook pai,
e o runbook pai deve ser exposto como um webhook. O runbook pai deve garantir que
as verificações apropriadas sejam feitas antes de invocar o runbook filho principal.
A primeira etapa para criar um webhook é criar um runbook normalmente, como feito
anteriormente. Depois que um runbook for criado, ele será exposto como um webhook.
Um novo runbook baseado no PowerShell chamado exposedrunbook é criado. Esse
runbook assume um único parâmetro, $WebhookData, do tipo de objeto. Ele deve ser
chamado verbatim. Esse objeto é criado pelo tempo de execução da Automação do
Azure e é fornecido ao runbook. O tempo de execução da Automação do Azure cria
esse objeto depois de obter os valores do cabeçalho de solicitação HTTP e o conteúdo
do corpo e preenche as propriedades RequestHeader e RequestBody deste objeto:
param(
[parameter(mandatory=$true)]
[object] $WebhookData
$webhookname = $WebhookData.WebhookName
$headers = $WebhookData.RequestHeader
$body = $WebhookData.RequestBody
126 | Automatizar a arquitetura no Azure
Write-output "webhook header data"
Write-Output $webhookname
Write-output $headers.message
Write-output $headers.subject
$connectionname = (ConvertFrom-Json -InputObject $body)
./connectAzure.ps1 -connectionName $connectionname[0].name
As três propriedades importantes deste objeto são WebhookName, RequestHeader
e RequestBody. Os valores são obtidos dessas propriedades e enviados para o fluxo
de saída pelo runbook.
O cabeçalho e o conteúdo do corpo podem ser qualquer coisa que o usuário forneça ao
invocar o webhook. Esses valores são preenchidos nas respectivas propriedades e são
disponibilizados no runbook. No exemplo anterior, há dois cabeçalhos definidos pelo
chamador, por exemplo, o cabeçalho de mensagem e status. O chamador também fornecerá
o nome da conexão compartilhada para ser usada como parte do conteúdo do corpo.
Depois que o runbook for criado, ele deverá ser publicado para que um webhook possa
ser criado. Depois de publicar o runbook, ao clicar no menu Webhook na parte superior,
você iniciará o processo de criação de um novo webhook para o runbook, conforme
mostrado na Figura 4.16:
Um nome para o webhook deve ser fornecido. Esse valor está disponível no runbook
usando o parâmetro WebhookData com o nome de propriedade WebhookName.
Invocar um webhook
Os webhooks são invocados como solicitações HTTP usando o método POST. Quando
um webhook é invocado, a solicitação HTTP tem como destino a Automação do Azure
para iniciar um runbook. Ele cria o objeto WebHookData, preenchendo-o com o cabeçalho
HTTP de entrada e os dados do corpo e cria um trabalho a ser escolhido por um
trabalhador do runbook. Essa chamada usa a URL do webhook gerada na etapa anterior.
O webhook pode ser invocado usando o Postman, por qualquer código que tenha
a capacidade de chamar um ponto de extremidade REST usando o método POST.
No próximo exemplo, o PowerShell será usado para invocar o webhook:
$uri = "https://s16events.azure-automation.net/
webhooks?token=rp0w93L60fAPYZQ4vryxl%2baN%2bS1Hz4F3qVdUaKUDzgM%3d"
$connection = @(
@{ name="azureforarchitectsconnection"}
)
$body = ConvertTo-Json -InputObject $ connection
$header = @{ subject="VMS specific to Ritesh";message="Get all virtual
machine details"}
Ao clicar no menu de saída, você verá a lista de VMs e SQL Server na assinatura.
Os próximos conceitos importantes na Automação do Azure são o Azure Monitor
e os Hybrid Workers, que serão explicados nas próximas seções detalhadamente.
Webhooks | 129
Selecione um recurso que deve ser monitorado e avaliado para geração de alertas.
Um grupo de recursos foi selecionado na lista e habilita automaticamente todos os
recursos no grupo de recursos. É possível remover as seleções de recursos do grupo
de recursos:
130 | Automatizar a arquitetura no Azure
Configure a condição e as regras que devem ser avaliadas. Selecione o nome do sinal
Desligar máquina virtual depois de selecionar Log de atividade como Tipo de sinal:
A seleção de um runbook de automação abrirá outra folha para selecionar uma conta
e um runbook apropriados da Automação do Azure. Vários runbooks estão disponíveis
e prontos para uso, e um deles foi usado aqui:
Hybrid Workers
Até agora, toda a execução dos runbooks foi principalmente na infraestrutura fornecida
pelo Azure. Os trabalhadores do runbook são os recursos de computação do Azure que
são provisionados pelo Azure com módulos e ativos apropriados implantados neles.
Todas as execuções de runbooks ocorrem nesta computação. No entanto, é possível que
os usuários tragam sua própria computação e executem o runbook nessa computação
fornecida pelo usuário, em vez da computação padrão do Azure.
Isso traz várias vantagens. Em primeiro lugar, toda a execução e seus logs são de
propriedade do usuário, e o Azure não tem visibilidade disso. Em segundo lugar,
a computação fornecida pelo usuário pode estar em qualquer nuvem, bem como
na infraestrutura local.
Adicionar um Hybrid Worker envolve várias etapas
• Em primeiro lugar, um agente precisa ser instalado na computação fornecida pelo
usuário. A Microsoft fornece um script que pode fazer o download e configurar
o agente automaticamente. Esse script está disponível em https://www.
powershellgallery.com/packages/New-OnPremiseHybridWorker/1.6.
O script também pode ser executado no PowerShell ISE como um administrador
no servidor que deve fazer parte do Hybrid Worker usando o seguinte comando:
Install-Script -Name New-OnPremiseHybridWorker -verbose
• Depois que o script for instalado, ele poderá ser executado juntamente com
parâmetros relacionados aos detalhes da conta da Automação do Azure.
Um nome também é fornecido para o Hybrid Worker. Se o nome já não existir,
ele será criado. Se existir, o servidor será adicionado ao Hybrid Worker existente.
É possível ter vários servidores em um único Hybrid Worker, e é possível ter vários
Hybrid Workers também:
New-OnPremiseHybridWorker.ps1 -AutomationAccountName bookaccount
-AAResourceGroupName automationrg '
-HybridGroupName "localrunbookexecutionengine" '
-SubscriptionID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Webhooks | 135
• Depois que a execução terminar, navegue de volta para o portal para ver uma
entrada para um Hybrid Worker, conforme mostrado na Figura 4.27:
• Se, neste momento, um runbook do Azure for executado com uma dependência do
módulo Az e um certificado personalizado carregado para o ativo do certificado,
ele falhará com erros relacionados ao módulo Az e o certificado não será
encontrado:
Depois que o script de configuração for importado, ele será compilado e armazenado
no servidor de pull do DSC usando o cmdlet Start-AzAutomationDscCompilationJob,
conforme mostrado a seguir:
Start-AzAutomationDscCompilationJob -ConfigurationName 'ensureiis'
-ResourceGroupName 'automationrg' -AutomationAccountName 'bookaccount'
É importante observar que a Contagem de nós na Figura 4.31 é 0. Isso significa que uma
configuração de nó chamada ensureiss.localhost existe, mas não é atribuída a nenhum
nó. A próxima etapa é atribuir a configuração ao nó.
Agora, temos uma configuração do DSC compilada disponível no servidor de pull do
DSC, mas não há nós para gerenciar. A próxima etapa é integrar as VMs e associá-las ao
servidor de pull do DSC. Isso é feito usando o cmdlet Register-AzAutomationDscNode:
Register-AzAutomationDscNode -ResourceGroupName 'automationrg'
-AutomationAccountName 'bookaccount' -AzureVMLocation "west
Europe" -AzureVMResourceGroup 'spark' -AzureVMName 'spark'
-ConfigurationModeFrequencyMins 30 -ConfigurationMode 'ApplyAndAutoCorrect'
Depois que a compilação for concluída, ela poderá ser atribuída aos nós. O status inicial
é Pendente, conforme mostrado na Figura 4.33:
Mais tarde, ao fazer logon no servidor e verificar se o servidor Web (IIS) está instalado,
você confirmará que ele está instalado, como pode ver na Figura 4.35:
Resumo
A Automação do Azure é um serviço importante no Azure e o único serviço de
gerenciamento de configurações e automação de processos. Este capítulo abordou
vários conceitos importantes relacionados à Automação do Azure e à automação de
processos, incluindo ativos compartilhados, como conexão, certificados e módulos.
Ele abordou a criação de runbooks, incluindo a invocação de runbooks de formas
diferentes, como relações entre pais e filhos, webhooks e uso do portal. O capítulo
também abordou a arquitetura e o ciclo de vida dos runbooks.
Também examinamos o uso de Hybrid Workers e, no final do capítulo, exploramos
o gerenciamento de configurações usando um servidor de pull do DSC e um
gerenciador de configurações local. Por fim, fizemos comparações com outras
tecnologias, como o Azure Functions.
No próximo capítulo, exploraremos a criação de políticas, bloqueios e marcas para
implantações do Azure.
Criar políticas,
5
bloqueios e marcas para
implantações do Azure
O Azure é uma plataforma de nuvem versátil. Os clientes podem não apenas criar
e implantar suas aplicações, mas também gerenciar e governar seus ambientes
ativamente. As nuvens geralmente seguem um paradigma pré-pago no qual um cliente
assina e pode implantar praticamente qualquer coisa nelas. Desde uma máquina
virtual básica até milhares de máquinas virtuais com unidades de manutenção de
estoque (SKUs) maiores. O Azure não impedirá que nenhum cliente provisione os
recursos que deseja provisionar. Em uma organização, pode haver um grande número
de pessoas com acesso à assinatura do Azure da organização. Há uma necessidade de
haver um modelo de governança em vigor para que somente os recursos necessários
sejam provisionados por pessoas com o direito de criá-los. O Azure fornece funções
de gerenciamento de recursos, como o Controle de acesso baseado em função do
Azure (RBAC), o Azure Policy, grupos de gerenciamento, Blueprints e bloqueios de
recursos para gerenciar e fornecer governança para os recursos.
146 | Criar políticas, bloqueios e marcas para implantações do Azure
Marcas do Azure
O Azure permite a marcação de recursos e grupos de recursos com pares nome-
valor. A marcação ajuda na categorização e organização lógica dos recursos. O Azure
também permite a marcação de 50 pares nome-valor para um grupo de recursos e seus
recursos. Embora um grupo de recursos funcione como um contêiner ou um espaço
reservado para recursos, a marcação de um grupo de recursos não significa a marcação
dos recursos nele. Os grupos de recursos e os recursos devem ser marcados com base
em seu uso, o que será explicado mais adiante nesta seção. As marcas são vinculadas
a uma assinatura, um grupo de recursos ou um recurso. O Azure aceita qualquer par
nome-valor e, por isso, é importante para uma organização definir os nomes e seus
possíveis valores.
148 | Criar políticas, bloqueios e marcas para implantações do Azure
Mas por que a marcação é importante? Em outras palavras, quais problemas podem
ser resolvidos usando a marcação? A marcação tem os seguintes benefícios:
• Categorização de recursos: uma assinatura do Azure pode ser usada por vários
departamentos e funções em uma organização. É importante para a equipe de
gerência identificar os proprietários de quaisquer recursos. A marcação ajuda
na atribuição de identificadores a recursos que possam ser usados representar
departamentos ou funções.
• Gerenciamento de informações para recursos do Azure: novamente, os recursos
do Azure em uma assinatura podem ser provisionados por qualquer pessoa que
tenha acesso a ela. As organizações desejam ter uma categorização adequada
dos recursos em vigor para atender às políticas de gerenciamento de informações.
Essas políticas podem ser baseadas no gerenciamento do ciclo de vida da
aplicação, como o gerenciamento dos ambientes de desenvolvimento, teste
e produção. Elas também podem ser baseadas no uso ou em quaisquer outras
prioridades. Cada organização tem sua própria maneira de definir as categorias
de informações, e o Azure atende a essa necessidade com as marcas.
• Gerenciamento de custos: a marcação no Azure pode ajudar a identificar recursos
com base na sua categorização. As consultas podem ser executadas no Azure para
identificar o custo por categoria, por exemplo. Por exemplo, o custo dos recursos
no Azure para o desenvolvimento de um ambiente para o departamento financeiro
e o departamento de marketing pode ser facilmente verificado. Além disso,
o Azure também fornece informações de cobrança com base em marcas. Isso
ajuda a identificar as taxas de consumo de equipes, departamentos ou grupos.
Projeto
Aprovador Ambiente
Mantenedor Proprietário
Recurso do
Azure
Data de
desativação Departamento
Data de
Data de início
correção
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/
deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources": [
{
"apiVersion": "2019-06-01",
"type": "Microsoft.Storage/storageAccounts",
"name": "[concat('storage', uniqueString(resourceGroup().id))]",
"location": "[resourceGroup().location]",
"tags": {
"Dept": "Finance",
"Environment": "Production"
},
"sku": {
"name": "Standard_LRS"
},
"kind": "Storage",
"properties": { }
}
]
}
Azure Policy
Na seção anterior, falamos sobre a aplicação de marcas para implantações do Azure.
As marcas são ótimas para organizar recursos; no entanto, há algo mais que não foi
discutido: como as organizações garantem que as marcas sejam aplicadas para cada
implantação? Deve haver uma imposição automática das marcas do Azure a recursos
e grupos de recursos. Não há nenhuma verificação do Azure para garantir que marcas
apropriadas sejam aplicadas a recursos e grupos de recursos. Isso não é apenas
específico das marcas; aplica-se à configuração de qualquer recurso no Azure. Por
exemplo, você pode querer restringir onde seus recursos podem ser provisionados
geograficamente (somente para a região Leste dos EUA, por exemplo).
Talvez você já tenha percebido que esta seção é sobre a formulação de um modelo
de governança no Azure. A governança é um elemento importante no Azure porque
garante que todos que acessarem o ambiente do Azure estejam cientes dos processos
e das prioridades organizacionais. Ela também ajuda a deixar os custos sob controle. Ela
ajuda na definição das convenções organizacionais para o gerenciamento de recursos.
Cada política pode ser criada usando várias regras, e várias políticas podem ser
aplicadas a uma assinatura ou a um grupo de recursos. Se as regras forem atendidas,
as políticas poderão executar várias ações. Uma ação poderia ser negar uma transação
em andamento, auditar (uma transação o que significa gravar em logs e permitir sua
conclusão) ou acrescentar metadados a uma transação se eles estiverem ausentes.
As políticas podem estar relacionadas à convenção de nomenclatura de recursos,
marcação de recursos, tipos de recursos que podem ser provisionados, localização
de recursos ou qualquer combinação delas.
Agora que você conhece a finalidade e o caso de uso do Azure Policy, vamos avançar
e abordar políticas internas, a linguagem de políticas e políticas personalizadas.
Políticas internas
O Azure fornece um serviço para criar políticas personalizadas. No entanto, ele
também fornece algumas políticas prontas para uso que podem ser usadas para a
governança. Essas políticas estão relacionadas a localizações permitidas, tipos de
recursos permitidos e marcas. Mais informações sobre essas políticas internas podem
ser encontradas em https://docs.microsoft.com/azure/azure-resource-manager/
resource-manager-policy.
Linguagem de políticas
As políticas no Azure usam a linguagem JSON para definir e descrever as políticas.
Há duas etapas na adoção de políticas. A política deve ser definida e, em seguida,
deve ser aplicada e atribuída. As políticas têm escopo e podem ser aplicadas no
nível da assinatura, do grupo de recursos e do grupo de gerenciamento.
As políticas são definidas usando blocos if...then que são semelhantes a qualquer
linguagem de programação popular. O bloco if é executado para avaliar as condições e,
com base no resultado dessas condições, o bloco then é executado:
{
"if": {
<condition> | <logical operator>
},
"then": {
"effect": "deny | audit | append"
}
}
As políticas do Azure não só permitem condições if simples, mas várias
condições if podem ser associadas logicamente para criar regras complexas.
Essas condições podem ser associadas usando operadores AND, OR e NOT:
• A sintaxe AND exige que todas as condições sejam verdadeiras.
• A sintaxe OR exige que uma das condições seja verdadeira.
• A sintaxe NOT inverte o resultado da condição.
154 | Criar políticas, bloqueios e marcas para implantações do Azure
"containsKey": "application"
},
{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts"
}
]
},
Na verdade, esses operadores lógicos podem ser combinados da seguinte maneira:
"if": {
"allOf": [
{
"not": {
"field": "tags",
"containsKey": "application"
}
},
{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts"
}
]
},
Isso é muito semelhante ao uso das condições if em linguagens de programação
populares como C# e Node.js
If ("type" == "Microsoft.Storage/storageAccounts") {
Deny
}
É importante observar que não há uma ação allow, embora haja uma ação Deny. Isto
significa que as regras políticas devem ser escritas com a possibilidade de negação
na mente. As regras devem avaliar as condições e Negar a ação se as condições forem
atendidas.
156 | Criar políticas, bloqueios e marcas para implantações do Azure
Campos permitidos
Os campos permitidos nas condições ao definir as políticas são os seguintes:
• Nome: o nome do recurso para aplicar a política. Isso é muito específico e aplicável
a um recurso de acordo com seu uso.
• Tipo: o tipo de recurso, como Microsoft.Compute/VirtualMachines. Por exemplo,
isso aplicaria a política a todas as instâncias de máquinas virtuais.
• Localização: a localização (ou seja, a região do Azure) de um recurso.
• Marcas: as marcas associadas a um recurso.
• Aliases de propriedade: propriedades específicas de recursos. Essas propriedades
são diferentes para diferentes recursos.
Na próxima seção, você aprenderá mais sobre como proteger recursos em ambientes
de produção.
Bloqueios do Azure
Os bloqueios são mecanismos para interromper determinadas atividades nos recursos.
O RBAC fornece direitos a usuários, grupos e aplicações em um determinado escopo.
Há funções RBAC prontas para uso, como proprietário, colaborador e leitor. Com a
função de colaborador, é possível excluir ou modificar um recurso. Como tais atividades
podem ser impedidas apesar do usuário ter a função de colaborador? Insira bloqueios
do Azure.
Os bloqueios do Azure podem ajudar de duas maneiras:
• Eles podem bloquear recursos de modo que eles não possam ser excluídos, mesmo
que você tenha acesso de proprietário.
• Eles podem bloquear recursos de forma que não possam ser excluídos nem ter sua
configuração modificada.
Para criar ou excluir bloqueios de recursos, o usuário deve ter acesso às ações
Microsoft.Authorization/* ou Microsoft.Authorization/locks/*. Você também pode
dar permissões granulares. Os proprietários e os administradores de acesso do usuário
terão acesso à criação ou exclusão de bloqueios por padrão.
Se você quer saber quais são as palavras-chave de Microsoft.Authorization/* e
Microsoft.Authorization/locks/*, você saberá mais sobre elas na próxima seção.
Agora, vamos ver o Azure RBAC.
Azure RBAC
O Azure fornece autenticação para seus recursos por meio do Azure Active Directory.
Uma vez que uma identidade tenha sido autenticada, os recursos a que a identidade
terá acesso deverão ser decididos. Isso é conhecido como autorização. A autorização
avalia as permissões que foram oferecidas a uma identidade. Qualquer pessoa que tenha
acesso a uma assinatura do Azure deve receber apenas as permissões necessárias para
que seu trabalho específico possa ser realizado, e nada mais.
A autorização também é popularmente conhecida como RBAC. O RBAC no Azure se refere
à atribuição de permissões a identidades em um escopo. O escopo pode ser um grupo de
gerenciamento, uma assinatura, um grupo de recursos ou recursos individuais.
Azure RBAC | 159
Há mais funções fornecidas pelo Azure, mas elas são específicas de recursos, como as
funções de colaborador de rede e gerenciador de segurança.
Para obter todas as funções fornecidas pelo Azure para todos os recursos, execute
o comando Get-AzRoleDefinition no console do PowerShell.
Cada definição de função tem determinadas ações permitidas e não permitidas. Por
exemplo, a função de proprietário tem todas as ações permitidas e nenhuma ação
é proibida:
PS C:\Users\riskaria> Get-AzRoleDefinition -Name "Owner"
Name : Owner
Id : 8e3af657-a8ff-443c-a75c-2fe8c4bcb635
IsCustom : False
Description : permite gerenciar tudo, incluindo o acesso a recursos.
Actions : {*}
NotActions : {}
DataActions : {}
NotDataActions : {}
AssignableScopes : {/}
Cada função consiste em várias permissões. Cada recurso fornece uma lista de
operações. As operações com o suporte de um recurso pode ser obtida usando
o cmdlet Get-AzProviderOperation. Esse cmdlet obtém o nome do provedor
e do recurso para recuperar as operações:
160 | Criar políticas, bloqueios e marcas para implantações do Azure
Operation
---------
Microsoft.Insights/Metrics/Action
Microsoft.Insights/Register/Action
Microsoft.Insights/Unregister/Action
Microsoft.Insights/ListMigrationDate/Action
Microsoft.Insights/MigrateToNewpricingModel/Action
Microsoft.Insights/RollbackToLegacyPricingModel/Action
.
.
.
.
.
.
.
.
Microsoft.Insights/PrivateLinkScopes/PrivateEndpointConnectionProxies/Read
Microsoft.Insights/PrivateLinkScopes/PrivateEndpointConnectionProxies/Write
Microsoft.Insights/PrivateLinkScopes/PrivateEndpointConnectionProxies/Delete
Microsoft.Insights/PrivateLinkScopeOperationStatuses/Read
Microsoft.Insights/DiagnosticSettingsCategories/Read
Funções personalizadas
O Azure fornece inúmeras funções genéricas de saída prontas para uso, como
proprietário, colaborador e leitor, bem como funções especializadas específicas de
recursos, como colaborador de máquina virtual. Ter uma função de leitura atribuída a
um usuário/grupo ou entidade de serviço significará que as permissões do leitor serão
atribuídas ao escopo. O escopo pode ser um recurso, um grupo de recursos ou uma
assinatura. Da mesma forma, um colaborador seria capaz de ler, bem como modificar
o escopo atribuído. Um colaborador de máquina virtual seria capaz de modificar as
configurações de máquina virtual, e não outras configurações de recursos. No entanto,
há momentos em que as funções existentes podem não atender aos nossos requisitos.
Nesses casos, o Azure permite a criação de funções personalizadas. Elas podem ser
atribuídos a usuários, grupos e entidades de serviço e são aplicáveis a recursos, grupos
de recursos e assinaturas.
Há um recurso de visualização disponível no portal do Azure que você pode usar para
criar funções RBAC personalizadas do próprio portal do Azure. Você tem a opção de
criar funções do zero, clonar uma função existente ou começar a escrever o manifesto
JSON. A Figura 5.3 mostra a folha Criar uma função personalizada, que está disponível
na seção IAM > +Adicionar:
Azure Blueprints
Você estará familiarizado com a palavra "blueprint", que se refere ao plano ou projeto
que é usado por um arquiteto para arquitetar uma solução. Da mesma forma, no Azure,
os arquitetos de nuvem podem aproveitar o Azure Blueprints para definir um conjunto
de recursos repetíveis do Azure que seguem as convenções, os processos e os padrões
de uma organização.
Um exemplo de implementação de recursos de governança do Azure | 163
Os objetos do Azure Blueprint são replicados para várias regiões e têm o suporte
do Azure Cosmos DB. A replicação ajuda a fornecer acesso consistente aos recursos
e a manter os padrões da organização, independentemente de qual região você esteja
implantando.
O Azure Blueprints é composto de vários artefatos, e você pode encontrar a lista
de artefatos com suporte aqui: https://docs.microsoft.com/azure/governance/
blueprints/overview#blueprint-definition.
O Blueprints pode ser criado no portal do Azure, no Azure PowerShell, na CLI do Azure,
nas APIs REST ou em modelos do ARM.
Na próxima seção, vamos ver um exemplo de como implementar recursos de
governança do Azure. Serviços e recursos como RBAC, Azure Policy e bloqueios
de recursos do Azure serão usados no exemplo.
Contexto
Company Inc é uma empresa internacional que está implementando uma solução de
mídias sociais em uma plataforma IaaS do Azure. Ela usa servidores Web e servidores de
aplicativos implantados em redes e máquinas virtuais do Azure. O SQL do Azure Server
age como o banco de dados de back-end.
Azure Policy
A empresa deve implementar o Azure Policy para garantir que seus usuários sempre
provisionem recursos de acordo com as diretrizes da empresa.
As políticas no Azure regem vários aspectos relacionados à implantação de recursos.
As políticas também governarão as atualizações após a implantação inicial. Algumas das
políticas que devem ser implementadas são fornecidas na seção a seguir.
Implantações em determinados locais
Os recursos e implantações do Azure só podem ser executados para determinados
locais escolhidos. Não seria possível implantar recursos em regiões fora da política.
Por exemplo, as regiões permitidas são a Europa Ocidental e o Leste dos EUA.
Não deve ser possível implantar recursos em qualquer outra região.
Marcas de recursos e grupos de recursos
Todos os recursos do Azure, incluindo os grupos de recursos, obrigatoriamente
terão marcas atribuídas a eles. As marcas incluirão, no mínimo, detalhes sobre
o departamento, o ambiente, os dados de criação e o nome do projeto.
Logs de diagnóstico e Application insights para todos os recursos
Todos os recursos implantados no Azure devem ter logs de diagnóstico e logs
de aplicações habilitados sempre que possível.
Resumo | 165
Bloqueios do Azure
Uma empresa deve implementar bloqueios do Azure para garantir que os recursos
cruciais não sejam excluídos acidentalmente. Cada recurso que é crucial para o
funcionamento de uma solução precisa ser bloqueado. Isso significa que até mesmo os
administradores dos serviços em execução no Azure não têm a capacidade de excluir
esses recursos. A única maneira de excluir um recurso é remover o bloqueio primeiro.
Você também deve observar que:
Todos os ambientes de produção e pré-produção, além dos ambientes de
desenvolvimento e teste, seriam bloqueados para exclusão.
Todos os ambientes de desenvolvimento e teste que têm instâncias únicas também
seriam bloqueados para exclusão.
Todos os recursos relacionados à aplicação Web seriam bloqueados para exclusão para
todos os ambientes do desenvolvimento à produção.
Todos os recursos compartilhados serão bloqueados para exclusão, independentemente
do ambiente.
Resumo
Neste capítulo, você aprendeu que a governança e o gerenciamento de custos estão
entre algumas das principais prioridades para empresas que estão migrando para
a nuvem. Ter uma assinatura pré-paga do Azure com um esquema pré-pago pode
prejudicar o orçamento da empresa, pois qualquer um que tenha acesso à assinatura
poderá provisionar quantos recursos quiser. Alguns recursos são gratuitos, mas outros
são caros.
Você também aprendeu que é importante que as organizações mantenham o controle
sobre seus custos de nuvem. As marcas ajudam na geração de relatórios de cobrança.
Esses relatórios podem ser baseados em departamentos, projetos, proprietários ou
qualquer outro critério. O custo e a governança são igualmente importantes. O Azure
fornece bloqueios, políticas e RBAC para implementar a governança adequada. As
políticas garantem que as operações de recursos possam ser negadas ou auditadas,
os bloqueios garantem que os recursos não possam ser modificados nem excluídos,
e o RBAC garante que os funcionários tenham as permissões corretas para realizar
seus trabalhos. Com todos esses recursos, as empresas podem ter governança sólida
e controle de custos para suas implantações do Azure.
No próximo capítulo, vamos abordar o gerenciamento de custos no Azure. Explicaremos
diferentes métodos de otimização, gerenciamento de custos e APIs de cobrança.
Gerenciamento
6
de custos para
soluções do Azure
No capítulo anterior, discutimos marcas, políticas e bloqueios e como eles podem ser
aproveitados do ponto de vista da conformidade. As marcas nos permitem adicionar
metadados aos nossos recursos; elas também nos ajudam no gerenciamento lógico
de recursos. No portal do Azure, podemos filtrar recursos com base em marcas.
Se presumirmos que há um grande número de recursos, o que é bastante comum
nas empresas, a filtragem nos ajudará a gerenciar facilmente nossos recursos.
Outro benefício das marcas é que elas podem ser usadas para filtrar relatórios de
cobrança ou relatórios de uso em termos de marcas. Neste capítulo, vamos explorar
o gerenciamento de custos para soluções do Azure.
O principal motivo pelo qual as corporações estão migrando para a nuvem é a economia
de custos. Não há um custo inicial para ter uma assinatura do Azure. O Azure fornece
uma assinatura pré-paga, em que a cobrança é baseada no consumo. O Azure mede o
uso de recursos e fornece faturas mensais. Não há um limite superior para o consumo
do Azure. Como estamos em uma nuvem pública, o Azure (como qualquer outro
provedor de serviços) tem alguns limites rígidos e flexíveis sobre o número de recursos
que podem ser implantados. Os limites flexíveis podem ser aumentados ao trabalhar
com o Suporte do Azure. Alguns recursos têm um limite rígido. Os limites de serviço
podem ser encontrados em https://docs.microsoft.com/azure/azure-resource-
manager/management/azure-subscription-service-limitse o limite padrão varia de
acordo com o tipo de assinatura que você tem.
168 | Gerenciamento de custos para soluções do Azure
Observe que, se a sua cobrança for gerenciada por um CSP, você não terá acesso a esse
recurso. Os clientes de CSP podem exibir seus custos no esquema pré-pago se fizerem
a transição de suas assinaturas herdadas de CSP para o plano do Azure. Vamos discutir
o plano do Azure e a plataforma de Comércio Moderno mais adiante no capítulo.
Clicar no menu Análise de custo nesta folha fornece um painel interativo abrangente,
usando o custo que pode ser analisado com diferentes dimensões e medidas:
Figura 6.4: analisando os custos de assinatura por meio da opção Análise de custo
O painel não só mostra o custo atual, mas também prevê o custo e o divide com base
em várias dimensões. Nome do serviço, Localização e Nome do grupo de recursos
são fornecidas por padrão, mas podem ser alteradas para outras dimensões também.
Sempre haverá um escopo associado a cada exibição. Alguns dos escopos disponíveis
são conta de cobrança, grupo de gerenciamento, assinatura e grupo de recursos.
Você pode mudar o escopo dependendo do nível que deseja analisar.
O menu Orçamentos à esquerda nos permite configurar o orçamento para um melhor
gerenciamento de custos e fornece recursos de alerta caso o custo real exceda as
estimativas de orçamento:
Noções básicas de cobrança | 173
Você precisa preencher os detalhes da sua função no AWS e outros detalhes para obter
as informações sobre custos, conforme mostrado na Figura 6.5. Se você não souber
como criar a política e a função no AWS, consulte https://docs.microsoft.com/azure/
cost-management-billing/costs/aws-integration-set-up-configure#create-a-role-
and-policy-in-aws:
Parte da análise de custo também está disponível na folha Assinaturas. Na seção Visão
geral, você pode ver os recursos e seu custo. Além disso, há outro gráfico, em que você
pode ver o gasto atual, a previsão e o crédito de saldo (se estiver usando uma assinatura
baseada em crédito).
Noções básicas de cobrança | 175
Ao clicar em qualquer um dos custos na Figura 6.7, você será redirecionado para a seção
Gerenciamento de Custos – Análise de Custo. Há várias dimensões no Gerenciamento
de Custos com as quais você pode agrupar os dados para análise. As dimensões
disponíveis variarão com base no escopo selecionado. Algumas das dimensões
comumente usadas são:
• Tipos de recursos
• Grupo de recursos
• Marca
• Localização do recurso
• ID do recurso
• Categoria do medidor
• Subcategoria do medidor
• Serviço
176 | Gerenciamento de custos para soluções do Azure
No início do capítulo, dissemos que as marcas podem ser usadas para o gerenciamento
de custos. Por exemplo, digamos que você tenha uma marca chamada Departamento
com valores de TI, RH e Finanças. A marcação adequada dos recursos ajudará você
a entender os custos incorridos por cada departamento. Você também pode fazer
o download do relatório de custos como um arquivo CSV, Excel ou PNG usando
o botão Download.
Além disso, o Gerenciamento de Custos oferece suporte a várias exibições. Você pode
criar seu próprio painel e salvá-lo. Os clientes de EA recebem o benefício adicional do
conector de Gerenciamento de Custos ou do Power BI. Com o conector, os usuários
podem obter as estatísticas de uso para o Power BI e criar visualizações.
Até agora, temos discutido como podemos acompanhar nosso uso com o
Gerenciamento de Custos. Na próxima seção, exploraremos como o faturamento
funciona para os serviços que usamos.
Faturamento
O sistema de cobrança do Azure também fornece informações sobre faturas que são
geradas mensalmente.
Ao clicar no menu Faturas, será exibida uma lista de todas as faturas geradas e ao clicar
em qualquer uma das faturas, você verá detalhes sobre essa fatura. A Figura 6.8 mostra
como as faturas são exibidas no portal do Azure:
Há dois tipos de faturas: um é para serviços do Azure, como SQL, Máquinas Virtuais
e Rede. O outro é para Azure Marketplace e Reservas. O Azure Marketplace fornece
serviços de parceiros de diferentes fornecedores para clientes. Vamos falar sobre as
Reservas do Azure posteriormente.
Por padrão, para uma assinatura pré-paga, o administrador da conta tem acesso
às faturas. Se quiser, ele pode delegar acesso a outros usuários, como a equipe de
finanças da organização, escolhendo a opção Acessar a fatura na Figura 6.8. Além disso,
o administrador da conta pode escolher os endereços de email para os quais deseja
enviar as cópias das faturas.
A opção Fatura por Email não está disponível para o Plano de Suporte agora.
Como alternativa, você pode visitar o portal de Contas e fazer o download da fatura.
A Microsoft está lentamente migrando desse portal e a maioria dos recursos estão
sendo preteridos à medida que são integrados ao portal do Azure.
Até agora, discutimos assinaturas e como o faturamento é feito. Algo novo que foi
introduzido pela Microsoft é o Comércio Moderno. Com essa nova experiência de
comércio, o processo e a experiência de compra foram simplificados. Vamos ver em
detalhes o Comércio Moderno e saber como ele é diferente da plataforma herdada
que discutimos até agora.
Todas as assinaturas que discutimos até agora eventualmente serão migradas para
um Plano do Azure, que é o futuro do Azure. Agora que você entende as noções
básicas do Comércio Moderno, vamos discutir outro tópico que desempenha um
papel muito importante ao arquitetar soluções. A maioria dos serviços tem limites por
padrão; alguns desses limites podem ser aumentados, enquanto alguns são rígidos. Ao
arquitetar uma solução, precisamos garantir que haja uma cota ampla. O planejamento
de capacidade é uma parte vital do design arquitetônico. Na próxima seção, você
aprenderá mais sobre limites em assinaturas.
Uso e cotas
Como mencionado na seção anterior, o planejamento de capacidade precisa ser uma
das primeiras etapas ao arquitetar uma solução. Precisamos verificar se a assinatura
tem cota suficiente para acomodar os novos recursos que estamos arquitetando.
Caso contrário, durante a implantação, poderemos enfrentar problemas.
Cada assinatura possui um limite de cota para cada tipo de recurso. Por exemplo, pode
haver no máximo 10 endereços IP públicos provisionados com uma conta Microsoft
MSDN. Da mesma forma, todos os recursos têm um limite máximo padrão para cada
tipo de recurso. Esses números de tipos de recursos para uma assinatura podem ser
aumentados ao contatar o Suporte do Azure ou ao clicar no botão Solicitar Aumento na
folha Uso + Cota na página Assinatura.
Considerando o número de recursos em cada região, será um desafio examinar a lista.
O portal fornece opções para filtrar o conjunto de dados e procurar o que queremos.
Na Figura 6.9, você pode ver que, se filtrarmos a localização para EUA Central e
definirmos o provedor de recursos como Microsoft.Storage, poderemos confirmar
quais cotas estão disponíveis para contas de armazenamento:
Figura 6.9: uso e cota para uma localização e um provedor de recursos específicos
180 | Gerenciamento de custos para soluções do Azure
Você pode ver claramente na Figura 6.9 que não criamos nenhuma conta de
armazenamento na região EUA Central, e isso nos deixa com uma cota de 250 contas.
Se a solução que estamos arquitetando exigir mais de 250 contas, precisaremos clicar
em Solicitar Aumento, para entrar em contato com o Suporte do Azure.
• API de Uso de Recursos do Azure: esta API pode ser usada com uma assinatura
de EA ou uma assinatura pré-paga para fazer o download dos dados de uso.
• API de RateCard de Recursos do Azure: só é aplicável ao Web Direct; os EAs não
têm suporte. Os clientes do Web Direct podem usá-la para fazer o download de
tabelas de preços.
• API de Download de Faturas do Azure: só é aplicável a clientes do Web Direct.
Ela é usada para fazer o download de faturas programaticamente.
Os nomes podem parecer familiares, e a diferença é apenas o ponto de extremidade que
estamos chamando. Para as APIs de Cobrança Empresarial do Azure, a URL começará
com https://consumption.azure.com e, para as APIs de Consumo do Azure, a URL
começará com https://management.azure.com. Você pode diferenciá-las dessa forma.
Na próxima seção, você verá um novo conjunto de APIs que são usadas especificamente
pelo Gerenciamento de Custos.
184 | Gerenciamento de custos para soluções do Azure
Como o Comércio Moderno está expandindo o MCA, há um novo conjunto de APIs que
podem ser exploradas aqui: https://docs.microsoft.com/rest/api/billing.
Você pode ter notado que não mencionamos o CSP em nenhum desses cenários.
No CSP, o cliente não tem acesso à cobrança, pois ela é gerenciada por um parceiro,
portanto, as APIs não são expostas. No entanto, uma transição para um Plano do Azure
permitiria que o cliente de CSP usasse as APIs de Gerenciamento de Custos do Azure
para ver as taxas de varejo.
Qualquer linguagem de programação ou script pode usar essas APIs e combiná-las
para criar soluções completas e abrangentes de cobrança. Na próxima seção, vamos
nos concentrar na calculadora de preços do Azure, que ajudará o cliente ou o arquiteto
a entender o custo de uma implantação.
Você pode selecionar o suporte que deseja, dependendo de seus requisitos. Por fim,
o custo total estimado é exibido:
Práticas recomendadas | 187
Práticas recomendadas
Os arquitetos precisam compreender sua arquitetura e os componentes do Azure
utilizados. Com base em monitoramento ativo, auditorias e uso, eles devem determinar
a melhor oferta da Microsoft em termos de SKU, tamanho e recursos. Esta seção
detalhará algumas das práticas recomendadas a serem adotadas de uma perspectiva
de otimização de custos.
Governança do Azure
A Governança do Azure pode ser definida como um conjunto de processos ou
mecanismos que podem ser aproveitados para manter o controle total sobre os
recursos implantados no Azure. Estes são alguns dos pontos principais:
Resumo
Neste capítulo, aprendemos a importância do gerenciamento de custos e da
administração ao trabalhar em um ambiente de nuvem. Também abordamos as várias
opções de preços do Azure e os vários recursos de otimização de preços que o Azure
oferece. O gerenciamento de custos de um projeto é fundamental principalmente
porque a despesa mensal pode ser muito baixa, mas pode aumentar se os recursos não
forem monitorados de forma periódica. Os arquitetos de nuvem devem projetar suas
aplicações de forma econômica. Eles devem usar os recursos do Azure, os SKUs, as
camadas e os tamanhos adequados e saber quando iniciar, parar, escalar verticalmente
e horizontalmente , transferir dados e muito mais. O gerenciamento de custos
adequado garantirá que as despesas reais correspondam às despesas orçamentárias.
No próximo capítulo, analisaremos vários recursos do Azure relacionados a serviços
de dados, como SQL do Azure, Cosmos DB e fragmentação.
Soluções OLTP
7
do Azure
O Azure fornece os serviços Infraestrutura como Serviço (IaaS) e Plataforma como
Serviço (PaaS). Esses tipos de serviços fornecem diferentes níveis e controles sobre
armazenamento, computação e redes às organizações. Armazenamento é o recurso
usado ao trabalhar com o armazenamento e a transmissão de dados. O Azure fornece
muitas opções para armazenar dados, como Armazenamento de Blobs do Azure,
Armazenamento de tabelas, Cosmos DB, Banco de Dados SQL do Azure, Azure
Data Lake Storage e muito mais. Embora algumas dessas opções sejam destinadas
a armazenamento, análise e apresentação de big data, há outras que são destinadas
a aplicações que processam transações. O SQL do Azure é o recurso principal no
Azure que funciona com dados transacionais.
194 | Soluções OLTP do Azure
Iniciaremos este capítulo analisando o que são aplicações OLTP e listando os serviços
OLTP do Azure e seus casos de uso.
Aplicações OLTP
Como mencionado anteriormente, as aplicações OLTP são aplicações que ajudam no
processamento e gerenciamento de transações. Algumas das implementações OLTP
mais prevalentes podem ser encontradas em vendas no varejo, sistemas de transações
financeiras e entrada de ordens. Essas aplicações executam captura, processamento,
recuperação, modificação e armazenamento de dados. No entanto, não param por aqui.
As aplicações OLTP tratam essas tarefas de dados como transações. As transações têm
algumas propriedades importantes e as aplicações OLTP são responsáveis por essas
propriedades. Essas propriedades são agrupadas com o acrônimo ACID. Vamos
discuti-las em detalhes:
• Atomicidade: esta propriedade informa que uma transação deve consistir em
instruções e que todas as instruções devem ser concluídas com êxito ou nenhuma
instrução deve ser executada. Se várias instruções forem agrupadas, elas formarão
uma transação. Atomicidade significa que cada transação é tratada como a menor
unidade única de execução que é concluída com êxito ou falha.
• Consistência: esta propriedade se concentra no estado dos dados em um banco
de dados. Ela determina que qualquer alteração no estado deve ser completa e
baseada nas regras e restrições do banco de dados, e que atualizações parciais não
devem ser permitidas.
Serviços de nuvem do Azure | 195
Agora que você sabe o que são aplicações OLTP, vamos discutir a função dos bancos
de dados relacionais nessas aplicações.
A Figura 7.1 mostra os diversos recursos e opções disponíveis para a criação de bancos
de dados baseados no SQL Server no Azure.
Novamente, uma pesquisa rápida por banco de dados no portal do Azure fornece vários
recursos e aqueles marcados na Figura 7.2 podem ser usados para aplicações OLTP:
A Figura 7.2 mostra os recursos fornecidos pelo Azure que podem hospedar dados em
vários bancos de dados, incluindo os seguintes:
• Bancos de dados MySQL
• Bancos de dados MariaDB
• Bancos de dados PostgreSQL
• Cosmos DB
Modelos de implantação
Os modelos de implantação no Azure são classificados com base no nível de
gerenciamento ou controle. Cabe ao usuário selecionar qual nível de gerenciamento ou
controle ele prefere; ele pode optar por controle total usando serviços como Máquinas
Virtuais ou pode usar serviços gerenciados em que as coisas serão gerenciadas pelo
Azure para ele.
Há dois modelos de implantação para implantar bancos de dados no Azure:
• Bancos de dados em Máquinas Virtuais do Azure (IaaS)
• Bancos de dados hospedados como serviços gerenciados (PaaS)
Modelos de implantação | 197
Esta opção não fornece nenhuma alta disponibilidade pronta para uso, a menos que
vários servidores sejam provisionados. Ela também não fornece recursos para escala
automática, a menos que a automação personalizada dê suporte a ela.
A disaster recovery também é responsabilidade do cliente. Os servidores devem ser
implantados em várias regiões conectadas por meio de serviços como emparelhamento
global, gateways de VPN, ExpressRoute ou WAN Virtual. É possível que essas máquinas
virtuais sejam conectadas a um datacenter na infraestrutura local por meio de VPNs site
a site ou do ExpressRoute sem ter nenhuma exposição ao mundo externo.
Esses bancos de dados também são conhecidos como bancos de dados não gerenciados.
Por outro lado, os bancos de dados hospedados com o Azure, diferentes das máquinas
virtuais, são gerenciados pelo Azure e são conhecidos como serviços gerenciados.
Na próxima seção, vamos abordá-los em detalhes.
198 | Soluções OLTP do Azure
Se você estiver se perguntando quando usar o quê, analise uma comparação de recursos
entre o Banco de Dados SQL e a Instância Gerenciada do SQL. Uma comparação
completa de recursos está disponível em https://docs.microsoft.com/azure/azure-sql/
database/features-comparison.
A seguir, vamos abordar alguns dos recursos do Banco de Dados SQL. Vamos começar
com os recursos da aplicação.
Recursos da aplicação
O Banco de Dados SQL do Azure fornece vários recursos específicos da aplicação que
atendem aos diferentes requisitos dos sistemas OLTP:
• Armazenamento colunar: este recurso permite o armazenamento de dados em
um formato colunar, em vez de um formato de linha.
• OLTP in-memory: geralmente, os dados são armazenados em arquivos de back-
end no SQL e são obtidos desses arquivos quando necessários para a aplicação.
Por outro lado, o OLTP in-memory coloca todos os dados na memória e não há
latência na leitura do armazenamento de dados. O armazenamento de dados
OLTP in-memory no SSD proporciona a melhor performance possível para
o SQL do Azure.
• Todos os recursos do SQL Server na infraestrutura local.
Agora que você sabe como a alta disponibilidade é tratada, vamos avançar para
o próximo recurso: backups.
Backups
O Banco de Dados SQL do Azure também fornece recursos para fazer backup
automático de bancos de dados e armazená-los em contas de armazenamento.
Este recurso é importante principalmente nos casos em que um banco de dados
se torna corrompido ou um usuário exclui uma tabela de forma acidental. Ele está
disponível no nível do servidor, conforme mostrado na Figura 7.6:
Os arquitetos devem preparar uma estratégia de backup para que os backups possam
ser usados em momentos de necessidade. Ao configurar backups, garanta que a
frequência deles não seja nem muito baixa nem muito alta. Com base nas necessidades
da empresa, um backup semanal ou até mesmo um backup diário deve ser configurado,
ou ainda mais frequentemente do que isso, se necessário. Esses backups podem ser
usados para fins de restauração.
Os backups ajudarão na continuidade dos negócios e na recuperação de dados.
Você também pode usar a replicação geográfica para recuperar os dados durante
uma falha regional. Na próxima seção, vamos abordar a replicação geográfica.
202 | Soluções OLTP do Azure
Replicação geográfica
O Banco de Dados SQL do Azure também fornece o benefício de ser capaz de replicar
um banco de dados para uma região diferente, também conhecida como região
secundária; isso é totalmente baseado no plano que você está escolhendo. O banco
de dados na região secundária pode ser lido por aplicações. O Banco de Dados SQL
do Azure permite bancos de dados secundários legíveis. Esta é uma ótima solução de
continuidade dos negócios, pois um banco de dados legível está disponível a qualquer
momento. Com a replicação geográfica, é possível ter até quatro regiões secundárias
de um banco de dados em diferentes regiões ou na mesma região. Com a replicação
geográfica, também é possível fazer o failover para um banco de dados secundário em
caso de desastres. A replicação geográfica é configurada no nível do banco de dados,
conforme mostrado na Figura 7.7:
Se você rolar para baixo nesta tela, as regiões que podem agir como secundárias são
listadas, conforme mostrado na Figura 7.8:
Escalabilidade
O Banco de Dados SQL do Azure fornece escalabilidade vertical adicionando mais
recursos (como computação, memória e IOPS). Isso pode ser feito aumentando
o número de Unidades de Taxa de Transferência de Banco de Dados (DTUs)
ou de recursos de computação e armazenamento no caso do modelo vCore:
Segurança
A segurança é um fator importante para qualquer serviço e solução de banco de dados.
O SQL do Azure fornece segurança de nível empresarial para o SQL do Azure, e esta
seção listará alguns dos recursos de segurança importantes no SQL do Azure.
Firewall
Por padrão, o Banco de Dados SQL do Azure não fornece acesso a nenhuma solicitação.
Os endereços IP de origem devem ser explicitamente aceitos para acessar o SQL Server.
Há uma opção para permitir que todos os serviços baseados no Azure também acessem
um banco de dados SQL. Essa opção inclui máquinas virtuais hospedadas no Azure.
O firewall pode ser configurado no nível do servidor, em vez do nível do banco de dados.
A opção Permitir o acesso aos serviços do Azure permite que todos os serviços, incluindo
máquinas virtuais, acessem um banco de dados hospedado em um servidor lógico.
Banco de Dados SQL do Azure | 205
Por padrão, essa opção será desativada por motivos de segurança; habilitá-la permitiria
o acesso de todos os serviços do Azure:
Por fim, na folha de configuração do SQL do Azure Server, deve ser adicionada uma
rede virtual existente que tenha um ponto de extremidade de serviço Microsoft.Sql
habilitado:
Figura 7.13: adicionando uma rede virtual com o ponto de extremidade de serviço Microsoft.Sql
A chave é uma chave RSA 2048 e deve existir no cofre. O SQL Server vai descriptografar
os dados no nível da página quando quiser lê-los e enviá-los para o chamador; em
seguida, ele vai criptografá-los depois de gravá-los no banco de dados. Nenhuma
alteração nas aplicações é necessária e isso é completamente transparente para elas:
Instância Única
Os bancos de dados de Instância Única são hospedados como um banco de dados único
em um servidor lógico único. Esses bancos de dados não têm acesso aos recursos
completos fornecidos pelo SQL Server. Cada banco de dados é isolado e portátil.
As instâncias únicas oferecem suporte aos modelos de compra baseados em vCPU
e DTU que discutimos anteriormente.
Pools elásticos | 211
Pools elásticos
Um pool elástico é um contêiner lógico que pode hospedar vários bancos de dados
em um único servidor lógico. Os pools elásticos estão disponíveis nos modelos de
compra baseados em vCore e DTU. O modelo de compra baseado em vCPU é o método
padrão e recomendado de implantação, em que você terá a liberdade de escolher seus
recursos de computação e armazenamento com base nos seus workloads de negócios.
Conforme mostrado na Figura 7.16, você pode selecionar a quantidade de núcleos
e armazenamento necessária para o seu banco de dados:
Além disso, na parte superior da figura anterior, há uma opção que diz Procurando
básico, padrão, premium? (Looking for basic, standard, premium?) Se você
selecioná-la, o modelo será alternado para o modelo de DTU.
Os SKUs disponíveis para pools elásticos no modelo baseado em DTU são os seguintes:
• Básico
• Padrão
• Premium
A Figura 7.17 mostra a quantidade máxima de DTUs que podem ser provisionadas para
cada SKU:
Todos os recursos discutidos para as instâncias únicas do SQL do Azure também estão
disponíveis para pools elásticos. No entanto, a escalabilidade horizontal é um recurso
adicional que permite a fragmentação. A fragmentação se refere ao particionamento
vertical ou horizontal de dados e ao armazenamento desses dados em bancos de dados
separados. Também é possível ter escala automática de bancos de dados individuais em
um pool elástico consumindo mais DTUs do que as alocadas para esse banco de dados.
Os pools elásticos também proporcionam outra vantagem em termos de custo.
Você verá em uma seção posterior que o Banco de Dados SQL do Azure é precificado
usando DTUs, e as DTUs são provisionadas assim que o serviço do SQL Server é
provisionado. As DTUs são cobradas independentemente de serem consumidas ou não.
Se houver vários bancos de dados, será possível colocá-los em pools elásticos e eles
compartilharem as DTUs entre si.
Todas as informações para implementar a fragmentação com pools elásticos do SQL
do Azure foram fornecidas em https://docs.microsoft.com/azure/sql-database/
sql-database-elastic-scale-introduction.
Instância Gerenciada | 213
Instância Gerenciada
A Instância Gerenciada é um serviço exclusivo que fornece um servidor SQL gerenciado
semelhante ao que está disponível nos servidores na infraestrutura local. Os usuários
têm acesso ao mestre, modelo e outros bancos de dados do sistema. A Instância
Gerenciada é ideal quando há vários bancos de dados e clientes migrando suas
instâncias para o Azure. A Instância Gerenciada consiste em vários bancos de dados.
O Banco de Dados SQL do Azure fornece um novo modelo de implantação conhecido
como Instância Gerenciada do Banco de Dados SQL do Azure que oferece quase 100%
de compatibilidade com o Mecanismo de Banco de Dados da Edição Enterprise do SQL
Server. Esse modelo fornece uma implementação de rede virtual nativa que aborda os
problemas de segurança habituais e é um modelo de negócios altamente recomendado
para clientes do SQL Server na infraestrutura local. A Instância Gerenciada permite
que os clientes existentes do SQL Server façam o "lift and shift" de suas aplicações na
infraestrutura local para a nuvem com alterações mínimas em aplicações e bancos de
dados, preservando todos os recursos de PaaS ao mesmo tempo. Esses recursos de PaaS
reduzem drasticamente a sobrecarga de gerenciamento e o custo total de propriedade,
conforme mostrado na Figura 7.18:
Por outro lado, o SKU padrão fornece de 10 a 300 DTUs com, no máximo, 250 GB de
dados. Como você pode ver aqui, cada DTU custa cerca de 991 rupias ou em torno
de US$ 1,40:
Figura 7.21: resumo de custos para o número selecionado de DTUs no SKU Padrão
Além disso, há um limite no número máximo de bancos de dados que podem ser criados
em um único pool elástico. Os limites completos podem ser revisados aqui: https://
docs.microsoft.com/azure/azure-sql/database/resource-limits-dtu-elastic-pools.
Na Figura 7.25, você pode ver no gráfico à esquerda que, à medida que a quantidade
de DTUs aumenta, a disponibilidade de recursos também aumenta linearmente; no
entanto, com os preços de vCPU (no gráfico à direita), é possível escolher configurações
independentes para cada banco de dados:
Com isso, podemos concluir nossa cobertura do Banco de Dados SQL do Azure.
Discutimos diferentes métodos de implantação, recursos, preços e planos relacionados
ao Banco de Dados SQL do Azure. Na próxima seção, vamos abordar o Cosmos DB, que
é um serviço de banco de dados NoSQL.
Azure Cosmos DB
O Cosmos DB é o serviço de banco de dados verdadeiramente entre regiões, altamente
disponível, distribuído e multimodelo do Azure. Ele é ideal para você, se quiser que
sua solução seja altamente responsiva e sempre disponível. Como ele é um banco de
dados multimodelo entre regiões, podemos implantar as aplicações mais próximas da
localização do usuário e obter baixa latência e alta disponibilidade.
Com o clique de um botão, a taxa de transferência e o armazenamento podem ser
escalados em qualquer número de regiões do Azure. Há alguns modelos de bancos
de dados diferentes para cobrir quase todos os requisitos de bancos de dados não
relacionais, incluindo:
1. SQL (documentos)
2. MongoDB
3. Cassandra
4. Tabela
5. Gráfico Gremlin
220 | Soluções OLTP do Azure
A hierarquia de objetos no Cosmos DB começa com a conta do Cosmos DB. Uma conta
pode ter vários bancos de dados e cada banco de dados pode ter vários contêineres.
Dependendo do tipo de banco de dados, o contêiner pode consistir em documentos,
como no caso do SQL; dados de chave-valor semiestruturados no Armazenamento
de tabelas; ou entidades e relacionamentos entre essas entidades, ao usar Gremlin
e Cassandra para armazenar dados NoSQL.
O Cosmos DB pode ser usado para armazenar dados OLTP. Ele responde por ACID no
que diz respeito a dados de transações, com algumas ressalvas.
O Cosmos DB sustenta os requisitos de ACID no nível do documento único. Isso significa que
os dados em um documento, quando atualizados, excluídos ou inseridos, terão atomicidade,
consistência, isolamento e durabilidade mantidos. No entanto, além dos documentos, a
consistência e a atomicidade precisam ser gerenciadas pelo próprio desenvolvedor.
Os preços do Cosmos DB podem ser encontrados aqui: https://azure.microsoft.com/
pricing/details/cosmos-db.
A Figura 7.26 mostra alguns recursos do Azure Cosmos DB:
Azure Cosmos DB
Distribuição global Escala elástica Baixa latência garantida Cinco modelos de consistência SLAs abrangentes
Na próxima seção, vamos abordar alguns dos principais recursos do Azure Cosmos DB.
Recursos
Alguns dos principais benefícios do Azure Cosmos DB são:
• Distribuição global: aplicações altamente responsivas e altamente disponíveis
podem ser criadas no mundo todo usando o Azure Cosmos DB. Com a ajuda da
replicação, as réplicas de dados podem ser armazenadas em regiões do Azure
que estejam próximas dos usuários, proporcionando assim menos latência e
distribuição global.
• Replicação: você pode aceitar ou recusar a replicação para uma região a qualquer
momento que desejar. Digamos que você tenha uma réplica dos seus dados
disponível na região Leste dos EUA, e sua organização esteja planejando encerrar
seus processos no Leste dos EUA e migrar para o Sul do Reino Unido. Com apenas
alguns cliques, a região Leste dos EUA pode ser removida e a região Sul do Reino
Unido pode ser adicionada à conta para replicação.
• AlwaysOn: o Cosmos DB fornece 99,999% de alta disponibilidade para leitura e
gravação. O failover regional de uma conta do Cosmos DB para outra região pode
ser invocado por meio do portal do Azure ou programaticamente. Isso garante
a continuidade dos negócios e o planejamento de disaster recovery para a sua
aplicação durante uma falha regional.
• Escalabilidade: o Cosmos DB oferece escalabilidade elástica incomparável para
gravações e leituras em todo o mundo. A resposta de escalabilidade é enorme,
o que significa que você pode escalar de milhares para centenas de milhões de
solicitações/segundo com uma única chamada à API. O interessante é que isso é
feito em todo o mundo, mas você precisa pagar apenas pela taxa de transferência
e pelo armazenamento. Esse nível de escalabilidade é ideal para lidar com picos
inesperados.
• Baixa latência: como mencionado anteriormente, replicar cópias de dados para
locais mais próximos dos usuários reduz drasticamente a latência; isso significa
que os usuários podem acessar seus dados em milissegundos. O Cosmos DB
garante menos de 10 ms de latência para leituras e gravações em todo o mundo.
• Economias de TCO: como o Cosmos DB é um serviço totalmente gerenciado, o
nível de gerenciamento exigido do cliente é baixo. Além disso, o cliente não precisa
configurar datacenters em todo o mundo para acomodar usuários de outras regiões.
• SLA: ele oferece um SLA de 99,999% de alta disponibilidade.
• Suporte para APIs de Software Open Source (OSS): o suporte para APIs de OSS
é outra vantagem adicional do Cosmos DB. Ele implementa APIs para Cassandra,
Mongo DB, Gremlin e Armazenamento de tabelas do Azure.
222 | Soluções OLTP do Azure
Cenários de uso
Se a sua aplicação envolve altos níveis de leituras e gravações de dados em uma escala
global, o Cosmos DB é a escolha ideal. Os tipos comuns de aplicações que têm esses
requisitos incluem aplicações Web, móveis, de jogos e de Internet das Coisas. Essas
aplicações se beneficiariam da alta disponibilidade, baixa latência e presença global do
Cosmos DB.
Além disso, o tempo de resposta oferecido pelo Cosmos DB é quase em tempo real.
Os SDKs do Cosmos DB podem ser aproveitados para desenvolver aplicações para iOS
e Android usando a estrutura Xamarin.
Alguns dos jogos populares que usam o Cosmos DB são The Walking Dead: No Man's
Land da Next Games e Halo 5: Guardians.
Uma lista completa de cenários de uso e exemplos pode ser encontrada aqui: https://
docs.microsoft.com/azure/cosmos-db/use-cases.
O Cosmos DB é o serviço popular no Azure para armazenar dados semiestruturados
como parte de aplicações OLTP. Eu poderia escrever um livro inteiro sobre os recursos
e as funcionalidades do Cosmos DB. A intenção desta seção foi fornecer uma introdução
ao Cosmos DB e à função que ele desempenha no tratamento de aplicações OLTP.
Resumo
Neste capítulo, você aprendeu que o Banco de Dados SQL do Azure é um dos principais
serviços do Azure. Uma infinidade de clientes estão usando esse serviço hoje e ele
oferece todos os recursos empresariais necessários para um sistema de gerenciamento
de bancos de dados de missão crítica.
Você descobriu que há vários tipos de implantação para o Banco de Dados SQL do
Azure, como Instância Única, Instância Gerenciada e pools elásticos. Os arquitetos
devem realizar uma avaliação completa de seus requisitos e escolher o modelo de
implantação apropriado. Depois de escolher um modelo de implantação, os arquitetos
devem escolher uma estratégia de preços entre DTUs e vCPUs. Eles também devem
configurar todos os requisitos de segurança, disponibilidade, disaster recovery,
monitoramento, performance e escalabilidade no Banco de Dados SQL do Azure
em relação aos dados.
No próximo capítulo, discutiremos como criar aplicações seguras no Azure.
Abordaremos as práticas e os recursos de segurança da maioria dos serviços.
Arquitetar aplicações
8
seguras no Azure
No capítulo anterior, discutimos os serviços de dados do Azure. Como estamos
lidando com dados confidenciais, a segurança é uma grande preocupação. A segurança
é, sem dúvida, o requisito não funcional mais importante para que os arquitetos
implementem. As empresas enfatizam muito a implementação correta de sua estratégia
de segurança. Na verdade, a segurança é uma das principais preocupações de quase
todos os stakeholders no desenvolvimento, na implantação e no gerenciamento de
uma aplicação. Ela se torna ainda mais importante quando uma aplicação é criada
para implantação na nuvem.
226 | Arquitetar aplicações seguras no Azure
Para que você entenda como pode proteger suas aplicações no Azure dependendo
da natureza da implantação, os seguintes tópicos serão abordados neste capítulo:
• Entender a segurança no Azure
• Segurança no nível da infraestrutura
• Segurança no nível da aplicação
• Autenticação e autorização em aplicações do Azure
• Trabalhar com OAuth, Azure Active Directory e outros métodos de autenticação
usando identidade federada, incluindo provedores de identidade de terceiros,
como o Facebook
• Entender identidades gerenciadas e usá-las para acessar recursos
Segurança
Como mencionado anteriormente, a segurança é um elemento importante para
qualquer software ou serviço. A segurança adequada deve ser implementada para que
uma aplicação só possa ser usada por pessoas que tenham permissão para acessá-la,
e os usuários não devem ser capazes de executar operações para as quais não possuem
autorização. Da mesma forma, todo o mecanismo de solicitação-resposta deve ser
criado usando métodos que garantam que apenas as partes pretendidas possam
entender as mensagens e deve garantir que seja fácil detectar se as mensagens foram
adulteradas ou não.
Pelos motivos a seguir, a segurança no Azure é ainda mais importante. Em primeiro
lugar, as organizações que implantam suas aplicações não estão no controle total
do hardware e das redes subjacentes. Em segundo lugar, a segurança precisa ser
incorporada a todas as camadas, incluindo hardware, redes, sistemas operacionais,
plataformas e aplicações. Quaisquer omissões ou configurações incorretas podem
tornar uma aplicação vulnerável a intrusos. Por exemplo, talvez você tenha ouvido falar
da recente vulnerabilidade que afetou as reuniões no Zoom e permitiu que os hackers
gravassem reuniões mesmo quando o host da reunião havia desabilitado a gravação para
os participantes. Fontes alegam que milhões de contas do Zoom foram vendidas na dark
web. A empresa tomou as medidas necessárias para resolver essa vulnerabilidade.
A segurança é uma grande preocupação nos dias de hoje, especialmente ao hospedar
aplicações na nuvem, e pode levar a consequências catastróficas se não for tratada de
forma adequada. Portanto, é necessário entender as práticas recomendadas envolvidas
na proteção dos seus workloads. Estamos progredindo na área de DevOps, onde as
equipes de desenvolvimento e operações colaboram de forma eficaz com a ajuda de
ferramentas e práticas, e a segurança também tem sido uma grande preocupação.
Segurança | 227
Para acomodar princípios e práticas de segurança como uma parte vital do DevOps sem
afetar a produtividade e a eficiência geral do processo, uma nova cultura conhecida
como DevSecOps foi introduzida. O DevSecOps nos ajuda a identificar problemas
de segurança no início do estágio de desenvolvimento, em vez de mitigá-los após o
envio. Em um processo de desenvolvimento que tem a segurança como um princípio
fundamental de todos os estágios, o DevSecOps reduz o custo de contratação de
profissionais de segurança em um estágio posterior para encontrar falhas de segurança
com o software.
Proteger uma aplicação significa que entidades desconhecidas e não autorizadas não
podem acessá-la. Também significa que a comunicação com a aplicação é segura e não
adulterada. Isso inclui as seguintes medidas de segurança:
• Autenticação: a autenticação verifica a identidade de um usuário e garante que
a identidade determinada possa acessar a aplicação ou o serviço. Ela é executada
no Azure usando o OpenID Connect, que é um protocolo de autenticação criado
no OAuth 2.0.
• Autorização: a autorização permite e estabelece permissões que uma identidade
pode realizar na aplicação ou no serviço. A autorização é realizada no Azure
usando OAuth.
• Confidencialidade: a confidencialidade garante que a comunicação entre o usuário
e a aplicação permaneça segura. A troca de carga entre entidades é criptografada
de modo que faça sentido apenas para o remetente e o destinatário, mas não
para outras pessoas. A confidencialidade de mensagens é garantida usando
criptografia simétrica e assimétrica. Os certificados são usados para implementar
a criptografia, isto é, a criptografia e descriptografia de mensagens.
A criptografia simétrica usa uma chave única, que é compartilhada com
o remetente e o destinatário, enquanto a criptografia assimétrica usa um par
de chaves privada e pública para criptografia, o que é mais seguro. Os pares de
chaves SSH no Linux, que são usados para autenticação, são um ótimo exemplo
de criptografia assimétrica.
• Integridade: a integridade garante que a troca de cargas e mensagens entre
o remetente e o destinatário não seja adulterada. O destinatário recebe a mesma
mensagem enviada pelo remetente. Os hashes e as assinaturas digitais são
os mecanismos de implementação para verificar a integridade de mensagens
recebidas.
228 | Arquitetar aplicações seguras no Azure
Segurança do Azure
O Azure fornece todos os seus serviços por meio de datacenters em várias regiões.
Esses datacenters estão interconectados nas regiões, bem como entre elas. O Azure
entende que ele hospeda dados, serviços e aplicações importantes e de missão crítica
para seus clientes. Ele deve garantir que a segurança seja de extrema importância para
seus datacenters e regiões.
Segurança de IaaS
O Azure é uma plataforma madura para a implantação de soluções de IaaS. Há muitos
usuários do Azure que desejam o controle total sobre as implantações, e normalmente eles
usam a IaaS para suas soluções. É importante que essas implantações e soluções sejam
seguras por padrão e design. O Azure fornece recursos de segurança avançados para
proteger soluções de IaaS. Nesta seção, alguns dos principais recursos serão abordados.
Com os resultados dessas investigações, um design NSG adequado deve ser criado.
Idealmente, deve haver várias sub-redes da rede para cada tipo de recurso e workload. Não
é recomendável implantar balanceadores de carga e máquinas virtuais na mesma sub-rede.
Considerando os requisitos do projeto, devem ser determinadas as regras que são comuns
para sub-redes e workloads de máquina virtual diferentes. Por exemplo, para uma
implantação do SharePoint, a aplicação de front-end e os SQL Servers são implantados
em sub-redes separadas. Portanto, devem ser determinadas regras para cada sub-rede.
Após a identificação das regras comuns no nível da sub-rede, as regras para recursos
individuais devem ser identificadas e aplicadas no nível da interface de rede. É importante
entender que, se uma regra permitir uma solicitação de entrada em uma porta, essa porta
também poderá ser usada para solicitações de saída sem nenhuma configuração.
234 | Arquitetar aplicações seguras no Azure
Se os recursos forem acessíveis pela Internet, as regras deverão ser criadas com portas
e intervalos de IP específicos, sempre que possível, em vez de permitir o tráfego de
todos os intervalos de IP (geralmente representados como 0.0.0.0/0). Testes funcionais
e de segurança cuidadosos devem ser executados para garantir que regras de NSG
adequadas e ideais sejam abertas e fechadas.
Firewalls
Os NSGs fornecem perímetros de segurança externa para solicitações. No entanto,
isso não significa que as máquinas virtuais não devem implementar medidas
de segurança adicionais. É sempre melhor implementar a segurança interna e
externamente. As máquinas virtuais no Linux ou no Windows fornecem um mecanismo
para filtrar solicitações no nível do sistema operacional. Isso é conhecido como firewall
no Windows e no Linux.
É aconselhável implementar firewalls para sistemas operacionais. Eles ajudam na
criação de um muro de segurança virtual que permite somente as solicitações
consideradas confiáveis. Quaisquer solicitações não confiáveis terão o acesso negado.
Há até mesmo dispositivos de firewall físicos, mas, na nuvem, os firewalls do sistema
operacional são usados. A Figura 8.4 mostra a configuração do firewall para um sistema
operacional Windows:
Firewall do Azure
Na seção anterior, discutimos o uso do Firewall do Azure em um sistema operacional
Windows/Linux para permitir ou negar solicitações e respostas por meio de portas
e serviços específicos. Embora os firewalls do sistema operacional desempenhem um
papel importante do ponto de vista da segurança e devam ser implementados para
qualquer implantação empresarial, o Azure fornece um recurso de segurança conhecido
como Firewall do Azure que tem uma funcionalidade semelhante de filtrar solicitações
com base em regras e determinar se uma solicitação deve ser permitida ou rejeitada.
A vantagem de usar o Firewall do Azure é que ele avalia uma solicitação antes que ela
alcance um sistema operacional. O Firewall do Azure é um recurso de rede e é um
serviço autônomo que protege recursos no nível da rede virtual. Quaisquer recursos,
incluindo máquinas virtuais e balanceadores de carga, que estejam diretamente
associados a uma rede virtual podem ser protegidos usando o Firewall do Azure.
O Firewall do Azure é um serviço altamente disponível e escalonável capaz de proteger
não apenas solicitações baseadas em HTTP, mas qualquer tipo de solicitação que entre
ou saia de uma rede virtual, incluindo FTP, SSH e RDP. Ele também pode abranger várias
Zonas de Disponibilidade durante a implantação para fornecer maior disponibilidade.
Segurança de IaaS | 237
Os itens mencionados acima são alguns dos principais pontos a serem considerados
do ponto de vista da segurança. A lista continuará crescendo, e precisamos melhorar
constantemente a segurança para evitar qualquer tipo de violação de segurança.
Azure Bastion
Na seção anterior, discutimos a implementação de servidores de salto. O Azure Bastion
é um serviço totalmente gerenciado que pode ser provisionado em uma rede virtual
para fornecer acesso RDP/SSH às suas máquinas virtuais diretamente no portal do
Azure sobre o TLS. O host do Bastion atuará como um servidor de salto e eliminará
a necessidade de endereços IP públicos para suas máquinas virtuais. O conceito de
usar o Bastion é o mesmo que implementar um servidor de salto; no entanto, como
esse é um serviço gerenciado, ele é totalmente gerenciado pelo Azure.
Como o Bastion é um serviço totalmente gerenciado do Azure e é fortalecido
internamente, não precisamos aplicar NSGs adicionais na sub-rede dele. Além disso,
como não estamos anexando IPs públicos às nossas máquinas virtuais, elas estão
protegidas contra a verificação de portas.
Segurança de aplicações
As aplicações Web podem ser hospedadas em soluções baseadas em IaaS sobre
máquinas virtuais, e podem ser hospedadas em serviços gerenciados fornecidos pelo
Azure, como o Serviço de Aplicativo. O Serviço de Aplicativo faz parte do paradigma de
implantação de PaaS, e vamos analisá-lo na próxima seção. Nesta seção, analisaremos
a segurança no nível da aplicação.
SSL/TLS
O Secure Socket Layer (SSL) foi preterido e substituído pelo Transport Layer Security
(TLS). O TLS fornece segurança de ponta a ponta por meio de criptografia. Ele fornece
dois tipos de criptografia:
Identidades gerenciadas
Antes de analisarmos as identidades gerenciadas, é importante saber como as
aplicações foram criadas sem elas.
Os cofres de chaves têm políticas de acesso que definem permissões para um usuário
ou grupo no que diz respeito ao acesso a segredos e credenciais dentro deles.
Os usuários, grupos ou aplicações de serviço que podem obter acesso são provisionados
e hospedados no Azure Active Directory (Azure AD). Embora contas de usuário
individuais possam receber acesso usando as políticas de acesso do Key Vault, é uma
prática melhor usar uma entidade de serviço para acessar o cofre de chaves. Uma
entidade de serviço tem um identificador, também conhecido como ID de aplicação ou
ID de cliente, juntamente com uma senha. A ID de cliente, juntamente com sua senha,
pode ser usada para autenticar com o Azure Key Vault. Essa entidade de serviço pode
ter permissão para acessar os segredos. As políticas de acesso do Azure Key Vault são
concedidas no painel Políticas de acesso do cofre de chaves. Na Figura 8.6, você pode
ver que a entidade de serviço, https://keyvault.book.com, concedeu acesso ao cofre de
chaves chamado keyvaultbook:
Figura 8.6: acesso concedido para uma entidade de serviço acessar um cofre de chaves
Isso nos leva a outro desafio: para acessar o cofre de chaves, precisamos usar a ID de
cliente e o segredo em nossos arquivos de configuração para que possamos nos conectar
ao cofre de chaves, obter o segredo e recuperar seu valor. Isso é quase equivalente ao uso
de nome de usuário, senha e cadeia de conexão SQL em arquivos de configuração.
É nesse aspecto que as identidades gerenciadas podem ajudar. O Azure lançou as
identidades de serviço gerenciadas e posteriormente as renomeou como identidades
gerenciadas. As identidades gerenciadas são identidades gerenciadas pelo Azure.
Em segundo plano, elas também criam uma entidade de serviço juntamente com uma
senha. Com identidades gerenciadas, não há necessidade de colocar credenciais em
arquivos de configuração.
242 | Arquitetar aplicações seguras no Azure
As identidades gerenciadas só podem ser usadas para autenticar com serviços que
ofereçam suporte ao Azure AD como um provedor de identidade. Elas se destinam
apenas à autenticação. Se o serviço de destino não fornecer permissão de controle
de acesso baseado em função (RBAC) à identidade, ela pode não ser capaz de executar
a atividade pretendida nesse serviço.
Há dois tipos de identidades gerenciadas:
• Identidades gerenciadas atribuídas ao sistema
• Identidades gerenciadas atribuídas ao usuário
As identidades atribuídas ao sistema são geradas pelo próprio serviço. Por exemplo,
se um serviço de aplicação quiser se conectar ao Banco de Dados SQL do Azure, ele
poderá gerar a identidade gerenciada atribuída ao sistema como parte de suas opções
de configuração. Essas identidades gerenciadas também são excluídas quando o recurso
ou serviço pai é excluído. Como mostrado na Figura 8.7, uma identidade atribuída ao
sistema pode ser usada pelo Serviço de Aplicativo para se conectar ao Banco de Dados
SQL do Azure:
Figura 8.7: habilitando uma identidade gerenciada atribuída ao sistema para o Serviço de Aplicativo
Depois que uma identidade gerenciada é criada e permissões de RBAC ou de acesso são
concedidas a ela no recurso de destino, ela pode ser usada dentro de aplicações para
acessar os recursos e serviços de destino.
O Azure fornece um SDK, bem como uma API REST, para falar com o Azure AD, obter
um token de acesso para identidades gerenciadas e, em seguida, usar o token para
acessar e consumir os recursos de destino.
O SDK faz parte do pacote NuGet Microsoft.Azure.Services.AppAuthentication para
C#. Quando o token de acesso estiver disponível, ele poderá ser usado para consumir
o recurso de destino.
O código necessário para obter o token de acesso é o seguinte:
var tokenProvider = new AzureServiceTokenProvider();
string token = await tokenProvider.GetAccessTokenAsync("https://vault.azure.
net");
Como alternativa, use isto:
string token = await tokenProvider.GetAccessTokenAsync("https://database.
windows.net");
Azure Sentinel
O Azure fornece SIEM e resposta automatizada de orquestração de segurança (SOAR)
como um serviço autônomo que pode ser integrado a qualquer implantação personalizada
no Azure. A Figura 8.8 mostra alguns dos principais recursos do Azure Sentinel:
Segurança de PaaS
O Azure fornece inúmeros serviços de PaaS, cada um com seus próprios recursos de
segurança. Em geral, os serviços de PaaS podem ser acessados usando credenciais,
certificados e tokens. Eles permitem a geração de tokens de acesso de segurança de
curta duração. As aplicações cliente podem enviar esses tokens de acesso de segurança
para representar usuários confiáveis. Nesta seção, vamos abordar alguns dos mais
importantes serviços de PaaS que são usados em quase todas as soluções.
O Azure Sentinel pode então fornecer insights e executar pastas de trabalho e runbooks
para responder a ameaças à segurança de forma automatizada. Os guias estratégicos
de segurança podem ser executados no Azure Sentinel em resposta a alertas. Todo guia
estratégico de segurança é composto por medidas que precisam ser tomadas em caso
de alertas. Os guias estratégicos são baseados em Aplicativos Lógicos do Azure,
e isso fornecerá a liberdade de usar e personalizar os modelos internos disponíveis com
Aplicativos Lógicos.
Log Analytics
O Log Analytics é uma nova solução analítica para o gerenciamento de implantações de
nuvem, datacenters na infraestrutura local e soluções híbridas.
Ele fornece várias soluções modulares, funcionalidade específica que ajuda a implementar
um recurso. Por exemplo, as soluções de segurança e auditoria ajudam a determinar uma
visão completa de segurança para a implantação de uma organização. Da mesma forma,
existem muitas outras soluções, como automação e controle de alterações, que devem
ser implementadas do ponto de vista da segurança. Os serviços de segurança e auditoria
do Log Analytics fornecem informações nas cinco categorias a seguir:
• Domínios de segurança: eles permitem exibir registros de segurança, avaliações
de malware, avaliações de atualização, segurança de rede, informações de
identidade e de acesso e computadores com eventos de segurança. O acesso
também é fornecido para o painel da Central de Segurança do Azure.
• Avaliação de antimalware: ajuda na identificação de servidores que não
estão protegidos contra malware e têm problemas de segurança. Ela fornece
informações sobre exposição a possíveis problemas de segurança e avalia o nível
de importância de qualquer risco. Os usuários podem tomar medidas proativas
com base nessas recomendações. As subcategorias da Central de Segurança do
Azure fornecem informações coletadas pela Central de Segurança do Azure.
248 | Arquitetar aplicações seguras no Azure
Agora que você aprendeu sobre a segurança para serviços de PaaS, vamos explorar
como proteger os dados armazenados no Armazenamento do Azure.
Armazenamento do Azure
As contas de armazenamento desempenham um papel importante na arquitetura
geral da solução. Elas podem armazenar informações importantes, como informações
de identificação pessoal (PII) de usuários, transações comerciais e outros dados
confidenciais. É de extrema importância que as contas de armazenamento sejam
seguras e permitam apenas o acesso de usuários autorizados. Os dados armazenados
são criptografados e transmitidos por meio de canais seguros. O armazenamento, assim
como os usuários e as aplicações cliente que utilizam a conta de armazenamento e seus
dados, desempenha um papel crucial na segurança geral dos dados. Os dados devem
permanecer criptografados o tempo todo. Isso também inclui credenciais e cadeias de
conexão que se conectam a repositórios de dados.
Armazenamento do Azure | 249
O Azure fornece RBAC para controlar quem pode gerenciar contas de armazenamento
dele. Essas permissões de RBAC são concedidas a usuários e grupos no Azure AD.
No entanto, quando uma aplicação a ser implantada no Azure for criada, ela terá
usuários e clientes que não estão disponíveis no Azure AD. Para permitir que os
usuários acessem a conta de armazenamento, o Armazenamento do Azure fornece
armazenamento de chaves de acesso. Há dois tipos de chaves de acesso no nível da
conta de armazenamento: primário e secundário. Os usuários com essas chaves podem
se conectar à conta de armazenamento. Essas chaves de acesso de armazenamento são
usadas na etapa de autenticação ao acessar a conta de armazenamento. As aplicações
podem acessar contas de armazenamento usando chaves primárias ou secundárias.
Duas chaves são fornecidas de modo que, se a chave primária for comprometida, as
aplicações poderão ser atualizadas para usar a chave secundária, enquanto a primária
é gerada novamente. Isso ajuda a minimizar o tempo de inatividade da aplicação.
Ademais, isso aumenta a segurança ao remover a chave comprometida sem afetar as
aplicações. Os detalhes da chave de armazenamento, como visto no portal do Azure,
são mostrados na Figura 8.10:
Os tokens SAS fornecem acesso granular a recursos e também podem ser combinados.
Esses tokens incluem leitura, gravação, exclusão, listagem, adição, criação, atualização
e processamento. Além disso, até mesmo o acesso a recursos pode ser determinado
durante a geração de tokens SAS. Poderia ser para blobs, tabelas, filas e arquivos
individualmente ou uma combinação deles. As chaves da conta de armazenamento são
para a conta inteira, elas não podem ser restritas a serviços individuais, nem podem ser
restritas do ponto de vista das permissões. É muito mais fácil criar e revogar tokens SAS
do que fazer isso com as chaves de acesso da conta de armazenamento. Os tokens SAS
podem ser criados para uso por um determinado período, após o qual eles se tornam
inválidos automaticamente.
Se estivermos regenerando a key1, que usamos para assinar o token SAS no exemplo
anterior, precisaremos criar um novo token SAS com a key2 ou a nova key1.
Armazenamento do Azure | 251
Roubo de cookies, injeção de scripts e ataques de DoS são meios comuns usados por
invasores para violar um ambiente e roubar dados. Os navegadores e o protocolo
HTTP implementam um mecanismo embutido que garante que essas atividades
mal-intencionadas não possam ser executadas. Geralmente, qualquer coisa entre
domínios não é permitida por HTTP e=ou navegadores. Um script em execução em
um domínio não pode solicitar recursos de outro domínio. No entanto, há casos de uso
válidos em que tais solicitações devem ser autorizadas. O protocolo HTTP implementa
o compartilhamento de recursos entre origens (CORS). Com a ajuda do CORS, é possível
acessar recursos entre domínios e fazê-los funcionar. O Armazenamento do Azure
configura regras de CORS para recursos de blob, arquivo, fila e tabela. Ele permite a
criação de regras que são avaliadas para cada solicitação autenticada. Se as regras forem
atendidas, a solicitação terá permissão para acessar o recurso. Na Figura 8.12, você pode
ver como adicionar regras de CORS a cada um dos serviços de armazenamento:
Os dados não devem apenas ser protegidos em trânsito, eles também devem ser
protegidos em repouso. Se os dados em repouso não forem criptografados, qualquer
um que tiver acesso à unidade física no datacenter poderá lê-los. Embora a possibilidade
de uma violação de dados seja insignificante, os clientes ainda devem criptografar seus
dados. A criptografia do serviço de armazenamento também ajuda a proteger dados em
repouso. Esse serviço funciona de forma transparente e injeta a si mesmo sem que os
usuários tomem conhecimento. Ele criptografa dados quando eles são salvos em uma
conta de armazenamento e os descriptografa automaticamente quando eles são lidos.
Todo esse processo acontece sem que os usuários executem qualquer atividade adicional.
As chaves de conta do Azure devem ser giradas periodicamente. Isso garantirá que um
invasor não seja capaz de obter acesso a contas de armazenamento.
Também é uma boa ideia regenerar as chaves; no entanto, isso deve ser avaliado
em relação ao seu uso em aplicações existentes. Se isso interromper as aplicações
existentes, essas aplicações deverão ser priorizadas para o gerenciamento de
alterações, que deverão ser aplicadas gradualmente.
252 | Arquitetar aplicações seguras no Azure
É sempre recomendável ter tokens SAS no nível do serviço individual com prazos
limitados. Esse token só deve ser fornecido aos usuários que devem acessar os recursos.
Sempre siga o princípio do privilégio mínimo e forneça apenas as permissões necessárias.
As chaves SAS e as chaves da conta de armazenamento devem ser armazenadas no
Azure Key Vault. Isso fornece armazenamento e acesso seguro a elas. Essas chaves
podem ser lidas no tempo de execução por aplicações do cofre de chaves, em vez
de armazená-las em arquivos de configuração.
Além disso, você também pode usar o Azure AD para autorizar as solicitações para
o armazenamento de blobs e filas. Vamos usar o RBAC para conceder as permissões
necessárias a uma entidade de serviço e, depois que autenticarmos a entidade de
serviço usando o Azure AD, um token OAuth 2.0 será gerado. Esse token poderá ser
adicionado ao cabeçalho de autorização das suas chamadas à API para autorizar uma
solicitação em relação ao armazenamento de blobs ou filas. A Microsoft recomenda
o uso da autorização do Azure AD ao trabalhar com aplicações de blobs e filas devido
à segurança superior proporcionada pelo Azure AD e sua simplicidade em comparação
com tokens SAS.
Na próxima seção, vamos avaliar as opções de segurança disponíveis para o Banco de
Dados SQL do Azure.
SQL do Azure
O SQL Server armazena dados relacionais no Azure, que é um serviço de banco de
dados relacional gerenciado. Ele também é conhecido como um Banco de Dados como
Serviço (DBaaS) que fornece uma plataforma altamente disponível, escalável, centrada
na performance e segura para armazenar dados. É acessível de qualquer lugar, com
qualquer plataforma e linguagem de programação. Os clientes precisam de uma cadeia
de conexão composta por servidor, banco de dados e informações de segurança para se
conectarem a ele.
O SQL Server fornece configurações de firewall que impedem o acesso de qualquer
pessoa por padrão. Os endereços IP e os intervalos devem ser incluídos na lista de
permissões para acessar o SQL Server. Os arquitetos só devem permitir os endereços IP
nos quais possam confiar e que pertençam a clientes/parceiros. Existem implantações
no Azure para as quais há vários endereços IP ou os endereços IP não são conhecidos,
como aplicações implantadas no Azure Functions ou em Aplicativos Lógicos. Para que
tais aplicações acessem o SQL do Azure, ele permite uma lista de permissões de todos
os endereços IP para serviços Azure em assinaturas.
Lembre-se de que a configuração do firewall está no nível do servidor, e não no nível
do banco de dados. Isso significa que quaisquer alterações aqui afetam todos os bancos
de dados dentro de um servidor. Na Figura 8.13, você pode ver como adicionar IPs de
clientes ao firewall para conceder acesso ao servidor:
SQL do Azure | 253
O SQL Server também fornece máscara dinâmica de dados (DDM), que é especialmente
útil para mascarar determinados tipos de dados, como dados de cartão de crédito ou PII
de usuários. O mascaramento não é igual à criptografia. Ele não criptografa os dados,
apenas os mascara, o que garante que eles não estejam em um formato legível por
humanos. Os usuários devem mascarar e criptografar dados confidenciais no SQL do
Azure Server.
O SQL Server também fornece um serviço de auditoria e detecção de ameaças para
todos os servidores. Existem serviços avançados de coleta de dados e inteligência em
execução nesses bancos de dados para descobrir ameaças e vulnerabilidades e alertar
os usuários com base neles. Os logs de auditoria são mantidos pelo Azure em contas de
armazenamento e podem ser exibidos por administradores para serem acionados. As
ameaças, como injeção de SQL e logons de clientes anônimos, podem gerar alertas que
podem ser enviados para os administradores por email. Na Figura 8.14, você pode ver
como habilitar a Detecção de Ameaças:
Figura 8.14: habilitando a Proteção contra Ameaças e selecionar os tipos de ameaças a serem detectados
Os dados podem ser mascarados no SQL do Azure. Isso nos ajuda a armazenar dados
em um formato que não pode ser lido por humanos:
SQL do Azure | 255
O SQL do Azure também fornece a TDE para criptografar dados em repouso, conforme
mostrado na Figura 8.16:
Para realizar uma avaliação de vulnerabilidade no SQL Server, você pode aproveitar
a Avaliação de Vulnerabilidade do SQL, que faz parte do pacote unificado para recursos
avançados de segurança do SQL conhecido como Segurança de Dados Avançada.
A Avaliação de Vulnerabilidade do SQL pode ser usada pelos clientes de forma proativa
para melhorar a segurança do banco de dados, descobrindo, rastreando e ajudando
você a corrigir possíveis vulnerabilidades do banco de dados.
256 | Arquitetar aplicações seguras no Azure
Mencionamos o Azure Key Vault algumas vezes nas seções anteriores, quando
discutimos identidades gerenciadas, Banco de Dados SQL e assim por diante.
Você já sabe qual é o objetivo do Azure Key Vault e, na próxima seção, exploraremos
alguns métodos que podem ajudar a proteger o conteúdo do seu cofre de chaves.
Um novo grupo de recursos pode ser criado usando o portal do Azure, como mostrado
na Figura 8.17:
Depois que o grupo de recursos for criado, um novo serviço de aplicação poderá ser
criado usando o portal, como mostrado na Figura 8.18:
É importante anotar a URL da aplicação Web porque ela será necessária posteriormente
ao configurar a aplicação do Facebook.
Depois que a aplicação Web for provisionada no Azure, a próxima etapa será criar uma
nova aplicação no Facebook. Isso é necessário para representar sua aplicação Web no
Facebook e gerar as credenciais de cliente apropriadas para ela. É assim que o Facebook
conhece a aplicação Web.
Navegue até developers.facebook.com e faça logon usando as credenciais apropriadas.
Crie uma nova aplicação selecionando a opção Criar Aplicativo em Meus Aplicativos
no canto superior direito, como mostrado na Figura 8.19:
A página da Web solicitará que você forneça um nome para a aplicação Web a fim de
criar uma nova aplicação no Facebook:
No portal do Azure, volte para o Serviço de Aplicativo do Azure criado nas primeiras
etapas desta seção e navegue até a folha de autenticação/autorização. Ative
a Autenticação do Serviço de Aplicativo, selecione Fazer logon com o Facebook
para autenticação e clique no item Facebook na lista:
Depois que você inserir suas credenciais, uma caixa de diálogo de consentimento do
usuário solicitará permissão para que os dados do Facebook sejam compartilhados com
a aplicação Web:
Figura 8.29: consentimento do usuário para compartilhar suas informações com a aplicação
Uma abordagem semelhante pode ser usada para proteger sua aplicação Web usando
Azure AD, Twitter, Microsoft e Google. Você também pode integrar seu próprio
provedor de identidade, se necessário.
A abordagem mostrada aqui ilustra apenas uma das maneiras de proteger um site
usando credenciais armazenadas em outro lugar e a autorização de aplicações externas
para acessar recursos protegidos. O Azure também fornece bibliotecas de JavaScript
e assemblies .NET para usar o método de programação imperativo a fim de consumir os
pontos de extremidade OAuth fornecidos pelo Azure AD e outras plataformas de redes
sociais. É recomendável usar essa abordagem para obter maior controle e flexibilidade
para autenticação e autorização nas suas aplicações.
Até agora, discutimos os recursos de segurança e como eles podem ser implementados.
Também é relevante ter monitoramento e auditoria em vigor. A implementação de uma
solução de auditoria ajudará sua equipe de segurança a auditar os logs e tomar medidas
preventivas. Na próxima seção, discutiremos as soluções de monitoramento e auditoria
de segurança no Azure.
Azure Monitor
O Azure Monitor é uma solução completa para o monitoramento de recursos do Azure.
Ele fornece informações sobre os recursos do Azure e seu estado. Também oferece uma
interface de consulta avançada com informações que podem ser divididas usando dados
nos níveis de assinatura, grupo de recursos, recurso individual e tipo de recurso. O Azure
Monitor coleta dados de várias fontes de dados, incluindo métricas e logs do Azure,
aplicações de clientes e os agentes executados em máquinas virtuais. Outros serviços,
como a Central de Segurança do Azure e o Observador de Rede, também ingerem dados
no espaço de trabalho do Log Analytics, que podem ser analisados no Azure Monitor.
Você pode usar APIs REST para enviar dados personalizados para o Azure Monitor.
266 | Arquitetar aplicações seguras no Azure
O Azure Monitor pode ser usado por meio do portal do Azure, do PowerShell, da CLI
e das APIs REST:
Resumo
A segurança é sempre um aspecto importante de qualquer implantação ou solução.
Ela se tornou muito mais importante e relevante por causa da implantação na nuvem.
Além disso, há uma ameaça crescente de ataques cibernéticos. Em tais circunstâncias,
a segurança tornou-se um ponto focal para as organizações. Não importa o tipo de
implantação ou solução, seja IaaS, PaaS ou SaaS, a segurança é necessária em todos
eles. Os datacenters do Azure são completamente seguros e têm diversas certificações
internacionais de segurança. Elas são seguras por padrão. Eles fornecem recursos
de segurança de IaaS, como NSGs, conversão de endereços de rede, pontos de
extremidade seguros, certificados, cofres de chaves, armazenamento, criptografia de
máquinas virtuais, e recursos de segurança de PaaS para recursos individuais de PaaS.
A segurança tem seu próprio ciclo de vida completo, e ele deve ser adequadamente
planejado, projetado, implementado e testado, assim como qualquer outra
funcionalidade de aplicação.
Resumo | 269
Big data
Com o influxo de dispositivos baratos, como dispositivos de Internet das Coisas
e dispositivos portáteis, a quantidade de dados que estão sendo gerados e capturados
aumentou exponencialmente. Quase todas as organizações têm uma grande quantidade
de dados e estão prontas para comprar mais, se necessário. Quando grandes
quantidades de dados chegam em vários formatos diferentes e com uma frequência
cada vez maior, podemos dizer que estamos lidando com big data. Em suma, há três
características principais de big data:
• Volume: a quantidade de dados em termos de tamanho (em GB, TB e PB, por
exemplo) e em termos do número de registros (como em um milhão de linhas
em um repositório de dados hierárquico, 100.000 imagens, meio bilhão de
documentos JSON e assim por diante).
• Velocidade: refere-se à velocidade com que os dados chegam ou são ingeridos.
Se os dados não forem alterados com frequência ou se dados novos não chegarem
com frequência, a velocidade dos dados será baixa, por outro lado, se houver
atualizações frequentes e muitos dados novos chegarem de forma contínua
e frequente, eles terão velocidade alta.
• Variedade: refere-se a diferentes tipos e formatos de dados. Os dados podem
vir de diferentes fontes em diferentes formatos. Os dados podem chegar como
dados estruturados (por exemplo, em arquivos separados por vírgula, arquivos
JSON ou dados hierárquicos), bancos de dados semiestruturados (por exemplo,
em documentos NoSQL sem esquema) ou dados não estruturados (como objetos
binários grandes (blobs), imagens, PDFs etc.). Com tantas variantes, é importante
ter um processo definido para processar dados ingeridos.
Hadoop
O Hadoop foi criado pela Apache Software Foundation e é uma estrutura distribuída,
escalonável e confiável para o processamento de big data, dividindo big data em blocos
menores de dados e distribuindo-os em um cluster. Um cluster do Hadoop é composto
por dois tipos de servidores: mestres e subordinados. O servidor mestre contém os
componentes administrativos do Hadoop, enquanto os subordinados são aqueles em
que o processamento de dados acontece. O Hadoop é responsável pelos dados lógicos
de partição entre subordinados; os subordinados executam toda a transformação nos
dados, reúnem insights e os repassam aos nós mestres que os agruparão para gerar a
saída final. Ele pode escalar para milhares de servidores, com cada servidor fornecendo
computação e armazenamento para os trabalhos. O Hadoop está disponível como
serviço usando o serviço HDInsight no Azure.
Há três componentes principais que compõem o sistema central do Hadoop:
HDFS: o Hadoop Distributed File System é um sistema de arquivos para
o armazenamento de big data. Ele é uma estrutura distribuída que ajuda a dividir
grandes arquivos de big data em blocos menores e colocá-los em diferentes
subordinados em um cluster. O HDFS é um sistema de arquivos tolerante a falhas.
Isso significa que, embora diferentes blocos de dados sejam disponibilizados
a diferentes subordinados no cluster, há também a replicação de dados entre
os subordinados para garantir que, em caso de falhas em qualquer subordinado,
esses dados também sejam disponibilizados em outro servidor. Ele também
fornece acesso rápido e eficiente aos dados para o solicitante.
MapReduce: o MapReduce é outra estrutura importante que permite ao Hadoop
processar dados em paralelo. Essa estrutura é responsável pelo processamento de
dados armazenados em subordinados do HDFS e pelo mapeamento deles para os
subordinados. Depois que os subordinados concluírem o processamento, a parte
"reduzir" trará informações de cada subordinado e as agrupará como a saída final.
Geralmente, o HDFS e o MapReduce ficam disponíveis no mesmo nó, de modo que
os dados não precisem viajar entre subordinados e uma maior eficiência possa ser
alcançada ao processá-los.
YARN: Yet Another Resource Negotiator (YARN) é um importante componente
arquitetônico do Hadoop que ajuda no agendamento de trabalhos relacionados
a aplicações e gerenciamento de recursos em um cluster. O YARN foi lançado
como parte do Hadoop 2.0, e muitas pessoas o escolheram como o sucessor
do MapReduce, pois ele é mais eficiente em termos de processamento em lote
e alocação de recursos.
276 | Soluções de Big Data do Azure
Apache Spark
O Apache Spark é uma solução analítica distribuída e confiável para processamento
de dados em grande escala. Ele fornece um cluster capaz de executar trabalhos de
transformação e machine learning em grandes quantidades de dados em paralelo e
trazer um resultado consolidado para o cliente. Ele é composto por nós mestres e de
trabalho. Os nós mestres são responsáveis por dividir e distribuir as ações em trabalhos
e dados entre nós de trabalho, bem como consolidar os resultados de todos os nós de
trabalho e devolver esses resultados ao cliente. Uma coisa importante a ser lembrada
ao usar o Spark é que a lógica ou os cálculos devem ser facilmente paralelizados,
e a quantidade de dados é muito grande para caber em uma máquina. O Spark está
disponível no Azure como um serviço do HDInsight e do Databricks.
Databricks
O Databricks é baseado no Apache Spark. Ele é uma Plataforma como Serviço em que
um cluster gerenciado do Spark é disponibilizado para os usuários. Ele fornece muitos
recursos adicionais, como um portal completo para gerenciar o cluster do Spark
e seus nós, além de ajudar a criar blocos de anotações, agendar e executar trabalhos
e fornecer segurança e suporte para vários usuários.
Agora, é hora de aprender a integrar dados de várias fontes e trabalhar com eles juntos
usando as ferramentas sobre as quais temos falado.
Integração de dados
Estamos cientes de como os padrões de integração são usados para aplicações. As
aplicações compostas de vários serviços são integradas usando vários padrões. No
entanto, há outro paradigma que é um requisito fundamental para muitas organizações,
conhecido como integração de dados. O aumento na integração de dados aconteceu
principalmente durante a última década, quando a geração e a disponibilidade de dados
se tornaram incrivelmente altas. A velocidade, a variedade e o volume de dados que
estão sendo gerados aumentaram drasticamente, e há dados em quase todos os lugares.
Cada organização tem muitos tipos diferentes de aplicações, e todos eles geram dados
em seus próprios formatos. Muitas vezes, os dados também são adquiridos do mercado.
Mesmo durante fusões e integrações de organizações, os dados precisam ser migrados
e combinados.
A integração de dados refere-se ao processo de trazer dados de várias fontes e gerar
uma nova saída que tenha mais significado e usabilidade.
ETL | 277
ETL
Um processo muito popular, conhecido como ETL, ajuda na criação de uma fonte
de dados de destino para armazenar dados que são consumíveis por aplicações.
Geralmente, os dados estão em um formato bruto e, para que se tornem consumíveis,
devem passar pelas três fases distintas a seguir:
• Extrair: durante essa fase, os dados são extraídos de vários lugares. Por exemplo,
pode haver várias fontes e todas precisam estar conectadas para recuperar
os dados. As fases de extração normalmente usam conectores de dados que
consistem em informações de conexão relacionadas à fonte de dados de destino.
Elas também podem ter armazenamento temporário para trazer os dados da fonte
e armazená-los para uma recuperação mais rápida. Essa fase é responsável pela
ingestão de dados.
• Transformar: os dados que ficam disponíveis após a fase de extração podem não
ser diretamente consumíveis por aplicações. Isso pode ocorrer por vários motivos;
por exemplo, os dados podem ter irregularidades, pode haver dados ausentes
ou pode haver dados errados. Ou pode até mesmo haver dados que não são
necessários. Como alternativa, o formato dos dados pode não ser apropriado para
consumo pelas aplicações de destino. Em todos esses casos, a transformação deve
ser aplicada aos dados de forma que possa ser consumida com eficiência pelas
aplicações.
278 | Soluções de Big Data do Azure
A seguir, vamos abordar como o Azure Data Factory se relaciona ao processo ETL.
Agora que você tem uma boa compreensão do Data Factory, vamos analisar as várias
opções de armazenamento disponíveis no Azure.
Após a conclusão dessas etapas, as atividades de preparação dos dados de origem estão
concluídas. Agora podemos nos concentrar na criação de uma instância do Data Lake
Storage.
Migrar dados do Armazenamento do Azure para o Data Lake Storage Gen2 | 283
Após a criação do data lake, vamos nos concentrar na criação de um novo pipeline do
Data Factory.
284 | Soluções de Big Data do Azure
Configurações do repositório
Antes de criar qualquer artefato do Data Factory, como conjuntos de dados e pipelines,
é recomendável configurar o repositório de código para hospedar arquivos relacionados
ao Data Factory:
1. Na página Criação, clique no botão Gerenciar e, em seguida, Configuração do
Git no menu à esquerda. Isso abrirá outro painel; clique no botão Configurar
repositório de código nesse painel:
Na próxima seção, prepararemos os conjuntos de dados que serão usados nos nossos
pipelines do Data Factory.
Migrar dados do Armazenamento do Azure para o Data Lake Storage Gen2 | 287
Agora que o primeiro conjunto de dados foi criado, vamos criar o segundo.
Agora que temos a conexão com os dados de origem e também conexões com
os repositórios de dados de origem e de destino, é hora de criar os pipelines
que conterão a lógica da transformação de dados.
Migrar dados do Armazenamento do Azure para o Data Lake Storage Gen2 | 291
Criar um pipeline
Depois que todos os conjuntos de dados forem criados, poderemos criar um pipeline
que consumirá esses conjuntos de dados. As etapas para criar um pipeline são
fornecidas a seguir:
1. Clique no menu + Pipelines => Novo Pipeline do menu à esquerda para criar
um novo pipeline. Em seguida, arraste e solte a atividade Copiar Dados do
menu Mover e Transformar, conforme demonstrado na Figura 9.14:
Depois que a criação do pipeline for concluída, ele poderá ser publicado em um
repositório de controle de versão, como o GitHub.
A seguir, investigaremos a criação de uma solução usando o Databricks e o Spark.
294 | Soluções de Big Data do Azure
7. Crie uma nova conta de armazenamento, como mostrado a seguir. Isso atuará
como armazenamento para os dados brutos da COVID no formato CSV:
Carregar dados
A segunda etapa importante é carregar os dados da COVID no espaço de trabalho do
Databricks. Isso pode ser feito de duas maneiras principais:
• Montar o contêiner de armazenamento do Azure no Databricks e, em seguida,
carregar os arquivos disponíveis na montagem.
• Carregar os dados diretamente da conta de armazenamento. Esta abordagem foi
usada no exemplo a seguir.
As etapas a seguir devem ser executadas para carregar e analisar dados usando o Databricks:
1. A primeira etapa é conectar e acessar a conta de armazenamento. A chave para
a conta de armazenamento é necessária e está armazenada na configuração do
Spark. Observe que a chave aqui é "fs.azure.account.key.coronadatastorage.
blob.core.windows.net" e o valor é a chave associada:
spark.conf.set("fs.azure.account.key.coronadatastorage.blob.core.windows.
net","xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx==")
2. A chave para a conta de armazenamento do Azure pode ser recuperada
navegando até as configurações e a propriedade Chaves de Acesso da conta de
armazenamento no portal.
A próxima etapa é carregar o arquivo e ler os dados no arquivo CSV. O esquema deve
ser inferido do próprio arquivo, em vez de ser fornecido explicitamente. Há também
uma linha de cabeçalho, que é representada usando a opção no próximo comando.
O arquivo é referenciado usando o seguinte formato: wasbs://{{container}}@
{{storage account name}}.blob.core.windows.net/{{filename}}.
298 | Soluções de Big Data do Azure
3. O método read do objeto SparkSession fornece métodos para ler arquivos. Para
ler arquivos CSV, o método csv deve ser usado juntamente com os parâmetros
necessários, como o caminho para o arquivo CSV. Há parâmetros opcionais adicionais
que podem ser fornecidos para personalizar o processo de leitura dos arquivos
de dados. Há vários tipos de formatos de arquivo, como JSON, Optimized Row
Columnar (ORC) e Parquet, e bancos de dados relacionais, como SQL Server e MySQL,
repositórios de dados NoSQL, como Cassandra e MongoDB, e plataformas de big
data, como Apache Hive, que podem ser usados no Spark. Vamos dar uma olhada no
seguinte comando para entender a implementação dos DataFrames do Spark:
coviddata = spark.read.format("csv").option("inferSchema", "true").
option("header", "true").load("wasbs://[email protected].
core.windows.net/owid-covid-data.csv")
O uso desse comando cria um novo objeto do tipo DataFrame no Spark. O Spark
fornece objetos Resilient Distributed Dataset (RDD) para manipular e trabalhar
com dados. Os RDDs são objetos de baixo nível e qualquer código escrito para
trabalhar com eles pode não ser otimizado. Os DataFrames são componentes de
nível superior aos RDDs e fornecem otimização para acessar e trabalhar com eles.
É melhor trabalhar com DataFrames do que com RDDs.
Os DataFrames fornecem dados no formato de linha/coluna, o que facilita
a visualização e o trabalho com dados. Os DataFrames do Spark são semelhantes
aos DataFrames do Pandas, com a diferença de serem implementações distintas.
4. O comando a seguir mostra os dados em um DataFrame. Ele mostra todas as linhas
e colunas disponíveis no DataFrame:
coviddata.show()
Você obterá uma saída semelhante à da Figura 9.25:
5. O esquema dos dados carregados é inferido pelo Spark e pode ser verificado
usando o seguinte comando:
coviddata.printSchema()
Isso fornecerá uma saída semelhante a esta:
Criar uma solução usando o Databricks | 299
6. Para contar o número de linhas no arquivo CSV, o comando a seguir pode ser
usado, e sua saída mostra que há 19.288 linhas no arquivo:
coviddata.count()
13. Às vezes, você precisará ter uma agregação de dados. Nesses cenários, você pode
executar o agrupamento de dados, como mostrado aqui:
coviddatanew = coviddata.groupBy('location').agg({'date': 'max'})
Isso exibirá os dados da instrução groupBy:
14. Como você pode ver na coluna max (date), as datas são praticamente as mesmas
para todos os países, podemos usar esse valor para filtrar os registros e obter uma
única linha para cada país que representa a data máxima:
coviddatauniquecountry = coviddata.filter("date='2020-05-23 00:00:00'")
coviddatauniquecountry.show()
15. Se pegarmos uma contagem de registros para o novo DataFrame, obtemos 209.
Podemos salvar o novo DataFrame em outro arquivo CSV, que pode ser necessário
para outros processadores de dados:
coviddatauniquecountry.rdd.saveAsTextFile("dbfs:/mnt/coronadatastorage/
uniquecountry.csv")
Podemos verificar o arquivo recém-criado com o seguinte comando:
%fs ls /mnt/coronadatastorage/
302 | Soluções de Big Data do Azure
18. É possível executar uma consulta SQL adicional em relação à tabela, como
mostrado a seguir:
spark.sql("select * from corona where location in ('India','Angola') order
by location").show()
Esse foi um pequeno resumo das possibilidades com o Databricks. Há muito mais
recursos e serviços dentro dele que não poderiam ser abordados em um único capítulo.
Leia mais sobre ele em https://azure.microsoft.com/services/databricks.
Resumo
Este capítulo tratou do serviço Azure Data Factory, que é responsável por fornecer
serviços ETL no Azure. Por ser uma plataforma como serviço, ele fornece escalabilidade
ilimitada, alta disponibilidade e pipelines fáceis de configurar. Sua integração com
o Azure DevOps e o GitHub também é perfeita. Também exploramos os recursos
e benefícios do uso do Azure Data Lake Storage Gen2 para armazenar qualquer tipo de
big data. É um repositório de dados hierárquico, econômico e altamente escalonável
para lidar com big data e é compatível com o Azure HDInsight, o Databricks
e o ecossistema Hadoop.
De forma alguma houve um aprofundamento completo em todos os tópicos mencionados
neste capítulo. O objetivo foi falar sobre as possibilidades no Azure, especialmente com
o Databricks e o Spark. Há várias tecnologias no Azure relacionadas a big data, incluindo
o HDInsight, o Hadoop, o Spark e seu ecossistema relacionado, e o Databricks, que é um
ambiente de Plataforma como Serviço para o Spark com funcionalidade adicionada. No
próximo capítulo, você conhecerá os recursos de computação sem servidor no Azure.
Sem servidor no
10
Azure – Trabalhar com
o Azure Functions
No capítulo anterior, você aprendeu sobre várias soluções de big data disponíveis no
Azure. Neste capítulo, você aprenderá como a tecnologia sem servidor pode ajudá-lo
a lidar com uma grande quantidade de dados.
Sem servidor é um dos chavões mais usados em tecnologia hoje em dia, e todo mundo
quer pegar uma carona. Sem servidor traz muitas vantagens em computação em
geral, processos de desenvolvimento de software, infraestrutura e implementação
técnica. Há muita coisa acontecendo na indústria: em uma extremidade do espectro
está a Infraestrutura como Serviço (IaaS) e, na outra, a função sem servidor. Entre
as duas estão a Plataforma como Serviço (PaaS) e os contêineres. Conheci muitos
desenvolvedores, e parece que há uma certa confusão entre eles sobre IaaS, PaaS,
contêineres e computação sem servidor. Além disso, há muita confusão sobre casos
de uso, aplicabilidade, arquitetura e implementação para o paradigma sem servidor.
A função em servidor é um novo paradigma que está mudando não apenas a tecnologia,
bem como a cultura e os processos dentro das organizações.
306 | Sem servidor no Azure – Trabalhar com o Azure Functions
Sem servidor
A função sem servidor refere-se a um modelo de implantação na qual os usuários
são responsáveis somente pelo código e pela configuração da sua aplicação.
Na computação sem servidor, os clientes não precisam se preocupar com trazer a sua
própria plataforma subjacente e a infraestrutura e, em vez disso, podem se concentrar
na resolução dos problemas de negócios.
Sem servidor não significa que não existem servidores. O código e a configuração
sempre precisarão de computação, armazenamento e redes para serem executados.
No entanto, do ponto de vista do cliente, não há visibilidade dessa computação,
armazenamento e redes. Eles não se importam com a plataforma e a infraestrutura
subjacentes. Eles não precisam gerenciar nem monitorar a infraestrutura e a
plataforma. A função sem servidor fornece um ambiente que pode ser expandido
e reduzido, de forma automática, sem o cliente ficar ciente disso. Todas as operações
relacionadas a plataformas e infraestruturas ocorrem nos bastidores e são executadas
pelo provedor de nuvem. Os clientes recebem contratos de nível de serviço (SLAs)
relacionados à performance, e o Azure garante que eles atendam aos contratos de nível
de serviço (SLAs), independentemente da demanda total.
Os clientes só precisam trazer seu código. É responsabilidade do provedor de nuvem
fornecer a infraestrutura e a plataforma necessárias para executar o código. Vamos
avançar e nos aprofundar nas várias vantagens do Azure Functions.
De fato, todos os dias parece que uma nova plataforma/estrutura está sendo apresentada,
e está se tornando cada vez mais difícil para as empresas decidir a respeito da estrutura
que funciona melhor para elas. O Azure fornece um valioso ambiente sem servidor
conhecido como Azure Functions. Veja a seguir alguns dos recursos compatíveis com ele:
• Diversas maneiras de invocar uma função: manual, agendada ou com base em um
evento.
• Diversos tipos de suporte vinculativo.
• A capacidade de executar funções de forma síncrona e assíncrona.
• A capacidade de executar funções com base em vários tipos de gatilhos.
• A capacidade de executar funções de longa e curta duração. No entanto, as
funções grandes e de longa duração não são recomendadas, pois podem causar
intervalos inesperados.
• A capacidade de usar recursos de proxy para arquiteturas de função diferentes.
• Vários modelos de uso, incluindo o consumo, bem como o modelo de Serviço de
Aplicativo.
• A capacidade de criar funções usando várias linguagens, como JavaScript, Python e C#.
• Autorização baseada em OAuth.
• A extensão Durable Functions ajuda a escrever funções com estado.
• Várias opções de autenticação, incluindo o Azure AD, o Facebook, o Twitter e
outros provedores de identidade.
• A capacidade de configurar facilmente parâmetros de entrada e saída.
• Integração do Visual Studio para criação de funções do Azure.
• Paralelismo em massa.
Vamos ver as FaaS e quais funções elas desempenham na arquitetura sem servidor.
308 | Sem servidor no Azure – Trabalhar com o Azure Functions
FaaS
O Azure fornece FaaS. Elas são implementações sem servidor do Azure. Com o Azure
Functions, o código pode ser escrito em qualquer linguagem com que o usuário se sinta
à vontade, e o Azure Functions fornecerá um tempo de execução para executá-lo. Com
base na linguagem escolhida, uma plataforma adequada é fornecida aos usuários por
trazer o seu próprio código. As funções são uma unidade de implantação e podem ser
automaticamente expandidas e reduzidas. Ao lidar com as funções, os usuários não
podem exibir as máquinas virtuais e as plataformas subjacentes, mas o Azure Functions
fornece uma pequena janela para visualizá-las por meio do console do Kudu.
Há dois componentes principais do Azure Functions:
• O tempo de execução do Azure Functions
• Associação e gatilhos do Azure Functions
Os autores de funções do Azure não precisam gravar nenhum código de conexão para
obter dados de várias fontes. Eles simplesmente decidem o tipo de dados esperado
do tempo de execução do Azure. Isso é mostrado no próximo segmento de código.
O check-out está disponível como uma cadeia de caracteres para a função. Vários
tipos de dados podem ser usados como associação para funções. Por exemplo, uma
associação de fila pode fornecer o seguinte:
• Um antigo objeto CLR (Common Language Runtime) simples (POCO)
• Uma cadeia
• Um byte
• CloudQueueMessage
312 | Sem servidor no Azure – Trabalhar com o Azure Functions
O autor da função pode usar qualquer um desses tipos de dados, e o tempo de execução
do Azure Functions garantirá que um objeto adequado como um parâmetro seja enviado
para a função: O seguinte é um trecho de código para aceitar dados de cadeia e o
tempo de execução do Functions encapsulará dados de entrada em um tipo de dados de
cadeia antes de invocar a função. Se o tempo de execução não puder lançar os dados de
entrada em uma cadeia, ele gerará uma exceção:
using System;
public static void Run(string checkOut, TraceWriter log)
{
log.Info($"C# Queue trigger function processed: { checkOut }");
}
Essas configurações afetam cada função contida por elas. Mais informações sobre
essas configurações estão disponíveis em https://docs.microsoft.com/azure/azure-
functions/functions-how-to-use-azure-function-app-settings.
FaaS | 313
Configuração de plataforma
As funções do Azure são hospedadas no Serviço de Aplicativo do Azure e, portanto,
elas obtêm todos os recursos. Os logs de diagnóstico e monitoramento podem ser
configurados com facilidade usando recursos de plataforma. Além disso, o Serviço
de Aplicativo fornece opções para atribuir certificados SSL usando autenticação,
autorização e um domínio personalizado como parte de seus recursos de rede.
Embora os clientes não estejam preocupados com a infraestrutura, o sistema
operacional, o sistema de arquivos ou a plataforma na qual as funções realmente são
executadas, o Azure Functions fornece as ferramentas necessárias para ter uma prévia
do sistema subjacente e fazer alterações. O console no portal e o console do Kudu são
as ferramentas usadas para essa finalidade. Eles fornecem um editor avançado para
criar as funções do Azure e editar sua configuração.
Assim como o Serviço de Aplicativo, o Azure Functions permite o armazenamento de
informações de configuração na seção de configuração da aplicação web.config, que
pode ser lida sob demanda. Alguns dos recursos da plataforma de aplicativos de função
são mostrados na Figura 10.3:
Esses recursos de plataforma podem ser usados para configurar autenticação, domínios
personalizados, SSL e assim por diante. Além disso, a guia Recursos da plataforma
fornece uma visão geral das ferramentas de desenvolvimento que podem ser usadas
com o aplicativo de função. Na próxima seção, vamos ver as configurações do aplicativo
de função que estão disponíveis nos recursos da plataforma.
314 | Sem servidor no Azure – Trabalhar com o Azure Functions
Um plano de consumo
Isso se baseia no consumo por segundo e na execução de funções. Esse plano calcula
o custo com base no uso de computação durante o consumo real e a execução da
função. Se uma função não for executada, não há nenhum custo associado a ela.
No entanto, isso não significa que a performance esteja comprometida nesse plano.
O Azure Functions será expandido e reduzido de forma automática com base na
demanda para garantir que os níveis mínimos básicos de performance sejam mantidos.
Uma execução de função é permitida 10 minutos para a sua conclusão.
Uma das principais desvantagens desse plano é que, se não houver nenhum consumo
de funções por alguns segundos, a função poderá ficar fria e a próxima solicitação
que surgir poderá enfrentar um pequeno atraso na obtenção de uma resposta, pois
a função está ociosa. Esse fenômeno é chamado de inicialização a frio. No entanto,
existem soluções alternativas que podem manter as funções ativas, mesmo quando
não há solicitações legítimas. Isso pode ser feito escrevendo uma função agendada
que continua invocando a função de destino para mantê-la ativa.
Um plano Premium
Este é um plano relativamente novo e oferece muitos benefícios em comparação com
o Serviço de Aplicativo e um plano de consumo. Nesse plano, não há inicializações
a frio para as funções do Azure. As funções podem ser associadas a uma rede privada,
e os clientes podem escolher seus próprios tamanhos de máquina virtual para executar
funções. Ele fornece inúmeras instalações prontas para uso que não eram possíveis
anteriormente com os outros dois tipos de planos.
Um plano do Serviço de Aplicativo
Este plano fornece funções com máquinas virtuais totalmente dedicadas no back-
end e, por isso, o custo é diretamente proporcional ao custo da máquina virtual e seu
tamanho. Há um custo associado fixo a esse plano, mesmo se as funções não forem
invocadas. O código de função pode ser executado durante o tempo necessário. Embora
não haja nenhuma restrição de tempo, o limite padrão é definido como 30 minutos. Isso
pode ser alterado com a alteração do valor no arquivo hosts.json. No âmbito do plano
de Serviço de Aplicativo, o tempo de execução da função fica ocioso se não utilizado
por alguns minutos e pode ser ativado somente usando um gatilho de HTTP. Há uma
configuração Always On que pode ser usada para impedir que o tempo de execução
da função fique ocioso. A escalabilidade é manual ou baseado em configurações de
escalabilidade automática.
Juntamente com a opção de preços flexível, o Azure também oferece várias opções
de hospedagem para implantação de arquitetura.
316 | Sem servidor no Azure – Trabalhar com o Azure Functions
Processamento de dados
O Azure Functions pode ser usado para o processamento de dados de entrada em lotes.
Ele pode ajudar no processamento de dados vem em vários formatos, como XML, CSV,
JSON e TXT. Ele também pode executar algoritmos de conversão, enriquecimento,
limpeza e filtragem. Na verdade, várias funções podem ser usadas, cada uma fazendo
conversão ou enriquecimento, limpeza ou filtragem. O Azure Functions também pode
ser usado para incorporar serviços cognitivos avançados, como reconhecimento óptico
de caracteres (OCR), visão computacional e manipulação e conversão de imagem. Isso
é ideal se você quiser processar as respostas de API e convertê-las.
Integração de aplicações herdadas
O Azure Functions pode ajudar na integração de aplicações herdadas com novos
protocolos e aplicações modernas. É possível que as aplicações herdadas não estejam
usando protocolos e formatos padrão da indústria. O Azure Functions pode atuar como
um proxy para essas aplicações herdadas, aceitar solicitações de usuários ou outras
aplicações, converter os dados em um formato compreendido por uma aplicação
herdada e se comunicar com ela com protocolos que ela entenda. Isso possibilita muitas
oportunidades para integrar e trazer aplicações antigas e herdadas para o portfólio
principal.
Trabalhos agendados
O Azure Functions pode ser usado para executar de forma contínua ou periodicamente
para determinadas funções da aplicação. Essas funções de aplicação podem realizar
tarefas como fazer backups periódicos, restaurar, executar trabalhos de lote, exportar
e importar dados e enviar emails em massa.
Gateways de comunicação
O Azure Functions pode ser usado em gateways de comunicação ao usar hubs de
notificação, mensagens SMS e assim por diante. Por exemplo, você pode usar o Azure
Functions para enviar uma notificação por push para dispositivos Android e iOS usando
Hubs de Notificações do Azure.
As funções do Azure estão disponíveis em diferentes tipos, que devem ser selecionadas
com base em sua relação com a otimização de workloads. Vamos vê-las em mais
detalhes.
318 | Sem servidor no Azure – Trabalhar com o Azure Functions
Na seção a seguir, você aprenderá a criar uma função orientada a eventos que será
vinculada a uma conta de armazenamento do Azure.
Execute as seguintes etapas para criar uma nova função do Azure no portal do Azure:
1. Clique no botão + ao lado do menu Funções à esquerda.
2. Selecione No portal na tela resultante e clique no botão Continuar.
3. Selecione Gatilho de Armazenamento de Blobs do Azure, conforme mostrado na
Figura 10.6:
Agora, essa função do Azure não tem conectividade com a conta de armazenamento.
As funções do Azure precisam de informações de conexão para a conta de
armazenamento e está disponível na guia Teclas de acesso na conta de armazenamento.
A mesma informação pode ser obtida usando o ambiente do editor do Azure Functions.
Na verdade, esse ambiente permite a criação de uma nova conta de armazenamento do
mesmo ambiente de editor.
O gatilho de Armazenamento de Blobs do Azure pode ser adicionado usando o botão
Novo ao lado do tipo de entrada de Conexão de conta de armazenamento.
Ele permite selecionar uma conta de armazenamento existente ou criar uma nova.
Como já tenho algumas contas de armazenamento, estou reutilizando-as, mas você
deve criar uma conta de armazenamento do Azure diferente. Ao selecionar uma
conta de armazenamento, você atualizará as configurações na seção appSettings com
a cadeia de conexão adicionada a ela.
Verifique se um contêiner já existe no serviço de blob da conta de armazenamento do
Azure de destino. A entrada do caminho se refere ao caminho para o contêiner. Neste
caso, o contêiner orders já existe na conta de armazenamento. O botão Criar mostrado
aqui provisionará a nova função que monitora o contêiner de conta de armazenamento:
320 | Sem servidor no Azure – Trabalhar com o Azure Functions
Figura 10.7: criando uma função que monitora o contêiner da conta de armazenamento
Agora, o upload de qualquer arquivo blob no contêiner orders deve acionar a função:
Na próxima seção, vamos nos aprofundar no Azure Function Proxies, que ajudarão você
a lidar com as solicitações e respostas das suas APIs de forma eficiente.
Function Proxies
O Azure Function Proxies é uma adição relativamente nova ao Azure Functions.
O Function Proxies ajuda a ocultar os detalhes das funções do Azure e expor pontos de
extremidade completamente diferentes aos clientes. O Function Proxies pode receber
solicitações em pontos de extremidade, modificar o conteúdo, o corpo, os cabeçalhos
e a URL da solicitação alterando os valores e aumentá-los com dados adicionais e
passá-los internamente para as funções do Azure. Assim que receberem uma resposta
dessas funções, podem novamente converter, substituir e aumentar a resposta
e devolvê-la ao cliente.
Ele também ajuda a invocar diferentes funções para operações CRUD (criação, leitura,
exclusão e atualização) usando cabeçalhos diferentes, assim dividindo grandes funções
em menores. Ele fornece um nível de segurança ao não expor o ponto de extremidade
da função original e também ajuda a alterar a implementação e os pontos de
extremidade da função interna sem afetar seu chamador. O Function Proxies ajuda ao
fornecer aos clientes uma única URL de função e, em seguida, invocar várias funções do
Azure nos back-end para concluir fluxos de trabalho. Mais informações sobre o Azure
Function Proxies podem ser encontradas em https://docs.microsoft.com/azure/azure-
functions/functions-proxies.
Na próxima seção, vamos abordar o Durable Functions em detalhes.
322 | Sem servidor no Azure – Trabalhar com o Azure Functions
Durable Functions
O Durable Functions é uma das adições mais recentes ao Azure Functions. Ele permite
que os arquitetos criem fluxos de trabalho com estado em uma função de orquestrador,
que é um novo tipo de função. Como desenvolvedor, você pode optar por codificar ou
usar qualquer forma de IDE. Algumas vantagens do uso do Durable Functions são:
• A saída da função pode ser salva para variáveis locais, e você pode chamar outras
funções de forma síncrona e assíncrona.
• O estado é preservado para você.
O Azure Durable Functions pode ser invocado por qualquer gatilho fornecido
pelo Azure Functions. Esses gatilhos incluem HTTP, Armazenamento de Blobs,
Armazenamento de Tabelas, filas do Barramento de Serviço e muito mais. Eles podem
ser acionados manualmente por alguém com acesso a eles ou por uma aplicação.
A Figura 10.9 mostra alguns gatilhos como exemplo. Eles também são conhecidos como
Durable Functions iniciais. O Durable Functions inicial invoca o gatilho do orquestrador
do Durable, que contem a lógica principal para a orquestração e orquestra a invocação
das funções da atividade.
Durable Functions | 323
Agora que você tem uma boa compreensão do funcionamento interno de uma função
durável, vamos explorar como criar uma função durável no Visual Studio.
324 | Sem servidor no Azure – Trabalhar com o Azure Functions
8. Agora, podemos codificar nossas funções duráveis no Visual Studio. Adicione uma
nova função, forneça um nome e selecione o tipo de gatilho Orquestração do
Durable Functions:
9. O Visual Studio gera o código clichê para o Durable Functions, e vamos usá-lo
para saber mais sobre o Durable Functions. As atividades do Durable Functions
são funções invocadas pela função de orquestrador principal. Geralmente, há
uma função de orquestrador principal e várias atividades do Durable Functions.
Após a instalação da extensão, forneça um nome para a função e escreva um
código que faça algo útil, como enviar um email ou mensagem SMS, conectar-se
a sistemas externos e executar lógica ou executar serviços usando seus pontos
de extremidade, como os serviços cognitivos.
O Visual Studio gera três conjuntos de funções em uma única linha de código:
• HttpStart: esta é a função inicial. Isso significa que ele é responsável por iniciar a
orquestração da função durável. O código gerado consiste em uma função inicial
do gatilho de HTTP. No entanto, pode ser qualquer função baseada em gatilho,
como BlobTrigger, uma fila ServiceBus ou uma função baseada em gatilho.
• RunOrchestrator: esta é a principal função de orquestração durável. Ela é
responsável por aceitar parâmetros da função inicial e invocar várias funções
de tarefa duráveis. Cada função de tarefa durável é responsável por uma
funcionalidade, e essas tarefas duráveis podem ser invocadas em paralelo
ou em sequência, dependendo da necessidade.
• SayHello: esta é a função de tarefa durável que é invocada no orquestrador
de função durável para realizar um trabalho específico.
326 | Sem servidor no Azure – Trabalhar com o Azure Functions
10. O código da função inicial (HttpStart) é mostrado a seguir. Essa função tem um
gatilho do tipo HTTP e aceita uma associação adicional do tipo DurableClient.
Esse objeto DurableClient ajuda a invocar a função de orquestrador:
Vamos invocar essa URL usando uma ferramenta conhecida como Postman (de que
é possível fazer o download em https://www.getpostman.com/). Só precisamos
copiar a URL e executá-la no Postman. Essa atividade é mostrada na Figura 10.17:
Lembre-se de que cinco URLs são geradas quando você inicia o orquestrador:
• A URL statusQueryGetUri é usada para localizar o status atual do orquestrador.
Ao clicar nessa URL no Postman, uma nova guia será aberta e, se executarmos
essa solicitação, o status do fluxo de trabalho será exibido:
Agora que você sabe como trabalhar com o Durable Functions usando o Visual Studio,
vamos abordar outro aspecto das funções do Azure: encadeá-las.
Vamos seguir as etapas abaixo para obter dados para a próxima função da saída de
uma função.
1. Crie um novo banco de dados, testdb, no Cosmos DB e uma nova coleção
chamada testcollection dentro dele. Você precisa do nome do banco de
dados e da coleção ao configurar as funções do Azure:
2. Crie uma nova função que terá um gatilho do Armazenamento de Blobs e uma
associação de saída do CosmosDB. O valor retornado da função será o tamanho
dos dados para o arquivo carregado. Esse valor retornado será gravado no Cosmos
DB. A associação de saída será gravada na coleção do Cosmos DB. Navegue até
a guia Integrar, clique no botão Nova Saída abaixo do rótulo Saídas e selecione
Azure Cosmos DB:
Criar uma arquitetura conectada com funções | 331
Esta seção abordou como a saída de uma função pode ser usada para obter dados para
a próxima função. Na próxima seção, você aprenderá a habilitar o eventos sem servidor,
compreendendo a Grade de Eventos do Azure.
Antes da Grade de Eventos, não havia nenhum serviço que poderia ser descrito como
uma plataforma de eventos em tempo real. Havia serviços separados, e cada um
forneceu seu próprio mecanismo para manipular eventos.
Por exemplo, o Log Analytics, também conhecido como Operations Management
Suite (OMS), fornece uma infraestrutura para capturar logs de ambiente e telemetria
em que os alertas podem ser gerados. Esses alertas podem ser usados para executar
um runbook, um webhook ou uma função. Isso é próximo ao tempo real, mas eles não
são completamente tempo real. Além disso, foi bastante complicado capturar logs
individuais e agir sobre eles. Da mesma forma, há o Application Insights, que fornece
recursos semelhantes para o Log Analytics, mas para aplicações.
Grade de Eventos
A Grade de Eventos permite criar aplicações com arquitetura baseada em eventos.
Há editores de eventos e há consumidores de eventos. No entanto, pode haver vários
assinantes para o mesmo evento.
O editor de um evento pode ser um recurso do Azure, como Armazenamento de
Blobs, hubs da Internet das Coisas (IoT) e muitos outros. Esses editores também são
conhecidos como origens de eventos. Esses editores usam tópicos do Azure prontos
para uso para enviar seus eventos para a Grade de Eventos. Não é necessário configurar
o recurso ou o tópico. Os eventos gerados por recursos do Azure já estão usando
internamente tópicos para enviar seus eventos para a Grade de Eventos. Assim que
o evento atingir a grade, poderá ser consumido pelos assinantes.
334 | Sem servidor no Azure – Trabalhar com o Azure Functions
Armazenamento
de blobs
Azure Functions
Serviços de Mídia
Aplicativos
Assinaturas Lógicos
do Azure Automação
Grupos de do Azure
Recursos
Webhooks
Hubs de Eventos
Armazenamento
de Filas
Hub IoT
Conexões
Barramento Híbridas
de Serviço Hubs de
Tópicos Eventos
Personalizados
Cada evento tem um tipo de evento e é reconhecido por ele. Por exemplo,
o Armazenamento de Blobs fornece tipos de eventos, como blobAdded e blobDeleted.
Os tópicos personalizados podem ser usados para enviar um evento personalizado
definido, como um evento personalizado do tipo KeyVaultSecretExpired.
Por outro lado, os assinantes têm a capacidade de aceitar todas as mensagens ou
apenas obter eventos com base em filtros. Esses filtros podem ser baseados no tipo
de evento ou em outras propriedades dentro da carga do evento.
Cada evento tem pelo menos estas cinco propriedades:
• id: é o identificador exclusivo para o evento.
• eventType: é o tipo de evento.
• eventTime: é a data e hora em que o evento foi gerado.
• subject: é uma breve descrição do evento.
• data: é um objeto de dicionário e contém dados específicos de recursos ou
quaisquer dados personalizados (para tópicos personalizados).
Eventos de recursos
Nesta seção, as etapas a seguir são fornecidas para criar uma solução na qual os eventos
que são gerados pelo Armazenamento de Blobs são publicados na Grade de Eventos e,
por fim, roteados para uma função do Azure:
1. Faça logon no portal do Azure e em sua assinatura usando as credenciais
adequadas e crie uma nova conta de armazenamento em um grupo de
recursos existente ou novo. A conta de armazenamento deve ser StorageV2 ou
Armazenamento de Blobs. Conforme demonstrado na Figura 10.26, a Grade de
Eventos não funcionará com StorageV1:
336 | Sem servidor no Azure – Trabalhar com o Azure Functions
2. Crie um novo aplicativo de função ou reutilize um existente para criar uma função
do Azure. A função do Azure será hospedada no aplicativo de função.
3. Crie uma nova função usando o modelo de gatilho da Grade de Eventos do Azure.
Instale a extensão Microsoft.Azure.WebJobs.Extensions.EventGrid se ainda não
estiver instalada, conforme mostrado na Figura 10.27:
Grade de Eventos do Azure | 337
Nesta seção, você aprendeu como os eventos gerados pelo Armazenamento de Blobs
podem ser roteados para uma função do Azure. Na próxima seção, você aprenderá
a aproveitar eventos personalizados.
Eventos personalizados
Neste exemplo, em vez de usar recursos prontos para uso para gerar eventos, serão
usados eventos personalizados. Usaremos o PowerShell para criar essa solução
e reutilizar a mesma função do Azure que foi criada no último exercício como
o manipulador:
1. Faça logon e conecte-se à assinatura do Azure à sua escolha usando o cmdlet
Login-AzAccount e Set-AzContext.
2. A próxima etapa é criar um novo tópico de Grade de Eventos no Azure em um
grupo de recursos. O cmdlet New-AzEventGridTopic é usado para criar um novo
tópico:
New-AzEventGridTopic -ResourceGroupName CustomEventGridDemo -Name
"KeyVaultAssetsExpiry" -Location "West Europe"
Grade de Eventos do Azure | 341
3. Depois que o tópico for criado, sua URL de ponto de extremidade e a chave
deverão ser recuperadas, já que são necessárias para enviar e publicar o evento
para ele. Os cmdlets Get-AzEventGridTopic e Get-AzEventGridTopicKey são usados
para recuperar esses valores. Observe que Key1 é recuperada para se conectar ao
ponto de extremidade:
$topicEndpoint = (Get-AzEventGridTopic -ResourceGroupName containers -Name
KeyVaultAssetsExpiry).Endpoint
7. Uma nova assinatura é criada para o tópico personalizado com um nome, o grupo
de recursos que contém o tópico, o nome do tópico, o ponto de extremidade do
webhook e o ponto de extremidade real que atua como o manipulador de eventos.
Nesse caso, o manipulador de eventos é a função do Azure:
New-AzEventGridSubscription -TopicName KeyVaultAssetsExpiry
-EventSubscriptionName "customtopicsubscriptionautocar" -ResourceGroupName
CustomEventGridDemo -EndpointType webhook '
-Endpoint "https://durablefunctiondemoapp.
azurewebsites.net/runtime/webhooks/
EventGrid?functionName=StorageEventHandler&code=0aSw6sxvtFmafXHvt7iOw/
Dsb8o1M9RKKagzVchTUkwe9EIkzl4mCg=='
-Verbose
A URL da função do Azure está disponível na guia Integrar, conforme mostrado
na Figura 10.31:
Resumo
A evolução das funções dos métodos tradicionais levou à criação da arquitetura de baixa
associação, de evolução independente, autossuficiente sem servidor que era apenas
um conceito antigamente. As funções são uma unidade de implantação e fornecem
um ambiente que não precisa ser gerenciado pelo usuário. Ele só precisa se preocupar
com o código escrito para a funcionalidade. O Azure fornece uma plataforma madura
para hospedagem de funções e as integra perfeitamente, com base em eventos ou sob
demanda. Quase todos os recursos no Azure podem participar de uma arquitetura
composta de funções do Azure. O futuro é das funções, pois cada vez mais organizações
querem se afastar do gerenciamento de infraestruturas e plataformas. Elas desejam
descarregar isso nos provedores de nuvem. O Azure Functions é um recurso essencial
a ser dominado por todos os arquitetos que lidam com o Azure.
Este capítulo explicou em detalhes o Azure Functions, Funções como Serviço,
o Durable Functions e a Grade de Eventos. O próximo capítulo se concentrará em
Aplicativos Lógicos do Azure, e vamos criar uma solução completa que combina vários
serviços sem servidor, juntamente com outros serviços do Azure, como o Azure Key
Vault e a Automação do Azure.
Soluções do Azure
11
usando Aplicativos
Lógicos do Azure,
Grade de Eventos
e Functions
Este capítulo continua a partir do capítulo anterior e mostrará mais detalhes sobre
os serviços sem servidor disponíveis no Azure. No capítulo anterior, você conheceu
detalhadamente o Azure Functions, Funções como Serviço, Durable Functions e Grade
de Eventos. De agora em diante, este capítulo se concentrará na compreensão dos
Aplicativos Lógicos e, em seguida, passará à criação de uma solução completa sem
servidor de ponta a ponta que combina vários serviços sem servidor, entre outros,
como Key Vault e Automação do Azure.
346 | Soluções do Azure usando Aplicativos Lógicos do Azure, Grade de Eventos e Functions
Atividades
Uma atividade é uma única unidade de trabalho. Exemplos de atividades incluem
a conversão de XML em JSON, a leitura de blobs do Armazenamento do Azure e a
gravação em uma coleção de documentos do Cosmos DB. O Aplicativos Lógicos fornece
uma definição de fluxo de trabalho que consiste em várias atividades relacionadas em
uma sequência. Há dois tipos de atividade no Aplicativos Lógicos:
• Gatilho: um gatilho refere-se à iniciação de uma atividade. Todos os Aplicativos
Lógicos têm um único gatilho que forma a primeira atividade. É o gatilho que cria
uma instância do aplicativo lógico e inicia a execução. Exemplos de gatilhos são a
chegada de mensagens da Grade de Eventos, um email, uma solicitação HTTP ou
um agendamento.
• Ações: qualquer atividade que não seja um gatilho é uma atividade de etapa,
e cada uma delas é responsável por executar uma tarefa. As etapas estão
conectadas entre si em um fluxo de trabalho. Cada etapa terá uma ação que
precisa ser concluída antes de passar para a próxima etapa.
Conectores
Os conectores são recursos do Azure que ajudam a conectar um Aplicativo Lógico
a serviços externos. Esses serviços podem estar na nuvem ou na infraestrutura local.
Por exemplo, há um conector para conectar Aplicativos Lógicos à Grade de Eventos.
Da mesma forma, há outro conector para se conectar ao Office 365 Exchange. Quase
todos os tipos de conectores estão disponíveis em Aplicativos Lógicos, e eles podem ser
usados para se conectar a serviços. Os conectores contêm informações de conexão e
também lógica para conectar a serviços externos usando essas informações de conexão.
Aplicativos Lógicos do Azure | 347
Figura 11.1: navegar até o serviço de Análise de Texto a partir do portal do Azure
9. Clique na Próxima etapa para adicionar outra ação e digite a variável de palavra-
chave na barra de pesquisa. Em seguida, selecione a ação Inicializar variável,
conforme demonstrado na Figura 11.3:
10. Depois, configure a ação de variável. Quando a caixa Valor for clicada, aparecerá
uma janela pop-up mostrando Conteúdo dinâmico e Expressão. O Conteúdo
dinâmico refere-se a propriedades que estão disponíveis para a ação atual e são
preenchidas com valores de tempo de execução de ações anteriores e gatilhos.
As variáveis ajudam a manter os fluxos de trabalho genéricos. Nessa janela,
selecione Corpo em Conteúdo dinâmico:
11. Para incluir outra ação, clique em Adicionar etapa, digite Outlook na barra de
pesquisa e selecione a ação Responder ao email:
12. Configure a nova ação. Verifique se Id da Mensagem está definida com o conteúdo
dinâmico, Id da Mensagem e, em seguida, digite a resposta que gostaria de enviar
ao destinatário na caixa Comentário:
13. Adicione outra ação, digite análise de texto na barra de pesquisa e, em seguida,
selecione Detectar Sentimento (visualização):
16. Em seguida, adicione uma nova ação selecionando Outlook. Em seguida, selecione
Enviar um email. Essa ação envia ao destinatário original o conteúdo do email
com a pontuação de sentimento em seu assunto. Ele deve ser configurado como
mostrado na Figura 11.10. Se a pontuação não estiver visível na janela de conteúdo
dinâmico, clique no link Ver mais ao lado dele:
Aplicativos Lógicos do Azure | 353
17. Salve o Aplicativo Lógico, navegue de volta para a página de visão geral
e clique no gatilho Executar. O gatilho verificará novos emails a cada 3 minutos,
responderá aos remetentes, executará a análise de sentimento e enviará um email
para o destinatário original. Um email de exemplo com conotações negativas
é enviado para a ID de email fornecida:
A declaração do problema
O problema que vamos resolver aqui é que os usuários e organizações não são
notificados sobre a expiração dos segredos em seu cofre de chaves, e as aplicações
param de funcionar quando expiram. Os usuários estão reclamando que o Azure não
fornece a infraestrutura para monitorar segredos, chaves e certificados do Key Vault.
Solução
A solução para esse problema é combinar vários serviços do Azure e integrá-los para
que os usuários possam ser notificados proativamente sobre a expiração de segredos.
A solução enviará notificações usando dois canais – email e SMS.
Arquitetura
Na seção anterior, exploramos a lista de serviços que serão usados na solução.
Se quisermos implementar a solução, os serviços deverão ser definidos na ordem
apropriada. A arquitetura nos ajudará a desenvolver o fluxo de trabalho e a chegar
mais perto da solução.
A arquitetura da solução compreende vários serviços, conforme mostrado na Figura 11.14:
s
õe
As
aç
Grade
sin
blic
atu
Pu
vez todos
ras
os dias email
Ac
Agendamento Grupos de
so
PowerShell
de automação administradores/
do Azure Certificados stakeholders
Segredos
Key Vault
Vamos passar por cada um desses serviços e entender seus papéis e a funcionalidade
que eles fornecem na solução geral.
Automação do Azure
A Automação do Azure fornece runbooks e estes runbooks podem ser usados para
executar a lógica utilizando o PowerShell, Python e outras linguagens de script.
Os scripts podem ser executados na infraestrutura local ou na nuvem, o que
proporciona infraestrutura e instalações avançadas para criar scripts. Esses tipos de
script são conhecidos como runbooks. Normalmente, os runbooks implementam um
cenário como interromper ou iniciar uma máquina virtual, ou criar e configurar contas
de armazenamento. É muito fácil conectar-se ao ambiente do Azure desde runbooks
com a ajuda de ativos, como variáveis, certificados e conexões.
Na solução atual, queremos conectar-se ao Azure Key Vault, ler todos os segredos
e chaves armazenados nele e buscar suas datas de expiração. Essas datas de expiração
devem ser comparadas com a data de hoje e, se a data de expiração estiver dentro de
um mês, o runbook deve disparar um evento personalizado na Grade de Eventos usando
um tópico personalizado de Grade de Eventos.
Um runbook da Automação do Azure utilizando um script do PowerShell será
implementado para conseguir isso. Junto com o runbook, um agendador também
será criado que executará o runbook uma vez por dia à meia-noite.
Criação de uma solução de ponta a ponta usando tecnologias sem servidor | 357
Pré-requisitos
No mínimo, você precisará de uma assinatura do Azure com direitos de colaborador. Como
estamos apenas implantando serviços no Azure e não há serviços externos implantados,
a assinatura é o único pré-requisito. Vamos continuar e implementar a solução.
Implementação
Um Key Vault já deve existir. Caso contrário, ele deverá ser criado.
Esta etapa deverá ser seguida se uma nova instância do Azure Key Vault precisar ser
provisionada. O Azure permite provisionar recursos de várias maneiras. Entre eles,
destacam-se o Azure PowerShell e a CLI do Azure. A CLI do Azure é uma interface
de linha de comando que funciona em várias plataformas. A primeira tarefa será
provisionar um cofre de chaves no Azure. Nesta implementação, utilizaremos o Azure
PowerShell para provisionar o cofre de chaves.
Antes que o Azure PowerShell possa ser usado para criar um cofre de chaves,
é importante fazer logon no Azure para que os comandos subsequentes possam
ser executados com êxito para criar o cofre de chaves.
358 | Soluções do Azure usando Aplicativos Lógicos do Azure, Grade de Eventos e Functions
Junto com a entidade de serviço, uma aplicação do Diretório de Aplicações será criada.
A aplicação atua como a representação global da nossa aplicação em diretórios, e a
entidade é como uma representação local da aplicação. Podemos criar várias entidades
usando a mesma aplicação em outro diretório. Podemos obter os detalhes da aplicação
criada usando o comando Get-AzAdApplication. Salvaremos a saída desse comando em
uma variável, $app, pois precisaremos dela posteriormente:
$app = Get-AzAdApplication -DisplayName $sp.DisplayName
Agora criamos uma entidade de serviço usando um segredo; outra maneira segura de
criá-la é usando certificados. Na próxima seção, criaremos uma entidade de serviço
usando certificados.
Etapa 3: criar uma entidade de serviço usando certificados
Para criar uma entidade de serviço usando certificados, as seguintes etapas devem ser
seguidas:
1. Criar um certificado autoassinado ou comprar um certificado: um certificado
autoassinado é usado para criar este exemplo de aplicação de ponta a ponta.
Para implantações da vida real, um certificado válido deve ser comprado de uma
autoridade de certificação.
Para criar um certificado autoassinado, o comando a seguir pode ser executado.
O certificado autoassinado é exportável e armazenado em uma pasta pessoal no
computador local — ele também tem uma data de expiração:
$currentDate = Get-Date
$expiryDate = $currentDate.AddYears(1)
$finalDate = $expiryDate.AddYears(1)
$servicePrincipalName = "https://automation.book.com"
$automationCertificate = New-SelfSignedCertificate -DnsName
$servicePrincipalName -KeyExportPolicy Exportable -Provider "Microsoft
Enhanced RSA and AES Cryptographic Provider" -NotAfter $finalDate
-CertStoreLocation "Cert:\LocalMachine\My"
2. Exportar o certificado recém-criado: o novo certificado deve ser exportado para o
sistema de arquivos para que, posteriormente, ele possa ser carregado para outros
destinos, como o Azure AD, para criar uma entidade de serviço.
Os comandos usados para exportar o certificado para o sistema de arquivos local
são mostrados a seguir. Note que este certificado tem chaves públicas e privadas
e, por isso, enquanto é exportado, tem de ser protegido utilizando uma senha
e a senha tem de ser uma cadeia de caracteres segura:
Criação de uma solução de ponta a ponta usando tecnologias sem servidor | 361
Nesse ponto, configuramos a entidade de serviço para funcionar com o Azure Key Vault.
A próxima parte da solução é criar uma conta de automação.
Etapa 5: criar uma conta da Automação
Assim como antes, nós usaremos o Azure PowerShell para criar uma nova conta da
Automação do Azure em um grupo de recursos. Antes de criar um grupo de recursos
e uma conta da Automação, uma conexão com o Azure deve ser estabelecida.
No entanto, desta vez, utilize as credenciais para que a entidade de serviço
se conecte ao Azure. As etapas são as seguintes:
Criação de uma solução de ponta a ponta usando tecnologias sem servidor | 363
5. Agora é hora de fazer upload de um certificado, que será usado para conexão com
o Azure a partir da Automação do Azure:
$securepfxpwd = ConvertTo-SecureString -String 'password' -AsPlainText
-Force # Password for the private key PFX certificate
New-AzAutomationCertificate -Name "AutomationCertifcate" -Path "C:\book\
azureautomation.pfx" -Password $securepfxpwd -AutomationAccountName
$automationAccountName -ResourceGroupName $IntegrationResourceGroup
6. A próxima etapa é instalar os módulos do PowerShell relacionados ao Key Vault
e à Grade de Eventos na conta da Automação do Azure, pois esses módulos não
são instalados por padrão.
7. No portal do Azure, navegue até o grupo de recursos VaultMonitoring já criado
clicando em Grupos de Recursos no menu à esquerda.
8. Clique na conta da Automação do Azure já provisionada, MonitoringKeyVault
e, então, clique em Módulos no menu à esquerda. O módulo Grade de Eventos
depende do módulo Az.profile e, portanto, temos que instalá-lo antes do módulo
Grade de Eventos.
9. Clique em Procurar na Galeria no menu superior e digite Az.profile na caixa
de pesquisa, como mostrado na Figura 11.16:
11. O status da instalação pode ser verificado no item de menu Módulo. A Figura 11.17
demonstra como podemos importar um módulo:
A Grade de Eventos do Azure gera duas chaves — uma primária e uma secundária.
A primeira referência fundamental é tomada da seguinte maneira:
$eventGridName = "ExpiredAssetsKeyVaultEvents"
$eventGridResourceGroup = "VaultMonitoring"
$topicEndpoint = (Get-AzEventGridTopic -ResourceGroupName
$eventGridResourceGroup -Name $eventGridName).Endpoint
$keys = (Get-AzEventGridTopicKey -ResourceGroupName
$eventGridResourceGroup -Name $eventGridName ).Key1
6. Em seguida, todos os cofres de chaves que foram provisionados na assinatura
são recuperados usando a iteração. Durante o loop, todos os segredos são
recuperados usando o cmdlet Get-AzKeyVaultSecret.
A data de expiração de cada segredo é comparada à data atual e, se a diferença for
inferior a um mês, gerará um evento de Grade de Eventos e o publicará usando o
comando invoke-webrequest.
As mesmas etapas são executadas para certificados armazenados no
cofre de chaves. O cmdlet usado para recuperar todos os certificados
é Get-AzKeyVaultCertificate.
O evento que é publicado na Grade de Eventos deve estar na matriz JSON. A mensagem
gerada é convertida em JSON usando o cmdlet ConvertTo-Json e, em seguida,
convertida em uma matriz por meio da adição de [ e ] como um prefixo e sufixo.
Para se conectar à Grade de Eventos do Azure e publicar o evento, o remetente
deverá fornecer a chave em seu cabeçalho. A solicitação falhará se esses dados
estiverem ausentes na carga da solicitação:
$keyvaults = Get-AzureRmKeyVault
foreach($vault in $keyvaults) {
$secrets = Get-AzureKeyVaultSecret -VaultName $vault.VaultName
foreach($secret in $secrets) {
if( ![string]::IsNullOrEmpty($secret.Expires) ) {
if($secret.Expires.AddMonths(-1) -lt [datetime]::Now)
{
$secretDataMessage = @{
id = [System.guid]::NewGuid()
subject = "Secret Expiry happening soon !!"
eventType = "Secret Expiry"
eventTime = [System.DateTime]::UtcNow
data = @{
"ExpiryDate" = $secret.Expires
"SecretName" = $secret.Name.ToString()
Criação de uma solução de ponta a ponta usando tecnologias sem servidor | 369
"VaultName" = $secret.VaultName.ToString()
"SecretCreationDate" = $secret.Created.ToString()
"IsSecretEnabled" = $secret.Enabled.ToString()
"SecretId" = $secret.Id.ToString()
}
}
...
Invoke-WebRequest -Uri $topicEndpoint -Body $finalBody -Headers $header
-Method Post -UseBasicParsing
}
}
Start-Sleep -Seconds 5
}
}
Agora que configuramos os níveis de acesso para o SendGrid, vamos configurar outro
serviço de terceiros, que é chamado de Twilio.
Etapa 9: introdução ao Twilio
Nesta etapa, criaremos uma nova conta do Twilio. O Twilio é usado para enviar
mensagens SMS em massa. Para criar uma conta com o Twilio, navegue até twilio.com
e crie uma nova conta. Depois de criar uma conta com êxito, um número de celular será
gerado e poderá ser usado para enviar mensagens SMS para receptores:
372 | Soluções do Azure usando Aplicativos Lógicos do Azure, Grade de Eventos e Functions
personalization.AddTo(new Email(ConfigurationManager.
AppSettings["toStakeholdersEmail"]));
var messageContent = new Content("text/html", alldata);
message.AddContent(messageContent);
message.AddPersonalization(personalization);
message.Subject = "Key Vault assets Expiring soon..";
message.From = new Email(ConfigurationManager.AppSettings["serviceEmail"]);
string msg = alldata;
sms = new SMSMessage();
sms.Body = msg;
sms.To = ConfigurationManager.AppSettings["adminPhone"];
sms.From = ConfigurationManager.AppSettings["servicePhone"];
return req.CreateResponse(HttpStatusCode.OK, "Hello ");
}
12. Clique em + Nova Saída novamente; isso serve para adicionar uma saída para
o serviço Twilio.
13. Em seguida, selecione SMS do Twilio. Ele pode solicitar que você instale
a extensão de SMS do Twilio. Instale a extensão, o que levará alguns minutos.
14. Depois de instalar a extensão, o formulário de configuração de saída será exibido.
Os itens de configuração importantes neste formulário são Nome do parâmetro
de mensagem, Configuração de SID da conta e Configuração do Token de
Autenticação. Altere o valor padrão para o Nome do parâmetro de mensagem
para sms. Isso é feito porque o parâmetro mensagem já é usado para o parâmetro de
serviço SendGrid. Certifique-se de que o valor de Configuração de SID da conta
seja TwilioAccountSid e que o valor da Configuração do Token de Autenticação
seja TwilioAuthToken. Esses valores já foram configurados em uma etapa anterior
da configuração de definições do aplicativo. O formulário deve ser configurado,
como mostrado na Figura 11.29. Em seguida, você deverá clicar em Salvar:
Criação de uma solução de ponta a ponta usando tecnologias sem servidor | 379
10. Adicione uma nova atividade Analisar JSON depois do gatilho da Grade Eventos —
essa atividade precisa do esquema JSON. Geralmente, o esquema não está disponível,
mas essa atividade ajudará a gerar o esquema se um JSON válido for fornecido a ele:
12. A caixa Conteúdo deve conter conteúdo dinâmico vindo do gatilho anterior,
conforme demonstrado na Figura 11.35:
13. Adicione outra ação de Azure Functions depois de Analisar JSON e então
selecione Escolher uma função do Azure. Selecione os aplicativos de função do
Azure chamados NotificationFunctionAppBook e SMSAndEmailFunction, que
foram criados anteriormente:
384 | Soluções do Azure usando Aplicativos Lógicos do Azure, Grade de Eventos e Functions
Figura 11.37: convertendo dados para JSON antes de enviá-los para uma função do Azure
Criação de uma solução de ponta a ponta usando tecnologias sem servidor | 385
16. Salve o aplicativo lógico inteiro; ele deve ter a seguinte aparência:
Depois de salvar o aplicativo lógico, sua solução estará pronta para ser testada. Se você
não tiver chaves ou segredos, tente adicioná-los com uma data de expiração para que
você possa confirmar se sua solução está funcionando.
Testes
Faça upload de alguns segredos e certificados que tenham datas de expiração para
o Azure Key Vault e execute o runbook da Automação do Azure. O runbook está
agendado para ser executado por agendamento. Além disso, o runbook publicará
eventos na Grade de Eventos. O Aplicativo Lógico deve ser habilitado e ele escolherá o
evento e, por fim, invocará a função do Azure para enviar notificações por email e SMS.
O email deve ter a seguinte aparência:
Resumo
Este capítulo apresentou os Aplicativos Lógicos e demonstrou uma solução completa
de ponta a ponta usando vários serviços do Azure. O capítulo concentrou-se
principalmente na criação de uma arquitetura que integrou vários serviços do
Azure para criar uma solução de ponta a ponta. Os serviços usados na solução foram
Automação do Azure, Aplicativos Lógicos do Azure, Grade de Eventos do Azure,
Azure Functions, SendGrid e Twilio. Esses serviços foram implementados por meio do
portal do Azure e do PowerShell usando entidades de serviço como contas de serviço.
O capítulo também mostrou uma série de maneiras para criar entidades de serviço com
autenticação de senha e certificado.
Uma solução para um problema pode ser encontrada de várias maneiras. Você pode
usar um gatilho do Outlook em um Aplicativo Lógico em vez do SendGrid. Haverá
muitas soluções para um problema — o que vai depender de qual abordagem você está
adotando. Quanto mais familiarizado estiver com os serviços, maior será o número de
opções que você terá. No próximo capítulo, você conhecerá a importância dos eventos
na arquitetura do Azure e de aplicações do Azure.
Soluções de eventos
12
de big data do Azure
Os eventos estão em toda parte. Qualquer atividade ou tarefa que altera o estado do
item de trabalho gera um evento. Devido à falta de infraestrutura e à indisponibilidade
de dispositivos acessíveis, antes não havia muita tração para a Internet das Coisas (IoT).
Historicamente, as organizações usavam ambientes hospedados de provedores de
serviços de Internet (ISPs) que apenas tinham sistemas de monitoramento acima deles.
Esses sistemas de monitoramento geraram eventos que eram poucos e distantes.
No entanto, com o surgimento da nuvem, as coisas estão mudando rapidamente.
Com o aumento das implantações na nuvem, especialmente dos serviços Plataforma
como um Serviço (PaaS), as organizações não precisam mais de muito controle
sobre o hardware e a plataforma, e, agora, toda vez que ocorre uma alteração em um
ambiente, é gerado um evento. Com o surgimento de eventos na nuvem, a IoT ganhou
muita proeminência, e os eventos começaram a roubar os holofotes.
Outro fenômeno recente durante esse período foi a rápida explosão de crescimento na
disponibilidade de dados. A velocidade, a variedade e o volume de dados aumentaram,
assim como a necessidade de soluções para armazenamento e processamento de
dados. Várias soluções e plataformas surgiram, como o Hadoop, data lakes para
armazenamento, data lakes para análise e serviços de aprendizado de máquina.
390 | Soluções de eventos de big data do Azure
Introdução a eventos
Eventos são componentes importantes no Azure e na arquitetura de aplicação do Azure.
Os eventos estão em toda parte no ecossistema de software. Geralmente, qualquer ação
realizada resulta em um evento que pode ser retido, e outras ações podem ser tomadas.
Para levar adiante esta discussão, é importante primeiro entender os fundamentos dos
eventos.
Os eventos ajudam a capturar o novo estado de um recurso de destino. Uma mensagem
é uma notificação leve de uma condição ou uma alteração de estado. Os eventos são
diferentes das mensagens. As mensagens estão relacionadas à funcionalidade de
negócios, como enviar detalhes do pedido para outro sistema. Elas contêm dados
brutos e podem ter um tamanho grande. Em comparação, os eventos são diferentes.
Por exemplo, uma máquina virtual que está sendo interrompida é um evento. A Figura
12.1 demonstra essa transição do estado atual para o estado de destino:
Streaming de eventos
O processamento de eventos à medida que são ingeridos e transmitidos ao longo de
uma janela de tempo fornece insights em tempo real sobre dados. A janela de tempo
pode ser de 15 minutos ou uma hora. A janela é definida pelo usuário e depende dos
insights que devem ser extraídos dos dados. Compras com cartão de crédito por
exemplo: milhões de compras com cartões de crédito acontecem a cada minuto,
e a detecção de fraudes pode ser feita em eventos transmitidos por uma janela de
tempo de um ou dois minutos.
O streaming de eventos refere-se a serviços que podem aceitar dados como e quando
surgem, em vez de aceitá-los periodicamente. Por exemplo, os fluxos de eventos devem
ser capazes de aceitar informações de temperatura de dispositivos como e quando
enviá-las, em vez de fazer com que os dados esperem em uma fila ou um ambiente
de preparo.
O streaming de eventos também tem a capacidade de consultar dados em trânsito.
Estes são dados temporais que são armazenados por um tempo, e as consultas ocorrem
nos dados em movimento. Portanto, os dados não são estacionários. Esse recurso não
está disponível em outras plataformas de dados, que podem consultar apenas dados
armazenados, e não dados temporais que acabaram de ser ingeridos.
Os serviços de streaming de eventos devem ser capazes de escalar facilmente para
aceitar milhões ou até bilhões de eventos. Eles devem estar altamente disponíveis para
que as fontes possam enviar eventos e dados para eles a qualquer momento. A ingestão
de dados em tempo real e a capacidade de trabalhar com esses dados, em vez de dados
armazenados em um local diferente, é fundamental para o streaming de eventos.
392 | Soluções de eventos de big data do Azure
Mas quando já temos tantas plataformas de dados com recursos avançados de execução
de consulta, por que precisamos de streaming de eventos? Uma das principais
vantagens do streaming de eventos é que ele fornece insights e informações em tempo
real cuja utilidade depende do tempo. As mesmas informações encontradas após alguns
minutos ou horas podem não ser tão úteis. Vamos considerar alguns cenários em que
trabalhar com dados de entrada é muito importante. Esses cenários não podem ser
resolvidos de forma eficaz e eficiente por plataformas de dados existentes:
• Detecção de fraude de cartão de crédito: deve acontecer quando uma transação
fraudulenta acontecer.
• Informações de telemetria dos sensores: no caso de dispositivos de IoT que
enviam informações essenciais sobre seus ambientes, o usuário deve ser
notificado como e quando uma anomalia for detectada.
• Painéis ativos: o streaming de eventos é necessário para criar painéis que
mostram informações em tempo real.
• Telemetria do ambiente do datacenter: permitirá que o usuário saiba sobre
invasões, violações de segurança, falhas de componentes, e muito mais.
Hubs de Eventos
Hubs de Eventos é uma plataforma de streaming que fornece funcionalidades
relacionadas à ingestão e ao armazenamento de eventos relacionados a streaming.
Ela pode ingerir dados de uma variedade de fontes. Elas podem ser sensores de IoT
ou qualquer aplicação que use o Kit de Desenvolvimento de Software (SDK) dos Hubs
de Eventos. Esse serviço é compatível com vários protocolos para ingerir e armazenar
dados. Esses protocolos são padrão da indústria e incluem o seguinte:
• HTTP: é uma opção sem estado e não requer uma sessão ativa.
• Advanced Messaging Queuing Protocol (AMQP): requer uma sessão ativa
(ou seja, uma conexão estabelecida usando soquetes) e funciona com os
protocolos Transport Layer Security (TLS) e Secure Socket Layer (SSL).
• Apache Kafka: é uma plataforma de streaming distribuída semelhante ao Stream
Analytics. No entanto, o Stream Analytics foi criado para executar análises em tempo
real em vários fluxos de dados de várias fontes, como sensores de IoT e sites.
Para criar uma instância dos Hubs de Eventos no portal, pesquise Hubs de Eventos
no Marketplace e clique em Criar. Selecione uma assinatura e um grupo de recursos
existente (ou crie um novo). Forneça um nome para o namespace dos Hubs de Eventos,
a região de preferência do Azure para hospedá-lo, a camada de preços (básica ou
padrão, explicada mais adiante) e o número de unidades de taxa de transferência
(explicado posteriormente):
Além disso, a SKU padrão não está disponível em todas as regiões. Sua disponibilidade
deve ser verificada no momento da criação e da implementação do hub de eventos.
A URL para verificar a disponibilidade da região é https://azure.microsoft.com/
global-infrastructure/services/?products=event-hubs.
Não é possível criar hubs de eventos sem um namespace dos Hubs de Eventos.
O namespace de Hubs de Eventos funciona como um contêiner e pode hospedar
vários hubs de eventos. Cada namespace de Hubs de Eventos fornece um ponto de
extremidade exclusivo baseado em REST que é consumido pelos clientes para enviar
dados aos Hubs de Eventos. Esse namespace é o mesmo namespace necessário para
artefatos do Barramento de Serviço, como tópicos e filas.
A cadeia de conexão de um namespace dos Hubs de Eventos é composta pela respectiva
URL, nome da política e chave. Uma cadeia de conexão de exemplo é mostrada no
seguinte bloco de código:
Endpoint=sb://demoeventhubnsbook.servicebus.windows.
net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=M/
E4eeBsr7DAlXcvw6ziFqlSDNbFX6E49Jfti8CRkbA=
Depois que o hub de eventos for criado, você verá na lista de hubs de eventos, conforme
mostrado na Figura 12.8:
Políticas separadas podem ser atribuídas a cada hub de eventos adicionando uma nova
política no nível do hub de eventos.
Depois de criar a política, a cadeia de conexão está disponível no item de menu
esquerdo Assinatura de Acesso Seguro no portal do Azure.
400 | Soluções de eventos de big data do Azure
Como um namespace pode consistir em vários hubs de eventos, a cadeia de conexão para
um hub de eventos individual será semelhante ao bloco de códigos a seguir. A diferença
aqui é o valor da chave e a adição de EntityPath com o nome do hub de eventos:
Endpoint=sb://azuretwittereventdata.servicebus.windows
=rxEu5K4Y2qsi5wEeOKuOvRnhtgW8xW35UBex4VlIKqg=;EntityPath=myeventhub
É importante entender que uma partição pode ter várias chaves. O usuário decide
quantas partições são necessárias, e o hub de eventos decide internamente a melhor
maneira de alocar as chaves de partição entre eles. Cada partição armazena dados
de forma ordenada usando um carimbo de data/hora e eventos mais recentes são
anexados ao final da partição.
É importante observar que não é possível alterar o número de partições depois que
o hub de eventos é criado.
Também é importante lembrar que as partições ajudam a trazer paralelismo e
simultaneidade para aplicações que leem os eventos. Por exemplo, se houver 10 partições,
10 leitores paralelos poderão ler os eventos sem qualquer degradação na performance.
Retenção de mensagens refere-se ao período pelo qual os eventos devem ser
armazenados. Após o término do período de retenção, os eventos são descartados.
402 | Soluções de eventos de big data do Azure
Grupos de consumidores
Os consumidores são aplicações que leem eventos de um hub de eventos. Os grupos
de consumidores são criados para que os consumidores se conectem a ele a fim de
ler os eventos. Pode haver vários grupos de consumidores para um hub de eventos,
e cada um deles tem acesso a todas as partições de um hub de eventos. Cada grupo de
consumidores faz uma consulta sobre os eventos nos hubs de eventos. As aplicações
podem usar grupos de consumidores e cada aplicação receberá uma exibição diferente
dos eventos dos hubs de eventos. Um grupo de consumidores $default padrão é criado
ao criar um hub de eventos. É recomendável para um consumidor estar associado a um
grupo de consumidores para obter excelente performance. No entanto, é possível ter
cinco leitores em cada partição em um grupo de consumidores:
Taxa de transferência
As partições ajudam com a escalabilidade, enquanto a taxa de transferência ajuda com
a capacidade por segundo. Então, qual é a capacidade em termos de Hubs de Eventos?
É a quantidade de dados que podem ser manipulados por segundo.
Nos Hubs de Eventos, uma única TU permite o seguinte:
• 1 MB de dados de ingestão por segundo ou 1.000 eventos por segundo
(o que acontecer primeiro)
• 2 MB de dados de saída por segundo ou 4.096 eventos por segundo
(o que acontecer primeiro)
Cada trabalho consiste em várias entradas, saídas e uma consulta, que transforma
os dados recebidos em novos resultados. Toda a arquitetura do Stream Analytics
é mostrada na Figura 12.14:
Na Figura 12.14, as fontes de eventos são exibidas à extrema esquerda. Estas são as
fontes que produzem os eventos. Podem ser dispositivos IoT, aplicações personalizadas
escritas em qualquer linguagem de programação ou eventos provenientes de outras
plataformas do Azure, como Log Analytics ou Application Insights.
Esses eventos devem primeiro ser ingeridos no sistema, e existem vários serviços do
Azure que podem ajudar a ingerir esses dados. Já vimos os Hubs de Eventos e como eles
ajudam na ingestão de dados. Há outros serviços, como Hub IoT, que também ajudam
na ingestão de dados específicos do dispositivo e do sensor. O Hub IoT e a ingestão são
abordados detalhadamente no Capítulo 11, Projetar soluções IoT. Esses dados ingeridos
passam por processamento à medida que chegam em um fluxo, e esse processamento
é feito usando o Stream Analytics. A saída do Stream Analytics pode ser alimentada em
uma plataforma de apresentação, como o Power BI, para mostrar dados em tempo real
para os stakeholders, ou uma plataforma de armazenamento, como o Cosmos DB, o
Data Lake Storage ou o Armazenamento do Azure, nos quais os dados podem ser lidos e
executados posteriormente pelas filas do Azure Functions e do Barramento de Serviço.
O Stream Analytics ajuda a coletar insights de dados ingeridos em tempo real em uma
janela de tempo e ajuda na identificação de padrões.
Uma cartilha sobre o Stream Analytics | 405
O Stream Analytics é capaz de ingerir milhões de eventos por segundo e pode executar
consultas sobre eles.
Os dados de entrada são compatíveis com qualquer um dos três formatos a seguir:
• JavaScript Object Notation (JSON): um formato leve e baseado em texto simples,
legível para humanos. Consiste em pares nome-valor. Um exemplo de um evento
JSON é o seguinte:
{
"SensorId" : 2,
"humidity" : 60,
"temperature" : 26C
}
406 | Soluções de eventos de big data do Azure
• Valores separados por vírgulas (CSV): também são valores de texto simples,
separados por vírgulas. Um exemplo de CSV é mostrado na Figura 12.16. A primeira
linha é o cabeçalho contendo três campos seguidos por duas linhas de dados:
Os Hubs de Eventos fornece mecanismos para enviar saídas de consultas para destinos.
No momento da redação, o Stream Analytics oferece suporte a vários destinos para
eventos e saídas de consulta, conforme mostrado anteriormente.
Também é possível definir funções personalizadas que podem ser reutilizadas nas
consultas. Há quatro opções fornecidas para definir funções personalizadas.
• Azure Machine Learning
• Funções JavaScript definidas pelo usuário
• Agregados JavaScript definidos pelo usuário
• Azure Machine Learning Studio
Ambiente de hospedagem
Os trabalhos do Stream Analytics podem ser executados em hosts que estão em
execução na nuvem ou podem ser executados em dispositivos do IoT Edge.
Os dispositivos do IoT Edge são dispositivos que estão perto de sensores IoT,
em vez de na nuvem. A Figura 12.18 mostra o painel Novo trabalho do Stream Analytics:
Unidades de streaming
Na Figura 12.18, você pode ver que a única configuração exclusiva para o Stream
Analytics é unidades de streaming. Unidades de streaming referem-se aos recursos
(isto é, CPU e memória) que são atribuídos para executar um trabalho do Stream
Analytics. As unidades de streaming mínimas e máximas são 1 e 120, respectivamente.
As unidades de streaming devem ser pré-alocadas de acordo com a quantidade de dados
e do número de consultas executadas nesses dados. Caso contrário, o trabalho falhará.
Nesta aplicação de exemplo, estaremos lendo todos os tweets que contenham a palavra
"Azure" e armazenando-os em uma conta de armazenamento do Azure.
Para criar essa solução, primeiro precisamos provisionar todos os recursos necessários.
Neste momento, um namespace dos Hubs de Eventos deve ter sido criado. É um
pré-requisito ter um namespace antes que um hub de eventos possa ser criado.
A próxima etapa é provisionar um hub de eventos.
Após essa etapa, você terá um hub de eventos que pode ser usado para enviar dados de
eventos, que são armazenados em um armazenamento durável, como um data lake ou
uma conta de armazenamento do Azure, para serem usados pelos serviços downstream.
Provisionar um novo grupo de recursos | 411
Depois que o aplicativo lógico for criado, selecione Quando um novo tweet for
postado , faça login e configure-o como mostrado na Figura 12.23. Você precisará
de uma conta válida no Twitter antes de configurar esse gatilho:
Figura 12.24: adicionando uma ação para enviar tweets para o hub de eventos
Provisionar um novo grupo de recursos | 413
Selecione o nome do hub de eventos que foi criado em uma etapa anterior.
O valor especificado na caixa de texto do conteúdo é uma expressão que foi redigida
dinamicamente usando funções fornecidas pelo Aplicativo Lógico e dados do Twitter.
Ao clicar em Adicionar conteúdo dinâmico, uma caixa de diálogo é fornecida, por meio
da qual é possível redigir a expressão:
A consulta é bem simples; você está apenas copiando os dados da entrada para a saída:
Embora este exemplo envolva apenas a cópia de dados, pode haver consultas mais
complexas para realizar a transformação antes de carregar dados em um destino.
Isso conclui todas as etapas para a aplicação. Agora, você deve conseguir executá-la.
Executar a aplicação
O aplicativo lógico deve estar habilitado, e o Stream Analytics deve estar em execução.
Agora, execute o aplicativo lógico. Isso criará um trabalho para executar todas as
atividades nele, conforme mostrado na Figura 12.30:
Como exercício, você pode estender essa solução de exemplo e avaliar o sentimento
dos tweets a cada três minutos. O fluxo de trabalho de Aplicativos Lógicos para esse
exercício será o seguinte:
Para detectar o sentimento, você precisará usar a API de Análise de Texto, que deve ser
configurada antes de ser usada em Aplicativos Lógicos.
Resumo
Este capítulo abordou tópicos relacionados ao streaming e o armazenamento
de eventos. Os eventos tornaram-se uma consideração importante na arquitetura
geral de soluções. Abordamos recursos importantes, como os Hubs de Eventos e
o Stream Analytics, e conceitos fundamentais, como grupos de consumidores e taxas
de transferência, além de criar uma solução completa usando-os juntamente com
Aplicativos Lógicos. Você aprendeu que os eventos são gerados de várias fontes e, para
obter insights em tempo real sobre atividades e seus eventos relacionados, serviços
como os Hubs de Eventos e o Stream Analytics desempenham uma função significativa.
No próximo capítulo, aprenderemos a integrar o Azure DevOps e o Jenkins e
implementar algumas das práticas recomendadas da indústria ao desenvolver soluções.
Integrar o DevOps
13
do Azure
No capítulo anterior, você aprendeu sobre eventos de big data e seu relacionamento
com os Hubs de Eventos do Azure e os serviços do Stream Analytics. O desenvolvimento
de software é uma tarefa complexa composta de vários processos e ferramentas,
envolvendo pessoas de diferentes departamentos. Todos precisam se unir e trabalhar
de maneira coesa. Com tantas variáveis, os riscos são altos quando você entrega aos
clientes finais. Uma pequena omissão ou configuração incorreta pode arruinar a
aplicação. Este capítulo é sobre a adoção e a implementação de práticas que reduzem
esse risco consideravelmente e garantem que um software de alta qualidade possa ser
entregue ao cliente constantemente.
422 | Integrar o DevOps do Azure
Antes de analisar os detalhes do DevOps, veja a seguir uma lista dos problemas
enfrentados pelas empresas de software que são resolvidos pelo DevOps:
• Organizações rígidas que não aceitam mudanças
• Processos demorados
• Equipes isoladas trabalhando em silos
• Design monolítico e implantações repentinas
• Execução manual
• Falta de inovação
DevOps
No momento, não há um consenso na indústria quanto à definição de DevOps.
As organizações têm formulado sua própria definição de DevOps e tentado
implementá-la. Elas têm sua própria perspectiva e acreditam que terão implementado
o DevOps quando implementarem o gerenciamento de automação e configuração
e usarem processos ágeis.
DevOps | 423
A essência do DevOps
O DevOps não é um paradigma novo. No entanto, tem ganhado muita popularidade
e tração. Sua adoção está no auge, e cada vez mais empresas estão iniciando essa
jornada. Eu me referi intencionalmente ao DevOps como uma jornada porque há
diferentes níveis de maturidade dentro dele. Enquanto a implementação bem-sucedida
de implantação e entrega contínuas é considerada como o nível mais alto de maturidade
nessa jornada, a adoção do desenvolvimento de software Agile e controle de código-
fonte é considerada como a primeira etapa na jornada de DevOps.
426 | Integrar o DevOps do Azure
Práticas de DevOps
O DevOps consiste em várias práticas, cada uma fornecendo funcionalidades
distintas ao processo como um todo. O diagrama a seguir mostra a relação entre elas.
O gerenciamento de configuração, a integração contínua e a implantação contínua
formam as práticas fundamentais que habilitam o DevOps. Quando fornecemos
serviços de software que combinam esses três serviços, alcançamos a entrega contínua.
A entrega contínua é a capacidade e o nível de maturidade de uma organização
dependente da maturidade de gerenciamento de configuração, integração contínua
e implantação contínua. Comentários contínuos em todos os estágios constituem o loop
de comentários que ajuda a fornecer serviços melhores aos clientes. Ele é executado
em todas as práticas de DevOps. Vamos nos aprofundar em cada um desses recursos
e práticas de DevOps:
Gerenciamento de configuração
Serviços e aplicações de negócios precisam de um ambiente em que possam ser
implantados. Normalmente, o ambiente é uma infraestrutura composta de vários
servidores, computadores, rede, armazenamento, contêineres e muitos outros
serviços funcionando em conjunto, de modo que as aplicações de negócios possam
ser implantadas sobre eles. Aplicações de negócios são decompostas em vários serviços
executados em vários servidores, na infraestrutura local ou na nuvem, e cada serviço
tem sua própria configuração, juntamente com requisitos relacionados à configuração
da infraestrutura. Em suma, a aplicação e a infraestrutura são necessárias para fornecer
sistemas aos clientes e cada um tem sua própria configuração. Se houver desvio na
configuração, a aplicação pode não funcionar conforme o esperado, resultando em
tempo de inatividade e falhas. Além disso, como os processos de Gerenciamento do
ciclo de vida da aplicação (ALM) determinam o uso de vários estágios e ambientes,
um aplicação será implantada em vários ambientes com diferentes configurações.
A aplicação será implantada no ambiente de desenvolvimento para que os
desenvolvedores vejam o resultado do seu trabalho. Ela será implantada em vários
ambientes de teste com diferentes configurações para testes funcionais, de carga
e estresse, de performance, de integração e muito mais. Também será implantada no
ambiente de pré-produção para realizar testes de aceitação do usuário e, por fim, no
ambiente de produção. É importante que uma aplicação possa ser implantada em vários
ambientes sem alterações manuais na sua configuração.
O gerenciamento de configuração fornece um conjunto de processos e ferramentas
para garantir que cada ambiente e aplicação tenha sua própria configuração. Ele
acompanha itens de configuração, e qualquer coisa que mude de um ambiente para
outro deve ser tratada como um item de configuração. Ele também define as relações
entre os itens de configuração e como as alterações em um desses itens afetará o outro.
Uso do gerenciamento de configuração
O gerenciamento de configuração ajuda nos seguintes pontos:
• Infraestrutura como Código: quando o processo de provisionamento da
infraestrutura e sua configuração são representados por meio de código,
e o mesmo código passa pelo processo de ciclo de vida da aplicação, isso é
conhecido como Infraestrutura como Código (IaC). O IaC ajuda a automatizar
o provisionamento e a configuração de infraestrutura. Ela também representa
toda a infraestrutura em código que pode ser armazenado em um repositório
e submetido ao controle de versão. Isso permite que os usuários empreguem
as configurações do ambiente anterior quando necessário. Também permite o
provisionamento de um ambiente várias vezes de forma consistente e previsível.
Todos os ambientes provisionados dessa forma são consistentes e iguais em todos
os estágios de ALM. Há muitas ferramentas que ajudam a alcançar a IaC, incluindo
modelos do ARM, Ansible e Terraform.
Práticas de DevOps | 429
Modelos do ARM
Os modelos do ARM são os principais meios de provisionamento de recursos no
ARM. Eles fornecem um modelo declarativo por meio do qual recursos e suas
configurações, scripts e extensões são especificados. Os modelos do ARM se baseiam
no formato JavaScript Object Notation (JSON). Eles usam as convenções e a sintaxe
JSON para declarar e configurar recursos. Os arquivos JSON são baseados em texto,
fáceis de usar e de ler. Eles podem ser armazenados em um repositório de código-
fonte e submetidos ao controle de versão. Eles também servem para representar
a infraestrutura como código que pode ser usada para provisionar recursos em
grupos de recursos do Azure de forma constante, previsível, consistente e uniforme.
Integração contínua
Vários desenvolvedores escrevem código que eventualmente é armazenado em um
repositório comum. O código normalmente é verificado ou enviado ao repositório
quando os desenvolvedores terminam de desenvolver seus recursos. Isso pode ocorrer
em um dia ou pode levar dias ou semanas. Alguns dos desenvolvedores talvez estejam
trabalhando no mesmo recurso e também seguindo as mesmas práticas de envio/
verificação de código em dias ou semanas. Isso pode criar problemas para a qualidade
do código. Um dos princípios do DevOps é falhar rápido. Os desenvolvedores devem
verificar/enviar o código ao repositório frequentemente e compilá-lo para verificar
se não criou bugs e se ele é compatível com o código escrito por seus colegas. Se um
desenvolvedor não seguir essa prática, o código em sua máquina ficará muito grande,
e será difícil integrá-lo ao código de outro colega. Além disso, se a compilação falhar,
será difícil e demorado corrigir os problemas decorrentes disso.
Práticas de DevOps | 431
Integração de código
A integração contínua resolve esses tipos de desafios. Ela ajuda na compilação e na
validação do código enviado/verificado por um desenvolvedor por meio de uma série
de etapas de validação. A integração contínua cria um fluxo de processo que consiste
em várias etapas. A integração contínua é composta por compilações automatizadas
contínuas e testes automatizados contínuos. Normalmente, a primeira etapa é o build
do código. Após o build bem-sucedido, cada etapa é responsável por validar o código de
uma perspectiva específica. Por exemplo, os testes de unidade podem ser executados
no código compilado e a cobertura de código pode ser executada para verificar quais
caminhos de código são executados pelos testes de unidade. Eles podem revelar se
testes de unidade abrangentes estão escritos ou se há espaço para adicionar mais testes
de unidade. O resultado final da integração contínua são pacotes de implantação que
podem ser usados pela implantação contínua para implantá-los em vários ambientes.
Envio de código frequente
Os desenvolvedores são incentivados a verificar seu código várias vezes por dia, em vez
de fazer isso após dias ou semanas. A integração contínua inicia a execução do pipeline
inteiro logo após a verificação ou o envio do código. Se a compilação for bem-sucedida,
os testes de código e outras atividades que fazem parte do pipeline serão executados
sem erros, o código será implantado em um ambiente de teste, e testes de integração
serão executados nele.
Maior produtividade
A integração contínua aumenta a produtividade dos desenvolvedores. Eles não precisam
compilar seu código manualmente, executar vários tipos de testes, um após o outro, e
criar pacotes a partir deles. Ela também reduz o risco de introdução de bugs no código,
o qual não fica obsoleto. Ela fornece comentários precoces aos desenvolvedores sobre
a qualidade do seu código. Em geral, a qualidade dos produtos finais é alta, e eles são
entregues com mais rapidez por meio da adoção de práticas de integração contínua.
Um pipeline de integração contínua de exemplo é mostrado aqui:
Automação de build
A automação de build consiste em várias tarefas executadas em sequência. Geralmente,
a primeira tarefa é responsável pela obtenção do código-fonte mais recente do
repositório. O código-fonte pode incluir vários projetos e arquivos. Eles são compilados
para gerar artefatos, como executáveis, bibliotecas de vínculo dinâmico e assemblies.
A automação de build bem-sucedida revela que não há erros de tempo de compilação
no código.
Pode haver mais etapas na automação de build dependendo da natureza e do tipo
de projeto.
Automação de testes
A automação de testes consiste em tarefas que são responsáveis por validar diferentes
aspectos do código. Essas tarefas têm como objetivo testar o código de uma perspectiva
diferente e são executadas em sequência. Geralmente, a primeira etapa é a execução de
uma série de testes de unidade no código. Os testes de unidade se referem ao processo
de testes da menor denominação de um recurso, validando seu comportamento
isolado de outros recursos. Eles podem ser manuais ou automatizados. No entanto,
a preferência é por testes de unidade automatizados.
A cobertura de código é outro tipo de teste automatizado que pode ser realizado
no código para descobrir qual parte dele é executada durante os testes de unidade.
Ela geralmente é representada como uma porcentagem e se refere à parte de código
testável por meio de testes de unidade. Se a cobertura de código não for próxima a
100%, é porque o desenvolvedor não criou testes de unidade para esse comportamento
ou o código não coberto não é necessário.
A execução bem-sucedida da automação de testes que não resultar em nenhuma falha
de código significativa deverá iniciar a execução das tarefas de empacotamento. Pode
haver mais etapas para a automação de testes dependendo da natureza e do tipo de
projeto.
Empacotamento
O empacotamento se refere ao processo de geração de artefatos implantáveis, como
pacotes MSI, NuGet e webdeploy, pacotes de bancos de dados, seu versionamento
e armazenamento em um local onde possam ser consumidos por outros pipelines
e processos.
Depois que o processo de integração contínua for concluído, o processo de implantação
contínua será iniciado, e esse será o foco da próxima seção.
Práticas de DevOps | 433
Implantação contínua
Quando o processo chegar na implantação contínua, a integração contínua terá
garantido que tenhamos bits totalmente funcionais de uma aplicação que agora poderá
passar por diferentes atividades de implantação contínua. A implantação contínua se
refere à capacidade de implantação de serviços e aplicações de negócios em ambientes
de pré-produção e produção por meio da automação. Por exemplo, a implantação
contínua pode provisionar e configurar o ambiente de pré-produção, implantar
aplicações nele e configurá-los. Após a realização de várias validações, como testes
funcionais e de performance no ambiente de pré-produção, o ambiente de produção
é provisionado, configurado e a aplicação é implantada em ambientes de produção
por meio da automação. Não há etapas manuais no processo de implantação. Todas as
tarefas de implantação são automatizadas. A implantação contínua pode provisionar
o ambiente e implantar a aplicação do zero, enquanto poderá simplesmente implantar
as alterações delta no ambiente existente se o ambiente já existir.
Todos os ambientes são provisionados por meio de automação usando a IaC. Isso
garante que todos os ambientes, sejam eles de desenvolvimento, teste, pré-produção
ou produção, sejam iguais. Da mesma forma, a aplicação é implantada por meio da
automação, garantindo que também seja implantado uniformemente em todos os
ambientes. A configuração nesses ambientes pode ser diferente para a aplicação.
A implantação contínua geralmente está assimilada à integração contínua. Quando
a integração contínua conclui seu trabalho gerando os pacotes implantáveis finais,
a implantação contínua entra em ação e inicia seu próprio pipeline. Esse pipeline
é chamado de pipeline de lançamento. O pipeline de lançamento consiste em
vários ambientes, e cada um deles consiste em tarefas responsáveis por provisionar
e configurar o ambiente, implantar e configurar aplicações, executar validação
operacional em ambientes e testar a aplicação em vários ambientes.
Empregar a implantação contínua fornece benefícios imensos. Há um alto nível de
confiança no processo de implantação como um todo que ajuda em lançamentos mais
rápidos e livres de riscos na produção. As chances de algo dar errado são drasticamente
reduzidas. A equipe terá níveis de estresse mais baixos, e a reversão para o ambiente
de trabalho anterior será possível se houver problemas na versão atual:
Provisionar Implantar Automação Testes de Ambiente Configurar Configurar
ambiente pacotes de testes performance de produção ambiente aplicação
Entrega contínua
A entrega contínua e a implantação contínua podem parecer semelhantes para muitos
leitores. No entanto, não são a mesma coisa. Enquanto a implantação contínua envolve
a implantação em vários ambientes e, por fim, no ambiente de produção por meio da
automação, as práticas de entrega contínua consistem na capacidade de gerar pacotes
de aplicações de forma que sejam prontamente implantáveis em qualquer ambiente.
Para gerar artefatos prontamente implantáveis, a integração contínua deve ser usada
para gerar os artefatos da aplicação e um ambiente novo ou existente deve ser usado
para implantar esses artefatos e conduzir testes funcionais, testes de performance
e testes de aceitação do usuário por meio da automação. Depois que essas atividades
forem executadas com êxito e sem erros, o pacote da aplicação será considerado
prontamente implantável. A entrega contínua inclui a integração e implantação
contínua em um ambiente para validações finais. Ele ajuda a obter feedback mais
rapidamente de ambas as operações e o usuário final. Esses comentários podem ser
usados para implementar iterações subsequentes.
Na próxima seção, analisaremos o aprendizado contínuo.
Aprendizado contínuo
Com todas as práticas de DevOps mencionadas anteriormente, é possível criar ótimas
aplicações de negócios e implantá-las automaticamente no ambiente de produção. No
entanto, os benefícios de DevOps não serão duradouros se os princípios de comentários
e melhoria contínuos não estiverem em vigor. É muito importante que comentários em
tempo real sobre o comportamento da aplicação, provenientes dos usuários finais e da
equipe de operações, sejam repassados à equipe de desenvolvimento.
Os comentários devem ser repassados às equipes, fornecendo informações relevantes
sobre o que está dando certo e, mais importante, o que não está dando certo.
A arquitetura e o design de uma aplicação devem ser criados com o monitoramento,
a auditoria e a telemetria em mente. A equipe de operações deve coletar as informações
de telemetria do ambiente de produção, capturando os bugs e problemas, e repassá-los
à equipe de desenvolvimento para que possam ser corrigidos em versões subsequentes.
436 | Integrar o DevOps do Azure
O aprendizado contínuo ajuda a tornar a aplicação robusta e resistente a falha. Ele ajuda
a garantir que a aplicação atenda aos requisitos dos consumidores. A Figura 13.4 mostra
o loop de comentários que deve ser implementado entre diferentes equipes:
Monitoramento Problemas Comentários
Azure DevOps
Vamos ver outro serviço online de alta qualidade, o Visual Studio Team Services (VSTS),
que permite a integração, a implantação e a entrega contínuas facilmente: Azure
DevOps. Na verdade, seria mais apropriado chamá-lo de um conjunto de serviços
disponíveis sob um único nome. O Azure DevOps é uma PaaS fornecida pela Microsoft
e hospedada na nuvem. O mesmo serviço está disponível como Team Foundation
Server (TFS) na infraestrutura local. Todos os exemplos mostrados neste livro usam
o Azure DevOps.
De acordo com a Microsoft, o Azure DevOps é uma plataforma de colaboração
baseada na nuvem que ajuda as equipes a compartilhar código, acompanhar o trabalho
e enviar software. Azure DevOps é um novo nome; anteriormente, ele era conhecido
como Visual Studio Team Services (VSTS). O Azure DevOps é uma ferramenta e um
serviço de desenvolvimento de software corporativo que permite que as organizações
forneçam instalações de automação ao processo de gerenciamento do ciclo de vida
da aplicação de ponta a ponta, desde planejamento até a implantação de aplicações
e a obtenção de comentários em tempo real em sistemas de software. Isso aumenta
a maturidade e a capacidade de uma organização fornecer sistemas de software de
alta qualidade aos seus clientes.
O fornecimento bem-sucedido de software envolve a união eficiente de muitos
processos e atividades. Entre eles estão a execução e a implementação de vários
processos Agile, o aumento da colaboração entre as equipes, a transição perfeita
e automática de artefatos de uma fase de ALM para outra, e implantações em vários
ambientes. É importante acompanhar e relatar essas atividades para medir, agir
e aprimorar os processos de entrega. O Azure DevOps torna isso simples e fácil.
Ele fornece todo um conjunto de serviços que possibilita o seguinte:
Azure DevOps | 437
A tabela a seguir mostra todos os serviços disponíveis para um projeto típico na barra
de navegação à esquerda do Azure DevOps:
Serviço Descrição
O Boards ajuda no planejamento do projeto exibindo o progresso atual de
tarefas, pendências e histórias de usuários ao lado de informações de sprint.
Boards
Ele também fornece um processo de Kanban e ajuda a representar as tarefas
atuais em andamento e concluídas.
O Repos ajuda no gerenciamento de repositórios. Ele fornece suporte para criar
Repos ramificações adicionais, mesclá-las, resolver conflitos de código e também gerenciar
permissões. Pode haver vários repositórios dentro de um projeto.
Planos Todos os artefatos relacionados a testes, junto com seu gerenciamento, estão
de teste disponíveis nos planos de teste.
TFVC
O TFVC é a maneira tradicional e centralizada de implementar o controle de versão na
qual há um repositório central e os desenvolvedores trabalham nele diretamente no
modo conectado para verificar suas alterações. Se o repositório central estiver offline
ou não disponível, os desenvolvedores não poderão verificar seu código e terão que
esperar que ele fique online e disponível. Outros desenvolvedores poderão ver somente
o código verificado. Os desenvolvedores podem agrupar várias alterações em um
único conjunto a fim de verificar alterações de código que são logicamente agrupadas
para formar uma única alteração. O TFVC bloqueia os arquivos de código que estão
passando por edições. Outros desenvolvedores poderão ler um arquivo bloqueado, mas
não poderão editá-lo. Eles deverão aguardar a conclusão da edição anterior e liberar
o bloqueio para poder editá-lo. O histórico de verificações e alterações é mantido
no repositório central, enquanto os desenvolvedores possuem a cópia funcional dos
arquivos, mas não o histórico.
O TFVC funciona muito bem com equipes grandes que estão trabalhando nos mesmos
projetos. Isso permite o controle do código-fonte em um local central. Ele também
funciona melhor quando projetos têm uma longa duração, pois o histórico é gerenciado
em um local central. O TFVC não tem problemas para trabalhar com arquivos grandes
e binários.
Git
Por outro lado, o Git é uma maneira moderna e distribuída de implementar o controle
de versão na qual os desenvolvedores podem trabalhar em suas próprias cópias locais
de código e histórico no modo offline. Os desenvolvedores podem trabalhar offline no
seu clone de código local. Cada desenvolvedor tem uma cópia local do código e todo
o seu histórico e trabalha nas suas alterações com esse repositório local. Ele pode
confirmar o código no repositório local. Pode se conectar ao repositório central para
a sincronização do repositório local, conforme necessário. Isso permite que todos os
desenvolvedores trabalhem em qualquer arquivo, pois eles trabalharão na sua cópia
local. A ramificação no Git não cria outra cópia do código original, e sua criação
é extremamente rápida.
O Git funciona bem com equipes pequenas e grandes. A ramificação e a mesclagem
são tranquilas com opções avançadas do Git.
O Git é a maneira recomendada de usar o controle de código-fonte devido
à funcionalidade avançada que oferece. Usaremos o Git como o repositório para
nossa aplicação de exemplo neste livro. Na próxima seção, vamos ter uma visão geral
detalhada da implementação da automação por meio do DevOps.
440 | Integrar o DevOps do Azure
Se o build
Enviar falhar, o
Executar
alterações Gerar rótulo desenvolvedor
testes de
para repo do build trabalhará
unidade
compartilhado novamente
no código
Pipeline
Implantar Executar
de build Sucesso
no ambiente atividades
executado ou reversão
de teste de teste
com sucesso
Aprovação
Pipeline de Criar modelos Executar
para
build gerou de ARM de validação
implantação
artefatos ambientes operacional
no próximo/
de teste na produção
produção
Começar
Executar a implantar Criar/atualizar Implantar
pipeline de no primeiro/ o próximo na produção
lançamento ambiente ambiente
de teste
Log Analytics
O Log Analytics é um serviço de auditoria e monitoramento fornecido pelo Azure para
obter informações em tempo real sobre todas as alterações, os desvios e os eventos
que ocorrem dentro de máquinas virtuais e contêineres. Ele fornece um painel e espaço
de trabalho centralizado para que administradores de TI possam exibir, pesquisar
e realizar pesquisas detalhadas em todas as alterações, os desvios e eventos que
ocorrerem nessas máquinas virtuais. Ele também fornece agentes que são implantados
em máquinas virtuais e contêineres de destino. Depois de implantados, esses agentes
começam a enviar todas as alterações, os eventos e desvios para o espaço de trabalho
centralizado. Vamos conferir as opções de armazenamento para implantar várias
aplicações.
Ferramentas de gerenciamento
Todas as ferramentas de gerenciamento, como Kubernetes, DC/OS, Docker Swarm
e ferramentas ITIL devem ser provisionadas antes de criar e implantar a solução.
Concluiremos esta seção sobre como preparar o DevOps com ferramentas de
gerenciamento. Há várias opções para cada atividade em um ecossistema de DevOps,
e devemos habilitá-las como parte da jornada de DevOps. Não deve ser uma
consideração posterior, mas sim parte do planejamento de DevOps.
444 | Integrar o DevOps do Azure
Servidor Lógico
Instâncias
Azure Active
Banco de dados Banco de dados
Directory Token de acesso
Serviço de Aplicativo
Autenticar
Conta de
Endereço IP armazenamento
Produção
Contêiner Blob
Preparo
Validar Logs de Logs de
implantação aplicativo servidor Web
Slots de implantação
implantar
Grupo de
Controle de fonte recursos
Figura 13.8: uma arquitetura típica do Serviço de Aplicativo de PaaS do Azure
A arquitetura mostra alguns dos componentes importantes, como SQL do Azure, contas
de armazenamento e o sistema de controle de versão, que participam da arquitetura
de solução de nuvem baseada no Serviço de Aplicativo do Azure. Esses artefatos
devem ser criados usando modelos do ARM. Esses modelos do ARM devem fazer parte
da estratégia global de gerenciamento de configuração. Ele pode ter seus próprios
pipelines de gerenciamento de lançamento e build muito semelhantes àquele mostrado
na Figura 13.9:
DevOps para soluções de PaaS | 445
Slots de implantação
O Serviço de Aplicativo do Azure fornece slots de implantação que torna a implantação
neles tranquila e fácil. Existem vários slots e a troca entre slots é feita em um nível
de DNS. Isso significa que qualquer coisa no slot de produção pode ser trocado com
um slot de preparação simplesmente trocando as entradas de DNS. Isso ajuda na
implantação inicial da solução de nuvem personalizada na preparação e, após todas
as verificações e testes, eles podem ser trocados para produção, se considerados
satisfatórios. No entanto, caso ocorram problemas na produção após a troca, os bons
valores anteriores do ambiente de produção podem ser restabelecidos por meio de
uma nova troca. Vamos avançar para compreender a oferta de banco de dados do
Azure e alguns de seus principais recursos.
446 | Integrar o DevOps do Azure
SQL do Azure
O SQL do Azure é um serviço PaaS do SQL fornecido pelo Azure para hospedar bancos
de dados. O Azure fornece uma plataforma segura para hospedar bancos de dados
e assume total propriedade para gerenciar a disponibilidade, a confiabilidade e a
escalabilidade do serviço. Com o SQL do Azure, não é necessário provisionar máquinas
virtuais personalizadas, implantar um SQL Server e configurá-lo. Em vez disso, a equipe
do Azure faz isso nos bastidores e as gerencia em seu nome. Ela também fornece um
serviço de firewall que habilita a segurança, e somente um endereço IP permitido pelo
firewall pode se conectar ao servidor e acessar o banco de dados. As máquinas virtuais
provisionadas para hospedar aplicativos Web têm endereços IP públicos distintos
atribuídos a elas e são adicionadas dinamicamente às regras de firewall do SQL do
Azure. O SQL Server Azure e seu banco de dados são criados ao executar o modelo
do ARM. Em seguida, abordaremos os pipelines de build e lançamento.
Restauração
do NuGet
Solução de build
450 | Integrar o DevOps do Azure
Assemblies
de teste
Publicar
caminho de
símbolos
Publicar
Artefato -
Aplicação MVC
DevOps para soluções de PaaS | 451
Publicar
Artefato -
código IaaS
(modelos ARM)
Solução
de build
Database1/
Database1.
sqlproj
452 | Integrar o DevOps do Azure
Copiar
Arquivos para:
$ (build.artifact-
stagingdirect-
ory)
Publicação do
SQL do Azure
Nesta seção, você viu maneiras de configurar pipelines de build e lançamento no Azure
DevOps. Na próxima seção, o foco será diferentes arquiteturas, como IaaS, contêineres
e diferentes cenários.
458 | Integrar o DevOps do Azure
Figura 13.15: arquitetura típica para uma solução de IaaS baseada em máquinas virtuais
O pipeline de build
Um pipeline de build típico para uma solução de IaaS baseada em máquinas virtuais
é mostrado a seguir. Um pipeline de lançamento é iniciado quando um desenvolvedor
envia seu código ao repositório. O pipeline de build é iniciado automaticamente como
parte da integração contínua. Ele compila e cria o código, realiza testes de unidade
e verificações de qualidade nele, verifica a qualidade do código e gera a documentação
desde os comentários do código. Ele implanta os novos binários no ambiente de
desenvolvimento (observe que esse ambiente não é recém-criado), altera configurações,
realiza testes de integração e gera rótulos de build para fácil identificação. Em seguida,
ele deposita os artefatos gerados em um local acessível pelo pipeline de lançamento.
Caso haja algum problema durante a execução de qualquer etapa desse pipeline, isso
será comunicado ao desenvolvedor como parte dos comentários do pipeline de build
para que possa retrabalhar e reenviar suas alterações. O pipeline de build falhará ou
será aprovado com base na gravidade dos problemas encontrados, e isso varia de
acordo com a organização. Um pipeline de build típico é mostrado na Figura 13.16:
460 | Integrar o DevOps do Azure
Atualizar Se o build
Enviar falhar, o
Execução de ambiente de
alterações Gerar rótulo desenvolvedor
testes de desenvolvimento
para repo do build trabalhará
unidade com novos
compartilhado novamente no
binários
código
CI do VSTS
Executar Verificar no
inicia e Pipeline de
Aplicar testes de código na
começa build compila
configuração integração ramificação
a criar o o código
local
pipeline
O pipeline de lançamento
Um pipeline de lançamento típico para uma implantação de IaaS baseada em máquinas
virtuais é mostrado a seguir. Um pipeline de lançamento é iniciado após a conclusão do
pipeline de build. A primeira etapa no pipeline de lançamento é a coleta dos artefatos
gerados pelo pipeline de build. Eles geralmente são documentos de configuração,
binários e assemblies implantáveis. O pipeline de lançamento executa e cria ou atualiza
o primeiro ambiente que geralmente é um ambiente de teste. Ele usa modelos do ARM
para provisionar todos os recursos e serviços IaaS e PaaS no Azure, além de configurá-
los. Ele também ajuda na execução de scripts e na configuração do DSC após a criação de
máquinas virtuais como etapas de pós-criação. Isso ajuda a configurar o ambiente dentro
da máquina virtual e do sistema operacional. Nesse estágio, os binários de aplicações
do pipeline de build são implantados e configurados. Diferentes testes automatizados
são realizados para verificar o funcionamento na solução, e, se considerado satisfatório,
o pipeline passa para a implantação no próximo ambiente após obter as aprovações
necessárias. As mesmas etapas são executadas novamente no próximo ambiente,
incluindo o ambiente de produção. Por fim, os testes de validação operacional são
realizados na produção para garantir que a aplicação esteja funcionando conforme
o esperado e que não haja desvios.
DevOps para IaaS | 461
Nesse estágio, se houver problemas ou bugs, eles deverão ser corrigidos e o ciclo
inteiro deverá ser repetido. No entanto, se isso não acontecer dentro de um período
estipulado, o último instantâneo conhecido deverá ser restaurado no ambiente de
produção para minimizar o tempo de inatividade. Um pipeline de lançamento típico
é mostrado na Figura 13.17:
Criar ambiente
Configurar Configurar
Pipeline de teste Implantar
ambiente de ambiente de
de build e configurar
- Modelos do ARM teste usando teste usando
executado aplicação
- Máquinas virtuais a configuração a configuração
com sucesso (DSC)
- Outros recursos do DSC do DSC
de laaS
Criar/atualizar
Começar a o próximo
Pipeline de implantar no Implantar ambiente de estágio Realizar testes
build gerou primeiro/ e configurar - Modelos do ARM e obter
artefatos ambiente aplicação - Máquinas virtuais aprovação
de teste - Outros recursos de
laaS
Obter
Executar Preparar Executar aprovação Implantar
pipeline de para atividades para implantar e configurar
lançamento implantação de teste no próximo produção
estágio
Executar
teste de
validação
operacional
Esta seção conclui o processo de DevOps para soluções de IaaS, e o próximo capítulo se
concentrará em contêineres em máquinas virtuais. Observe que os contêineres também
podem ser executados em PaaS, como o Serviço de Aplicativo e o Azure Functions.
462 | Integrar o DevOps do Azure
Contêineres
Os contêineres são uma tecnologia de virtualização. No entanto, eles não virtualizam
servidores físicos. Em vez disso, contêineres são uma virtualização no nível do
sistema operacional. Isso significa que os contêineres compartilham o kernel do
sistema operacional fornecido pelo host entre eles e com o host. A execução de vários
contêineres em um host (físico ou virtual) compartilha o kernel do sistema operacional
do host. Há um único kernel de sistema operacional fornecido pelo host e usado por
todos os contêineres em execução sobre ele.
Os contêineres também são completamente isolados de seu host e de outros contêineres,
assim como uma máquina virtual. Os contêineres usam namespaces do sistema
operacional, grupos de controle no Linux, para fornecer a percepção de um novo ambiente
de sistema operacional e usar técnicas específicas de virtualização do sistema operacional
no Windows. Cada contêiner tem sua própria cópia dos recursos do sistema operacional.
DevOps com contêineres | 463
Docker
O Docker fornece recursos de gerenciamento a contêineres. Ele é composto por dois
executáveis:
• Daemon do Docker
• Cliente do Docker
O pipeline de build
Da perspectiva do build, não há nenhuma diferença entre o contêiner e uma solução baseada
em máquinas virtuais. A etapa de build permanece a mesma. Um pipeline de lançamento
típico para uma implantação de IaaS baseada em contêineres é mostrado a seguir.
O pipeline de lançamento
A única diferença entre um pipeline de lançamento típico para uma implantação
baseada em contêineres de IaaS, e o pipeline de lançamento é o gerenciamento de
imagens de contêiner e a criação de contêineres usando o Dockerfile e o Docker
Compose. Os utilitários avançados de gerenciamento de contêineres avançados, como
Docker Swarm, DC/OS e Kubernetes, também podem ser implantados e configurados
como parte do gerenciamento de versões. No entanto, note que essas ferramentas de
gerenciamento de contêineres devem fazer parte do pipeline de lançamento de serviços
compartilhados, conforme abordado anteriormente. A Figura 13.19 mostra um pipeline
de lançamento típica para uma solução baseada em contêineres:
464 | Integrar o DevOps do Azure
Criar e
Pipeline executar Executar
contêineres Implantar Implantar teste de
de build
e configurar e configurar validação
executado
- Configuração aplicação produção operacional
com sucesso
do DSC
Fazer o
Pipeline de download de Executar Realizar
build gerou imagens de atividades teste e obter
artefatos contêineres de teste aprovação
do repositório
Criar ambiente
Obter
de teste Implantar
Executar aprovação
pipeline de - Modelos do ARM e configurar
para implantar
lançamento - Máquinas virtuais aplicação
no próximo
- Outros recursos (DSC)
estágio
de laaS
A configuração do Jenkins pode ser adicionada ao Azure DevOps como ganchos de serviço
e, sempre que qualquer alteração de código for confirmada no repositório do Azure
DevOps, ele poderá acionar pipelines no Jenkins. A Figura 13.20 mostra a configuração
do Jenkins da seção de configuração de gancho de serviço do Azure DevOps:
O Jenkins já deve ter sido implantado antes de usá-lo em qualquer cenário. O processo
de implantação no Linux pode ser encontrado em https://docs.microsoft.com/azure/
virtual-machines/linux/tutorial-jenkins-github-docker-cicd.
Automação do Azure
A Automação do Azure é a plataforma da Microsoft para todas as implementações de
automação referentes a implantações na nuvem, na infraestrutura local e híbridas.
A Automação do Azure é uma plataforma de automação madura que fornece recursos
avançados para:
• Definição de ativos, como variáveis, conexões, credenciais, certificados e módulos
• Implementação de runbooks usando Python, scripts do PowerShell e fluxos
de trabalho do PowerShell
• Fornecimento de IUs para criar runbooks
• Gerenciamento do ciclo de vida completo do runbook, incluindo criação, testes
e publicação
• Agendamento de runbooks
• A capacidade de executar runbooks em qualquer lugar, na nuvem ou na
infraestrutura local
• DSC como uma plataforma de gerenciamento de configuração
• Gerenciamento e configuração de ambientes: Windows e Linux, aplicações
e implantação
• A capacidade de estender a Automação do Azure importando módulos personalizados
O DSC fornece uma linguagem declarativa, na qual você define a intenção e a configuração,
mas não como executar e aplicar essas configurações. Essas configurações são baseadas na
linguagem do PowerShell e facilitam o processo de gerenciamento de configuração.
Nesta seção, analisaremos uma implementação simples de uso do DSC da Automação
do Azure para configurar uma máquina virtual com o objetivo de instalar e configurar
o servidor Web (IIS) e criar um arquivo index.htm que informe aos usuários que o site
está em manutenção.
Em seguida, você aprenderá a provisionar uma conta da Automação do Azure.
WindowsFeature AspNet45
{
Ensure = "Present"
Name = "Web-Asp-Net45"
DependsOn = "[WindowsFeature]AspDotNet"
}
File IndexFile
{
DestinationPath = "C:\inetpub\wwwroot\index.htm"
Ensure = "Present"
Type = "File"
Force = $true
Contents = "<HTML><HEAD><Title> Website under construction.</
Title></HEAD><BODY> '
<h1>If you are seeing this page, it means the website is under
maintenance and DSC Rocks !!!!!</h1></BODY></HTML>"
}
}
}
Depois de criar uma configuração do DSC de exemplo, ela deve ser importada na
Automação do Azure, conforme mostrado na próxima seção.
Agora, você realizou a configuração de nós do DSC. Na próxima seção, você aprenderá
a atribuir configurações aos nós.
Agora, podemos testar se a configuração foi aplicada aos servidores navegando no site
recém-implantado usando um navegador. Depois que os testes forem concluídos com
êxito, vamos avançar para validar as conexões.
Ferramentas para DevOps | 471
Validação
Se apropriado, os grupos de segurança de rede e firewalls são abertos e habilitados
para a porta 80, e um IP público é atribuído à máquina virtual. O site padrão pode ser
navegado usando o endereço IP. Caso contrário, faça logon na máquina virtual que é
usada para aplicar a configuração do DSC e navegue até http://localhost.
Isso deve mostrar a seguinte página:
A Figura 13.24 mostra os utilitários e as ferramentas da Microsoft que podem ser usados
para diferentes fases do gerenciamento do ciclo de vida da aplicação e do DevOps em
geral. Novamente, essa é apenas uma pequena representação de todos os utilitários
e ferramentas. Há muito mais opções disponíveis, como a seguir:
• Orquestração de build do Azure DevOps para construção de um pipeline de build
• Microsoft Test Manager e Pester para testes
• Modelos DSC, PowerShell e ARM para implantação ou gerenciamento de
configuração
• Log Analytics, Application Insights e System Center Operations Manager (SCOM)
para alertas e monitoramento
• Azure DevOps e System Center Service Manager para gerenciamento de
processos:
Resumo | 473
Resumo
O DevOps está ganhando muita tração e impulso na indústria. A maioria das
organizações percebeu seus benefícios e está procurando implementá-lo. Isso está
acontecendo enquanto a maioria delas está migrando para a nuvem. O Azure, como uma
plataforma de nuvem, fornece serviços de DevOps sofisticados e maduros, facilitando
a implementação de DevOps para essas organizações.
Neste capítulo, discutimos o DevOps e suas práticas fundamentais, como
gerenciamento de configuração, integração contínua, entrega contínua e implantação.
Também abordamos diferentes soluções de nuvem baseadas em PaaS, uma IaaS de
máquina virtual e uma IaaS de contêiner, juntamente com seus respectivos recursos do
Azure, os pipelines de build e lançamento.
O gerenciamento de configuração também foi explicado neste capítulo, juntamente
com os serviços do DSC da Automação do Azure e o uso de servidores de pull para
configurar máquinas virtuais automaticamente. Por fim, abordamos a abertura
e a flexibilidade do Azure em relação à opção de linguagens, ferramentas e sistemas
operacionais.
No próximo capítulo, vamos ver os detalhes do Kubernetes e seus componentes e
interações, além de considerações de design e implantação de aplicações no Kubernetes.
Arquitetar soluções de
14
Kubernetes do Azure
Os contêineres são um dos componentes de infraestrutura mais comentados da última
década. Os contêineres não são uma nova tecnologia. Eles existem há muito tempo.
Eles têm sido prevalentes no mundo Linux há mais de duas décadas. Os contêineres não
eram bem conhecidos na comunidade de desenvolvedores devido à sua complexidade
e ao fato de que não havia muita documentação sobre eles. No entanto, em torno do
início desta década, em 2013, foi criada uma empresa conhecida como Docker que
mudou a percepção e a adoção de contêineres no mundo de desenvolvedores.
O Docker escreveu um wrapper de API robusto sobre os contêineres do Linux (LXC)
existentes e facilitou a criação, o gerenciamento e o destruição de contêineres na
interface de linha de comando por parte dos desenvolvedores. Ao organizar aplicações
em contêineres, o número de contêineres pode aumentar drasticamente com o tempo,
e podemos chegar a um ponto em que precisamos gerenciar centenas ou até mesmo
milhares de contêineres. É aqui que os orquestradores de contêiner desempenham
uma função importante, e o Kubernetes é um deles. Usando o Kubernetes, podemos
automatizar a implantação, a escalabilidade, a rede e o gerenciamento de contêineres.
476 | Arquitetar soluções de Kubernetes do Azure
Agora que você sabe para que o Kubernetes é usado, vamos começar do zero e discutir
o que são contêineres, como eles são orquestrados usando o Kubernetes e muito mais.
Todos esses benefícios fornecem grandes benefícios para as organizações que adotam
a tecnologia de contêineres, e o Docker é um dos precursores a esse respeito. Há
outras opções de tempo de execução do contêiner disponíveis, como CoreOS Rkt
(pronunciado como "Rocket", fora de produção), Mesos Containerizer e contêineres
LXC. As organizações podem adotar a tecnologia com a qual se sintam à vontade.
Os contêineres não estavam disponíveis anteriormente no mundo Windows, sendo
disponibilizados somente para Windows 10 e Windows Server 2016. No entanto,
os contêineres agora são cidadãos de primeira classe no mundo Windows.
Como mencionado na introdução, os contêineres devem ser monitorados, regidos
e gerenciados apropriadamente, assim como qualquer outro componente de
infraestrutura em um ecossistema. É necessário implantar um orquestrador, como
o Kubernetes, que pode ajudar você a fazer isso facilmente. Na próxima seção,
você conhecerá os fundamentos do Kubernetes, incluindo quais são suas vantagens.
Fundamentos do Kubernetes
Muitas organizações ainda perguntam: "Precisamos do Kubernetes ou, na verdade,
de qualquer orquestrador de contêineres?" Quando consideramos o gerenciamento
de contêineres em grande escala, precisamos considerar vários pontos, como
escalabilidade, balanceamento de carga, gerenciamento de ciclo de vida, entrega
contínua, registro em log, monitoramento e muito mais.
Você pode perguntar: "Os contêineres não devem fazer tudo isso?" A resposta é que os
contêineres são apenas uma peça de baixo nível do quebra-cabeças. Os benefícios reais
são obtidos por meio das ferramentas que agem sobre os contêineres. No final do dia,
precisamos de algo para ajudar com a orquestração.
Kubernetes é uma palavra grega, κυβερνήτης, que significa "timoneiro" ou "capitão do
navio". Mantendo o tema marítimo dos contêineres do Docker, o Kubernetes é o capitão
do navio. O Kubernetes muitas vezes é chamado de K8s, onde 8 representa as oito letras
entre "K" e "s" na palavra "Kubernetes".
Como mencionado anteriormente, os contêineres são mais ágeis do que as máquinas
virtuais. Eles podem ser criados em segundos e destruídos também rapidamente. Eles
têm um ciclo de vida semelhante às máquinas virtuais. No entanto, eles precisam ser
monitorados, regidos e gerenciados ativamente em um ambiente.
478 | Arquitetar soluções de Kubernetes do Azure
Alguns dos principais benefícios do uso do AKS em clusters não gerenciados são:
• Se você estiver usando clusters não gerenciados, precisará trabalhar para tornar
a solução altamente disponível e escalável. Além disso, você precisa ter um
gerenciamento de atualização adequado para instalar atualizações e patches.
Por outro lado, no AKS, o Azure gerencia isso completamente, permitindo que
os desenvolvedores economizem tempo e sejam mais produtivos.
• Integração nativa com outros serviços, como o Registro de Contêiner do Azure
para armazenar suas imagens de contêiner com segurança, o Azure DevOps para
integrar pipelines de CI/CD, o Azure Monitor para registro em log e o Azure
Active Directory para segurança.
• Escalabilidade e velocidade de inicialização mais rápida.
• Suporte para conjuntos de escala de máquinas virtuais.
Arquitetura do Kubernetes
A primeira etapa para entender o Kubernetes é entender sua arquitetura. Vamos
abordar os detalhes de cada componente na próxima seção, mas obter uma visão geral
de alto nível da arquitetura ajudará você a entender a interação entre os componentes.
480 | Arquitetar soluções de Kubernetes do Azure
Clusters do Kubernetes
O Kubernetes precisa de nós físicos ou virtuais para instalar dois tipos de componentes:
• Componentes do plano de controle do Kubernetes ou componentes mestre
• Nós de trabalho do Kubernetes (minions) ou componentes não mestre
A Figura 14.1 é um diagrama que oferece uma visão geral de alto nível da arquitetura
do Kubernetes. Vamos abordar os componentes em mais detalhes mais adiante:
Componentes do Kubernetes
Os componentes do Kubernetes são divididos em duas categorias: componentes mestre
e componentes de nó. Os componentes mestre também são conhecidos como o plano de
controle do cluster. O plano de controle é responsável por gerenciar os nós de trabalho
e os pods no cluster. A autoridade de tomada de decisão de um cluster é o plano de
controle e também é responsável pela detecção e pelas respostas relacionadas a eventos
de cluster. A Figura 14.2 descreve a arquitetura completa de um cluster do Kubernetes:
Agora, vamos explorar os componentes de nós que são implantados em cada um dos
nós de trabalho no cluster:
• Kubelet: enquanto o servidor de API, o agendador, os controladores e o etcd
são implantados em nós mestre, os kubelets são implantados em nós minion.
Eles atuam como agentes dos componentes mestre do Kubernetes e são
responsáveis por gerenciar pods localmente nos nós. Há um kubelet em cada
nó. Um kubelet recebe comandos dos componentes mestre e também fornece
informações de integridade, monitoramento e atualização sobre nós e pods para
os componentes mestre, como o servidor de API e o gerenciador do controlador.
Eles são o canal de comunicação administrativa entre os nós mestre e minion.
• kube-proxy: o kube-proxy, assim como o kubelets, é implantado em nós minion.
Ele é responsável pelo monitoramento de pods e serviços, bem como pela
atualização das regras de firewall netfilter e iptables locais com qualquer alteração
na disponibilidade de pods e serviços. Isso garante que as informações de
roteamento nos nós sejam atualizadas à medida e quando novos pods e serviços
são criados ou que pods e serviços existentes sejam excluídos.
484 | Arquitetar soluções de Kubernetes do Azure
Primitivos do Kubernetes
Você aprendeu que o Kubernetes é um sistema de orquestração usado para implantar
e gerenciar contêineres. O Kubernetes define um conjunto de blocos de construção,
que também são conhecidos como primitivos. Esses primitivos em conjunto podem nos
ajudar a implantar, manter e escalar aplicações em contêineres. Vamos ver cada um dos
primitivos e entender suas funções.
Primitivos do Kubernetes | 485
Pod
Pods são a unidade mais básica da implantação no Kubernetes. A pergunta imediata
que surge em uma mente curiosa é: como um pod difere-se de um contêiner? Os pods
são wrappers sobre contêineres. Em outras palavras, os contêineres estão contidos
em pods. Pode haver vários contêineres dentro de um pod. No entanto, a prática
recomendada é ter um relacionamento individual de um único contêiner. Isso não
significa que não podemos ter mais de um contêiner em um pod. Também é possível ter
vários contêineres em um pod, contanto que haja um contêiner principal e os restantes
sejam contêineres auxiliares. Também há padrões, como padrões de sidecar, que podem
ser implementados com pods de vários contêineres.
Cada pod tem seu próprio endereço IP e pilha de rede. Todos os contêineres
compartilham a pilha e a interface de rede. Todos os contêineres dentro de
um pod podem ser acessados localmente usando o nome de host.
Uma definição simples de pod no formato YAML é mostrada nas linhas de código a seguir:
---
apiVersion: v1
kind: Pod
metadata:
name: tappdeployment
labels:
appname: tapp
ostype: linux
spec:
containers:
- name: mynewcontainer
image: "tacracr.azurecr.io/tapp:latest"
ports:
- containerPort: 80
protocol: TCP
name: http
A definição de pod mostrada tem um nome e define alguns rótulos, que podem ser usados
pelo recurso de serviço para expor a outros pods, nós e recursos personalizados externos.
Ele também define um único contêiner com base em uma imagem personalizada
armazenada no Registro de Contêiner do Azure e abre a porta 80 para o contêiner.
486 | Arquitetar soluções de Kubernetes do Azure
Serviços
O Kubernetes permite a criação de pods com várias instâncias. Esses pods devem ser
acessíveis em qualquer Pod ou nó dentro de um cluster. É possível usar o endereço
IP de um pod diretamente e acessar o pod. No entanto, isso está longe de ser ideal.
Os pods são efêmeros e poderão obter um novo endereço IP se o pod anterior ficar
inativo. Nesses casos, a aplicação falhará facilmente. O Kubernetes fornece serviços,
que dissociam instâncias de pod de seus clientes. Os pods podem ser criados e
removidos, mas o endereço IP de um Serviço de Kubernetes permanece constante
e estável. Os clientes podem se conectar ao endereço IP do serviço, que tem um ponto
de extremidade para cada pod para o qual pode enviar solicitações. Se houver várias
instâncias de pod, cada um de seus endereços IP estará disponível para o serviço
como um objeto de ponto de extremidade. Quando um pod fica inativo, os pontos de
extremidade são atualizados para refletir as instâncias atuais do pod, juntamente com
seus endereços IP.
Os serviços são altamente dissociados de pods. O principal objetivo dos serviços
é enfileirar para pods que têm rótulos em suas definições do seletor de serviço.
Um serviço define seletores de rótulos e, com base neles, os endereços IP de pod são
adicionados ao recurso de serviço. Pods e serviços podem ser gerenciados de forma
independente uns dos outros.
Um serviço fornece vários tipos de esquemas de endereço IP. Existem quatro tipos
de serviços: ClusterIP, NodePort, LoadBalancer e controlador de entrada usando
o Gateway de Aplicativo.
O esquema mais fundamental é conhecido como ClusterIP, e é um endereço IP interno
que pode ser acessado somente no cluster. O esquema ClusterIP é mostrado na
Figura 14.4:
Implantações
As implantações do Kubernetes são recursos de nível mais alto em comparação
a ReplicaSets e pods. As implantações fornecem funcionalidades relacionadas à
atualização e ao lançamento de uma aplicação. Os recursos de implantação criam
um ReplicaSet, e o ReplicaSet gerencia o pod. É importante entender a necessidade
de recursos de implantação quando ReplicaSets já existem.
As implantações desempenham uma função significativa na atualização de aplicações.
Se uma aplicação já está em produção e uma nova versão da aplicação precisa ser
implantada, há algumas opções para você:
1. Excluir pods existentes e criar novos pods: neste método, há tempo de inatividade
para a aplicação, portanto, só deverá ser usado se o tempo de inatividade for
aceitável. Haverá um risco de maior tempo de inatividade se a implantação conter
bugs, e você precisará reverter para uma versão anterior.
Primitivos do Kubernetes | 489
Todas essas abordagens teriam que ser executadas manualmente sem um recurso de
implantação. Um recurso de implantação automatiza todo o processo de lançamento
e atualização. Ele também poderá ajudar a reverter automaticamente para uma versão
anterior se houver problemas com a implantação atual.
Uma definição de implantação é mostrada na listagem de código a seguir:
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: tappdeployment
labels:
appname: tapp
ostype: linux
spec:
replicas: 3
selector:
matchLabels:
appname: myappnew
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
template:
490 | Arquitetar soluções de Kubernetes do Azure
metadata:
name: mypod
labels:
appname: myappnew
spec:
containers:
- name: mynewcontainer
image: "tacracr.azurecr.io/tapp:latest"
ports:
- containerPort: 80
protocol: TCP
name: http
É importante observar que uma implantação tem uma propriedade strategy, que
determina se a estratégia recreate ou RollingUpdate é usada. A estratégia recreate
excluirá todos os pods existentes e criará outros novos. Ela também contém detalhes
de configuração relacionados a RollingUpdate, fornecendo o número máximo de pods
que podem ser criados e destruídos em uma única execução.
name: tappdeployment
labels:
appname: tapp
ostype: linux
spec:
replicas: 3
selector:
matchLabels:
appname: myappnew
template:
metadata:
name: mypod
labels:
appname: myappnew
spec:
containers:
- name: mynewcontainer
image: "tacracr.azurecr.io/tapp:latest"
ports:
- containerPort: 80
protocol: TCP
name: http
É importante observar que ReplicaSets têm uma propriedade replicas, que determina
a contagem de instâncias de pod, uma propriedade selector, que define os pods que
devem ser gerenciados por ReplicaSet, e, por fim, a propriedade template, que define
o pod em si.
ConfigMaps e segredos
O Kubernetes fornece dois recursos importantes para armazenar dados de
configuração. ConfigMaps são usados para armazenar dados de configuração geral
que não são sensíveis à segurança. Os dados de configuração genéricos da aplicação,
como nomes de pastas, nomes de volume e nomes DNS, podem ser armazenados em
ConfigMaps. Por outro lado, dados confidenciais, como credenciais, certificados e
segredos, devem ser armazenados nos recursos de segredos. Esses dados de segredos
são criptografados e armazenados no armazenamento de dados etcd do Kubernetes.
492 | Arquitetar soluções de Kubernetes do Azure
Arquitetura do AKS
Na seção anterior, abordamos a arquitetura de um cluster não gerenciado.
Agora, exploraremos a arquitetura do AKS. Ao ler esta seção, você poderá indicar as
principais diferenças entre a arquitetura de clusters não gerenciados e gerenciados
(o AKS, neste caso).
Quando uma instância do AKS é criada, somente os nós de trabalhador são criados.
Os componentes mestre são gerenciados pelo Azure. Os componentes mestre são
o servidor de API, o agendador, etcd e o gerenciador do controlador, que abordamos
anteriormente. Os kubelets e o kube-proxy são implantados nos nós de trabalhador.
A comunicação entre os nós e os componentes mestre ocorre usando kubelets, que
atuam como agentes dos clusters do Kubernetes para o nó:
Se o comando for bem-sucedido, você poderá ver uma saída semelhante a esta:
Ao passar pelo cluster, você verá um item de linha que diz "nodeResourceGroup": "MC_
AzureForArchitects_AzureForArchitects-AKS_southeastasia". Ao criar um cluster do
AKS, um segundo recurso é criado automaticamente para armazenar os recursos do nó.
Implantar um cluster do AKS | 495
Kubectl
O kubectl é o principal componente por meio do qual desenvolvedores e consultores
de infraestrutura podem interagir com o AKS. O kubectl ajuda na criação de uma
solicitação REST contendo o cabeçalho e o corpo HTTP e no envio dela para o servidor
de API. O cabeçalho contém os detalhes de autenticação, como uma combinação de
token ou nome de usuário/senha. O corpo contém a carga real no formato JSON.
O comando kubectl fornece detalhes de log avançados quando usado juntamente com
a alternância detalhada. A alternância usa uma entrada inteira que pode variar de 0 a 9,
que pode ser visualizada nos logs de detalhes.
Conectar ao cluster
Para se conectar ao cluster localmente, precisamos instalar o kubectl. O Azure
Cloud Shell já tem o kubectl instalado. Se você quiser se conectar localmente, use
az aks install-cli para instalar o kubectl.
Para configurar o kubectl a fim de se conectar ao nosso cluster do Kubernetes, precisamos
fazer o download das credenciais e configurar a CLI com elas. Isso pode ser feito usando
o comando az aks get-credentials. Use o comando, conforme mostrado aqui:
az aks get-credentials \
--resource-group AzureForArchitects \
--name AzureForArchitects-AKS
Agora, precisamos verificar se estamos conectados ao cluster. Como mencionado
anteriormente, usaremos o kubectl para nos comunicarmos com o cluster, e kubectl
get nodes mostrará uma lista de nós no cluster. Durante a criação, definimos a
contagem de nós como 2, de modo que a saída tenha dois nós. Além disso, precisamos
garantir que o status do nó esteja Pronto. A saída deve ser semelhante à Figura 14.11:
Como nosso nó está no estado Pronto, vamos avançar e criar um pod. Há duas formas
de criar recursos no Kubernetes. Elas são:
• Imperativo: neste método, usamos os comandos kubectl run e kubectl expose
para criar os recursos.
• Declarativo: descrevemos o estado do recurso por meio de um arquivo JSON
ou YAML. Enquanto abordávamos os primitivos do Kubernetes, você viu muitos
arquivos YAML para cada um dos blocos de construção. Vamos passar o arquivo
para o comando kubectl apply a fim de criar os recursos, e os recursos declarados
no arquivo serão criados.
Vamos adotar a abordagem imperativa primeiro, para criar um pod com o nome
webserver, a operação de um contêiner NGINX com a porta 80 exposta:
kubectl run webserver --restart=Never --image nginx --port 80
containers:
- name: wenserver-2-container
image: nginx
ports:
- containerPort: 80
protocol: TCP
name: http
Já que criamos os pods, podemos usar o comando kubectl get pods para listar todos
os pods. O Kubernetes usa o conceito de namespaces para o isolamento lógico dos
recursos. Por padrão, todos os comandos estão apontando para o namespace padrão.
Se você quiser executar uma ação em um namespace específico, poderá passar o nome
do namespace por meio do parâmetro -n. Na Figura 14.14, você pode ver que kubectl
get pods retorna os pods que criamos no exemplo anterior, que residem no namespace
padrão. Além disso, quando usamos --all-namespaces, a saída retorna pods em todos os
namespaces:
Agora, vamos criar uma implantação simples que executa o NGINX e com um balanceador
de carga que o expõe à Internet. O arquivo YAML será semelhante ao seguinte:
#Creating a deployment that runs six replicas of nginx
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-server
spec:
replicas: 6
selector:
matchLabels:
app: nginx-server
template:
metadata:
labels:
app: nginx-server
spec:
containers:
- name: nginx-server
image: nginx
ports:
- containerPort: 80
name: http
---
#Creating Service
apiVersion: v1
kind: Service
metadata:
name: nginx-service
Implantar um cluster do AKS | 499
spec:
ports:
- port: 80
selector:
app: nginx-server
---
apiVersion: v1
kind: Service
metadata:
name: nginx-lb
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: nginx-server
Usaremos o comando kubectl apply e passaremos o arquivo YAML para o parâmetro -f.
Após o êxito, todos os três serviços serão criados, e se você executar o comando
kubectl get deployment nginx-server, verá seis réplicas em execução, conforme
mostrado na Figura 14.15, para tornar o serviço altamente disponível:
Agora que temos o IP público, podemos ir para o navegador e ver a página de destino
do NGINX, conforme mostrado na Figura 14.17:
Da mesma forma, você pode usar os arquivos YAML que abordamos na seção Primitivos
do Kubernetes para criar diferentes tipos de recursos.
Há muitos comandos, como logs, describe, exec e delete, que os administradores
precisam usar com o comando kubectl. O objetivo desta seção é capacitar você a criar
um cluster do AKS, se conectar ao cluster e implantar uma aplicação Web simples.
Na próxima seção, abordaremos a rede do AKS.
Rede do AKS
A rede forma um componente principal dentro de um cluster do Kubernetes.
Os componentes mestre devem conseguir alcançar os nós minion e os pods em
execução sobre eles, enquanto os nós de trabalhador devem conseguir se comunicar
entre si, bem como com os componentes mestre.
Pode ser uma surpresa que o Kubernetes central não gerencie a pilha de rede.
É o trabalho do tempo de execução do contêiner nos nós.
Rede do AKS | 501
Kubenet
O Kubenet é a estrutura de rede padrão no AKS. No Kubenet, cada nó obtém um
endereço IP da sub-rede da rede virtual à qual eles estão conectados. Os pods não
obtêm endereços IP da sub-rede. Em vez disso, um esquema de endereçamento
separado é usado para fornecer endereços IP aos serviços e pods do Kubernetes.
Ao criar uma instância do AKS, é importante definir o intervalo de endereços IP para
pods e serviços. Como os pods não estão na mesma rede que os nós, as solicitações de
pods e para pods são sempre NATed/roteadas para substituir o IP do pod de origem
pelo endereço IP do nó e vice-versa.
No roteamento definido pelo usuário, o Azure pode oferecer suporte a até 400 rotas,
e você também não pode ter um cluster maior do que 400 nós. A Figura 14.18 mostra
como o nó do AKs recebe um endereço IP da rede virtual, mas não os pods criados no nó:
502 | Arquitetar soluções de Kubernetes do Azure
Por padrão, esse Kubenet é configurado com 110 pods por nó. Isso significa que
pode haver um máximo de 110 * 400 pods em um cluster do Kubernetes por padrão.
O número máximo de pods por nó é 250.
Esse esquema deve ser usado quando a disponibilidade do endereço IP e o roteamento
definido pelo usuário não são uma restrição.
Na CLI do Azure, você pode executar o seguinte comando para criar uma instância do
AKS usando essa pilha de rede:
az aks create \
--resource-group myResourceGroup \
--name myAKSCluster \
--node-count 3 \
--network-plugin kubenet \
--service-cidr 10.0.0.0/16 \
--dns-service-ip 10.0.0.10 \
--pod-cidr 10.244.0.0/16 \
--docker-bridge-address 172.17.0.1/16 \
--vnet-subnet-id $SUBNET_ID \
--service-principal <appId> \
--client-secret <password>
Rede do AKS | 503
Kubelet virtual
O kubelet virtual está em visualização no momento e é gerenciado pela organização
CNCF. É uma abordagem bastante inovadora que o AKS usa para fins de escalabilidade.
O kubelet virtual é implantado no cluster do Kubernetes como um pod. O contêiner
em execução no pod usa o SDK do Kubernetes para criar um novo recurso de nó
e se apresenta para todo o cluster como um nó. Os componentes do cluster, incluindo
o servidor de API, o agendador e os controladores, o consideram e tratam como um
nó e agendam pods nele.
No entanto, quando um pod é agendado nesse nó que está disfarçado como um nó,
ele se comunica com seus componentes de back-end, conhecidos como provedores,
para criar, excluir e atualizar os pods. Um dos principais provedores no Azure são
Instâncias de Contêiner do Azure. O Lote do Azure também pode ser usado como
um provedor. Isso significa que os contêineres são realmente criados em Instâncias
de Contêiner ou no Lote do Azure, em vez do próprio cluster. No entanto, eles são
gerenciados pelo cluster. A arquitetura do kubelet virtual é mostrada na Figura 14.20:
Nós virtuais
Uma das limitações do virtual kubelet é que os pods implantados em provedores do
kubelet virtual são isolados e não se comunicam com outros pods no cluster. Se houver
a necessidade de os pods nesses provedores se comunicarem com outros pods e nós no
cluster e vice-versa, nós virtuais deverão ser criados. Nós virtuais são criados em uma
sub-rede diferente na mesma rede virtual que hospeda nós de cluster do Kubernetes,
o que pode permitir a comunicação entre pods. No momento da redação, somente
o sistema operacional Linux tem suporte para trabalhar com nós virtuais.
Nós virtuais dão a impressão de um nó. No entanto, o nó não existe. Qualquer coisa
agendada nesse nó é criada em Instâncias de Contêiner do Azure. Os nós virtuais são
baseados no kubelet virtual, mas têm a funcionalidade extra de comunicação integrada
entre o cluster e as Instâncias de Contêiner do Azure.
Ao implantar pods em nós virtuais, a definição de pod deve conter um seletor de nó
apropriado para se referir a nós virtuais e também tolerâncias, conforme mostrado
no trecho de código a seguir:
nodeSelector:
kubernetes.io/role: agent
beta.kubernetes.io/os: linux
type: virtual-kubelet
tolerations:
- key: virtual-kubelet.io/provider
operator: Exists
- key: azure.com/aci
effect: NoSchedule
Aqui, o seletor de nó está usando a propriedade type para se referir ao kubelet virtual
e a propriedade tolerations para informar o Kubernetes de que nós com marcas,
virtual-kubelet.io/provider, devem permitir a implantação desses pods neles.
Resumo | 507
Resumo
O kubernetes é o orquestrador de contêineres mais usado e funciona com diferentes
tempos de execução de contêiner e rede. Neste capítulo, você aprendeu sobre
os fundamentos do kubernetes, sua arquitetura e alguns dos componentes de
infraestrutura importantes, como etcd, o servidor de API, gerenciadores do controlador
e o agendador, juntamente com sua finalidade. Além disso, analisamos recursos
importantes que podem ser implantados para gerenciar aplicações, como pods,
controladores de replicação, ReplicaSets, implantações e serviços.
O AKS fornece algumas pilhas de rede diferentes: a CNI do Azure e o Kubenet. Eles
fornecem diferentes estratégias para atribuir endereços IP a pods. Enquanto a CNI do
Azure fornece endereços IP para pods da sub-rede subjacente, o Kubenet usa apenas
endereços IP virtuais.
Também abordamos alguns dos recursos oferecidos exclusivamente pelo Azure, como
nós virtuais, e conceitos em torno do kubelet virtual. No próximo capítulo, aprenderemos
sobre o provisionamento e a configuração de recursos com modelos do ARM.
Implantações entre
15
assinaturas usando
modelos do ARM
Os modelos do Azure Resource Manager (ARM) são o mecanismo preferencial para
provisionar recursos e configurá-los no Azure.
Os modelos do ARM ajudam a implementar um paradigma relativamente novo
conhecido como Infraestrutura como Código (IaC). Os modelos do ARM convertem
a infraestrutura e sua configuração em código, que tem inúmeras vantagens. A IaC traz
um alto nível de consistência e previsibilidade para implantações entre ambientes.
Ela também garante que os ambientes possam ser testados antes de ir para a produção
e, por fim, proporciona um alto nível de confiança no processo de implantação,
manutenção e governança.
510 | Implantações entre assinaturas usando modelos do ARM
Modelos do ARM
Uma vantagem proeminente da IaC é que ela pode ter controle de versão. Ele também
pode ser reutilizado entre ambientes, o que fornece um alto grau de consistência
e previsibilidade nas implantações e garante que o impacto e o resultado da implantação
de um modelo do ARM sejam os mesmos, independentemente do número de vezes que
o modelo é implantado. Esse recurso também é conhecido como idempotência.
Os modelos do ARM foram apresentados com a introdução da especificação do
ARM. Desde então, receberam mais recursos e ganharam maturidade. É importante
compreender que geralmente há uma lacuna que dura de algumas semanas a alguns
meses entre a configuração de recurso real e a disponibilidade da configuração em
modelos do ARM.
Cada recurso tem sua própria configuração. Essa configuração pode ser afetada de
diversas maneiras, inclusive usando o Azure PowerShell, a CLI do Azure, os SDKs
do Azure, as APIs REST e os modelos do ARM.
Cada uma dessas técnicas tem seu próprio ciclo de vida de desenvolvimento
e lançamento, que é diferente do desenvolvimento real de recursos. Vamos tentar
entender isso com a ajuda de um exemplo.
O recurso do Azure Databricks tem seu próprio ciclo de vida de cadência
e desenvolvimento. Os consumidores desse recurso têm seu próprio ciclo de vida de
desenvolvimento, que é diferente do desenvolvimento real dos recursos. Se o Databricks
receber sua primeira versão em 31 de dezembro, os cmdlets do Azure PowerShell para
ele podem não estar disponíveis na mesma data e podem até ser lançados em 31 de
janeiro do próximo ano. De maneira semelhante, a disponibilidade desses recursos
nos modelos do ARM e da API REST pode ocorrer em torno de 15 de janeiro.
Modelos do ARM | 511
Cada recurso no modelo do ARM tem a propriedade apiVersion. Essa propriedade ajuda
a decidir qual versão da API REST deve ser usada para provisionar e implantar o recurso.
A Figura 15.1 mostra o fluxo de solicitações do modelo do ARM para APIs de recursos
que são responsáveis pela criação, atualização e exclusão de recursos:
Se o módulo mais recente do Azure não estiver instalado, faça isso usando o seguinte
comando:
install-module -Name az -Force
É hora de criar um modelo do ARM que criará vários grupos de recursos na mesma
assinatura. O código do modelo do ARM é o seguinte:
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/
deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"resourceGroupInfo": {
"type": "array" },
"multiLocation": {
"type": "array"
}
},
"resources": [
{
"type": "Microsoft.Resources/resourceGroups",
"location": "[parameters('multiLocation')[copyIndex()]]",
"name": "[parameters('resourceGroupInfo')[copyIndex()]]",
"apiVersion": "2019-10-01",
"copy": {
"name": "allResourceGroups",
"count": "[length(parameters('resourceGroupInfo'))]"
},
"properties": {}
}
],
"outputs": {}
}
A segunda seção principal é a matriz JSON resources, que pode conter vários recursos.
Neste exemplo, estamos criando grupos de recursos. Portanto, isso é declarado na
seção resources. Os grupos de recursos estão sendo provisionados em um loop devido
ao uso do elemento copy. O elemento copy garante que o recurso seja executado em
um número especificado de vezes e cria um novo recurso em todas as iterações. Se
enviarmos dois valores para o parâmetro de matriz resourceGroupInfo, o comprimento
da matriz será "dois", e o elemento copy garantirá que o recurso resourceGroup seja
executado duas vezes.
Todos os nomes de recursos em um modelo devem ser exclusivos para um tipo de
recurso. A função copyIndex é usada para atribuir o número de iteração atual ao nome
geral do recurso e torná-lo único. Além disso, queremos que os grupos de recursos
sejam criados em regiões diferentes usando nomes de regiões distintos enviados
como parâmetros. A atribuição de um nome e local para cada grupo de recursos
é feita usando a função copyIndex.
O código do arquivo parameters é mostrado a seguir. Esse código é bastante simples
e fornece valores de matriz para os dois parâmetros esperados pelo modelo anterior.
Os valores nesse arquivo devem ser alterados para todos os parâmetros de acordo
com o seu ambiente:
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/
deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"resourceGroupInfo": {
"value": [ "firstResourceGroup", "SeocndResourceGroup" ]
},
"multiLocation": {
"value": [
"West Europe",
"East US"
]
}
}
}
As credenciais válidas podem ser uma conta de usuário ou uma entidade de serviço.
Em seguida, use um cmdlet New-AzDeployment recém-lançado para implantar o modelo.
O script de implantação está disponível no arquivo multipleResourceGroups.ps1:
New-AzDeployment -Location "West Europe" -TemplateFile "c:\users\rites\
source\repos\CrossSubscription\CrossSubscription\multipleResourceGroups.
json" -TemplateParameterFile "c:\users\rites\source\repos\CrossSubscription\
CrossSubscription\multipleResourceGroups.parameters.json" -Verbose
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/
deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"storagePrefix1": {
"type": "string",
"defaultValue": "st01"
...
"type": "string",
"defaultValue": "rg01"
},
"remoteSub": {
"type": "string",
"defaultValue": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}
...
}
}
],
"outputs": {}
}
}
}
],
"outputs": {}
}
Depois que o comando for executado, os recursos definidos no modelo do ARM devem
ser refletidos no portal do Azure.
Você deve ter em mente que o valor ResourceID deve ser observado a partir do resultado
do cmdlet New-AzKeyVault. Esse valor precisará ser substituído no arquivo parameters.
Consulte a Figura 15.4 para obter detalhes:
Usaremos a mesma instância do Key Vault que foi criada na seção anterior.
Só precisamos garantir que haja dois segredos disponíveis na instância do Key Vault.
O primeiro segredo é StorageName, e o outro é StorageKey. Os comandos para criar
esses segredos na instância do Key Vault são:
Set-AzKeyVaultSecret -VaultName "testkeyvaultbook" -Name "storageName"
-SecretValue $(ConvertTo-SecureString -String "uniquename" -AsPlainText
-Force ) -Verbose
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/
deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"hostingPlanNames": {
"value": [ "firstappservice", "secondappservice" ]
...
"storageKey": {
"reference": {
"keyVault": { "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourceGroups/keyvaluedemo/providers/Microsoft.KeyVault/
vaults/forsqlvault1" },
"secretName": "storageKey"
}
}
}
}
}
]
}
},
"[resourceId('Microsoft.Network/publicIPAddresses/',
variables('publicIPAddressName'))]",
"[resourceId('Microsoft.Network/virtualNetworks/',
variables('virtualNetworkName'))]"
],
"properties": {
"ipConfigurations": [
{
"name": "ipconfig1",
"properties": {
"privateIPAllocationMethod": "Dynamic",
"publicIPAddress": {
"id": "[resourceId('Microsoft.Network/
publicIPAddresses',variables('publicIPAddressName'))]"
},
"subnet": {
"id": "[variables('subnetRef')]"
}
}
}
]
}
},
"publisher": "[variables('imagePublisher')]",
"offer": "[variables('imageOffer')]",
"sku": "[parameters('windowsOSVersion')]",
"version": "latest"
},
"osDisk": { "createOption": "FromImage" },
"copy": [
{
"name": "dataDisks",
"count": 3,
"input": {
"lun": "[copyIndex('dataDisks')]",
"createOption": "Empty",
"diskSizeGB": "1023",
"name": "[concat(variables('vmName'), '-datadisk', copyIndex('dataDisks'))]"
}
}
]
},
"networkProfile": {
"networkInterfaces": [
{
"id": "[resourceId('Microsoft.Network/networkInterfaces',
variables('nicName'))]"
}
]
}
}
}
532 | Implantações entre assinaturas usando modelos do ARM
A próxima seção mostrará um exemplo de como usar modelos do ARM para provisionar
uma solução de Plataforma como Serviço.
{
"apiVersion": "2019-08-01",
"name": "[variables('hostingPlanName')]",
"type": "Microsoft.Web/serverfarms",
"location": "[parameters('location')]",
"tags": {
"displayName": "HostingPlan"
},
"sku": {
"name": "[parameters('skuName')]",
"capacity": "[parameters('skuCapacity')]"
},
"properties": {
"name": "[variables('hostingPlanName')]"
}
},
O próximo recurso que deve ser provisionado após um plano é o serviço de aplicativo
em si. É importante que uma dependência entre esses recursos seja criada de forma
que um plano já seja criado antes que o serviço de aplicativo em si seja criado:
{
"apiVersion": "2019-08-01",
"name": "[variables('webSiteName')]",
"type": "Microsoft.Web/sites",
"location": "[parameters('location')]",
"dependsOn": [
"[variables('hostingPlanName')]"
],
"properties": {
"name": "[variables('webSiteName')]",
"serverFarmId": "[resourceId('Microsoft.Web/serverfarms',
variables('hostingPlanName'))]"
},
"resources": [
534 | Implantações entre assinaturas usando modelos do ARM
{
"apiVersion": "2019-08-01",
"type": "config",
"name": "connectionstrings",
"dependsOn": [
"[variables('webSiteName')]"
],
"properties": {
"DefaultConnection": {
"value": "[concat( 'sql connection string here')]",
"type": "SQLAzure"
}
}
}
]
}
No código anterior, um recurso do tipo Microsoft.Web/sites é definido e tem uma
dependência do plano. Ele também está usando o plano do Serviço de Aplicativo e é
associado a ele usando o serverFarmId. Ele ainda declara uma cadeia de conexão que
pode ser usada para se conectar ao SQL Server.
Esta seção mostrou um exemplo de como criar uma solução PaaS no Azure usando um
modelo do ARM. Da mesma forma, outras soluções PaaS, incluindo aplicativos do Azure
Functions, Serviço de Kubernetes e Service Fabric, entre muitas outras, podem ser
criadas usando modelos do ARM.
Cada data factory tem vários serviços vinculados. Esses serviços vinculados atuam
como conectores para obter dados no data factory, ou o data factory pode enviar
dados para eles. A seguinte listagem de código cria um serviço vinculado para a conta
de armazenamento do Azure na qual os blobs serão lidos para o data factory e outro
serviço vinculado para o Banco de Dados SQL do Azure:
{
"type": "linkedservices",
"name": "[variables('storageLinkedServiceName')]",
"apiVersion": "2018-06-01",
"dependsOn": [
"[variables('dataFactoryName')]"
],
"properties": {
"type": "AzureStorage",
"description": "Azure Storage Linked Service",
"typeProperties": {
"connectionString":
"[concat('DefaultEndpointsProtocol=https;
AccountName=',parameters('storageAccountName'),';
AccountKey=',parameters('storageAccountKey'))]"
}
}
},
{
"type": "linkedservices",
536 | Implantações entre assinaturas usando modelos do ARM
"name": "[variables('sqlLinkedServiceName')]",
"apiVersion": "2018-06-01",
"dependsOn": [
"[variables('dataFactoryName')]"
],
"properties": {
"type": "AzureSqlDatabase",
"description": "Azure SQL linked service",
"typeProperties": {
"connectionString": "[concat('Data Source=tcp:', parameters('sqlServerName'),
'.database.windows.net,1433;Initial Catalog=', parameters('sqlDatabaseName'),
';Integrated Security=False;User ID=', parameters('sqlUserId'), ';Password=',
parameters('sqlPassword'), ';Connect Timeout=30;Encrypt=True')]"
}
}
},
Após os serviços vinculados, é hora de definir os conjuntos de dados para o Azure Data
Factory. Os conjuntos de dados ajudam a identificar os dados que devem ser lidos
e colocados no data factory. Eles também podem representar os dados temporários
que precisam ser armazenados pelo data factory durante a transformação ou até
mesmo o local de destino onde os dados serão gravados. O próximo bloco de código
cria três conjuntos de dados, um para cada um dos aspectos dos conjuntos de dados
que acabaram de ser mencionados.
O conjunto de dados de leitura é mostrado no seguinte bloco de código:
{
"type": "datasets",
"name": "[variables('storageDataset')]",
"dependsOn": [
"[variables('dataFactoryName')]",
"[variables('storageLinkedServiceName')]"
],
"apiVersion": "2018-06-01",
"properties": {
"type": "AzureBlob",
"linkedServiceName": "[variables('storageLinkedServiceName')]",
Soluções relacionadas a dados usando modelos do ARM | 537
"typeProperties": {
"folderPath": "[concat(parameters('sourceBlobContainer'), '/')]",
"fileName": "[parameters('sourceBlobName')]",
"format": {
"type": "TextFormat"
}
},
"availability": {
"frequency": "Hour",
"interval": 1
},
"external": true
}
},
O conjunto de dados intermediário é mostrado nas seguintes linhas de código:
{
"type": "datasets",
"name": "[variables('intermediateDataset')]",
"dependsOn": [
"[variables('dataFactoryName')]",
"[variables('sqlLinkedServiceName')]"
],
"apiVersion": "2018-06-01",
"properties": {
"type": "AzureSqlTable",
"linkedServiceName": "[variables('sqlLinkedServiceName')]",
"typeProperties": {
"tableName": "[variables('intermediateDataset')]"
},
"availability": {
"frequency": "Hour",
"interval": 1
538 | Implantações entre assinaturas usando modelos do ARM
}
}
},
Por fim, o conjunto de dados usado para o destino é mostrado aqui:
{
"type": "datasets",
"name": "[variables('sqlDataset')]",
"dependsOn": [
"[variables('dataFactoryName')]",
"[variables('sqlLinkedServiceName')]"
],
"apiVersion": "2018-06-01",
"properties": {
"type": "AzureSqlTable",
"linkedServiceName": "[variables('sqlLinkedServiceName')]",
"typeProperties": {
"tableName": "[parameters('sqlTargetTable')]"
},
"availability": {
"frequency": "Hour",
"interval": 1
}
}
},
Por fim, precisamos de um pipeline no data factory que possa reunir todos os conjuntos
de dados e serviços vinculados e ajudar na criação de soluções de dados de extração,
transação e carregamento. Um pipeline consiste em várias atividades, cada uma cumprindo
uma tarefa específica. Todas essas atividades podem ser definidas no modelo do ARM,
como você verá agora. A primeira atividade copia os blobs na conta de armazenamento
para um SQL Server intermediário, conforme mostrado no código a seguir:
{
"type": "dataPipelines",
"name": "[variables('pipelineName')]",
"dependsOn": [
Soluções relacionadas a dados usando modelos do ARM | 539
"[variables('dataFactoryName')]",
"[variables('storageLinkedServiceName')]",
"[variables('sqlLinkedServiceName')]",
"[variables('storageDataset')]",
"[variables('sqlDataset')]"
],
"apiVersion": "2018-06-01",
"properties": {
"description": "Copies data from Azure Blob to Sql DB while invoking stored
procedure",
"activities": [
{
"name": "BlobtoSqlTableCopyActivity",
"type": "Copy",
"typeProperties": {
"source": {
"type": "BlobSource"
},
"sink": {
"type": "SqlSink",
"writeBatchSize": 0,
"writeBatchTimeout": "00:00:00"
}
},
"inputs": [
{
"name": "[variables('storageDataset')]"
}
],
"outputs": [
{
"name": "[variables('intermediateDataset')]"
540 | Implantações entre assinaturas usando modelos do ARM
}
]
},
{
"name": "SqlTabletoSqlDbSprocActivity",
"type": "SqlServerStoredProcedure",
"inputs": [
{
"name": "[variables('intermediateDataset')]"
}
],
"outputs": [
{
"name": "[variables('sqlDataset')]"
}
],
"typeProperties": {
"storedProcedureName": "[parameters('sqlWriterStoredProcedureName')]"
},
"scheduler": {
"frequency": "Hour",
"interval": 1
},
"policy": {
"timeout": "02:00:00",
"concurrency": 1,
"executionPriorityOrder": "NewestFirst",
"retry": 3
}
}
],
Criar uma solução IaaS no Azure com o Active Directory e o DNS | 541
"start": "2020-10-01T00:00:00Z",
"end": "2020-10-02T00:00:00Z"
}
}
]
}
Por fim, para converter uma máquina virtual no Active Directory, um script do
PowerShell ou um script de Desired State Configuration (DSC) deve ser executado
na máquina virtual. Mesmo para associar outras máquinas virtuais ao domínio,
outro conjunto de scripts deve ser executado nessas máquinas virtuais.
544 | Implantações entre assinaturas usando modelos do ARM
Resumo
A opção de implantar recursos usando uma única implantação para várias assinaturas,
grupos de recursos e regiões proporciona melhor capacidade de implantar, reduzir
bugs na implantação e acessar benefícios avançados, como criar sites de Disaster
Recovery e alcançar alta disponibilidade.
Neste capítulo, você viu como criar alguns tipos diferentes de solução usando modelos
do ARM. Isso incluiu a criação de uma solução baseada em infraestrutura que inclui
máquinas virtuais; uma solução baseada em plataformas usando o Serviço de Aplicativo
do Azure; uma solução relacionada a dados usando o recurso Data Factory (incluindo
sua configuração); e um datacenter no Azure com máquinas virtuais, o Active Directory
e o DNS instalados sobre a máquina virtual.
No próximo capítulo, vamos nos concentrar na criação de modelos do ARM modulares,
uma habilidade essencial para os arquitetos que realmente querem levar seus modelos
do ARM para o próximo nível. O capítulo também mostrará várias maneiras de
desenvolver modelos do ARM e criar modelos do ARM reutilizáveis e modulares.
Design modular
16
e implementação
de modelos do ARM
Sabemos que há várias maneiras de criar um modelo do Azure Resource Manager
(ARM). É muito fácil criar um que provisione todos os recursos necessários no Azure
usando o Visual Studio e o Visual Studio Code. Um único modelo do ARM pode consistir
em todos os recursos necessários para uma solução no Azure. Esse modelo pode ter
apenas alguns recursos ou ser maior e conter muitos recursos.
Enquanto a criação de um único modelo que consiste em todos os recursos é muito
tentadora, é aconselhável planejar com antecedência uma implementação do modelo
do ARM dividida em vários modelos do ARM menores para que problemas futuros
relacionados a eles possam ser evitados.
Neste capítulo, veremos como escrever modelos do ARM de maneira modular para
que eles evoluam ao longo de um período com o mínimo de envolvimento em termos
de alterações e esforço em testes e implantação.
Abuso de dependência
As dependências entre recursos também tendem a se tornar mais complexas em
modelos maiores. É muito fácil abusar do uso do recurso dependsOn em modelos do ARM
devido à maneira como eles funcionam. Cada recurso em um modelo pode se referir
a todos os seus recursos anteriores, em vez de criar uma árvore de dependências.
Os modelos do ARM não reclamarão se um único recurso depender de todos os outros
no modelo do ARM, mesmo que esses outros recursos possam ter interdependências.
Isso torna a mudança de modelos do ARM propensa a bugs e, às vezes, nem sequer
é possível alterá-los.
Agilidade reduzida
Geralmente, há várias equipes em um projeto, cada uma com seus próprios recursos no
Azure. Essas equipes terão dificuldades para trabalhar com um único modelo do ARM
porque um único desenvolvedor deve atualizá-lo. A atualização de um único modelo
com várias equipes pode causar conflitos e mesclagens difíceis de resolver. Com vários
modelos menores, cada equipe pode criar seu próprio modelo do ARM.
Sem reutilização
Não há problema se você tem um único modelo, e o uso dele implica na implantação
de todos os recursos. Não há nenhuma possibilidade de selecionar recursos individuais
sem algumas manobras, como a adição de recursos condicionais. Um único modelo
grande perde a reutilização, pois ou você implanta todos os recursos ou não
implanta nenhum deles.
Sabendo que modelos grandes únicos têm tantos problemas, é recomendável criar
modelos modulares para ter benefícios como os seguintes:
• Várias equipes podem trabalhar em seus próprios modelos isoladamente.
• Os modelos podem ser reutilizados em projetos e soluções.
• É fácil depurar e solucionar problemas dos modelos.
Agora que abordamos alguns dos problemas com modelos grandes e únicos, na próxima
seção, consideraremos o ponto crucial dos modelos modulares e como eles podem
ajudar os desenvolvedores a implementar implantações eficientes.
550 | Design modular e implementação de modelos do ARM
Modelos modulares
Quando um único modelo grande é decomposto em vários modelos em que cada
modelo menor cuida de seus próprios recursos, e esses recursos são exclusivamente
mantidos e são de propriedade e responsabilidade do modelo que os contém, podemos
dizer que temos modelos modulares. Cada modelo dentro desses modelos segue
o princípio da responsabilidade única.
Antes de aprender a dividir um modelo grande em vários modelos reutilizáveis menores,
é importante entender a tecnologia por trás da criação de modelos menores e como
criá-los para implantar soluções completas.
Entender o princípio da responsabilidade única | 551
Recursos de implantação
O ARM facilita a vinculação de modelos. Embora já tenhamos visto os modelos
vinculados em detalhes, vou mencioná-los aqui para ajudar você a entender
como os modelos de vinculação ajudam a alcançar a modularidade, a composição
e a reutilização.
Os modelos do ARM fornecem recursos especializados conhecidos como implantações,
que estão disponíveis no namespace Microsoft.Resources. Um recurso de implantações
em um modelo do ARM tem aparência muito semelhante à do segmento de código
a seguir:
"resources": [
{
"apiVersion": "2019-10-01",
"name": "linkedTemplate",
"type": "Microsoft.Resources/deployments",
"properties": {
"mode": "Incremental",
<nested-template-or-external-template>
}
}
]
Pode haver níveis aninhados de implantações em modelos do ARM. Isso significa que
um único modelo pode chamar outro, e o modelo chamado pode chamar outro, e isso
pode continuar por cinco níveis de chamadas aninhadas.
Agora que entendemos que os modelos grandes podem ser modulares com recursos
separados em modelos diferentes, precisamos vinculá-los e reuni-los para implantar
recursos no Azure. Os modelos vinculados e aninhados são maneiras de compor vários
modelos juntos.
Modelos vinculados
Os modelos vinculados são modelos que invocam modelos externos. Os modelos
externos são armazenados em arquivos de modelo do ARM diferentes. Um exemplo
de modelos vinculados é:
"resources": [
{
"apiVersion": "2019-10-01",
"name": "linkedTemplate",
"type": "Microsoft.Resources/deployments",
"properties": {
"mode": "Incremental",
"templateLink": {
"uri":"https://mystorageaccount.blob.core.windows.net/
AzureTemplates/newStorageAccount.json",
"contentVersion":"1.0.0.0"
},
"parametersLink": {
"uri":"https://mystorageaccount.blob.core.windows.net/
AzureTemplates/newStorageAccount.parameters.json",
"contentVersion":"1.0.0.0"
Modelos vinculados | 553
}
}
}
]
Agora você tem uma boa compreensão dos modelos vinculados. Um tópico intimamente
relacionado é modelos aninhados, que a próxima seção abordará detalhadamente.
554 | Design modular e implementação de modelos do ARM
Modelos aninhados
Os modelos aninhados são um recurso relativamente novo em modelos do ARM em
comparação com modelos vinculados externos.
Agora que entendemos a tecnologia por trás dos modelos do ARM modulares, como
devemos dividir um modelo grande em modelos menores?
Há várias maneiras como um modelo grande pode ser decomposto em modelos
menores. A Microsoft recomenda o seguinte padrão para a decomposição de modelos
do ARM:
Configurações conhecidas
Por outro lado, configurações conhecidas são configurações pré-determinadas
específicas para implantar um ambiente usando modelos do ARM. Essas configurações
pré-determinadas são conhecidas como configurações de dimensionamento
t-shirt. Semelhante ao modo como um t-shirt está disponível em uma configuração
pré-determinada, como pequenas, médias e grandes, os modelos do ARM podem ser
pré-configurados para implantar um ambiente pequeno, médio ou grande, dependendo
dos requisitos. Isso significa que os usuários não podem determinar qualquer tamanho
personalizado aleatório para o ambiente, mas podem escolher entre várias opções
fornecidas, e os modelos do ARM executados durante o tempo de execução garantirão
que uma configuração apropriada do ambiente seja fornecida.
Assim, a primeira etapa da criação de um modelo do ARM modular é decidir quais serão
as configurações conhecidas de um ambiente.
Os modelos do ARM podem ser divididos em modelos modulares com base em:
• Tecnologia
• Funcionalidade
Uma maneira ideal de decidir qual método modular será usado para criar um modelo
do ARM é:
• Defina modelos de nível folha ou recursos que consistem em recursos únicos.
No diagrama a seguir, os modelos de extrema direita são modelos de nível folha.
No diagrama, as máquinas virtuais, a rede virtual, o armazenamento e outros na
mesma coluna representam modelos de nível folha.
• Componha modelos específicos do ambiente usando os modelos de nível folha.
Esses modelos específicos do ambiente fornecem um ambiente do Azure, como
um ambiente do SQL Server, de Serviço de Aplicativo ou de datacenter. Vamos nos
aprofundar um pouco mais neste tópico. Vamos ver o exemplo de um ambiente
de SQL do Azure. Para criar um ambiente de SQL do Azure, são necessários vários
recursos. No mínimo, um SQL Server lógico, um banco de dados SQL e alguns
recursos de firewall do SQL devem ser provisionados. Todos esses recursos
são definidos em modelos individuais ao nível folha. Esses recursos podem ser
compostos em conjunto em um único modelo que tem a capacidade de criar um
ambiente SQL do Azure. Qualquer pessoa que queira criar um ambiente SQL pode
usar esse modelo composto. A Figura 16.3 tem Datacenter, Mensagens e Serviço
de Aplicativo como modelos específicos do ambiente.
• Crie modelos com maior abstração compondo vários modelos específicos do
ambiente em soluções. Esses modelos são compostos por modelos específicos
do ambiente que foram criados na etapa anterior. Por exemplo, para criar uma
solução de inventário de comércio eletrônico que precise de um ambiente de
Serviço de Aplicativo e um ambiente SQL, dois modelos de ambiente, Serviço de
Aplicativo e SQL Server podem ser compostos em conjunto. A Figura 16.3 tem os
modelos Funcional 1 e Funcional 2, que são compostos por modelos filhos.
• Por fim, um modelo mestre deve ser criado e deve ser composto por vários
modelos em que cada um deles pode implantar uma solução.
558 | Design modular e implementação de modelos do ARM
As etapas anteriores para criar um modelo projetado modular podem ser facilmente
entendidas por meio da Figura 16.3:
Agora, vamos criar uma solução usando modelos do ARM com uma abordagem modular.
Como mencionado anteriormente, a primeira etapa é criar modelos de recursos
individuais. Tais modelos serão usados para compor modelos adicionais capazes de
criar um ambiente. Esses modelos serão necessários para criar uma máquina virtual.
Todos os modelos do ARM mostrados aqui estão disponíveis no código do capítulo
que os acompanha. Os nomes e o código desses modelos são:
• Storage.json
• virtualNetwork.json
• PublicIPAddress.json
• NIC.json
• VirtualMachine.json
• CustomScriptExtension.json
Primeiro, vejamos o código do modelo Storage.json. Esse modelo fornece uma conta
de armazenamento de que todas as máquinas virtuais precisam para armazenar seus
arquivos de sistema operacional e disco de dados:
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-
01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"storageAccountName": {
"type": "string",
"minLength": 1
},
"storageType": {
"type": "string",
"minLength": 1
},
...
"outputs": {
"resourceDetails": {
"type": "object",
"value": "[reference(parameters('storageAccountName'))]"
}
}
}
560 | Design modular e implementação de modelos do ARM
Em seguida, veremos o código da placa da interface de rede. Uma placa de rede virtual
é necessária para que uma máquina virtual se conecte a uma rede virtual, além de
aceitar e enviar solicitações da Internet e para ela. O código a seguir está disponível
no arquivo NIC.json:
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-
01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"nicName": {
"type": "string",
"minLength": 1
},
"publicIpReference": {
"type": "string",
"minLength": 1
...
[resourceId(subscription().subscriptionId,resourceGroup().name, 'Microsoft.
Network/publicIPAddresses', parameters('publicIpReference'))]",
"vnetRef": "[resourceId(subscription().
subscriptionId,resourceGroup().name, 'Microsoft.Network/virtualNetworks',
parameters('virtualNetworkReference'))]",
"subnet1Ref": "[concat(variables('vnetRef'),'/subnets/',
parameters('subnetReference'))]"
},
...
"id": "[variables('subnet1Ref')]"
}
}
}
]
}
}
],
"outputs": {
"resourceDetails": {
"type": "object",
"value": "[reference(parameters('nicName'))]"
}
}
}
Configurações conhecidas | 563
Em seguida, veremos o código para criar uma máquina virtual. Cada máquina virtual
é um recurso no Azure. Além disso, lembre-se de que esse modelo não tem nenhuma
referência ao armazenamento, à rede, aos endereços IP públicos ou a outros recursos
criados anteriormente. Essa referência e composição acontecerá posteriormente
nesta seção usando outro modelo. O código a seguir está disponível no arquivo
VirtualMachine.json:
{
"$schema": "https://schema.management.azure.com/schemas/2015-01
01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"vmName": {
"type": "string",
"minLength": 1
...
},
"imageOffer": {
"type": "string",
"minLength": 1
},
"windowsOSVersion": {
"type": "string",
"minLength": 1
},
...
"outputs": {
"resourceDetails": {
"type": "object",
"value": "[reference(parameters('vmName'))]"
}
}
}
564 | Design modular e implementação de modelos do ARM
},
"parameters": {
"storageAccountName": {
"value": "[parameters('storageAccountName')]"
},
"storageType": {
"value": "[parameters('storageType')]"
},
"resourceLocation": {
"value": "[resourceGroup().location]"
...
"outputs": {
"resourceDetails": {
"type": "object",
"value": "[reference('GetVM').outputs.resourceDetails.value]"
}
}
}
O restante dos valores de parâmetro é necessário para configurar cada recurso. O nome
da conta de armazenamento e o valor dnsNameForPublicIP devem ser únicos no Azure:
New-AzResourceGroupDeployment -Name "testdeploy1" -ResourceGroupName
testvmrg -Mode Incremental -TemplateFile "C:\chapter 05\Master.json"
-storageAccountName "st02gvwldcxm5suwe" -storageType "Standard_LRS"
-publicIPAddressName "uniipaddname" -publicIPAddressType "Dynamic"
-dnsNameForPublicIP "azureforarchitectsbook" -virtualNetworkName
vnetwork01 -addressPrefix "10.0.1.0/16" -subnetName "subnet01" -subnetPrefix
"10.0.1.0/24" -nicName nic02 -vmSize "Standard_DS1" -adminUsername "sysadmin"
-adminPassword $(ConvertTo-SecureString -String sysadmin@123 -AsPlainText
-Force) -vhdStorageName oddnewuniqueacc -vhdStorageContainerName vhds
-OSDiskName mynewvm -vmName vm10 -windowsOSVersion 2012-R2-Datacenter
-imagePublisher MicrosoftWindowsServer -imageOffer WindowsServer
-containerName armtemplates -Verbose
O código a seguir mostra uma das maneiras que os valores podem ser extraídos do
Azure Key Vault no tempo de execução usando o arquivo de parâmetros:
{
"$schema": https://schema.management.azure.com/schemas/2016-01-01/
deploymentParameters.json#,
"contentVersion": "1.0.0.0",
"parameters": {
"storageAccountName": {
"reference": {
"keyVault": {
"id": "/subscriptions/--subscription id --/
resourceGroups/rgname/providers/Microsoft.KeyVault/vaults/keyvaultbook"),
"secretName": "StorageAccountName"
}
}
}
}
}
Nesta listagem de código, um parâmetro é definido que faz referência ao Azure Key
Vault para obter valores no tempo de execução durante a implantação. O identificador
do Azure Key Vault e o nome do segrego foram fornecidos como valores de entrada.
570 | Design modular e implementação de modelos do ARM
Agora que você aprendeu a proteger modelos do ARM, vamos ver a identificação das
várias dependências entre eles e como podemos habilitar a comunicação entre vários
modelos.
Resumo
Os modelos do ARM são os meios preferidos de provisionamento de recursos no
Azure. Eles são idempotentes por natureza, trazendo consistência, previsibilidade
e reutilização para a criação do ambiente. Neste capítulo, vimos como criar um modelo
do ARM modular. É importante que as equipes passem um tempo criando modelos do
ARM de modo adequado para que várias equipes possam trabalhar neles juntas. Eles
são altamente reutilizáveis e exigem mudanças mínimas para evoluir. Neste capítulo,
aprendemos a criar modelos que são seguros por design, a provisionar várias instâncias
de recursos em uma única implantação e a passar saídas de um modelo aninhado para
outro usando a seção saídas de modelos do ARM.
O próximo capítulo abordará uma vertente diferente e muito popular da tecnologia
conhecida como função sem servidor no Azure. O Azure Functions é um dos principais
recursos sem servidor do Azure. Ele será abordado de maneira detalhada, incluindo
o Durable Functions.
Projetar soluções IoT
17
No capítulo anterior, você aprendeu sobre modelos do ARM e, até agora, lidamos
com preocupações arquitetônicas e suas soluções no Azure em geral. No entanto,
este capítulo não se baseia na arquitetura generalizada. De fato, ele explora uma das
tecnologias mais revolucionárias deste século. Este capítulo abordará os detalhes da
Internet das Coisas (IoT) e do Azure.
O Azure IoT refere-se a uma coleção de serviços de nuvem gerenciados pela Microsoft
que podem conectar, monitorar e controlar bilhões de ativos de IoT. Em outras
palavras, uma solução IoT compõe um ou mais dispositivos IoT que se comunicam
constantemente com um ou mais servidores de back-end na nuvem.
576 | Projetar soluções IoT
IoT
A Internet foi inventada na década de 1980 e, mais tarde, tornou-se amplamente
disponível. Quase todo mundo avançou em direção a ter uma presença na Internet
e começou a criar suas próprias páginas da Web estáticas. Finalmente, o conteúdo
estático tornou-se dinâmico e pôde ser gerado dinamicamente com base no contexto.
Em quase todos os casos, um navegador era necessário para acessar a Internet. Havia
uma infinidade de navegadores disponíveis e, sem eles, o uso da Internet era um desafio.
Durante a primeira década deste século, houve um acontecimento interessante no
desenvolvimento: o surgimento de dispositivos portáteis, como telefones celulares
e tablets. Os celulares começaram a ficar cada dia mais baratos e disponíveis de forma
onipresente. Os recursos de hardware e software desses dispositivos portáteis estavam
melhorando consideravelmente, tanto que as pessoas começaram a usar navegadores
em seus dispositivos móveis, em vez dos desktops. Mas uma mudança particularmente
distinta foi o surgimento de aplicativos móveis. Esses aplicativos móveis eram obtidos
de alguma loja por download e eram conectados à Internet para se comunicarem com
sistemas de back-end. Até o final da década passada, havia milhões de aplicativos
disponíveis com quase todas as funcionalidades imagináveis dentro deles. O sistema
de back-end para esses aplicativos foi criado na nuvem para que eles pudessem ser
escalados rapidamente. Essa foi a era da conexão entre aplicações e servidores.
Arquitetura de IoT | 577
Mas esse foi o auge da inovação? Qual foi a próxima evolução da Internet? Bem, outro
paradigma agora está tomando o centro do palco: IoT. Em vez de apenas celulares e
tablets conectados à internet, por que não pode haver outros dispositivos conectados
à internet? Anteriormente, esses dispositivos estavam disponíveis apenas em mercados
selecionados; eles eram caros, não estavam disponíveis para as massas e tinham
recursos limitados de hardware e software. No entanto, desde a primeira parte desta
década, a comercialização desses dispositivos tem crescido em grande escala. Esses
dispositivos estão se tornando menores e menores, têm mais capacidade em termos
de hardware e software, têm mais poder de computação e armazenamento, podem se
conectar à internet em vários protocolos e podem ser conectados a quase tudo. Esta
é a era da conexão de dispositivos a servidores, aplicações e outros dispositivos.
Isso levou à formulação da ideia de que os aplicações de IoT podem, de fato, mudar
a forma como as indústrias estão operando. As soluções mais recentes que eram
inéditas começaram a se tornar realidade. Agora, esses dispositivos podem ser
conectados a qualquer coisa; podem obter informações e enviá-las para um sistema
de back-end que pode assimilar informações de todos os dispositivos e executar ações
ou relatar incidentes.
Os sensores e controles de IoT podem ser aproveitados em muitos casos de uso
de negócios. Por exemplo, eles podem ser usados em sistemas de rastreamento de
veículos, que podem rastrear todos os parâmetros essenciais de um veículo e enviá-
los para um armazenamento de dados centralizado para análise. Iniciativas de cidades
inteligentes também podem usar vários sensores para rastrear os níveis de poluição,
temperatura e congestionamento nas ruas. A IoT também encontrou seu caminho
para atividades relacionadas à agricultura, como medir a fertilidade do solo, a umidade
e muito mais. Você pode acessar os casos de sucesso técnicos da Microsoft para IoT, em
https://microsoft.github.io/techcasestudies/#technology=IoT&sortBy=featured, para
obter exemplos reais de como as organizações aproveitam o Azure IoT.
Antes de explorarmos as ferramentas e os serviços relacionados à IoT, abordaremos
primeiro a arquitetura de detalhadamente.
Arquitetura de IoT
Antes de entrar no Azure e em seus recursos e serviços relacionados à IoT, é importante
compreender os vários componentes necessários para criar soluções IoT completas.
Considere dispositivos IoT em todo o mundo estão enviando milhões de mensagens
a cada segundo para um banco de dados centralizado. Por que esses dados estão sendo
coletados? Bem, a resposta é extrair informações valiosas sobre eventos, anomalias
e exceções que estão relacionadas a tudo quando esses dispositivos estão monitorando.
578 | Projetar soluções IoT
A Figura 17.1 mostra uma arquitetura genérica baseada em IoT. Os dados são gerados
ou coletados por dispositivos e enviados por meio do gateway de nuvem. O gateway
de nuvem, por sua vez, envia os dados para vários serviços de back-end para
processamento. Os gateways de nuvem são componentes opcionais. Eles devem ser
usados quando os próprios dispositivos não são capazes de enviar solicitações para
serviços de back-end, seja por causa das limitações de recursos ou pela falta de uma
rede confiável. Esses gateways de nuvem podem agrupar dados de vários dispositivos
e enviá-los para os serviços de back-end. Em seguida, os dados podem ser processados
pelos serviços de back-end e mostrados como insights ou painéis aos usuários:
Arquitetura de IoT | 579
Agora que a arquitetura está clara, vamos avançar e entender como os dispositivos IoT
se comunicam com outros dispositivos.
Conectividade
Os dispositivos de IoT precisam se comunicar para se conectarem a outros dispositivos.
Existem vários tipos de conectividade; por exemplo, a conectividade pode existir entre
dispositivos em uma região, entre dispositivos e um gateway centralizado e entre
dispositivos e uma plataforma IoT.
Em todos esses casos, os dispositivos IoT precisam de capacidade de conectividade.
Essa capacidade poderia ser na forma de conectividade com a Internet, Bluetooth,
infravermelho ou qualquer outra comunicação com dispositivos próximos.
No entanto, alguns dispositivos IoT podem não ter a capacidade de se conectar
à Internet. Nesses casos, eles podem se conectar por um gateway que, por sua vez,
possui conectividade com a Internet.
Os dispositivos IoT usam protocolos para enviar mensagens. Os principais protocolos
são o Advanced Message Queuing Protocol (AMQP) e o Message Queue Telemetry
Transport (MQTT).
580 | Projetar soluções IoT
Os dados de dispositivos devem ser enviados para uma infraestrutura de TI. O protocolo
MQTT é um protocolo de dispositivo para servidor que os dispositivos podem usar
para enviar dados de telemetria e outras informações para servidores. Uma vez que
o servidor recebe uma mensagem por meio do protocolo MQTT, precisa transportar
a mensagem para outros servidores usando uma tecnologia confiável baseada em
mensagens e filas. AMQP é o protocolo preferencial para mover mensagens de forma
confiável e previsível entre os servidores em uma infraestrutura de TI:
Os servidores que recebem as mensagens iniciais de dispositivos IoT devem enviar essas
mensagens para outros servidores para qualquer processamento que seja necessário,
como salvamento em logs, avaliação, análise e apresentação.
Alguns dispositivos não têm a capacidade de se conectar à Internet ou não oferecem
suporte a protocolos que são compatíveis com outras tecnologias de servidor. Para
permitir que esses dispositivos funcionem com uma plataforma IoT e na nuvem,
gateways intermediários podem ser usados. Os gateways ajudam na integração de
dispositivos cuja conectividade e capacidade de rede sejam lentas e não consistentes;
esses dispositivos podem usar protocolos não padronizados ou suas capacidades podem
ser limitadas em termos de recursos e potência.
Nas circunstâncias em que os dispositivos precisam de infraestrutura adicional para
se conectar a serviços back-end, os gateways cliente podem ser implantados. Esses
gateways recebem mensagens de dispositivos próximos e os encaminham (ou enviam
por push) para a infraestrutura de TI e para a plataforma de IoT para mais consumo.
Esses gateways podem traduzir protocolos, se necessário.
Nesta seção, você aprendeu como a comunicação é implementada com outros
dispositivos e sobre a função que os gateways desempenham em termos de
comunicação. Na próxima seção, vamos falar sobre identidade.
Arquitetura de IoT | 581
Identidade
Os dispositivos IoT devem ser registrados em uma plataforma de nuvem. Os dispositivos
que não estão registrados não devem ser autorizados a se conectar a uma plataforma de
nuvem. Os dispositivos devem ser registrados e receber uma identidade. Um dispositivo
deve enviar suas informações de identidade durante a conexão com a nuvem. Se o
dispositivo não conseguir enviar essas informações de identidade, a conectividade
deverá falhar. Você verá mais adiante neste capítulo como gerar uma identidade para
um dispositivo usando uma aplicação de simulação. Como você já sabe, os dispositivos
IoT são implantados para capturar informações e, na próxima seção, vamos falar um
pouco sobre o processo de captura.
Captura
Os dispositivos IoT devem ser capazes de capturar informações. Por exemplo, eles
devem ser capazes de ler ou monitorar o conteúdo sobre a umidade no ar ou no solo.
Essas informações podem ser capturadas com base na frequência, talvez até uma vez
por segundo. Assim que as informações são capturadas, o dispositivo deve ser capaz de
enviá-las para a plataforma IoT para processamento. Se um dispositivo não conseguir
se conectar diretamente à plataforma IoT, poderá se conectar a um gateway de nuvem
intermediário e ter que enviar por push as informações capturadas.
O tamanho dos dados capturados e a frequência de captura são as coisas mais
importantes para o dispositivo. O fato de um dispositivo ter armazenamento local
para conseguir armazenar temporariamente os dados capturados é outro aspecto
importante que deve ser considerado. Por exemplo, um dispositivo poderá funcionar
em modo offline se houver armazenamento local disponível suficiente. Até mesmo
os dispositivos móveis às vezes atuam como dispositivos IoT conectados a diversos
instrumentos e têm a capacidade de armazenar dados. Depois de capturar os dados,
precisamos ingeri-los em uma plataforma IoT para análise adicional e, na próxima
seção, exploraremos a ingestão.
Ingestão
Os dados capturados e gerados por dispositivos devem ser enviados para uma
plataforma IoT capaz de ingerir e consumir esses dados para extrair deles informações
significativas e insights. O serviço de ingestão é essencial porque a disponibilidade e
a escalabilidade do serviço afetam a taxa de transferência dos dados de entrada. Se os
dados começarem a ficar limitados por problemas de escalabilidade ou se a ingestão
não for possível devido a problemas de disponibilidade, os dados serão perdidos e
o conjunto de dados poderá ser tornar tendencioso ou distorcido. Temos os dados
capturados e precisamos de um lugar para armazenar esses dados. Na próxima seção,
você aprenderá sobre o armazenamento.
582 | Projetar soluções IoT
Armazenamento
As soluções IoT geralmente lidam com milhões ou até mesmo bilhões de registros, com
terabytes ou petabytes de dados. Esses são dados valiosos que podem fornecer insights
sobre as operações e sua integridade. Esses dados precisam ser armazenados de tal forma
que possam ser analisados. O armazenamento deve estar prontamente disponível para
análise, aplicações e serviços para consumi-lo. As soluções de armazenamento devem
fornecer taxa de transferência e latência adequadas de uma perspectiva de performance,
bem como ser altamente disponíveis, escaláveis e seguras. A próxima seção aborda
a transformação de dados, que é necessária para armazenar e analisar dados.
Transformação
Em geral, as soluções IoT são orientadas a dados e têm um volume de dados
consideravelmente alto para lidar. Imagine que cada carro tenha um dispositivo
e envie mensagens a cada cinco segundos. Se existirem um milhão de carros enviando
mensagens, isso será igual a 288 milhões de mensagens por dia e 8 bilhões de
mensagens por mês. Juntos, esses dados têm muitas informações e insights ocultos; no
entanto, extrair informações desse tipo de dados por mera análise é bastante difícil.
Os dados capturados e armazenados por dispositivos IoT podem ser consumidos para
resolver problemas de negócios, mas nem todos os dados capturados são importantes.
Apenas um subconjunto de dados pode ser necessário para resolver um problema.
Além disso, os dados que os dispositivos IoT coletam podem não ser consistentes.
Para garantir que os dados sejam consistentes e não tendenciosos ou distorcidos, as
transformações adequadas devem ser executadas neles para torná-los prontos para
análise. Durante essa transformação, os dados são filtrados, classificados, removidos,
enriquecidos e transformados em uma estrutura, de forma que os dados possam ser
consumidos por componentes e aplicações downstream. Precisamos realizar algumas
análises com os dados transformados antes de apresentá-los. Como a próxima etapa
do fluxo de trabalho, vamos abordar a análise.
Análise
Os dados transformados na etapa anterior tornam-se a entrada para a etapa de análise.
Dependendo do problema em questão, existem diferentes tipos de análise que podem
ser executados nos dados transformados.
A seguir estão os diferentes tipos de análise que podem ser executados:
• Análise descritiva: esse tipo de análise ajuda na procura de padrões e detalhes
sobre o status dos dispositivos IoT e de sua integridade geral. Essa etapa identifica
e resume os dados para consumo adicional por meio de etapas de análise mais
avançadas. Ela ajudará no resumo, na descoberta de estatísticas relacionadas
à probabilidade, na identificação do desvio e em outras tarefas estatísticas.
Arquitetura de IoT | 583
Na fase final, a saída da análise é apresentada de maneira legível por humanos para que
um público mais amplo possa compreender e interpretá-la. Na próxima parte, vamos
abordar a apresentação.
Apresentação
A análise ajuda na identificação de respostas, padrões e insights com base nos dados.
Esses insights também precisam estar disponíveis para todos os stakeholders em
formatos que eles consigam compreender. Para essa finalidade, painéis e relatórios
podem ser gerados, de forma estatística ou dinâmica, e então podem ser apresentados
aos stakeholders. Os stakeholders podem consumir esses relatórios para executar
outras ações e melhorar suas soluções continuamente.
Recapitulando rapidamente todas as etapas anteriores, começamos esta seção analisando
a conectividade, em que apresentamos gateways para enviar os dados de dispositivos que
não são compatíveis com os protocolos padrão. Em seguida, falamos sobre a identidade
e como os dados são capturados. Em seguida, os dados capturados são ingeridos
e armazenados para transformação adicional. Após a transformação, a análise é feita nos
dados para que sejam apresentados a todos os stakeholders. Como estamos trabalhando
no Azure, na próxima seção, abordaremos o que é o Azure IoT e consideraremos os
conceitos básicos que aprendemos até agora do ponto de vista do Azure.
584 | Projetar soluções IoT
Azure IoT
Agora, você aprendeu sobre os vários estágios de soluções IoT completas. Cada um desses
estágios é fundamental, e sua implementação é imprescindível para o sucesso de qualquer
solução. O Azure fornece muitos serviços para cada um desses estágios. Além desses
serviços, o Azure fornece o Hub IoT do Azure, que é o principal serviço e plataforma IoT do
Azure. Ele é capaz de hospedar soluções IoT complexas, altamente disponíveis e escaláveis.
Nos aprofundaremos no Hub IoT depois de passarmos por alguns outros serviços:
Conectividade
O Hub IoT fornece todos os conjuntos de protocolos importantes para dispositivos se
conectarem a hubs de IoT.
Ele oferece:
• HTTPS: o método Transport Protocol Secure HyperText usa certificados que
consistem em um par de chaves, conhecidas como chaves privadas/públicas, que
são usadas para criptografar e descriptografar dados entre um dispositivo e o Hub
IoT. Ele fornece comunicação unidirecional de um dispositivo para a nuvem.
• AMQP: é um padrão da indústria para enviar e receber mensagens entre
aplicações. Ele fornece uma infraestrutura avançada para a segurança e a
confiabilidade das mensagens, e essa é uma das razões pelas quais é amplamente
usado no espaço de IoT. Ele fornece recursos do dispositivo para o Hub, bem como
do Hub para o dispositivo, e os dispositivos podem usá-lo para autenticar usando
o Claims-Based Security (CBS) ou Simple Authentication and Security Layer
(SASL). Ele é usado principalmente em cenários em que existem gateways de
campo, e uma única identidade relacionada a vários dispositivos pode transmitir
dados de telemetria para a nuvem.
Azure IoT | 585
Identidade
O Hub IoT também fornece serviços para autenticar dispositivos. Ele oferece uma
interface para a geração de hashes de identidade exclusiva para cada dispositivo.
Quando os dispositivos enviarem mensagens contendo um hash, o Hub IoT poderá
autenticá-las após a verificação do seu próprio banco de dados em busca da existência
desse hash. Agora, vamos ver como os dados são capturados.
Captura
O Azure fornece gateways IoT, que habilitam dispositivos que não estão em
conformidade com o Hub IoT para se adaptar e enviar dados por push. Gateways locais
ou intermediários podem ser implantados perto de dispositivos de forma que vários
dispositivos possam se conectar a um único gateway para conectar e enviar as suas
informações. Da mesma forma, vários desses clusters de dispositivos com gateways
locais também podem ser implantados. Pode haver um gateway de nuvem implantado
na própria nuvem, o qual é capaz de capturar e aceitar dados de várias fontes e ingeri-
los para o Hub IoT. Como abordado anteriormente, precisamos ingerir os dados que
capturamos. Na próxima seção, você aprenderá sobre a ingestão com o Hub IoT.
Ingestão
Um Hub IoT pode ser um único ponto de contato para dispositivos e outras aplicações.
Em outras palavras, a ingestão de mensagens IoT é de responsabilidade do serviço do
Hub IoT. Existem outros serviços, tais como Hubs de Eventos e a infraestrutura de
serviço de mensagens do Barramento de Serviço, que podem ingerir as mensagens
recebidas. No entanto, os benefícios e as vantagens de usar o Hub IoT para ingerir
dados da IoT superam muito o uso de Hubs de Eventos e serviço de mensagens de
Barramento de Serviço. Na verdade, o Hub IoT foi criado especificamente com a
finalidade de ingerir mensagens IoT dentro do ecossistema do Azure, de forma que
os outros serviços e componentes possam agir sobre eles. Os dados ingeridos são
armazenados no armazenamento. Antes de fazermos qualquer tipo de transformação
ou análise, vamos explorar a função de armazenamento no fluxo de trabalho na
próxima seção.
586 | Projetar soluções IoT
Armazenamento
O Azure fornece várias maneiras de armazenar mensagens de dispositivos IoT. Elas
incluem o armazenamento de dados relacionais, dados NoSQL sem esquemas e blobs:
Transformação e análise
O Azure fornece vários recursos para executar tarefas e atividades em dados ingeridos.
Alguns deles são listados aqui:
• Data Factory: o Azure Data Factory é um serviço de integração de dados
baseados em nuvem que nos permite criar fluxos de trabalho orientados por
dados na nuvem para orquestração e automatização da movimentação de dados
e transformação de dados. O Azure Data Factory ajuda a criar e a agendar fluxos
de trabalho orientados a dados (chamados pipelines) que podem ingerir dados de
armazenamentos de dados diferentes; processar e transformar os dados usando
serviços de computação, como Azure HDInsight, Hadoop, Spark, Azure Data Lake
Analytics, Azure Synapse Analytics e Azure Machine Learning; publicar dados de
saída para um data warehouse para aplicações de Business Intelligence (BI) em
vez de uma plataforma tradicional de Extrair, Transformar e Carregar (ETL).
• Azure Databricks: fornece um ambiente Spark completo e gerenciado. Ele pode
ajudar na transformação de dados usando Scala e Python. Ele também fornece
uma biblioteca de SQL para manipular dados usando a sintaxe SQL tradicional.
É mais eficiente do que os ambientes Hadoop.
Azure IoT | 587
Apresentação
Após a execução de análises adequadas nos dados, os dados deverão ser apresentados
aos stakeholders em um formato consumível por eles. Existem inúmeras maneiras
de apresentar insights de dados. Elas incluem a apresentação de dados por meio de
aplicações Web implantadas usando o Serviço de Aplicativo do Azure, enviando dados
para hubs de notificação que podem notificar aplicações móveis e muito mais.
No entanto, a abordagem ideal para apresentar e consumir insights é por meio de
relatórios e painéis do Power BI. O Power BI é uma ferramenta de visualização da
Microsoft que é usada para renderizar relatórios dinâmicos e painéis na Internet.
588 | Projetar soluções IoT
Para concluir, o IoT do Azure está estreitamente alinhado com os conceitos básicos de
arquitetura de IoT. Ele segue o mesmo processo. No entanto, o Azure nos dá a liberdade
de escolher diferentes serviços e dependências com base em nossos requisitos.
Na próxima seção, vamos nos concentrar no Hub IoT do Azure, um serviço hospedado
na nuvem e totalmente gerenciado pelo Azure.
Abordamos uma visão geral do Hub IoT do Azure. Agora, vamos no aprofundar para
entender mais sobre os protocolos e como os dispositivos são registrados no Hub IoT
do Azure.
Hub IoT do Azure | 589
Protocolos
O Hub IoT do Azure dá suporte nativo à comunicação sobre os protocolos HTTP, MQTT
e AMQP. Em alguns casos, dispositivos ou gateways de campo podem não ser capazes
de usar um desses protocolos padrão e exigirão adaptação do protocolo. Nesses casos,
gateways personalizados podem ser implantados. O gateway de protocolo do IoT do
Azure pode habilitar adaptação do protocolo para pontos de extremidade do Hub IoT
ao criar uma ponte para o tráfego de e para o Hub IoT. Na próxima seção, abordaremos
como os dispositivos são registrados no Hub IoT do Azure.
Registro do dispositivo
Os dispositivos devem ser registrados antes que eles possam enviar mensagens para
o Hub IoT. O registro de dispositivos pode ser feito manualmente usando o portal do
Azure ou pode ser automatizado usando o SDK do Hub IoT. O Azure também fornece
exemplos de aplicações de simulação, por meio dos quais fica mais fácil registrar
dispositivos virtuais para fins de desenvolvimento e de testes. Há também um simulador
online do Raspberry Pi que pode ser usado como um dispositivo virtual, e depois,
obviamente, haverá outros dispositivos físicos que poderão ser configurados para
se conectarem ao Hub IoT.
Se você desejar simular um dispositivo de um computador local que geralmente é usado
para fins de testes e de desenvolvimento, há tutoriais disponíveis na documentação do
Azure em vários idiomas. Esses tutoriais estão disponíveis em https://docs.microsoft.
com/azure/iot-hub/iot-hub-get-started-simulated.
O simulador online do Raspberry Pi está disponível em https://docs.microsoft.com/
azure/iot-hub/iot-hub-raspberry-pi-web-simulator-get-started, e para dispositivos
físicos que precisam ser registrados com o Hub IoT, as etapas mencionadas em
https://docs.microsoft.com/azure/iot-hub/iot-hub-get-started-physical devem
ser usadas.
Para adicionar manualmente um dispositivo usando o portal do Azure, o Hub IoT
fornece um menu Dispositivos IoT, que pode ser usado para configurar um novo
dispositivo. Selecionar a opção Novo permitirá criar um novo dispositivo, conforme
mostrado na Figura 17.4:
590 | Projetar soluções IoT
Nesta fase, o dispositivo foi registrado com o Hub IoT, e nossa próxima missão é fazer
com que a comunicação aconteça entre o dispositivo e o Hub IoT. A próxima seção
oferece uma boa compreensão de como o gerenciamento de mensagens é feito.
Gerenciamento de mensagens
Depois que os dispositivos forem registrados no Hub IoT, eles poderão começar a
interagir com ele. O gerenciamento de mensagens refere-se a como a comunicação
ou a interação entre o dispositivo IoT e o Hub IoT é feita. Essa interação pode ser do
dispositivo para a nuvem ou da nuvem para o dispositivo.
Hub IoT do Azure | 591
As mensagens podem ser roteadas para diferentes pontos de extremidade com base em
propriedades de cabeçalho e de corpo da mensagem, conforme mostrado na Figura 17.7:
As mensagens em um hub IoT permanecem lá por sete dias por padrão, e seu tamanho
pode ser até 256 KB.
Segurança
A segurança é um aspecto importante em aplicações baseadas em IoT. Os aplicações
baseadas em IoT são compostas por dispositivos que usam a Internet pública para
conectividade com aplicações de back-end. A proteção de dispositivos, de aplicações
de back-end e de conectividade de usuários mal-intencionados e hackers deve ser
considerada uma prioridade para o sucesso dessas aplicações.
Segurança na IoT
As aplicações IoT são criadas principalmente em torno da Internet, e a segurança deve
desempenhar um papel importante para garantir que a solução não seja comprometida.
Algumas das decisões de segurança mais importantes que afetam a arquitetura de IoT
são listadas aqui:
• Sobre os dispositivos que usam HTTP versus pontos de extremidade REST HTTPS,
os pontos de extremidade REST protegidos por certificados garantem que as
mensagens transferidas de um dispositivo para a nuvem e vice-versa sejam bem
criptografadas e assinadas. As mensagens não devem fazer sentido para um
intruso e devem ser extremamente difíceis de decifrar.
• Se os dispositivos estiverem conectados a um gateway local, o gateway local
deverá se conectar à nuvem usando um protocolo HTTP seguro.
• Os dispositivos devem ser registrados no Hub IoT para que possam enviar mensagens.
• As informações passadas para a nuvem devem ser mantidas no armazenamento,
que está bem protegido e seguro. Os tokens SAS apropriados ou as cadeias de
conexão armazenados no Azure Key Vault devem ser usados para a conexão.
• O Azure Key Vault deve ser usado para armazenar todos os segredos, as senhas
e as credenciais, incluindo os certificados.
• A Central de Segurança do Azure para IoT fornece prevenção e análise de ameaças
para todos os dispositivos, IoT Edge e Hub IoT em todos os ativos de IoT. Podemos
criar nossos próprios painéis na Central de Segurança do Azure com base nas
avaliações de segurança. Alguns dos principais recursos incluem gerenciamento na
Central de Segurança do Azure, proteção contra ameaças adaptativas e detecção
de ameaças inteligentes. É uma prática recomendada considerar a Central de
Segurança do Azure ao implementar soluções IoT seguras.
Em seguida, vamos analisar o aspecto de escalabilidade do Hub IoT.
594 | Projetar soluções IoT
Escalabilidade
A escalabilidade para o Hub IoT é um pouco diferente de outros serviços. No Hub IoT,
existem dois tipos de mensagens:
• Entrada: mensagens do dispositivo para a nuvem
• Saída: mensagens da nuvem para o dispositivo
Um dos serviços em expansão no Hub IoT do Azure agora é o Azure IoT Edge, que é um
serviço totalmente gerenciado criado no Hub IoT do Azure. Vamos explorar o Azure IoT
Edge na próxima seção.
Alta disponibilidade
O Hub IoT é uma oferta de Plataforma como Serviço (PaaS) do Azure. Os clientes e
os usuários não interagem diretamente com o número e o tamanho subjacentes de
máquinas virtuais nas quais o serviço do Hub IoT é executado. Os usuários decidem
a região, a SKU do hub IoT e o número de unidades para sua aplicação. O restante da
configuração é determinado e executado pelo Azure nos bastidores. O Azure garante
que cada serviço PaaS seja altamente disponível por padrão. Ele faz isso ao garantir que
várias máquinas virtuais provisionadas por trás do serviço estejam em racks separados
no datacenter. Ele faz isso colocando as máquinas virtuais em um conjunto de
disponibilidade e em domínios de falha e de atualização separados. Isso ajuda a garantir
a alta disponibilidade para a manutenção planejada e não planejada. Os conjuntos de
disponibilidade cuidam da alta disponibilidade no nível do datacenter.
Na próxima seção, abordaremos o Azure IoT Central.
Azure IoT Central | 597
Resumo
A IoT é uma das maiores tecnologias emergentes desta década e já está transformando
as indústrias. Coisas que pareciam impossíveis antes agora são repentinamente
possíveis.
Neste capítulo, exploramos o Hub IoT e abordamos a entrega de soluções IoT para
o cliente de maneira mais rápida, melhor e mais barata do que as soluções alternativas.
Também abordamos como a IoT pode rastrear o ciclo de vida de desenvolvimento
inteiro e ajudar a agilizar o tempo de lançamento no mercado para as empresas.
Por fim, você aprendeu sobre o Azure IoT Edge e o Azure IoT Central.
Para ajudá-lo a analisar os crescentes volumes de dados com eficácia, abordaremos
o Azure Synapse Analytics no próximo capítulo.
Azure Synapse
18
Analytics para
arquitetos
O Azure Synapse Analytics é uma evolução inovadora do SQL Data Warehouse do Azure.
O Azure Synapse é um serviço integrado de análise de dados totalmente gerenciado que
combina data warehouse, integração de dados e processamento de big data com tempo
acelerado para insights para formar um único serviço.
602 | Azure Synapse Analytics para arquitetos
Até agora, cada uma dessas etapas exigia uma ferramenta diferente. Evidentemente,
com tantos serviços, aplicações e ferramentas diferentes disponíveis no mercado,
escolher os mais adequados pode ser uma tarefa assustadora.
Há inúmeros serviços disponíveis para ingerir, carregar, preparar e fornecer dados.
Também há inúmeros serviços para limpeza de dados com base na linguagem escolhida
pelo desenvolvedor. Além disso, alguns desenvolvedores podem preferir usar o SQL,
alguns podem querer usar o Spark, enquanto outros podem querer usar ambientes sem
código para transformar os dados.
Mesmo depois que a coleção aparentemente adequada de ferramentas for selecionada,
muitas vezes há uma curva de aprendizado íngreme para essas ferramentas. Além disso,
os arquitetos podem encontrar desafios logísticos inesperados na manutenção de um
pipeline de dados em plataformas e linguagens diferentes devido a incompatibilidades.
Com essa gama de problemas, implementar e manter soluções analíticas baseadas em
nuvem pode ser uma tarefa difícil.
O Azure Synapse Analytics resolve esses problemas e muito mais. Ele simplifica todo
o padrão de data warehouse moderno, permitindo que os arquitetos se concentrem
em criar soluções de análise completas em um ambiente unificado.
Marketing 40%
40%
In-memory local + SSD Cache
Data
warehouse
Você pode criar grupos de workloads em um cluster definindo alguns limites simples.
Eles são ajustados automaticamente dependendo do workload e do cluster, mas sempre
garantem uma experiência de qualidade para os usuários que executam os workloads.
Consulte https://techcommunity.microsoft.com/t5/data-architecture-blog/
configuring-workload-isolation-in-azure-synapse-analytics/ba-p/1201739 para ler
mais sobre como configurar o isolamento de workloads no Azure Synapse Analytics.
Para aproveitar ao máximo os benefícios do Azure Synapse, primeiro vamos ver os
espaços de trabalho do Synapse e o Synapse Studio.
O Azure Synapse fornece uma interface de usuário Web unificada para preparação,
gerenciamento e armazenamento de dados, além de análise de big data, BI e tarefas de
IA conhecidas como Synapse Studio. Juntamente com espaços de trabalho do Synapse,
o Synapse Studio é um ambiente ideal para engenheiros de dados e cientistas de dados
compartilharem e colaborarem com as soluções de análise, conforme mostrado na
Figura 18.2:
Recursos:
• Um data warehouse rápido, altamente elástico e seguro com performance
e segurança líderes da indústria
• A capacidade de explorar o Azure Data Lake Storage e data warehouses usando
a sintaxe T-SQL familiar em consultas SQL e SQL sob demanda (sem servidor)
• Apache Spark integrado ao Azure Machine Learning
• Integração de dados híbridos para acelerar a ingestão de dados e operacionalização
do processo de análise (ingerir, preparar, transformar e fornecer)
• Geração de relatório de negócios e veiculação com integração do Power BI
Principais recursos:
• Criar e operacionalizar pipelines para ingestão e orquestração de dados.
• Explorar diretamente os dados em seu Azure Data Lake Storage ou data
warehouse, bem como quaisquer conexões externas ao espaço de trabalho,
usando o Synapse Studio.
• Escrever código usando blocos de anotações e editores de consultas T-SQL.
• Ferramenta de transformação de dados sem código, se preferir não escrever seu
próprio código.
• Monitorar, proteger e gerenciar seus espaços de trabalho sem sair do ambiente.
• Experiência de desenvolvimento baseada na Web para as soluções de análise inteiras.
• O recurso de backup e restauração no pool de SQL do Azure Synapse permite que
pontos de restauração sejam criados para facilitar a recuperação ou a cópia de um
data warehouse para um estado anterior.
• A capacidade de executar consultas simultâneas de T-SQL em pools de SQL em
petabytes de dados para fornecer ferramentas e aplicações de BI.
• O SQL sob demanda fornece consultas SQL sem servidor para facilitar
a exploração e a análise de dados no Azure Data Lake Storage sem nenhuma
configuração ou manutenção de infraestrutura.
• Atende a toda a gama de necessidades de análise, desde engenharia de dados até
ciência de dados, usando uma variedade de linguagens, como Python, Scala, C#
e Spark SQL.
• Pools Spark, que aliviam a configuração e manutenção complexas de clusters
e simplificam o desenvolvimento de aplicações Spark e o uso de blocos de
anotações do Spark.
Uma visão geral do Azure Synapse Analytics | 607
Plataforma
• Oferece suporte a computação provisionada e sem servidor. Exemplos de
computação provisionada incluem computação SQL e computação Spark.
• A computação provisionada permite que as equipes segmentem os recursos de
computação para que possam controlar o custo e o uso para se alinhar melhor
com a estrutura organizacional.
• Por outro lado, a computação sem servidor permite que as equipes usem
o serviço sob demanda sem provisionamento ou gerenciamento de infraestrutura
subjacente.
• Integração profunda entre os mecanismos Spark e SQL.
Synapse SQL
O Synapse SQL permite o uso do T-SQL para consultar e analisar dados. Há dois
modelos para escolher:
1. Modelo totalmente provisionado
2. Modelo SQL sob demanda sem servidores
Tempo de execução Tempo de execução Tempo de execução Tempo de execução Tempo de execução
Sistema operacional Sistema operacional Sistema operacional Sistema operacional Sistema operacional
Você gerencia
Tabela 18.1: comparação entre diferentes infraestruturas
Principais recursos:
• Os analistas podem se concentrar em analisar os dados sem se preocupar em
gerenciar nenhuma infraestrutura.
• Os clientes podem se beneficiar de um modelo de preços simples e flexível,
pois eles só pagam pelo que usam.
Uma visão geral do Azure Synapse Analytics | 609
Pipelines do Synapse
Os pipelines do Synapse permitem que os desenvolvedores criem fluxos de trabalho
completos para cenários de movimentação e processamento de dados. O Azure Synapse
Analytics usa a tecnologia do Azure Data Factory (ADF) para fornecer recursos de
integração de dados. Os principais recursos do ADF que são essenciais para o pipeline
de data warehouse moderno estão disponíveis no Azure Synapse Analytics. Todos esses
recursos são embrulhados com um modelo de segurança comum, Controle de acesso
baseado em função (RBAC), no espaço de trabalho do Azure Synapse Analytics.
A Figura 18.3 a seguir mostra um exemplo de um pipeline de dados e das atividades do
ADF que estão diretamente integrados dentro do ambiente do Azure Synapse Analytics:
Principais recursos:
• Serviços integrados de plataforma para gerenciamento, segurança, monitoramento
e gerenciamento de metadados.
• Integração nativa entre Spark e SQL. Use uma única linha de código para ler
e escrever com Spark de/no SQL analytics.
• A capacidade de criar uma tabela do Spark e consultá-la instantaneamente com
o SQL Analytics sem definir um esquema.
• Ambiente “livre de chaves”. Com o logon único e a passagem do Azure Active
Directory, nenhuma chave ou login é necessário para interagir com o Azure Data
Lake Storage (ADLS)/bancos de dados.
Por que você deve migrar seu data warehouse herdado para o Azure Synapse
Analytics?
Ao migrar para o Azure Synapse Analytics, as empresas com sistemas herdados de data
warehouse podem aproveitar as inovações mais recentes em tecnologias de nuvem
e delegar tarefas, como manutenção de infraestrutura e atualização de plataforma
para o Azure.
Os clientes que migraram para o Azure Synapse já estão colhendo muitos benefícios,
incluindo o seguinte.
612 | Azure Synapse Analytics para arquitetos
Performance
O Azure Synapse Analytics oferece a melhor performance de banco de dados relacional
usando técnicas como processamento massivo paralelo (MPP) e o armazenamento
em cache automático in-memory. Para obter mais informações, consulte a arquitetura
do Azure Synapse Analytics (https://docs.microsoft.com/azure/synapse-analytics/
sql-data-warehouse/massively-parallel-processing-mpp-architecture).
Velocidade
O data warehouse usa muitos processos. Envolve a ingestão de dados, a transformação
de dados, a limpeza de dados, a agregação de dados, a integração de dados e a produção
de relatórios e visualização de dados. Os muitos processos envolvidos na movimentação
de dados de fontes originais para um data warehouse são complexos e interdependentes.
Um único gargalo pode retardar todo o pipeline e um pico inesperado no volume
de dados amplia a necessidade de velocidade. Quando a pontualidade dos dados é
importante, o Azure Synapse Analytics atende à demanda por processamento rápido.
Maior segurança e conformidade
O Azure é uma plataforma de nuvem disponível no mundo todo, altamente escalável
e segura. Ele oferece muitos recursos de segurança, incluindo Azure Active Directory,
RBAC, identidades gerenciadas e pontos de extremidade privados gerenciados.
O Azure Synapse Analytics, que reside dentro do ecossistema do Azure, herda todos
os benefícios mencionados anteriormente.
Escalabilidade
O volume de dados em um data warehouse normalmente aumenta com o passar do
tempo e conforme o histórico é coletado. O Azure Synapse Analytics pode ser escalado
para corresponder a esse crescimento adicionando incrementalmente recursos
à medida que os dados e workloads aumentam.
Migrar de sistemas herdados existentes para o Azure Synapse Analytics | 613
Redução de custos
A operação de um datacenter herdado na infraestrutura local é dispendiosa (considerando
os custos de servidores e hardware, rede, espaço físico, eletricidade, resfriamento e
pessoal). Essas despesas podem ser minimizadas substancialmente com o Azure Synapse
Analytics. Com a separação das camadas de computação e armazenamento, o Azure
Synapse oferece uma relação de preço-performance muito lucrativa.
Pós-migração
• Monitore e documente todas as etapas do processo.
• Use a experiência adquirida para criar um modelo para futuras migrações.
• Recrie o modelo de dados, se necessário.
• Teste aplicações e ferramentas de consulta.
• Compare e otimize a performance da consulta.
Estratégia Reprojetar
Em cenários em que o data warehouse herdado evoluiu com o passar do tempo, pode
ser essencial reprojetá-lo para manter os melhores níveis de performance ou oferecer
suporte a novos tipos de dados. Isso pode incluir uma alteração no modelo de dados
subjacente.
Para minimizar o risco, é recomendável migrar primeiro usando a estratégia lift and
shift e, em seguida, modernizar gradualmente o modelo de dados do data warehouse
no Azure Synapse Analytics usando a estratégia Reprojetar. Uma mudança completa no
modelo de dados aumentará os riscos porque afetará a origem dos trabalhos de ETL do
data warehouse e os data marts downstream.
Na próxima seção, ofereceremos algumas recomendações sobre como reduzir
a complexidade de seu data warehouse herdado existente antes de migrar.
Migrar de sistemas herdados existentes para o Azure Synapse Analytics | 615
Na próxima seção, vamos ver melhor por que você deve considerar a conversão de um
data mart físico em um data mart virtual.
• Funções: funções prontas para uso e funções definidas pelo usuário (UDFs)
• Procedimentos armazenados
• Requisitos de escalabilidade
• Projeções de crescimento
• Requisitos de workloads: usuários simultâneos
Com o inventário concluído, agora você pode tomar decisões sobre como escolher
o esquema que deseja migrar. Basicamente, há quatro opções para o escopo da
migração de esquema de data warehouse herdado:
1. Migrando um data mart por vez:
Figura 18.5: migrando todos os data marts de uma só vez, depois o data warehouse
618 | Azure Synapse Analytics para arquitetos
Tenha em mente ao escolher sua opção que o objetivo é alcançar um design de banco
de dados físico que corresponderá ou excederá seu sistema de data warehouse herdado
atual em performance e, preferencialmente, a um custo menor.
Migrar de sistemas herdados existentes para o Azure Synapse Analytics | 619
A Tabela 18.2 descreve as quatro opções de migração de dados e seus prós e contras:
Migrar dados • A migração de dados de um data mart • Até que sua migração esteja concluída,
do data mart por vez é uma abordagem incremental você terá alguns dados que existem
primeiro, seguido de baixo risco. Ela também fornece na infraestrutura local e no Azure.
por dados do uma prova mais rápida do caso de
data warehouse negócios para os usuários finais do • O processamento de ETL do data
departamento de análise. warehouse para data marts precisaria
• A migração de ETL subsequente preencher o firewall e ser alterado
é limitada apenas aos dados nos para segmentar o Azure Synapse.
data marts dependentes migrados.
Migrar dados do • Todos os dados históricos do data • Deixar data marts dependentes na
data warehouse warehouse são migrados. infraestrutura local não é ideal, pois
primeiro, seguido os ETLs precisam fluir dados de volta
por data marts. para o datacenter.
Na próxima seção, falaremos sobre como migrar os processos de ETL para o Azure
Synapse Analytics.
Migrar de sistemas herdados existentes para o Azure Synapse Analytics | 621
No entanto, muitas vezes, esse não é o caso. Nessa situação, uma estratégia diferente
deve ser tomada:
• Identifique os relatórios de alta prioridade para migrar primeiro.
• Use as estatísticas de uso para identificar os relatórios que nunca são usados.
• Evite migrar qualquer coisa que não esteja mais em uso.
• Depois de produzir a lista de relatórios para migrar, suas prioridades e os
relatórios não usados a serem ignorados, confirme essa lista com os stakeholders.
• Para os relatórios que você está migrando, identifique precocemente as
incompatibilidades para avaliar o esforço de migração.
• Considere a virtualização de dados para proteger as ferramentas de BI e aplicações
contra alterações estruturais no modelo de dados de data warehouse e/ou data
mart que pode ocorrer durante a migração.
geometry varbinary
geography varbinary
hierarchyid nvarchar(4000)
image varbinary
text varchar
ntext nvarchar
xml varchar
user-defined type Converta de volta para o tipo de dados nativo quando possível
Tabela 18.4: tipos de dados sem suporte e soluções alternativas apropriadas no Azure Synapse Analytics
624 | Azure Synapse Analytics para arquitetos
Nas próximas seções, forneceremos uma cobertura abrangente sobre como resolver
outras incompatibilidades do SQL comuns durante a migração de um data warehouse
herdado para o Azure Synapse Analytics.
Nulos • Os valores NULL podem ser gerenciados • Gere consultas SQL para testar valores
de forma diferente nos bancos de dados NULL.
SQL legados.
Por exemplo, na Oracle, uma string • Teste relatórios que incluem colunas
vazia é equivalente a um valor NULL. anuláveis.
Tabela 18.6: diferenças de DDL SQL entre sistemas herdados e o Azure Synapse
Incompatibilidades do SQL comuns e resoluções | 627
Abortar Permite que o usuário aborte sessões. Aplica-se a grupos KILL DATABASE
e usuários. CONNECTION
Soltar Permite que o usuário solte objetos. Aplica-se a todos os tipos de objeto. DROP
Preparar Permite que o usuário recupere o espaço em disco para linhas Gerenciado
excluídas ou desatualizadas e reorganize uma tabela pelas chaves automaticamente
de organização ou migre dados para tabelas que têm várias versões no Azure Synapse
armazenadas.
Inserir Permite que o usuário insira linhas em uma tabela. Aplica-se INSERT
apenas a tabelas.
Listar Permite que o usuário exiba um nome de objeto, seja em uma LIST
lista ou de outra maneira. Aplica-se a todos os objetos.
Selecionar Permite que o usuário selecione (ou consulte) linhas dentro SELECT
de uma tabela.
Truncar Permite que o usuário exclua todas as linhas de uma tabela. TRUNCATE
Aplica-se apenas a tabelas.
Permite que o usuário modifique as linhas da tabela. Aplica-se
Atualizar apenas a tabelas. UPDATE
Nesta seção, falamos sobre problemas comuns de migração que os arquitetos podem
encontrar durante um projeto de migração e possíveis soluções. Na próxima seção,
vamos ver considerações de segurança às quais um arquiteto deve estar atento.
Dados em movimento
Todas as conexões com o Azure Synapse Analytics são criptografadas por padrão,
usando protocolos padrão da indústria, como TLS e SSH
Além disso, a máscara de dados dinâmicos (DDM) pode ser usada para ofuscar dados
de determinadas classes de usuários com base em regras de mascaramento de dados.
Como prática recomendada, se o data warehouse herdado tiver uma hierarquia
complexa de permissões, usuários e funções, considere o uso de técnicas de automação
em seu processo de migração. Você pode usar metadados existentes do seu sistema
herdado para gerar o SQL necessário para migrar usuários, grupos e privilégios no
Azure Synapse Analytics.
Na seção final deste capítulo, revisaremos algumas das ferramentas que os arquitetos
podem escolher para ajudar a migrar de sistemas herdados de data warehouse para
o Azure Synapse Analytics.
Ferramentas para ajudar a migrar para o Azure Synapse Analytics | 633
Vamos começar.
ADF
O ADF é um serviço de integração de dados totalmente gerenciado, pré-pago e híbrido
para processamento de ETL em escala de nuvem. Ele oferece os seguintes recursos:
• Processa e analisa dados in-memory e em paralelo para escalar e maximizar a taxa
de transferência
• Cria pipelines de migração de data warehouse que orquestram e automatizam
o movimento de dados, a transformação de dados e o carregamento de dados no
Azure Synapse Analytics
• Também pode ser usado para modernizar seu data warehouse, ingerindo dados no
Azure Data Lake Storage, processando e analisando dados em escala e carregando
dados em um data warehouse
• Oferece suporte a interfaces de usuário baseadas em função para mapear fluxos
de dados para profissionais de TI e processar dados self-service para usuários
corporativos
• Pode se conectar a vários armazenamentos de dados que abrangem aplicações de
datacenter, nuvens e SaaS
• Mais de 90 conectores nativos e livres de manutenção disponíveis (https://azure.
microsoft.com/services/data-factory)
• Pode misturar e associar processamento e mapeamento de fluxos de dados no
mesmo pipeline para preparar dados em escala
• A orquestração de ADF pode controlar a migração de data warehouse para o Azure
Synapse Analytics
• Pode executar pacotes SSIS de ETL
634 | Azure Synapse Analytics para arquitetos
Azure ExpressRoute
O Azure ExpressRoute permite fazer conexões privadas entre seus datacenters
e o Azure sem passar pela Internet pública. Ele oferece os seguintes recursos:
BCP
O BCP pode ser usado para importar e exportar dados de qualquer ambiente do SQL
Server, incluindo o Azure Synapse Analytics Ele oferece os seguintes recursos:
• Oferece suporte a linhas com mais de 1 MB de comprimento
• Originalmente desenvolvido para versões anteriores do Microsoft SQL Server
Resumo
O Azure Synapse Analytics é um serviço de análise ilimitado com um tempo incomparável
de insight que acelera a entrega de BI, IA e aplicações inteligentes para empresas. Você
obterá muitos benefícios ao migrar o data warehouse herdado para o Azure Synapse
Analytics, incluindo performance, velocidade, maior segurança e conformidade,
elasticidade, infraestrutura gerenciada, escalabilidade e redução de custos.
Resumo | 637
A evolução da IA
A IA não é um novo campo de conhecimento. Na verdade, a tecnologia é o resultado de
décadas de inovação e pesquisa. No entanto, sua implementação nas décadas anteriores
foi um desafio pelas seguintes razões:
1. Custo: experimentos de IA eram caros por natureza, e não havia tecnologia
de nuvem. Toda a infraestrutura era comprada ou contratada por terceiros.
Experimentos também eram demorados para configurar, e grandes habilidades
eram necessárias para começar. Um grande poder de armazenamento e
computação também era necessário, o que geralmente faltava na comunidade
em geral e estava disponível apenas para alguns.
2. Falta de dados: quase não havia dispositivos portáteis inteligentes e sensores
disponíveis gerando dados. Os dados eram limitados por natureza e precisavam
ser adquiridos, o que novamente tornava as aplicações de IA dispendiosas. Os
dados também eram menos confiáveis, e havia uma falta de confiança geral nos
dados em si.
3. Dificuldade: os algoritmos de IA não eram documentados o suficiente e estavam
principalmente no domínio de matemáticos e estatísticos. Eles eram difíceis
de criar e utilizar nas aplicações. Basta imaginar a criação de um sistema de
reconhecimento óptico de caracteres (OCR) há 15 anos. Não havia quase nenhuma
biblioteca, dados, poder de processamento ou as habilidades necessárias para
desenvolver aplicações usando OCR.
Embora o fluxo de dados tenha aumentado com o tempo, ainda havia falta de
ferramentas para entender os dados de forma que agregasse valor comercial. Além
disso, bons modelos de IA são baseados em dados suficientemente precisos e treinados
com algoritmos para serem capazes de resolver problemas reais. A tecnologia de nuvem
e o grande número de sensores e dispositivos portáteis redefiniram esse cenário.
Processos de IA do Azure | 641
Processos de IA do Azure
Cada projeto baseado em IA deve passar por um determinado conjunto de etapas para
que seja operacional. Vamos explorar estas sete fases:
Ingestão de dados
Nesta fase, os dados são capturados de várias fontes e armazenados de forma
que possam ser consumidos na próxima fase. Os dados são limpos antes de serem
armazenados, e os desvios da norma são ignorados. Isso faz parte da preparação de
dados. Os dados podem ter diferentes velocidade, variedade e volume. Eles podem ser
estruturados de forma semelhante a bancos de dados relacionais, semiestruturados
como documentos JSON ou não estruturados, como imagens, documentos do Word
e assim por diante.
Transformação de dados
Os dados ingeridos são transformados em outro formato, pois podem não ser
consumíveis em seu formato atual. A transformação de dados normalmente inclui a
limpeza e a filtragem de dados, removendo os vieses dos dados, aumentando os dados
ao uni-los a outros conjuntos de dados, criando dados adicionais com base em dados
existentes e muito mais. Isso também faz parte da preparação dos dados.
Análise
Os dados da última fase são reutilizados para análise. A fase de análise contém
atividades relacionadas à descoberta de padrões nos dados, realização de análises de
dados exploratórios e geração de insights adicionais com base neles. Esses insights são
armazenados juntamente com os dados existentes para consumo na próxima fase. Isso
faz parte do processo de empacotamento do modelo.
642 | Arquitetar soluções inteligentes
Modelagem de dados
Depois que os dados são aumentados e limpos, os dados apropriados e necessários
são disponibilizados para os algoritmos de IA a fim de gerar um modelo propício para
atingir o objetivo geral. É um processo iterativo conhecido como experimentação
usando várias combinações de dados (engenharia de recursos) para garantir que o
modelo de dados seja robusto. Isso também faz parte do processo de empacotamento
do modelo.
Os dados são alimentados em algoritmos de aprendizado para identificar padrões. Este
processo é normalmente conhecido como treinamento do modelo. Mais tarde, os dados
de teste são usados no modelo para verificar sua eficácia e eficiência.
Validar o modelo
Depois que o modelo é criado, um conjunto de dados de teste é usado para encontrar
sua eficácia. Se a análise obtida dos dados de teste reflete a realidade, o modelo é sólido
e utilizável. O teste é um aspecto importante do processo de IA.
Implantação
O modelo é implantado em produção para que os dados em tempo real possam ser
alimentados nele para obter a saída prevista. Essa saída pode ser usada nas aplicações.
Monitoramento
O modelo implantado em produção é monitorado continuamente para a análise futura de
todos os dados de entrada e para treinar novamente e melhorar os modelos de eficácia.
Os estágios e processos de IA, por natureza, são demorados e iterativos. Assim,
as aplicações baseadas neles têm um risco inerente de serem de longa duração,
experimentais e de uso intensivo de recursos, juntamente com atrasos com custos
excedentes e com poucas chances de sucesso.
Mantendo essas coisas em mente, deve haver soluções de IA prontas para uso que os
desenvolvedores possam usar nas aplicações para torná-las inteligentes. Essas soluções
de IA devem ser facilmente consumíveis de aplicações e devem ter os seguintes recursos:
• Capacidade entre plataformas: os desenvolvedores que usam qualquer plataforma
devem ser capazes de consumir esses serviços. Elas devem ser implantadas
e consumidas em Linux, Windows ou Mac sem problemas de compatibilidade.
• Capacidade entre linguagens: os desenvolvedores devem ser capazes de usar
qualquer linguagem para consumir essas soluções. Os desenvolvedores não só
encontrarão uma curva de aprendizado mais curta, como também não precisarão
alterar sua escolha preferencial de linguagem para consumir essas soluções.
Serviços Cognitivos do Azure | 643
Essas soluções devem ser implantadas como serviços usando padrões e protocolos da
indústria. Geralmente, esses serviços estão disponíveis como pontos de extremidade
REST HTTP que podem ser invocados usando qualquer linguagem de programação
e plataforma.
Há muitos tipos de serviço que podem ser modelados e implantados para o consumo
do desenvolvedor. Alguns exemplos incluem:
• Conversão de linguagem: nesses serviços, o usuário fornece texto em uma
linguagem e obtém o texto correspondente em uma linguagem diferente
como saída.
• Reconhecimento de caracteres: esses serviços aceitam imagens e retornam
o texto presente neles.
• Conversão de fala em texto: esses serviços podem converter a fala de entrada
em texto.
Visão
Esta API fornece algoritmos para classificação de imagens e ajuda no processamento de
imagens, fornecendo informações significativas. A visão computacional pode fornecer
uma variedade de informações com base nas imagens em diferentes objetos, pessoas,
personagens, emoções e muito mais.
Pesquisa
Essas APIs ajudam em aplicações relacionadas a pesquisas. Elas ajudam na pesquisa com
base em texto, imagens, vídeo e fornecem opções de pesquisa personalizadas.
Linguagem
Estas APIs são baseadas no processamento de linguagem natural e ajudam a extrair
informações sobre a intenção do texto enviado pelo usuário juntamente com a detecção
de entidades. Elas também ajudam na análise e conversão de texto para diferentes
linguagens.
Fala
Estas APIs ajudam a converter a fala em texto, texto em fala e tradução de fala. Elas
podem ser usadas para ingerir arquivos de áudio e realizar ações com base no conteúdo
em nome dos usuários. A Cortana é um exemplo que usa serviços semelhantes para
tomar medidas para os usuários com base em fala.
Decisão
Estas APIs ajudam na detecção de anomalias e na moderação de conteúdo. Elas podem
verificar se há conteúdo em imagens, vídeos e texto e descobrir padrões que devem ser
destacados. Um exemplo dessa aplicação é exibir um aviso sobre conteúdo adulto.
Agora que você tem uma compreensão dos conceitos básicos dos Serviços Cognitivos,
vamos abordar como eles funcionam em detalhes.
Entender os Serviços Cognitivos | 645
Use octet-stream ao enviar dados binários e json para enviar valores de cadeia.
form-data pode ser usados para enviar vários valores de combinação de binário e texto.
A chave é uma cadeia única usada para validar se o chamador recebeu permissão para
invocar a URL. Essa chave deve ser protegida para que outras pessoas que não devem
ser capazes de invocar os pontos de extremidade não tenham acesso a ela. Mais adiante
no capítulo, você verá maneiras de proteger essas chaves.
646 | Arquitetar soluções inteligentes
O reconhecimento óptico de caracteres está disponível como uma API de visão e pode
ser provisionado usando o portal do Azure, conforme mostrado a seguir. Crie uma
API de visão navegando pelos Serviços Cognitivos > Visão computacional > Criar,
conforme mostrado na Figura 19.1:
Depois que a API é provisionada, a página de visão geral fornece todos os detalhes para
consumir a API. Ela fornece a URL base e as informações importantes. Anote a chave,
pois será usada posteriormente:
Ela também fornece um console de API para testar rapidamente a API. Ao clicar nela,
é aberta uma nova janela que tem todos os pontos de extremidade relacionados a
este serviço disponíveis. Ao clicar em OCR, você verá um formulário que pode ser
preenchido com os dados apropriados e executar os pontos de extremidade de serviço.
Você também verá uma resposta completa. Isso é mostrado na Figura 19.3. A URL está
disponível como uma URL de solicitação, e a solicitação é uma solicitação HTTP típica
com um método POST. A URL aponta para o ponto de extremidade na região Leste dos
EUA do Azure. Ela também está relacionada ao grupo de visão de APIs, versão 2 e ao
ponto de extremidade de OCR.
648 | Arquitetar soluções inteligentes
A solicitação pode ser enviada para o ponto de extremidade, clicando no botão Enviar. Isso
resultará em uma resposta HTTP 200 OK, conforme mostrado a seguir, se tudo der certo.
Se houver um erro nos valores da solicitação, a resposta será um código HTTP de erro:
Usar o Powershell
A mesma solicitação pode ser criada usando o PowerShell. O seguinte código do
PowerShell pode ser executado usando o PowerShell ISE.
O código usa o cmdlet Invoke-WebRequest para invocar o ponto de extremidade de
Serviços Cognitivos, passando a URL para o parâmetro Uri usando o método POST
e adiciona os cabeçalhos apropriados conforme abordado na última seção e, por fim,
o corpo consistindo em dados no formato JSON. Os dados são convertidos em JSON
usando o cmdlet ConvertTo-Json:
$ret = Invoke-WebRequest -Uri “https://eastus.api.cognitive.microsoft.
com/vision/v2.0/ocr?language=en&detectOrientation=true” -Method Post
-Headers @{“Ocp-Apim-Subscription-Key”=“ff0cd61f27d8452bbadad36942
570c48”; “Content-type”=“application/json”} -Body $(ConvertTo-Json
-InputObject @{"url“=”https://ichef.bbci.co.uk/news/320/cpsprodpb/F944/
production/_109321836_oomzonlz.jpg"})
Usar C#
Nesta seção, vamos criar um serviço que deve aceitar solicitações de usuários, extrair
a URL da imagem, criar a solicitação HTTP e enviá-la para o ponto de extremidade
de Serviços Cognitivos. O ponto de extremidade de Serviços Cognitivos retorna uma
resposta JSON. O conteúdo de texto apropriado é extraído da resposta e retornado ao
usuário.
Arquitetura e design
Uma aplicação inteligente é uma aplicação MVC ASP.NET Core. Uma aplicação MVC
é criada por um desenvolvedor em uma máquina de desenvolvedor, percorre o pipeline
de integração e entrega contínuos, gera uma imagem do Docker e envia a imagem do
Docker para o Registro de Contêiner do Azure. Aqui, os principais componentes da
aplicação são explicados, juntamente com seu uso:
Registro de
Contêiner do Azure
s
en
ag
im
ir
tra
Ex
Instância
Agendador
do pod 2
Servidor de API
kube-proxy
Usuários Balanceador
de carga Instância kubelet Gerenciador
do Controlador
do pod 1
Nós do
trabalhador Nós mestres
do Kubernetes de Kubernetes
Rede virtual
Docker
O Docker é um dos principais representantes em tecnologias de contêiner e está
disponível entre plataformas, incluindo Linux, Windows e Mac. O desenvolvimento de
aplicações e serviços em contêineres em mente fornece a flexibilidade para implantá-
las em nuvens e locais, bem como na infraestrutura local. Ele também remove todas as
dependências na plataforma de host, o que novamente permite menos dependência da
plataforma como serviço. O Docker ajuda na criação de imagens personalizadas, e os
contêineres podem ser criados com base nessas imagens. As imagens contêm todas
as dependências, binários e estruturas necessárias para fazer a aplicação ou o serviço
funcionar, e eles são completamente autossuficientes. Isso os torna um ótimo destino
de implantação para serviços como microsserviços.
Registro de Contêiner do Azure
O Registro de Contêiner do Azure é um registro semelhante ao Docker Hub para
o armazenamento de imagens de contêiner em um repositório. É possível criar vários
repositórios e carregar várias imagens neles. Uma imagem tem um nome e um número
de versão, formando juntos um nome totalmente qualificado que é usado para consultá-
los em uma definição do pod do Kubernetes. Essas imagens podem ser acessadas
e baixadas por qualquer ecossistema do Kubernetes. Um pré-requisito disso é que os
segredos apropriados para extrair a imagem já devem ser criados antes. Ela não precisa
estar na mesma rede que os nós do Kubernetes e, na verdade, não há necessidade de
uma rede criar e usar o Registro de Contêiner do Azure.
Serviço Azure Kubernetes
A aplicação inteligente que aceita a URL de uma imagem para recuperar o texto
nela pode ser hospedada em máquinas virtuais simples ou até mesmo no Serviço
de Aplicativo do Azure. No entanto, a implantação no Serviço de Kubernetes do
Azure oferece muitas vantagens, o que foi abordado no Capítulo 8, Arquitetar
soluções do Kubernetes do Azure Por enquanto, é importante saber que essas
aplicações têm recuperação automática por natureza, e um número mínimo de
instâncias é automaticamente mantido pelo mestre do Kubernetes, juntamente
com o fornecimento da flexibilidade para atualizá-los de várias maneiras, incluindo
implementações azul-verde e atualizações canário.
Pods, conjuntos de réplicas e implantações
O desenvolvedor também cria um arquivo YAML relacionado à implantação do
Kubernetes que faz referência às imagens na especificação do pod e também fornece
uma especificação para o conjunto de réplicas. Ele fornece sua própria especificação
relacionada à estratégia de atualização.
652 | Arquitetar soluções inteligentes
Serviços
Cognitivos do Azure
a
st
spo
/re
ão
itaç
lic
So
Instância
do pod 2 Agendador
Servidor de API
kube-proxy
Usuários Balanceador
de carga Instância kubelet Gerenciador
do pod 1 do Controlador
Nós do
trabalhador Nós
mestres do
de Kubernetes Kubernetes
Rede virtual
Depois que recebe a resposta JSON dos serviços, ele pode recuperar as informações
e retorná-las ao usuário.
O processo de desenvolvimento
O ambiente de desenvolvimento pode ser Windows ou Linux. Ele funcionará com
o Windows 10 e o Windows 2016/19 Server. Ao usar o Windows, é útil implantar
o Docker para Windows para que ele crie um ambiente do Linux e um ambiente
Docker do Windows.
Criar um serviço de OCR | 653
Ao criar um projeto de aplicação Web ASP.NET Core usando o Visual Studio 2019, a
opção Suporte do Docker deve ser selecionada com Windows ou Linux como valores.
Dependendo do valor escolhido, o conteúdo apropriado será gerado no Dockerfile.
A principal diferença no Dockerfile é os nomes de imagem base. Ele usa imagens
diferentes para Linux em comparação com o Windows.
Ao instalar o Docker para Windows, ele também instala uma máquina virtual Linux, e,
por isso, é importante ativar o hipervisor Hyper-V.
Neste exemplo, em vez de enviar os dados como uma cadeia JSON, a imagem é obtida
por download, e os dados binários são enviados para o ponto de extremidade de
Serviços Cognitivos.
Ele tem uma função que aceita uma entrada de cadeia para valores de URL. Em seguida,
ele invoca os Serviços Cognitivos com valores de cabeçalho apropriados e um corpo
contendo a URL. Os valores de cabeçalho devem conter a chave fornecida pelos Serviços
Cognitivos durante o provisionamento do serviço. O valor no corpo pode conter valores
de cadeia simples na forma de JSON ou pode conter dados de imagem binários em si. A
propriedade de cabeçalho do tipo de conteúdo deve ser definida em conformidade.
O código declara a URL e a chave relacionadas aos Serviços Cognitivos. Isso é mostrado
apenas para fins informativos. A URL e a chave devem ser colocadas em arquivos de
configuração.
{
httpClient1.BaseAddress = new Uri(myurl);
httpClient1.DefaultRequestHeaders.Add(“Ocp-Apim-
Subscription-Key”, token);
Nesta seção, criamos uma aplicação simples que usa os Serviços Cognitivos para
fornecer extrações de palavras de recursos usando a API de OCR e implantá-la nos pods
do Kubernetes. Esse processo e a arquitetura podem ser usados em qualquer aplicação
que deseja consumir APIs dos Serviços Cognitivos. Em seguida, vamos ver outra API de
Serviços Cognitivos, conhecida como recursos visuais.
Usar o Powershell
O código no PowerShell é semelhante ao exemplo de OCR anterior, portanto,
não é repetido aqui. A URL é diferente do exemplo de código anterior:
Usar .NET
Este exemplo é novamente uma aplicação MVC ASP.NET Core e tem o pacote NuGet
Microsoft.Azure.CognitiveServices.Vision.ComputerVision instalado nela:
Figura 19.8: aplicação MVC ASP.NET Core com o pacote NuGet Microsoft.Azure.CognitiveServices.
Vision. ComputerVision
[HttpPost]
public string Post([FromBody] string value)
{
private string visionapiurl = “ https://
eastus.api.cognitive.microsoft.com/vision/v2.0/
analyze?visualFeaure=tags,description,objects&language=en”;
private string apikey = “e55d36ac228f4d718d365f1fcddc0851”;
private ComputerVisionClient client;
private List<VisualFeatureTypes> visionType = new
List<VisualFeatureTypes>();
{
descrip += caption.Text + “ ”;
}
}
return tags;
// return descrip or objprop
Resumo
Neste capítulo, você adquiriu uma compreensão da arquitetura de implantação e da
arquitetura de aplicações para criar aplicações inteligentes no Azure. O Azure fornece
Serviços Cognitivos com vários pontos de extremidade: cada ponto de extremidade é
responsável por executar um algoritmo relacionado à IA e fornecer saídas. Quase todos
os pontos de extremidade de Serviços Cognitivos funcionam de forma semelhante em
relação a solicitações e respostas HTTP. Esses pontos de extremidade também podem
ser invocados usando SDKs fornecidos pelo Azure para diferentes linguagens, e você
viu um exemplo de como obter recursos visuais usando-os. Há mais de 50 pontos de
extremidade diferentes, e é recomendável obter uma compreensão da natureza dos
pontos de extremidade usando o recurso de console de API oferecido pelo Azure.
Por desenvolve- Receba artigos técnicos,
código de exemplo e
● Acompanhe as tecnologias
mais recentes
Sobre
Todas as principais palavras-chave usadas neste livro são capturadas em ordem alfabética nesta
seção. Cada uma é acompanhada pelo número da página onde aparece.
A endereço: 29, 33, 35, 37,
73, 75, 77, 93, 226, 233,
artefatos: 106-107, 112,
162-163, 230, 285-286,
acesso: 3, 8, 10, 12-13, 236, 246, 250, 256, 395, 429, 432, 434-436,
19, 71, 73-74, 76, 80, 268, 446, 458-459, 441, 444, 459-460, 644
84-85, 87, 110, 113, 115, 471, 480, 485-486, assembleias: 265,
145-148, 156, 158-159, 501-503, 526, 528-529, 432, 448, 460
163-165, 168, 170-171, 560-561, 570, 572 ataque: 228, 237, 248, 265
177-178, 184, 189-190, agregados: 405, 407 auditorias: 187
204-206, 208, 210, 213, alertas: 27, 58, 61, 63-66, automatizar: 17-18, 20,
221, 226-227, 230-232, 129, 133, 171, 198, 101, 105, 109, 184, 428,
234, 237-243, 245, 229, 237, 247-248, 475, 613, 619, 622, 633
247-252, 256, 265, 267, 254, 266, 333, 578 autoscale: 48, 53, 315
275, 287, 294, 297-298, algoritmo: 50, 659 azcopy: 634
319, 322, 358-359, análise: 8, 50, 61-64, azureappid: 363, 367
361-363, 371, 395-396, 66-67, 70, 74, 193, 244, azureblob: 536
399, 402, 442, 446, 458, 247-248, 265-266, 269, azurecr: 485, 490-491
479, 486, 503-504, 517, 273, 276-277, 333, 347, azurerm: 119, 122-123
522, 545, 553, 565-566, 351, 389-392, 403-408, azure-sql: 199, 213, 217
569, 576, 604, 609, 411, 413-416, 418, 421,
627, 632, 637, 645, 655
conta: 38, 52, 60, 64, 87,
442-443, 462, 472, 534,
578, 580, 582-588,
B
105-107, 109-111, 113, 598, 601-607, 609-614, back-end: 163, 310,
116-117, 119, 121, 132, 134, 616, 619-623, 625-627, 315, 321, 505
136-137, 139, 141, 151, 631-633, 635-637, 644 backup: 46, 201, 606, 632
157, 172, 174, 176-177, 179, android: 222, 317 bacpac: 429
184, 191, 194, 220-221, ansible: 428, 430, 442 balanceador: 29, 32-35,
233, 248-252, 257, 274, apache: 7, 275-276, 298, 38-39, 45, 50, 189, 245,
279-284, 286-289, 392, 587, 606-607, 637 458-459, 487-488,
293, 296-297, 309-312, baseado em API: 116 498, 500, 526
318-320, 329, 332, apikey: 657 largura de banda: 42, 70,
335-339, 347-348, apiversion: 151, 157, 73, 76, 79, 87, 215, 634
358, 361-364, 366, 485, 488-490, 496, binário: 272, 406, 439,
369, 371-372, 375, 378, 498-499, 511-512, 514, 645, 653, 656
399-400, 405, 408, 520, 524, 527-528, 530, associação: 307-311,
410-413, 415, 417, 443, 533-539, 542-544, 326, 330-332
458, 467-468, 483, 504, 551-554, 568, 571-572 blobadded: 335, 340
511, 516-519, 522, 524, appname: 485, blobsource: 539
526-529, 532, 535, 538, 488-491, 496 navegador: 17, 263,
554, 559, 565-569 arquiteto: 20, 23-24, 67, 295, 470, 500, 576
adappname: 361 71, 101, 162, 179, 184, pacote: 518, 520
addcontent: 374 190-191, 269, 343,
355, 386, 603, 632
C restrição: 79, 198, 502, 625
contêiner: 4, 10, 15-16, 32,
conjunto de dados: 179,
282, 287-289, 292, 298,
armazenamento em 50, 60, 147, 178, 190, 211, 406, 536-538, 541, 581
cache: 58, 190, 612 220, 280, 282, 288-289, descriptografia: 33,
retorno de chamada: 261 297, 316, 318-321, 330, 227, 239-240
canário: 651 340, 395, 413-414, 417, implantação: 4-8, 10-12,
cassandra: 7, 219-221, 298 438, 443, 462-463, 473, 14, 17, 19-20, 24-25,
certkey: 115 475, 477-479, 484-485, 39, 42, 45, 49, 58-59,
cgroups: 476 493, 496, 500-501, 72-75, 78, 152, 163-164,
cliente: 16-17, 36-37, 505-507, 522, 558, 179-180, 184, 188, 190,
57-58, 85, 238, 241, 565-566, 569, 650-652 194-200, 211, 213,
245, 248, 254, 257, cosmosdb: 330 218-219, 222, 225-226,
259-260, 276, 321, 380, 228, 230-231, 233,
463, 481, 580, 657
nuvens: 7, 67, 72, 136, 139,
D 235-236, 239, 244-245,
247, 256, 268, 306,
141, 145, 173, 633, 651 dacpac: 448 308, 314-315, 343, 358,
cluster: 29, 200, 275-276, daemon: 16-17, 463 425-427, 429, 431-437,
295, 478, 480-481, painel: 61, 107, 172-173, 440, 443, 445-446,
483-484, 486-487, 176, 180, 247, 373, 443 460, 463, 466, 472-473,
490, 492-495, banco de dados: 6-7, 475, 478-479, 483, 485,
500-506, 604-605 16, 39-40, 106, 111, 488-490, 492, 498-500,
cmdlet: 18, 112, 116-118, 121, 163, 178, 190, 193-199, 506, 509, 512-513,
127, 137-139, 150, 159, 201-202, 204, 206, 516-521, 525-526,
340, 342, 358, 361, 368, 208-215, 217-220, 222, 534, 545, 547-548,
469-470, 516, 519, 649 231, 242-243, 252-253, 550-551, 554, 556,
cognitivo: 8, 317, 255-256, 269, 330-331, 567, 569-570, 572-573,
325, 347, 637, 640, 405, 432, 442, 445-446, 607, 642, 651, 659
643-646, 649-650, 448, 534-536, 557, devops: 6, 11, 226-227,
652-653, 655-659 569, 577, 585-586, 286, 303, 418, 421-427,
colunar: 199, 298, 610 610, 612, 618, 634 430, 435-444, 457-458,
compilar: 108, databricks: 272, 274, 276, 461-462, 464-466,
430-431, 470 293-295, 297, 302-303, 471-473, 479, 493
simultâneo: 195, 606, 617 510, 534, 586, 607 dnsserver: 544
configurar: 12, 19, 27, 40, datacenter: 7, 26-27, 29, downstream: 14, 274,
62, 66, 130-131, 134, 31, 36, 38, 61, 70, 76, 410, 582, 614
136-137, 162, 197, 218, 80-82, 86, 197, 230,
222, 233, 259-261, 266,
292, 307, 313, 333, 346,
251, 253, 392, 545,
556-557, 565, 596, 613
E
348, 350-352, 361, 371, dataops: 619 ecossistema: 1, 6-8,
412, 414-415, 429-430, 44, 303, 390, 424,
433, 446, 457, 460, 443, 477, 484, 585,
467-468, 470, 473, 495, 603, 612, 637, 651
513, 530, 567, 589, 594 emulador: 327
633, 635, 641
criptografia: 33, 70, 75,
79, 85, 208-209, 227,
G instalador: 18
231, 239, 251, 253-254, github: 54, 293, 303, instância: 12, 26, 30,
267-268, 358, 632 535, 545, 577 32-33, 36, 46-47, 49, 54,
pontos de extremidade: gremlin: 219-221 56-57, 64, 70, 148, 152,
4, 19, 29, 35-38, 40, 125, 182, 185, 194, 198-199,
256-257, 265, 268, 316,
321, 325, 334, 486-487,
H 210, 213-214, 222, 245,
272, 277, 279-280, 282,
588-589, 591-593, hadoop: 7, 269, 272, 289, 346, 357-358,
612, 643-647, 659 274-275, 303, 389, 390-391, 393, 487,
inscrição: 168 586-587, 622 492-493, 501-503,
entidades: 84, 87, cabeçalho: 125-127, 252, 519-520, 522-524,
220, 227, 586 297-298, 341-342, 550, 581, 632, 656
eventgrid: 336, 368-369, 406, 495, 592, integridade: 76, 227, 625
342, 365, 381 644-646, 648, 653, 655 faturamento: 168, 176-177
eventtype: 335, 341, 368 horizontal: 51, 212 isolamento: 4, 10, 15-16,
extensão: 36, 50, 240, hospedagem: 1, 3, 14, 30, 73, 76, 83, 90, 195,
307, 325, 336, 377-378, 33, 38, 46, 74, 131, 133, 220, 247, 432, 497,
429, 463, 558, 564, 610 189, 197-198, 226, 229, 549, 596, 604-605
238, 285, 315, 343, 407,
F 414, 445, 476, 493, 503,
506, 526, 532, 584
J
failover: 40, 78, 86, 89, 221 nome de host: 485 javascript: 19, 58, 265,
nome do arquivo: 115, httpclient: 653-654, 307, 405, 407, 430
137, 297, 497, 537 656-657 jenkins: 6, 418, 422,
sistema de arquivos: httppost: 653, 657 464-466
208, 237, 360-361 httpstart: 325-326
firewall: 29, 33, 38, 40, 74,
K
189, 204-205, 233-237,
245-247, 252-253, 265,
I kernel: 15-16, 462, 476
269, 446, 458, 483, identificador: 117, 128, keyvault: 241, 365,
493, 557, 570, 596 241, 289, 335, 375, 569 521, 525, 569
formatos: 256, 272-273, imagens: 14, 17, 58, 84, 272, kubectl: 495-497,
277, 298, 317, 316, 443, 463, 479, 641, 499-500, 504
405-406, 583, 646 643-644, 651-653, 655 kubelet: 483, 493, 504-507
estrutura: 9, 18, 46, importar: 112, 122-123,
222, 275, 307-308,
423, 429, 468, 501
137, 300, 362,
364-365, 469, 636
L
frequência: 84, 184, 348, ingestão: 273, 277, lambda: 307
412, 537-538, 540, 581 391-392, 399, 403-404, bibliotecas: 17, 58, 265,
578, 581, 584-585, 432, 463, 640
587, 606-607, 612, licença: 188
localhost: 137, 139-140, 471 migração: 11, 279-280, 400-402
locais: 14, 18, 58, 81, 602, 611, 613-617, senha: 112-116, 210,
86, 153, 164, 221, 619-621, 623, 625, 240-241, 359-361,
519, 556, 651 632-637, 641 364, 380, 386, 495,
registro: 59-60, 74, 115, modelagem: 228-229, 642 502, 536, 544
141, 238, 263, 265, monitoramento: 11, 23, padrão: 69, 86, 90-101,
358, 477, 479, 532 32, 42, 52, 58-59, 218, 265, 333, 415,
pesquisa: 405 61-63, 66-67, 74, 187, 466, 555, 584,
198, 210-211, 222, 229, 592-593, 603, 659
M 231, 244, 265, 267-269,
279, 313, 316, 319,
carga: 35, 66, 184, 227,
308-309, 335, 341, 368,
máquina: 7, 25, 30, 57, 389, 435, 443, 462, 382, 495, 649, 655
65, 70-72, 74, 84, 99, 471-472, 477, 483, 577, petabytes: 8, 85, 274,
127, 130, 145, 161, 180, 588, 607, 610, 642 582, 588, 606
185-186, 188-190, pipeline: 278, 280,
197-198, 213, 231-233,
235, 238, 256, 268, 274,
N 282-284, 286-287, 291,
293, 431, 433-434,
276, 279, 295, 315, 356, namespace: 15, 279, 443, 446, 448, 452,
360, 389-390, 405, 283, 393-396, 400, 457, 459-461, 463-464,
407, 429-430, 442-443, 403, 409-410, 497, 472, 538, 541, 603,
460, 462, 467, 471, 473, 504, 512, 551 609, 612, 633, 650
478-479, 526, 528-530, nativo: 178, 213, 257, guia estratégico: 247
532, 541-545, 551, 556, 479, 501, 609-610 política: 8, 13, 56,
558-560, 562-565, nginx-lb: 499-500 145-148, 152-153,
570, 572, 586-587, bloco de anotação: 155-156, 162-164, 174,
603-604, 606-607, 295-296 278, 361, 395-396,
622, 637, 650, 653 399, 522, 540, 565
mainframe: 1
mariadb: 196
O postgresql: 6, 196
postman: 127, 328
mestre: 169, 213, 275-276, descarregar: 33, 343, 637 powershell: 8, 10, 17-20,
294, 343, 448, 478-484, sob demanda: 2-3, 6, 14, 50, 72, 108-109, 111-112,
492, 500, 535, 545, 240, 306, 318, 603-604, 114-115, 117-118, 120-121,
555, 557, 565-567, 606-608, 639, 641 125, 127, 134, 148-150,
571-572, 651 openid: 227, 257 152, 157-159, 163, 237,
memória: 14, 44, 46-48, oracle: 7 266, 316, 340, 356-357,
51, 186, 199, 204, os-level: 30 362, 364, 366, 386,
217-218, 361, 408, 633 429, 440, 443, 458,
metadados: 12-13, 51, 152,
167, 309, 485, 488-491,
P 466-468, 470, 472,
493, 510, 512-513, 515,
496, 498-499, 564, pacote: 18, 243, 255, 324, 519, 521, 543-544, 564,
591-592, 609-610, 429, 435, 446, 564, 656 567, 646, 649, 655
613, 619, 632 partição: 275, 398, premium: 30, 47-48,
84, 87, 190, 200,
212, 294, 315, 568
regiões: 7, 12-14, 27-29,
36-41, 67, 69-73,
S
preços: 141, 168, 178, 75, 79-80, 101, 106, escalabilidade: 3-4, 44-49,
184-185, 191, 214-215, 163-164, 189, 191, 197, 51, 53-54, 56-57, 197,
217-220, 222, 247, 315, 202-203, 219, 221, 230, 315, 475, 477, 576, 594
347, 370, 393-394, 409, 246, 333, 512, 515, 519, cenários: 29, 53-54, 76,
594-595, 598, 608 545, 556, 649, 654 78-79, 96, 107, 109,
entidade: 59, 107, 111, 113, registro: 15, 237, 316, 136, 180, 184, 222, 277,
115-118, 121, 161, 210, 479, 485, 650-652 301, 323, 392, 457,
241, 252, 287, 358-362, confiável: 82, 84, 88-89, 584-585, 603, 609, 614
367, 380-381, 516, 569 101, 103, 275-276, 426, agenda: 53-54, 98, 237,
protegido: 66, 75, 578, 580, 597, 640 276, 307, 346, 369,
230-231, 236, 239, 247, remoto: 81, 98, 385, 425, 483, 493,
251, 256-257, 265, 360, 238, 246, 459 505, 586, 622
522, 553, 593, 645 réplicas: 86, 221, 489, escopos: 170, 172, 237
protocolo: 29, 33, 491, 498-499 script: 107, 111, 115,
35, 84-85, 88, 227, replicaset: 482-483, 118-121, 134, 136-138,
232-233, 251, 257, 341, 488, 490-493 152, 237, 251, 356,
370, 392, 485, 488, relatar: 176, 180, 182, 184, 512, 516-518, 521, 525,
490-491, 497, 579-580, 436, 442, 577, 606 543, 558, 564-565
584, 588-589, 593 resiliente: 29, 38, 98, segredo: 239-241, 261-262,
psgallery: 564 274, 298, 436 357, 359-360, 368-369,
publicar: 333-334, resposta: 33, 43, 99, 519-521, 523-524, 569
341-342, 357, 127-128, 131, 182, 184, sendgrid: 355, 357,
368-369, 385, 586 221-222, 233, 244, 247, 370-373, 375,
pyspark: 300 315, 321, 493, 647-650, 377-379, 386
python: 6, 109, 112, 307, 652, 654-656, 658 sentinel: 243-245, 247
316, 356, 466, 586, recuperar: 19, 150, 159, servicebus: 325, 395, 400
603-604, 606-607, 646 182, 241, 277, 330, 332, servicenow: 66
341, 368, 651-652 sessão: 15-16, 29,
R revogar: 250
rgname: 569
32-33, 35, 38, 40,
263, 302, 392, 459
raspberry: 589 baseado em função: definir: 49, 57, 85, 107,
rawdata: 282 8, 115, 145, 242, 294, 131, 136, 161, 211, 217,
legível: 19, 202, 405, 430 504, 609, 633 266, 285, 315-316, 366,
reinicializar: 27, 30, 564 runbook: 105-106, 109, 371-373, 375, 378-379,
recriar: 503 111, 118-121, 123-129, 522, 566, 592, 605, 607
recuperação: 4, 7, 197-198, 131-132, 134-136, 141, sharepoint: 233
201, 221-222, 513, 545 333, 356-357, 366-367, assinatura: 85, 113, 249,
redundância: 25-27, 369, 379, 382, 385, 466 287, 395, 399, 522, 553
58, 86, 189, 200 skuname: 533
subordinados: 275
socket: 239, 392
sqlazure: 534
locatário: 77, 96, 117,
257, 358, 361, 363,
W
sqlclient: 636 367, 380, 569 warehouse: 277,
sqldataset: 538-540 terraform: 428 586-587, 601-606,
sql-query: 586 tokens: 85, 87, 182, 245, 609-612, 614-619,
autônomo: 236, 242, 244 249-250, 252, 569, 593 622-623, 625-627,
sem estado: 57, 142, 392 rastreamento: 63, 76, 632-634, 636-637
estático: 58, 65, 75, 190, 178, 247, 255, 437, 577 baseado na web: 33, 606
312, 320, 373, 576 tráfego: 29, 33-38, 40, webdeploy: 429, 432
streaming: 266, 391-392, 45-47, 72, 74, 77, 79, webhook: 66, 119, 125-127,
403, 407-408, 414, 82, 106, 142, 188-189, 129, 131, 333, 342
418, 587, 637 234, 237-238, 245, webserver: 468, 470, 496
estruturado: 84, 248, 390, 501, 589 webserver-: 496
272-273, 641 twilio: 355, 357, 371-373, windows: 1, 6, 14-18, 50,
sub-rede: 37, 50, 73, 375, 378-379, 386 63, 108, 188, 210, 234,
75, 207, 232-233, twitter: 257, 265, 269, 236, 243, 297-298, 316,
235, 238-239, 307, 406, 411-413, 415 395, 400, 429-430,
501-503, 506-507, 442, 462, 466, 476-477,
527-529, 562, 567
assinar: 333-334, 338, 379
U 503, 536, 552-553,
558, 564-565, 596,
assinado: 333 ubuntu: 235 642, 651-653
mudar: 27, 172, 262, upgrade: 54-56, 489, 594 workbooks: 247
478, 495, 615 trabalhador: 105-106,
synapse: 405, 586-587,
598, 601-614,
V 111, 119, 127, 134-136,
276, 294-295, 478-481,
616, 619-637 validação: 277, 431, 483, 492, 500
sysadmin: 567 433-434, 437, fluxos de trabalho:
460, 471, 481 108-109, 278, 321-322,
T cofres: 241, 268, 358, 366,
368, 379, 525, 569
346, 350, 355, 466,
586, 609, 622
destino: 29, 33, 87, 113, versão: 11-12, 19, 51, 56, workloads: 26, 58, 211,
242-243, 277-278, 289, 274, 279, 284-285, 293, 226, 233, 235, 237, 317,
292-293, 310, 315, 319, 295, 308, 324, 430, 587, 604-605, 613
390, 407, 426, 443, 438-439, 441, 444, 478,
468, 613, 619, 651 488-490, 510-513, 516,
modelo: 19-20, 56, 157, 531, 592, 604, 607, 610,
336, 348, 358, 446, 645, 647, 651, 655
489, 491, 498, 510-519, virtualizar: 15, 462
521-522, 524-527, 529,
532, 534-535, 538,
541, 547-561, 563,
565-568, 570-573, 614