Déployer et interconnecter 2 clusters GKE et Elastic Cloud

Dans cet article, nous allons déployer, en continu, un cluster GKE, un Private Service Connect et un cluster ElasticCloud depuis GitLab CI. Les déploiements seront réalisés par Terraform pour les 2 clusters et par GCloud SDK pour le PSC. Les états (state) Terraform seront hébergés directement dans le projet GitLab. Cette fonctionnalité est disponible depuis la version 14.0.

Session vidéo lors de ElasticCC en février 2022, lien vers la vidéo Youtube

Pré-requis

Pour suivre toutes les étapes de l'article, vous devez disposer :

d'un projet GCP
d'un projet Elastic
d'un projet GitLab en version 14.0 minimum
d'un Gitlab Runner utilisant Docker

Pour les besoins du déploiement, votre runner doit avoir une architecture amd64 car l'image Terraform ne fonctionne pas sous une architecture arm.

Préparation

Gitlab

Commençons par créer les différents variables qui seront nécessaire au bon déroulement des étapes de l'article. Pour ce faire, il faut ouvrir la page Settings > CI/CD de votre projet, puis ouvrir le panneau Variables.

Créer les variables ci-dessous :

EC_API_KEY : Clé de l'API ElasticCloud
EC_DNS_ZONE : Zone DNS pour Elastic Cloud
EC_SERVICE_ATTACHMENT_URI : URI pour le PSC
GCP_PROJECT_ID : Identifiant du projet Google Cloud Platform
GCP_REGION : Région où seront déployés les services GCP
GCP_NETWORK_NAME : Nom du VPC du cluster GKE
GCP_SUBNETWORK_NAME : Nom du sous-réseau du VPC
GCP_SA : Compte de service Google Cloud Platform
GCP_INTERNAL_IP_NAME : Nom de l'IP interne utilisée pour le PSC
GCP_PSC_NAME : Nom du PSC
GCP_DNS_ZONE_GKE_ELASTIC : Nom de la zone DNS pour le PSC

EC_API_KEY

Pour créer la clé d'API Elastic Cloud, il faut se connecter sur le compte Elastic, lien vers la page des clés API et cliquer sur Generate API key. Copier-coller ensuite le contenu généré dans la variable EC_API_KEY dans Gitlab.

EC_DNS_ZONE et EC_SERVICE_ATTACHMENT_URI

Ces 2 variables sont utiles pour mettre en place le filtrage du trafic dans le but de sécuriser la connexion entre les 2 clusters.

Pour récupérer les valeurs de ces 2 variables, vous devez ouvrir la page GCP Private Service Connect traffic filters. Les valeurs sont différentes en fonction de la région où sera déployé le cluster Elastic.

Pour ma part, j'ai utilisé les valeurs ci-dessous :

EC_DNS_ZONE : psc.europe-west1.gcp.cloud.es.io
EC_SERVICE_ATTACHMENT_URI : projects/cloud-production-168820/regions/europe-west1/serviceAttachments/proxy-psc-production-europe-west1-v1-attachment

GCP_PROJECT_ID

Pour récupérer l'identifiant du projet Google Cloud Platform, il faut se connecter sur la console, lien vers la console GCP, sélectionner votre projet et copier-coller la valeur présente dans la colonne de droite nommée ID du projet sélectionné.

Profitez de cette action pour sélectionner le projet, car nous allons activer les différentes API nécessaires au déploiement et procéder à la création du compte de service.

Pour activer les APIs, il faut ouvrir le Cloud Shell. Une fois ouvert, vérifier que vous êtes bien sur le bon projet puis exécuter la commande ci-dessous :

gcloud services enable cloudresourcemanager.googleapis.com compute.googleapis.com sqladmin.googleapis.com container.googleapis.com servicenetworking.googleapis.com redis.googleapis.com dns.googleapis.com

Lien vers la documentation de la commande gcloud services.

GCP_SA

Profitons également que le Cloud Shell soit ouvert pour créer le compte de service qui sera utilisé par Gitlab Ci. Modifier les valeurs de <nom-du-compte-de-service> et de <gcp_project_id> avant de lancer la commande :

gcloud iam service-accounts create <nom-du-compte-de-service> --description="Service Account for Gitlab" --display-name="Gitlab Ci"
gcloud iam service-accounts keys create sa-gitlab.json --iam-account="<nom-du-compte-de-service>@<gcp_project_id>.iam.gserviceaccount.com"
cat sa-gitlab.json

Copier-coller le contenu du fichier sa-gitlab.json dans Gitlab Ci. Après avoir créé la variable, pensez à supprimer le fichier sa-gitlab.json.

Pour le déploiement, le compte de service aura besoin de droits. Pour ce faire, remplacer les valeurs de <nom-du-compte-de-service> et de <gcp_project_id> avant de lancer la commande :

gcloud projects add-iam-policy-binding <gcp_project_id> --member "serviceAccount:<nom-du-compte-de-service>@<gcp_project_id>.iam.gserviceaccount.com" --role "roles/container.admin"
gcloud projects add-iam-policy-binding <gcp_project_id> --member "serviceAccount:<nom-du-compte-de-service>@<gcp_project_id>.iam.gserviceaccount.com" --role "roles/compute.networkAdmin"
gcloud projects add-iam-policy-binding <gcp_project_id> --member "serviceAccount:<nom-du-compte-de-service>@<gcp_project_id>.iam.gserviceaccount.com" --role "roles/container.serviceAgent"
gcloud projects add-iam-policy-binding <gcp_project_id> --member "serviceAccount:<nom-du-compte-de-service>@<gcp_project_id>.iam.gserviceaccount.com" --role "roles/redis.admin"
gcloud projects add-iam-policy-binding <gcp_project_id> --member "serviceAccount:<nom-du-compte-de-service>@<gcp_project_id>.iam.gserviceaccount.com" --role "roles/cloudsql.admin"

Lien vers la documentation de la commande gcloud projects

Les autres variables GCP

Pour terminer avec les variables, voici celle que vous pouvez renseigner selon vos envies, pour ma part, voici ce que j'ai défini :

GCP_REGION : europe-west1
GCP_NETWORK_NAME : vpc-network-gke
GCP_SUBNETWORK_NAME : vpc-subnetwork-gke
GCP_INTERNAL_IP_NAME : vpc-private-internal-ip-gke
GCP_PSC_NAME : psc-gke-elasticcloud
GCP_DNS_ZONE_GKE_ELASTIC : dns-zone-gke-elastic

Lien vers la liste des régions et des zones Google Cloud Platform

Gitlab Runner

Un Gitlab Runner est nécessaire pour le déploiement du projet. Si votre serveur Gitlab n'en possède pas, je vous invite à suivre cet article sur la mise en place d'un Gitlab Runner.

Création des manifests

Commençons par créer l'architecture de notre projet. Créer le dossier manifests ainsi que les sous-dossiers elastic, gke et psc. Vous devriez obtenir le résultat suivant :

.
├─ manifests/
|  └─ elastic/
|  └─ gke/
|  └─ psc/

À la racine du projet, créer le fichier .gitlab-ci.yml, avec le contenu ci-dessous :

image: busybox:latest

stages:
  - gke
  - psc
  - elastic

variables:
  TF_ROOT_ELASTIC: ${CI_PROJECT_DIR}/manifests/elastic
  TF_ROOT_GKE: ${CI_PROJECT_DIR}/manifests/gke
  GCLOUD_ROOT_PSC: ${CI_PROJECT_DIR}/manifests/psc

cache:
  - key: elastic
    paths:
      - ${TF_ROOT_ELASTIC}/.terraform
  - key: gke
    paths:
      - ${TF_ROOT_GKE}/.terraform

check-gke:
  stage: gke
  image:
    name: registry.gitlab.com/gitlab-org/terraform-images/stable:latest
    entrypoint: [""]
  before_script:
    - |
  script:
    - |

apply-gke:
  stage: gke
  needs:
    - check-gke
  image:
    name: registry.gitlab.com/gitlab-org/terraform-images/stable:latest
    entrypoint: [""]
  before_script:
    - |
  script:
    - |

gcloud-psc:
  stage: psc
  needs:
    - apply-gke
  image:
    name: google/cloud-sdk:slim
    entrypoint: [""]
  before_script:
    - |
  script:
    - |

check-elastic:
  stage: elastic
  needs:
    - gcloud-psc
  image:
    name: registry.gitlab.com/gitlab-org/terraform-images/stable:latest
    entrypoint: [""]
  before_script:
    - |
  script:
    - |

apply-elastic:
  stage: elastic
  needs:
    - check-elastic
  image:
    name: registry.gitlab.com/gitlab-org/terraform-images/stable:latest
    entrypoint: [""]
  before_script:
    - |
  script:
    - |

À cette base de travail, nous allons ajouter les variables, scripts... nécessaires au déploiement. Chaque job est décrit ci-dessous.

Job : check-gke

Nous allons définir ici les vérifications requises pour les manifests Terraform du déploiement du cluster GKE.

Tout d'abord, il faut définir les variables. Il existe 3 types de variables.

La première TF_ADDRESS permet de spécifier à Gitlab le dossier où sera stocké l'état du déploiement Terraform. Pour rappel, nous utilisons une fonctionnalité de GitLab.

Le second type TF_VAR_... sont les variables utilisées par les manifests Terraform. En les définissant en variables d'environnement, nous évitons de les ajouter aux commandes plan, apply et/ou destroy.

Le dernier type de variable contient le compte de service (Service account) Google Cloud Platform qui nous permettra de réaliser le déploiement au sein du projet GCP.

Ensuite, nous déclarons les scripts. Avant de d'exécuter les commandes Terraform, nous dirigeons le runner dans le dossier des manifests gke. Puis, le fichier gcp-sa.json est créé, ce dernier contient le compte de service.

Le dernier bloc du job créé un fichier plan.json dans le cache dans le but d'être réutilisé dans le job apply-gke.

check-gke:
  stage: gke
  image:
    name: registry.gitlab.com/gitlab-org/terraform-images/stable:latest
    entrypoint: [""]
  variables:
    TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/gke
    TF_VAR_ec_apikey: $EC_API_KEY
    TF_VAR_project_id: $GCP_PROJECT_ID
    TF_VAR_region: $GCP_REGION
    TF_VAR_vpc_network_name: $GCP_NETWORK_NAME
    TF_VAR_vpc_subnetwork_name: $GCP_SUBNETWORK_NAME
    GCP_SA: $GCP_SA
  before_script:
    - |
      cd $TF_ROOT_GKE
      echo $GCP_SA > gcp-sa.json
  script:
    - |
      gitlab-terraform init
      gitlab-terraform validate
      gitlab-terraform fmt -check
      gitlab-terraform plan
      gitlab-terraform plan-json
  artifacts:
    name: plan
    paths:
      - ${TF_ROOT_GKE}/plan.cache
    reports:
      terraform: ${TF_ROOT_GKE}/plan.json

Job : apply-gke

Ce job va déployer le cluster GKE. La directive needs indique que le job a besoin du précédent avant d'être exécuté.

Le job est identique au précédent excepté pour la partie script où nous appliquons les directives des manifests.

apply-gke:
  stage: gke
  needs:
    - check-gke
  image:
    name: registry.gitlab.com/gitlab-org/terraform-images/stable:latest
    entrypoint: [""]
  variables:
    TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/gke
    TF_VAR_ec_apikey: $EC_API_KEY
    TF_VAR_project_id: $GCP_PROJECT_ID
    TF_VAR_region: $GCP_REGION
    TF_VAR_vpc_network_name: $GCP_NETWORK_NAME
    TF_VAR_vpc_subnetwork_name: $GCP_SUBNETWORK_NAME
    GCP_SA: $GCP_SA
  before_script:
    - |
      cd $TF_ROOT_GKE
      echo $GCP_SA > gcp-sa.json
  script:
    - |
      gitlab-terraform init
      gitlab-terraform apply -auto-approve

Job : gcloud-psc

Une fois le cluster GKE déployé, nous allons pouvoir créer le Private Service Connect qui nous permettra d'interconnecter les 2 clusters entre eux.

Comme précédemment, nous utilisons la directive needs, car nous devons avoir déployé un VPC avec de créer l'interconnexion. Nous changeons l'image Docker, car nous utiliserons le Google Cloud SDK, ainsi que les variables.

Dans la directive before_script, nous récupérons le contenu de la variable $GCP_SA pour créer un fichier JSON comprenant la clé du compte de service. Ceci va nous permettre de s'authentifier et de pouvoir sélectionner le projet sur lequel nous allons exécuter notre script setting-psc.sh.

Vous noterez que le job créé un artifact. Ce dernier contiendra l'identifiant du PSC pour être utilisé dans la création du filtre de trafic dans Elastic Cloud.

gcloud-psc:
  stage: psc
  needs:
    - apply-gke
  image:
    name: google/cloud-sdk:slim
    entrypoint: [""]
  variables:
    GCP_PROJECT_ID: $GCP_PROJECT_ID
    GCP_SA: $GCP_SA
    GCP_REGION: $GCP_REGION
    GCP_NETWORK_NAME: $GCP_NETWORK_NAME
    GCP_SUBNETWORK_NAME: $GCP_SUBNETWORK_NAME
    GCP_INTERNAL_IP_NAME: $GCP_INTERNAL_IP_NAME
    GCP_PSC_NAME: $GCP_PSC_NAME
    GCP_DNS_ZONE_GKE_ELASTIC: $GCP_DNS_ZONE_GKE_ELASTIC
    EC_SERVICE_ATTACHMENT_URI: $EC_SERVICE_ATTACHMENT_URI
    EC_DNS_ZONE: $EC_DNS_ZONE
  before_script:
    - |
      echo $GCP_SA > gcp-sa.json
      gcloud auth activate-service-account --key-file gcp-sa.json
      echo "Activate Service Account: OK"
      gcloud config set project $GCP_PROJECT_ID
      echo "Set Project: OK"
      cd $GCLOUD_ROOT_PSC
  script:
    - |
      chmod +x ./setting-psc.sh
      ./setting-psc.sh
  artifacts:
    paths:
      - ${CI_PROJECT_DIR}/pscConnectionId.env

Job : check-elastic

Ce job est identique à check-gke, il permet d'exécuter les commandes d'initialisation, de validation, de contrôle de la structure du manifest Terraform et d'indiquer ce qui va être déployé dans le job suivant.

Seule particularité ici, nous récupérons le contenu du fichier pscConnectionId.env, créé dans le job précédent, pour définir une variable TF_VAR_psc_connection_id nécessaire pour le déploiement du filtre de trafic au sein du cluster Elastic.

check-elastic:
  stage: elastic
  needs:
    - gcloud-psc
  image:
    name: registry.gitlab.com/gitlab-org/terraform-images/stable:latest
    entrypoint: [""]
  variables:
    TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/elastic
    TF_VAR_ec_apikey: $EC_API_KEY
  before_script:
    - |
      export TF_VAR_psc_connection_id=$(cat ${CI_PROJECT_DIR}/pscConnectionId.env | grep GCP_PSC_CONNECTION_ID | cut -d = -f2)
      cd $TF_ROOT_ELASTIC
  script:
    - |
      gitlab-terraform init
      gitlab-terraform validate
      gitlab-terraform fmt -check
      gitlab-terraform plan
      gitlab-terraform plan-json
  artifacts:
    name: plan
    paths:
      - ${TF_ROOT_ELASTIC}/plan.cache
    reports:
      terraform: ${TF_ROOT_ELASTIC}/plan.json

Job : check-elastic

Ici, nous déployons le cluster Elastic Cloud. Ceci est la dernière étape de notre déploiement continu.

apply-elastic:
  stage: elastic
  needs:
    - check-elastic
  image:
    name: registry.gitlab.com/gitlab-org/terraform-images/stable:latest
    entrypoint: [""]
  variables:
    TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/elastic
    TF_VAR_ec_apikey: $EC_API_KEY
  before_script:
    - |
      export TF_VAR_psc_connection_id=$(cat ${CI_PROJECT_DIR}/pscConnectionId.env | grep GCP_PSC_CONNECTION_ID | cut -d = -f2)
      cd $TF_ROOT_ELASTIC
  script:
    - |
      gitlab-terraform init
      gitlab-terraform apply -auto-approve

Pour vérifier si le runner fonctionne, ouvrez votre projet dans votre navigateur et cliquer dans le menu CI/CD, puis ouvrez la page Jobs. Vous devriez avoir une ligne avec le status passed pour votre job.

Manifests

Au sein de notre projet, nous avons désormais la structure suivante :

.
├─ manifests/
|  └─ elastic/
|  └─ gke/
|  └─ psc/
|  .gitlab-ci.yml

Il faut désormais créer les manifests Terraform pour nos clusters. Pour cette partie, je vous invite à récupérer les fichiers au sein du dépôt Froggit de cet article, lien vers le dépôt.

Par contre, je vais m'attarder un peu plus sur le fichier setting-psc.sh qui doit être créé au sein du dossier psc de notre projet. Commençons par ajouter le shebang :

#!/bin/bash

Le fichier sera découpé 5 parties :

