8.3. Utiliser des stratégies de déploiement

Un déploiement continu 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 déploiement continu 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.

Un déploiement continu attend généralement que les nouveaux pods deviennent ready par le biais d'un contrôle de disponibilité avant de réduire les anciens composants. En cas de problème important, le déploiement continu peut être interrompu.

When to use a rolling deployment:

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

strategy:
  type: Rolling
  rollingParams:
    updatePeriodSeconds: 1 1
    intervalSeconds: 1 2
    timeoutSeconds: 120 3
    maxSurge: "20%" 4
    maxUnavailable: "10%" 5
    pre: {} 6
    post: {}

La stratégie de roulement :

Le paramètre maxUnavailable est le nombre maximum de modules qui peuvent être indisponibles pendant la mise à jour. Le paramètre maxSurge est le nombre maximum de modules qui peuvent être planifiés en plus du nombre initial de modules. Les deux paramètres peuvent être définis en pourcentage (par exemple, 10%) ou en valeur absolue (par exemple, 2). La valeur par défaut est 25%.

Ces paramètres permettent d'ajuster le déploiement en termes de disponibilité et de rapidité. Ces paramètres permettent d'ajuster le déploiement en fonction de la disponibilité et de la vitesse :

En règle générale, si vous souhaitez des déploiements rapides, utilisez maxSurge. Si vous devez tenir compte d'un quota de ressources et que vous pouvez accepter une indisponibilité partielle, utilisez maxUnavailable.

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

strategy:
  type: Recreate
  recreateParams: 1
    pre: {} 2
    mid: {}
    post: {}

La stratégie de recréation :

When to use a recreate deployment:

Un déploiement par recréation entraîne des temps d'arrêt car, pendant une brève période, aucune instance de votre application ne s'exécute. Cependant, l'ancien et le nouveau code ne s'exécutent pas en même temps.

Vous pouvez changer la stratégie de déploiement de la mise à jour continue par défaut à une mise à jour de recréation en utilisant la perspective Developer dans la console web.

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

strategy:
  type: Custom
  customParams:
    image: organization/strategy
    command: [ "command", "arg1" ]
    environment:
      - name: ENV_1
        value: VALUE_1

Dans l'exemple ci-dessus, l'image du conteneur organization/strategy fournit le comportement de déploiement. Le tableau facultatif command remplace toute directive CMD spécifiée dans l'image Dockerfile. Les variables d'environnement facultatives fournies sont ajoutées à l'environnement d'exécution du processus de stratégie.

En outre, OpenShift Container Platform fournit les variables d'environnement suivantes au processus de déploiement :

Le nombre de répliques du nouveau déploiement sera initialement égal à zéro. 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.

Vous pouvez également utiliser l'objet customParams pour injecter la logique de déploiement personnalisée dans les stratégies de déploiement existantes. Fournir une logique de script shell personnalisée et appeler le binaire openshift-deploy. Les utilisateurs ne doivent pas fournir leur image de conteneur de déploiement personnalisé ; dans ce cas, l'image de déploiement par défaut d'OpenShift Container Platform est utilisée à la place :

strategy:
  type: Rolling
  customParams:
    command:
    - /bin/sh
    - -c
    - |
      set -e
      openshift-deploy --until=50%
      echo Halfway there
      openshift-deploy
      echo Complete

Il en résulte le 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

Si le processus de stratégie de déploiement personnalisé nécessite un accès à l'API OpenShift Container Platform ou à l'API Kubernetes, le conteneur qui exécute la stratégie peut utiliser le jeton de compte de service disponible dans le conteneur pour l'authentification.

Les stratégies rolling et recreate prennent en charge lifecycle hooks, ou crochets de déploiement, qui permettent d'injecter un comportement dans le processus de déploiement à des points prédéfinis de la stratégie :

pre:
  failurePolicy: Abort
  execNewPod: {} 1

Chaque crochet a un failure policy, qui définit l'action que la stratégie doit entreprendre en cas d'échec du crochet :

Les crochets ont un champ spécifique au type qui décrit comment exécuter le crochet. Actuellement, les crochets basés sur les pods sont le seul type de crochet pris en charge, spécifié par le champ execNewPod.

Crochet de cycle de vie basé sur les pods

Les crochets de cycle de vie basés sur les pods exécutent le code du crochet dans un nouveau pod dérivé 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 par souci de concision :

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

Dans cet exemple, le hook pre sera exécuté dans un nouveau pod utilisant l'image openshift/origin-ruby-sample du conteneur helloworld. Le pod de crochet a les propriétés suivantes :