Azure Service Bus

visão geral, CLI , processo de Autenticação

Os sistemas se multiplicam muito rapidamente, percebemos rápido que é mais simples começar um pequeno sistema do zero do que adicionar novas funcionalidades à um sistema existente, os micro serviços tentam dar conta dessa constatação com alguma ordem, mas desenhar sistemas com baixo acoplamento é um grande desafio. Essa estratégia gera muitos benefícios como diluição dos riscos de downtime, manutenção e evolução em sistemas mais simples e focados, independência de tecnologia etc, ma não podemos deixar de lembrar que esses sistemas, precisam se comunicar , precisam trocar informações entre eles e isso definitivamente não deveria ser feito usando seu banco de dados.

As mensagens são uma forma interessante de trocar informações entre sistemas, e o Azure oferece um produto de mensageira sob protocolo AMQP/JMS totalmente gerenciado capaz de nos ajudar a resolver essa demanda, tirando o máximo de proveito da estratégia de PASS, um barramento de serviços como plataforma é algo realmente poderoso, e pode resolver diversos dos nossos problemas de integrações entre sistemas.

fiz um Post no passado sobre Rabbitmq de uma olha e faça comparações, os dois implementam o mesmo protocolo AMQP

Filas

As filas oferecem entrega de mensagem do tipo FIFO (primeiro a entrar, primeiro a sair) para um ou mais consumidores concorrentes. Ou seja, os receptores geralmente recebem e processam mensagens na ordem em que foram adicionados à fila. E, somente um consumidor de mensagem recebe e processa cada mensagem.

Tópicos

Os tópicos e as assinaturas fornecem uma forma de comunicação de um para muitos, em um padrão de publicação e assinatura. É útil para dimensionar para um grande número de destinatários.

Assinaturas

As assinaturas podem usar filtros adicionais para restringir as mensagens que desejam receber. Os editores enviam mensagens para um tópico da mesma forma que enviam mensagens para uma fila. No entanto, os consumidores não recebem mensagens diretamente do tópico. Em vez disso, os consumidores recebem mensagens de assinaturas do tópico.

saiba mais

Gerenciando suas instâncias do Azure Service Bus com Azure CLI

O Azure CLI é uma forma genial para gerenciar os recursos do Azure, com ele podemos usar uma série de comando criados exclusivamente para cada recurso do Azure para automatizar sua gestão, mas para isso precisamos de um básico de como logar, trocar assinatura, verificar qual a assinatura corrente etc.

Instalar a CLI do Azure para Windows

Comandos básicos

Abaixo vou listar os principais comandos para gerenciar instâncias do Azure Service Bus por meio do CLI, para isso vou utilizar os seguintes parâmetros

1. Grupos de Recursos: pocs
2. Instância Principal: seed-bus-p
3. Instância Secundaria: seed-bus-s
4. Nome da Fila: queueSampleSeed
5. Nome do Tópico: topicSampleSeed
6. Assinatura: consumer1

Criar uma instância Standard

Mensagens até 256 KB , sem escala automática e sem recuperação de desastre geográfico, para saber mais sobre limites do Azure service bus Clique aqui

1. Criar uma instância standard, no oeste dos estados unidos, chamada seed-bus-p com duas tags departamentoA e Company

az servicebus namespace create --resource-group pocs --name seed-bus-p --location westus --tags tag1=departamentoA tag2=Company --sku Standard

Criar Filas, Tópicos e Assinaturas

1. Criar uma Fila (FIFO) para as instâncias seed-bus-p, chamado queueSampleSeed

az servicebus queue create --resource-group pocs --namespace-name seed-bus-p --name queueSampleSeed

podemos usar o parâmetro;

--enable-dead-lettering-on-message-expiration true

Para habilitar um fila de erros de mensagens que não puderam ser entregues para nenhum receptor.

2. Criar um Tópico

az servicebus topic create --resource-group pocs --namespace-name seed-bus-p --name topicSampleSeed

3. Criar uma Assinatura da instância seed-bus-p, tópico topicSampleSeed chamada consumer1

az servicebus topic subscription create --resource-group pocs --namespace-name seed-bus-p --topic-name topicSampleSeed --name consumer1

Montando instância Premium com GEO-DR

Mensagens até 1 MB, fila de até 80 GB, com Escala automática e com recuperação de desastre geográfico

1. Criar uma instância Premium, no oeste dos estados unidos, chamada seed-bus-p com duas tags departamentoA e Company

az servicebus namespace create --resource-group pocs --name seed-bus-p --location westus --tags tag1=departamentoA tag2=Company --sku Premium

2. Criar uma segunda instância Premium, no sul do Brasil, chamada seed-bus-s com duas tags departamentoB e Company

az servicebus namespace create --resource-group pocs --name seed-bus-s --location brazilsouth --tags tag1=departamentoB tag2=Company --sku Premium

3. Criar uma Aliais que gera um terceiro endereço para ser usado como ponto centralizador

az servicebus georecovery-alias set --resource-group pocs --namespace-name seed-bus-p --alias seed-bus-a --partner-namespace seed-bus-s

Migração Standard para Premium

1. Começa a migração

az servicebus migration start --resource-group pocs --name seed-bus-p --target-namespace seed-bus-s --post-migration-name mypostmigrationname

3. Visualizar migrações em andamento

az servicebus migration show --resource-group pocs --name seed-bus-p

2. Finaliza

az servicebus migration complete --resource-group pocs --name seed-bus-p

Depois de migrar, devemos deletar a instância antiga, todas as configurações foram levadas para a nova instância inclusive o endpoint e connection strings

az servicebus namespace delete --ids "/subscriptions/<subscriptionId>/resourceGroups/pocs/providers/Microsoft.ServiceBus/namespaces/seed-bus-p"

Desmontar Estrutura de GEO-DR

1. Quebrar vínculo

az servicebus georecovery-alias break-pair --resource-group pocs --namespace-name seed-bus-p --alias seed-bus-a

2. Deleta o Aliais

az servicebus georecovery-alias delete --resource-group pocs --namespace-name seed-bus-p --alias seed-bus-a

3.Basta deletar as instâncias

az servicebus namespace delete --ids "/subscriptions/<subscriptionId>/resourceGroups/pocs/providers/Microsoft.ServiceBus/namespaces/seed-bus-s"

Scaling

az servicebus namespace update --resource-group pocs --name seed-bus-p --capacity 2

ARM Azure Resource Manager

Podemos exportar a configuração de uma recurso em um arquivo json, com um padrão conhecido como ARM templates, para isso podemos listar os itens de um grupo de recursos e então encontrar o que queremos exportar;

1. Listar

az resource list --resource-group "pocs"

2. Exporta o arm template da instância seed-bus-p

az group export --resource-group "pocs" --resource-ids "/subscriptions/<subscriptionId>/resourceGroups/pocs/providers/Microsoft.ServiceBus/namespaces/seed-bus-p"

para salvar isso em um arquivo *.json

az group export --resource-group "pocs" --resource-ids "/subscriptions/<subscriptionId>/resourceGroups/pocs/providers/Microsoft.ServiceBus/namespaces/seed-bus-p" >> seed-bus-p-template.json

para executar a implantação do template

az deployment group create -g "pocs" -n "myDeploy"  --template-file 'seed-bus-p-template.json'  --parameters p_name=seed-bus-r p_location=brazilsouth p_sku=Standard

Perceba que estamos passando alguns parâmetros na linha de comando;

1. p_name
2. p_location
3. p_sku

Por padrão a exportação gera apenas um parâmetro podemos ver o parâmetro nesse exemplo;

"parameters": {
   "namespaces_seed_bus_p_name": {
     "type": "String"
   }
}

mas podemos configurar da forma que acharmos melhor;

"parameters": {
 "p_name": {
   "type": "String"
 },
 "p_location": {
   "type": "String",
   "defaultValue": "brazilsouth"
 },
 "p_sku": {
   "type": "String",
   "defaultValue": "Standard"
 }
}

no corpo do template usamos assim

"sku": {
 "name": "[parameters('p_sku')]",
 "tier": "[parameters('p_sku')]"
},

exemplo completo;

Para saber mais sobre modelo Azure Resource Mananger para o service bus, clique aqui

Usando Key Vault em uma aplicação Produtora de Mensagens e tópicos

Para acessar informações seguras com key Vault, em uma aplicação .net core vamos precisar de alguns pacotes nuget comuns para o key vault e para Identidade de acesso;

Azure.Identity
Azure.Security.KeyVault.Keys
Azure.Security.KeyVault.Secrets
Microsoft.Azure.KeyVaul

Método que obtém as chave ServiceBusCns do Key Vault, utilizando a chave EnvironmentCredential para passar as credenciais de acesso por meio de variáveis de ambiente.

Definição de variáveis de ambiente para processo de Debug no próprio Visual Studio

O usuário conectado é usado para se autenticar no cofre de chaves, que é o método preferencial para o desenvolvimento local. Para os aplicativos implantados no Azure, a identidade gerenciada deve ser atribuída ao serviço de aplicativo para saber mais sobre identidades gerenciadas clique aqui

Observe que existe configurações que vem do arquivo *.json, esse recurso permite que utilizemos informações sensíveis durante do desenvolvimento empregando a estratégia de user secrets , e também durante os processos de implantação com as funcionalidades de Application and Configuration Settings dos pipes do azure devops

Os códigos acima são dois exemplos que atendem o mesmo propósito, obter uma chave do key vault chamada ServiceBusCns, essa chave foi obtida na instância do Azure Service Bus no menu Settings, item de menu Shared Access policies, e depois cadastrada no key vault como um secret, esse tipo de procedimento é muito bom pois centraliza em apenas um ponto de manutenção a chave de acesso ao barramento de serviços, mas existem alguns problemas que vou descrever abaixo.

Controle de acesso baseado em função do Azure

Uma outra forma de controlar o acesso ao barramento de serviços é trabalhar com RBAC

Quando usamos uma configuração como a Connectionstring de algum recurso , toda vez que recriamos o recurso essa connectionstring muda. Podemos pensar que basta trocar seu valor na aplicação e tudo vai começar a utilizar esse valor imediatamente, infelizmente isso pode não acontecer em todos os cenários causando a necessidade de reiniciar a aplicação alem de transtornos de novos deploys.

Por exemplo a Connectionstring é setada na classe ServiceBusClient que em muitas vezes pode ser instanciada apenas uma vez no ciclo de vida em uma aplicação produtora ou consumidora de mensagens, então para que a alteração seja lida no aplicativo que pretende acessar o Service Bus é preciso que essa instância seja recriada.

O problema descrito acima pode ser um inconveniente, mas pode ser resolvido com o uso do RBAC saiba mais aqui

Com o RBAC criamos uma aplicação no Azure AD e assim podemos centralizar o controle da Credencial nela e não mais na intancia do ServiceBus, podemos usar o RBAC para dar permissões a uma entidade de segurança, que pode ser um usuário, um grupo ou uma entidade de serviço de aplicativo. A entidade de segurança é autenticada pelo Azure AD para retornar um token OAuth 2.0. O token pode ser usado para autorizar uma solicitação para acessar um recurso do Barramento de Serviço (fila, tópico e assim por diante).

O primeiro passo é registrar uma aplicação no AD , usando o App Registrations, depois na instanciá do Service Bus no portal do Azure, devemos clicar em Access Control(IAM), Role assignments e adicionar. Agora escolhemos qual Role (Azure Service Bus Data Owner/ Azure Service Bus Data Contributor / Azure Service Bus Data Reciver/ Azure Service Bus Data Sender) desejamos aplicar para essa aplicaão.

Podemos fazer esse processo na instancia inteira ou apenas em uma fila.

A classe ServiceBusClient recebe uma instância de ClientSecretCredential permitindo que criemos uma representação do aplicativo a ser autorizado por meio do fluxo OAuth2 conhecido como Client Credencial. isso é interessante pois podemos controlar o acesso ao Service bus sem a connection string. Assim podemos criar um ARM Template que já seja implantando com essa permissão atribuída, agilizando o processo.

Role: Azure Service Bus Data Owner/ Azure Service Bus Data Contributor / Azure Service Bus Data Reciver/ Azure Service Bus Data Sender

Assign access to: User group,or servivce principal

Select: nome da aplicação registrada no diretório

o código completo para uma aplicação produtora de mensagens e tópicos está no github

mas só por curiosidade segue uma palhinha, depois que obtemos um client autenticado com a classe ServiceBusClient basta criar um sender seja para filas ou para tópicos;

senderQueue = client.CreateSender(queueName);
senderTopic = client.CreateSender(topicName);

depois podemos mandar uma mensagem ou um lote de mensagens

await senderQueue.SendMessagesAsync(messageBatch);
await senderTopic.SendMessagesAsync(messageBatch);

veja um método completo para envio de mensagens;

código original docs da Microsoft

Referencia

1. https://docs.microsoft.com/pt-br/azure/service-bus-messaging/
2. https://docs.microsoft.com/pt-br/cli/azure/servicebus?view=azure-cli-latest
3. https://docs.microsoft.com/en-us/azure/service-bus-messaging/authenticate-application
4. https://docs.microsoft.com/pt-br/azure/service-bus-messaging/service-bus-managed-service-identity
5. https://docs.microsoft.com/pt-br/azure/service-bus-messaging/service-bus-quotas