Deployment: Implantando um microsserviço Devprime no Azure Kubernetes Services (AKS)

Mon, 01 Jan 0001 00:00:00 +0000

Introdução

A plataforma Devprime acelera a produtividade do desenvolvedor de software, oferecendo um projeto completo de arquitetura de software, componentes com comportamentos inteligentes, aceleradores para implementação de código e atualizações com novos recursos.

Neste artigo, abordaremos o uso do serviço Azure Kubernetes Service (AKS), uma plataforma de cloud que oferece diversos recursos para o desenvolvedor de software utilizar nas aplicações.

Nós utilizaremos dois microsserviços com uma regra de negócio relacionada a pedidos e outra a pagamentos utilizando o banco de dados MongoDB baseado no Azure CosmosDB gerenciado pela Microsoft. Demonstraremos os passos para criar o microsserviço, os serviços de cloud no Azure Kubernetes Service (AKS), Azure Container Registry, MongoDB e implantaremos o RabbitMQ dentro do Kubernetes, em seguida, as configurações iniciais necessárias.

Checklist e preparação do ambiente inicial

Abra uma conta na plataforma Devprime e adquira uma licença (Developer/Enterprise).
Instale uma versão atualizada do .NET (Linux, macOS e Windows).
Instale e/ou atualize o Visual Studio Code e/ou o Visual Studio 2023 Community / Professional / Enterprise.
Instale e/ou atualize o Docker (Linux, macOS e Windows) (Para Windows, utilize o WSL2).
Inicialize localmente os containers do MongoDB e RabbitMQ no Docker e adicione a fila ‘orderevents’ e ‘paymentevents’ no RabbitMQ.
Instale e ative a versão mais nova do Devprime CLI.
Crie uma pasta local para os seus projetos e defina as permissões de leitura e gravação.
Consulte o artigo “Criando o primeiro microsserviço” para explorar os primeiros passos na plataforma Devprime.
Uma conta ativa no Microsoft Azure.
O Azure CLI instalado e ativo no ambiente local.
Criar uma conta no Azure CosmosDB e obter as credenciais de conexão.
Criar uma conta no Azure Event Hubs e obter as credenciais de conexão.

Primeiros passos

Neste artigo, utilizaremos um projeto com dois microsserviços utilizando comunicação assíncrona, sendo o primeiro Order e o segundo Payment que você pode optar por criar do zero ou utilizando o exemplo no GitHub.

a) Execute um clone do projeto no GitHub:
git clone https://github.com/devprime/devprime-microservices-order-payment.git

b) Acesse a pasta clonada e verifique a pasta inicial com os itens Order e Payment. Cada pasta desta tem um microsserviço desenvolvido com a plataforma Devprime e pronto para utilização.
cd devprime-microservices-order-payment
git remote remove origin

c) Execute o comando dp stack para aplicar atualização e a sua licença Devprime:
dp stack

d) Execute cada microsserviço em uma aba do terminal para testar localmente utilizando os arquivos .\run.ps1 no Windows ou run.sh no Linux e macOS. Aplique a permissão chmod no Linux, macOS.
chmod +x run.sh

Inicie o microsserviço executando um dos scripts abaixo:
.\run.ps1 (Windows) ou ./run.sh (Linux, macOS)

/ms-order
/ms-payment

Com os microsserviços rodando efetue um post na API do microsserviço order e acompanhe o processamento no microsserviço payment conforme descrito no artigo sobre comunicação assíncrona entre microsserviços.

Analisando a porta padrão no Dockerfile e na configuração do App

Os microsserviços desenvolvidos utilizando a plataforma Devprime são implementados automaticamente com um arquivo Dockerfile na pasta do projeto que deve ser configurado caso deseje modificar a porta interna para receber requests. Caso deseje modificar para 8080 ou outro valor, você deverá alterar no Dockerfile e também na configuração da aplicação.

Analisando a porta padrão no arquivo Dockerfile
Abra pelo Visual Studio Code:

`1`	`code ./Dockerfile`

# Step 1
FROM mcr.microsoft.com/dotnet/aspnet:8.0.6-jammy AS base
WORKDIR /app
EXPOSE 80

Analisando a porta padrão no arquivo AppSettings
Abra pelo Visual Studio Code:

`1`	`code .\src\App\appsettings.json`

