Introdução
Este documento é resultado do estudo feito para aprender como instalar e utilizar a solução de microgateway de API da WSO2. Nele serão mostrados os requisitos necessários para utilizar a solução, bem como o fluxo de trabalho proposto pela WSO2.
Desenvolvimento
No estudo feito, a base de consulta foi primariamente as documentações disponibilizadas pela WSO2. Na seção Referências Consultadas deste documento estão relacionados os links correspondentes.
Segundo a WSO2, o desenvolvimento de microgateways de API possui duas etapas: DEV e OPS.
Fase DEV
Corresponde a definir as APIs que serão gerenciadas pelo microgateway e gerar um executável dessa definição.
O desenvolvedor escreve a definição das APIs que deseja gerenciar pelo Microgateway utilizando o padrão OpenAPI 3 em conjunto com extensões desenvolvidas pela WSO2. Em seguida, as definições são compiladas pelo toolkit do microgateway, gerando uma imagem Docker ou um deployment Kubernetes, dependendo do ambiente de execução desejado.
Além disso, o desenvolvedor também deve:
- Gerar um token JWT que deve ser usado por quem for acessar os endpoints gerenciados pelo microgateway.
- Incorporar o certificado no executável do microgateway, para validar o token JWT usado no acesso aos endpoints.
Especificamente, o desenvolvedor deve seguir os passos abaixo:
- Pela linha de comando, selecione uma pasta onde ficarão os projetos de microgateway.
- Crie um arquivo de configuração para realizar o build do projeto. O conteúdo do arquivo pode variar de acordo com o target do projeto - Docker ou Kubernetes. Para mais detalhes, consulte as documentações abaixo:
- Execute o comando abaixo para criar a pasta do projeto e os arquivos necessários.
- Crie ou edite arquivos OpenAPI 3 das APIs, inserindo as tags customizadas necessárias para a execução no microgateway. O arquivo OpenAPI deve ter, obrigatoriamente, a extensão .yaml.
- Coloque na pasta <nome_projeto>/api_definitions os arquivos OpenAPI editados.
- Insira na keystore do microgateway o certificado utilizado para gerar o token JWT que será usado para realizar as chamadas às APIs. O token pode ser gerado pelo API Manager (2.6.0) ou por outro serviço de geração de tokens JWT.
- Faça o build do projeto, executando o comando:
Fase OPS
Corresponde a executar o build do microgateway, gerado na fase DEV.
A imagem Docker gerada pode ser executada diretamente, ou disponibilizada em um repositório Docker, para posteriormente ser implantada em um cluster Kubernetes.
Os passos a seguir neste fase são:
- Docker:
- Kubernetes:
- Faça o deploy da imagem Docker gerada no registry local ou em um Repositório Docker público ou privado, mas que esteja acessível pelo container que executará a imagem.
- Faça o deploy das definições do Kubernetes, geradas pelo build:
- Kubectl create -f <nome_projeto>/target/kubernetes/
- Acesse a API usando HTTPS e o token JWT, gerado anteriormente.
Para a prova de conceito da solução, foram desenvolvidos os seguintes cenários de uso:
- Gateway para uma API SOAP: Neste cenário, o endpoint consumido foi o Webservice de recebimento de mensagem padronizada, disponível numa instância do Logix.
- Gateway para uma API REST: Neste cenário, foi utilizado uma API padrão de testes do Swagger (Petstore), no padrão REST.
- Gateway para mais de uma API (misto de SOAP e REST): Este cenário combinou as duas APIs acima, num único build do microgateway.
- Gateway com um ingress, para expor APIs com um DNS específico: Com base no cenário acima, foi definido um DNS (multiapi.totvs.io) para a instalação do microgateway em Kubernetes.
Conclusões
A solução de microgateway da WSO2 mostrou-se bem flexível, permitindo gerenciar APIs REST e SOAP, bem como consolidar várias APIs num único deploy de microgateway.
Em relação a autenticação do acesso aos endpoints, a solução proposta, usando token JWT + certificado garante que o microgateway não dependa de soluções externas para executar esta função.
Entretanto, por rodar de forma isolada, o microgateway não consegue efetuar a autorização do acesso, ou seja, esta função deve ser desempenhada pelo backend do endpoint, combinado com algum outro mecanismo que permita identificar quem está efetuando a requisição.
O uso de ferramentas de linha de comando permite que o fluxo de trabalho seja automatizado, sendo facilmente incorporado num pipeline de CI/CD.
Referências consultadas
Além dos links já citados no documento, seguem referencias adicionais, consultadas durante o estudo:
Overview sobre API Microgateway - https://docs.wso2.com/display/MG301/Overview
Quick Start - https://docs.wso2.com/display/MG301/Quick+Start+Guide
Artigo sobre Microgateway no Kubernetes - https://medium.com/@pubudu538/deploy-wso2-api-microgateway-in-kubernetes-c2f25a35d863
Artigo sobre LoadBalancer no Kubernetes - https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0
Serviços de rede no Kubernetes - https://kubernetes.io/docs/concepts/services-networking/service/