Limiter le comportement de déploiement à l'aide de règles

Ce document explique comment utiliser des règles de déploiement pour restreindre les actions manuelles ou automatisées du pipeline de diffusion.

Une règle de déploiement est une ressource Cloud Deploy que vous pouvez utiliser pour restreindre les actions manuelles ou automatiques sur un pipeline de diffusion ou une cible sélectionnés (ou tous les pipelines ou cibles).

Quel comportement peut être limité ?

Vous pouvez créer des règles de déploiement pour limiter ou empêcher Cloud Deploy d'effectuer certaines actions sur les déploiements. Par exemple, une règle peut empêcher la création de déploiement pour un pipeline de diffusion donné pendant une période spécifiée. Vous pouvez l'utiliser pour des restrictions saisonnières, par exemple.

Comment les règles sont-elles évaluées et appliquées ?

Pour toute action manuelle ou automatisée, Cloud Deploy effectue les opérations suivantes:

1. Vérifie les autorisations Identity and Access Management.

   Si l'utilisateur ou le compte de service ne dispose pas des autorisations IAM appropriées, l'action n'est pas effectuée et il n'est pas nécessaire d'évaluer les stratégies de déploiement.

2. Vérifie si une règle s'applique au pipeline de diffusion ou de cible, et si c'est le cas, elle est évaluée.

   • Cloud Deploy évalue l'action effectuée pour déterminer si cette règle est applicable.

     Autrement dit, le type d'action et l'appelant correspondent-ils à la règle ?

   • Cloud Deploy vérifie les plages de date et d'heure définies pour la stratégie pour déterminer si elle est en vigueur au moment de la requête.

   • Si la règle est en vigueur et qu'elle s'applique au pipeline de diffusion ou à la cible et à l'action, cette règle est appliquée et l'action est bloquée.

Conditions requises et limites

• Chaque stratégie doit comporter au moins un sélecteur.

• Chaque stratégie doit comporter au moins une règle.

  Tous les ID de règle doivent être uniques dans une stratégie de déploiement.

• Chaque règle doit comporter au moins un timeWindows, et dans ce timeWindows, il doit y avoir un oneTimeWindows ou un weeklyWindows.

  Pour en savoir plus sur l'utilisation des blocs de temps, consultez Dates et heures.

• Vous ne pouvez pas avoir plus de 1 000 stratégies de déploiement par projet/emplacement.

Rôles et autorisations Identity and Access Management requis

En plus des autorisations dont vous avez besoin pour exécuter un pipeline de diffusion Cloud Deploy et effectuer les tâches qui seraient limitées par les règles, plusieurs autorisations sont requises pour effectuer certaines opérations sur la ressource de stratégie:

• clouddeploy.deployPolicies.create
• clouddeploy.deployPolicies.delete
• clouddeploy.deployPolicies.get
• clouddeploy.deployPolicies.list
• clouddeploy.deployPolicies.update
• clouddeploy.deployPolicies.override

Ces autorisations sont incluses dans le rôle roles/clouddeploy.policyAdmin. De plus, le rôle roles/clouddeploy.policyOverrider inclut l'autorisation .override.

Créer une règle de déploiement

Pour créer une ressource de stratégie de déploiement, procédez comme suit:

1. Créez un fichier YAML avec la configuration de la règle de déploiement.

   La configuration inclut un en-tête, qui identifie la ressource en tant que stratégie de déploiement. name est obligatoire.

    apiVersion: deploy.cloud.google.com/v1
    kind: DeployPolicy
    metadata:
      name: 
    description: 
   

2. Ajoutez une référence aux pipelines de diffusion et aux cibles auxquels la stratégie s'applique (le selectors).

   Pour en savoir plus sur les sélecteurs de règles et leur configuration, consultez Déploiement de sélecteurs de règles et la documentation de référence sur le schéma de configuration.

3. Ajoutez une ou plusieurs rules de stratégie.

   Chaque règle décrit une restriction et les circonstances dans lesquelles cette restriction est appliquée. Pour en savoir plus sur les règles de stratégie et leur configuration, consultez Déploiement des règles de stratégie et la documentation de référence sur le schéma de configuration.

4. Appliquez ce fichier à l'aide de gcloud deploy apply --filename= pour créer la ressource.

Les pipelines de diffusion ou cibles référencés sont désormais limités conformément aux règles de la ressource "deploy-policy".

Sélecteurs de règles de déploiement

Les sélecteurs, définis dans les configurations de la règle de déploiement, déterminent les pipelines de diffusion et les cibles concernés par une règle donnée.

Un sélecteur est défini dans une strophe selectors dans la configuration de la règle de déploiement, en tant que propriété de niveau supérieur:

selectors:
- deliveryPipeline:
    id:
    labels:
  target:
    id:
    labels:

Dans ce fichier YAML de configuration, deliveryPipeline.id prend le nom du pipeline de diffusion et target.id prend le nom de la cible (dans les deux cas, metadata.name).

Vous pouvez utiliser id: * pour sélectionner tous les pipelines de diffusion ou toutes les cibles. Vous pouvez également utiliser des libellés pour faire correspondre des pipelines de diffusion ou des cibles, ou les deux.

Dans un sélecteur donné, les éléments sont associés à l'opérateur AND. Plusieurs sélecteurs sont associés à l'opérateur OR. Autrement dit, pour qu'une requête donnée soit limitée par la règle, elle doit s'appliquer à au moins un sélecteur. Toutefois, dans ce sélecteur, la requête doit correspondre à tous les éléments.

Règles de déploiement des stratégies

Chaque stratégie de déploiement inclut une ou plusieurs règles de stratégie, qui définissent l'action limitée dans le pipeline de diffusion ou la cible sélectionnés. La règle définit également dans quelles circonstances elle s'applique.

Les règles suivantes sont disponibles:

• rolloutRestriction

La règle rolloutRestriction empêche les actions de déploiement spécifiées d'être effectuées sur les cibles sélectionnées utilisées par les pipelines de diffusion sélectionnés. Cette règle utilise une période qui définit quand un déploiement ne peut pas être créé pour le pipeline de diffusion et la cible sélectionnés. Pour en savoir plus sur la manière dont les dates et heures sont spécifiées dans les règles de stratégie de déploiement, consultez la section Dates et heures.

Les actions suivantes peuvent être limitées lorsque la règle est en vigueur:

• ADVANCE

  Les phases de déploiement ne peuvent pas être avancées.

• APPROVE

  La promotion de déploiement ne peut pas être approuvée.

• CANCEL

  Les déploiements ne peuvent pas être annulés.

• CREATE

  Il est impossible de créer des déploiements. Vous pouvez créer une version si une règle empêche cette action, mais cette version ne générera pas de déploiement.

• IGNORE_JOB

  Les jobs ne peuvent pas être ignorés.

• RETRY_JOB

  Les tâches ne peuvent pas être relancées.

• ROLLBACK

  Les déploiements ne peuvent pas être annulés.

• TERMINATE_JOBRUN

  Impossible d'arrêter les exécutions de tâches

  Consultez la documentation de référence sur le schéma de configuration pour connaître la structure YAML de cette règle.

Dates et heures dans une règle rolloutRestriction

Vous configurez des blocs de date et d'heure pour spécifier des périodes récurrentes et non récurrentes pendant lesquelles la règle de déploiement est en vigueur.

Voici les exigences concernant l'expression des dates et des heures:

• Les dates sont exprimées sous la forme yyyy-mm-dd.

• Pour indiquer l'heure de la journée, le début de la journée est 00:00 et la fin de la journée est 24:00.

• Pour oneTimeWindows, les dates doivent inclure l'heure. Pour weeklyWindows, vous pouvez omettre l'heure de la journée. Toutefois, si vous incluez startTime, vous devez également inclure endTime, et inversement.

  Par exemple, une suspension des dépenses le dimanche uniquement se présente comme suit:

  - daysOfWeek: [SUNDAY]
    startTime: "00:00"
    endTime: "24:00"
  

  Vous pouvez également procéder comme suit:

  - daysOfWeek: [SUNDAY]
  

  Mais pas:

  - daysOfWeek: [SUNDAY]
    startTime: "00:00"
  

• Vous devez inclure un fuseau horaire dans le stanza timeWindows.

  Exemple : timeZone: America/New_York.

Fenêtres temporelles non répétitives

Une période non récurrente commence et se termine à une date et une heure spécifiques. Vous l'utiliserez pour tout bloc de temps pour lequel vous souhaitez limiter les déploiements.

Les périodes non répétitives sont configurées à l'aide d'une strophe oneTimeWindows.

Fenêtres de temps répétées

Une période récurrente décrit un bloc de temps récurrent pendant lequel vous souhaitez limiter les déploiements. Par exemple, vous pouvez l'utiliser pour limiter les déploiements les week-ends.

Les périodes temporelles récurrentes sont configurées à l'aide d'une strophe weeklyWindows.

Examples

Cette section contient des exemples d'utilisation de dates et d'heures pour configurer le moment où une stratégie de déploiement est appliquée.

Blocage annuel

Si vous souhaitez geler les déploiements à une période donnée de l'année, vous pouvez configurer un bloc oneTimeWindows pour ce faire. Si les dates sont prévisibles d'une année à l'autre, vous devez toujours utiliser plusieurs blocs oneTimeWindow.

Le fichier YAML suivant montre une fenêtre temporelle unique (non répétitive) pour appliquer une stratégie de déploiement pour un blocage annuel:

timeWindows:
  timeZone: "America/New_York"
  oneTimeWindows:
  - start: "2024-12-22 17:00"
    end: "2025-01-02 09:00"

Ce fichier YAML décrit une période allant du 22 décembre 2024 à 17h au 2 janvier 2025 à 9h.

Blocage répété le week-end

Le fichier YAML suivant montre une période récurrente pour appliquer une stratégie de déploiement qui limite les déploiements le week-end, du vendredi à 17h au lundi matin à 9h:

timeWindows:
  timeZone: "America/New_York"
  weeklyWindows:
  - daysOfWeek: [FRIDAY]
    startTime: "17:00"
    endTime: "24:00"
  - daysOfWeek: [SATURDAY, SUNDAY]
    startTime: "00:00"
    endTime: "24:00"
  - daysOfWeek: [MONDAY]
    startTime: "00:00"
    endTime: "09:00"

Mettre à jour une règle de déploiement

Pour mettre à jour une stratégie de déploiement, procédez comme suit:

1. Modifiez le fichier YAML de configuration des règles.

   Si vous avez créé la stratégie à l'aide de la console Google Cloud, vous pouvez obtenir la configuration YAML en sélectionnant l'onglet YAML sur la page Détails de la stratégie de déploiement. Vous pouvez ensuite copier ce texte dans un fichier local et le modifier.

2. Appliquez ce fichier à l'aide de gcloud deploy apply --filename=.

   La ressource de stratégie de déploiement est alors mise à jour avec la nouvelle configuration.

Étant donné que les règles de déploiement sont évaluées lorsque l'action limitée est tentée, toutes ces actions sur toutes les ressources Cloud Deploy sont soumises à la règle mise à jour. Autrement dit, il ne reste aucune trace des restrictions précédentes. Par exemple, si vous avez un blocage restrictRollouts pour tout le mois de décembre et que vous modifiez la règle le 14 décembre pour que la restriction se termine le 15 décembre, les déploiements ne sont plus bloqués après le 15 décembre.

Ignorer une règle de déploiement

Si nécessaire, vous pouvez remplacer une règle de déploiement. Par exemple, si un déploiement en production pose problème et que vous devez le rétablir, mais qu'une règle de déploiement empêche tout déploiement, vous pouvez remplacer cette règle pour rétablir le déploiement incorrect.

Pour remplacer une stratégie de déploiement, vous devez disposer de l'autorisation IAM clouddeploy.deployPolicies.override.

Vous pouvez remplacer la règle à partir de la gcloud CLI ou de la console Google Cloud:

 gcloud deploy releases promote --release=my-release-001 \
   --project=my-policy-testing-project \
   --region=us-central1 \
   --delivery-pipeline=my-pipeline \
   --to-target=prod-target \
   --override-deploy-policies=my-deploy-policy

Supprimer une règle de déploiement

Pour supprimer une règle de déploiement:

 gcloud deploy deploy-policies delete \
    --project=[PROJECT] \
    --region=[REGION] \
    [POLICY_NAME]

Une fois la ressource de stratégie de déploiement supprimée, les pipelines de diffusion et les cibles concernés ne sont plus soumis à la stratégie et ne sont pas limités, sauf s'ils sont affectés par une autre stratégie de déploiement.

Journalisation de la stratégie de déploiement

Lorsqu'une règle de déploiement est évaluée, des entrées de journal de la plate-forme sont créées pour les actions suivantes:

• Évaluation de la stratégie

  Les journaux de la plate-forme sont écrits lorsqu'une requête est évaluée et ne respecte pas la règle. Un journal est également écrit lorsqu'une requête ne respecte pas la règle, mais qu'elle est autorisée, car la règle est suspendue ou a été remplacée. Aucun journal n'est écrit lorsque la requête est accordée, car le règlement n'est pas enfreint.

• Échec de la notification Pub/Sub lors de la modification d'une ressource de stratégie de déploiement.

Étape suivante

• Pour en savoir plus sur la configuration des règles de déploiement, consultez le schéma du fichier de configuration.

• Découvrez l'automatisation du déploiement Cloud Deploy.