{
  "DevPrime_Web": {
    "url": "http://*:80",
    "enable": "true",
    "enableswagger": "true",
    "PostSuccess": "201",
    "PostFailure": "500",
    "GetSuccess": "200",
    "GetFailure": "500",
    "PatchSuccess": "200",
    "PatchFailure": "500",
    "PutSuccess": "200",
    "PutFailure": "500",
    "DeleteSuccess": "200",
    "DeleteFailure": "500",
    "EnableWebLegacy": "false",
    "EnableStaticFiles": "true",
    "ShowHttpRequests": "false",
    "ShowBadRequestDetails": "false"
  }
}

IMPORTANTE:

O valor da porta exposta no Dockerfile tem que ser igual ao valor da porta configurada na chave DevPrime_Web enviada como environment para o Azure Kubernetes Service (AKS).
Caso modifique o Dockerfile é necessário publicar uma nova imagem no Azure Container Registry (ACR).

Criando o Azure Container Registry (ACR)

Nós utilizaremos o Azure Container Registry (ACR) para repositório de imagens docker privadas. Você pode acessar o portal do Azure e criar um novo repositório privado ou, se preferir, utilizar o Azure CLI e outras estratégias para provisionar os recursos.

Entre no portal e crie um novo Container Registry. No exemplo, nós utilizamos o nome de “devprimeregistry” e avançamos até ativar o serviço.

Após criar o ACR, localize o item “Settings > Access keys” e ative a opção “Admin user” para obter a credencial que será utilizada para se conectar ao serviço do Azure Container Registry (ACR) e realizar a publicação de uma imagem.

Na tabela abaixo, é apresentado um resumo das informações necessárias para conexão ao serviço do Azure Container Registry (ACR). É importante lembrar que você deve obter os dados no seu portal do Azure.

Chave	Valor
Server	devprimeregistry.azurecr.io
Registry	devprimeregistry
Username	devprimeregistry
Password	2t44H70qmRDGdBCo

Criando um cluster Azure Kubernetes Service (AKS)

A criação de um novo cluster Kubernetes no Azure Kubernetes Service (AKS) pode ser realizada pelo portal, CLI e ferramentas de mercado como Bicep, Terraform, entre outras. Um passo importante na criação do cluster é definir o primeiro nó do cluster e a quantidade de réplicas. Em nosso artigo, utilizaremos um exemplo conceitual com o objetivo de apresentar o roteiro básico.

Acesse o portal do Azure e inicie a criação de um novo serviço

Após avançar localize a aba “Integration” e vincule nesse momento o Azure Container Registry (ACR) ao Azure Kubernetes Services (AKS) isso vai facilitar a implantação dos continers no AKS por usando as credenciais integradas.

Ao avançar na aba monitoring você pode desativar todos os itens sugeridos, pois não são necessários para essa demonstração.

Instalando ferramentas para utilização no Kubernetes

Nós utilizaremos algumas ferramentas para integração com o Kubernetes como o kubectl, que é o CLI do Kubernetes, Helm, ferramenta para instalar pacotes no Kubernetes, K9S ferramenta para visualizar o cluster, Stern, ferramenta para visualizar logs no Kubernetes, Azure CLI, Azure Command-Line Interface (CLI) e Docker. Algumas dessas ferramentas podem ser instaladas por meio de gerenciadores de pacote conforme o sistema operacional.

Após instalar o Azure CLI, é fundamental seguir os procedimentos de configuração do mesmo para ativar o acesso ao e habilitar as operações como obteção de credenciais do Azure Kubernetes Service (AKS).

Checklist:

Ativando o Azure CLI
az login
Ativando o Docker
docker login
Ativando o Devprime CLI
dp auth

Obtendo acesso ao Azure Kubernetes Services (AKS)

As credenciais de acesso ao cluster Kubernetes podem ser obtidas utilizando o Azure CLI, conforme faremos durante este artigo. Ao executar o comando get-credentials, as credenciais de acesso ao cluster serão salvas no ambiente local no arquivo .kube/config. No exemplo, passamos o nome do serviço AKS criado, “devprime-aks-devtest”, e o grupo de recursos vinculado, “devprime-aks-devtest_group”.

Exxecute o comando no prompt

`1`	`az aks get-credentials -n devprime-aks-devtest -g devprime-aks-devtest_group`

Listando todos os pods do Cluster

`1`	`kubectl get pods --all-namespaces`

Utilizando o k9s para visualizar o Cluster

`k9s`

Na imagem estamos listando todos os containers ativos implantados na criação do cluster.

Nos próximos passos iniciaremos a criação do container do order e do payment.

Criando imagens Docker e publicando no Azure Container Registry (ACR)

Um passo importante no cenário do Kubernetes é construir a imagem Docker dos nossos microsserviços para que possamos realizar a publicação dentro do ambiente do Cluster Kubernetes. Agora chegou o momento de utilizar o Azure CLI ou “az” para efetuar login no Azure Container Registry criado no passo anterior e permitir realizar o envio de imagens docker do seu ambiente local para o ACR. Antes de avançar, certifique-se de que você tem o Azure CLI ativado (az login) no seu ambiente.

Autenticando o Docker no Container Registry

`1`	`az acr login -n devprimeregistry -u devprimeregistry -p SvL8zP1ZXXwhLgtsc3S7`

Construindo a imagem do microsserviço order no Docker

Entre na pasta do microsserviço order e execute
cd ms-order
docker build -t order .
Crie uma tag para essa imagem
docker tag order devprimeregistry.azurecr.io/order:latest
Efetuando o push enviando para o Docker
docker push devprimeregistry.azurecr.io/order:latest

Construindo a imagem do microsserviço payment no Docker

Entre na pasta do microsserviço payment e execute
cd ms-payment
docker build -t payment .
Crie uma tag para essa imagem
docker tag payment devprimeregistry.azurecr.io/payment:latest
Efetuando o push enviando para o Docker
docker push devprimeregistry.azurecr.io/payment:latest

Ao final desse procedimento de push nas imagens do order e payment será possível conferir no portal do Container Registry e já estão prontas para utilização no Kubernetes.

Implantando o RabbitMQ no Kubernetes

A plataforma Devprime habilita a conectividade com diversos serviços de Stream com RabbitMQ, Kafka e outros e nesse projeto nós vamos utilizar o helm para implantar o RabbitMQ no cluster. Você pode optar a depender do cenário no seu projeto em utilizar o serviço de Kafka gerenciado oferecido pela pelo Azure Event Hubs ou outra alternativa para comunicação entre os microsserviços.

Implantando o RabbitMQ utilizando o Helm. Altere o usuário e senha a seu critério.
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm install rabbitmq bitnami/rabbitmq --set auth.username=admin --set auth.password=MQ@passX6DP

O processo de implantação do RabbitMQ demora um certo tempo até concluir e você pode acompanhar pelo K9S. Após a instalação você pode mapear as portas do RabbitMQ no ambiente local para acessar. Antes de realizar o mapemaento é fundamental parar o container local do RabbiMQ para evitar conflitos de portas TCP.

Portas do RabbitMQ

RabbitMQ AMQP port:
kubectl port-forward --namespace default svc/rabbitmq 5672:5672
RabbitMQ Web Management interface:
kubectl port-forward --namespace default svc/rabbitmq 15672:15672

Definindo a configuração inicial do RabbitMQ
Efetue o mapeamento da porta 15672 e acesse o portal administrativo do RabbitMQ pela url http://localhost:15672 para configurar as filas ‘orderevents’ e ‘paymentevents’ no RabbitMQ e relacione com a “exchange” conforme a documentação do RabbitMQ na Devprime com o objetivo de habilitar esse artigo.

Analisando as credenciais do MongoDB e RabbitMQ nos microsserviços ambientes locais

No ambiente local, você pode editar as configurações e credenciais da aplicação no arquivo src/App/appsettings.json, como os dados de acesso ao MongoDB e ao RabbitMQ utilizados no projeto e outros itens disponiveis na documentação de configuração da Devprime.

Para abrir a configuração de cada microsserviço entre na pasta relacionada
ms-order
ms-payment

Abra pelo Visual Studio Code ou outro editor
code src/App/appsettings.json

Visualiuze na chave RabbitMQ e do MongoDB as credenciais do utilizadas no ambiemte local e podem ser modificadas a qualquer momento.

  "DevPrime_Stream": [
    {
      "Alias": "Stream1",
      "Enable": "true",
      "Default": "true",
      "StreamType": "RabbitMQ",
      "HostName": "Localhost",
      "User": "guest",
      "Password": "guest",
      "Port": "5672",
      "Exchange": "devprime",
      "ExchangeType": "direct",
      "Retry": "3",
      "Fallback": "State1",
      "Threads": "30",
      "Buffer": "1",
      "Subscribe": []
    }
  ],

  "DevPrime_State": [
    {
      "enable": "true",
      "alias": "State1",
      "type": "db",
      "dbtype": "mongodb",
      "connection": "mongodb://mongoadmin:LltF8Nx*yo@localhost:27017",
      "timeout": "5",
      "retry": "2",
      "dbname": "ms-order",
      "isssl": "true",
      "durationofbreak": "45"
    }
  ],

