DEV Community: Ana Carolina Manzan

Implementando Blue-Green deployment com Deployment slots do Azure Web App

Ana Carolina Manzan — Thu, 23 Jan 2025 01:02:13 +0000

Você já passou pela experiência de planejar os seus deployments fora de horário comercial por causa da indisponibilidade que o deployment pode causar?

Ou então, depois de finalizar o deployment, você se deu conta de que a nova versão tem problemas que não deveriam chegar ao ambiente produtivo e precisou realizar um rollback para a versão anterior?

Neste artigo, eu quero mostrar uma solução simples para este problema utilizando a estratégia blue-green deployment com os deployment slots do Azure App Service.

O que são deployment slots?

Primeiramente, precisamos entender o que são os deployment slots e como eles podem nos auxiliar a aplicar a estratégia Blue-green.

Deployment slots é uma funcionalidade específica do recurso Azure App Service que facilita a implantação da aplicação seguindo a estratégia blue-green. Ele nos permite criar uma réplica, um ambiente duplicado atrelado ao Web App original que irá se comportar como um ambiente de preparação que irá receber novas versões da nossa aplicação.

E como isso se relaciona com a estratégia blue-green?

O blue-green é uma estratégia de deployment que consiste em termos uma réplica do ambiente produtivo, na qual iremos implantar as novas versões da aplicação. Depois da implantação, chaveiam-se os ambientes e todas as requisições para a aplicação são encaminhadas para esta nova versão, liberando assim o acesso a todos os usuários.

Uma de suas vantagens é que, em caso de erros na nova versão, basta redirecionar as requisições dos usuários de volta para a versão anterior.

Vou usar uma analogia para explicar melhor: Imagine que você tem 2 cozinhas em seu restaurante: uma azul e uma verde. A cozinha azul é utilizada para preparar as refeições e servir os seus clientes, enquanto a cozinha verde está passando por uma reforma. Quando a reforma da cozinha verde é finalizada, você volta a utilizá-la para preparar as refeições e servir seus clientes, e, se tudo correr bem, você então irá desativar a cozinha azul.

Vamos à prática

Para utilizar os deployment slots, é necessário criar um Web App atrelado a um App Service Plan na camada Standard, no mínimo. As camadas Premium e Isolated de precificação também oferecem a funcionalidade de Deployment Slots.

Para facilitar esta etapa, vamos usar o Azure CLI para criar os recursos.

Quero deixar uma explicação breve sobre o código de criação de recursos abaixo: da linha 1 até a linha 5, criamos variáveis que vão conter as informações dos recursos, como por exemplo, a região onde o recurso deve ser criado, o nome do grupo de recursos, do App Service Plan, do web app e do deployment slot. Você pode trocar os valores das variáveis de acordo com o nome que desejar para seus recursos.

Da linha 7 até a linha 10 do código, vamos criar o grupo de recursos, o App Service Plan, o Web App e o Deployment Slot acoplado ao Web App.

Os comandos acima podem ser executados diretamente no seu computador (após instalar o Azure CLI) ou no portal do Azure usando o cloud shell.

Depois de executar os comandos, esse é o resultado que esperamos no portal do Azure, com todos os recursos criados:

Logo após a criação dos recursos, o Web App (à esquerda) e o Deployment Slot (à direita) exibirão uma mensagem aguardando pelo código que será implantado neles, conforme a imagem abaixo:

Agora com a infraestrutura pronta, precisamos criar uma pipeline que fará a implantação (o deployment) da aplicação no Web App, e depois disso, fará a operação de troca do Web App com o Deployment Slot.

No código acima, temos as tarefas que farão as operações de deployment e troca de ambientes. Vamos focar nestas duas tarefas da pipeline por ora, mas disponibilizei o código completo da pipeline aqui e o código completo do projeto aqui.

A primeira tarefa da pipeline será utilizada para implantar a nossa aplicação no Web App. Nesta tarefa, o código da aplicação será enviado diretamente ao deployment slot chamado stage do Web App bgapp.

Depois que o código for implantado no deployment slot, na segunda tarefa vamos realizar a operação de troca dos ambientes (swap). Nesta etapa, trocamos o deployment slot stage de lugar com o Web App que está em produção, e então, disponibilizaremos aos nossos usuários a versão mais atual da aplicação.

Observe que neste cenário, sempre que tivermos uma implantação, a troca também acontecerá logo depois dela. Se desejar ou se for aplicável ao seu cenário, você também pode executar a operação de troca manualmente no portal do Azure.

É hora de testar!

Agora que finalizamos as implementações, configure e execute a pipeline diretamente no Azure DevOps pela primeira vez e valide então o resultado:

Após a primeira execução da pipeline, implantamos a versão da aplicação que contém a funcionalidade blue, como podemos confirmar na imagem acima.

Agora, iremos implementar a funcionalidade green e implantar novamente com a nossa pipeline. Altere o código fonte para exibir a funcionalidade green, faça o commit e o push para o Azure DevOps, e então, a pipeline será acionada pelas mudanças realizadas na branch main.

Durante a execução da pipeline, o código será implantando no deployment slot stage inicialmente:

E depois que a operação de troca de ambientes acontecer, teremos então o resultado final da nossa nova implementação:

À esquerda na imagem acima, temos o nosso ambiente produtivo do Web App com a versão da aplicação que contém a funcionalidade green. À direita, temos o slot stage com a versão anterior que contém a funcionalidade blue.

Espero que este conteúdo possa contribuir para sua jornada, e se você gostou, deixe um comentário ou entre em contato comigo no LinkedIn.

Até mais! 👋

Automatizando a inclusão de certificados ao Key Vault usando Azure DevOps Secure Files com Terraform

Ana Carolina Manzan — Thu, 21 Nov 2024 20:12:07 +0000

Ao trabalharmos com certificados de autoridade certificadora, quando por exemplo, configuramos o SSL no Azure Application Gateway ou no Azure API Management, podemos nos deparar com a necessidade de adicionar os certificados ao Azure Key Vault. Neste artigo, veremos um método de adicionar os certificados automaticamente ao Key Vault, sem a necessidade de intervenções manuais que podem causar interrupções no processo de automação. Para alcançarmos este objetivo, vamos utilizar o Secure Files do Azure DevOps e Terraform.

Configurações no Azure DevOps

Vamos trabalhar com um cenário onde já temos um um certificado no formato .pfx e uma senha para o certificado. Para começar, vamos fazer o upload do nosso certificado na seção Secure Files do Azure DevOps. Acesse https://dev.azure.com/<nome_da_organizacao>/<nome_do_projeto>/_library?itemType=SecureFiles

Como na imagem acima, clique no botão + Secure File para fazer o upload do seu certificado. Para o exemplo do artigo, criei um dummy certificate (veja como criar aqui ou aqui) com o nome certificate.pfx, fiz o upload para o Secure Files e renomeei o arquivo para certificate (Removi a extensão .pfx do arquivo para facilitar o uso do nome do certificado em variáveis).

Depois de realizar o upload, acesse o arquivo do certificado para dar permissão à pipeline na qual você deseja usá-lo. Siga os passos conforme a imagem:

Como faremos o deployment da infraestrutura através de uma pipeline yaml, vamos adicionar duas variáveis ao grupo de variáveis que vamos utilizar para este artigo: CERTIFICATE_NAME e CERTIFICATE_PASSWORD.

Código Terraform

Vamos agora trazer o código terraform para a criação do Key Vault.
No código abaixo, temos a criação do Key Vault contendo políticas de acesso que vão permitir que a nossa Service Principal crie (Create), importe (Import) e obtenha (Get) certificados.

Além disso, no bloco azurerm_key_vault_certificate temos a criação do certificado em si, obtendo o conteúdo do certificado através da função filebase64 e da variável certificate_path que contém o caminho para o arquivo do certificado.

Pipeline

Na pipeline, precisamos realizar o download do arquivo do certificado que está dentro do Secure Files. Para isso, usaremos a tarefa DownloadSecureFile@1. Esta é uma tarefa relativamente simples, que recupera um arquivo do Secure Files a partir do seu nome.

Neste bloco de código, podemos observar que a tarefa tem dois parâmetros importantes: name e secureFile (dentro do bloco inputs).
O parâmetro name vai nos servir como uma variável para obter as saídas da tarefa (como o caminho para onde o arquivo foi baixado, por exemplo).
Já o parâmetro secureFile vai receber o valor da variável CERTIFICATE_NAME que criamos anteriormente no nosso grupo de variáveis.

Já na tarefa que executa o comando terraform apply, como vemos acima, vamos passar o caminho do certificado para a variável certificate_path utilizando o mesmo valor do parâmetro name da tarefa DownloadSecureFile@1, e referenciando o valor de saída com o .secureFilePath. Neste exemplo, o resultado é $(certificate_secure_file.secureFilePath).

Excluindo o arquivo do certificado

Podemos realizar a exclusão do arquivo do certificado de dentro do agente de deployment usando a tarefa DeleteFiles@1. Esta tarefa faz a exclusão de arquivos e/ou pastas a partir do caminho apontado a ela no parâmetro Contents. Aqui também vamos utilizar a variável $(certificate_secure_file.secureFilePath) para garantir que depois de utilizado pelo terraform, o nosso certificado será excluído do agente.

Você pode encontrar o código completo do exemplo deste artigo aqui.

Este é artigo traduzido e adaptado do artigo original escrito por T. Constantini.

Observabilidade à uma tela com Dashboards

Ana Carolina Manzan — Wed, 16 Oct 2024 23:40:26 +0000

Este artigo foi escrito, em uma iniciativa conjunta no curso de Observabilidade da comunidade WomakersCode, por:

Ana Carolina Manzan - LinkedIn
Daniela Farias - LinkedIn
Gabriela Tavares - LinkedIn
Natacsha Melo - LinkedIn

Quando falamos sobre o assunto observabilidade, é natural pensarmos em pilares e em ferramentas que possam tornar os nossos sistemas observáveis. Nossos sistemas podem ser observados através de logs, métricas e traces, e estes podem ser instrumentados através de ferramentas de monitoramento como os dashboards.

O que é um dashboard?

Um dashboard é um painel personalizado para exibição de informações, que permite unir informações e dados para apresentação visual, geralmente em forma de gráfico ou tabelas, e a partir da junção deles é possível fazer várias análises desses dados. Um dashboard conta uma história, ao olharmos para ele é possível identificar o que está sendo transmitido.

O dashboard nos permite ver os dados em tempo real, podendo fazer a análise dos dados de maneira eficiente e assertiva, que também é uma ferramenta muito importante na tomada de decisões.

Quais ferramentas usar para a criação de um dashboard?

Agora que já entendemos o que é um dashboard, conheceremos quais ferramentas podemos utilizar para a construção dos dashs.

Tableau: É uma ferramenta de visualização de dados mais popular disponível atualmente. Suporta um número grande de dados, e permite flexibilidade no manipulação dos dados

Microsoft Power BI: Uma ferramenta líder de mercado na construção de dashs, que permite a integração com outros produtos da Microsoft como Excel e Azure. Oferece recursos robustos na visualização de dados, interativos e podem ser compartilhados com outros usuários.

Sentry: É uma ferramenta que rastreia erros e mostra as falhas na pilha de código quando elas ocorrem, e também, oferece dashboards configuráveis que permitem visualizar métricas de erro, desempenho e tendências ao longo do tempo.

Grafana: É uma ferramenta na qual permite a criação de dashboards dinâmicos, pois possui suporte para diversos tipos de fonte de dados, possibilitando a visualização e monitoramento dos dados do sistema.

Azure Application Insights: O Application Insights é uma funcionalidade do Azure Monitor, e é um produto do Azure que nos fornece perspectivas de nossas aplicações, como por exemplo: visão de performance e saúde da aplicação, visualização de métricas em tempo real, rastreio de traces e transações específicas, dentre outras funcionalidades que o caracterizam como uma ótima opção quando falamos sobre dashboards.

Como utilizar dashboards?

Para exemplificarmos a utilização de dashboards e algumas práticas comuns, vamos utilizar aqui no artigo o Sentry para exemplos.

O Sentry, como dito anteriormente, por ser uma ferramenta forte de rastreamento de erros, pode ser utilizado para criar dashboards interessantes, e como a ferramenta também é amplamente utilizada na observabilidade do front-end de aplicações.

Já de início eles oferecem templates prontos para dashboards gerais, front-end, back-end e mobile.

Usando como exemplo os modelos de dashboards do Sentry, vamos passar pelo uso de cada um e no que seria útil de tê-lo para visualização no dia-a-dia. Começando pelos dashboards gerais, são dashs que permitem a ampla visão de usuários afetados pelos erros e suas informações mais críticas que podem ser usadas para estratégias da empresa e correção de bugs.
Como a quantidade de usuários afetados, localização dos usuários, quantidade de erros, quantidade de issues criadas a partir de erros e suas atribuições, que permite maior controle de tarefas de uma equipe, horários que os erros mais afetaram, navegadores, endpoint e entre outros.

