Contrôleur d'entrée Citrix ADC

Déployer la solution de déploiement Canary intégrée à Citrix ADC

La version Canary est une technique visant à réduire le risque d’introduction d’une nouvelle version logicielle en production en déployant d’abord la modification à un petit sous-ensemble d’utilisateurs. Après la validation de l’utilisateur, l’application est déployée auprès du plus grand nombre d’utilisateurs.

Citrix fournit les options suivantes pour le déploiement Canary à l’aide du Citrix ingress controller.

Dans un déploiement utilisant le CRD Canary, la configuration Canary est appliquée à l’aide d’un CRD Kubernetes. Citrix prend également en charge une option beaucoup plus simple pour le déploiement Canary à l’aide des annotations Ingress.

Déployer Canary en utilisant le CRD Canary

Cette section fournit des informations sur la façon d’effectuer un déploiement Canary à l’aide du CRD Canary.

La solution de déploiement Canary intégrée à Citrix ADC regroupe tous les composants de la livraison continue (CD) et facilite le déploiement de Canary pour les développeurs d’applications. Cette solution utilise Spinnaker comme plateforme de livraison continue et Kayenta comme plug-in Spinnaker pour l’analyse des canaris. Kayenta est un service d’analyse Canary open source qui récupère les mesures configurées par l’utilisateur à partir de leurs sources, exécute des tests statistiques et fournit un score agrégé pour le Canary. Le score des tests statistiques et des compteurs ainsi que les critères de réussite sont utilisés pour promouvoir ou échouer le canari.

Citrix ADC est livré avec un riche module de configuration centré sur les applications et fournit une visibilité complète sur le trafic des applications et la santé des instances d’application. Les capacités de Citrix ADC pour générer des statistiques de performances précises peuvent être exploitées pour l’analyse Canary afin de prendre de meilleures décisions concernant le déploiement de Canary. Dans cette solution, Citrix ADC est intégré à la plateforme Spinnaker et sert de source pour fournir des mesures précises pour l’analyse du déploiement Canary à l’aide de Kayenta.

Citrix ADC Metrics Exporter exporte les mesures de performance de l’application vers le système de surveillance open source Prometheus et vous pouvez configurer Kayenta pour récupérer les mesures pour le déploiement Canary. La distribution du trafic vers la version Canary peut être régulée à l’aide de l’infrastructure de stratégie Citrix ADC. Si vous souhaitez détourner un type de trafic spécifique de la production vers la ligne de base et Canary, vous pouvez utiliser des expressions de correspondance pour rediriger le trafic vers la ligne de base et Canary en tirant parti de la riche infrastructure de stratégie Citrix ADC.

Par exemple, vous pouvez détourner le trafic de la production vers Canary et la ligne de base à l’aide de l’expression de correspondance HTTP.REQ.URL.CONTAINS (« citrix india »). Le trafic qui correspond à l’expression est détourné vers Canary et Baseline et le reste du trafic passe en production.

Les composants qui font partie de la solution de déploiement Canary intégrée à Citrix et leurs fonctionnalités sont expliqués comme suit :

  • GitHub : GitHub offre toutes les fonctionnalités de contrôle de version distribué et de gestion du code source fournies par Git et possède des fonctionnalités supplémentaires. GitHub propose de nombreux utilitaires pour l’intégration à d’autres outils qui font partie de votre pipeline CI/CD, tels que Docker Hub et Spinnaker.

  • Docker Hub : Docker Hub est un service de référentiel basé sur le cloud fourni par Docker pour partager et trouver des images Docker. Vous pouvez intégrer GitHub à Docker Hub pour créer automatiquement des images à partir du code source dans GitHub et envoyer l’image créée vers Docker Hub.

  • Spinnaker : Spinnaker est une plateforme de diffusion continue multi-cloud open source qui permet de publier des modifications logicielles avec une grande rapidité et fiabilité. Vous pouvez utiliser les fonctionnalités de déploiement d’applications de Spinnaker pour construire et gérer des flux de travail de livraison continue. La construction clé de gestion du déploiement dans Spinnaker est connue sous le nom de pipeline. Les pipelines de Spinnaker consistent en une séquence d’actions, appelée étapes. Spinnaker propose différentes étapes pour le déploiement d’une application, l’exécution d’un script, l’exécution d’une analyse Canary, la suppression du déploiement, etc. Vous pouvez intégrer Spinnaker à de nombreux outils tiers pour prendre en charge de nombreuses fonctionnalités supplémentaires.

  • Prometheus : Prometheus est une boîte à outils open source de surveillance et d’alerte des systèmes. Prometheus est un système de surveillance capable de conserver une énorme quantité de données dans une base de données de séries chronologiques. Citrix ADC Metrics expose les mesures de performance à Spinnaker via Prometheus.

  • Jenkins : Jenkins est un serveur d’automatisation open source qui permet d’automatiser toutes sortes de tâches liées à la création, au test, à la livraison ou au déploiement de logiciels. Jenkins prend également en charge l’exécution de scripts personnalisés dans le cadre de votre cycle de déploiement.

  • Citrix fournit un Ingress Controller pour Citrix ADC MPX (matériel), Citrix ADC VPX (virtualisé) et Citrix ADC CPX (conteneurisé) pour les déploiements bare metal et cloud. Le Citrix ingress controller est construit autour de Kubernetes Ingress et configure automatiquement un ou plusieurs Citrix ADC en fonction de la configuration de la ressource Ingress.