Activation de l'accès privé à Google
Création d'une adresse IP interne
Création d'une règle de transfert
Création d'une zone DNS
Récupération de l'identifiant du PSC

Chaque partie de code contient une commande de contrôle où la valeur retournée est stockée dans une variable. Cette dernière est testée, puis en fonction du résultat, une ou plusieurs commandes sont exécutées.

Pour vérifier et/ou activer l'accès privé à Google, ajouter le bloc ci-dessous dans le fichier :

PRIVATE_IP_ENABLED=$(gcloud compute networks subnets describe $GCP_SUBNETWORK_NAME --region=$GCP_REGION --format="get(privateIpGoogleAccess)")

if [[ $PRIVATE_IP_ENABLED == "True" ]]; then
  echo 'PRIVATE_IP_ENABLED'
else
  gcloud compute networks subnets update $GCP_SUBNETWORK_NAME --region=$GCP_REGION --enable-private-ip-google-access
fi

On stocke dans une variable la valeur de privateIpGoogleAccess renvoyée par la commande qui nous permet de détailler les caractéristiques du sous-réseau. Dans le cas où l'accès privé à Google n'est pas activé, nous exécutons la commande pour activer l'accès privé au sein du sous-réseau.

Ensuite, nous allons créer l'adresse IP interne dans le sous-réseau, si elle est inexistante.

ADDRESS_CREATED=$(gcloud compute addresses describe $GCP_INTERNAL_IP_NAME --region=$GCP_REGION --format="get(status)")

if [[ $ADDRESS_CREATED == "IN_USE" ]]; then
  echo 'ADDRESS_CREATED'
else
  gcloud compute addresses create $GCP_INTERNAL_IP_NAME --region=$GCP_REGION --subnet=$GCP_SUBNETWORK_NAME
fi

La règle de transfert permet au point de terminaison PSC de se connecter aux services Google. Ici, nous crééons une règle de transfert à destination du Service Attachment d'Elastic Cloud.

FORWARDING_RULE_ACCEPTED=$(gcloud compute forwarding-rules describe $GCP_PSC_NAME --region=$GCP_REGION --format="get(pscConnectionStatus)")

if [[ $FORWARDING_RULE_ACCEPTED == "ACCEPTED" ]]; then
  echo 'FORWARDING_RULE_ACCEPTED'
else
  gcloud compute forwarding-rules create $GCP_PSC_NAME --region=$GCP_REGION --network=$GCP_NETWORK_NAME --address=$GCP_INTERNAL_IP_NAME --target-service-attachment=$EC_SERVICE_ATTACHMENT_URI
fi

Pour faciliter la connexion au cluster Elastic Cloud, nous allons définir une zone DNS. La création d'une zone DNS s'effectue en 2 étapes, la création de la zone puis la création des enregistrements.

Pour créer un enregistrement, il est nécessaire d'exécuter une transaction qui débute par la commande gcloud dns record-sets transaction start ... et se termine par gcloud dns record-sets transaction execute ... au sein de la zone DNS.

gcloud dns managed-zones describe $GCP_DNS_ZONE_GKE_ELASTIC > /dev/null 2>&1
DNS_ZONE_CREATED=$?

if [[ $DNS_ZONE_CREATED == 0 ]]; then
  echo 'DNS_ZONE_CREATED'
else
  gcloud dns managed-zones create $GCP_DNS_ZONE_GKE_ELASTIC --description="Managed by GitLab CI" --dns-name=$EC_DNS_ZONE. --visibility=private --networks=$GCP_NETWORK_NAME
  gcloud dns record-sets transaction start --zone="$GCP_DNS_ZONE_GKE_ELASTIC"
  gcloud dns record-sets transaction add $(gcloud compute addresses describe $GCP_INTERNAL_IP_NAME --region=$GCP_REGION --format="get(address)") --name="*.$EC_DNS_ZONE." --ttl="30" --type="A" --zone="$GCP_DNS_ZONE_GKE_ELASTIC"
  gcloud dns record-sets transaction execute --zone="$GCP_DNS_ZONE_GKE_ELASTIC"
fi

Pour terminer notre script, nous stockons dans un fichier la variable GCP_PSC_CONNECTION_ID. Comme vu précédemment, cette dernière sera utilisée pour la création du filtre de trafic au sein du manifest Elastic.

