Voltar

Implementação do Microcks no Managed Kubernetes Service (MKS) da OVHcloud

Aurélie Vache8 minutos de leitura
,
Implementação do Microcks no Managed Kubernetes Service (MKS) da OVHcloud

O seu serviço está pronto a testar, mas a API da qual depende não será lançada antes de três semanas. Já passou por isso? Quando se desenvolve ou testa uma aplicação, algumas das API de que esta depende muitas vezes ainda não estão disponíveis, o que pode ser frustrante.

A simulação de API resolve esse problema: permite-lhe testar as suas integrações sem ter de esperar pelo backend real. O Microcks responde a esta necessidade e fá-lo diretamente a partir do seu cluster Kubernetes.

Neste artigo, ensinamos a implementar o Microcks num cluster Managed Kubernetes Service (MKS) da OVHcloud e a expô-lo usando a API Gateway Kubernetes, o Envoy Gateway e um Load Balancer Public Cloud da OVHcloud.

Enquanto projeto da CNCF, o Microcks integra-se facilmente num ambiente cloud-native. E como a OVHcloud é membro Platinum da CNCF, executar o Microcks no MKS é uma forma natural de integrar a simulação e o teste de API na sua plataforma Kubernetes.

O que é o Microcks?

Logótipo do Microcks, ferramenta open-source de simulação e teste de API

O Microcks é uma ferramenta open-source para simulação e teste de API.

Cria simulações a partir de especificações de API, para que possa testar aplicações e integrações sem que seja necessário que o backend real esteja disponível.

Isto é particularmente útil em ambientes distribuídos, onde as equipas e os serviços evoluem de forma independente. E como é executado no Kubernetes, o Microcks integra-se de forma muito simples num ambiente cloud-native.

Pré-requisitos

Antes de começar, irá precisar de:

  • Uma conta OVHcloud
  • Um projeto Public Cloud OVHcloud
  • Uma credencial API com as permissões necessárias para gerir um cluster MKS
  • A CLI OVHcloud
  • kubectl
  • Helm
  • Um nome de domínio (a apontar para o Load Balancer, se pretender um nome de domínio personalizado)

Vamos a isso!

1.º passo: Criar o cluster MKS

Primeiro é preciso criar um cluster Managed Kubernetes Service e um pool de nós.

Este exemplo usa um pool de três nós baseado no flavor b3-8.

Tenha em atenção que, para o uso em produção, deve considerar recorrer a um plano standard em vez do plano gratuito.

Crie o cluster

Defina os parâmetros do seu cluster:

bash
export CLUSTER_NAME="microcks"
export REGION="GRA9"
export PLAN="free"

Crie o cluster Kubernetes:

bash
CLUSTER_ID=$(ovhcloud cloud mks create --name $CLUSTER_NAME --region $REGION --plan $PLAN | grep -oE '[0-9a-f-]{36}')

Aguarde 2 ou 3 minutos para que o cluster seja aprovisionado.

Verifique o estado do cluster Kubernetes:

bash
ovhcloud cloud mks get $CLUSTER_ID

Crie o pool de nós e ligue ao cluster

O Microcks é composto por várias cargas de trabalho Kubernetes, incluindo a aplicação Microcks, o Keycloak e a sua instância PostgreSQL, o MongoDB e o runtime Postman.

Para uma instalação pequena, um pool com três nós de uso geral é uma base razoável.

Assim que o cluster tiver sido criado, pode criar o pool de nós. Defina a configuração do pool de nós:

bash
export NODEPOOL_NAME="microcks-np"
export NODE_FLAVOR="b3-8"

Crie o pool de nós:

bash
NP_ID=$(ovhcloud cloud mks nodepool create $CLUSTER_ID --flavor-name $NODE_FLAVOR --name $NODEPOOL_NAME --desired-nodes 3 --min-nodes 2 --max-nodes 3 | grep -oE '[0-9a-f-]{36}')

Aguarde 3 ou 4 minutos para que o pool de nós seja aprovisionado.

Verifique o estado do pool de nós:

bash
ovhcloud cloud mks nodepool get $CLUSTER_ID $NP_ID

Assim que o cluster e o pool de nós estiverem prontos, faça a configuração do Kubernetes:

bash
ovhcloud cloud mks kubeconfig generate $CLUSTER_ID > microcks.yaml

Configure a CLI kubectl com o kubeconfig gerado:

bash
export KUBECONFIG=$(pwd)/microcks.yaml

Verifique se os nós estão prontos:

bash
kubectl get np
kubectl get nodes

O seu cluster Kubernetes está pronto. Pode avançar para a exposição do Microcks.

2.º passo: Expor o cluster com a API Gateway

Concebida como a sucessora do Ingress, a API Gateway é o padrão do Kubernetes para o encaminhamento de tráfego para um cluster. Ela descreve o que pretende expor; um controlador transforma então essa descrição num proxy em execução e, no MKS, num Load Balancer Public Cloud da OVHcloud.

Utilizará três componentes: o Envoy Gateway, uma implementação da API Gateway baseada no proxy Envoy; o cert-manager, que automatiza a gestão de certificados TLS; e um recurso Gateway que os integra.

Instale o Envoy Gateway

Instale o gráfico Helm do Envoy Gateway:

bash
helm install envoy-gateway oci://docker.io/envoyproxy/gateway-helm -n envoy-gateway-system --create-namespace

Em seguida, crie um GatewayClass que indique ao Kubernetes que o Envoy Gateway é responsável pelos seus recursos Gateway:

bash
cat <<EOF | kubectl apply -f -
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: envoy
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller
EOF

Administre os certificados TLS com o cert-manager

Para gerir automaticamente os seus certificados TLS, use o cert-manager em conjunto com o Let's Encrypt.

Instale o cert-manager:

bash
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager --namespace cert-manager --create-namespace --set crds.enabled=true --set config.gatewayAPI.enabled=true

De seguida, crie um ClusterIssuer para o Let's Encrypt:

bash
cat <<EOF | kubectl apply -f -
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod-microcks
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: <your-email@example.com>   # Update with your email address
    privateKeySecretRef:
      name: letsencrypt-prod-microcks
    solvers:
      - http01:
          gatewayHTTPRoute:
            parentRefs:
              - name: microcks-gateway
                namespace: microcks
                group: gateway.networking.k8s.io
                kind: Gateway
EOF

Este emissor permite ao cert-manager solicitar certificados do Let's Encrypt utilizando o resolvedor HTTP-01 da API Gateway.

Crie o Gateway

Já pode criar o Gateway que irá expor o Microcks.

Crie o namespace:

bash
kubectl create namespace microcks

Crie o Gateway com os seus cinco ouvintes: HTTP e HTTPS para o Microcks, TLS passthrough para o gRPC, e HTTP e HTTPS para o Keycloak.

bash
cat <<EOF | kubectl apply -f -
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: microcks-gateway
  namespace: microcks
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod-microcks
spec:
  gatewayClassName: envoy
  listeners:
    - name: microcks-http
      hostname: microcks.<YOUR_DOMAIN>.com
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: Same
    - name: microcks-https
      hostname: microcks.<YOUR_DOMAIN>.com
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - name: microcks-tls
      allowedRoutes:
        namespaces:
          from: Same
    - name: microcks-grpc
      hostname: microcks-grpc.<YOUR_DOMAIN>.com
      protocol: TLS
      port: 443
      tls:
        mode: Passthrough
      allowedRoutes:
        namespaces:
          from: Same
    - name: keycloak-http
      hostname: keycloak.<YOUR_DOMAIN>.com
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: Same
    - name: keycloak-https
      hostname: keycloak.<YOUR_DOMAIN>.com
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - name: keycloak-tls
      allowedRoutes:
        namespaces:
          from: Same
EOF

Verifique o estado do Gateway:

bash
kubectl get gateway -n microcks
--- OUTPUT ---
NAME               CLASS   ADDRESS        PROGRAMMED   AGE
microcks-gateway   envoy   xx.xx.xx.xx    True         3m49s

Nesta fase, o Gateway deverá estar Accepted=True e Programmed=True. Se ainda não estiver, aguarde alguns minutos para que o Gateway seja programado e para que o Load Balancer Public Cloud da OVHcloud seja aprovisionado.

Configurar o DNS

Obtenha o endereço externo atribuído ao Gateway:

bash
export GATEWAY_IP=$(kubectl get gateway microcks-gateway \
  -n microcks \
  -o jsonpath='{.status.addresses[0].value}')
 
echo $GATEWAY_IP
--- OUTPUT ---
xx.xx.xx.xx

Se estiver a usar um domínio personalizado, crie os seguintes registos DNS:

bash
microcks.<YOUR_DOMAIN>.com       A    <GATEWAY_IP>
microcks-grpc.<YOUR_DOMAIN>.com  A    <GATEWAY_IP>
keycloak.<YOUR_DOMAIN>.com       A    <GATEWAY_IP>

Pode configurar estes registos através da interface de gestão DNS da OVHcloud:

Implemente o Microcks

Assim que o DNS estiver configurado, verifique os registos:

bash
dig keycloak.<YOUR_DOMAIN>.com +noall +answer
dig microcks.<YOUR_DOMAIN>.com +noall +answer
dig microcks-grpc.<YOUR_DOMAIN>.com +noall +answer

3.º passo: Implementar e verificar o Microcks

A infraestrutura está pronta. Chegou a altura de implementar o Microcks.

Implemente o Microcks com Helm

Vai utilizar o gráfico Helm oficial do Microcks e configurá-lo para criar recursos HTTPRoute da API Gateway em vez de recursos Ingress do Kubernetes.

Adicione o repositório Helm do Microcks:

bash
helm repo add microcks https://microcks.io/helm/
helm repo update

Crie um ficheiro microcks_values.yaml:

bash
cat > microcks_values.yaml <<EOF
appName: microcks
 
ingresses: false
gatewayRoutes: true
 
gatewayRefName: microcks-gateway
gatewayRefNamespace: microcks
gatewayRefSectionName: microcks-https
grpcGatewayRefSectionName: microcks-grpc
 
microcks:
  url: microcks.<YOUR_DOMAIN>.com
  ingressSecretRef: microcks-tls
  generateCert: false
  grpcEnableTLS: true
 
keycloak:
  url: keycloak.<YOUR_DOMAIN>.com
  privateUrl: http://microcks-keycloak.microcks.svc.cluster.local:8080
  ingressSecretRef: keycloak-tls
  generateCert: false
  gatewayRefName: microcks-gateway
  gatewayRefNamespace: microcks
  gatewayRefSectionName: keycloak-https
EOF

Instale o Microcks:

bash
helm install microcks microcks/microcks -n microcks -f microcks_values.yaml

Verifique a implementação

Verifique os pods:

bash
kubectl get pods -n microcks
--- OUTPUT ---
NAME                                           READY   STATUS    RESTARTS       AGE
microcks-7f9f994fbc-jd7pb                      1/1     Running   0              19m
microcks-keycloak-5cf68c6b65-xjr6n             1/1     Running   3 (3m1s ago)   19m
microcks-keycloak-postgresql-6665b755f-zjdrl   1/1     Running   0              19m
microcks-mongodb-7ddff9f544-8rdcx              1/1     Running   0              19m
microcks-postman-runtime-5699859b86-58mr7      1/1     Running   0              19m

Aguarde até que todos os pods estejam no estado Running e que os containers estejam prontos.

Também pode verificar as rotas da API Gateway:

bash
kubectl get httproute -n microcks
--- OUTPUT ---
NAME                HOSTNAMES                          AGE
microcks            ["microcks.<YOUR_DOMAIN>.com"]     3m34s
microcks-keycloak   ["keycloak.<YOUR_DOMAIN>.com"]     3m34s

As rotas devem referenciar os hostnames do Microcks e do Keycloak configurados anteriormente.

Neste momento, o Microcks deve estar acessível via:

bash
https://microcks.<YOUR_DOMAIN>.com
https://microcks-grpc.<YOUR_DOMAIN>.com
https://keycloak.<YOUR_DOMAIN>.com

O Microcks encontra-se em execução num cluster do Managed Kubernetes Service da OVHcloud, exposto através da API Gateway e protegido com certificados TLS geridos pelo cert-manager.

Conclusão e próximos passos

Neste artigo, o Microcks foi implementado num cluster Managed Kubernetes Service da OVHcloud. Depois foi exposto através da implementação da API Gateway Kubernetes do Envoy Gateway e de um Load Balancer Public Cloud OVHcloud. Os certificados TLS são geridos com o cert-manager e o Let's Encrypt.

Neste momento já pode simular e testar as suas API diretamente a partir de um cluster MKS.

Para um ambiente de produção, outra opção seria utilizar o Managed Databases da OVHcloud para PostgreSQL e MongoDB, em vez de executar estes componentes de bases de dados diretamente no cluster Kubernetes. Esta abordagem separa a plataforma de aplicações da infraestrutura de base de dados e permite tirar partido de serviços geridos de bases de dados.Pronto para testar? Crie o seu primeiro cluster Managed Kubernetes e implemente o Microcks em menos de 30 minutos. Para acompanhar as funcionalidades mais recentes dos produtos Public Cloud da OVHcloud, consulte o Cloud Roadmap & Changelog.

Partilhar em: