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. |
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.
Este estudo foi baseado na versão 3.01 do API Microgateway. |
Para ter o API Microgateway rodando localmente, é necessário cumprir os pré-requisitos indicados neste link. É imprescindível ter Docker e Minikube instalados também. |
Segundo a WSO2, o desenvolvimento de microgateways de API possui duas etapas: DEV e OPS.
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:
Especificamente, o desenvolvedor deve seguir os passos abaixo:
micro-gw init <nome_projeto>
micro-gw build <nome_projeto> --deployment-config <arquivo_configuração>
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:
Para a prova de conceito da solução, foram desenvolvidos os seguintes cenários de uso:
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.
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/
|