echo "GCP_PSC_CONNECTION_ID=$(gcloud compute forwarding-rules describe $GCP_PSC_NAME --region=$GCP_REGION --format="get(pscConnectionId)")" > ${CI_PROJECT_DIR}/pscConnectionId.env

Déploiement

Une fois que votre projet contient l'ensemble des fichiers ci-dessous, vous devriez pouvoir commit et push votre projet au sein de votre dépôt Gitlab.

.
├─ manifests/
|  └─ elastic/
|       main.tf
|       outputs.tf
|       variables.tf
|  └─ gke/
|       main.tf
|       outputs.tf
|       variables.tf
|  └─ psc/
|       setting-psc.sh
|  .gitlab-ci.yml

Une fois les fichiers envoyés sur le serveur, connectez-vous à votre projet Gitlab et ouvrez la page CI/CD > Pipelines. Vous devriez avoir un nouveau pipeline en cours d'exécution.

Maintenant, il faut attendre patiemment que le déploiement soit entièrement finalisé avant de contrôler que l'interconnexion est opérationnelle.

Récupérer le cluster ID du cluster Elastic

Une fois le cluster Elastic déployé, il est nécessaire de récupérer 2 informations, le cluster ID et le mot de passe de l'utilisateur du cluster.

Le cluster ID permet d'identifier le serveur Elastic du cluster lors de la connexion avec le PSC que nous avons créé. Pour récupérer cette valeur, connectez-vous à la page Deployments de votre compte Elastic, lien vers la page. Puis cliquer sur votre déploiement. Cliquer ensuite sur Copy cluster ID.

Profitons également d'être connecter à Elastic pour réinitialiser le mot de passe du cluster de l'utilisateur nommé elastic.

Dans la page du déploiement, cliquer sur Manage > Reset password et pour terminer Reset password.

Noter ou télécharger le mot de passe généré automatiquement, car nous en aurons besoin pour réaliser le test de connexion entre les 2 clusters.

Lien vers la documentation Elastic

Vérification de l'interconnexion

Pour contrôler que les 2 clusters communiquent entre eux, je vous invite à ouvrir, dans la console Google Cloud Platform, le Cloud Shell pour vous connecter au cluster GKE. Pour ce faire, remplacer les valeurs de <gcp_project_id> avant de lancer la commande :

gcloud container clusters get-credentials gke --region europe-west1 --project <gcp_project_id>

Vous pouvez créer le fichier utils.yaml avec le contenu ci-dessous. Ceci nous permettra de lancer un curl pour contrôler la connexion au cluster Elastic.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: utils-deployment
  labels:
    app: utils
spec:
  replicas: 1
  selector:
    matchLabels:
      app: utils
  template:
    metadata:
      labels:
        app: utils
    spec:
      containers:
      - name: utils
        image: debian:stable-slim
        command: ["tail", "-f", "/dev/null"]

Lancer la commande kubectl apply -f utils.yaml puis la commande kubectl get pods. Récupérer le nom du pod qui a l'état running.

Exécuter la commande kubectl exec -it <nopm-du-pod> -- bash qui nous permet d'exécuter un shell dans le conteneur en cours d'exécution.

Au sein du pod, lancer la commande apt-get update && apt-get install curl jq pour installer curl et jq. Une fois l'installation réussie, vous pouvez lancer la commande après avoir modifié les valeurs <mot-de-passe-elastic> et <cluster-id>:

curl -u elastic:<mot-de-passe-elastic> https://<cluster-id>.psc.europe-west1.gcp.cloud.es.io | jq .tagline

Le retour de cette commande devrait être "You Know, for Search".

Destruction

Pour faciliter le travail de destruction de l'ensemble du déploiement ci-dessus, vous trouverez, dans le dépôt Froggit de cet article, la CD permettant de réaliser la destruction ainsi que le script destroy-psc.sh.

Section title

Déployer et interconnecter 2 clusters GKE et Elastic Cloud

Pré-requis

Préparation

Gitlab

EC_API_KEY

EC_DNS_ZONE et EC_SERVICE_ATTACHMENT_URI

GCP_PROJECT_ID

GCP_SA

Les autres variables GCP

Gitlab Runner

Création des manifests

Job : check-gke

Job : apply-gke

Job : gcloud-psc

Job : check-elastic

Job : check-elastic

Manifests

Déploiement

Récupérer le cluster ID du cluster Elastic

Vérification de l'interconnexion

Destruction

Sources