Retour

Déployer Microcks sur OVHcloud Managed Kubernetes Service (MKS)

Aurélie Vache8 min de lecture
Kubernetes,Public Cloud
Déployer Microcks sur OVHcloud Managed Kubernetes Service (MKS)

Votre service est prêt à être testé, mais l'API dont il dépend ne sera pas disponible avant trois semaines. Ce scénario vous semble familier ? Lorsque vous développez ou testez une application, certaines des API dont elle dépend ne sont souvent pas encore disponibles, ce qui peut être source de frustration.

L’API mocking comble cette lacune : elle vous permet de tester vos intégrations sans attendre le back-end réel. Microcks répond à ce besoin. Et ce, directement depuis votre cluster Kubernetes.

Cet article de blog vous montre comment déployer Microcks sur un cluster Managed Kubernetes Service (MKS) d’OVHcloud et comment l’exposer en utilisant Gateway API de Kubernetes, Envoy Gateway et un OVHcloud Load Balancer Public Cloud.

En tant que projet CNCF, Microcks s'intègre naturellement dans un environnement cloud native. Et avec OVHcloud, membre CNCF Platinum, l’exécution de Microcks sur MKS constitue une manière naturelle d’intégrer le mocking et le test d’API à votre plateforme Kubernetes.

Qu'est-ce que Microcks ?

Le logo de Microcks, l'outil open source de simulation et de test d'API

Microcks est un outil open source pour le mocking et le test d'API.

Il crée des mocks à partir de spécifications d'API, ce qui vous permet de tester des applications et des intégrations sans que le back-end réel ne soit nécessaire.

Cela s’avère particulièrement utile dans les environnements distribués, où les équipes et les services évoluent de manière indépendante. Et comme Microcks fonctionne sur Kubernetes, il s’intègre naturellement à un environnement cloud native.

Prérequis

Avant de commencer, vous aurez besoin :

  • d’un compte OVHcloud ;
  • d’un projet Public Cloud actif ;
  • d’une d’identifiants API avec les autorisations nécessaires pour gérer un cluster MKS ;
  • de la CLI OVHcloud ;
  • de kubectl ;
  • d’Helm ;
  • d’un nom de domaine (pointant vers le Load Balancer, si vous souhaitez un nom de domaine personnalisé).

C’est parti !

Étape 1 : créer un cluster MKS

Il faut d’abord créer un cluster Managed Kubernetes Service OVHcloud et un pool de nœuds.

Pour cet exemple, nous utiliserons un pool de trois nœuds basé sur la variante b3-8.

Notez que pour une utilisation en production, vous devriez envisager d'utiliser une offre standard plutôt que l’offre gratuite.

Créer le cluster

Définissez les paramètres de votre cluster.

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

Créez le cluster Kubernetes.

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

Attendez 2 à 3 minutes pour que le cluster soit provisionné.

Vérifiez l'état du cluster Kubernetes.

bash
ovhcloud cloud mks get $CLUSTER_ID

Créer le pool de nœuds et se connecter au cluster

Microcks est composé de plusieurs charges de travail Kubernetes, notamment l’application Microcks, Keycloak et son instance PostgreSQL, MongoDB ainsi que le runtime Postman.

Pour une petite installation, un pool de nœuds avec trois nœuds polyvalents constitue un bon point de départ.

Une fois le cluster mis en place, vous pouvez créer le pool de nœuds. Définissez la configuration du pool de nœuds.

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

Créez le pool de nœuds.

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}')

Attendez 3 à 4 minutes pour qu’il soit provisionné.

Vérifiez l'état du pool de nœuds.

bash
ovhcloud cloud mks nodepool get $CLUSTER_ID $NP_ID

Une fois le cluster et le pool de nœuds prêts, générez la configuration Kubernetes.

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

Configurez la CLI kubectl avec le fichier kubeconfig généré.

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

Vérifiez que les nœuds sont prêts.

bash
kubectl get np
kubectl get nodes

Votre cluster Kubernetes est maintenant prêt. Vous pouvez passer à l’exposition de Microcks.

Étape 2 : exposer le cluster avec Gateway API

Gateway API est le standard Kubernetes pour le routage du trafic vers un cluster, conçue comme le successeur d'Ingress. Cette solution décrit ce que vous souhaitez exposer. Un contrôleur transforme ensuite cette description en un proxy opérationnel et, sur MKS, en un Load Balancer OVHcloud Public Cloud.

Vous utiliserez trois composants : Envoy Gateway, une implémentation d’API Gateway construite sur le proxy Envoy, cert-manager, qui automatise les certificats TLS, et une ressource Gateway qui les relie entre eux.

Installer Envoy Gateway

Installez le chart Helm Envoy Gateway.

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

Créez ensuite une GatewayClass qui indique à Kubernetes qu’Envoy Gateway est responsable de vos ressources 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

Gérer les certificats TLS avec cert-manager

Pour gérer automatiquement vos certificats TLS, vous utiliserez cert-manager en combinaison avec Let's Encrypt.

Installez 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

Créez ensuite un ClusterIssuer pour 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

Cet issuer permet à cert-manager de demander des certificats à Let's Encrypt en utilisant le solveur HTTP-01 de l'API Gateway.

Créer la Gateway

Vous pouvez maintenant créer la Gateway qui exposera Microcks.

Créez le namespace.

bash
kubectl create namespace microcks

Créez ensuite la Gateway avec ses cinq listeners : HTTP et HTTPS pour Microcks, TLS passthrough pour gRPC et HTTP et HTTPS pour 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

Vérifier l'état de la Gateway.

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

À ce stade, la Gateway devrait être Accepté=True et Programmed=True. Si ce n'est pas le cas, attendez quelques minutes pour que la Gateway soit programmée et que le Load Balancer Public Cloud soit provisionné.

Configurer le DNSSEC

Obtenez l'adresse externe attribuée à la 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

Si vous utilisez un domaine Custom, créez les enregistrements DNS suivants.

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

Vous pouvez configurer ces enregistrements via l’interface de gestion DNS d’OVHcloud.

Déployer Microcks

Une fois le DNS configuré, vérifiez les enregistrements.

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

Étape 3 : déployer et vérifier Microcks

L’infrastructure est désormais prête. Déployons Microcks.

Déployer Microcks avec Helm

Vous allez utiliser le chart Helm officiel de Microcks et le configurer pour qu'il crée des ressources HTTPRoute de Gateway API, au lieu de ressources Ingress Kubernetes.

Ajoutez le dépôt Helm de Microcks.

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

Créez un fichier 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

Installez Microcks.

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

Vérifier le déploiement

Vérifier les 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

Attendez que tous les pods soient dans l'état En cours d'exécution et que les conteneurs soient prêts.

Vous pouvez également vérifier les routes de l’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

Les routes doivent faire référence aux noms d'hôte Microcks et Keycloak configurés précédemment.

À ce stade, Microcks devrait être accessible.

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

Vous disposez désormais de Microcks fonctionnant sur un cluster OVHcloud Managed Kubernetes Service, exposé via Gateway API et sécurisé avec des certificats TLS gérés par cert-manager.

Conclusion et perspectives

Dans cet article de blog, vous avez déployé Microcks sur un cluster OVHcloud Managed Kubernetes Service et l'avez exposé en utilisant l'implémentation de la Kubernetes Gateway API d'Envoy Gateway et un Load Balancer Public Cloud d'OVHcloud. Les certificats TLS sont gérés avec cert-manager et Let's Encrypt.

Vous pouvez désormais simuler et tester des API directement depuis un cluster MKS.

Pour un environnement de production, une autre option serait d'utiliser OVHcloud Managed Databases for PostgreSQL et MongoDB au lieu d'exécuter ces composants de base de données directement dans le cluster Kubernetes. Cette approche sépare la plateforme applicative de l'infrastructure de base de données, et vous permet de tirer parti des services de bases de données managées.

Envie de tester ? Créez votre premier cluster Kubernetes managé et déployez Microcks en moins de 30 minutes. Pour suivre les dernières fonctionnalités à venir sur les produits Public Cloud d’OVHcloud, consultez la feuille de route et le changelog de nos produits cloud.

Partager sur :