Ce document explique comment utiliser les règles de déploiement pour restreindre les actions manuelles ou automatisées du pipeline de déploiement.
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 ou une cible de déploiement sélectionnés (ou sur tous les pipelines ou toutes les cibles).
Quels comportements peuvent être restreints ?
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 d'un déploiement pour un pipeline de diffusion donné pendant une période spécifique. Vous pouvez l'utiliser pour les 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 :
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.
Vérifie s'il existe une règle applicable au pipeline cible ou de diffusion. Si c'est le cas, la règle est évaluée.
Cloud Deploy évalue l'action en cours pour déterminer si cette règle est applicable.
Autrement dit, le type d'action et l'invocateur correspondent-ils à la règle ?
Cloud Deploy vérifie les plages de dates et d'heures définies pour la règle afin de déterminer si elle est en vigueur au moment de la requête.
Si la règle est en vigueur et s'applique au pipeline de diffusion ou à la cible et à l'action, elle 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 règle de déploiement.
Chaque règle doit comporter au moins un
timeWindows, et cetimeWindowsdoit contenir unoneTimeWindowsou unweeklyWindows.Pour en savoir plus sur l'utilisation des plages horaires, 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 déploiement Cloud Deploy et effectuer les tâches qui seraient limitées par les règles, plusieurs autorisations sont nécessaires pour effectuer certaines opérations sur la ressource de règle :
clouddeploy.deployPolicies.createclouddeploy.deployPolicies.deleteclouddeploy.deployPolicies.getclouddeploy.deployPolicies.listclouddeploy.deployPolicies.updateclouddeploy.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
La création d'une ressource deploy-policy comprend les étapes suivantes :
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 comme une règle de déploiement.
nameest obligatoire.apiVersion: deploy.cloud.google.com/v1 kind: DeployPolicy metadata: name: description:Ajoutez une référence aux pipelines de diffusion et aux cibles auxquels la règle s'applique (
selectors).Pour en savoir plus sur les sélecteurs de règles et leur configuration, consultez Déployer des sélecteurs de règles et la documentation de référence sur le schéma de configuration.
Ajoutez une ou plusieurs règles
rules.Chaque règle décrit une restriction et les circonstances dans lesquelles elle est appliquée. Pour en savoir plus sur les règles de stratégie et leur configuration, consultez Déployer des règles de stratégie et la documentation de référence sur le schéma de configuration.
Appliquez ce fichier pour créer la stratégie :
gcloud deploy apply --file=FILENAME \ --region=REGION \ --project=PROJECT_IDOù
FILENAMEest le nom du fichier YAML contenant votre définitionDeployPolicy,REGIONest la région dans laquelle vous souhaitez créer la ressource de règle de déploiement etPROJECT_IDest le projet dans lequel vous souhaitez créer la ressource.
Les pipelines ou cibles de diffusion référencés sont désormais soumis aux règles de la ressource deploy-policy.
Sélecteurs de règles de déploiement
Les sélecteurs, définis dans les configurations des règles de déploiement, déterminent les pipelines et cibles de diffusion concernés par une règle donnée.
Un sélecteur est défini dans une strophe selectors de la configuration de la règle de déploiement, en tant que propriété de premier niveau :
selectors:
- deliveryPipeline:
id:
labels:
target:
id:
labels:
Dans ce fichier YAML de configuration, deliveryPipeline.id prend le nom du pipeline de déploiement 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. Notez que * est une valeur de champ spéciale permettant de tout sélectionner. Les caractères génériques arbitraires ne sont pas acceptés. Vous pouvez également utiliser des libellés pour faire correspondre des pipelines de livraison, des cibles ou les deux.
Dans un sélecteur donné, les éléments sont combinés avec un opérateur AND. Les sélecteurs multiples sont combinés avec un 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.
Déployer des règles de stratégie
Chaque règle de déploiement inclut une ou plusieurs règles qui définissent l'action restreinte dans le pipeline de déploiement ou la cible sélectionnés. La règle définit également les circonstances dans lesquelles elle est appliquée.
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 savoir comment spécifier les dates et les heures dans les règles de stratégie de déploiement, consultez Dates et heures.
Les actions suivantes peuvent être limitées pendant l'application de la règle :
ADVANCEIl n'est pas possible d'avancer les phases de déploiement.
APPROVEImpossible d'approuver la promotion de déploiement.
CANCELLes déploiements ne peuvent pas être annulés.
CREATEIl est impossible de créer des déploiements. Vous pouvez créer une version si une règle vous empêche d'effectuer cette action, mais cette version ne générera pas de déploiement.
IGNORE_JOBLes jobs ne peuvent pas être ignorés.
RETRY_JOBIl n'est pas possible de relancer les jobs.
ROLLBACKLes déploiements ne peuvent pas être annulés.
TERMINATE_JOBRUNImpossible d'arrêter les exécutions de jobs
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 les périodes récurrentes et non récurrentes pendant lesquelles la règle de déploiement est en vigueur.
Voici les exigences à respecter pour exprimer les dates et les heures :
Les dates sont exprimées au format
yyyy-mm-dd.Pour exprimer l'heure de la journée, le début de la journée est
00:00et la fin de la journée est24:00.Pour
oneTimeWindows, les dates doivent inclure l'heure. PourweeklyWindows, vous pouvez omettre l'heure de la journée. Toutefois, si vous incluezstartTime, vous devez inclureendTime, et inversement.Par exemple, un gel uniquement le dimanche se présenterait comme suit :
- daysOfWeek: [SUNDAY] startTime: "00:00" endTime: "24:00"Vous pouvez également procéder comme suit :
- daysOfWeek: [SUNDAY]Mais pas ceci :
- daysOfWeek: [SUNDAY] startTime: "00:00"Vous devez inclure un fuseau horaire dans la stanza
timeWindows.Exemple :
timeZone: America/New_York.
Périodes non répétitives
Un intervalle de temps non récurrent commence et se termine à un jour et une heure spécifiques. Vous pouvez l'utiliser pour toute période pendant laquelle vous souhaitez limiter les déploiements.
Les fenêtres temporelles non répétitives sont configurées à l'aide d'une strophe oneTimeWindows.
Fenêtres temporelles récurrentes
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 le week-end.
Les plages horaires récurrentes sont configurées à l'aide d'une strophe weeklyWindows.
Exemples
Cette section contient des exemples d'utilisation des dates et heures pour configurer le moment où une règle de déploiement est appliquée.
Gel annuel
Si vous souhaitez suspendre les déploiements à une période de l'année, vous pouvez configurer un bloc oneTimeWindows pour le faire. Si les dates sont prévisibles d'une année à l'autre, vous devez quand même utiliser plusieurs blocs oneTimeWindow.
Le fichier YAML suivant montre une période ponctuelle (non répétée) pour appliquer une stratégie de déploiement pour un gel 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.
Gel répété du week-end
Le fichier YAML suivant montre une fenêtre temporelle 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
La mise à jour d'une règle de déploiement comprend les étapes suivantes :
Modifiez le fichier YAML de configuration de la règle.
Si vous avez créé la règle à 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 règle de déploiement. Vous pouvez ensuite copier ce texte dans un fichier local et le modifier.
Appliquez ce fichier pour mettre à jour la règle :
gcloud deploy apply --file=FILENAME \ --region=REGION \ --project=PROJECT_IDLa ressource de règle 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 restreinte 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, le 14 décembre, vous modifiez le règlement pour que la restriction se termine le 15 décembre, les déploiements ne seront plus bloqués après le 15 décembre.
Ignorer une règle de déploiement
Vous pouvez ignorer une règle de déploiement si nécessaire. Par exemple, si un problème survient lors d'un déploiement en production et que vous devez effectuer un rollback, mais qu'une règle de déploiement empêche tout déploiement, vous pouvez ignorer cette règle pour effectuer un rollback du déploiement problématique.
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 à l'aide de la console Google Cloud :
Console
Dans la console Google Cloud , essayez d'effectuer une action bloquée par un règlement.
Une boîte de dialogue s'affiche pour indiquer que l'action est bloquée par une stratégie de déploiement. Cette boîte de dialogue inclut un lien vers le règlement spécifique qui bloque cette action.
Dans le champ de texte fourni, saisissez le nom de la règle, puis cliquez sur Tenter de remplacer les règles.
Si vous disposez de l'autorisation de remplacer la règle, Cloud Deploy exécute l'action.
CLI gcloud
Pour remplacer une règle de déploiement à l'aide de gcloud CLI, ajoutez --override-deploy-policies à la commande pour toute action qui serait empêchée par cette règle. Par exemple, la commande suivante promeut une version, en remplaçant une stratégie de déploiement spécifique qui empêcherait normalement la promotion :
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 :
Console
Dans la console Google Cloud , accédez à la page Règles de déploiement de Cloud Deploy.
Ouvrir la page "Déployer des règles"
La page inclut la liste des règles de déploiement disponibles dans votre projet actuel, le cas échéant.
Sélectionnez le bouton Actions pour la règle que vous souhaitez supprimer, puis cliquez sur Supprimer la règle de déploiement.
Confirmez la suppression en saisissant le nom de la règle de déploiement, puis cliquez sur Confirmer.
La règle est maintenant supprimée. Vous pouvez désormais effectuer toutes les actions qu'elle limitait.
CLI gcloud
Pour supprimer une stratégie de déploiement à l'aide de gcloud CLI, exécutez la commande suivante :
gcloud deploy deploy-policies delete \
--project=[PROJECT] \
--region=[REGION] \
[POLICY_NAME]
Remplacez les éléments suivants :
[POLICY_NAME]Nom de la règle tel qu'il est défini dans le fichier de configuration des règles.
[PROJECT]ID du projet Google Cloud dans lequel vous avez créé la règle de déploiement.
[REGION]Région dans laquelle vous avez créé la règle de déploiement.
Une fois que vous avez supprimé la ressource de stratégie de déploiement, les cibles et les pipelines de déploiement concernés ne sont plus soumis à la stratégie et ne seront pas limités, sauf s'ils sont concerné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 plate-forme sont créées pour les actions suivantes :
Évaluation de la stratégie
Les journaux de plate-forme sont écrits lorsqu'une demande est évaluée et ne respecte pas le règlement. Un journal est également écrit lorsque la règle est enfreinte par une requête, mais que la requête est autorisée parce que la règle est suspendue ou a été remplacée. Aucun journal n'est écrit lorsque la demande 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 règle de déploiement.
Étapes suivantes
Pour en savoir plus sur la configuration des règles de déploiement, consultez le schéma du fichier de configuration.
En savoir plus sur l'automatisation du déploiement Cloud Deploy