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:
- Portal do Desenvolvedor
- Gateway
- Portal do Azure
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
- Diminuir a latência e o tráfego de dados do gateway com o backend (API)
- Manter chamadas de APIs locais dentro da infraestrutura local
- Segregar custo computacional em diferentes hardwares
Vamos considerar o cenário abaixo
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.
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?
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.
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ê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.
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.
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.yamllocalmente com o conteúdo fornecido na aba deployment.
Caso precise fazer a associação de outra APIS basta acessar a o menu APIS do gateway.
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 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.
Testes pelo Postman dentro da VM na região de East US
Na chamada no endereço do gateway auto-hospedado http://20.127.183.117/us/api/device temos 13 ms
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