Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

6.4. En utilisant des stratégies de déploiement

Les stratégies de déploiement sont utilisées pour modifier ou mettre à niveau les applications sans temps d’arrêt afin que les utilisateurs remarquent à peine un changement.

Étant donné que les utilisateurs accèdent généralement aux applications via une route gérée par un routeur, les stratégies de déploiement peuvent se concentrer sur les fonctionnalités d’objet DeploymentConfig ou les fonctionnalités de routage. Les stratégies qui se concentrent sur l’objet DeploymentConfig ont un impact sur tous les itinéraires qui utilisent l’application. Les stratégies qui utilisent le routeur comprennent des itinéraires individuels ciblés.

La plupart des stratégies de déploiement sont prises en charge par l’objet DeploymentConfig, et certaines stratégies supplémentaires sont prises en charge par le biais de fonctionnalités de routeur.

6.4.1. Choisir une stratégie de déploiement
Copier lien

Considérez ce qui suit lors du choix d’une stratégie de déploiement:

  • Les connexions de longue durée doivent être gérées gracieusement.
  • Les conversions de bases de données peuvent être complexes et doivent être faites et retournées avec l’application.
  • Lorsque l’application est un hybride de microservices et de composants traditionnels, des temps d’arrêt pourraient être nécessaires pour terminer la transition.
  • Il faut avoir l’infrastructure nécessaire pour le faire.
  • Lorsque vous disposez d’un environnement de test non isolé, vous pouvez casser les versions nouvelles et anciennes.

La stratégie de déploiement utilise des vérifications de préparation pour déterminer si un nouveau pod est prêt à être utilisé. En cas d’échec d’une vérification de préparation, l’objet DeploymentConfig se répète pour exécuter le pod jusqu’à ce qu’il soit éteint. Le timeout par défaut est 10m, une valeur définie dans TimeoutSeconds dans dc.spec.strarategy.*params.

6.4.2. La stratégie de roulement
Copier lien

Le déploiement mobile remplace lentement les instances de la version précédente d’une application par des instances de la nouvelle version de l’application. La stratégie de roulement est la stratégie de déploiement par défaut utilisée si aucune stratégie n’est spécifiée sur un objet DeploymentConfig.

En général, un déploiement roulant attend que les nouveaux pods deviennent prêts via un contrôle de préparation avant de réduire les anciens composants. En cas de problème important, le déploiement roulant peut être avorté.

Lors de l’utilisation d’un déploiement roulant:

  • Lorsque vous voulez ne pas prendre de temps d’arrêt lors d’une mise à jour de l’application.
  • Lorsque votre application prend en charge l’ancien code et le nouveau code en même temps.

Le déploiement continu signifie que vous avez des versions anciennes et nouvelles de votre code en même temps. Cela nécessite généralement que votre application gère la compatibilité N-1.

Définition d’une stratégie de roulement

kind: DeploymentConfig
apiVersion: apps.openshift.io/v1
metadata:
  name: example-dc
# ...
spec:
# ...
  strategy:
    type: Rolling
    rollingParams:
      updatePeriodSeconds: 1
1 

      intervalSeconds: 1
2 

      timeoutSeconds: 120
3 

      maxSurge: "20%"
4 

      maxUnavailable: "10%"
5 

      pre: {}
6 

     post: {}
Copy to Clipboard Toggle word wrap

1
Le temps d’attendre entre les mises à jour individuelles des pod. En cas d’absence de précision, cette valeur par défaut à 1.
2
Le temps d’attendre entre le sondage de l’état du déploiement après la mise à jour. En cas d’absence de précision, cette valeur par défaut à 1.
3
Le temps d’attendre un événement de mise à l’échelle avant d’abandonner. Facultatif; la valeur par défaut est 600. Ici, abandonner signifie retourner automatiquement au déploiement complet précédent.
4
le maxSurge est facultatif et par défaut à 25% s’il n’est pas spécifié. Consultez les informations ci-dessous la procédure suivante.
5
le maxUnavailable est optionnel et par défaut à 25% s’il n’est pas spécifié. Consultez les informations ci-dessous la procédure suivante.
6
les pré et post sont tous deux des crochets du cycle de vie.

La stratégie de roulement:

  1. Exécute n’importe quel crochet de cycle de vie.
  2. Augmente le nouveau contrôleur de réplication en fonction du nombre de surtensions.
  3. Réduit l’ancien contrôleur de réplication en fonction du nombre maximum indisponible.
  4. Il répète cette mise à l’échelle jusqu’à ce que le nouveau contrôleur de réplication ait atteint le nombre de répliques souhaité et que l’ancien contrôleur de réplication ait été mis à l’échelle à zéro.
  5. Exécute n’importe quel crochet après le cycle de vie.
Important

Lors de la mise à l’échelle, la stratégie de roulement attend que les pods deviennent prêts afin qu’il puisse décider si une autre mise à l’échelle affecterait la disponibilité. En cas de mise à l’échelle des pods ne deviennent jamais prêts, le processus de déploiement finira par s’achever et entraînera une défaillance du déploiement.

Le paramètre maxUnavailable est le nombre maximum de pods qui peuvent être indisponibles pendant la mise à jour. Le paramètre maxSurge est le nombre maximum de gousses qui peuvent être programmées au-dessus du nombre original de gousses. Les deux paramètres peuvent être définis sur un pourcentage (par exemple, 10 %) ou une valeur absolue (par exemple, 2). La valeur par défaut pour les deux est de 25%.

Ces paramètres permettent de régler le déploiement pour la disponibilité et la vitesse. À titre d’exemple:

  • le maxUnavailable*=0 et maxSurge*=20% assurent le maintien de la pleine capacité pendant la mise à jour et la mise à l’échelle rapide.
  • * maxUnavailable*=10% et maxSurge*=0 effectue une mise à jour sans capacité supplémentaire (une mise à jour en place).
  • le maxUnavailable*=10% et maxSurge*=10% augmentent et diminuent rapidement avec un certain potentiel de perte de capacité.

Généralement, si vous voulez des déploiements rapides, utilisez maxSurge. Dans le cas où vous devez prendre en compte le quota de ressources et accepter l’indisponibilité partielle, utilisez maxUnavailable.

Avertissement

Le paramètre par défaut pour maxUnavailable est 1 pour tous les pools de configuration de la machine dans Red Hat OpenShift Service sur AWS. Il est recommandé de ne pas modifier cette valeur et de mettre à jour un nœud de plan de contrôle à la fois. Il ne faut pas changer cette valeur à 3 pour le pool de plan de contrôle.

6.4.2.1. Déploiements des Canaries
Copier lien

Les déploiements roulants dans Red Hat OpenShift Service sur AWS sont des déploiements canaris ; une nouvelle version (le canari) est testée avant que toutes les anciennes instances ne soient remplacées. Lorsque la vérification de préparation ne réussit jamais, l’instance canari est supprimée et l’objet DeploymentConfig sera automatiquement redéployé.

La vérification de préparation fait partie du code d’application et peut être aussi sophistiquée que nécessaire pour s’assurer que la nouvelle instance est prête à être utilisée. Lorsque vous devez implémenter des vérifications plus complexes de l’application (comme l’envoi de véritables charges de travail utilisateur à la nouvelle instance), envisagez de mettre en œuvre un déploiement personnalisé ou d’utiliser une stratégie de déploiement bleu-vert.

6.4.2.2. Création d’un déploiement mobile
Copier lien

Les déploiements roulants sont le type par défaut dans Red Hat OpenShift Service sur AWS. Il est possible de créer un déploiement mobile à l’aide du CLI.

Procédure

  1. Créer une application basée sur l’exemple d’images de déploiement trouvées dans Quay.io: 

    $ oc new-app quay.io/openshifttest/deployment-example:latest
    Copy to Clipboard Toggle word wrap
    Note

    Cette image n’expose aucun port. Lorsque vous souhaitez exposer vos applications sur un service externe LoadBalancer ou activer l’accès à l’application via Internet public, créez un service en utilisant la commande oc expose dc/déployment-exemple --port=<port> après avoir terminé cette procédure.

  2. Lorsque vous avez installé le routeur, rendez l’application disponible via un itinéraire ou utilisez l’IP du service directement. 

    $ oc expose svc/deployment-example
    Copy to Clipboard Toggle word wrap
  3. Accédez à l’application à l’exemple de déploiement.<project>.<router_domain> pour vérifier que vous voyez l’image v1.

  4. Faites évoluer l’objet DeploymentConfig jusqu’à trois répliques: 

    $ oc scale dc/deployment-example --replicas=3
    Copy to Clipboard Toggle word wrap

  5. Déclenchez automatiquement un nouveau déploiement en étiquetant une nouvelle version de l’exemple comme la dernière balise: 

    $ oc tag deployment-example:v2 deployment-example:latest
    Copy to Clipboard Toggle word wrap
  6. Dans votre navigateur, actualisez la page jusqu’à ce que vous voyez l’image v2.

  7. Lors de l’utilisation du CLI, la commande suivante indique combien de pods sont sur la version 1 et combien sont sur la version 2. Dans la console web, les pods sont progressivement ajoutés à v2 et supprimés de v1: 

    $ oc describe dc deployment-example
    Copy to Clipboard Toggle word wrap

Au cours du processus de déploiement, le nouveau contrôleur de réplication est progressivement mis à l’échelle. Après que les nouveaux pods soient marqués comme prêts (en passant leur vérification de préparation), le processus de déploiement se poursuit.

Dans le cas où les pods ne deviennent pas prêts, le processus s’absente et le déploiement revient à sa version précédente.

En utilisant la perspective Développeur, vous pouvez modifier la stratégie de déploiement, les paramètres d’image, les variables d’environnement et les options avancées pour votre déploiement.

Conditions préalables

  • Dans la perspective Développeur de la console web.
  • C’est vous qui avez créé une application.

Procédure

  1. Accédez à la vue Topology.
  2. Cliquez sur votre application pour voir le panneau Détails.
  3. Dans le menu déroulant Actions, sélectionnez Modifier le déploiement pour afficher la page Modifier le déploiement.

  4. Il est possible d’éditer les options avancées suivantes pour votre déploiement:

    1. Facultatif: Vous pouvez mettre fin aux déploiements en cliquant sur les déploiements de Pause, puis en sélectionnant les déploiements de Pause pour cette case à cocher de déploiement.

      En mettant en pause les déploiements, vous pouvez apporter des modifications à votre application sans déclencher un déploiement. À tout moment, vous pouvez reprendre les déploiements.

    2. Facultatif: Cliquez sur Évoluer pour modifier le nombre d’instances de votre image en modifiant le nombre de répliques.
  5. Cliquez sur Save.

Il est possible de mettre à niveau une application en démarrant un déploiement mobile.

Conditions préalables

  • Dans la perspective Développeur de la console web.
  • C’est vous qui avez créé une application.

Procédure

  1. Dans la vue Topologie, cliquez sur le nœud de l’application pour voir l’onglet Aperçu dans le panneau latéral. Il est à noter que la stratégie de mise à jour est définie sur la stratégie de roulement par défaut.

  2. Dans le menu déroulant Actions, sélectionnez Démarrer le déploiement pour lancer une mise à jour continue. Le déploiement roulant fait tourner la nouvelle version de l’application, puis met fin à l’ancienne.

    Figure 6.1. La mise à jour continue

    la mise à jour du roulement ODC
    View larger image
    la mise à jour du roulement ODC

6.4.3. Créer une stratégie
Copier lien

La stratégie de recréation a un comportement de déploiement de base et prend en charge les crochets du cycle de vie pour injecter du code dans le processus de déploiement.

Exemple recréer la définition de stratégie

kind: Deployment
apiVersion: apps/v1
metadata:
  name: hello-openshift
# ...
spec:
# ...
  strategy:
    type: Recreate
    recreateParams:
1 

      pre: {}
2 

      mid: {}
      post: {}
Copy to Clipboard Toggle word wrap

1
les recréerParams sont facultatifs.
2
avant, le milieu et le post sont des crochets du cycle de vie.

La stratégie de recréer:

  1. Exécute n’importe quel crochet de cycle de vie.
  2. Réduit le déploiement précédent à zéro.
  3. Exécute n’importe quel crochet de cycle de vie moyen.
  4. Augmente le nouveau déploiement.
  5. Exécute n’importe quel crochet après le cycle de vie.
Important

Lors de la mise à l’échelle, si le nombre de répliques du déploiement est supérieur à un, la première réplique du déploiement sera validée pour la préparation avant d’augmenter complètement le déploiement. En cas d’échec de la validation de la première réplique, le déploiement sera considéré comme un échec.

Lors de l’utilisation d’un déploiement recréé:

  • Lorsque vous devez effectuer des migrations ou d’autres transformations de données avant le début de votre nouveau code.
  • Lorsque vous ne supportez pas d’avoir des versions nouvelles et anciennes de votre code d’application en même temps.
  • Lorsque vous souhaitez utiliser un volume RWO, qui n’est pas pris en charge étant partagé entre plusieurs répliques.

Le déploiement recrée entraîne des temps d’arrêt parce que, pendant une courte période, aucune instance de votre application n’est en cours d’exécution. Cependant, votre ancien code et votre nouveau code ne s’exécutent pas en même temps.

En utilisant la perspective Développeur, vous pouvez modifier la stratégie de déploiement, les paramètres d’image, les variables d’environnement et les options avancées pour votre déploiement.

Conditions préalables

  • Dans la perspective Développeur de la console web.
  • C’est vous qui avez créé une application.

Procédure

  1. Accédez à la vue Topology.
  2. Cliquez sur votre application pour voir le panneau Détails.
  3. Dans le menu déroulant Actions, sélectionnez Modifier le déploiement pour afficher la page Modifier le déploiement.

  4. Il est possible d’éditer les options avancées suivantes pour votre déploiement:

    1. Facultatif: Vous pouvez mettre fin aux déploiements en cliquant sur les déploiements de Pause, puis en sélectionnant les déploiements de Pause pour cette case à cocher de déploiement.

      En mettant en pause les déploiements, vous pouvez apporter des modifications à votre application sans déclencher un déploiement. À tout moment, vous pouvez reprendre les déploiements.

    2. Facultatif: Cliquez sur Évoluer pour modifier le nombre d’instances de votre image en modifiant le nombre de répliques.
  5. Cliquez sur Save.

La stratégie de déploiement peut passer de la mise à jour par défaut à une mise à jour recréée en utilisant la perspective Développeur dans la console Web.

Conditions préalables

  • Assurez-vous que vous êtes dans la perspective Développeur de la console Web.
  • Assurez-vous d’avoir créé une application à l’aide de la vue Ajouter et de la voir déployée dans la vue Topology.

Procédure

De passer à une stratégie de recréer la mise à jour et de mettre à niveau une application:

  1. Cliquez sur votre application pour voir le panneau Détails.
  2. Dans le menu déroulant Actions, sélectionnez Edit Deployment Config pour voir les détails de configuration de déploiement de l’application.
  3. Dans l’éditeur YAML, modifiez spec.strarategy.type pour Recréer et cliquez sur Enregistrer.
  4. Dans la vue Topologie, sélectionnez le nœud pour voir l’onglet Aperçu dans le panneau latéral. La stratégie de mise à jour est maintenant définie sur Recreate.

  5. Dans le menu déroulant Actions, sélectionnez Démarrer le déploiement pour lancer une mise à jour à l’aide de la stratégie de recréation. La stratégie de recréation termine d’abord les pods pour l’ancienne version de l’application, puis tourne les pods pour la nouvelle version.

    Figure 6.2. Créer une mise à jour

    l’ODC recrée la mise à jour
    View larger image
    l’ODC recrée la mise à jour

6.4.4. La stratégie personnalisée
Copier lien

La stratégie personnalisée vous permet de fournir votre propre comportement de déploiement.

Exemple de définition de stratégie personnalisée

kind: DeploymentConfig
apiVersion: apps.openshift.io/v1
metadata:
  name: example-dc
# ...
spec:
# ...
  strategy:
    type: Custom
    customParams:
      image: organization/strategy
      command: [ "command", "arg1" ]
      environment:
        - name: ENV_1
          value: VALUE_1
Copy to Clipboard Toggle word wrap

Dans l’exemple ci-dessus, l’image du conteneur d’organisation/stratégie fournit le comportement de déploiement. Le tableau de commande optionnel remplace toute directive CMD spécifiée dans le Dockerfile de l’image. Les variables d’environnement optionnelles fournies sont ajoutées à l’environnement d’exécution du processus de stratégie.

De plus, Red Hat OpenShift Service sur AWS fournit les variables d’environnement suivantes au processus de déploiement:

Expand
La variable d’environnementDescription

AJOUTER AU PANIER OPENSHIFT_DEPLOYMENT_NAME

Le nom du nouveau déploiement, un contrôleur de réplication.

DESCRIPTION DU PRODUIT OPENSHIFT_DEPLOYMENT_NAMESPACE

L’espace nom du nouveau déploiement.

Le nombre de répliques du nouveau déploiement sera initialement nul. La responsabilité de la stratégie est de rendre le nouveau déploiement actif en utilisant la logique qui répond le mieux aux besoins de l’utilisateur.

Alternativement, utilisez l’objet CustomParams pour injecter la logique de déploiement personnalisée dans les stratégies de déploiement existantes. Fournissez une logique de script shell personnalisé et appelez le binaire openshift-déploy. Les utilisateurs n’ont pas à fournir leur image de conteneur de déploiement personnalisé; dans ce cas, le service par défaut Red Hat OpenShift sur l’image de déploiement AWS est utilisé à la place: 

kind: DeploymentConfig
apiVersion: apps.openshift.io/v1
metadata:
  name: example-dc
# ...
spec:
# ...
  strategy:
    type: Rolling
    customParams:
      command:
      - /bin/sh
      - -c
      - |
        set -e
        openshift-deploy --until=50%
        echo Halfway there
        openshift-deploy
        echo Complete
Copy to Clipboard Toggle word wrap

Il en résulte un déploiement suivant: 

Started deployment #2
--> Scaling up custom-deployment-2 from 0 to 2, scaling down custom-deployment-1 from 2 to 0 (keep 2 pods available, don't exceed 3 pods)
    Scaling custom-deployment-2 up to 1
--> Reached 50% (currently 50%)
Halfway there
--> Scaling up custom-deployment-2 from 1 to 2, scaling down custom-deployment-1 from 2 to 0 (keep 2 pods available, don't exceed 3 pods)
    Scaling custom-deployment-1 down to 1
    Scaling custom-deployment-2 up to 2
    Scaling custom-deployment-1 down to 0
--> Success
Complete
Copy to Clipboard Toggle word wrap

Lorsque le processus de stratégie de déploiement personnalisé nécessite l’accès au service Red Hat OpenShift sur AWS API ou à l’API Kubernetes, le conteneur qui exécute la stratégie peut utiliser le jeton de compte de service disponible à l’intérieur du conteneur pour l’authentification.

En utilisant la perspective Développeur, vous pouvez modifier la stratégie de déploiement, les paramètres d’image, les variables d’environnement et les options avancées pour votre déploiement.

Conditions préalables

  • Dans la perspective Développeur de la console web.
  • C’est vous qui avez créé une application.

Procédure

  1. Accédez à la vue Topology.
  2. Cliquez sur votre application pour voir le panneau Détails.
  3. Dans le menu déroulant Actions, sélectionnez Modifier le déploiement pour afficher la page Modifier le déploiement.

  4. Il est possible d’éditer les options avancées suivantes pour votre déploiement:

    1. Facultatif: Vous pouvez mettre fin aux déploiements en cliquant sur les déploiements de Pause, puis en sélectionnant les déploiements de Pause pour cette case à cocher de déploiement.

      En mettant en pause les déploiements, vous pouvez apporter des modifications à votre application sans déclencher un déploiement. À tout moment, vous pouvez reprendre les déploiements.

    2. Facultatif: Cliquez sur Évoluer pour modifier le nombre d’instances de votre image en modifiant le nombre de répliques.
  5. Cliquez sur Save.

6.4.5. Crochets de cycle de vie
Copier lien

Les stratégies de roulement et de recréation prennent en charge les crochets du cycle de vie, ou les crochets de déploiement, qui permettent d’injecter le comportement dans le processus de déploiement à des points prédéfinis dans la stratégie:

Exemple de crochet pré cycle de vie

pre:
  failurePolicy: Abort
  execNewPod: {}
1
Copy to Clipboard Toggle word wrap

1
execNewPod est un crochet de cycle de vie à base de pod.

Chaque crochet a une politique d’échec, qui définit l’action que la stratégie doit prendre lorsqu’une défaillance de crochet est rencontrée:

Expand

Avort

Le processus de déploiement sera considéré comme un échec si le crochet échoue.

Essayez de réessayer

L’exécution du crochet doit être récupérée jusqu’à ce qu’elle réussisse.

Ignorer

Les pannes de crochet doivent être ignorées et le déploiement doit se poursuivre.

Les crochets ont un champ spécifique qui décrit comment exécuter le crochet. Actuellement, les crochets à base de pod sont le seul type de crochet pris en charge, spécifié par le champ execNewPod.

Crochet de cycle de vie à base de pod

Les crochets de cycle de vie à base de pod exécutent le code de crochet dans une nouvelle pod dérivée du modèle dans un objet DeploymentConfig.

L’exemple de déploiement simplifié suivant utilise la stratégie de roulement. Les déclencheurs et d’autres détails mineurs sont omis pour la brièveté: 

kind: DeploymentConfig
apiVersion: apps.openshift.io/v1
metadata:
  name: frontend
spec:
  template:
    metadata:
      labels:
        name: frontend
    spec:
      containers:
        - name: helloworld
          image: openshift/origin-ruby-sample
  replicas: 5
  selector:
    name: frontend
  strategy:
    type: Rolling
    rollingParams:
      pre:
        failurePolicy: Abort
        execNewPod:
          containerName: helloworld
1 

          command: [ "/usr/bin/command", "arg1", "arg2" ]
2 

          env:
3 

            - name: CUSTOM_VAR1
              value: custom_value1
          volumes:
            - data
4
Copy to Clipboard Toggle word wrap
1
Le nom helloworld fait référence à spec.template.spec.containers[0].name.
2
Cette commande remplace toute ENTRYPOINT définie par l’image openshift/origin-ruby-sample.
3
ENV est un ensemble optionnel de variables d’environnement pour le conteneur de crochet.
4
les volumes sont un ensemble facultatif de références de volume pour le récipient à crochets.

Dans cet exemple, le crochet pré sera exécuté dans un nouveau pod en utilisant l’image openshift/origin-ruby-sample du conteneur helloworld. La gousse de crochet a les propriétés suivantes:

  • La commande crochet est /usr/bin/command arg1 arg2.
  • Le conteneur de crochet a la variable d’environnement CUSTOM_VAR1=custom_value1.
  • La politique d’échec du crochet est Abort, ce qui signifie que le processus de déploiement échoue si le crochet échoue.
  • La gousse de crochet hérite du volume de données de la pod objet DeploymentConfig.

6.4.5.1. Réglage des crochets du cycle de vie
Copier lien

Il est possible de définir des crochets de cycle de vie, ou des crochets de déploiement, pour un déploiement à l’aide du CLI.

Procédure

  1. La commande oc set déploiement-hook permet de définir le type de crochet que vous souhaitez: --pre, --mid, ou --post. À titre d’exemple, pour définir un crochet de pré-déploiement: 

    $ oc set deployment-hook dc/frontend \
    --pre -c helloworld -e CUSTOM_VAR1=custom_value1 \
    --volumes data --failure-policy=abort -- /usr/bin/command arg1 arg2
    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