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 politiques de déploiement des mises à niveau
Une politique de déploiement des mises à niveau définit la manière dont AWS les services appliquent les mises à niveau automatiques à vos ressources. Comprendre la syntaxe des politiques vous permet de créer des politiques efficaces qui répondent aux exigences de mise à niveau de votre organisation.
Rubriques
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 hors production et développez-les progressivement pour garantir le comportement souhaité. Pour de plus amples informations, veuillez consulter Commencez petit et agrandissez progressivement.
-
Les modifications de politique peuvent mettre plusieurs heures à se propager dans l'ensemble de votre organisation. Planifiez vos implémentations en conséquence et assurez-vous qu'un suivi approprié 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. Gardez les structures des politiques aussi simples que possible tout en répondant à vos exigences.
-
Des examens réguliers 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é passent par défaut à l'ordre « Second ». 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 priorité sur les ordres de mise à niveau définis par les règles. Assurez-vous que vos processus de gestion des modifications tiennent compte à la fois 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 implémentez des politiques de déploiement de mises à niveau basées sur des balises depuis votre compte de gestion, sachez que le compte de gestion ne peut pas directement afficher ou accéder aux balises au niveau des ressources dans les comptes membres. Nous vous recommandons de mettre en place un processus dans lequel 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 les utiliser Politiques de balises pour maintenir des balises cohérentes lorsque les ressources sont balisées dans l'ensemble 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 de politique (telles que les informations de version)
-
Règles de ciblage des ressources
-
Spécifications des commandes de mise à niveau
-
Messages d'exception facultatifs
-
Service-specific attributs
L'exemple suivant illustre la structure de base d'une politique de déploiement des mises à niveau :
{ "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 comprend deux éléments clés qui fonctionnent ensemble pour contrôler la manière dont les mises à niveau sont appliquées à 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 permet de 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 remplacements 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 qui ne sont pas affectées d'ordre de mise à niveau explicite par le biais de balises suivront cet ordre par défaut.
Note
L'expérience de console d'aujourd'hui 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 plus tard dans le cycle de mise à niveau :
"upgrade_rollout": { "default": { "patch_order": "last" } }
Priorisation du niveau de ressource via des balises
Vous pouvez modifier 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, de vos étapes de développement ou de l'importance 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 leur mise 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 de politique de déploiement des mises à niveau courants :
Exemple 1 : environnement de développement d'abord
Cet exemple montre comment configurer les ressources de votre environnement de développement pour recevoir les mises à niveau en premier. 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": { "patch_order": "first" } } } } }
Exemple 2 : dernier environnement de production
Cet exemple montre comment s'assurer que vos environnements de production reçoivent les dernières mises à niveau. En définissant explicitement les ressources étiquetées de production sur le dernier ordre 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 qui ont des exigences strictes en matière de gestion du changement :
{ "tags": { "environment": { "tag_values": { "production": { "patch_order": "last" } } } } }
Exemple 3 : plusieurs commandes de mise à niveau à l'aide de 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" } } } } } } }