Um dash de front-end pode nos dar informações importantes que afetam experiência do usuário, rapidez do sistema, estratégias de SEO, e também, ao nos mostrar facilmente rotas mais afetadas, seja por erros ou lentidão, ajuda a mobilização dos desenvolvedores na resolução de problemas e melhorias, e ajuda a empresa e o time a traçar estratégias de otimização e sustentabilidade maior da aplicação.

No back-end o uso no Sentry é similar a depender dos dados escolhidos ao criar um dashboard para observar e monitorar, focando na satisfação e experiência do usuário, ele mostra tempos de respostas, horários e quantidade de usuários afetados, os endpoints mais afetados para rápida identificação no time desenvolvimento, entre outros.

Para aplicações mobile os dados normalmente mostrados nos dashs são quantidades de crashes, quantidade de usuários únicos afetados, horários, tempo de inicialização do aplicativo e sistemas operacionais mais afetados.

Com essa facilidade de criação de dashboards separadas por funções, aos exemplos acimas, facilidade de visualização desses dashs e o vínculo da criação de issues e atribuição a equipe, dado esse que também pode ser colocada em um dash, torna o Sentry uma ferramenta completa que nos permite organizar dados e métricas para observá-los, assim como outras diversas ferramentas disponíveis no mercado e aqui citadas.

Fundamentos de Observabilidade

Ana Carolina Manzan — Sun, 29 Sep 2024 21:31:47 +0000

Este artigo foi escrito, em uma iniciativa conjunta no curso de Observabilidade da comunidade WomakersCode, por:

Ana Carolina Manzan - LinkedIn
Daniela Farias - LinkedIn
Gabriela Tavares - LinkedIn
Natacsha Melo - LinkedIn

Observabilidade versus Monitoramento

Quando ouvimos a palavra observabilidade, é natural que façamos algumas referências e analogias diretas ao termo monitoramento. Afinal, através de alguns pilares da observabilidade, como as métricas, por exemplo, podemos monitorar alguns aspectos das nossas aplicações.

Mas qual a diferença entre um sistema "monitorado" e um sistema "observável"?

Ao tentar entender a diferença entre os dois termos, buscamos alguns significados para os mesmos diretamente da língua inglesa, de onde eles surgiram e de onde obteremos algumas explicações que podem vir a ser ilustrativas:

Observe: notice or perceive (something) and register it as being significant.
Observar: notar ou perceber (algo) e registrá-lo como significativo.

Monitor: an instrument or device used for observing, checking, or keeping a continuous record of a process or quantity.
Monitor/monitorar: um instrumento ou dispositivo usado para observar, verificar ou manter um registro contínuo de um processo ou quantidade.

A partir da definição em inglês e da tradução livre, podemos concluir então que o monitoramento nada mais é do que um meio, um recurso e/ou instrumento a ser usado para observar um sistema, mas não define o conceito de observabilidade inteiramente e por si só.

Um sistema pode ser observado por meio de monitoramento, alertas, comportamentos, estados, logs, métricas, traces e telemetria. A observação de um sistema requer diversos olhares e mapeamento para identificar dados relevantes. Filtrar esses dados é crucial, pois a observabilidade vai além do monitoramento, trazendo benefícios como resolução de bugs, melhorias e maior qualidade de código. Por exemplo, ao monitorar logs, uma equipe pode detectar um status 403 inesperado e resolver o problema antes de uma reclamação formal do usuário, demonstrando a diferença entre observabilidade e monitoramento.

Os 3 pilares da Observabilidade

A observabilidade é construída sobre três pilares principais — logs, métricas e traces — que, juntos, ajudam a garantir que possamos entender e diagnosticar problemas em sistemas em ambientes de produção com rapidez e eficiência. Com a crescente complexidade dos sistemas modernos, onde uma simples falha pode afetar várias partes interconectadas, ter esses três pilares bem implementados se torna fundamental.

Os logs são o primeiro pilar, registrando os eventos que ocorrem no sistema. Eles detalham o que está acontecendo nos bastidores, fornecendo informações sobre erros, warnings e eventos importantes. Para desenvolvedores, os logs são a primeira linha de investigação quando algo sai do controle, oferecendo uma visão clara do que aconteceu em determinado momento.

Métricas é um dos pilares da observabilidade, entram com uma visão mais quantitativa, permitindo que possamos monitorar a saúde do sistema em tempo real, podemos dizer que métrica é uma informação pré estruturada.Elas ajudam a identificar anomalias em recursos como CPU, memória, latência e throughput, que permitem ao longo do tempo fazer o acompanhamento de determinados comportamentos que possam se tornar problemas maiores.

Por último, os traces são o mapa que revela o caminho percorrido por uma requisição dentro do sistema. Eles ajudam a entender como uma solicitação passa por diferentes serviços e onde possíveis gargalos podem estar ocorrendo, como por exemplo onde uma requisição pode atravessar dezenas de microsserviços, os traces são cruciais para detectar problemas de performance e otimizar o fluxo entre serviços.

Dessa forma, ao combinar logs, métricas e traces, desenvolvedores conseguem ter uma visão completa do sistema, tornando o processo de identificação, diagnóstico e resolução de problemas muito mais ágil e eficaz. Além de apoiar também na tomada de decisão.

Próximos passos: Como colocar o conceito de observabilidade em prática?

Uma das formas de aplicarmos a observabilidade é por meio da construção de troubleshootings e runbooks.

Os troubleshootings são guias que auxiliam na identificação e resolução de problemas, oferecendo uma abordagem sistemática para diagnosticar falhas em sistemas complexos. Eles ajudam a mapear possíveis causas de um incidente e oferecem soluções potenciais com base em dados e métricas disponíveis.

Já os runbooks são conjuntos de procedimentos operacionais padronizados que descrevem as ações a serem tomadas em resposta a situações específicas, muitas vezes integrando métricas de observabilidade para auxiliar na automação e na rápida resolução de incidentes.

Conclusão

A partir dos conceitos e ferramentas apresentadas neste artigo, podemos concluir que a observabilidade é essencial para a saúde e a performance das nossas aplicações. Deixamos aqui também alguns links úteis para que os nossos leitores possam dar continuidade aos seus estudos sobre este tema essencial para profissionais de tecnologia.

Potencialize o desenvolvimento da sua IaC com terraform console

Ana Carolina Manzan — Wed, 14 Aug 2024 01:24:47 +0000

Olá dev!

Se você é usuário do Terraform, provavelmente já utilizou as funções built-in da ferramenta, como por exemplo concat, map e format.

Enquanto utilizava alguma delas, você já se perguntou qual seria o resultado da função ou até mesmo gostaria de testá-la antes de incorporá-la ao seu código? Se sim, hoje estou aqui para te mostrar como você pode testar essas funções de maneira prática usando o próprio CLI do Terraform!

O comando terraform console

É através do comando terraform console, que, nos fornecendo um console interativo, poderemos testar as funções.

Para começar, inicie seu terminal e digite terraform console e pressione enter. Após executar o comando, o prompt do console será imediatamente disponibilizado. Começaremos testando a função max(8,5,42,12) com uma lista de valores como no exemplo abaixo:

Neste simples teste, validamos que utilizando a função max com o input 8, 5, 42, 12 obteremos o resultado 42, o maior número presente nesta lista.

Em outro cenário, com a função split(“,”, “Testing,terraform,functions”) teremos o nosso texto dividido a cada vírgula, e transformado em uma lista de palavras, como na imagem abaixo:

Em resumo: além do output, o terraform console também nos informa qual o formato do mesmo, como podemos ver acima com a lista representada pelo tolist([...]).

Interação com arquivos

Mais do que apenas testar funções, ainda podemos utilizar o terraform console para interagir com arquivos Terraform.

Para exemplificar, criei um arquivo variables.tf no diretório onde estou realizando os testes, e nele incluí a declaração de uma variável chamada cidr, como na imagem a seguir:

Na variável configurei o valor padrão de 10.1.0.0/16, pois com ela quero calcular endereços de sub-rede; Para calcular esses endereços, vou utilizar a função cidrsubnet.

Quero aproveitar e trazer junto ao exemplo uma forma diferente de utilizarmos o terraform console. Para isso, vou utilizá-lo adicionando um pipe após a chamada da função desejada:

echo '[for i in range(1, 5) : cidrsubnet(var.cidr, 8, i)]' | terraform console

E ao executar o código acima, obteremos o resultado como no exemplo abaixo:

Conclusão

O terraform console pode se transformar em uma ferramenta valiosa em nosso dia-a-dia, à medida em que nossa infraestrutura cresce. Ele é um poderoso aliado quando precisamos garantir que o código que estamos desenvolvendo produzirá os resultados que esperamos.

Espero que o conteúdo tenha te ajudado, e se você gostou do post deixe o seu comentário ou venha bater um papo comigo no LinkedIn.

Até mais 👋