Configurando as credenciais do MongoDB e RabbitMQ no Kubernetes

Em nosso contexto, criaremos um arquivo de deployment para cada microsserviço e utilizaremos o DevPrime CLI para construir os arquivos iniciais deployment.yml e service.yml. Para isso, executaremos o comando na pasta de cada microsserviço. Em seguida, realizaremos a configuração com as credenciais que utilizaremos nos microsserviços order e payment dentro do cluster Kubernetes.

Entre na pasta ms-order e execute o comando
dp export kubernetes

Entre na pasta ms-payment e execute o comando
dp export kubernetes

O resultado será similar ao trecho abaixo, com dois arquivos criados contendo as configurações iniciais necessárias para a publicação no Kubernetes. Observe que foram gerados um arquivo deployment.yml e um arquivo service.yml.

 ____             ____       _
|  _ \  _____   _|  _ \ _ __(_)_ __ ___   ___
| | | |/ _ \ \ / / |_) | '__| | '_ ` _ \ / _ \
| |_| |  __/\ V /|  __/| |  | | | | | | |  __/
|____/ \___| \_/ |_|   |_|  |_|_| |_| |_|\___|
  Empower developers. Accelerate productivity
==============================================
Welcome to the DevPrime CLI v8.0.8

Export configurations kubernetes

.devprime/kubernetes/deployment.yml' created
.devprime/kubernetes/service.yml' created

Agora chegou o momento de editar o arquivo “deployment.yml”. Localize
o item “image” na pasta do order e na pasta do payment.

Abra a pasta no Visual Studio Code ou outro editor
code .devprime/kubernetes/deployment.yml

Arquivo: deployment.yml

apiVersion : apps/v1
kind: Deployment
metadata:
  name: ms-order
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ms-order
  template:
    metadata:
      labels:
        app: ms-order
    spec:
      containers:
        - name: ms-order 
          image: ms-order:latest

Realize o procedimento para cada microsserviço (order / payment) e altere o item image para o path da sua imagem no Azure Container Registry. A url do Azure Container Registry é a mesma utilizada pelo comando push do docker.

Execute na pasta ms-order
code .devprime/kubernetes/deployment.yml

1
2
3

      containers:
        - name: ms-order 
          image: devprimeregistry.azurecr.io/order:latest

Execute na pasta ms-payment
Arquivo: payment/deployment.yaml

1
2
3

      containers:
        - name: ms-payment 
          image: devprimeregistry.azurecr.io/payment:latest

Agora chegou um momento de configurar em cada microsserviço as credenciais de produçao do RabbitMQ e do
MongoDB fornecidas pela Microsoft Azure Cosmos Db. Localize o bloco abaixo no arquivo deployment.yaml

code .devprime/kubernetes/deployment.yml

         env:
           - name: devprime_stream1
             value: "alias=Stream1|||enable=true|||default=true|||streamtype=RabbitMQ
        |||hostname=rabbitmq.default.svc|||user=admin|||password=guest|||port=5672|||
             exchange=devprime|||exchangetype=direct|||retry=3|||fallback=State1|||
             threads=30|||buffer=1"
           - name: devprime_state1
             value: "enable=true|||alias=State1|||type=db|||dbtype=mongodb|||
             connection=mongodb.default.svc|||timeout=5|||retry=2|||
             dbname=ms-order|||isssl=true|||durationofbreak=45"

No item devprime_stream1 altere o usuário para “admin” e a senha para “MQ@passX6DP”.
no item devprime_state1 altere a connection pela Connection String do MongoDB na Microsoft Azure Cosmos Db.

Abaixo é possível conferir um exemplo após as alterações que devem ser feitas nos arquivos de deployment dos microsserviços (order/payment). Faça a alteração diretamente em cada arquivo para evitar modificar outros parâmetros nessa demonstração, pois as chaves têm pequenas diferenças entre os microsserviços.

Execute na pasta ms-order
code .devprime/kubernetes/deployment.yml

         env:
           - name: devprime_stream1
             value: "alias=Stream1|||enable=true|||default=true|||streamtype=RabbitMQ|||
             hostname=rabbitmq.default.svc|||user=admin|||password=MQ@passX6DP|||
             port=5672|||exchange=devprime|||exchangetype=direct|||retry=3
             |||fallback=State1|||threads=30|||buffer=1"
           - name: devprime_state1
             value: "enable=true|||alias=State1|||type=db|||dbtype=mongodb|||
             connection=mongodb://devprime-cosmosdb:bashjqHel@devprime-cosmosdb.mongo.cosmos.azure.com:10255
             /?ssl=true&retrywrites=false&replicaSet=globaldb&
             maxIdleTimeMS=120000&appName=@devprime-cosmosdb@|||timeout=5|||
             retry=2|||dbname=order|||isssl=true|||durationofbreak=45"
           - name: Devprime_Custom

Execute na pasta ms-payment
code .devprime/kubernetes/deployment.yml

         env:
           - name: devprime_stream1
             value: "alias=Stream1|||enable=true|||default=true|||streamtype=RabbitMQ|||hostname=rabbitmq.default.svc|||user=admin|||password=MQ@passX6DP|||port=5672|||exchange=devprime|||exchangetype=direct|||retry=3|||fallback=State1|||threads=30|||buffer=1|||subscribe=[queues=orderevents]"
           - name: devprime_state1
             value: "enable=true|||alias=State1|||type=db|||dbtype=mongodb|||
             connection=mongodb://devprime-cosmosdb:bashjqHel@devprime-cosmosdb.mongo.cosmos.azure.com:10255
             /?ssl=true&retrywrites=false&replicaSet=globaldb&
             maxIdleTimeMS=120000&appName=@devprime-cosmosdb@|||timeout=5|||
             retry=2|||dbname=payment|||isssl=true|||durationofbreak=45"
           - name: Devprime_Custom

Executando o deployment dos microsserviços no Kubernetes

Agora chegou o momento mais esperado, onde iremos publicar efetivamente os microsserviços (order e payment) dentro do cluster Kubernetes e para isso utilizaremos os arquivos deployment.yml e service.yml de cada microsserviço.

Entre em cada pasta e execute os comandos abaixo:

Para o microsserviço order
- Navegue até a pasta do Kubernetes do serviço order:
  ms-order/.devprime/kubernetes
- Aplique o deployment e o serviço:
  kubectl apply -f deployment.yml
  kubectl apply -f service.yml
Para o microsserviço ayment
- Navegue até a pasta do Kubernetes do serviço payment:
  ms-payment/.devprime/kubernetes
- Aplique o deployment e o serviço:
  kubectl apply -f deployment.yml
  kubectl apply -f service.yml

Agora que terminamos de efetuar o nosso deployment dos dois microsserviços, podemos visualizar diretamente no cluster pela ferramenta k9s ou utilizando o kubectl.

Efetuando um teste no microsserviço

Abra uma aba do terminal e execute o comando port-forward para mapear o microsserviço order na porta local 8080 e permitir realizar o primeiro teste acessando a plataforma diretamente no cluster.

Execute o comando para o Order
kubectl port-forward --namespace default svc/ms-order 8080:80
Acesse a URL e efetue um POST no microsserviço order para que processe e emita um evento na fila do RabbitMQ e propague para o microsserviço payment
http://localhost:8080

Atribuindo um IP público ao microsserviço order

Nós vamos alterar o services para alterar de um ip interno no parametro “ClusterIP” para “LoadBalancer” que utilizará um ip público do cluster.

Entre na pasta order e execute o comando para abrir Visual Studio Code
code .devprime/kubernetes/service.yml

apiVersion: v1
kind: Service
metadata:  
  name: ms-order
spec:
  selector:    
    app: ms-order
  type: LoadBalancer
  ports:  
  - name: http
    port: 80
    targetPort: 80

Entre na pasta order abaixo e execute os comandos:
ms-order/.devprime/kubernetes

Excluindo o service do microsserviço order:
kubectl delete svc ms-order

Recriando o service ms-order:
kubectl apply -f service.yml

Agora consulte a atualização até receber um IP público no microsserviço order:
kubectl get svc ms-order -w

NAME       TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)        AGE
ms-order   LoadBalancer   10.0.175.19   48.x.x.x         80:31191/TCP   50m

Visualizando o microsserviço order usando um ip externo

Visualizando logs no Kuberbernetes

Os microsserviços baseados na plataforma Devprime disponibilizam uma abordagem de observabilidade automática de logs distribuídos que podem ser visualizados pelo kubectl, k9s, stern e indexados em ferramentas como SEQ, Elastic Search e muitas outras para acompanhar o comportamento das aplicações no ambiente produtivo.

Nesse exemplo, utilizaremos a ferramenta stern para visualizar o log de cada deployment:

Abra uma aba para o microsserviço ‘order’ no terminal e execute:
stern ms-order
Abra uma aba para o microsserviço ‘payment’ no terminal e execute:
stern ms-payment
Agora, utilize o mapeamento de porta ou IP público e realize um post no microsserviço ‘order’ para conferir um resultado. No log abaixo, você verá um resumo do ‘order’ como exemplo.

[INF][ms-order][Web]["http://*:80"][Host]["Production"][Parameters]["Environment"][RID 30c1c7a9-7799-43e6-a1b2-5d4007b3edb8][TID 30c1c7a9-7799-43e6-a1b2-5d4007b3edb8]
[INF][ms-order][Stream][Type "RabbitMQ"][Alias "Stream1"]["Enable"][RID 30c1c7a9-7799-43e6-a1b2-5d4007b3edb8][TID 30c1c7a9-7799-43e6-a1b2-5d4007b3edb8]
[INF][ms-order][Web]["HTTP"][Order][POST /v1/order][Origin "http://localhost/swagger/index.html"][RID c1461cc3-7000-473d-a62c-915867954ced][TID c1461cc3-7000-473d-a62c-915867954ced]
[INF][ms-order][Application][OrderService][Add][RID c1461cc3-7000-473d-a62c-915867954ced][TID c1461cc3-7000-473d-a62c-915867954ced]
[INF][ms-order][Domain][Order][Add][RID c1461cc3-7000-473d-a62c-915867954ced][TID c1461cc3-7000-473d-a62c-915867954ced]
[INF][ms-order][Domain][Order][ProcessEvent]["CreateOrder"][RID c1461cc3-7000-473d-a62c-915867954ced][TID c1461cc3-7000-473d-a62c-915867954ced]
[INF][ms-order][Application][EventHandler]["CreateOrderEventHandler"][Event]["CreateOrder"][RID c1461cc3-7000-473d-a62c-915867954ced][TID c1461cc3-7000-473d-a62c-915867954ced]
[INF][ms-order][State][Type "MongoDB"][Alias "State1"][Initialize][OrderRepository][Add][RID c1461cc3-7000-473d-a62c-915867954ced][TID c1461cc3-7000-473d-a62c-915867954ced]
[INF][ms-order][State][Type "MongoDB"][Alias "State1"][Complete][OrderRepository][Add][Duration 1192.1472ms][RID c1461cc3-7000-473d-a62c-915867954ced][TID c1461cc3-7000-473d-a62c-915867954ced]
[INF][ms-order][Domain][Order][ProcessEvent]["OrderCreated"][RID c1461cc3-7000-473d-a62c-915867954ced][TID c1461cc3-7000-473d-a62c-915867954ced]
[INF][ms-order][Application][EventHandler]["OrderCreatedEventHandler"][Event]["OrderCreated"][RID c1461cc3-7000-473d-a62c-915867954ced][TID c1461cc3-7000-473d-a62c-915867954ced]
[INF][ms-order][Stream][Type "RabbitMQ"][Alias "Stream1"][Out][Event]["OrderCreated"]["Delivered"]["orderevents"]
["{\""Payload\":{\"ID\":\"ca9983\",\"CustomerName\":\"Ramon Duraes\",\"CustomerTaxID\":\"AC875512\",\"Total\":1200}}"]

Considerações finais

Durante este artigo, demonstramos a publicação de dois microsserviços (order e payment) desenvolvidos utilizando a tecnologia da plataforma Devprime no cluster Azure Kubernetes Service (AKS), em conjunto com os serviços de Azure Container Registry e Azure CosmosDB usando a api MongoDB gerenciados e com o RabbitMQ que implantamos no cluster utilizando o Helm. Você acompanhou também como acessar o serviço utilizando um IP interno e um IP Externo e visualizar os logs.

Em um ambiente produtivo, é fundamental adicionar um nginx ingress, um dominio de internet e Let’s Encrypt para gerar um certificado SSL, utilizar um serviço de DevOps para automatizar a publicação, cofre digital para credenciais, proteção de acesso com um API Gateway, provedor de identidade e Web Application Firewall.

Devprime | Documentação – Azure Kubernetes Service (AKS)