Certificação AZ-204: desenvolvendo com Azure Compute Services

Conhecendo o Azure App Services - Apresentação

Olá, boas-vindas ao curso de certificação AZ-204: desenvolvimento de Azure Compute Services. Meu nome é Emílio Celso de Souza.

Audiodescrição: Emílio Celso é uma pessoa de pele clara de 54 anos, 1,75m de altura e 76kg. É grisalho e tem olhos castanhos. Usa óculos de grau, brinco na orelha esquerda e camiseta cinza. Está sentado e tem um microfone à sua frente. Ao fundo, estúdio com iluminação suave. À direita, uma estante com decorações.

Se você está interessado na certificação AZ-204, esse curso é para você!

Pré-requisitos

No entanto, é importante lembrar que existem alguns pré-requisitos importantes.

Não é objetivo do curso ensinar a plataforma .NET. É recomendado conhecer todo conhecimento de linguagem C#, ASP.NET Core e desenvolvimento web com ASP.NET.

A própria Microsoft recomenda uma experiência de dois anos na área de desenvolvimento. Não é obrigatório ter essa experiência, mas deve-se ter pelo menos um conhecimento equivalente ao que essa experiência exigiria.

Documentação

Apesar das aulas, é muito importante manter contato também com a documentação, porque ela sempre trará informações complementares relevantes. E, para efeito de certificação, é recomendado (e considerado) que a documentação seja estudada junto com as aulas e implementações.

Com relação à documentação, durante todo o curso serão apresentados documentos em inglês. Um exemplo é o guia de estudo para o AZ-204. Se você não se sentir confortável em ler o texto em inglês, é possível o ler em português. Todos os documentos têm um atalho para uma tradução automática acima do título. Basta clicar no ícone de globo denominado "Read in Português (Brasil)".

Só que é necessário tomar algumas precauções. Por exemplo, dentre os objetivos do exame, na seção "Desenvolver soluções de computação do Azure > Implementar soluções conteinerizadas", existe uma frase específica que queremos destacar. No quarto tópico, lê-se "criar soluções usando os Aplicativos de Contêiner do Azure".

Quando nos referimos à "Aplicativos de Contêiner", o termo técnico correto é "Container App". Não vamos nos referir a ele como está na tradução. Problemas como esses podem surgir, por isso, recomendamos a leitura do documento em inglês.

O que vamos aprender?

Nesse curso, vamos abordar o desenvolvimento de App Services e Web Apps, criação de registros de diagnóstico e domínios customizados. Também vamos entender o conceito de escalabilidade de App Services.

Além disso, vamos trabalhar com Azure Functions e todos os tipos de functions envolvidas. Basicamente, vamos conhecer os conceitos de Binding e Trigger, além de diferentes triggers usadas nas Azure Functions.

Também trabalharemos com soluções conteinerizadas. Nessa ocasião, vamos entender a diferença entre imagem e contêiner.

Apesar do Docker não fazer parte do objetivo do exame, vamos apresentar os conceitos do Docker justamente para introduzir conceitos relevantes para a conteinerização, que são: Azure Container Registry, Azure Container Instance e Container App.

Você também pode contar com o apoio da comunidade do Discord da Alura e com atividades de apoio disponíveis para cada aula.

Bons estudos e até o próximo vídeo!

Conhecendo o Azure App Services - O que são Azure App Services

Nesta aula, vamos conhecer os App Services. Vamos entender do que se trata esse serviço tão importante do Azure.

App Services, como o próprio nome indica, são serviços que permitem publicar e desenvolver aplicações.

Dentro do contexto dos App Services, temos os Web Apps, Azure Functions e Containers.

O que são Azure App Services?

Para contextualizar, vamos mostrar como acessar os App Services no portal do Azure. Uma vez que tenhamos disponível uma subscription, isto é, uma conta no Azure, acessamos portal.azure.com e fornecemos nossas credenciais para ter acesso a diversos recursos.

Para conhecer os recursos, um dos itens que podemos acessar é o menu do Azure. No canto superior esquerdo, pdoemos expandir o menu com os serviços clicando em "Show portal menu".

Opcionalmente, podemos clicar no primeiro ícone da tela principal, denominado Create a Resource (Criar um Recurso) e buscar dentre os diversos recursos disponíveis. Por exemplo, o Web App e Function App são alguns dos recursos que fazem parte do conglomerado dos App Services.

Todo serviço voltado à configuração, gerenciamento, desenvolvimento e publicação de aplicações fazem parte do App Service.

Próximos passos

Nossos próximos passos consistirão em criar App Services, mais especificamente Web Apps e Azure Functions. A partir daí, vamos mostrar como podemos fazer as publicações, isto é, como podemos desenvolver aplicações e torná-las disponíveis no Azure.

Conhecendo o Azure App Services - Publicando seu primeiro App Service através do Portal do Azure

Neste vídeo, vamos aprender como criar um Web App (aplicação web) no portal do Azure.

O Web App é um dos recursos disponíveis que fazem parte dos App Services. Portanto, criar um App Service é, na verdade, criar um Web App e vice-versa. Vamos mostrar como criamos e quais são as partes integrantes de um Web App.

Criando Web App através do portal

Existem várias formas de acessar o recurso Web App pelo portal do Azure. Uma delas é acessar a página inicial do portal e criar um novo recurso clicando na primeira opção de "Create a Resource". Outra forma é procurar por todos os serviços clicando em "All Services" no menu lateral esquerdo e, a partir daí, criar App Services.

Existem diversos caminhos e, à medida que evoluímos e desenvolvemos, conheceremos diversos atalhos para chegar ao mesmo recurso.

Como o portal é dinâmico, os recursos podem estar em uma ordem diferente da apresentada nesse curso. O importante é saber qual recurso, ferramenta ou componente buscamos acessar.

Em All Services > App Services, clicamos na opção "Create" que vai conter as opções de App Service que podemos criar: Web App, Static Web App, Web App com Database, ou uma aplicação WordPress. Nesse caso, escolhemos Web App e somos redirecionados a um formulário.

Praticamente em todos os recursos que criamos no Azure, precisamos fornecer dados em um formulário. Mas, as informações variam de recurso para recurso.

Básico

Geralmente, para todos os recursos, incluindo Web App, é preciso fornecer a nossa subscription (assinatura). Por padrão, o campo já contém uma subscription denominada "MCT", mas pode ser qualquer nível de subscription.

Pode ser uma subscription referente a uma conta gratuita do Azure, pertencente à assinatura do Visual Studio Enterprise ou fornecida pela empresa que você trabalha.

Uma vez selecionada a subscription, vamos definir uma informação muito importante, que é o resource group (grupo de recursos). Como é a primeira vez que usamos o serviço, não temos nenhum grupo.

O resource group nada mais é que um grupo de recursos. É uma estrutura que criamos para provisionar vários serviços.

Por exemplo, no mesmo resource group, podemos ter um Web App, um banco de dados, uma máquina virtual e assim por diante.

O resource group é utilizado principalmente para agrupar recursos, facilitando o processo de precificação - uma vez que todos os recursos têm um determinado preço no Azure.

O nome do resource group pode ser o que você quiser. Nesse caso, vamos colocar rg-webapp, sendo que o prefixo rg é a abreviação de resource group e webapp informa que criamos um Web App.

É interessante que o nome do grupo seja descritivo, mas não precisa ser exclusivo. Porém, o nome da instância de um Web App deve ser exclusivo.

Dentre os detalhes da instância, vamos fornecer um nome de instância no campo "Name". Porém, o nome sempre terá uma continuação, o sufixo .azurewebsites.net. Isso significa que o nome irá se transformar em um domínio da web, por exemplo, meudominio.azurewebsites.net.

