Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

6.5. En utilisant des stratégies de déploiement basées sur la route

Les stratégies de déploiement permettent à l’application d’évoluer. Certaines stratégies utilisent des objets de déploiement pour apporter des modifications qui sont vues par les utilisateurs de tous les itinéraires qui se résolvent à l’application. D’autres stratégies avancées, telles que celles décrites dans cette section, utilisent des fonctions de routeur en conjonction avec des objets de déploiement pour avoir un impact sur des itinéraires spécifiques.

La stratégie la plus courante basée sur la route est d’utiliser un déploiement bleu-vert. La nouvelle version (la version verte) est présentée pour les tests et l’évaluation, tandis que les utilisateurs utilisent toujours la version stable (la version bleue). Lorsqu’ils sont prêts, les utilisateurs sont passés à la version verte. En cas de problème, vous pouvez revenir à la version bleue.

Alternativement, vous pouvez utiliser une stratégie de versions A/B dans laquelle les deux versions sont actives en même temps. Avec cette stratégie, certains utilisateurs peuvent utiliser la version A et d’autres utilisateurs peuvent utiliser la version B. Cette stratégie permet d’expérimenter des changements d’interface utilisateur ou d’autres fonctionnalités afin d’obtenir des commentaires des utilisateurs. Il peut également être utilisé pour vérifier le bon fonctionnement dans un contexte de production où les problèmes affectent un nombre limité d’utilisateurs.

Le déploiement canari teste la nouvelle version, mais lorsqu’un problème est détecté, il revient rapidement à la version précédente. Cela peut être fait avec les deux stratégies ci-dessus.

Les stratégies de déploiement basées sur la route n’évoluent pas le nombre de pods dans les services. Afin de maintenir les caractéristiques de performance souhaitées, les configurations de déploiement pourraient devoir être mises à l’échelle.

6.5.1. Éclats de proxy et fractionnement du trafic
Copier lien

Dans les environnements de production, vous pouvez contrôler avec précision la distribution du trafic qui atterrit sur un fragment particulier. Lorsque vous traitez d’un grand nombre d’instances, vous pouvez utiliser l’échelle relative des fragments individuels pour implémenter le trafic basé sur le pourcentage. Cela se combine bien avec un shard proxy, qui transmet ou divise le trafic qu’il reçoit à un service ou une application séparé fonctionnant ailleurs.

Dans la configuration la plus simple, le proxy transmet les requêtes inchangées. Dans les configurations plus complexes, vous pouvez dupliquer les requêtes entrantes et envoyer à la fois à un cluster séparé ainsi qu’à une instance locale de l’application, et comparer le résultat. D’autres modèles incluent la conservation des caches d’une installation DR au chaud, ou l’échantillonnage du trafic entrant à des fins d’analyse.

Chaque proxy TCP (ou UDP) pourrait être exécuté sous le shard désiré. La commande oc scale permet de modifier le nombre relatif d’instances qui servent des requêtes dans le shard proxy. Afin de gérer le trafic plus complexe, envisagez de personnaliser le service OpenShift Red Hat sur le routeur AWS avec des capacités d’équilibrage proportionnelles.

6.5.2. Compatibilité N-1
Copier lien

Les applications qui ont un nouveau code et un ancien code en même temps doivent veiller à ce que les données écrites par le nouveau code puissent être lues et traitées (ou gracieusement ignorées) par l’ancienne version du code. Cela s’appelle parfois l’évolution du schéma et est un problème complexe.

Cela peut prendre plusieurs formes: données stockées sur disque, dans une base de données, dans un cache temporaire, ou qui fait partie de la session du navigateur d’un utilisateur. Bien que la plupart des applications Web puissent prendre en charge les déploiements roulants, il est important de tester et de concevoir votre application pour la gérer.

Dans certaines applications, la période pendant laquelle l’ancien code et le nouveau code s’exécutent côte à côte est courte, de sorte que les bogues ou certaines transactions utilisateur échouées sont acceptables. Dans d’autres cas, le schéma d’échec peut entraîner la non-fonctionnalité de l’ensemble de l’application.

La validation de la compatibilité N-1 consiste à utiliser un déploiement A/B: exécuter l’ancien code et le nouveau code en même temps de manière contrôlée dans un environnement de test, et vérifier que le trafic qui s’écoule vers le nouveau déploiement ne provoque pas de défaillances dans l’ancien déploiement.

6.5.3. Résiliation gracieuse
Copier lien

Le service OpenShift Red Hat sur AWS et Kubernetes donne aux instances d’application le temps de s’arrêter avant de les retirer des rotations d’équilibrage de charge. Cependant, les applications doivent s’assurer qu’elles arrêtent proprement les connexions utilisateur avant leur sortie.

Lors de l’arrêt, Red Hat OpenShift Service sur AWS envoie un signal TERM aux processus dans le conteneur. Code de l’application, sur réception SIGTERM, arrêtez d’accepter de nouvelles connexions. Cela garantit que les balanceurs de charge acheminent le trafic vers d’autres instances actives. Le code de l’application attend ensuite jusqu’à ce que toutes les connexions ouvertes soient fermées, ou gracieusement mettre fin aux connexions individuelles à la prochaine occasion, avant de sortir.

Après l’expiration du délai de résiliation gracieux, un processus qui n’est pas sorti est envoyé le signal KILL, qui met immédiatement fin au processus. L’attribut terminaisonGracePeriodSeconds d’un modèle pod ou pod contrôle le délai de résiliation gracieux (par défaut 30 secondes) et peut être personnalisé par application si nécessaire.

6.5.4. Déploiements bleu-vert
Copier lien

Les déploiements bleu-vert impliquent l’exécution de deux versions d’une application en même temps et le déplacement du trafic de la version en production (la version bleue) à la version la plus récente (la version verte). Il est possible d’utiliser une stratégie mobile ou de changer de service dans un itinéraire.

Étant donné que de nombreuses applications dépendent de données persistantes, vous devez avoir une application qui prend en charge la compatibilité N-1, ce qui signifie qu’elle partage des données et implémente la migration en direct entre la base de données, le stockage ou le disque en créant deux copies de la couche de données.

Considérez les données utilisées pour tester la nouvelle version. Lorsqu’il s’agit des données de production, un bug dans la nouvelle version peut casser la version de production.

6.5.4.1. Configuration d’un déploiement bleu-vert
Copier lien

Les déploiements bleu-vert utilisent deux objets de déploiement. Les deux sont en cours d’exécution, et celui en production dépend du service que l’itinéraire spécifie, chaque objet de déploiement étant exposé à un service différent.

Note

Les itinéraires sont destinés au trafic Web (HTTP et HTTPS), de sorte que cette technique convient le mieux aux applications Web.

Il est possible de créer un nouvel itinéraire vers la nouvelle version et de le tester. Lorsque vous êtes prêt, modifiez le service dans la voie de production pour pointer vers le nouveau service et la nouvelle version (verte) est en direct.

Au besoin, vous pouvez revenir à l’ancienne version (bleue) en reconnectant le service à la version précédente.

Procédure

  1. Créez deux composants d’application indépendants.

    1. Créez une copie de l’application d’exemple exécutant l’image v1 sous le service example-blue: 

      $ oc new-app openshift/deployment-example:v1 --name=example-blue
      Copy to Clipboard Toggle word wrap

    2. Créez une deuxième copie qui utilise l’image v2 sous le service example-green: 

      $ oc new-app openshift/deployment-example:v2 --name=example-green
      Copy to Clipboard Toggle word wrap

  2. Créez un itinéraire qui pointe vers l’ancien service: 

    $ oc expose svc/example-blue --name=bluegreen-example
    Copy to Clipboard Toggle word wrap
  3. Accédez à l’application à bluegreen-example-<project>.<router_domain> pour vérifier que vous voyez l’image v1.

  4. Modifiez l’itinéraire et modifiez le nom du service en exemple-green: 

    $ oc patch route/bluegreen-example -p '{"spec":{"to":{"name":"example-green"}}}'
    Copy to Clipboard Toggle word wrap
  5. Afin de vérifier que l’itinéraire a changé, actualisez le navigateur jusqu’à ce que vous voyez l’image v2.

6.5.5. Déploiements a/B
Copier lien

La stratégie de déploiement A/B vous permet d’essayer une nouvelle version de l’application de manière limitée dans l’environnement de production. Il est possible de spécifier que la version de production reçoit la plupart des requêtes de l’utilisateur alors qu’une fraction limitée des requêtes vont à la nouvelle version.

Étant donné que vous contrôlez la partie des requêtes à chaque version, à mesure que le test progresse, vous pouvez augmenter la fraction des requêtes vers la nouvelle version et finalement arrêter d’utiliser la version précédente. Au fur et à mesure que vous ajustez la charge de requête sur chaque version, le nombre de pods dans chaque service peut devoir être mis à l’échelle aussi bien pour fournir les performances attendues.

En plus de mettre à niveau le logiciel, vous pouvez utiliser cette fonctionnalité pour expérimenter des versions de l’interface utilisateur. Comme certains utilisateurs obtiennent l’ancienne version et d’autres la nouvelle, vous pouvez évaluer la réaction de l’utilisateur aux différentes versions pour éclairer les décisions de conception.

Afin d’être efficace, les anciennes et les nouvelles versions doivent être suffisamment similaires pour que les deux puissent fonctionner en même temps. Ceci est courant avec les versions de correction de bogues et lorsque les nouvelles fonctionnalités n’interfèrent pas avec l’ancienne. Les versions nécessitent une compatibilité N-1 pour fonctionner correctement ensemble.

Le Red Hat OpenShift Service sur AWS prend en charge la compatibilité N-1 via la console Web ainsi que le CLI.

6.5.5.1. Équilibrage de charge pour les essais A/B
Copier lien

L’utilisateur met en place un itinéraire avec plusieurs services. Chaque service gère une version de l’application.

Chaque service se voit attribuer un poids et la partie des requêtes à chaque service est le service_weight divisé par le sum_of_weights. La pondération pour chaque service est répartie aux points de terminaison du service de sorte que la somme des pondérations du point de terminaison soit le poids du service.

L’itinéraire peut avoir jusqu’à quatre services. Le poids pour le service peut être compris entre 0 et 256. Lorsque le poids est 0, le service ne participe pas à l’équilibrage de charge, mais continue de desservir les connexions persistantes existantes. Lorsque le poids de service n’est pas 0, chaque point final a un poids minimum de 1. De ce fait, un service avec beaucoup de points finaux peut se retrouver avec un poids plus élevé que prévu. Dans ce cas, réduisez le nombre de gousses pour obtenir le poids attendu de l’équilibre de charge.

Procédure

La mise en place de l’environnement A/B:

  1. Créez les deux applications et donnez-leur des noms différents. Chacun crée un objet de déploiement. Les applications sont des versions du même programme; l’une est généralement la version de production actuelle et l’autre la nouvelle version proposée.

    1. Créez la première application. L’exemple suivant crée une application appelée ab-example-a: 

      $ oc new-app openshift/deployment-example --name=ab-example-a
      Copy to Clipboard Toggle word wrap

    2. Créer la deuxième application: 

      $ oc new-app openshift/deployment-example:v2 --name=ab-example-b
      Copy to Clipboard Toggle word wrap

      Les deux applications sont déployées et des services sont créés.

  2. Faites en sorte que l’application soit disponible à l’extérieur via un itinéraire. À ce stade, vous pouvez exposer non plus. Il peut être pratique d’exposer d’abord la version de production actuelle et de modifier plus tard l’itinéraire pour ajouter la nouvelle version. 

    $ oc expose svc/ab-example-a
    Copy to Clipboard Toggle word wrap

    Accédez à l’application ab-example-a.<project>.<router_domain> pour vérifier que vous voyez la version attendue.

  3. Lorsque vous déployez l’itinéraire, le routeur équilibre le trafic en fonction des poids spécifiés pour les services. À ce stade, il y a un seul service avec le poids par défaut=1 de sorte que toutes les requêtes vont à elle. L’ajout de l’autre service en tant que backends alternatif et l’ajustement des poids donnent vie à la configuration A/B. Cela peut être fait par la commande oc set route-backends ou en modifiant l’itinéraire.

    Note

    Lorsque vous utilisez des backends alternatifs, utilisez également la stratégie d’équilibrage de la charge de rotation pour s’assurer que les demandes sont distribuées comme prévu aux services en fonction du poids. la rondrobine peut être définie pour un itinéraire à l’aide d’une annotation de route. Consultez la section Ressources supplémentaires pour plus d’informations sur les annotations d’itinéraire.

    La définition d’oc set route-backend à 0 signifie que le service ne participe pas à l’équilibrage de charge, mais continue de desservir les connexions persistantes existantes.

    Note

    Les modifications apportées à l’itinéraire ne font que changer la portion du trafic vers les différents services. Il vous faudra peut-être mettre à l’échelle le déploiement pour ajuster le nombre de pods pour gérer les charges prévues.

    Afin de modifier l’itinéraire, exécutez: 

    $ oc edit route <route_name>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: route-alternate-service
  annotations:
    haproxy.router.openshift.io/balance: roundrobin
# ...
spec:
  host: ab-example.my-project.my-domain
  to:
    kind: Service
    name: ab-example-a
    weight: 10
  alternateBackends:
  - kind: Service
    name: ab-example-b
    weight: 15
# ...
    Copy to Clipboard Toggle word wrap

Procédure

  1. Accédez à la page Networking Routes.
  2. Cliquez sur le menu Options à côté de l’itinéraire que vous souhaitez modifier et sélectionnez Modifier l’itinéraire.
  3. Éditez le fichier YAML. Actualisez le poids pour être un entier entre 0 et 256 qui spécifie le poids relatif de la cible par rapport aux autres objets de référence cibles. La valeur 0 supprime les requêtes dans ce back end. La valeur par défaut est 100. Exécutez oc expliquer routes.spec.alternateBackends pour plus d’informations sur les options.
  4. Cliquez sur Save.
  1. Accédez à la page Networking Routes.
  2. Cliquez sur Créer un itinéraire.
  3. Entrez le nom de l’itinéraire.
  4. Choisissez le Service.
  5. Cliquez sur Ajouter un service alternatif.
  6. Entrez une valeur pour le poids et le poids de service alternatif. Entrez un nombre compris entre 0 et 255 qui représente un poids relatif par rapport à d’autres cibles. La valeur par défaut est 100.
  7. Choisissez le port cible.
  8. Cliquez sur Create.
6.5.5.1.3. Gérer les poids à l’aide du CLI
Copier lien

Procédure

  1. Afin de gérer les services et les poids correspondants de charge équilibrés par l’itinéraire, utilisez la commande route-backends oc set: 

    $ oc set route-backends ROUTENAME \
    [--zero|--equal] [--adjust] SERVICE=WEIGHT[%] [...] [options]
    Copy to Clipboard Toggle word wrap

    A titre d’exemple, ab-exemple-a est le service principal avec poids=198 et ab-example-b comme premier service de rechange avec un poids = 2: 

    $ oc set route-backends ab-example ab-example-a=198 ab-example-b=2
    Copy to Clipboard Toggle word wrap

    Cela signifie que 99% du trafic est envoyé au service ab-exemple-a et 1% pour le service ab-example-b.

    Cette commande ne met pas à l’échelle le déploiement. Il se peut que vous soyez obligé de le faire pour disposer de suffisamment de pods pour gérer le chargement de la demande.

  2. Exécutez la commande sans drapeaux pour vérifier la configuration actuelle: 

    $ oc set route-backends ab-example
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME                    KIND     TO           WEIGHT
routes/ab-example       Service  ab-example-a 198 (99%)
routes/ab-example       Service  ab-example-b 2   (1%)
    Copy to Clipboard Toggle word wrap

  3. Afin de remplacer les valeurs par défaut de l’algorithme d’équilibrage de charge, ajustez l’annotation sur l’itinéraire en réglant l’algorithme sur roundrobin. Dans le cas d’un itinéraire sur Red Hat OpenShift Service sur AWS, l’algorithme d’équilibrage de charge par défaut est défini sur des valeurs aléatoires ou source.

    Afin de définir l’algorithme sur Roundrobin, exécutez la commande: 

    $ oc annotate routes/<route-name> haproxy.router.openshift.io/balance=roundrobin
    Copy to Clipboard Toggle word wrap

    La valeur par défaut est source pour les routes de transmission de la sécurité des couches de transport (TLS). Dans tous les autres itinéraires, la valeur par défaut est aléatoire.

  4. Afin de modifier le poids d’un service individuel par rapport à lui-même ou au service principal, utilisez le drapeau --ajuster. La spécification d’un pourcentage ajuste le service par rapport à la primaire ou à la première alternative (si vous spécifiez la primaire). En cas d’autres backends, leurs poids sont maintenus proportionnels au changement.

    L’exemple suivant modifie le poids des services ab-exemple-a et ab-exemple-b: 

    $ oc set route-backends ab-example --adjust ab-example-a=200 ab-example-b=10
    Copy to Clipboard Toggle word wrap

    Alternativement, modifier le poids d’un service en spécifiant un pourcentage: 

    $ oc set route-backends ab-example --adjust ab-example-b=5%
    Copy to Clipboard Toggle word wrap

    En spécifiant + avant la déclaration de pourcentage, vous pouvez ajuster une pondération par rapport au paramètre actuel. À titre d’exemple: 

    $ oc set route-backends ab-example --adjust ab-example-b=+15%
    Copy to Clipboard Toggle word wrap

    Le drapeau égal fixe le poids de tous les services à 100: 

    $ oc set route-backends ab-example --equal
    Copy to Clipboard Toggle word wrap

    Le drapeau --zero définit le poids de tous les services à 0. Ensuite, toutes les requêtes retournent avec une erreur 503.

    Note

    Les routeurs ne supportent pas tous les backends multiples ou pondérés.

