Syntaxe et exemples de politique de déploiement des mises à niveau - AWS Organizations
ConsidérationsStructure politique de baseComposants de politiqueExemples de politiques de déploiement des mises à niveau

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Syntaxe et exemples de politique de déploiement des mises à niveau

Une politique de déploiement des mises à niveau définit la manière dont les AWS services appliquent les mises à niveau automatiques à l'ensemble de vos ressources. La compréhension de la syntaxe des politiques vous permet de créer des politiques efficaces qui répondent aux exigences de mise à niveau de votre organisation.

Considérations

Lors de la mise en œuvre des politiques de déploiement des mises à niveau, tenez compte des facteurs importants suivants :

  • Les noms des politiques doivent être uniques au sein de votre organisation et doivent être clairs et descriptifs. Choisissez des noms qui reflètent l'objectif et la portée de la politique. Pour de plus amples informations, veuillez consulter Optimisez l'efficacité opérationnelle.

  • Les tests sont essentiels avant un déploiement à grande échelle. Validez d'abord les nouvelles politiques dans les environnements non liés à la production, puis étendez-les progressivement pour garantir le comportement souhaité. Pour de plus amples informations, veuillez consulter Commencez petit et agrandissez progressivement.

  • Les modifications de politique peuvent prendre plusieurs heures pour se propager au sein de votre organisation. Planifiez vos mises en œuvre en conséquence et assurez-vous qu'une surveillance appropriée est en place. Pour de plus amples informations, veuillez consulter Surveiller et communiquer les modifications.

  • Le formatage JSON doit être valide et respecter la taille maximale de la politique de 5 120 octets. Simplifiez au maximum les structures des politiques tout en répondant à vos exigences.

  • Des révisions régulières des politiques contribuent à maintenir l'efficacité. Planifiez des évaluations périodiques de vos politiques pour vous assurer qu'elles continuent de répondre aux besoins de votre organisation. Pour de plus amples informations, veuillez consulter Mettre en place des processus de révision.

  • Les ressources sans ordre de mise à niveau attribué sont par défaut du « deuxième » ordre. Envisagez de définir explicitement des ordres de mise à niveau pour les ressources critiques plutôt que de vous fier aux valeurs par défaut. Pour de plus amples informations, veuillez consulter Validez efficacement les modifications de politique.

  • Les mises à niveau manuelles ont la priorité sur les ordres de mise à niveau définis par des règles. Assurez-vous que vos processus de gestion des modifications tiennent compte des scénarios de mise à niveau automatiques et manuels. Pour de plus amples informations, veuillez consulter Mettre en place des processus de révision.

Note

Lorsque vous mettez en œuvre des politiques de déploiement de mise à niveau basées sur des balises à partir de votre compte de gestion, sachez que le compte de gestion ne peut pas afficher ou accéder directement aux balises au niveau des ressources dans les comptes membres. Nous recommandons d'établir un processus dans le cadre duquel les comptes membres appliquent des balises de ressources cohérentes, puis de créer des politiques au niveau de l'organisation qui font référence à ces balises. Cela garantit une bonne coordination entre le balisage au niveau des ressources et l'application des politiques organisationnelles. Vous pouvez également l'utiliser Politiques de balises pour maintenir la cohérence des balises lorsque les ressources sont balisées au sein de votre organisation.

Structure politique de base

Les politiques de déploiement des mises à niveau utilisent une structure JSON qui inclut les principaux éléments suivants :

  • Métadonnées relatives aux politiques (telles que les informations de version)

  • Règles de ciblage des ressources

  • Spécifications des commandes de mise à niveau

  • Messages d'exception facultatifs

  • Attributs spécifiques au service

L'exemple suivant montre une structure de politique de déploiement de mise à niveau de base :

{
   "upgrade_rollout":{
      "default":{
         "patch_order":{
            "@@assign":"last"
         }
      },
      "tags":{
         "devtag":{
            "tag_values":{
               "tag1":{
                  "patch_order":{
                     "@@assign":"first"
                  }
               },
               "tag2":{
                  "patch_order":{
                     "@@assign":"second"
                  }
               },
               "tag3":{
                  "patch_order":{
                     "@@assign":"last"
                  }
               }
            }
         }
      }
   }
}

Composants de politique

Une politique de déploiement des mises à niveau se compose de deux composants clés qui fonctionnent ensemble pour contrôler la manière dont les mises à niveau sont appliquées à l'ensemble de vos ressources. Ces composants incluent des options de configuration pour les comportements par défaut et les remplacements basés sur des balises. Comprendre comment ces composants interagissent vous aide à créer des politiques efficaces qui répondent aux besoins de votre organisation.

Configuration de l'ordre des correctifs par défaut

Lorsque vous créez une politique de déploiement de mise à niveau sans spécifier de dérogations spécifiques aux ressources, toutes les ressources utilisent par défaut un ordre de mise à niveau de base. Vous pouvez définir cette valeur par défaut à l'aide du champ « par défaut » de votre politique. Les ressources sans attribution explicite d'ordre de mise à niveau via des balises suivront cet ordre par défaut.

Note

L'expérience console actuelle nécessite la spécification d'un ordre par défaut.

L'exemple suivant montre comment configurer toutes les ressources pour qu'elles reçoivent les mises à niveau en dernier par défaut, sauf si elles sont remplacées par des balises. Cette approche est utile lorsque vous souhaitez vous assurer que la plupart des ressources sont mises à jour ultérieurement dans le cycle de mise à niveau :

"upgrade_rollout": {
    "default": {
        "patch_order": "last"
    }
}

Modification du niveau de ressource via des balises

Vous pouvez annuler l'ordre de mise à niveau par défaut pour des ressources spécifiques à l'aide de balises. Cela vous permet de créer un contrôle granulaire sur les ressources qui reçoivent des mises à niveau et dans quel ordre. Par exemple, vous pouvez attribuer différents ordres de mise à niveau en fonction de vos types d'environnement, des étapes de développement ou de la criticité de votre charge de travail.

L'exemple suivant montre comment configurer les ressources de développement pour recevoir les mises à niveau en premier et les ressources de production pour les recevoir en dernier. Cette configuration garantit que vos environnements de développement peuvent valider les mises à niveau avant qu'elles ne soient mises en production :

"upgrade_rollout": {
    "tags": {
        "environment": {
            "tag_values": {
                "development": {
                    "patch_order": "first"
                },
                "production": {
                    "patch_order": "last"
                }
            }
        }
    }
}

Exemples de politiques de déploiement des mises à niveau

Voici les scénarios courants relatifs aux politiques de déploiement des mises à niveau :

Exemple 1 : environnement de développement d'abord

Cet exemple montre comment configurer les ressources de votre environnement de développement pour qu'elles reçoivent d'abord les mises à niveau. En ciblant les ressources à l'aide de la balise d'environnement « développement », vous vous assurez que vos environnements de développement sont les premiers à recevoir et à valider les nouvelles mises à niveau. Ce modèle permet d'identifier les problèmes potentiels avant que les mises à niveau n'atteignent des environnements plus critiques :

{
    "tags": {
        "environment": {
            "tag_values": {
                "development": {
                    "upgrade_order": "first"
                }
            }
        }
    }
}

Exemple 2 : dernier environnement de production

Cet exemple montre comment garantir que vos environnements de production reçoivent les mises à niveau en dernier. En affectant explicitement les ressources étiquetées en production à la dernière commande de mise à niveau, vous maintenez la stabilité de votre environnement de production tout en permettant des tests adéquats dans les environnements de pré-production. Cette approche est particulièrement utile pour les organisations ayant des exigences strictes en matière de gestion du changement :

{
    "tags": {
        "environment": {
            "tag_values": {
                "production": {
                    "upgrade_order": "last"
                }
            }
        }
    }
}

Exemple 3 : plusieurs ordres de mise à niveau utilisant des balises

L'exemple suivant montre comment utiliser une clé de balise unique avec des valeurs différentes pour spécifier les trois ordres de mise à niveau. Cette approche est utile lorsque vous souhaitez gérer les commandes de mise à niveau via un schéma de balisage unique :

{
   "upgrade_rollout":{
      "default":{
         "patch_order":{
            "@@assign":"last"
         }
      },
      "tags":{
         "devtag":{
            "tag_values":{
               "tag1":{
                  "patch_order":{
                     "@@assign":"first"
                  }
               },
               "tag2":{
                  "patch_order":{
                     "@@assign":"second"
                  }
               },
               "tag3":{
                  "patch_order":{
                     "@@assign":"last"
                  }
               }
            }
         }
      }
   }
}