8.2. Gestion des processus de déploiement

Procédure

1. Pour lancer un nouveau processus de déploiement à partir d'un objet DeploymentConfig existant, exécutez la commande suivante :

   oc rollout latest dc/<name>

   Note

   Si un processus de déploiement est déjà en cours, la commande affiche un message et un nouveau contrôleur de réplication ne sera pas déployé.

Procédure

1. Pour afficher les détails de tous les contrôleurs de réplication récemment créés pour l'objet DeploymentConfig fourni, y compris tout processus de déploiement en cours, exécutez la commande suivante :

   oc rollout history dc/<name>

2. Pour afficher les détails spécifiques à une révision, ajoutez le drapeau --revision:

   $ oc rollout history dc/<name> --revision=1

3. Pour obtenir des informations plus détaillées sur un objet DeploymentConfig et sa dernière révision, utilisez la commande oc describe:

   oc describe dc <name> $ oc describe dc <name>

Procédure

1. Pour redémarrer un processus de déploiement qui a échoué :

   oc rollout retry dc/<name>

   Si la dernière révision a été déployée avec succès, la commande affiche un message et le processus de déploiement n'est pas réessayé.

   Note

   Une nouvelle tentative de déploiement redémarre le processus de déploiement et ne crée pas de nouvelle révision de déploiement. Le contrôleur de réplication redémarré a la même configuration que celle qu'il avait au moment de l'échec.

Procédure

1. Pour revenir à la dernière révision déployée avec succès de votre configuration :

   oc rollout undo dc/<name>

   Le modèle de l'objet DeploymentConfig est inversé pour correspondre à la révision de déploiement spécifiée dans la commande undo, et un nouveau contrôleur de réplication est démarré. Si aucune révision n'est spécifiée avec --to-revision, la dernière révision déployée avec succès est utilisée.

2. Les déclencheurs de changement d'image sur l'objet DeploymentConfig sont désactivés dans le cadre du retour en arrière afin d'éviter de lancer accidentellement un nouveau processus de déploiement peu après la fin du retour en arrière.

   Pour réactiver les déclencheurs de changement d'image :

   oc set triggers dc/<name> --auto

Procédure

1. Ajoutez les paramètres command au champ spec de l'objet DeploymentConfig. Vous pouvez également ajouter un champ args, qui modifie le champ command (ou ENTRYPOINT si command n'existe pas).

   spec:
     containers:
     - name: <container_name>
       image: 'image'
       command:
         - '<command>'
       args:
         - '<argument_1>'
         - '<argument_2>'
         - '<argument_3>'

   Par exemple, pour exécuter la commande java avec les arguments -jar et /opt/app-root/springboots2idemo.jar:

   spec:
     containers:
     - name: example-spring-boot
       image: 'image'
       command:
         - java
       args:
         - '-jar'
         - /opt/app-root/springboots2idemo.jar

Procédure

1. Pour diffuser les journaux de la dernière révision d'un objet DeploymentConfig donné :

   $ oc logs -f dc/<name>

   Si la dernière révision est en cours ou a échoué, la commande renvoie les journaux du processus responsable du déploiement de vos pods. En cas de succès, elle renvoie les journaux d'un pod de votre application.

2. Vous pouvez également consulter les journaux des anciens processus de déploiement qui ont échoué, si et seulement si ces processus (anciens contrôleurs de réplication et leurs pods de déploiement) existent et n'ont pas été élagués ou supprimés manuellement :

   oc logs --version=1 dc/<name>

Procédure

1. Dans l'exemple suivant, chacun des éléments suivants : resources, cpu, memory et ephemeral-storage est facultatif :

   type: "Recreate"
   resources:
     limits:
       cpu: "100m" 1
       memory: "256Mi" 2
       ephemeral-storage: "1Gi" 3

   1

   cpu is in CPU units: 100m represents 0.1 CPU units (100 * 1e-3).

   2

   memory is in bytes: 256Mi represents 268435456 bytes (256 * 2 ^ 20).

   3

   ephemeral-storage est en octets : 1Gi représente 1073741824 octets (2 ^ 30).

   Toutefois, si un quota a été défini pour votre projet, l'un des deux éléments suivants est nécessaire :

   • Un ensemble de sections resources avec un requests explicite :

       type: "Recreate"
       resources:
         requests: 1
           cpu: "100m"
           memory: "256Mi"
           ephemeral-storage: "1Gi"

     1

     L'objet requests contient la liste des ressources correspondant à la liste des ressources du quota.

   • Une plage de limites définie dans votre projet, où les valeurs par défaut de l'objet LimitRange s'appliquent aux pods créés au cours du processus de déploiement.

   Pour définir les ressources de déploiement, choisissez l'une des options ci-dessus. Dans le cas contraire, la création d'un pod de déploiement échoue, en raison d'un quota non atteint.

Procédure

1. Pour mettre à l'échelle manuellement un objet DeploymentConfig, utilisez la commande oc scale. Par exemple, la commande suivante définit les répliques de l'objet frontend DeploymentConfig sur 3.

   $ oc scale dc frontend --replicas=3

   Le nombre de répliques se propage finalement à l'état souhaité et actuel du déploiement configuré par l'objet DeploymentConfig frontend .

Procédure

1. Créer un nouveau projet.
2. Sur la page Workloads, créez un secret contenant les informations d'identification permettant d'accéder à un dépôt d'images privé.
3. Créer un objet DeploymentConfig.
4. Sur la page de l'éditeur d'objets DeploymentConfig, définissez l'objet Pull Secret et enregistrez vos modifications.

Procédure

1. Pour ajouter un sélecteur de nœud lors de la création d'un module, modifiez la configuration Pod et ajoutez la valeur nodeSelector. Cette valeur peut être ajoutée à une seule configuration Pod ou à un modèle Pod:

   apiVersion: v1
   kind: Pod
   spec:
     nodeSelector:
       disktype: ssd
   ...

   Les pods créés lorsque le sélecteur de nœuds est en place sont assignés aux nœuds avec les étiquettes spécifiées. Les étiquettes spécifiées ici sont utilisées conjointement avec les étiquettes ajoutées par un administrateur de cluster.

   Par exemple, si l'administrateur du cluster a ajouté les labels type=user-node et region=east à un projet et que vous ajoutez le label disktype: ssd ci-dessus à un module, ce dernier n'est jamais planifié que sur les nœuds qui ont les trois labels.

   Note

   Les étiquettes ne peuvent être définies que sur une seule valeur, de sorte que la définition d'un sélecteur de nœud de region=west dans une configuration Pod qui a region=east comme valeur par défaut définie par l'administrateur, entraîne la création d'un module qui ne sera jamais programmé.

Procédure

1. Modifiez l'objet DeploymentConfig:

   oc edit dc/<deployment_config>

2. Ajoutez les paramètres serviceAccount et serviceAccountName au champ spec et indiquez le compte de service que vous souhaitez utiliser :

   spec:
     securityContext: {}
     serviceAccount: <service_account>
     serviceAccountName: <service_account>