Uma dica é usar seu primeiro e segundo nome e complementar com traço web. Por exemplo, emiliocelso-web está disponível. Se tentássemos usar um nome de instância muito convencional, como "app ou "aplicação", ele pode já não estar disponível. Além disso, não poderíamos usar o mesmo nome de instância para criar um segundo recurso.

Quando o serviço for publicado, a instância se chamará emiliocelso-web.azurewebsites.net.

Em seguida, podemos escolher o critério de publicação em "Publish". Para publicar usando o próprio portal do Azure como plataforma, basta selecionar a opção "Code". Nesse caso, seria a plataforma envolvendo o IIS (Internet Information Services), envolvendo um recurso que vai suportar a nossa aplicação.

Também podemos publicar em um Docker Container. Nesse caso, o contêiner tem que estar disponível e provisionado. Ou podemos publicar na forma de Static Web App. Como o próprio nome já sugere, é uma aplicação estática, envolvendo apenas HTML, CSS e, porventura, JavaScript. Não tem nenhum runtime envolvido.

No nosso caso, vamos selecionar a opção "Code" e, logo abaixo, informar qual é o runtime que vamos utilizar.

No dropdown de "Runtime stack", existem várias opções de runtime. Para .NET, é possível escolher entre .NET 8, 7 e 6. No momento da gravação desse vídeo, .NET 8 é a versão mais atualizada. Também conta com as versões tradicionais do ASP.NET.

Além disso, podemos publicar também em Java 21, 17, 11 e 8. A versão mais recente do Java no momento da gravação desse vídeo é a versão 21. Por fim, podemos publicar também em Node, PHP e Python.

No caso, vamos escolher ".NET 8 (LTS)". Por fazer parte do .NET Core, o .NET permite publicação tanto para Windows quanto para Linux. Por isso, podemos escolher qual plataforma vamos provisionar. Nesse caso, em "Operating System", vamos escolher o Windows como sistema operacional subjacente.

Outra informação importante é a região. Quando provisionamos um serviço, precisamos dizer em que região ele será provisionado. Como padrão, foi selecionado "East US" (Leste dos Estados Unidos). Dependendo da região, existe uma tabela de preços diferente.

Atenção: A região dos Estados Unidos é, normalmente, um pouco mais barata que a do Brasil. Porém, é preciso tomar cuidado com a LGPD (Lei Geral De proteção de Dados Pessoais).

Por exemplo, até podemos criar uma instância em um data center que fica nos Estados Unidos, mas tendo ciência de que deve ser usada para fins de teste, e imediatamente, deve ser removida na sequência.

Para provisionar profissionalmente, é necessário ter algum tipo de relacionamento, como ter uma filial da empresa naquela localidade e assim por diante.

Pensando nisso, vamos selecionar "Brazil South" (Sul do Brasil) que é um data center localizado em São Paulo.

Existem outros aspectos importantes, mas que vamos discutir em outro momento, como o conceito de service plan e pricing plan que são os tipos de serviço e precificação.

Para avançar para a próxima etapa, clicamos no botão "Next: Database" na parte inferior da página.

Base de dados

É possível criar um database associado a esse recurso que estamos criando, o App Service, caso queiramos nos conectar a uma base de dados específica.

O fato de poder provisionar ou não um database vai depender do modelo de preço que estamos utilizando. Esse modelo é escolhido na etapa anterior no campo "pricing plan". Para voltar a etapa básica, basta clicar no botão "Previous" na parte inferior da página.

O plano que selecionamos foi o plano padrão, chamado "Standard S1". Esse plano padrão permite um database, mas não vamos optar por ele. Por isso, deixaremos a caixa "Create a Database" desmarcada e seguiremos para a próxima etapa clicando no botão "Next: Deployment".

Implantação

No próximo passo, deployment, existem duas opções importantes: Basic Authentication (autenticação básica) e Continuous deployment (implantação contínua).

Por enquanto, vamos deixar o Basic Authentication desabilitado, selecionando a opção "Disable". Essa configuração está relacionada a como fazemos a publicação da aplicação.

Por exemplo, para publicar a partir do Visual Studio ou de alguma ferramenta de desenvolvimento, é preciso permitir que essa ferramenta se integre com o nosso recurso no portal. Nesse caso, colocaríamos a opção "Enable". Isso pode ser mudado em outro momento, como mostraremos logo mais.

Para permitir que a nossa aplicação seja publicada no GitHub e que o Web App seja sincronizado com essa aplicação publicada, devemos habilitar o Continuous Deployment, selecionado a opção "Enable".

Com isso, precisamos fornecer os dados da nossa conta do GitHub na seção "Github Actions details". Nesse primeiro momento, vamos deixar em "Disable" para não habilitá-la.

Feito isso, passamos para a próxima etapa clicando em "Next: Networking".

Networking

No próximo passo, Networking, o único conceito que deixaremos ativado será o Public Access (acesso público). Manteremos a opção "On" para provisionar um endereço IP, a partir do qual podemos acessar a nossa aplicação ou integrá-la com outros recursos, como, por exemplo, uma máquina virtual.

Monitoramento

Próximo passo se chama Monitoring (monitoramento). Essa propriedade está relacionada ao processo de instrumentação.

Recursos que existem no Azure, também relacionados a monitoramento, mais especificamente, associados a Application Insights.

Isso tem relação com um recurso que monitora a nossa aplicação, dependendo de como queremos tratá-la. Por exemplo, métricas relacionadas à quantidade de requisições, tempo de requisição, e assim por diante.

Nesse primeiro caso, vamos deixar essa opção desabilitada, marcando "No", e seguir para a próxima etapa.

Etiquetas

As tags não são importantes nesse momento para a nossa aplicação. Por isso, não vamos apenas seguir para o passo de "Review + Create".

Revisão e criação

O passo de review e create é onde todas as propriedades preenchidas são revisadas para poder criar o recurso. Após clicar no botão "*Create", pode levar algum tempo para criar o recurso.

Uma vez que o recurso foi criado, podemos pressionar o botão "Go to Resource" para ir até a página do recurso que criamos, um Web App denominado emiliocelso-web. Pode ser o nome que você quiser, desde que seja exclusivo.

Na lateral direita da página do recurso, temos diversas propriedades disponíveis. Na primeira propriedade chamada "Overview", são listadas as principais propriedades.

Dentre elas, o Default Domain (domínio padrão) é o nome que havíamos falado no início na criação do recurso, emiliocelso-web.azurewebsites.net. Se clicarmos nesse link, será aberta a aplicação web.

Já temos uma Web App pronta para ser usada. Obviamente que não é aquela que desejamos.

Conclusão

O que queríamos mostrar nesse vídeo é o processo de criação e o detalhamento das propriedades que utilizamos no processo de criação de um recurso dentro de um resource group.

Nesse momento, o único recurso que temos disponível é uma Web App, que já está implantada. Normalmente, é comum integrá-la com alguma ferramenta de desenvolvimento, como Visual Studio, para publicar uma aplicação real.

Até o próximo vídeo!

Sobre o curso Certificação AZ-204: desenvolvendo com Azure Compute Services

O curso Certificação AZ-204: desenvolvendo com Azure Compute Services possui 576 minutos de vídeos, em um total de 116 atividades. Gostou? Conheça nossos outros cursos de Azure em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Conhecendo o Azure App Services
• App Service Plans
• Propriedades e configurações das Web Apps
• Escalabilidade: Scale Up e Scale Out
• Publicação através do Github - Conceitos de CI/CD
• Deployment Slots
• Domínios customizados
• Conhecendo Azure Functions
• Triggers e Bindings
• Azure Durable Functions
• Azure Container Registry (ACR)
• Tarefas no Azure Container Registry
• Suporte a Containers no Azure App Service
• Apresentação do Azure Container Instances (ACI)
• Azure Container App