Powrót

Wdrożenie Microcks w OVHcloud Managed Kubernetes Service (MKS)

Aurélie Vache7 min. czytania
,
Wdrożenie Microcks w OVHcloud Managed Kubernetes Service (MKS)

Twoja usługa jest już gotowa do testów, ale API wymagane do jej działania będzie dostępne dopiero za trzy tygodnie. Brzmi znajomo? Podczas tworzenia i testowania aplikacji często okazuje się, że nie wszystkie potrzebne API są już gotowe. To potrafi skutecznie spowolnić prace.

API mocking rozwiązuje ten problem: pozwala testować integracje bez czekania na rzeczywisty backend. Dzięki Microcks przeprowadzisz testy bezpośrednio w klastrze Kubernetes.

W tym artykule pokazujemy, jak wdrożyć Microcks w klastrze OVHcloud Managed Kubernetes Service (MKS) i udostępnić go za pomocą Kubernetes Gateway API, Envoy Gateway oraz OVHcloud Public Cloud Load Balancer.

Microcks jest projektem CNCF i dobrze sprawdza się w architekturze cloud native. OVHcloud ma status CNCF Platinum Member, dlatego MKS jest naturalnym środowiskiem do uruchamiania tego narzędzia oraz mockowania i testowania API na platformie Kubernetes.

Co to jest Microcks?

Logo Microcks, narzędzia open source do mockowania i testowania interfejsów API.

Microcks to narzędzie open source do mockowania i testowania API.

Na podstawie specyfikacji API tworzy mocki, dzięki którym można sprawdzać działanie aplikacji i integracji bez dostępu do rzeczywistego backendu.

Jest to szczególnie przydatne w systemach rozproszonych, w których poszczególne usługi są rozwijane niezależnie przez różne zespoły. Microcks działa w Kubernetes, więc dobrze sprawdza się w architekturze cloud native.

Wymagania początkowe

Zanim zaczniesz, upewnij się, że masz:

  • Konto OVHcloud
  • Projekt Public Cloud w OVHcloud
  • Poświadczenia API z uprawnieniami wymaganymi do zarządzania klastrem MKS
  • OVHcloud CLI
  • kubectl
  • Helm
  • Domenę (wskazującą na Load Balancer, jeśli chcesz używać własnej domeny)

Zaczynamy!

Krok 1: Utwórz klaster MKS

Najpierw utwórz klaster OVHcloud Managed Kubernetes Service i pulę węzłów.

W tym przykładzie użyjemy puli trzech węzłów w konfiguracji b3-8.

W środowisku produkcyjnym warto rozważyć pakiet Standard zamiast bezpłatnego pakietu Free.

Utwórz klaster

Określ parametry klastra:

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

Utwórz klaster Kubernetes:

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

Poczekaj 2-3 minuty, aż klaster zostanie skonfigurowany.

Sprawdź stan klastra Kubernetes:

bash
ovhcloud cloud mks get $CLUSTER_ID

Utwórz pulę węzłów i połącz się z klastrem

Microcks składa się z kilku obciążeń roboczych Kubernetes, w tym aplikacji Microcks, Keycloak i jego instancji PostgreSQL, MongoDB oraz środowiska uruchomieniowego Postman.

W przypadku niewielkiej instalacji dobrym punktem wyjścia jest pula trzech węzłów ogólnego przeznaczenia.

Po utworzeniu klastra dodaj pulę węzłów. Najpierw zdefiniuj jej konfigurację:

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

Utwórz pulę węzłów:

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

Poczekaj 3-4 minuty, aż pula węzłów zostanie udostępniona.

Sprawdź status puli węzłów:

bash
ovhcloud cloud mks nodepool get $CLUSTER_ID $NP_ID

Gdy klaster i pula węzłów będą gotowe, wygeneruj konfigurację Kubernetes:

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

Skonfiguruj kubectl CLI z wygenerowanym plikiem kubeconfig:

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

Sprawdź, czy węzły są gotowe:

bash
kubectl get np
kubectl get nodes

Klaster Kubernetes jest gotowy. Możesz teraz przejść do konfiguracji dostępu do Microcks.

Krok 2: Udostępnij klaster za pomocą Gateway API

Gateway API to standard Kubernetes kierujący ruch do klastra (zastąpił Ingress). Określa, które zasoby mają być dostępne z zewnątrz. Na tej podstawie kontroler uruchamia proxy, a w przypadku MKS tworzy OVHcloud Public Cloud Load Balancer.

W tej konfiguracji wykorzystamy trzy komponenty: Envoy Gateway, czyli implementację Gateway API opartą na proxy Envoy, cert-manager do automatycznego zarządzania certyfikatami TLS oraz zasób Gateway, który je łączy.

Instalacja Envoy Gateway

Zainstaluj chart Envoy Gateway Helm:

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

Następnie utwórz GatewayClass. W ten sposób Kubernetes otrzyma informację, że za zasoby Gateway odpowiada Envoy 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

Zarządzaj certyfikatami TLS za pomocą cert-manager

Do automatycznego zarządzania certyfikatami TLS wykorzystamy cert-manager i Let's Encrypt.

Zainstaluj 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

Następnie utwórz ClusterIssuer dla 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

Ten „issuer” pozwala cert-manager pobierać certyfikaty z Let's Encrypt za pomocą mechanizmu HTTP-01 Gateway API.

Utwórz Gateway

Teraz utwórz Gateway, za pośrednictwem którego Microcks będzie dostępny z zewnątrz.

Utwórz namespace:

bash
kubectl create namespace microcks

Następnie skonfiguruj Gateway z pięcioma obiektami „listener”: HTTP i HTTPS dla Microcks, TLS passthrough dla gRPC oraz HTTP i HTTPS dla 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

Sprawdź status Gateway:

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

Na tym etapie Gateway powinien mieć status Accepted=True i Programmed=True. Jeśli tak nie jest, odczekaj kilka minut na zakończenie konfiguracji Gateway i utworzenie Load Balancera Public Cloud.

Skonfiguruj DNS

Pobierz zewnętrzny adres przypisany do 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

Jeśli używasz własnej domeny, utwórz następujące rekordy DNS:

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

Rekordy możesz skonfigurować w interfejsie zarządzania DNS OVHcloud:

Wdrożenie Microcks

Po skonfigurowaniu DNS, sprawdź wpisy:

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

Krok 3: Zainstaluj i sprawdź Microcks

Infrastruktura jest już gotowa. Czas na wdrożenie Microcks.

Zainstaluj Microcks za pomocą Helm

Użyj oficjalnego chartu Helm Microcks i skonfiguruj go tak, żeby tworzył zasoby HTTPRoute Gateway API zamiast zasobów Kubernetes Ingress.

Dodaj repozytorium Microcks Helm:

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

Utwórz plik 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

Zainstaluj Microcks:

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

Sprawdź wdrożenie

Sprawdź pody:

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

Poczekaj, aż wszystkie pody uzyskają status Running i kontenery będą gotowe.

Możesz również sprawdzić trasy Gateway API:

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

Trasy powinny wskazywać skonfigurowane wcześniej nazwy hostów Microcks i Keycloak.

Microcks powinien być teraz dostępny pod następującymi adresami:

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

Microcks działa teraz w klastrze OVHcloud Managed Kubernetes Service i jest dostępny za pośrednictwem Gateway API. Dostęp jest zabezpieczony certyfikatami TLS zarządzanymi przez cert-manager.

Podsumowanie i kolejne kroki

W tym artykule pokazaliśmy, jak wdrożyć Microcks w klastrze OVHcloud Managed Kubernetes Service i udostępnić go za pomocą implementacji Kubernetes Gateway API w Envoy Gateway oraz OVHcloud Public Cloud Load Balancer. Certyfikatami TLS zarządzają cert-manager i Let's Encrypt.

Możesz teraz mockować i testować API bezpośrednio w klastrze MKS.

W środowisku produkcyjnym możesz również skorzystać z OVHcloud Managed Databases for PostgreSQL i MongoDB zamiast uruchamiać te komponenty bazodanowe bezpośrednio w klastrze Kubernetes. Pozwala to oddzielić platformę aplikacyjną od infrastruktury bazodanowej i wykorzystać zarządzane usługi baz danych.

Chcesz wypróbować Microcks? Utwórz pierwszy zarządzany klaster Kubernetes i uruchom Microcks w mniej niż 30 minut. Informacje o najnowszych funkcjach wprowadzanych w produktach OVHcloud Public Cloud znajdziesz w Cloud Roadmap & Changelog.

Udostępnij na: