Monday, April 18, 2022

Azure API Management com gateway auto-hospedado no AKS

Azure API Management com gateway auto-hospedado no AKS

 

O Azure API Management é uma solução completa que oferece um Gateway além de dois outros componentes que vão ajudá-lo a distribuir, documentar e manter suas APIs:

  1. Portal do Desenvolvedor
  2. Gateway
  3. Portal do Azure

Saiba mais sobre o APIM

A questão aqui é que o gateway pode ser hospedado em diferentes infraestruturas, esse recurso é chamado de gateway auto-hospedado. O gateway auto-hospedado implanta uma versão em contêiner do componente do gateway no mesmo ambiente que hospeda suas APIs.

Todos os gateways auto-hospedados são gerenciados a partir do portal do Azure, fornecendo uma experiência de gerenciamento unificada. Com isso podemos ter em um mesmo local todas as nossas APIs internas e externas, com gateways dedicados para as situações necessárias.

 

Cenários comuns

 

  1. Diminuir a latência e o tráfego de dados do gateway com o backend (API)
  2. Manter chamadas de APIs locais dentro da infraestrutura local
  3. Segregar custo computacional em diferentes hardwares

 

Vamos considerar o cenário abaixo

 

Cenário Clássico do APIM com apenas um gateway na nuvem.Cenário Clássico do APIM com apenas um gateway na nuvem.

 

Nesse cenário podemos perceber que as requisições sempre vão passar pelo gateway da nuvem, nesse caso o APIM está no sul do Brasil, assim como o backend https://api-sample-br.azurewebsites.net. Fica fácil deduzir que o backend https://api-sample-us.azurewebsites.net terá maior latência.

instância do APIM no Sul do Brasil.instância do APIM no Sul do Brasil.

 

Por padrão, todos esses componentes são implantados no Azure, centralizando o tráfego da API dentro da infra de nuvem, independentemente de onde os back-ends estejam hospedados.

Por padrão, todos esses componentes são implantados no Azure, centralizando o tráfego da API dentro da infra de nuvem, independentemente de onde os back-ends estejam hospedados.Por padrão, todos esses componentes são implantados no Azure, centralizando o tráfego da API dentro da infra de nuvem, independentemente de onde os back-ends estejam hospedados.

 

E se pudéssemos ter mais de um Gateway?

 

Podemos ter vários componentes de gateway.Podemos ter vários componentes de gateway.

 

Para resolver isso podemos criar um segundo gateway próximo do backend dos Estados Unidos. Podemos usar o serviço gerenciado do Kubernetes no Azure (AKS) criando o cluster também nos Estados Unidos.

Cluster AKS criado na região de East USCluster AKS criado na região de East US

 

Com a criação do Cluster AKS criado na região de East US, temos uma arquitetura de gateways distribuídos, tal como a imagem abaixo sugere.

O gateway auto-hospedado é uma versão em contêinerO gateway auto-hospedado é uma versão em contêiner

 

O gateway auto-hospedado é uma versão em contêiner

O gateway auto-hospedado está disponível como uma imagem de contêiner do Docker baseado em Linux do Microsoft Container Registry. Ele pode ser implantado no Docker, Kubernetes ou qualquer outra solução de orquestração de contêiner em execução em um cluster de servidor local, infraestrutura de nuvem ou para fins de avaliação e desenvolvimento, em um computador pessoal.

A implantação de gateways auto-hospedados nos mesmos ambientes das APIs permite que o tráfego flua diretamente para as APIs de back-end, o que reduz a latência, otimiza os custos de transferência de dados.

 

Restrições

 

Existem algumas restrições importantes para gateways auto-hospedados, principalmente no que diz respeito a certificados, veja a lista completa aqui

 

POC

 

Uma vez que entendemos o cenário vamos fazer uma POC, para isso vou usar vários comandos de CLI, começando com a CLI do AKS que precisa ser instalada. Também será preciso logar na conta do Azure usando a CLI do Azure e para isso use os comandos abaixo.

# Fazer login na conta do Azure
az login
az account set --subscription <id>
# Baixar a CLI do AKS
az aks install-cli
# Criar uma instancia do AKS em East US
az aks create --resource-group APIM --name cluster-apim-02 --node-count 1 --location "East US"
# Obter credenciais de acesso para um cluster Kubernetes gerenciado
az aks get-credentials --resource-group APIM --name cluster-apim-02

 

Como configurar o portal do Azure

 

Vamos acessar a instancia do APIM no portal do Azure e navegar até o menu gateway na lateral esquerda, dentro do grupo “Deployment + infrastructure” e então vamos adicionar um gateway novo.

Basta definir um nome, a região desejada, uma descrição e as APIs que esse gateway vai atender.

Adicionando um novo gateway, no use letras em maiúsculo, isso gera um erro na hora de aplicar o deployment no AKS.Adicionando um novo gateway, no use letras em maiúsculo, isso gera um erro na hora de aplicar o deployment no AKS.

 

Não use letras em maiúsculo, isso gera um erro na hora de aplicar o deployment no AKS.

Lembre-se que a região é apenas informativa, o que realmente importa é onde o recurso que vai hospedar o gateway foi implantado.

Podemos perceber pelo campo “Status” que antes do deploys (rodar os scripts), o gateway ainda não está respondendo.

Deployment gateway do APIM no KubernetesDeployment gateway do APIM no Kubernetes

 

Na aba Deployments dentro do gateway, podemos escolher entre Docker e Kubernetes, teremos os scripts de apoio para serem executados no nosso CLI, após rodar esses comandos veremos o gateway ativado.

Basicamente temos dois comandos, uma para gerar um token para o gateway e outro que vai aplicar o *.yaml de deployment no AKS.

kubectl create secret generic us-token --from-literal=value="XXX"
kubectl apply -f us.yaml

obs. precisa criar o arquivo us.yaml localmente com o conteúdo fornecido na aba deployment.

Gateway ativado.Gateway ativado.

 

Caso precise fazer a associação de outra APIS basta acessar a o menu APIS do gateway.

Associar APIS no gateway US.Associar APIS no gateway US.

 

O Básico de Kubernetes

 

O Kubernets é um orquestrador de containers, cada container é um ambiente isolado dentro de um agrupador maior chamado cluster. Um container nada mais é do que uma imagem em execução, as imagens empacotam as aplicações com tudo que elas precisam para rodar. A criação das imagens pode ser feita em diversas ferramentas, como o Docker, Podman, Containerd entre outras.

As imagem são usadas para realizar deploys no kubernetes, fazemos as configurados do deploy em arquivos *.yaml onde podemos definir o número de pods, limites de CPU, memória etc. O Kubernetes define um pod como a menor unidade implementável do cluster, algo replicável e volátil, ele é um conjunto de um ou mais containers e fica dentro do Node que representa a máquina virtual ou física.

Saiba mais aqui.

Agora que entendemos os conceitos principais, vamos testar alguns dos principais comandos do kubernetes para pegar detalhes do gateway auto-hospedado.

 

kubectl get pods  
kubectl get nodes  
kubectl get deployments  
kubectl get services  
kubectl get logs <nomedopod>

 

Listar logs do pod do gateway

 

$kubectl get pods
NAME                 READY   STATUS    RESTARTS   AGE
us-66d8d59cf-vrjfc   1/1     Running   0          10s


$kubectl logs us-66d8d59cf-vrjfc
WARNING: ca-certificates.crt does not contain exactly one certificate or CRL: skipping

(c) Microsoft Corporation. All rights reserved.

This software is licensed to you as part of your or your company's subscription license for Microsoft Azure Services.
You may only use the software with Microsoft Azure Services and subject to the terms and conditions of the agreement under which you obtained Microsoft Azure Services.
If you do not have an active subscription license for Microsoft Azure Services, you may not use the software.
See Microsoft Azure Legal Information: https://azure.microsoft.com/en-us/support/legal/

     __       __   ___          __                             __   ___        ___      ___
 /\   / |  | |__) |__      /\  |__) |     |\/|  /\  |\ |  /\  / _` |__   |\/| |__  |\ |  |
/~~\ /_ \__/ |  \ |___    /~~\ |    |     |  | /~~\ | \| /~~\ \__> |___  |  | |___ | \|  |

   ____           _    __           _   _                 _                _      ____           _
 / ___|    ___  | |  / _|         | | | |   ___    ___  | |_    ___    __| |    / ___|   __ _  | |_    ___  __      __   __ _   _   _
 \___ \   / _ \ | | | |_   _____  | |_| |  / _ \  / __| | __|  / _ \  / _` |   | |  _   / _` | | __|  / _ \ \ \ /\ / /  / _` | | | | |
  ___) | |  __/ | | |  _| |_____| |  _  | | (_) | \__ \ | |_  |  __/ | (_| |   | |_| | | (_| | | |_  |  __/  \ V  V /  | (_| | | |_| |
 |____/   \___| |_| |_|           |_| |_|  \___/  |___/  \__|  \___|  \__,_|    \____|  \__,_|  \__|  \___|   \_/\_/    \__,_|  \__, |
                                                                                                                                |___/

               .%*
                         /##(
                                   #####.
                                            ,%%%#%%/
                                                      #%%%%%%%%
                                                     (((#####((((#/
                                                   ((((##(((//////((
                                                  ((((##(///*******//.
                                                 /(((%#(//**,,..,,,*//
   %%%%%%%%############(/############%%%%%%%%%%%%%%%%%((/**,..  ..,,**
                                         .**(/%/%%%%%%((/**,... ..,***
                                                  (((%#((/**,,,,,,**/.
                                                   (((%#((//****,,//
                                                     ((%##((((///(*
                                                        ,%%####
                                                  %%%%%,
                                          *%%#%
                                   (###
                            ##(
                    ,#/
             (,

  _                                     _
 | |__     ___    ___   _ __           | |__     ___    ___   _ __
 | '_ \   / _ \  / _ \ | '_ \   _____  | '_ \   / _ \  / _ \ | '_ \
 | |_) | |  __/ |  __/ | |_) | |_____| | |_) | |  __/ |  __/ | |_) |
 |_.__/   \___|  \___| | .__/          |_.__/   \___|  \___| | .__/
                       |_|                                   |_|


version: 2.0.2.0
commit: 88e75c566e527dcf335d884f6df561fe1fd7c199
[Warn] 2022-04-18T02:46:46.872 [LoadBackupLocationNotFound], message: /apim/config, source: BackupMetadataProvider
[Info] 2022-04-18T02:46:46.886 [HostBootstrapperStarting]
[Info] 2022-04-18T02:46:46.886 [ComponentStarting], message: LogSinkEventListenerHost
[Info] 2022-04-18T02:46:46.887 [ComponentStarted], message: LogSinkEventListenerHost
[Info] 2022-04-18T02:46:46.887 [ComponentStarting], message: P2PRateLimitSignalSenderService
...

Acima temos os logs do pod do gateway, mostrando detalhes da imagem do gateway e operações de sincronização realizadas entre o gateway hospedado no Azure e o gateway hospedado na sua infra. Basta listar os pods com kubectl get pods e depois ver os logs de cada um.

 

Agora vamos obter o IP do gateway usando o comando abaixo

 

$kubectl get services
NAME         TYPE           CLUSTER-IP   EXTERNAL-IP      PORT(S)                      AGE
kubernetes   ClusterIP      10.0.0.1     <none>           443/TCP                      20d
us           LoadBalancer   10.0.55.81   20.127.183.117   80:32380/TCP,443:30841/TCP   20d

Acima temos uma lista dos serviços e podemos ver que existe um serviço us com IP externo 20.127.183.117 com esse IP podemos acessar as APIS.

Com esse IP podemos fazer uma comparação acessado a API que está respondendo pelo gateway hospedado na região dos Estados Unidos e o gateway do Azure que fica no Brasil.

Para termos um cenário com mais próximo da realidade, criei um VM no Estados unidos, nela vou fazer as comparações.

Máquina Virtual criada nos Estados unidosMáquina Virtual criada nos Estados unidos

 

Testes pelo Postman dentro da VM na região de East US

 

Teste no postman no gateway auto-hospedado.Teste no postman no gateway auto-hospedado.

 

Na chamada no endereço do gateway auto-hospedado http://20.127.183.117/us/api/device temos 13 ms

Teste no postman no gateway na nuvem.Teste no postman no gateway na nuvem.

 

Na chamada no endereço do gateway hospedado no Azure https://apimdevestudo04.azure-api.net/us/api/Device temos 247 ms

 

Conclusão

 

O exemplo acima mostra uma diferença muito significativa, algo de 10 até 15 vezes mais rápido de um gateway do outro. O gateway auto-hospedado é uma excelente opção para cenários onde nossos backends então hospedados on-premises, em outras nuvens diferentes do Azure, ou mesmo em cenários de regiões diferentes dentro do Azure. Com esse recurso podemos manter o tráfego local entre backend e gateway, diminuindo a latência e o custo com transferência de dados.

 

Referências

 

  1. Self-hosted gateway overview | Microsoft Docs
  2. Deploy a self-hosted gateway to Kubernetes with YAML | Microsoft Docs
  3. Provision a self-hosted gateway in Azure API Management | Microsoft Docs
  4. az aks | Microsoft Docs
Posted at https://sl.advdat.com/3uUP1Oghttps://sl.advdat.com/3uUP1Og