Les versions logicielles Citrix suivantes sont requises pour la solution de déploiement Canary intégrée à Citrix :

  • Construction/version du Citrix ingress controller : quay.io/citrix/citrix-k8s-ingress-controller:1.26.7.
  • Version de Citrix ADC CPX : quay.io/citrix/citrix-k8s-cpx-ingress:13.0-83.27.
  • Version de l’exportateur de métriques Citrix ADC : quay.io/citrix/netscaler-metrics-exporter:1.4.0.

Workflow d’un pipeline Spinnaker pour la solution de déploiement Canary intégrée à Citrix ADC

Le diagramme suivant explique le flux de travail d’un pipeline Spinnaker pour la solution de déploiement Canary intégrée à Citrix ADC.

Spinnaker_pipeline

Les étapes suivantes expliquent le flux de travail spécifié dans le diagramme.

  1. Les développeurs maintiennent le code source dans GitHub, apportent des modifications chaque fois que nécessaire et valident les modifications sur GitHub.
  2. Un webhook est configuré dans GitHub pour écouter les modifications du code source. Chaque fois que le code source est intégré à GitHub, le webhook est déclenché et informe Docker Hub de créer l’image avec le nouveau code source. Une fois l’image docker créée, un webhook distinct configuré dans Docker Hub déclenche un pipeline Spinnaker.
  3. Une fois le pipeline Spinnaker déclenché, les versions Canary et Baseline de l’image sont déployées.
  4. Une fois les versions Canary et de référence déployées, un certain pourcentage du trafic de production est redirigé vers les versions Canary et de référence. Citrix ADC collecte les statistiques de performances et les exporte vers Prometheus à l’aide de Citrix ADC Metrics Exporter. Prometheus transmet ces statistiques à Kayenta pour analyse canari.

  5. Kayenta effectue une analyse Canary basée sur les statistiques de performance et génère un score. Sur la base du score, le déploiement Canary est qualifié de réussite ou d’échec et l’image est déployée ou annulée.

Déployer la solution de déploiement Canary intégrée à Citrix ADC dans Google Cloud Platform

Cette section contient des informations sur la configuration de Spinnaker, comment créer un pipeline Spinnaker et un exemple de déploiement Canary.

Déployer Spinnaker dans Google Cloud Platform

Cette rubrique contient des informations sur le déploiement de Spinnaker et sur la façon d’intégrer des plug-ins avec Spinnaker pour un déploiement Canary sur Google Cloud Platform (GCP).

Effectuez les étapes suivantes pour déployer Spinnaker et intégrer des plug-ins dans GCP.

  1. Configurez l’environnement et créez un cluster GKE à l’aide des commandes suivantes.

    export GOOGLE_CLOUD_PROJECT=[PROJECT_ID] 
    gcloud config set project $GOOGLE_CLOUD_PROJECT 
    gcloud config set compute/zone us-central1-f
    gcloud services enable container.googleapis.com
    gcloud beta container clusters create kayenta-tutorial 
    --machine-type=n1-standard-2 --enable-stackdriver-kubernetes
    
  2. Installez le plug-in pour intégrer Prometheus à Stackdriver à l’aide de la commande suivante.

    kubectl apply --as=admin --as-group=system:masters -f \
    https://storage.googleapis.com/stackdriver-prometheus-documentation/rbac-setup.yml
    curl -sS "https://storage.googleapis.com/stackdriver-prometheus-documentation/prometheus-service.yml" | 
    \sed "s/_stackdriver_project_id:.*/_stackdriver_project_id: $GOOGLE_CLOUD_PROJECT/" | 
    \sed "s/_kubernetes_cluster_name:.*/_kubernetes_cluster_name: kayenta-tutorial/" | 
    \sed "s/_kubernetes_location:.*/_kubernetes_location: us-central1-f/" | 
    \kubectl apply -f -
    
  3. Déployez Spinnaker dans le cluster GKE en suivant les étapes suivantes.

    1. Téléchargez le fichier quick-install.yml pour Spinnaker sur le site de Spinnaker .
    2. Mettez à jour le fichier quick-install.yml pour intégrer différents composants à partir de Docker Hub. Pour intégrer Spinnaker à Docker Hub, mettez à jour les valeurs de l’adresse, du nom d’utilisateur, du mot de passe, de l’e-mail et du référentiel sous ConfigMap dans le fichier quick-install.yml.

      dockerRegistry:
                  enabled: true
                  accounts:
                  - name: my-docker-registry
                  requiredGroupMembership: []
                  providerVersion: V1
                  permissions: {}
                  address: https://index.docker.io
                  username: <username>
                  password: <password>
                  email: <mail-id>
                  cacheIntervalSeconds: 30
                  clientTimeoutMillis: 60000
                  cacheThreads: 1
                  paginateSize: 100
                  sortTagsByDate: false
                  trackDigests: false
                  insecureRegistry: false
                  repositories:- <repository-name>
                  primaryAccount: my-docker-registry
      
    3. (Facultatif) Effectuez les étapes suivantes pour configurer Jenkins.

      sudo apt-get update
      sudo apt-get upgrade
      sudo apt-get install openjdk-8-jdk
      wget -q -O - https://jenkins-ci.org/debian/jenkins-ci.org.key |       
      sudo apt-key add -
      sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'
      sudo apt-get update
      sudo apt-get install jenkins git
      sudo apt-get install software-properties-common python-software-properties apt-transport-https
      sudo add-apt-repository https://dl.bintray.com/spinnaker-releases/debians
      

      Remarque :

      Si Jenkins est installé sur l’un des nœuds de Kubernetes, vous devez mettre à jour les règles de pare-feu pour ce nœud pour un accès public.

    4. Mettez à jour les valeurs suivantes dans le fichier quick-install.yml pour intégrer Jenkins à Spinnaker.

          data:igor.yml: |
      enabled: true
      skipLifeCycleManagement: false
          ci:jenkins:
      enabled: true
        masters: 
      - name: master
            address: <endpoint>
          username: <username>
        password: <password>
      
    5. Pour configurer Prometheus et Grafana, reportez-vous à la section Intégration Prometheus et Grafana dans Citrix ADC Metrics Exporter et suivez les étapes.

    6. Pour intégrer Prometheus à Spinnaker, mettez à jour les valeurs suivantes dans le fichier quick-install.yml.

        data:
        config: | 
          deploymentConfigurations:
          canary:
          enabled: true
      serviceIntegrations:
            - name: prometheus
        enabled: true
      accounts:
        - name: my-prometheus
      endpoint:
            baseUrl: prometheus-endpoint
          supportedTypes:
      - METRICS_STORE
        data:
        config: |
          deploymentConfigurations:
          metricStores:
            prometheus:
            enabled: true
            add_source_metalabels: true
            stackdriver:
        enabled: true
          period: 30
          enabled: true
      
    7. Pour intégrer Slack pour la notification avec Spinnaker, mettez à jour les valeurs suivantes dans le fichier quick-install.yml.

      data:
       config: |
        deploymentConfigurations:
         notifications:
          slack:
           enabled: true
            botName: <BotName>
            token: <token>
      
    8. Une fois tous les composants nécessaires intégrés, déployez Spinnaker en effectuant l’étape suivante.

      kubectl apply -f quick-install.yaml
      
    9. Vérifiez la progression du déploiement à l’aide de la commande suivante. Une fois le déploiement terminé, cette commande affiche tous les espaces comme Ready x/x.

      watch kubectl -n spinnaker get pods
      
  4. Une fois que vous avez déployé Spinnaker, vous pouvez tester le déploiement en suivant les étapes suivantes :

    1. Activez l’accès au Spinnaker en transférant un port local au composant deck de Spinnaker à l’aide de la commande suivante :

      DECK_POD=$(kubectl -n spinnaker get pods -l \
      cluster=spin-deck,app=spin \
      -o=jsonpath='{.items[0].metadata.name}')
      kubectl -n spinnaker port-forward $DECK_POD 8080:9000 >/dev/null &
      
    2. Pour accéder à Spinnaker, dans Cloud Shell, cliquez sur l’ icône Web Preview et sélectionnez Aperçu sur le port 8080.

      Remarque :

      Vous pouvez accéder à Spinnaker en toute sécurité ou via HTTP. Pour exposer Spinnaker en toute sécurité, utilisez le fichier spin-ingress-ssl.yaml pour déployer l’entrée. Une fois que l’application Spinnaker est exposée publiquement, vous pouvez utiliser le domaine attribué à Spinnaker ou l’adresse IP de l’entrée pour y accéder.

Créez un pipeline Spinnaker et configurez le déploiement automatisé de Canary

Une fois que vous avez déployé Spinnaker, créez un pipeline Spinnaker pour une application et configurez le déploiement automatisé Canary.

  1. Créez une application dans Spinnaker.
  2. Créez un pipeline Spinnaker. Vous pouvez modifier le pipeline en tant que fichier JSON à l’aide du fichier d’exemple fourni dans Exemples de fichiers JSON.
  3. Créez une configuration Canary automatisée dans Spinnaker pour une analyse Canary automatisée. Vous pouvez utiliser la configuration fournie dans le fichier JSON comme exemple de configuration automatique Canary Exemples de fichiers JSON.

Déployer un exemple d’application pour Canary

Cet exemple montre comment exécuter le déploiement Canary d’un exemple d’application à l’aide de la solution de déploiement Canary intégrée à Citrix ADC. Dans cet exemple, Citrix ADC CPX, MPX ou VPX est déployé en tant que périphérique d’entrée pour un cluster GKE. Citrix ADC génère les mesures de performance requises pour l’analyse Canary.

Au préalable, vous devez effectuer l’étape suivante avant de déployer l’exemple d’application.

Déployer l’exemple d’application

Effectuez les étapes suivantes pour déployer un exemple d’application en tant que version Canary.

  1. Créez les règles RBAC nécessaires pour Citrix ADC en déployant le fichier rbac.yaml .

    kubectl apply -f rbac.yaml 
    
  2. Vous pouvez déployer le Citrix ingress controller en tant que side-car avec Citrix ADC CPX ou en tant qu’espace autonome contrôlant Citrix ADC VPX ou MPX.

    Utilisez le fichier cpx-with-cic-sidecar.yml pour déployer le Citrix ingress controller en tant que sidecar avec Citrix ADC CPX. Il déploie également Citrix ADC Metrics Exporter sur le même espace.

    kubectl apply -f cpx-with-cic-sidecar.yml 
    

    Pour déployer le Citrix ingress controller en tant qu’espace autonome pour Citrix ADC VPX ou MPX, utilisez le fichier cic-vpx.yaml . Dans ce déploiement, vous devez utiliser le fichier exporter.yaml pour déployer Citrix ADC Metrics Exporter.

    kubectl apply -f cic-vpx.yaml
    kubectl apply -f exporter.yaml
    

    Remarque :

    Selon la façon dont vous déployez le Citrix ingress controller, vous devez modifier le fichier YAML pour le déploiement du Citrix ingress controller et modifier les valeurs des variables d’environnement comme indiqué dans le déploiement du Citrix ingress controller.

  3. Déployez l’entrée pour exposer Spinnaker en toute sécurité à l’aide du fichier spin-ingress-ssl.yaml .

    kubectl apply -f spin-ingress-ssl.yaml 
    

    Remarque :

    Pour plus d’informations sur la création d’un certificat TLS pour Ingress, consultez Certificats TLS dans Citrix Ingress Controller.

  4. Une fois que Spinnaker est exposé à l’aide de Citrix ADC, accédez à Spinnaker et effectuez les étapes décrites dans Créer un pipeline Spinnaker et configurez le déploiement automatique de Canary si les étapes ne sont pas déjà effectuées.

  5. Déployez la version de production de l’application à l’aide du fichier production.yaml .

    kubectl apply -f production.yaml 
    
  6. Créez la règle de ressource Ingress pour exposer le trafic provenant de l’extérieur du cluster aux services internes au cluster à l’aide du fichier ingress.yaml .

    kubectl apply -f ingress.yaml 
    
  7. Créez un service Kubernetes pour l’application qui nécessite un déploiement Canary à l’aide du fichier service.yaml .

    kubectl apply -f service.yaml
    
  8. Déployez le CRD Canary qui définit la configuration Canary à l’aide du fichier canary-crd-class.yaml .

    kubectl apply -f canary-crd-class.yaml
    

    Remarque :

    Une fois que vous avez créé le CRD, attendez 10 secondes avant d’appliquer l’objet CRD.

  9. Créez un objet CRD canary-crd-object.yaml basé sur le CRD Canary pour personnaliser la configuration Canary.

    kubectl apply -f canary-crd-object.yaml
    

    Le tableau suivant explique les champs de l’objet CRD Canary.

    Champ Description
    Noms de service Liste des services sur lesquels ce CRD doit être appliqué
    déploiement Spécifie la stratégie de déploiement en tant que Kayenta.
    pourcentage Spécifie le pourcentage de trafic à détourner de la production vers la configuration de référence et Canary.
    MatchExpression (facultatif) Toute stratégie prise en charge par Citrix ADC pouvant être utilisée pour définir le sous-ensemble d’utilisateurs à diriger vers les versions Canary et de référence. Si x pourcentage du trafic est configuré, alors à partir d’un sous-ensemble d’utilisateurs correspondant à MatchExpression, seul x pourcentage d’utilisateurs sont redirigés vers la ligne de base et Canary. Les utilisateurs restants sont redirigés vers la production.
    Spi Spécifie les configurations de pipeline Spinnaker que vous souhaitez appliquer à vos services.
    domaine Adresse IP ou nom de domaine du Spinnaker Gate.
    port Numéro de port de la porte Spinnaker.
    Nom de l’application Le nom de l’application dans Spinnaker.
    Nom du pipeline Le nom du pipeline sous l’application Spinnaker.
    Nom du service Spécifie le nom du service auquel vous souhaitez appliquer la configuration Spinnaker.
  10. Déployez les versions Canary et de référence de l’application.

    Remarque :

    Si vous automatisez entièrement le déploiement Canary, déployez les versions Canary et de référence à l’aide de l’ étape Deploy (Manifest) dans le pipeline Spinnaker et il n’est pas nécessaire d’effectuer cette étape.

    Pour déployer manuellement des versions Canary et de référence, utilisez les fichiers canary.yaml et baseline.yaml .

    kubectl apply -f canary.yaml
    kubectl apply -f baseline.yaml
    

Résolution des problèmes

Pour résoudre les problèmes liés au déploiement, effectuez les opérations suivantes.

  1. Vérifiez les journaux de l’espace pour les composants respectifs tels que Spinnaker, Prometheus, Kayenta, Citrix ADC CPX, Citrix ADC Metrics Exporter, Citrix ingress controller.
  2. Vérifiez les journaux de l’espace du Citrix ingress controller pour détecter toute erreur liée à la configuration lors de la configuration du proxy Citrix.
  3. Recherchez le mot-clé exception/Exception dans les journaux de l’espace du Citrix ingress controller pour réduire les problèmes.
  4. Vérifiez les journaux précédant la recherche. Vérifiez la configuration qui a échoué et qui est à l’origine du problème.
  5. Vérifiez la raison des défaillances lors de la configuration.
  6. Si l’échec s’est produit en raison d’une configuration incorrecte, corrigez la configuration.

Exemples de fichiers JSON

Cette rubrique contient des exemples de fichiers JSON pour la configuration du pipeline Spinnaker et la configuration automatisée Canary. Ces fichiers peuvent être utilisés comme référence lors de la création du pipeline Spinnaker et de la configuration automatisée Canary.

Un exemple de fichier JSON pour la configuration du pipeline Spinnaker**

{
  "appConfig": {},
  "description": "This pipeline deploys a canary version of the application, and a baseline (identical to production) version.\nIt compares them, and if the canary is OK, it triggers the production deployment pipeline.",
  "executionEngine": "v2",
  "expectedArtifacts": [
    {
      "defaultArtifact": {
        "kind": "custom"
      },
      "id": "ac842617-988f-48dc-a7a4-7f020d93cc42",
      "matchArtifact": {
        "kind": "docker",
        "name": "index.docker.io/sample/demo",
        "type": "docker/image"
      },
      "useDefaultArtifact": false,
      "usePriorExecution": false
    }
  ],
  "keepWaitingPipelines": false,
  "lastModifiedBy": "anonymous",
  "limitConcurrent": true,
  "parallel": true,
  "parameterConfig": [],
  "stages": [
    {
      "account": "my-kubernetes-account",
      "cloudProvider": "kubernetes",
      "kinds": [
        "Deployment",
        "ConfigMap"
      ],
      "labelSelectors": {
        "selectors": [
          {
            "key": "version",
            "kind": "EQUALS",
            "values": [
              "canary"
            ]
          }
        ]
      },
      "location": "default",
      "name": "Delete Canary",
      "options": {
        "cascading": true
      },
      "refId": "12",
      "requisiteStageRefIds": [
        "19",
        "26"
      ],
      "type": "deleteManifest"
    },
    {
      "account": "my-kubernetes-account",
      "cloudProvider": "kubernetes",
      "kinds": [
        "Deployment"
      ],
      "labelSelectors": {
        "selectors": [
          {
            "key": "version",
            "kind": "EQUALS",
            "values": [
              "baseline"
            ]
          }
        ]
      },
      "location": "default",
      "name": "Delete Baseline",
      "options": {
        "cascading": true
      },
      "refId": "13",
      "requisiteStageRefIds": [
        "19",
        "26"
      ],
      "type": "deleteManifest"
    },
    {
      "name": "Successful deployment",
      "preconditions": [],
      "refId": "14",
      "requisiteStageRefIds": [
        "12",
        "13"
      ],
      "type": "checkPreconditions"
    },
    {
      "application": "sampleapplicaion",
      "expectedArtifacts": [
        {
          "defaultArtifact": {
            "kind": "custom"
          },
          "id": "9185c756-c6cd-49bc-beee-e3f7118f3412",
          "matchArtifact": {
            "kind": "docker",
            "name": "index.docker.io/sample/demo",
            "type": "docker/image"
          },
          "useDefaultArtifact": false,
          "usePriorExecution": false
        }
      ],
      "failPipeline": true,
      "name": "Deploy to Production",
      "pipeline": "7048e5ac-2464-4557-a05a-bec8bdf868fc",
      "refId": "19",
      "requisiteStageRefIds": [
        "25"
      ],
      "stageEnabled": {
        "expression": ""${ #stage('Canary Analysis')['status'].toString() == 'SUCCEEDED'}"",
        "type": "expression"
      },
      "type": "pipeline",
      "waitForCompletion": true
    },
    {
      "account": "my-kubernetes-account",
      "cloudProvider": "kubernetes",
      "manifestArtifactAccount": "embedded-artifact",
      "manifests": [
        {
          "apiVersion": "apps/v1",
          "kind": "Deployment",
          "metadata": {
            "labels": {
              "name": "sampleapplicaion-prod",
              "version": "baseline"
            },
            "name": "sampleapplicaion-baseline-deployment",
            "namespace": "default"
          },
          "spec": {
            "replicas": 4,
            "strategy": {
              "rollingUpdate": {
                "maxSurge": 10,
                "maxUnavailable": 10
              },
              "type": "RollingUpdate"
            },
            "template": {
              "metadata": {
                "labels": {
                  "name": "sampleapplicaion-prod"
                }
              },
              "spec": {
                "containers": [
                  {
                    "image": "index.docker.io/sample/demo:v1",
                    "imagePullPolicy": "Always",
                    "name": "sampleapplicaion-prod",
                    "ports": [
                      {
                        "containerPort": 8080,
                        "name": "port-8080"
                      }
                    ]
                  }
                ]
              }
            }
          }
        }
      ],
      "moniker": {
        "app": "sampleapplicaion"
      },
      "name": "Deploy Baseline",
      "refId": "20",
      "relationships": {
        "loadBalancers": [],
        "securityGroups": []
      },
      "requisiteStageRefIds": [],
      "source": "text",
      "type": "deployManifest"
    },
    {
      "account": "my-kubernetes-account",
      "cloudProvider": "kubernetes",
      "manifestArtifactAccount": "embedded-artifact",
      "manifests": [
        {
          "apiVersion": "apps/v1",
          "kind": "Deployment",
          "metadata": {
            "labels": {
              "name": "sampleapplicaion-prod",
              "version": "canary"
            },
            "name": "sampleapplicaion-canary-deployment",
            "namespace": "default"
          },
          "spec": {
            "replicas": 4,
            "strategy": {
              "rollingUpdate": {
                "maxSurge": 10,
                "maxUnavailable": 10
              },
              "type": "RollingUpdate"
            },
            "template": {
              "metadata": {
                "labels": {
                  "name": "sampleapplicaion-prod"
                }
              },
              "spec": {
                "containers": [
                  {
                    "image": "index.docker.io/sample/demo",
                    "imagePullPolicy": "Always",
                    "name": "sampleapplicaion-prod",
                    "ports": [
                      {
                        "containerPort": 8080,
                        "name": "port-8080"
                      }
                    ]
                  }
                ]
              }
            }
          }
        }
      ],
      "moniker": {
        "app": "sampleapplicaion"
      },
      "name": "Deploy Canary",
      "refId": "21",
      "relationships": {
        "loadBalancers": [],
        "securityGroups": []
      },
      "requiredArtifactIds": [
        "ac842617-988f-48dc-a7a4-7f020d93cc42"
      ],
      "requisiteStageRefIds": [],
      "source": "text",
      "type": "deployManifest"
    },
    {
      "analysisType": "realTime",
      "canaryConfig": {
        "beginCanaryAnalysisAfterMins": "2",
        "canaryAnalysisIntervalMins": "",
        "canaryConfigId": "7bdb4ab4-f933-4a41-865f-6d3e9c786351",
        "combinedCanaryResultStrategy": "LOWEST",
        "lifetimeDuration": "PT0H5M",
        "metricsAccountName": "my-prometheus",
        "scopes": [
          {
            "controlLocation": "default",
            "controlScope": "k8s-sampleapplicaion.default.80.k8s-sampleapplicaion.default.8080.svc-baseline",
            "experimentLocation": "default",
            "experimentScope": "k8s-sampleapplicaion.default.80.k8s-sampleapplicaion.default.8080.svc-canary",
            "extendedScopeParams": {},
            "scopeName": "default"
          }
        ],
        "scoreThresholds": {
          "marginal": "0",
          "pass": "70"
        },
        "storageAccountName": "kayenta-minio"
      },
      "name": "Canary Analysis",
      "refId": "25",
      "requisiteStageRefIds": [
        "20",
        "21"
      ],
      "type": "kayentaCanary"
    },
    {
      "continuePipeline": false,
      "failPipeline": true,
      "job": "NJob",
      "master": "master",
      "name": "Auto Cleanup:  GCR Image and code revert",
      "parameters": {},
      "refId": "26",
      "requisiteStageRefIds": [
        "25"
      ],
      "stageEnabled": {
        "type": "expression"
      },
      "type": "jenkins"
    }
  ],
  "triggers": [
    {
      "account": "my-docker-registry",
      "enabled": true,
      "expectedArtifactIds": [
        "ac842617-988f-48dc-a7a4-7f020d93cc42"
      ],
      "organization": "sample",
      "payloadConstraints": {},
      "registry": "index.docker.io",
      "repository": "sample/demo",
      "source": "dockerhub",
      "type": "webhook"
    }
  ],
  "updateTs": "1553144362000"
}
<!--NeedCopy-->

Un exemple de fichier JSON pour la configuration automatisée de Canary

Voici un exemple de fichier JSON pour la configuration automatisée de Canary.

{
  "applications": [
    "sampleapplicaion"
  ],
  "classifier": {
    "groupWeights": {
      "Group 1": 70,
      "Group 2": 30
    },
    "scoreThresholds": {
      "marginal": 75,
      "pass": 95
    }
  },
  "configVersion": "1",
  "createdTimestamp": 1552650414234,
  "createdTimestampIso": "2019-03-15T11:46:54.234Z",
  "description": "Canary Config",
  "judge": {
    "judgeConfigurations": {},
    "name": "NetflixACAJudge-v1.0"
  },
  "metrics": [
    {
      "analysisConfigurations": {
        "canary": {
          "direction": "increase"
        }
      },
      "groups": [
        "Group 1"
      ],
      "name": "Server Response Errors - 5XX",
      "query": {
        "customFilterTemplate": "tot_requests",
        "metricName": "netscaler_lb_vserver_svr_busy_err_rate",
        "serviceType": "prometheus",
        "type": "prometheus"
      },
      "scopeName": "default"
    },
    {
      "analysisConfigurations": {
        "canary": {
          "direction": "either",
          "nanStrategy": "replace"
        }
      },
      "groups": [
        "Group 2"
      ],
      "name": "Server Response Latency - TTFB",
      "query": {
        "customFilterTemplate": "ttfb",
        "metricName": "netscaler_lb_vserver_hits_total",
        "serviceType": "prometheus",
        "type": "prometheus"
      },
      "scopeName": "default"
    }
  ],
  "name": "canary-config",
  "templates": {
    "tot_requests": "lb_vserver_name = "${scope}"",
    "ttfb": "lb_vserver_name = "${scope}""
  },
  "updatedTimestamp": 1553098513495,
  "updatedTimestampIso": "2019-03-20T16:15:13.495Z"
}
<!--NeedCopy-->

Déploiement Canary simplifié grâce aux annotations Ingress

Cette rubrique fournit des informations sur le déploiement simplifié de Canary à l’aide d’annotations d’entrée. Bien que Citrix propose plusieurs options pour prendre en charge le déploiement Canary, il s’agit d’un type de déploiement Canary plus simple.

Canary utilisant les annotations Ingress est un déploiement Canary basé sur des règles. Dans cette approche, vous devez définir un objet Ingress supplémentaire avec des annotations spécifiques pour indiquer que la demande d’application doit être traitée en fonction de la stratégie de déploiement Canary basée sur des règles. Dans la solution Citrix, le routage du trafic basé sur Canary au niveau de l’entrée peut être réalisé en définissant différents ensembles de règles comme suit :

  • Appliquer les règles Canary en fonction du poids
  • Appliquer les règles Canary en fonction de l’en-tête de requête HTTP
  • Appliquer les règles Canary en fonction de la valeur de l’en-tête HTTP

L’ordre de priorité des règles Canary est le suivant :

Canary par valeur d’en-tête de requête HTTP -> canari par en-tête de requête HTTP -> canari par poids

Déploiement Canary basé sur le poids

Le déploiement Canary basé sur le poids est une approche de déploiement Canary largement utilisée. Dans cette approche, vous pouvez définir le poids sur une plage comprise entre 0 et 100, ce qui détermine le pourcentage de trafic à diriger vers la version Canary et la version de production d’une application.

Voici le flux de travail pour le déploiement Canary basé sur le poids :

  • Au départ, le poids peut être réglé sur zéro, ce qui indique que le trafic n’est pas transféré vers la version Canary.

  • Une fois que vous avez décidé de démarrer le déploiement Canary, modifiez le poids sur le pourcentage requis pour vous assurer que le trafic est également dirigé vers la version Canary.

  • Enfin, lorsque vous déterminez que la version Canary est prête à être publiée, définissez le poids sur 100 pour vous assurer que tout le trafic est dirigé vers la version Canary.

Pour déployer Canary basé sur le poids à l’aide du Citrix ingress controller, créez une nouvelle entrée avec une annotation Canary ingress.citrix.com/canary-weight: et spécifiez le pourcentage de trafic à diriger vers la version Canary.

Déploiement Canary basé sur l’en-tête de requête HTTP

Vous pouvez configurer le déploiement Canary en fonction de l’en-tête de demande HTTP contrôlé par les clients. L’en-tête de demande indique à l’entrée d’acheminer la demande vers le service spécifié dans l’entrée Canary. Lorsque l’en-tête de demande contient la valeur mentionnée dans l’annotation Ingress ingress.citrix.com/canary-by-header:, la demande est acheminée vers le service spécifié dans Canary Ingress.

Déploiement Canary basé sur la valeur de l’en-tête de requête HTTP

Vous pouvez également configurer le déploiement Canary en fonction des valeurs de l’en-tête de requête HTTP qui est une extension de Canary by header. Dans ce déploiement, vous spécifiez également l’annotation ingress.citrix.com/canary-by-header: en même temps que l’annotation ingress.citrix.com/canary-by-header-value:. Lorsque la valeur de l’en-tête de demande correspond à la valeur spécifiée dans l’annotation Ingress, ingress.citrix.com/canary-by-header-value: la demande est acheminée vers le service spécifié dans Canary Ingress. Vous pouvez spécifier plusieurs valeurs d’en-tête sous forme de liste de chaînes.

Voici un exemple d’annotation pour le déploiement Canary basé sur les valeurs d’en-tête de requête HTTP :

ingress.citrix.com/canary-by-header-value: ‘[“value1”,”value2”,”value3”,”value4”]’

Configurer le déploiement Canary à l’aide des annotations d’

Effectuez les étapes suivantes pour déployer un exemple d’application en tant que version Canary.

  1. Déployez le Citrix ingress controller en suivant les étapes de la section Déployer le Citrix ingress controller. Vous pouvez déployer le Citrix ingress controller en tant que side-car avec Citrix ADC CPX ou en tant qu’espace autonome contrôlant Citrix ADC VPX ou MPX.

  2. Déployez l’application Guestbook à l’aide du fichier guestbook-deploy.yaml .

    kubectl apply -f guestbook-deploy.yaml
    
  3. Déployez un service pour exposer l’application Guestbook à l’aide du fichier guestbook-service.yaml .

    kubectl apply -f guestbook-service.yaml
    
  4. Déployez l’objet Ingress pour l’application Guestbook à l’aide du fichier guestbook-ingress.yaml .

      kubectl apply -f  guestbook-ingress.yaml
    
  5. Déployez une version Canary de l’application Guestbook à l’aide du fichier canary-deployment.yaml .

        kubectl apply –f canary-deployment.yaml
    
  6. Déployez un service pour exposer la version Canary de l’application Guestbook à l’aide du fichier canary-service.yaml .

        kubectl apply –f canary-service.yaml       
    
  7. Déployez un objet Ingress avec des annotations pour la version Canary de l’application Guestbook à l’aide du fichier canary-ingress.yaml .

        kubectl apply –f canary-ingress.yaml
    
    
    
          apiVersion: networking.k8s.io/v1
          kind: Ingress
          metadata:
            annotations:
              ingress.citrix.com/canary-weight: "10"
              kubernetes.io/ingress.class: citrix
            name: canary-by-weight
          spec:
            rules:
            - host: webapp.com
              http:
                paths:
                - backend:
                    service:
                      name: guestbook-canary
                      port:
                        number: 80
                  path: /
                  pathType: Prefix
    

    Here, the annotation ingress.citrix.com/canary-weight: “10” is the annotation for the weight based canary. This annotation specifies the Citrix ingress controller to configure the Citrix ADC in such a way that 10 percent of the total requests destined to webapp.com is sent to the guestbook-canary service. This is the service for the canary version of the Guestbook application.

Pour déployer le Canary basé sur l’en-tête HTTP à l’aide du Citrix ingress controller, remplacez l’annotation Canary ingress.citrix.com/canary-weight: par l’annotation ingress.citrix.com/canary-by-header: dans le fichier canary-ingress.yaml.

Pour déployer le Canary basé sur la valeur d’en-tête HTTP à l’aide du Citrix ingress controller, remplacez l’annotation ingress.citrix.com/canary-weight: par les annotations ingress.citrix.com/canary-by-header: et ingress.citrix.com/canary-by-header-value: dans le fichier canary-ingress.yaml.

Remarque :

Vous pouvez voir les exemples de YAML Canary pour obtenir Canary basé sur l’en-tête et Canary basé sur la valeur de l’en-tête.

Déployer la solution de déploiement Canary intégrée à Citrix ADC