6.5.5.1.4. 1 service, plusieurs objets de déploiement
Copier lien

Procédure

  1. Créez une nouvelle application, en ajoutant une étiquette ab-example=true qui sera commune à tous les fragments: 

    $ oc new-app openshift/deployment-example --name=ab-example-a --as-deployment-config=true --labels=ab-example=true --env=SUBTITLE\=shardA
    Copy to Clipboard Toggle word wrap 
    $ oc delete svc/ab-example-a
    Copy to Clipboard Toggle word wrap

    L’application est déployée et un service est créé. C’est le premier shard.

  2. Rendre l’application disponible via un itinéraire, ou utiliser le service IP directement: 

    $ oc expose deployment ab-example-a --name=ab-example --selector=ab-example\=true
    Copy to Clipboard Toggle word wrap 
    $ oc expose service ab-example
    Copy to Clipboard Toggle word wrap
  3. Accédez à l’application ab-example-&lt;project_name&gt;.&lt;router_domain&gt; pour vérifier que vous voyez l’image v1.

  4. Créez un second fragment basé sur la même image source et étiquette que le premier shard, mais avec une version différente et des variables d’environnement uniques: 

    $ oc new-app openshift/deployment-example:v2 \
    --name=ab-example-b --labels=ab-example=true \
    SUBTITLE="shard B" COLOR="red" --as-deployment-config=true
    Copy to Clipboard Toggle word wrap 
    $ oc delete svc/ab-example-b
    Copy to Clipboard Toggle word wrap

  5. À ce stade, les deux ensembles de gousses sont desservis sous la route. Cependant, étant donné que les deux navigateurs (en laissant une connexion ouverte) et le routeur (par défaut, via un cookie) tentent de préserver votre connexion à un serveur back-end, vous pourriez ne pas voir les deux fragments vous être retournés.

    Forcer votre navigateur à l’un ou l’autre shard:

    1. La commande oc scale permet de réduire les répliques d’ab-exemple-a à 0. 

      $ oc scale dc/ab-example-a --replicas=0
      Copy to Clipboard Toggle word wrap

      Actualisez votre navigateur pour afficher v2 et shard B (en rouge).

    2. Échelle ab-exemple-a à 1 réplique et ab-exemple-b à 0: 

      $ oc scale dc/ab-example-a --replicas=1; oc scale dc/ab-example-b --replicas=0
      Copy to Clipboard Toggle word wrap

      Actualisez votre navigateur pour afficher v1 et shard A (en bleu).

  6. Lorsque vous déclenchez un déploiement sur l’un ou l’autre des fragments, seuls les pods de ce fragment sont affectés. Il est possible de déclencher un déploiement en modifiant la variable d’environnement SUBTITLE dans l’un ou l’autre objet de déploiement: 

    $ oc edit dc/ab-example-a
    Copy to Clipboard Toggle word wrap

    a) ou 

    $ oc edit dc/ab-example-b
    Copy to Clipboard Toggle word wrap
Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat